Non POSIX (really Windows) Support

[H Zhang]

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.

Haitao

[gmhwxi]

There is no need to use siglongjmp and sigsetjmp.

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)

[H Zhang]

1) The tip helped. It allowed me to move forward.

2) 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).

3) 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

[gmhwxi]

That is good to know. Cheers!

[Cyrille Duret]

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.

[gmhwxi]

Do you mean (1), or (2), or both?

1. To make sure that the ATS compiler (ATS/Positats) can run under windows
2. To make sure that the generated C code from ATS source can run under windows

[H Zhang]

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.

[gmhwxi]

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.

[H Zhang]

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

[gmhwxi]

>>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.

[Cyrille Duret]

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

https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust#windows

Surely I would think about pushing ATS in my big projects if I had better support of all major platforms

cheers

;-)

[Zhiqiang Ren]

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:

[Brandon Barker]

(or even running in cygwin, since that seems to work fine for now)

Brandon Barker
brandon...@gmail.com

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/0e8891e2-c9ef-4033-96aa-ed68abf2579c%40googlegroups.com.

[H Zhang]

Cyrille,

As I have documented earlier in this thread it is not hard to get Windows executables:
1) You need to install Cygwin and the MinGW cross compiler from the Cygwin installer;
2) You can build ATS itself under Cygwin;
3) 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;
4) 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

[gmhwxi]

Then it should be largely straightforward. Essentially, you need
Windows-equivalent of the following package:

ATS2-Postiats-include-0.0.6.tgz

which is available in the following directory:

http://sourceforge.net/projects/ats2-lang/files/ats2-lang/ats2-postiats-0.0.6/

I can set up a project to create such a package for Windows.

[gmhwxi]

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.

[gmhwxi]

>>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.

[Cyrille Duret]

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 https://github.com/philips/libuv-webserver) and try to compile it on all platforms.

cheers ;-)