I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference tosiglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference tosigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to Cygwin
could make it hard for non-open source usages.
I can set up a project to create such a package for Windows.On Monday, March 24, 2014 4:33:51 AM UTC-4, Cyrille Duret wrote:
I just mean about the generated code could run under window.
Ideal would be same as Rust language to have proper support os mingw/msys
solution under windows that would generate native windows executables
Surely I would think about pushing ATS in my big projects if I had better
support of all major platforms
cheers
Le dimanche 23 mars 2014 16:28:35 UTC+1, gmhwxi a écrit :
Do you mean (1), or (2), or both?
To make sure that the ATS compiler (ATS/Positats) can run under windows
To make sure that the generated C code from ATS source can run under
windows
On Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
Since interfacing with C in ATS is as simple as modeling the function
prototypes and C structs in ATS it is doubtful that this is what is
holding up ATS.On Sunday, March 23, 2014 1:41:49 AM UTC-7, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use it
for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference
to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
Cool !
As I see ATS2 is already able to generate clean native windows executable.
The hard work is indeed to make the postiats-include package for windows.
It would be nice if you could create an empty package for windows so we
could start to begin some experiments.
I understand better the workflow now :
generate the C files under cygwin,
crosscompile it to mingw with the win32-postiats-include package
My concern is at this time networking support for all platform and I look
at libuv to make a minimal embedded http server
I think I will make a minimal server (based on this project GitHub - philips/libuv-webserver: simple webserver in libuv) and try to compile it on all
platforms.
cheers ;-)Le lundi 24 mars 2014 18:08:46 UTC+1, gmhwxi a écrit :
I would agree step 3) could use some help to have wrapper files make
using Windows as convenient as POSIX but it is just as well to be driven by
a project that actually uses ATS.
Yes, I would say that project-driven development for this sort of thing is
the best.
On Monday, March 24, 2014 12:55:35 PM UTC-4, H Zhang wrote:
Cyrille,
As I have documented earlier in this thread it is not hard to get Windows
executables:
You need to install Cygwin and the MinGW cross compiler from the
Cygwin installer;
You can build ATS itself under Cygwin;
Make sure your ATS user program does not load library files that are
POSIX dependent; if you need Windows functions, model the prototype in ATS
following the book chapter on working with C code;
Run cross compiler on the generated C code to generate Windows
executables
ATS is not a huge system and it is fairly straightforward to figure out
what to do if you run into problems. And if you can’t figure it out on your
own people on this list will be more than happy to help. If you have a
project to work through the kinks please publish you experience so others
can learn too. Early adopters are expected to contribute towards the
success of ATS!
I would agree step 3) could use some help to have wrapper files make
using Windows as convenient as POSIX but it is just as well to be driven by
a project that actually uses ATS.
Haitao
On Monday, March 24, 2014 1:33:51 AM UTC-7, Cyrille Duret wrote:
I just mean about the generated code could run under window.
Ideal would be same as Rust language to have proper support os
mingw/msys solution under windows that would generate native windows
executables
Surely I would think about pushing ATS in my big projects if I had
better support of all major platforms
cheers
Le dimanche 23 mars 2014 16:28:35 UTC+1, gmhwxi a écrit :
Do you mean (1), or (2), or both?
To make sure that the ATS compiler (ATS/Positats) can run under
windows
To make sure that the generated C code from ATS source can run under
windows
On Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation
of ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will
use it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting
to Cygwin could make it hard for non-open source usages.
That is good to know. Cheers!On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
The early adopters will likely be more looking for performance (memory,
latency and speed) and productivity
(needs to be better than C to be attractive). I also think
implementing library in ATS is more likely than
sizable standalone applications completely written in ATS, at least in
the beginning.
I completely agree. I have high hope for the template system of ATS2, which
is primarily designed to greatly increase
programming productivity.
even if you can prove that your code should work there is still no
guarantee that ATS will translate it correctly
Compiler errors are fundamentally different from errors introduced by
programmers.
ATS compiler is a ‘closed world’; it can get better after being used more
and more. While a programmer can get
better, the programmer cannot write code forever.On Monday, March 24, 2014 1:10:12 AM UTC-4, H Zhang wrote:
Dependent types/linear types do seem formidable to use. It is not even
easy to understand code base as mature as the ATS library. On the other
hand ATS does seem to generate quality C code and can effortlessly
interface with C and work with unboxed/C data with no overhead. That is
what is attractive to me.
It is hard to imagine that early adopters of ATS will be those who are
mainly concerned with correctness due to the very limited usage history of
ATS – even if you can prove that your code should work there is still no
guarantee that ATS will translate it correctly (I am not questioning ATS’s
implementation quality just that seems to be the way how people think). The
early adopters will likely be more looking for performance (memory, latency
and speed) and productivity (needs to be better than C to be attractive). I
also think implementing library in ATS is more likely than sizable
standalone applications completely written in ATS, at least in the
beginning. As I noted before GC dependence is a problem for implementing
library in ATS though there are mitigation techniques that we have
discussed, including using multiple heaps (which would suit my requirement
for now).
Haitao
On Sunday, March 23, 2014 8:13:04 PM UTC-7, gmhwxi wrote:
I have to say that ATS is difficult to use in general. My impression is
that
everyone (including myself) trying to use ATS has struggled a lot. The
learning
curve for ATS, as of now, may be simply too steep for most of programmers.
However, I do believe that there are programmers out there who will,
somehow and someday,
be able to make effective use of ATS in writing high-quality software.
On Sunday, March 23, 2014 8:51:39 PM UTC-4, H Zhang wrote:
Since interfacing with C in ATS is as simple as modeling the function
prototypes and C structs in ATS it is doubtful that this is what is
holding up ATS.
On Sunday, March 23, 2014 1:41:49 AM UTC-7, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
I have to say that ATS is difficult to use in general. My impression is that
everyone (including myself) trying to use ATS has struggled a lot. The
learning
curve for ATS, as of now, may be simply too steep for most of programmers.
However, I do believe that there are programmers out there who will,
somehow and someday,
be able to make effective use of ATS in writing high-quality software.On Sunday, March 23, 2014 8:51:39 PM UTC-4, H Zhang wrote:
Since interfacing with C in ATS is as simple as modeling the function
prototypes and C structs in ATS it is doubtful that this is what is
holding up ATS.
On Sunday, March 23, 2014 1:41:49 AM UTC-7, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference
to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
Is there support for longjmp and setjmp under Windows?
If there is, please do:
#define sigsetjmp(env, savesigs) setjmp(env) #define siglongjmp(env, val) longjmp(env, val)On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to Cygwin
could make it hard for non-open source usages.
I don’t think it’s that important to make ATS compiler to run on all major
platforms like Windows. Maybe it’s more interesting to make an ATS compiler
running on Linux to generate C code which is compilabe and runnable on
Windows.On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to Cygwin
could make it hard for non-open source usages.
As I have documented earlier in this thread it is not hard to get Windows
executables:
You need to install Cygwin and the MinGW cross compiler from the Cygwin
installer;
You can build ATS itself under Cygwin;
Make sure your ATS user program does not load library files that are
POSIX dependent; if you need Windows functions, model the prototype in ATS
following the book chapter on working with C code;
Run cross compiler on the generated C code to generate Windows
executables
ATS is not a huge system and it is fairly straightforward to figure out
what to do if you run into problems. And if you can’t figure it out on your
own people on this list will be more than happy to help. If you have a
project to work through the kinks please publish you experience so others
can learn too. Early adopters are expected to contribute towards the
success of ATS!
I would agree step 3) could use some help to have wrapper files make using
Windows as convenient as POSIX but it is just as well to be driven by a
project that actually uses ATS.
HaitaoOn Monday, March 24, 2014 1:33:51 AM UTC-7, Cyrille Duret wrote:
I just mean about the generated code could run under window.
Ideal would be same as Rust language to have proper support os mingw/msys
solution under windows that would generate native windows executables
Surely I would think about pushing ATS in my big projects if I had better
support of all major platforms
cheers
Le dimanche 23 mars 2014 16:28:35 UTC+1, gmhwxi a écrit :
Do you mean (1), or (2), or both?
To make sure that the ATS compiler (ATS/Positats) can run under windows
To make sure that the generated C code from ATS source can run under
windows
On Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
I would agree step 3) could use some help to have wrapper files make
using Windows as convenient as POSIX but it is just as well to be driven by
a project that actually uses ATS.
Yes, I would say that project-driven development for this sort of thing is
the best.On Monday, March 24, 2014 12:55:35 PM UTC-4, H Zhang wrote:
Cyrille,
As I have documented earlier in this thread it is not hard to get Windows
executables:
You need to install Cygwin and the MinGW cross compiler from the Cygwin
installer;
You can build ATS itself under Cygwin;
Make sure your ATS user program does not load library files that are
POSIX dependent; if you need Windows functions, model the prototype in ATS
following the book chapter on working with C code;
Run cross compiler on the generated C code to generate Windows
executables
ATS is not a huge system and it is fairly straightforward to figure out
what to do if you run into problems. And if you can’t figure it out on your
own people on this list will be more than happy to help. If you have a
project to work through the kinks please publish you experience so others
can learn too. Early adopters are expected to contribute towards the
success of ATS!
I would agree step 3) could use some help to have wrapper files make using
Windows as convenient as POSIX but it is just as well to be driven by a
project that actually uses ATS.
Haitao
On Monday, March 24, 2014 1:33:51 AM UTC-7, Cyrille Duret wrote:
I just mean about the generated code could run under window.
Ideal would be same as Rust language to have proper support os mingw/msys
solution under windows that would generate native windows executables
Surely I would think about pushing ATS in my big projects if I had better
support of all major platforms
cheers
Le dimanche 23 mars 2014 16:28:35 UTC+1, gmhwxi a écrit :
Do you mean (1), or (2), or both?
To make sure that the ATS compiler (ATS/Positats) can run under
windows
To make sure that the generated C code from ATS source can run under
windows
On Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
To make sure that the ATS compiler (ATS/Positats) can run under windows
To make sure that the generated C code from ATS source can run under
windowsOn Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use it
for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference
to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
(or even running in cygwin, since that seems to work fine for now)
Brandon Barker
brandon…@gmail.comOn Mon, Mar 24, 2014 at 12:27 PM, Zhiqiang Ren alex.r...@gmail.comwrote:
I don’t think it’s that important to make ATS compiler to run on all major
platforms like Windows. Maybe it’s more interesting to make an ATS compiler
running on Linux to generate C code which is compilabe and runnable on
Windows.
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
Still I had to get around more errors related mostly to the file systems
and processes to get patsopt to compile. Unfortunately the compiled version
does not seem to function correctly and I suspect the problem is with POSIX
file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
HaitaoOn Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
Dependent types/linear types do seem formidable to use. It is not even easy
to understand code base as mature as the ATS library. On the other hand ATS
does seem to generate quality C code and can effortlessly interface with C
and work with unboxed/C data with no overhead. That is what is attractive
to me.
It is hard to imagine that early adopters of ATS will be those who are
mainly concerned with correctness due to the very limited usage history of
ATS – even if you can prove that your code should work there is still no
guarantee that ATS will translate it correctly (I am not questioning ATS’s
implementation quality just that seems to be the way how people think). The
early adopters will likely be more looking for performance (memory, latency
and speed) and productivity (needs to be better than C to be attractive). I
also think implementing library in ATS is more likely than sizable
standalone applications completely written in ATS, at least in the
beginning. As I noted before GC dependence is a problem for implementing
library in ATS though there are mitigation techniques that we have
discussed, including using multiple heaps (which would suit my requirement
for now).
HaitaoOn Sunday, March 23, 2014 8:13:04 PM UTC-7, gmhwxi wrote:
I have to say that ATS is difficult to use in general. My impression is
that
everyone (including myself) trying to use ATS has struggled a lot. The
learning
curve for ATS, as of now, may be simply too steep for most of programmers.
However, I do believe that there are programmers out there who will,
somehow and someday,
be able to make effective use of ATS in writing high-quality software.
On Sunday, March 23, 2014 8:51:39 PM UTC-4, H Zhang wrote:
Since interfacing with C in ATS is as simple as modeling the function
prototypes and C structs in ATS it is doubtful that this is what is
holding up ATS.
On Sunday, March 23, 2014 1:41:49 AM UTC-7, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
By the way, for file-related operations, I suggest that SDL2 be
used. SDL2 has a very liberal licence; it is for developing games
that are OS-independent, but you can certainly use it for other
purposes.
–Hongwei
PS: I haven’t looked at the support for threads in SDL2, but I have
a feeling that it is also good for developing OS-independent software
in general.On Monday, March 24, 2014 12:59:28 PM UTC-4, gmhwxi wrote:
Then it should be largely straightforward. Essentially, you need
Windows-equivalent of the following package:
I can set up a project to create such a package for Windows.
On Monday, March 24, 2014 4:33:51 AM UTC-4, Cyrille Duret wrote:
I just mean about the generated code could run under window.
Ideal would be same as Rust language to have proper support os mingw/msys
solution under windows that would generate native windows executables
Surely I would think about pushing ATS in my big projects if I had better
support of all major platforms
cheers
Le dimanche 23 mars 2014 16:28:35 UTC+1, gmhwxi a écrit :
Do you mean (1), or (2), or both?
To make sure that the ATS compiler (ATS/Positats) can run under
windows
To make sure that the generated C code from ATS source can run under
windows
On Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain
in Cygwin and cross compile to mingw, that way one can focus on addressing
the incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5
release and compiled under Cygwin. I then tested cross compiling to mingw.
It seems to work as long as one avoid incompatible headers (such as
types.cats, unistd, fcntl, wait, stat, mman and maybe more are not
pulled in. Cross compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is
no problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined
reference to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
Would it be so hard work to make a really independant implementation of ATS
and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use it
for a real project because of lack of a proper windows support.Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference
to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
I just mean about the generated code could run under window.
Ideal would be same as Rust language to have proper support os mingw/msys
solution under windows that would generate native windows executables
Surely I would think about pushing ATS in my big projects if I had better
support of all major platforms
cheers
;-)Le dimanche 23 mars 2014 16:28:35 UTC+1, gmhwxi a écrit :
Do you mean (1), or (2), or both?
To make sure that the ATS compiler (ATS/Positats) can run under windows
To make sure that the generated C code from ATS source can run under
windows
On Sunday, March 23, 2014 4:41:49 AM UTC-4, Cyrille Duret wrote:
Would it be so hard work to make a really independant implementation of
ATS and POSIX so one could use it for native windows apps ?
I think ATS is a wonderful language but because of that no one will use
it for a real project because of lack of a proper windows support.
Le jeudi 16 janvier 2014 22:53:46 UTC+1, gmhwxi a écrit :
That is good to know. Cheers!
On Thursday, January 16, 2014 4:03:01 PM UTC-5, H Zhang wrote:
The tip helped. It allowed me to move forward.
Still I had to get around more errors related mostly to the file
systems and processes to get patsopt to compile. Unfortunately the compiled
version does not seem to function correctly and I suspect the problem is
with POSIX file handling (stat vs lstat, some path issues etc).
For now I think the more promising path is to keep the tool chain in
Cygwin and cross compile to mingw, that way one can focus on addressing the
incompatibilities in ATS2 libraries. I downloaded the newest 0.0.5 release
and compiled under Cygwin. I then tested cross compiling to mingw. It seems
to work as long as one avoid incompatible headers (such as types.cats,
unistd, fcntl, wait, stat, mman and maybe more are not pulled in. Cross
compiled exe can run standalone in Windows. Cool!
Haitao
On Thursday, January 16, 2014 12:45:16 AM UTC-8, gmhwxi wrote:
There is no need to use siglongjmp and sigsetjmp.
Is there support for longjmp and setjmp under Windows?
On Thursday, January 16, 2014 3:14:21 AM UTC-5, H Zhang wrote:
Hi,
I have been trying to compile ATS2 using mingw (under Cygwin it is no
problem) and I have run into some roadblocks mostly related to POSIX
assumptions. I was able to work around the superfluous ones by commenting
out most POSIX types related things (like uid/gid etc. that does not appear
to be used by the compiler itself anyway). However at the final link stage
there are errors related to sigsetjmp and siglongjmp:
pats_error_dats.o:pats_error_dats.c:(.text+0x22): undefined reference
to siglongjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0x1e): undefined reference to siglongjmp’
pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xcf7):
undefined reference to sigsetjmp' pats_staexp2_skexp_dats.o:pats_staexp2_skexp_dats.c:(.text+0xd97): undefined reference to sigsetjmp’
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-mingw32/bin/ld:
pats_staexp2_skexp_dats.o: bad reloc address 0x0 in section `.pdata’
collect2: error: ld returned 1 exit status
make[1]: *** [patsopt] Error 1
make: *** [src2_patsopt] Error 2
These appear to be used by the exception mechanism.
Is there any plan to make ATS2 compatible with Windows? Limiting to
Cygwin could make it hard for non-open source usages.
are not