Dnia 21-08-2010 o 05:36:28 SK napisał(a):
Then to make this more concrete, what if D had an option to suspend
compilation after the front-end finished? The resulting executable
contains the abstract RTL blobs and the compiler backend, which
finishes the job for the specific platform on which t
Dnia 26-08-2010 o 05:59:19 Andrei Alexandrescu
napisał(a):
At my workplace we're using Google's logging library glog
(http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
more I use it, the more I like it. It's simple, to the point, and
effective.
I was thinking it would
Dnia 27-08-2010 o 22:03:46 Stanislav Blinov
napisał(a):
I can tell that this wasn't true even 15 years from here. Books,
interviews, movies, games - all had solid and nice translations,
pleasant to read an hear. But something has changed. And not for the
best.
But during the time when '
Dnia 29-08-2010 o 06:57:17 Brad Roberts napisał(a):
On 8/28/2010 6:29 PM, dsimcha wrote:
An issue that comes up very frequently when trying to use const, pure or
nothrow in generic code is lack of knowledge of whether the functions
you're
calling are const/pure/nothrow. For example:
T abs
Dnia 30-08-2010 o 21:10:10 Tomek Sowiński napisał(a):
How about reduce!fun(range)? It's pure/nothrow when fun is pure/nothrow.
Plenty of std.algorithm would benefit.
Eh, nevermind. popFront() must mutate the range so it can't be pure. Need
to get some sleep...
Dnia 30-08-2010 o 21:16:15 Tomek Sowiński napisał(a):
Dnia 30-08-2010 o 21:10:10 Tomek Sowiński napisał(a):
How about reduce!fun(range)? It's pure/nothrow when fun is
pure/nothrow. Plenty of std.algorithm would benefit.
Eh, nevermind. popFront() must mutate the range so it can'
Dnia 03-09-2010 o 23:37:18 John Demme napisał(a):
(Yes, all of those exponents are 4, not 2. This is actually a 4
dimensional
matrix, but for the purpose of most parts of the computation, I can
treat it
like a typical 2-dim matrix. Not relevant, I suppose, but perhaps
interesting.)
Very
Dnia 04-09-2010 o 08:03:12 John Demme napisał(a):
As for the graphs, I essentially take two input graphs, represented in
adjacency matrix form (two 2-d matrices of size n^2 each, assuming equal
sized graphs). Then, I compute the Kronecker Tensor Graph Product[2],
which
creates a matrix of s
Dnia 08-09-2010 o 15:58:31 BCS napisał(a):
Can't you compute the Kronecker product lazily? E.g. a proxy object
that computes a value in an overloaded opIndex. Even if your
algorithms inspect (compute) the same value several times, you may
still win -- the bottleneck these days is memory acce
Dnia 08-09-2010 o 15:55:30 Andrei Alexandrescu
napisał(a):
I just added SortedRange as discussed a while ago in this newsgroup. I
think it turned out pretty neat. Generally the range abstraction is
turning out to be very solid.
To get a SortedRange object for a given range r either call
Dnia 08-09-2010 o 23:12:55 Stanislav Blinov
napisał(a):
I was wondering about it for some time:
void foreach_loop(int arr[100])
{
foreach(i,a; arr)
{
auto e = a;
}
}
void for_loop(int arr[100])
{
for (int i = 0; i < 100; ++i)
{
auto e = arr[i];
Tomek Sowiński napisał:
> 2. Could makeIndex() also return SortedRange? The predicate should be
> morphed of course to account for dereferencing.
Or better: SortedRange's underlying range should account for dereferencing and
leave the predicate intact.
Tomek
Michel Fortin napisał:
> The interesting thing with this change is that you can now call
> mutators functions on the local variables inside the pure function,
> because those can be made pure. You can't even iterate over a range
> inside a pure function without this!
>
> pure int test() {
> int r
dsimcha napisał:
> 1. The documentation that says that the parameters need to be convertible
> to immutable is outdated. This was changed a while ago to only requiring
> const.
Good to know. Yet, I wonder why such changes are not discussed on this NG and
at the very
least announced in the cha
Don napisał:
> You're operating with a different definition. There are actually three
> levels. For extra clarity, let's split strongly-pure into two:
>
> immutably pure == all parameters are immutable
> const pure == all parameters are const
> weakly pure == no access to globals
>
> The interes
Gary Whatmore napisał:
> We could use these proposals as a base for D 2.5 or D 3.0. Now that a
> better purity/constness system seems to solve problems more easily, D 2.0
> seems too limited for modern systems programming. Is it finally time to
> put D 1.0 to rest, D 2.0 in maintenance mode, and c
Michel Fortin napisał:
>> It's because popFront() can't be made pure. It could be if there was
>> @tail immutable in the
>> language -- pure functions would mark their arguments with @tail
>> immutable instead of
>> immutable. That allows popFront() to advance the range.
>
> I know popFront() can
Tomek Sowiński napisał:
> So in the "three levels of purity" nomenclature, tail(const|immutable)
> would popularize the stronger two. E.g. popFront() could be immutably pure
> if the range in on an immutable collection and const-pure if it's on any
> collection.
Ehm,
Tomek Sowiński napisał:
>> Note that this is possible only because immutable and const are
>> transitive. It wouldn't be possible with head-const, or logical const.
>
> But it would be possible with tail const. Quite a few functions could be
> made immutably pure if it
I've been reading about caching mechanisms in today's processors -- amazing in
their
intricacy.
It made me wonder, is there a way to exclude immutable regions of memory from a
cache
coherence mechanism? I mean, let the processor know: no invalidation for cache
lines from
immutable memory.
And
Gareth Charnock napisał:
> I've attempted this in the past, however, each time I manage to work up
> renewed enthusiasm I keep running into compiler bugs that put me off. My
> current feeling is I should sit back at wait for the language to mature
> a little.
Welcome to the club:) I'm writing mat
I remember using defineEnum a few times. From user perspective you have enum
names as
strings that forms a nasty mixin, not to mention you can't Ddoc single enum
values. It felt like
stone age. Then I took a look at how it's implemented and saw a bunch of
unreadable
templates glueing together
bearophile napisał:
>> I remember using defineEnum a few times.
>
> Isn't it deprecated now?
Ah.. it is, got an old release.
Still, do you want my stuff?
--
Tomek
Tomek Sowiński napisał:
> enum Eh { Ah, Oh, Uh }// plain vanilla enum
> mixin EnumUtils!Eh; // that's all you need, magic happens here
Actually, you don't even need the mixin, just 2 functions...
--
Tomek
Andrei Alexandrescu napisał:
> That's a good contribution, but I just deprecated enumToString in a
> recent commit because D's current introspection abilities made it easy
> to define parse and to!string to manipulate enum names.
>
> I'll be looking forward to other goodies!
Thanks, I just saw s
Walter Bright napisał:
> If expr represents a tuple, we (Andrei and I) were thinking about the
> syntax:
>
> auto (a, b, c, d) = expr;
>
> being equivalent to:
>
> auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
Typo? If not, what is 'd'?
Either way, I'd like mismatc
Andrei Alexandrescu napisał:
> On the client side the syntax is very light. The definition of the
> function would need to specify the type name:
>
> Tuple!(int, "foo", string, "bar") fun(int) {
> ...
> }
Blue sky idea -- anonymous structs:
struct { int foo; string bar; } fun(int) {
...
}
They
Simen kjaeraas napisał:
> retard wrote:
>> I guess the other places of confusion
>> are interaction with built-in statements and other features, e.g.
>>
>> auto foo = (1,2,3);
>>
>> auto bar = [foo];
>>
>> Should there be some way to construct a [1,2,3] array from the tuple or
>> should the only
bearophile napisał:
> Another solution is to support the "in" operator for dynamic arrays too,
> and define a new attribute, like @complexity(), plus an Enum that allows
> to specify the worst case complexity. So associative arrays are annotated
> with @complexity(O.linear), while the function tha
Daniel Gibson napisał:
> 2010/10/8 Tomek Sowiński :
>> bearophile napisał:
>>
>>> Another solution is to support the "in" operator for dynamic arrays too,
>>> and define a new attribute, like @complexity(), plus an Enum that allows
>>> to spec
Simen kjaeraas napisał:
> Tomek Sowiński wrote:
>
>> __traits(getAttribute, opIn, @complexity).bigOh == O.constant
>
> How does this test for things like N log M?
>
> __traits(getAttribute, opIn, @complexity).bigOh == tuple( O.linear,
> O.logarithmic )
Or:
Tomek Sowiński napisał:
> Simen kjaeraas napisał:
>
>> Tomek Sowiński wrote:
>>
>>> __traits(getAttribute, opIn, @complexity).bigOh == O.constant
>>
>> How does this test for things like N log M?
>>
>> __traits(getAttribute, opIn, @com
Simen kjaeraas napisał:
> Tomek Sowiński wrote:
>> Even if the attribute properties could see the arguments, how to deal
>> with things like
>> lhs.length + rhs.length? It has to be inspectable at compile-time. One
>> idea is to store the
>> expression's ab
I've been having fun with ranges lately. While nesting computing ranges I
noticed only the
outermost range's cache is necessary; there's no way of accessing front() of
ranges deeper
in the expression twice because they are sealed by the outermost range. Example:
map!"a._0 + a._1"(// caches
bearophile napisał:
> The ghost fields may be used to store partial computations useful to reduce
> the work done
by the class invariant.
You can do:
class C {
version(unittest) int temp;
invariant() {
// use temp
}
}
Or am I missing something?
--
Tomek
Pelle napisał:
> On 10/09/2010 09:38 PM, Tomek Sowiński wrote:
>> I've been having fun with ranges lately. While nesting computing ranges I
>> noticed only the outermost range's cache is necessary; there's no way of
>> accessing front() of ranges deeper in the
bearophile napisał:
> Tomek S.:
>
>> You can do:
>>
>> class C {
>> version(unittest) int temp;
>> invariant() {
>> // use temp
>> }
>> }
>>
>> Or am I missing something?
>
> D2 has several ways to perform conditional compilation, so you may
> implement hand-made ghost fields using a
Peter Alexander napisał:
> On 9/10/10 8:58 PM, Pelle wrote:
>> How about never having caches and if you need them, you can get a
>> cached(map(..etc..))?
>>
>> I do not understand where the notion that ranges should have caches come
>> from. It destroys the possibility for using const and complica
pragma(msg, "blabla")
bug or feature?
--
Tomek
Simen kjaeraas napisał:
> Tomek Sowiński wrote:
>
>> pragma(msg, "blabla")
>>
>> bug or feature?
>
> Feature. http://www.digitalmars.com/d/2.0/pragma.html:
>
> "Pragmas can be used by themselves terminated with a ';', they can
>
Currently the contents of Stride depend on from which end we look at it:
auto m = [1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4]; // 3 rows, 4 columns
auto col = stride(m, 4);
assert(equal(col, [1, 1, 1]));
assert(equal(retro(col), [4, 4, 4]));
Is the quantum behavior intended?
--
Tomek
Peter Alexander napisał:
> On 10/10/10 7:34 PM, Tomek Sowiński wrote:
>> Currently the contents of Stride depend on from which end we look at it:
>>
>> auto m = [1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4]; // 3 rows, 4 columns
>> auto col = stride(m, 4);
>> assert(equal(
Christopher Bergqvist napisał:
> Hi,
>
> Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
> out to me was the special behavior of assert(false). Consider the
> following program compiled with "-release".
>
> void main()
> {
> int a = 0;
> assert(a);
> }
>
> That
Andrei Alexandrescu napisał:
> On 10/10/10 13:34 CDT, Tomek Sowiński wrote:
>> Currently the contents of Stride depend on from which end we look at it:
>>
>> auto m = [1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4]; // 3 rows, 4 columns
>> auto col = stride(m, 4);
>> assert(
Philippe Sigaud napisał:
> As you can see, an "open or closed for both ends" policy could be
> interesting to add. In the previous example, is 1.0 a correct value?
It can be handled as in std.random: Bounded!(T, min, max, string bounds =
"[)"). But with "[]"
as default.
--
Tomek
Simen kjaeraas napisał:
> Peter Alexander wrote:
>
>> In short, when UFC is working on all types, will this be possible:
>>
>> Foo opBinary(string op)(Foo a, Foo b)
>> {
>> return ...;
>> }
>>
>> Foo x, y;
>> Foo z = x + y;
>>
>> My reasoning here is that x + y is supposedly sugar for
>> x.
It may sound ridiculous but this is what came to me in a dream last night: why
exactly does
Bounded have to express an interval? Forget intervals for a minute:
struct Bounded(alias Pred, T);
where Pred is a unary callable returning bool (same as in e.g. filter()).
This opens a host of possibil
Jason House napisał:
> Tomek Sowiński Wrote:
>
>> It may sound ridiculous but this is what came to me in a dream last
>> night: why exactly does Bounded have to express an interval? Forget
>> intervals for a minute:
>>
>> struct Bounded(alias Pred, T);
&
Philippe Sigaud napisał:
> 2010/10/13 Tomek Sowiński :
>> It may sound ridiculous but this is what came to me in a dream last
>> night: why exactly does Bounded have to express an interval? Forget
>> intervals for a minute:
>>
>> struct Bounded(alias Pred, T);
>
bearophile napisał:
> The lazy attribute may be deprecated, but I don't remember a final word on
> this.
Me neither.
> I don't know what's meant to replace them
AFAIR, implicit conversion of expressions to parameterless delegates.
--
Tomek
Lutger napisał:
> for reference: http://d.puremagic.com/issues/show_bug.cgi?id=2630
>
> Tomasz Sowiński raises the point that each unittest should test the
> preceding declaration. I think that's a little inflexible, instead the
> following could work:
>
> - unittests marked with 'ditto' will do
Andrei Alexandrescu napisał:
> I'm happy with a much more modest change that doesn't add anything to
> the syntax. Simply prefixing a unittest with a documentation comment
> makes it an example:
>
> /**
> The example below illustrates how D gets a basic arithmetic operation
> totally right.
> */
Andrei Alexandrescu napisał:
>> Let's drill down on this:
>>
>> /// The ultimate foo.
>> void foo();
>>
>> /// The test.
>> unittest { ... }
>>
>> What would be the outline of the above snippet?
>
> From a ddoc perspective this should be the same as:
>
> /** The ultimate foo.
>
> The test.
> -
Tomek Sowiński napisał:
> As I mentioned in bugzilla, it opens the opportunity to kill the unittest
> naming problem with the same stone:
>
> void foo();
>
> unittest(owner) {
> Log.info("Testing " ~ owner.stringof ~ "...");
> scope(exit) Log.i
Andrei Alexandrescu napisał:
> On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:
>> I suggest wrapping a char[] or wchar[] (of all constancies) with a
>> special range that imposes the restrictions.
>
> I did so. It was called byDchar and it would accept a string type. It
> sucked.
Why it suck
Funny thing:
void foo(T)(t); // typeless argument
If you don't instantiate the template, it actually compiles. Bug?
--
Tomek
What's the status quo on member functions defined outside the type?
import std.array;
void main() {
int[] arr = [1,2];
// compiles, should it?
int a = __traits(getMember, arr, "front");
// compiles (called popFront), should it?
__traits(getMember, arr, "popFront");
Tomek Sowiński napisał:
> What's the status quo on member functions defined outside the type?
>
> import std.array;
>
> void main() {
> int[] arr = [1,2];
>
> // compiles, should it?
> int a = __traits(getMember, arr, "front");
>
&
lurker napisał:
>> class C
>> {
>>int draw(){ return 10; }
>> }
>> interface Drawable
>> {
>>long draw();
>> }
>> ...
>> auto c = new C;
>> auto d = duck!Drawable(c);
>
> Object c = new C;
> auto d = duck!Drawable(c); // awes
>
> does this work? After all, c is a C:
I'd say no. c is an Object,
Initializing immutable structures is a source of constant grief. Anything
non-trivial requires instancing a mutable structure, initializing it, and
then either casting to immutable (it's up to you to ensure no alias
leaked) or, not to violate the type system, duplicate the whole.
Yet, if th
Dnia 18-10-2010 o 20:53:15 Steven Schveighoffer
napisał(a):
On Mon, 18 Oct 2010 14:31:26 -0400, Tomek Sowiński wrote:
Initializing immutable structures is a source of constant grief.
Anything non-trivial requires instancing a mutable structure,
initializing it, and then either casting
Dnia 18-10-2010 o 18:15:47 F. Almeida
napisał(a):
The version() { ... } blocks would greatly improve from support of
boolean operators, which would make code much more readable.
Let us assume, for example, that I have several version identifiers
(VERSION1, VERSION2, VERSION3, VERSION4, etc.)
Dnia 18-10-2010 o 21:38:07 Steven Schveighoffer
napisał(a):
On Mon, 18 Oct 2010 15:20:39 -0400, Tomek Sowiński wrote:
[snip]
Anyway, if these immutable ctors are defined inside the type, then the
library writer may not provide a ctor suitable for your case (very
possible).
Yes true
Dnia 18-10-2010 o 22:39:32 Lars T. Kyllingstad
napisał(a):
version(VERSION1 || VERSION3)
{
// ...
}
You can have it now:
template isVersion(string ver) {
enum bool isVersion = !is(typeof({
mixin("version(" ~ ver ~") static assert(0);");
}));
}
static if (isVersion"VE
Dnia 18-10-2010 o 23:05:27 Don napisał(a):
Michel Fortin wrote:
On 2010-10-18 14:31:26 -0400, Tomek Sowiński said:
Call me crazy, but I think it is safe to implicitly convert a pure
function's return value to immutable. What you think?
Well, it depends on the arguments of the
Dnia 08-12-2009 o 19:46:02 Michal Minich
napisał(a):
Discussion with Tomek Sowiński and Steven Schveighoffer moved from
digitalmars.D.learn:
Currently it is impossible to have static member function in struct or
class; this does not compile:
struct S2
{
static void foo () immutable
Dnia 08-12-2009 o 20:09:10 Tomek Sowiński napisał(a):
I think immutable static member functions don't make sense and rightly
so. On functions immutable is about "this" and there's no "this".
Currently everything inside an immutable struct/class is tagged
Dnia 08-12-2009 o 23:17:55 hehe45 napisał(a):
In c++ it is valid syntax to have trailing commas at the and of enum
definitions:
enum {a, b, c, };
This would be a useful addition to D too.
Please no. I've done some C++ but the "need semicolon after brace?" is
always something I need to thi
This rightfully doesn't compile:
class A {
A opAssign(A a); // Error: function test.A.opAssign identity
assignment operator overload is illegal
}
But when instead of A you assign const(A), shared(A) or
any_type_constructor(A) it compiles. Is this intended?
Tomek
I was playing with D's function pointers and immutability and ran into
some trouble. It's probably because function pointers are treated just
like data pointers when it comes to immutability. To mend this, function
pointers should be treated as values. It may sound odd but makes sense --
yo
Dnia 20-03-2010 o 14:34:31 bearophile
napisał(a):
In my opinion, if you write a large amount of code on the base of a
feature that's not fully developed yet then you risk wasting some of
your time.
You're right. That's why I was asking. Thx 4 info.
Will the multidimensional length operator make it into D2? If so, would
the syntax be any different from
http://d.puremagic.com/issues/show_bug.cgi?id=3474 ? I'd like to gear my
matrix code to match the syntax not to change too much for the new DMD
release.
Tomek
Dnia 08-04-2010 o 01:01:03 bearophile
napisał(a):
Adding D1 with LDC to Google code Jam accepted languages?
It starts now, but there is time to add it still, I think.
I recall the Tango people wanted to put D1 to Google Summer of Code and
failed several times. Is code jam sth way differen
Dnia 05-05-2010 o 03:24:50 bearophile
napisał(a):
[snip]
2) Names for unittests. Giving names to things in the universe is a
first essential step if you want to try to understand some part of it.
The compiler makes sure in each module two unittest tests don't share
the same name. An exam
Dnia 10-05-2010 o 19:52:23 Walter Bright
napisał(a):
http://programming.dojo.net.nz/welcome/index
Anyone care to write up a D page and email it to him?
I gave it a whirl, will see what his response will be.
negerns wrote:
> Also, I have introduced a unjoin() function as a helper function. It
> splits a string into an array of lines using the specified array of
> characters as delimiters. I am not sure if there is already an
existing
> function that does the same but I could not find it. For lack of
201 - 276 of 276 matches
Mail list logo
