June 18, 2008 Re: OT: D2 in Descent | ||||
---|---|---|---|---|
| ||||
Posted in reply to Extrawurst | Extrawurst a écrit :
> Ary Borenszweig schrieb:
>> After I finish making Descent support D2, I'll try to make templates and CTFE debuggable (i.e. you put a breakpoint, you right click on a template or a function and select "Debug at compile-time").
>
> You are working on this at the very moment ? Thats great to hear, any idea when its gonna be released ? Thats what i am waiting for all the time ;)
I hope to have it done in about a month or less, I'm trying to port a little bit each day. And then after porting it's about moving the parser stuff up to the core stuff (public AST, signature) and then to the UI stuff (labels for const and invariant, etc.). But it's a race against Walter's releases... See, now after I finish porting to DMD 2.013, I'll have to port to DMD 2.015 :-P
(but that should be much easier than porting from D1 to D2)
It's great to hear there is interest in Descent for D2.
|
June 18, 2008 Re: OT: D2 in Descent | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | On Wed, 18 Jun 2008 15:20:23 +0400, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> Extrawurst a écrit :
>> Ary Borenszweig schrieb:
>>> After I finish making Descent support D2, I'll try to make templates and CTFE debuggable (i.e. you put a breakpoint, you right click on a template or a function and select "Debug at compile-time").
>> You are working on this at the very moment ? Thats great to hear, any idea when its gonna be released ? Thats what i am waiting for all the time ;)
>
> I hope to have it done in about a month or less, I'm trying to port a little bit each day. And then after porting it's about moving the parser stuff up to the core stuff (public AST, signature) and then to the UI stuff (labels for const and invariant, etc.). But it's a race against Walter's releases... See, now after I finish porting to DMD 2.013, I'll have to port to DMD 2.015 :-P
>
> (but that should be much easier than porting from D1 to D2)
>
> It's great to hear there is interest in Descent for D2.
Of course there is!!!
|
June 19, 2008 Re: Debugging CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | Jarrett Billingsley wrote: > "Matthias Walter" <Matthias.Walter@st.ovgu.de> wrote in message news:g38na9$2gs7$1@digitalmars.com... >> Hello, >> >> I have written some compile time executable functions with D 1.0 which work in runtime but hang (and allocate memory without end) at compile-time. Is there a way to debug this further? Can one print stuff out? (Don't know if writefln works at compile-time, as I'm using Tango) Can I somehow get a stack trace of the functions called? >> > > No, no, and no. CTFE support in the current frontend has some rather unworkable disadvantages. For one, it's terribly buggy.You're better off trying to convert it to templates in most cases. I disagree. I've not had much trouble with CTFE. The really, really nice thing about CTFE is that you can write it as a runtime function, and make sure it works before using it a compile time. The problem with CTFE is bugzilla issue #1382 (no memory release for CTFE functions)... For two, CTFE is > interpreting a garbage-collected language but is not itself garbage-collected, meaning that memory-unconscious code evaluated at compile time (i.e. a loop that appends data to the end of a string) will just leak like hell and cause the compiler to easily use up several GB of memory. That might be what's happening to your code. That's very likely. The maximum size of code you can write with CTFE is pretty small. > Or it could be a bug in CTFE. Bugzilla issue #1382 is the killer. One of the most important bugs in bugzilla, I reckon. |
June 19, 2008 Re: Debugging CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | Don Wrote:
> Jarrett Billingsley wrote:
> > "Matthias Walter" <Matthias.Walter@st.ovgu.de> wrote in message news:g38na9$2gs7$1@digitalmars.com...
> >> Hello,
> >>
> >> I have written some compile time executable functions with D 1.0 which work in runtime but hang (and allocate memory without end) at compile-time. Is there a way to debug this further? Can one print stuff out? (Don't know if writefln works at compile-time, as I'm using Tango) Can I somehow get a stack trace of the functions called?
> >>
> >
> > No, no, and no. CTFE support in the current frontend has some rather unworkable disadvantages. For one, it's terribly buggy.You're better off trying to convert it to templates in most cases.
>
> I disagree. I've not had much trouble with CTFE. The really, really nice thing about CTFE is that you can write it as a runtime function, and make sure it works before using it a compile time.
>
> The problem with CTFE is bugzilla issue #1382 (no memory release for CTFE functions)...
>
> For two, CTFE is
> > interpreting a garbage-collected language but is not itself garbage-collected, meaning that memory-unconscious code evaluated at compile time (i.e. a loop that appends data to the end of a string) will just leak like hell and cause the compiler to easily use up several GB of memory. That might be what's happening to your code.
>
> That's very likely. The maximum size of code you can write with CTFE is pretty small.
>
> > Or it could be a bug in CTFE.
>
> Bugzilla issue #1382 is the killer. One of the most important bugs in bugzilla, I reckon.
But in my case, the runtime-function needed some milliseconds, allocating not more than 1 MB data. the compiler then allocated 1 GB until I killed the process. I guess, there might be some other bugs. Unfortunatly, I was unable to make proofing code more easy to get the cause of the bug.
Anyway, I now don't use functions for much stuff, but try to achieve my needs with templates, although template programming is sometimes a bit messier. But it works and debugging via pragmas is like printf-debugging in C and thus just a matter of time :) Training more functional thinking is also helpful for other things...
best regards and thanks for the tips
Matthias
|
June 19, 2008 Re: Debugging CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthias Walter | Matthias Walter wrote: > Don Wrote: > >> Jarrett Billingsley wrote: >>> "Matthias Walter" <Matthias.Walter@st.ovgu.de> wrote in message news:g38na9$2gs7$1@digitalmars.com... >>>> Hello, >>>> >>>> I have written some compile time executable functions with D 1.0 which work in runtime but hang (and allocate memory without end) at compile-time. Is there a way to debug this further? Can one print stuff out? (Don't know if writefln works at compile-time, as I'm using Tango) Can I somehow get a stack trace of the functions called? >>>> >>> No, no, and no. CTFE support in the current frontend has some rather unworkable disadvantages. For one, it's terribly buggy.You're better off trying to convert it to templates in most cases. >> I disagree. I've not had much trouble with CTFE. The really, really nice thing about CTFE is that you can write it as a runtime function, and make sure it works before using it a compile time. >> >> The problem with CTFE is bugzilla issue #1382 (no memory release for CTFE functions)... >> >> For two, CTFE is >>> interpreting a garbage-collected language but is not itself garbage-collected, meaning that memory-unconscious code evaluated at compile time (i.e. a loop that appends data to the end of a string) will just leak like hell and cause the compiler to easily use up several GB of memory. That might be what's happening to your code. >> That's very likely. The maximum size of code you can write with CTFE is pretty small. >> >>> Or it could be a bug in CTFE. >> Bugzilla issue #1382 is the killer. One of the most important bugs in bugzilla, I reckon. > > But in my case, the runtime-function needed some milliseconds, allocating not more than 1 MB data. the compiler then allocated 1 GB until I killed the process. I guess, there might be some other bugs. Unfortunatly, I was unable to make proofing code more easy to get the cause of the bug. That'll be issue #1382. You can only do a few thousand memory allocations (including ~) before CTFE dies. Basically, you can use CTFE for very small tasks, and for library development. Because of #1382, you can't use it large-scale stuff yet. > > Anyway, I now don't use functions for much stuff, but try to achieve my needs with templates, although template programming is sometimes a bit messier. But it works and debugging via pragmas is like printf-debugging in C and thus just a matter of time :) Training more functional thinking is also helpful for other things... > > best regards and thanks for the tips > Matthias |
June 19, 2008 Re: Debugging CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | On Thu, 19 Jun 2008 14:11:55 +0400, Don <nospam@nospam.com.au> wrote:
> Matthias Walter wrote:
>> Don Wrote:
>>
>>> Jarrett Billingsley wrote:
>>>> "Matthias Walter" <Matthias.Walter@st.ovgu.de> wrote in message news:g38na9$2gs7$1@digitalmars.com...
>>>>> Hello,
>>>>>
>>>>> I have written some compile time executable functions with D 1.0 which work in runtime but hang (and allocate memory without end) at compile-time. Is there a way to debug this further? Can one print stuff out? (Don't know if writefln works at compile-time, as I'm using Tango) Can I somehow get a stack trace of the functions called?
>>>>>
>>>> No, no, and no. CTFE support in the current frontend has some rather unworkable disadvantages. For one, it's terribly buggy.You're better off trying to convert it to templates in most cases.
>>> I disagree. I've not had much trouble with CTFE. The really, really nice thing about CTFE is that you can write it as a runtime function, and make sure it works before using it a compile time.
>>>
>>> The problem with CTFE is bugzilla issue #1382 (no memory release for CTFE functions)...
>>>
>>> For two, CTFE is
>>>> interpreting a garbage-collected language but is not itself garbage-collected, meaning that memory-unconscious code evaluated at compile time (i.e. a loop that appends data to the end of a string) will just leak like hell and cause the compiler to easily use up several GB of memory. That might be what's happening to your code.
>>> That's very likely. The maximum size of code you can write with CTFE is pretty small.
>>>
>>>> Or it could be a bug in CTFE.
>>> Bugzilla issue #1382 is the killer. One of the most important bugs in bugzilla, I reckon.
>> But in my case, the runtime-function needed some milliseconds, allocating not more than 1 MB data. the compiler then allocated 1 GB until I killed the process. I guess, there might be some other bugs. Unfortunatly, I was unable to make proofing code more easy to get the cause of the bug.
>
> That'll be issue #1382. You can only do a few thousand memory allocations (including ~) before CTFE dies.
>
> Basically, you can use CTFE for very small tasks, and for library development. Because of #1382, you can't use it large-scale stuff yet.
>
>> Anyway, I now don't use functions for much stuff, but try to achieve my needs with templates, although template programming is sometimes a bit messier. But it works and debugging via pragmas is like printf-debugging in C and thus just a matter of time :) Training more functional thinking is also helpful for other things...
>> best regards and thanks for the tips
>> Matthias
IIRC, there is a Hans Boehm garbage Collector available for MDC, could Walter integrate it into DMD and solve the problem? :)
|
Copyright © 1999-2021 by the D Language Foundation