By 'caching compilation' I mean that the machine code is saved and not
regenerated until there are updates to the source code. With this normal
optimizations and normal error-checking can be performed. You can do this
by having a deterministic location for the produced executable
("script.exe", say) and then on startup testing the file modification time
of the source and the generated executable when that exists: if the
executable exists and is newer than the source, just exec it; otherwise,
rebuild it and then exec it.
On Saturday, February 10, 2018 at 8:45:42 AM UTC-6, gmhwxi wrote:
>
> Very interesting. I didn't know this.
>
> What do you mean by caching compilation?
>
> On Friday, February 9, 2018 at 10:53:19 PM UTC-5, Julian Fondren wrote:
>>
>> Scripts are typically invoked directly, as "tool" where tool is in your
>> PATH, or "./tool"
>>
>> In Unix, the kernel itself finds the scripting binary to run an
>> executable file beginning with #!
>> So languages intended for scripting use typically accept #! or # as a
>> line comment.
>>
>> ATS doesn't accept it as a comment, but you can make do with some
>> overhead:
>>
>> $ cat hello.dats
>> //usr/bin/env myatscc "$0"; exit
>> (*
>> ##myatsccdef=\
>> patsopt --constraint-ignore --dynamic $1 | \
>> tcc -run -DATS_MEMALLOC_LIBC -I${PATSHOME} -I${PATSHOME}/ccomp/runtime -
>> $arglst(2)
>> *)
>>
>> implement main0() = println!("Hello, world!")
>> $ ./hello.dats
>> Hello, world!
>>
>> The next step would be to cache the compilation entirely, as with
>> https://github.com/mjambon/ocamlscript
>>
>> On Tuesday, April 25, 2017 at 7:24:19 PM UTC-5, gmhwxi wrote:
>>>
>>>
>>> Often a file of ATS source code has to be compiled with the use of a
>>> Makefile.
>>> This can be quite inconvenient in practice.
>>>
>>> When teaching, I have to answer countless questions regarding the need
>>> of certain
>>> flags for compiling ATS code through the use of patscc/patsopt directly.
>>>
>>> I recently wrote a command 'myatscc' (which should be available to you
>>> if you build
>>> the latest version of ATS (that is, ATS2-0.3.5). The simple idea behind
>>> of 'myatscc' is
>>> like this:
>>>
>>> Given a file, say, foo.dats, one should be able to compile it by issuing
>>> the following
>>> command:
>>>
>>> myatscc foo.dats
>>>
>>> Whatever needed for compiling foo.dats should be written as some form of
>>> comment
>>> inside foo.dats. For instance, the following comment is assumed to be
>>> the default (if
>>> nothing is given explicitly):
>>>
>>> (*
>>> ##myatsccdef=\
>>> patscc -D_GNU_SOURCE -DATS_MEMALLOC_LIBC -o $fname($1) $1
>>> *)
>>>
>>> $1: the first non-flag argument passed to myatscc
>>> $fname: a built-in function for myatscc that returns the proper part of
>>> a filename
>>>
>>> If you just want to see what myatscc generates (but not to execute what
>>> is generated),
>>> please do:
>>>
>>> myatscc --dryrun foo.dats
>>>
>>> I am pretty sure that 'myatscc' will save a great deal of my own time :)
>>>
>>> Cheers!
>>>
>>
--
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-users+unsubscr...@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/cdd933af-8381-4e07-8a87-fe592c00b7c2%40googlegroups.com.
