On Fri, Apr 22, 2011 at 12:34 AM, dennis luehring wrote:
> On 17.04.2011 22:45, Andrew Wiley wrote:
>
>> On Sun, Apr 17, 2011 at 3:30 PM, dennis luehring
>> wrote:
>>
>>> On 11.04.2011 23:27, bearophile wrote:
>>>
From what I am seeing, in a D2 program if I have many (tens or more)
>>
On 17.04.2011 22:45, Andrew Wiley wrote:
On Sun, Apr 17, 2011 at 3:30 PM, dennis luehring wrote:
On 11.04.2011 23:27, bearophile wrote:
From what I am seeing, in a D2 program if I have many (tens or more) pure
functions that call to each other, and I want to add (or activate) a
printf/write
On Sun, Apr 17, 2011 at 3:30 PM, dennis luehring wrote:
> On 11.04.2011 23:27, bearophile wrote:
>>
>> From what I am seeing, in a D2 program if I have many (tens or more) pure
>> functions that call to each other, and I want to add (or activate) a
>> printf/writeln inside one (or few) of those f
On 11.04.2011 23:27, bearophile wrote:
From what I am seeing, in a D2 program if I have many (tens or more) pure functions that
call to each other, and I want to add (or activate) a printf/writeln inside one (or few)
of those functions to debug it, I may need to temporarily comment out the
"p
On 4/16/2011 1:21 PM, bearophile wrote:
Walter:
No, it is not. You seem to be thinking that purity is just a bug finding
or optimization feature. That is not so. Purity is a guarantee that can be
relied upon for a program's behavior. Breaking purity breaks that
guarantee.
(Think multithreaded
Walter:
> No, it is not. You seem to be thinking that purity is just a bug finding or
> optimization feature. That is not so. Purity is a guarantee that can be relied
> upon for a program's behavior. Breaking purity breaks that guarantee.
>
> (Think multithreaded programs, for example.)
I was no
On 4/16/2011 11:52 AM, bearophile wrote:
Walter:
Saying it is a safe way to break purity assumes that there was no purpose
to the purity. There is no guaranteed safe way to break purity, with or
without a compiler switch.
The compiler switch I am talking about doesn't break purity. Its purpos
Walter:
> Saying it is a safe way to break purity assumes that there was no purpose to
> the purity.
> There is no guaranteed safe way to break purity, with or without a compiler
> switch.
The compiler switch I am talking about doesn't break purity. Its purpose is
similar to removing the "pure
On 4/16/2011 6:41 AM, bearophile wrote:
Yes, it allows one to break the purity of the function. The alternative is
to use casts (which also breaks the purity) or another compiler switch
(which also breaks the purity).
A compiler switch to disable purity doesn't break purity. It just turns all
p
Walter:
> Yes, it allows one to break the purity of the function. The alternative is to
> use casts (which also breaks the purity) or another compiler switch (which
> also
> breaks the purity).
A compiler switch to disable purity doesn't break purity. It just turns all
pure functions inside t
On 4/15/2011 7:06 PM, bearophile wrote:
There is something I don't understand. If your last change allows code like
this, isn't it breaking the safety of pure functions in debug mode? Do you
think this loss of safety is not important?
Yes, it allows one to break the purity of the function. The
Walter:
> On the contrary, I think it is the right solution. After all, the reason
> people
> want to put impure code in a pure function is for debugging. By putting it
> under
> the debug conditional, any logging or printing code can be there without
> needing
> the compiler to be aware of wha
On 4/15/2011 3:00 PM, bearophile wrote:
I presume this front end change is not following my suggestion (of adding a
switch to disable purity), but adds a dirty hack that allows impure debug
code inside pure functions. If this is true, then let's now find the bad side
effects of this change.
On
> > Related news:
> > https://github.com/D-Programming-Language/dmd/commit/ed8068f5036f88fff1603d98ebe96bb6659bceed
I have forgotten to add something: thank you Walter. Sorry for criticizing
before actually trying out the change.
Bye,
bearophile
David Nadlinger:
> Related news:
> https://github.com/D-Programming-Language/dmd/commit/ed8068f5036f88fff1603d98ebe96bb6659bceed
It's a bit disconcerting to see how important things I'm asking and arguing for
for three years or more gets ignored, while this that I have barely noted gets
worked
On 4/11/11 11:27 PM, bearophile wrote:
From what I am seeing, in a D2 program if I have many (tens or more) pure functions that
call to each other, and I want to add (or activate) a printf/writeln inside one (or few)
of those functions to debug it, I may need to temporarily comment out the
"p
On 04/12/2011 09:54 PM, Steven Schveighoffer wrote:
On Tue, 12 Apr 2011 15:48:33 -0400, bearophile wrote:
Walter:
pure void foo()
{
debug writeln("in foo()");
}
Simple and effective.
Very simple designs are sometimes the mark of the genius. But isn't your idea
able to lead to debug code t
On Tue, 12 Apr 2011 16:11:41 -0400, bearophile
wrote:
Steven Schveighoffer:
Well, yes. So? How does the compiler establish rules to separate "safe
debug printing" from "all code that isn't pure"? If you did that, how
does the compiler know it's safe? The only way I can think of is to
Steven Schveighoffer:
> Well, yes. So? How does the compiler establish rules to separate "safe
> debug printing" from "all code that isn't pure"? If you did that, how
> does the compiler know it's safe? The only way I can think of is to treat
> writeln specially, which doesn't sound like
On Tue, 12 Apr 2011 15:48:33 -0400, bearophile
wrote:
Walter:
pure void foo()
{
debug writeln("in foo()");
}
Simple and effective.
Very simple designs are sometimes the mark of the genius. But isn't your
idea able to lead to debug code that's more buggy than the nondebug
code, i
Walter:
> pure void foo()
> {
> debug writeln("in foo()");
> }
>
> Simple and effective.
Very simple designs are sometimes the mark of the genius. But isn't your idea
able to lead to debug code that's more buggy than the nondebug code, if some
side effect (like modifying a global) is used
On Tue, 12 Apr 2011 13:18:30 -0400, Walter Bright
wrote:
On 4/12/2011 8:03 AM, Steven Schveighoffer wrote:
use C linkage, you can do whatever you want. It's how druntime
accomplishes a
lot of stuff.
For example:
puredebug.d:
import std.stdio;
extern(C) void pureprint(string[] values...
On 4/12/2011 8:03 AM, Steven Schveighoffer wrote:
use C linkage, you can do whatever you want. It's how druntime accomplishes a
lot of stuff.
For example:
puredebug.d:
import std.stdio;
extern(C) void pureprint(string[] values...)
{
write("[pure debug] ");
foreach(value; values)
write(value);
David Gileadi:
> I'm not a day-to-day D programmer but it's seemed to me for a while that
> having a print/log function that would work in normal code, in pure code
> and in CTFE would be extremely useful.
Vote, if you like :-) This asks for something minimal, a way to print strings
at compile
On 4/12/11 1:12 AM, spir wrote:
On 04/12/2011 04:05 AM, Nick Sabalausky wrote:
As more and more D2 functions become pure in my code and in Phobos,
> something like a -disablepure compiler switch (and printf/writeln
inside
> debug{}) may allow more handy debugging with prints (if the purity
is we
On Mon, 11 Apr 2011 17:27:41 -0400, bearophile
wrote:
From what I am seeing, in a D2 program if I have many (tens or more)
pure functions that call to each other, and I want to add (or activate)
a printf/writeln inside one (or few) of those functions to debug it, I
may need to temporaril
On 04/12/2011 04:05 AM, Nick Sabalausky wrote:
As more and more D2 functions become pure in my code and in Phobos,
> something like a -disablepure compiler switch (and printf/writeln inside
> debug{}) may allow more handy debugging with prints (if the purity is well
> managed by the compiler t
"bearophile" wrote in message
news:invrod$3182$1...@digitalmars.com...
> From what I am seeing, in a D2 program if I have many (tens or more) pure
> functions that call to each other, and I want to add (or activate) a
> printf/writeln inside one (or few) of those functions to debug it, I may
>
bearophile:
> To avoid some possible troubles I suggest to keep puts pure only in debug
> builds:
Definitely. It is a filthy hack, after all!
dsimcha:
> Interesting (and practical) idea.
It's one example of a third class of compiler messages that I have named
compiler tips (beside warnings and errors).
> The only problems I see are templated
> functions (for which pure, nothrow, etc. are so broken it's not even
> funny) and findin
Adam D. Ruppe:
> Yes. In fact, I view it as better than always seeing it twenty
> times because it reflects what's actually going on.
To avoid some possible troubles I suggest to keep puts pure only in debug
builds:
debug
extern(C) pure void puts(const char*);
else
extern(C) void puts(c
On 4/11/2011 6:23 PM, bearophile wrote:
One extra note: in GCC 4.6 there are compiler switches like
-Wsuggest-attribute=const that generate suggestions for functions that are
implicitly const (pure) but don't have a const attribute yet.
Bye,
bearophile
Interesting (and practical) idea. The
One extra note: in GCC 4.6 there are compiler switches like
-Wsuggest-attribute=const that generate suggestions for functions that are
implicitly const (pure) but don't have a const attribute yet.
Bye,
bearophile
bearophile wrote:
> Is this an acceptable debug printing for you?
Yes. In fact, I view it as better than always seeing it twenty
times because it reflects what's actually going on.
You already know what it's supposed to do, and if it did what it
was supposed to do, you wouldn't be debugging it.
On 04/11/2011 11:27 PM, bearophile wrote:
From what I am seeing, in a D2 program if I have many (tens or more) pure functions that
call to each other, and I want to add (or activate) a printf/writeln inside one (or few)
of those functions to debug it, I may need to temporarily comment out the
Adam D. Ruppe:
> I wonder if it would be a good idea to have logging or debug prints
> that simply lie about being pure so you can use them there.
If the compiler sees a function as pure, the debug prints may or may not appear
according to how much pure-related optimizations the compiler is doin
I wonder if it would be a good idea to have logging or debug prints
that simply lie about being pure so you can use them there.
Something like this:
==
extern(C) pure void puts(const char*);
pure void hello() {
puts("hello world from pure land\n"); // compiles
}
==
>From what I am seeing, in a D2 program if I have many (tens or more) pure
>functions that call to each other, and I want to add (or activate) a
>printf/writeln inside one (or few) of those functions to debug it, I may need
>to temporarily comment out the "pure" attribute of many functions (beca
38 matches
Mail list logo
