On Mon, 10 Aug 2015 22:22:49 +1200, Rikki Cattermole wrote:
> Nah, I like CTFE a lot.
if it will ever be augmented with AST macros... yes. until then, people
will try to bolt extensions on it again and again, and i have a feeling
that CTFE engine will become another abomination that makes D weir
On 10/08/2015 10:31 p.m., Dmitry Olshansky wrote:
On 10-Aug-2015 13:22, Rikki Cattermole wrote:
On 10/08/2015 9:48 p.m., ketmar wrote:
On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:
I think you mean dlopen, dlsym and dlclose. Not full file system access
geez.
and root privs req
On 10-Aug-2015 13:22, Rikki Cattermole wrote:
On 10/08/2015 9:48 p.m., ketmar wrote:
On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:
I think you mean dlopen, dlsym and dlclose. Not full file system access
geez.
and root privs requirement. just to complement it all.
We are alre
On 10/08/2015 9:48 p.m., ketmar wrote:
On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:
I think you mean dlopen, dlsym and dlclose. Not full file system access
geez.
and root privs requirement. just to complement it all.
We are already getting so close to have a full blown CTFE
On Monday, 10 August 2015 at 09:55:51 UTC, Iain Buclaw wrote:
Who said anything about D-files? import() accepts any
arbitrary text that you may want to embed in a program.
And that is not a problem if it is reading a static file from the
source-bundle, conceptually it just means you have spli
On 10 August 2015 at 10:59, via Digitalmars-d
wrote:
> On Monday, 10 August 2015 at 08:03:47 UTC, lobo wrote:
>>
>> While I agree with you I am curious; where would the compiler place its
>> artefacts and why can't "export" write to the same place?
>
>
> I think that is an implementation detail an
On Mon, 10 Aug 2015 07:50:27 +, Ola Fosheim Grøstad wrote:
> Ugh⦠please don't add more ugly features that has to be ripped out to
> bring the language to a sane state.
hear, hear.
signature.asc
Description: PGP signature
On Mon, 10 Aug 2015 08:33:49 +, Tofu Ninja wrote:
> On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
>> On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
>>>
>>> what will bing D more awesomeness is a ctfe execute.
>>>
>>> enum file = execute("shell scripts");
>>
>> I don't
On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:
> I think you mean dlopen, dlsym and dlclose. Not full file system access
> geez.
and root privs requirement. just to complement it all.
> We are already getting so close to have a full blown CTFE implementation
> that it isn't funny.
On Monday, 10 August 2015 at 08:03:47 UTC, lobo wrote:
While I agree with you I am curious; where would the compiler
place its artefacts and why can't "export" write to the same
place?
I think that is an implementation detail and not a language-issue.
The way I see it files created by export
On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
what will bing D more awesomeness is a ctfe execute.
enum file = execute("shell scripts");
I don't think so...
Its basically as bad, but the execute is frr more useful.
On Monday, 10 August 2015 at 07:50:29 UTC, Ola Fosheim Grøstad
wrote:
Ugh… please don't add more ugly features that has to be ripped
out to bring the language to a sane state.
A compiler should be able to compile all programs on a read
only filesystem. If the language requires a filesystem t
On Monday, 10 August 2015 at 07:05:40 UTC, Iain Buclaw wrote:
On 9 August 2015 at 11:07, JDemler via Digitalmars-d
wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
So, something like:
enum contents = s
On 9 August 2015 at 11:07, JDemler via Digitalmars-d
wrote:
> We can read files at compile-time:
>
> enum file = import(fileName);
>
> But we cannot write to a file or create files at compile time.
>
So, something like:
enum contents = someCTFEStringFunction();
export(fileName, contents);
Iai
On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
wrote:
> On Sunday, 9 August 2015 at 09:07:51 UTC, JDemler wrote:
>>
>> We can read files at compile-time:
>>
>> enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>> Generating code at com
On Sunday, 9 August 2015 at 09:07:51 UTC, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but has
a few flaws.
It isn't debuggable, the gene
On 10/08/2015 9:48 a.m., JDemler wrote:
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
On 10/08/2015 1:57 a.m., cym13 wrote:
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum fi
On 10/08/2015 1:57 p.m., ketmar wrote:
On Sun, 09 Aug 2015 09:07:49 +, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but has a few
On 8/9/15 5:39 PM, JDemler wrote:
The next step is a DIP on which further discussion is based?
I would be willing to provide one.
Great. I assume it's understood it's a difficult undertaking. Looking
forward to more on the topic. -- Andrei
On Monday, 10 August 2015 at 01:57:40 UTC, ketmar wrote:
next will be full filesystem access, 'cause hey, we need
directory listings! and stat()! and unlink()! and wow, how can
we live without http downloader?! and...
this road has no end, and the problem already has a solution:
preprocessing
On Sun, 09 Aug 2015 09:07:49 +, JDemler wrote:
> We can read files at compile-time:
>
>enum file = import(fileName);
>
> But we cannot write to a file or create files at compile time.
>
> Generating code at compile-time and mixing it in is fun but has a few
> flaws.
> It isn't debuggabl
On Sunday, 9 August 2015 at 21:48:13 UTC, JDemler wrote:
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole
wrote:
On 10/08/2015 1:57 a.m., cym13 wrote:
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
[...]
I think this is an in
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
On 10/08/2015 1:57 a.m., cym13 wrote:
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot wri
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but
On Sunday, 9 August 2015 at 14:50:21 UTC, Rikki Cattermole wrote:
Bin2D[1] is my preferred processor. Note, I'm the author.
I'll take a look. Thanks.
On 10/08/2015 2:38 a.m., jmh530 wrote:
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
I'm actually at the point where I believe the addition of string
import was a bad one. No. I prefer preprocessing into a D file first.
It irks me, you have to be pretty careful with them, bu
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
I'm actually at the point where I believe the addition of
string import was a bad one. No. I prefer preprocessing into a
D file first.
It irks me, you have to be pretty careful with them, but at
least a preprocessed file you kn
On 10/08/2015 1:57 a.m., cym13 wrote:
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at c
On 8/9/15 9:57 AM, cym13 wrote:
The moment this is added to D, we will have two complete languages in
one: an interpreted one at compile-time and another at runtime.
Where is the definition of the other one? -- Andrei
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but has a few
flaws.
It isn't debuggable, the generated code cannot be di
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but has a
few flaws.
It isn't debuggable, the generated code cannot be directly
inspected (we have to use p
32 matches
Mail list logo