Re: Dynamic loading, D all the way (dmd 64bit 2.060/Ubuntu 64bit 12.04/x86_64)
On 2012-08-24 00:26, Philip Daniels wrote:
But wouldn't that require you to link everything together at, err,
compile time?
What I'm getting at is, would it be possible to port a DI/IoC tool such
as StructureMap (http://docs.structuremap.net/index.html) or Spring to
D? This can handle tasks such as creating dynamic plug-in architectures.
For example, given SomeBigApp.exe (not written by me) which looks in
standard folders for components implementing a particular interface, I
can just drop my code in that folder and have it loaded at runtime. I
could even drop it in there after the program starts running. I know how
to achieve this in the .Net world, just wondered if it was possible in D.
Sure, you just need to come up with a couple of conventions. Say for
example that you have your application in a folder structure like this:
app
|--plugins
|---fully.qualified.class.name.so/dll/dylib
The host application inspects the "plugins" folder at runtime grabbing
all the names of the dynamic libraries. The convention is that in the
dynamic library there will be a class with the same fully qualified name
as the name of the dynamic library its located in.
The next convention is that the class must implement an interface, which
the host application provides. The class also needs to have a default
constructor (there are ways around that).
Then the host application would do something like this:
interface Plugin
{
void initialize ();
// ... other needed methods
}
auto plugin = cast(Plugin) Object.factory("fully.qualified.class.name");
plugin.initialize();
The magic behind this is the "Object.factory" method:
http://dlang.org/phobos/object.html#factory
--
/Jacob Carlborg
Re: More on vectorized comparisons
On 24/08/12 00:13, bearophile wrote: Sean Cavanaugh: Well, right now the binary operators == != >= <= > and < are required to return bool instead of allowing a user defined type, which prevents a lot of the sugar you would want to make the code nice to write. The hypothetical D sugar I was looking for is this, where 'a', 'b' and 'c' are normal dynamic arrays of doubles (not of float[4] of double[2]) (currently this code is a syntax error): if (a[] > 0) b[] += c[]; The front-end is able to implement those two lines of code as it likes, like seeing those normal arrays as arrays of double[2] (or double[4] on more modern CPUs) and put there all the needed intrinsics or assembly needed to implement that semantics. So what's the problem the > operator causes in this code? Bye, bearophile It's just syntax sugar for a very obscure operation, and it's somewhat ambiguous -- is it allowed to use short-circuit evaluation? Mathematically, it doesn't make sense. You can compare scalars, but ordered comparison of vectors is a bit nonsensical, unless it is element-wise. Usually, a[] > 0, a[] < 0, and a[] == 0 will all be false. Most likely, you really meant dot(a[]) > 0. Something like if ( all( a[] > 0 ) ) b[] += c[]; is more reasonable. But an implicit 'reduce' in a vector operation has little to commend it, I think.
Re: Vote for the new std.hash (oops, std.digest)
Am Thu, 23 Aug 2012 22:46:35 +0200 schrieb Jens Mueller : > > It says "Digests do not work in CTFE". > Just checked it for MD5. > I do not know but I think this is just a current limitation of the > CTFE implementation. It's possible to support CTFE, Piotr Szturmaj has some digests which work in CTFE. But it's difficult as everything which depends on endianness isn't supported in CTFE. https://github.com/pszturmaj/phobos/commit/d06c258b442c5b59ab3a66125c9aea8a4c00a0b7 take for example the setByte function: a[offset / E.sizeof] |= value << ((offset % E.sizeof) * 8); This is necessary because you can't cast from uint to ubyte[4] in CTFE.
Re: Vote for the new std.hash (oops, std.digest)
Johannes Pfau wrote: > Am Thu, 23 Aug 2012 22:46:35 +0200 > schrieb Jens Mueller : > > > > > It says "Digests do not work in CTFE". > > Just checked it for MD5. > > I do not know but I think this is just a current limitation of the > > CTFE implementation. > > It's possible to support CTFE, Piotr Szturmaj has some digests which > work in CTFE. But it's difficult as everything which depends on > endianness isn't supported in CTFE. > > https://github.com/pszturmaj/phobos/commit/d06c258b442c5b59ab3a66125c9aea8a4c00a0b7 > > take for example the setByte function: > a[offset / E.sizeof] |= value << ((offset % E.sizeof) * 8); > This is necessary because you can't cast from uint to ubyte[4] in CTFE. I see. Though I do not understand that limitation of CTFE. Since D has version(LittleEndian) and version(BigEndian) and CTFE should follow versioning I see no reason why casts that depend on endianness should not be supported. When writing a function you have to care about endianness anyway. Jens
Re: Vote for the new std.hash (oops, std.digest)
Yes
Re: Formatted read consumes input
On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra wrote:
As title implies:
import std.stdio;
import std.format;
void main()
{
string s = "42";
int v;
formattedRead(s, "%d", &v);
writefln("[%s] [%s]", s, v);
}
[] [42]
Is this the "expected" behavior?
Yes, both parse family and formattedRead are operating on ref
argument. That means they modify in place. Also ponder the
thought that 2 consecutive reads should obviously read first and
2nd value in the string not the same one.
Furthermore, it is not possible to try to "save" s:
import std.stdio;
import std.format;
import std.range;
void main()
{
string s = "42";
int v;
formattedRead(s.save, "%d", &v);
writefln("[%s] [%s]", s, v);
}
Yes, because ref doesn't bind r-value.
The workaround is to have a named backup:
auto ss = s.save;
formattedRead(ss, "%d", &v);
I've traced the root issue to formattedRead's signature, which
is:
uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S
args);
As I explained above the reason is because the only sane logic of
multiple reads is to consume input and to do so it needs ref.
Is there a particular reason for this pass by ref? It is
inconsistent with the rest of phobos, or even C's scanf?
C's scanf is a poor argument as it uses pointers instead of ref
(and it can't do ref as there is no ref in C :) ). Yet it doesn't
allow to read things in a couple of calls AFAIK. In C scanf
returns number of arguments successfully read not bytes so there
is no way to continue from where it stopped.
BTW it's not documented what formattedRead returns ... just ouch.
Re: Formatted read consumes input
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote: On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra wrote: I've traced the root issue to formattedRead's signature, which is: uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S args); As I explained above the reason is because the only sane logic of multiple reads is to consume input and to do so it needs ref. I had actually considered that argument. But a lot of algorithms have the same approach, yet they don't take refs, they *return* the consumed front: R formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args) auto s2 = formatedRead(s, "%d", &v); Or arguably: Tuple!(size_t, R) formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args) "minCount", "boyerMooreFinder" and "levenshteinDistanceAndPath" all take this approach to return a consumed range plus an index/count.
Re: Formatted read consumes input
24.08.2012 16:16, monarch_dodra пишет: On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote: On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra wrote: I've traced the root issue to formattedRead's signature, which is: uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S args); As I explained above the reason is because the only sane logic of multiple reads is to consume input and to do so it needs ref. I had actually considered that argument. But a lot of algorithms have the same approach, yet they don't take refs, they *return* the consumed front: R formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args) auto s2 = formatedRead(s, "%d", &v); Or arguably: Tuple!(size_t, R) formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args) "minCount", "boyerMooreFinder" and "levenshteinDistanceAndPath" all take this approach to return a consumed range plus an index/count. It's because `formattedRead` is designed to work with an input range which isn't a forward range (not save-able). -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Study: build times for D programs
On Tue, 24 Jul 2012 10:34:57 -0400, Andrei Alexandrescu wrote: Hello, I was talking to Walter on how to define a good study of D's compilation speed. We figured that we clearly need a good baseline, otherwise numbers have little meaning. Might I draw attention again to this bug: http://d.puremagic.com/issues/show_bug.cgi?id=4900 Granted, this is really freaking old. A re-application of profiling should be done. But in general, what I have observed from DMD compiling is that the number and size (string size) of symbols is what really bogs it down. Most of the time, it's lightning fast. The reason the dcollections unit test taxes it so much is because I'm instantiating 15 objects for each container type, and each one has humongous symbols, a consequence of so many template arguments. -Steve
Re: Formatted read consumes input
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote: C's scanf is a poor argument as it uses pointers instead of ref (and it can't do ref as there is no ref in C :) ). Yet it doesn't allow to read things in a couple of calls AFAIK. In C scanf returns number of arguments successfully read not bytes so there is no way to continue from where it stopped. BTW it's not documented what formattedRead returns ... just ouch. Actually... look up "%n" in sscanf it's wonderful, I use it all the time.
Re: Formatted read consumes input
On Friday, 24 August 2012 at 13:08:43 UTC, Denis Shelomovskij wrote: 24.08.2012 16:16, monarch_dodra пишет: On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote: On Thursday, 23 August 2012 at 11:33:19 UTC, monarch_dodra wrote: I've traced the root issue to formattedRead's signature, which is: uint formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, S args); As I explained above the reason is because the only sane logic of multiple reads is to consume input and to do so it needs ref. I had actually considered that argument. But a lot of algorithms have the same approach, yet they don't take refs, they *return* the consumed front: R formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args) auto s2 = formatedRead(s, "%d", &v); Or arguably: Tuple!(size_t, R) formattedRead(R, Char, S...)(R r, const(Char)[] fmt, S args) "minCount", "boyerMooreFinder" and "levenshteinDistanceAndPath" all take this approach to return a consumed range plus an index/count. It's because `formattedRead` is designed to work with an input range which isn't a forward range (not save-able). You had me ready to throw in the towel on that argument, but thinking harder about it, that doesn't really change anything actually: At the end of formattedRead, the passed range has a certain state. whether you give this range back to the caller via "pass by ref" or "return by value" has nothing to do with save-ability.
Re: More on vectorized comparisons
It's just syntax sugar for a very obscure operation,<
It's an operation included in Cilk Plus, I think Intel devs know
enough what they are doing.
And I think code like this is a common need:
if (a[] > 0) {
// ...
}
and it's somewhat ambiguous -- is it allowed to use
short-circuit evaluation?<
That code means:
foreach (i; 0 .. a.length) {
if (a[i] > 0) {
// ...
}
}
Here I don't see problems caused by short circuit evaluation.
You can compare scalars, but ordered comparison of vectors is a
bit nonsensical, unless it is element-wise.<
It's a comparison element-wise between each item and a constant,
it's similar to:
a[] = a[] + 5;
Probably you have misunderstood the semantics of what I am
discussing.
Bye,
bearophile
Re: interfaces and such
On Fri, 27 Jul 2012 12:48:59 -0400, David Nadlinger wrote: On Friday, 27 July 2012 at 14:56:18 UTC, Gor Gyolchanyan wrote: I have a small question: why aren't interfaces implicitly convertible to Object? Not all interfaces »originate« from D objects, they can also be COM interfaces. Using (cast(Object)foo) should work if foo is really an Object. All Com interfaces inherit from IUnknown. This is statically known. The idea that we cannot tell which interfaces are COM and which are normal is a myth. There is no reason why interfaces (that aren't COM) shouldn't be implicitly castable to Object. -Steve
Re: Null references
On 23/08/2012 18:27, Namespace wrote: Is there any special reason why these functions doesn't get "Maybe" as (const) ref? void show(T)(Maybe!T m) bool opEquals(Maybe!T m) void opAssign(Maybe!T m) No special reason. The Maybe struct is usually pretty small so using ref didn't occur to me, but if it's good practice I should do so. I suppose ref would be necessary because T could be a struct. I hadn't thought about const at all yet. BTW show is just a test function, I recently made it private. Nick
Re: Null references
On 22/08/2012 16:42, Philippe Sigaud wrote:
Then, both Simen and you could code a generic algebraic datatype
generator, with the associated matching functions (and probably
mapping / reducing) Here come the whole Haskell / ML menagerie of
types:)
mixin(ADT("
Tree(T):
Leaf(T)
| Branch(Tree, Tree)
"));
or something like that... And then encode JSON like this.
Or update std.typecons.Algebraic to make it deal with recursive definitions...
Sounds interesting. I haven't really thought about modelling sum types
yet - but I'm probably not the best person as I haven't actually used
them in a functional language. I expect that D's meta-programming
abilities will allow for some interesting things.
BTW thanks for your template tutorial, it's been very helpful.
Re: Vote for the new std.hash (oops, std.digest)
On Friday, 24 August 2012 at 08:18:07 UTC, Johannes Pfau wrote: Am Thu, 23 Aug 2012 22:46:35 +0200 schrieb Jens Mueller : It says "Digests do not work in CTFE". Just checked it for MD5. I do not know but I think this is just a current limitation of the CTFE implementation. It's possible to support CTFE, Piotr Szturmaj has some digests which work in CTFE. But it's difficult as everything which depends on endianness isn't supported in CTFE. Writing a library which is good enough to belong to std IS difficult. With D's incredibly powerful compile-time capabilities, I'm 100% many people will wonder why such a pure functionality as digest doesn't work with CTFE. As long as the interface itself allows future CTFE support, and the work is planned that's a YES from me. But I'd like to see at least one algorithm being implemented (e.g. CRC32 which currently works with CTFE) as a proof of concept (and a unit-test).
Re: Phobos unittest failure on single-core machines
On Friday, 24 August 2012 at 02:16:24 UTC, Ed McCardell wrote: When trying to run the phobos unittests on my 32- and 64-bit linux single-processor machines, I get this output: Testing generated/linux/debug/64/unittest/std/parallelism totalCPUs = 1 core.exception.AssertError@std.parallelism(4082): unittest failure Has anyone else seen this, or is possible that I have an error in my dmd setup? (I'm using dmd/druntime/phobos from git HEAD, building in what I thought was the normal manner). --Ed McCardell This looks to be a bug in a recently-added feature. I'll look at it in detail tonight, but I think I know what the problem is and it's pretty easy to fix. Can you please file a Bugzilla and note whether it always occurs or is non-deterministic?
Re: Consistency, Templates, Constructors, and D3
On 24/08/2012 06:14, F i L wrote:
DISCLAIMER: This isn't a feature request or anything like that. It's
ONLY intended to stir _constructive_ conversation and criticism of D's
existing features, and how to improve them _in the future_ (note the
'D3' in the title).
To start, let's look at: cast(T) vs to!T(t)
In D, we have one way to use template function, and then we have special
keyword syntax which doesn't follow the same syntactical rules. Here,
cast looks like the 'scope()' or 'debug' statement, which should be
followed by a body of code, but it works like a function which takes in
the following argument and returns the result. Setting aside the
"func!()()" syntax for a moment, what cast should look like in D is:
int i = cast!int(myLong);
That syntax makes sense, but cast is a built-in language feature. I'm
not sure making it look like a library function is really worth the
change IMO. In some cases the syntax would be a bit noisier:
cast(immutable int) v; // current
cast!(immutable int)(v); // new
It's a similar story with __traits(). What appears to be a function
taking in a run-time parameter is actually compile-time parameter which
works by "magic". It should look like:
bool b = traits!HasMember(Foo);
Or:
bool b = traits.hasMember!(Foo, "bar")();
Also:
int i;
bool b = __traits(isArithmetic, i); // current
bool b = traits.isArithmetic(i);// new
'i' cannot be a compile-time parameter or a runtime parameter either (by
normal rules). So I think __traits are special, they're not really like
a template function.
# Nimrod code
template foo(x:int) # compile time
when x == 0:
doSomething()
else:
doSomethingElse()
proc bar(x:int) # run time
if x == 0:
doSomething()
else:
doSomethingElse()
block main:
foo(0) # both have identical..
bar(0) # ..call signatures.
In D, that looks like:
void foo(int x)() {
static if (x == 0) { doSomething(); }
else { doSomethingElse(); }
}
void bar(int x) {
if (x == 0) { doSomething(); }
else { doSomethingElse(); }
}
void main() {
foo!0();
bar(0); // completely difference signatures
}
Ultimately foo is just more optimized in the case where an 'int' can be
passed at compile time, but the way you use it in Nimrod is much more
consistent than in D. In fact, Nimrod code is very clean because there's
no special syntax oddities, and that makes it easy to follow (at least
on that level), especially for people learning the language.
Personally I think it's a benefit that D makes compile-time and runtime
parameters look different in caller code. The two things are very different.
But I think there's a much better way. One of the things people like
about Dynamicly Typed languages is that you can hack things together
quickly. Given:
function load(filename) { ... }
the name of the parameter is all that's required when throwing something
together. You know what 'filename' is and how to use it. The biggest
problem (beyond efficiency), is later when you're tightening things up
you have to make sure that 'filename' is a valid type, so we end up
having to do the work manually where in a Strong Typed language we can
just define a type:
function load(filename)
{
if (filename != String) {
error("Must be string");
return;
}
...
}
vs:
void load(string filename) { ... }
but, of course, sometimes we want to take in a generic parameter, as D
programmers are fully aware. In D, we have that option:
void load(T)(T file)
{
static if (is(T : string))
...
else if (is(T : File))
...
}
Perhaps I'm being pedantic, but here it would probably be:
void load(T:string)(T file){...}
void load(T:File)(T file){...}
but it's wonky. Two parameter sets? Type deduction? These concepts
aren't the easiest to pick up, and I remember having some amount of
difficulty first learn what the "func!(...)(...)" did in D.
I think it's straightforward if you already know func<...>(...) syntax
from C++ and other languages.
So why not have one set of parameters and allow "typeless" ones which
are simply compile-time duck-typed?
void load(file)
{
static if (is(typeof(file) : string))
...
else if (is(typeof(file) : File))
...
}
this way, we have one set of rules for calling functions, and
deducing/defaulting parameters, with the same power. Plus, we get the
convenience of just hacking things together and going back later to
tighten things up.
The above code doesn't look much easier to understand than the current D
example. I think knowing about template function syntax is simpler than
knowing how to do static if tests.
I think there was a discussion about this before, but using:
void load(auto file)
Your analysis seems to go into more
Re: Formatted read consumes input
On 24-Aug-12 17:43, Tove wrote: On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote: C's scanf is a poor argument as it uses pointers instead of ref (and it can't do ref as there is no ref in C :) ). Yet it doesn't allow to read things in a couple of calls AFAIK. In C scanf returns number of arguments successfully read not bytes so there is no way to continue from where it stopped. BTW it's not documented what formattedRead returns ... just ouch. Actually... look up "%n" in sscanf it's wonderful, I use it all the time. God... what an awful kludge :) -- Olshansky Dmitry
Re: Study: build times for D programs
On Tuesday, 24 July 2012 at 14:34:58 UTC, Andrei Alexandrescu wrote: Hello, I was talking to Walter on how to define a good study of D's compilation speed. We figured that we clearly need a good baseline, otherwise numbers have little meaning. One idea would be to take a real, non-trivial application, written in both D and another compiled language. We then can measure build times for both applications, and also measure the relative speeds of the generated executables. Although it sounds daunting to write the same nontrivial program twice, it turns out such an application does exist: dmdscript, a Javascript engine written by Walter in both C++ and D. It has over 40KLOC so it's of a good size to play with. What we need is a volunteer who dusts off the codebase (e.g. the D source is in D1 and should be adjusted to compile with D2), run careful measurements, and show the results. Is anyone interested? Thanks, Andrei You can try testing DMD (written in C++) against DDMD (written in D). I don't think you can find more fair comparison (both projects are in sync - though dated - and project size is fairly large).
Re: More on vectorized comparisons
On Thursday, 23 August 2012 at 00:19:39 UTC, bearophile wrote:
At page 69 of those slides there is some code that looks
interesting, I think this is a reduced version of part of it,
that shows another way to use vectorized comparisons:
void main() {
double[] a = [1.0, 1.0, -1.0, 1.0, 0.0, -1.0];
double[] b = [10, 20, 30, 40, 50, 60];
double[] c = [1, 2,3, 4, 5,6];
if (a[] > 0)
b[] += c[];
}
I think that code is semantically equivalent to:
void main() {
double[] a = [1.0, 1.0, -1.0, 1.0, 0.0, -1.0];
double[] b = [10, 20, 30, 40, 50, 60];
double[] c = [1, 2,3, 4, 5,6];
foreach (i; 0 .. a.length)
if (a[i] > 0)
b[i] += c[i];
}
The proposed syntax looks weird. Wouldn't the followind be more
intuitive:
foreach (i; a[i] > 0)
b[i] += c[i];
Or alternatively it would be nice to be able to do it like in
Matlab:
i = (a[] > 0);
b[i] += c[i];
Re: Consistency, Templates, Constructors, and D3
On Friday, 24 August 2012 at 05:14:39 UTC, F i L wrote:
We replace it with special factory functions. Example:
class Person {
string name;
uint age;
this new(string n, uint a) {
name = n;
age = a;
}
}
void main() {
auto philip = Person.new("Philip", 24);
}
Notice 'new()' returns type 'this', which makes it static and
implicitly calls allocation methods (which could be overridden)
and has a 'this' reference.
The constructor definition syntax doesn't seem to be an
improvement: this new instead of the old this.
The constructor calling syntax is actually something I've thought
of before. I think Class.new is better than new Class, simply
because it's more succinct when chaining:
Class.new().method() vs. (new Class()).method()
NMS
Re: Consistency, Templates, Constructors, and D3
On 8/24/12, Nathan M. Swan wrote: > Class.new().method() vs. (new Class()).method() I prefer the latter because it's more explicit that you're throwing away an object after invocation (unless you do something funky in 'method' and store the 'this' reference globally).
Re: containers, iteration, and removal
On Wed, 01 Aug 2012 03:44:47 -0400, Ellery Newcomer
wrote:
Hello.
Today I was thinking about Java. Specifically, java.util.Iterator and
the pattern
while(iter.hasNext()) {
Object item = iter.next();
if(predicate(item)) {
iter.remove();
}
}
You can do this in Java.
You can do this just as easy in dcollections:
foreach(bool doRemove, item; container)
{
doRemove = predicate(item);
}
In fact, this little feature is one of the major reasons I wanted to
create a collections library. Tango's container library was modeled after
Doug Lea's (not the Java adaptation of it), and it did not include a way
to remove during iteration.
-Steve
Re: profiler issues: time overflows, conversion to seconds, gui/html output
Thanks, The trace code is in druntime/rt/trace.d. There you can see that the ticks/sec is just set to the shown constant value for anything but Windows, but RDTSC is used to read the processor cycles. So the values are probably off by a factor of 300 to 1000. So I'm still not sure how to convert those numbers to seconds. Is there a deterministic way? Is the multiplicative factor (300 to 1000) fixed on a given machine or what does it depend on ? The time in ms is calculated as (time * 100) / freq, so with a processor speed of 2GHz, this will overflow after about 2000s. Why not use 64 bit integer instead of 32 bit for counter? This doesn't seem to explain negative values in your run, so some random hints: - if you rerun the program, results will accumulate in trace.log I ran it just once - if you are calling recursive functions from inside main, there might be some issues with the timings of these functions (from my own experience from writing a profiler, it can get quite tricky to measure the execution time of recursive functions), and these are used to calculate the FuncTime of main. No recursive functions Visual D lets you explore trace.log in a browse window inside Visual Studio, but I guess this won't help you on OSX. great! Is there a way to run it on a project build outside of visualD? I use a makefile instead of relying on visualD's build system. When I open the profiler window and open trace.log inside nothing is shown. Ideally all it should do is demangle symbols and convert to a table, so I'm assuming trace.log is self-contained.
Re: profiler issues: time overflows, conversion to seconds, gui/html output
great! Is there a way to run it on a project build outside of visualD? I use a makefile instead of relying on visualD's build system. When I open the profiler window and open trace.log inside nothing is shown. Ideally all it should do is demangle symbols and convert to a table, so I'm assuming trace.log is self-contained. Oh the problem is trace.log here was built on a different architecture (osx). Would there be any way to visualize that with the tool still ? It should only be a matter of demangling osx style instead of windows style, the rest being identical?
Re: Phobos unittest failure on single-core machines
On 08/24/12 12:27, dsimcha wrote: This looks to be a bug in a recently-added feature. I'll look at it in detail tonight, but I think I know what the problem is and it's pretty easy to fix. Can you please file a Bugzilla and note whether it always occurs or is non-deterministic? Filed as http://d.puremagic.com/issues/show_bug.cgi?id=8582 --Ed
Re: containers, iteration, and removal
I feel kinda stupid here, what's wrong with C++ remove_if ( http://www.cplusplus.com/reference/algorithm/remove_if/ )?
Re: profiler issues: time overflows, conversion to seconds, gui/html output
On 24.08.2012 19:35, timotheecour wrote: Thanks, The trace code is in druntime/rt/trace.d. There you can see that the ticks/sec is just set to the shown constant value for anything but Windows, but RDTSC is used to read the processor cycles. So the values are probably off by a factor of 300 to 1000. So I'm still not sure how to convert those numbers to seconds. Is there a deterministic way? Is the multiplicative factor (300 to 1000) fixed on a given machine or what does it depend on ? The factor should be CPU-cycles-per-second / 3579545, so my estimate was for a CPU that runs at about 1 - 3.5 GHz. The time in ms is calculated as (time * 100) / freq, so with a processor speed of 2GHz, this will overflow after about 2000s. Why not use 64 bit integer instead of 32 bit for counter? The time is a long, but for current CPU-clock-speeds multiplying it with 100 limits the measurable time. Visual D lets you explore trace.log in a browse window inside Visual Studio, but I guess this won't help you on OSX. great! Is there a way to run it on a project build outside of visualD? I use a makefile instead of relying on visualD's build system. When I open the profiler window and open trace.log inside nothing is shown. Ideally all it should do is demangle symbols and convert to a table, so I'm assuming trace.log is self-contained. I would have guessed that it should not depend on the system the trace.log is generated as the D name mangling should be the same. And even if it is not, the profiler window still displays the mangled names. If you have an example of a non-working trace.log, you can send it to me, and I'll have a look.
Re: [GSOC] New unicode module beta, with Grapheme support!
On 23-Aug-12 10:34, Jacob Carlborg wrote: On 2012-08-22 23:31, Dmitry Olshansky wrote: Well, officially the final bell has rung, marking the end of GSOC. Cool. P.P.S. Volunteers who'd like to test x64 are welcome to run rdmd gen_uni.d and report back (maybe it's my local setup problem). On Mac OS X, using DMD 2.060 64bit, the assert at line 568 is triggered. The last part of the output is: 2FA1D ---> 2A600 2fa1d -~-> 2a600 core.exception.AssertError@gen_uni(568): Assertion failure Found one pesky bug ... not in my code though ^) http://d.puremagic.com/issues/show_bug.cgi?id=8583 And it appears to be the only problem with x64. The beta zipball now should have proper x64 version too. https://github.com/blackwhale/gsoc-bench-2012/zipball/beta -- Olshansky Dmitry
Re: Consistency, Templates, Constructors, and D3
On Friday, 24 August 2012 at 17:04:49 UTC, Andrej Mitrovic wrote: On 8/24/12, Nathan M. Swan wrote: Class.new().method() vs. (new Class()).method() I prefer the latter because it's more explicit that you're throwing away an object after invocation I'm not sure if I follow you here – when chaining methods, you are _always_ throwing away the return value temporaries… David
D-etractions A real world programmers view on D
was Andrew McKinlay is trying D for Suneido. http://thesoftwarelife.blogspot.fr/2012/08/d-etractions.html You do not necessarily have to agree with Andrew, but this is a pragmatic developer's view. Let me say that Andrew has created his own database system (Relational Algebra based) , his own language (Ruby like) and his own application frame work. Finally he is using his Tools to create real world software.. i.e. Trucking/Transport / Accounting etc. IMO a voice, D core developers should listen to. Bjoern
Re: D-etractions A real world programmers view on D
On 08/25/2012 01:58 AM, Pragma Tix wrote: was Andrew McKinlay is trying D for Suneido. http://thesoftwarelife.blogspot.fr/2012/08/d-etractions.html You do not necessarily have to agree with Andrew, but this is a pragmatic developer's view. Let me say that Andrew has created his own database system (Relational Algebra based) , his own language (Ruby like) and his own application frame work. Finally he is using his Tools to create real world software.. i.e. Trucking/Transport / Accounting etc. IMO a voice, D core developers should listen to. Bjoern His post comes down to: "I like to have an IDE and I prefer Java because I already know Java." This is perfectly fine of course, but why would this be relevant for D development?
Re: D-etractions A real world programmers view on D
Pragma Tix: IMO a voice, D core developers should listen to. Even assuming all the things he has said are true, what do you suggest D core developers to do? Example: how can D language devevelopers help D programmers better refactor D code? Maybe having some built-in refactoring features? Probably some GC improvements are coming, thanks to Google sponsorship. Bye, bearophile
Re: Consistency, Templates, Constructors, and D3
Nathan M. Swan wrote:
The constructor definition syntax doesn't seem to be an
improvement: this new instead of the old this.
well the reason they're named is because then you can multiple
constructors under different names:
class Model
{
string name;
float x = 0, y = 0;
this new(string n) {
name = n;
}
this new(string n, float x, float y) {
name = n;
this.x = x;
this.y = y;
}
this load(string fn) {
auto file = File.load(fn);
...
}
}
Here we have two overloads of the constructor new() without
conflict, but also two constructors that would have conflicted if
they weren't separated by name: new(string) and load(string).
In this situation today, we would normally need to make a static
factory function called 'load()' which created a 'new Model()'
and returned it. We do this factory function thing all the time
today, and it's required for things like Memory Pools and to
resolve naming conflicts like above. Ideally, there should be a
single, consistent way of creating objects which allow for
arbitrary named separation, and I think this is best solution.
Both Vala and Dart have a named-constructor syntax to address
this issue, but neither feels as consistent (to me) as what I'm
presenting above.
Re: D-etractions A real world programmers view on D
Am 25.08.2012 02:22, schrieb bearophile: Even assuming all the things he has said are true, what do you suggest D core developers to do? Example: how can D language devevelopers help D programmers better refactor D code? Maybe having some built-in refactoring features? Probably some GC improvements are coming, thanks to Google sponsorship. First of all --- I have just forwarded a link, 'cause I thought that this blog contains some interesting insights/views/opinions. Next. What the core team can do : GC Improvements. IDE support. std.lexer Following the blog you will find a few remarks about missing things in Phobos. Quote ~ D templates and CTFE + mixins are making me nervous. ~ End quote Well, than .. I would say C++11 is making me panicking. But the author did not offer any details. so it's hard to say what exactly make him worry. send him some gentle feedback ..
Re: D-etractions A real world programmers view on D
Pragma Tix: First of all --- I have just forwarded a link, 'cause I thought that this blog contains some interesting insights/views/opinions. Right, sorry :-) Bye, bearophile
Re: D-etractions A real world programmers view on D
Am 25.08.2012 02:20, schrieb Timon Gehr: His post comes down to: "I like to have an IDE and I prefer Java because I already know Java." Not exactly. Seems that he likes pure and immutable ... (not really Java ) F.I. quote But when you can't put immutable values in a container without wrapping them in a "Rebindable" template, that again makes me nervous. end quote Say an associative array that stores immutable objects. > This is perfectly fine of course, but why would this be relevant for D > development? This blog is relevant 'cause it is a voice saying "D is not production ready" Let me ask you this. why HBase/Hadoop is not done in D, why SWIFT is not written in D, why... etc. A: 'Cause the language is not yet stable, therefore the basic library is in flow. 4 me D2 is very far away from being a serious tool, atm D is a geek toy. Having a foreign pragmatic programmer saying exactly that, makes sense to me. I think this is an constructive blog, in case that somebody is willing to listen.
Re: interfaces and such
On Friday, 24 August 2012 at 14:15:28 UTC, Steven Schveighoffer wrote: On Fri, 27 Jul 2012 12:48:59 -0400, David Nadlinger wrote: On Friday, 27 July 2012 at 14:56:18 UTC, Gor Gyolchanyan wrote: I have a small question: why aren't interfaces implicitly convertible to Object? Not all interfaces »originate« from D objects, they can also be COM interfaces. Using (cast(Object)foo) should work if foo is really an Object. All Com interfaces inherit from IUnknown. This is statically known. The idea that we cannot tell which interfaces are COM and which are normal is a myth. There is no reason why interfaces (that aren't COM) shouldn't be implicitly castable to Object. -Steve Technically true, however COM is not the only example of foreign objects used via interfaces. The (limited) C++ compatibility, for example, works this way.
Re: D-etractions A real world programmers view on D
Pragma Tix: 'Cause the language is not yet stable, therefore the basic library is in flow. In a simulated annealing algorithm (http://en.wikipedia.org/wiki/Simulated_annealing ) you can't lower the temperature too much quickly, otherwise you get a bad solution. To reach a stable solution you need to lower the temperature progressively and smartly, sometimes you even have to increase it a bit again, before letting the system cool down and reach the stability you look for. Stochastic optimization strategies offer lot of useful metaphors to express ideas :-) Bye, bearophile
Re: Consistency, Templates, Constructors, and D3
I've had a couple of ideas recently about the importance of
consistency in a language design, and how a few languages I
highly respect (D, C#, and Nimrod) approach these issues. This
post is mostly me wanting to reach out to a community that
enjoys discussing such issues, in an effort to correct any
mis-conceptions I might hold, and to spread potentially good
ideas to the community in hopes that my favorite language will
benefit from our discussion.
The points you raise are good and I generally like your ideas,
although it feels a little early to talk about D3 when D2 is
still far from a comprehensive solution. Amazing that bug 1528 is
still open for example:
http://stackoverflow.com/questions/10970143/wheres-the-conflict-here
Regarding your idea for merging compile-time and run-time
arguments together, it sounds good at first but I wonder if it
would be difficult to handle in the parser, because at the call
site, the parser does not know whether a particular argument
should be a type or an expression. Still, no insurmountable
difficulties come to mind.
I certainly like the idea to introduce a more regular syntax for
object construction (as I have proposed before, see
http://d.puremagic.com/issues/show_bug.cgi?id=8381#c1) but you
didn't say whether it would be allowed to declare a static method
called "new". I'd be adamant that it should be allowed: the
caller should not know whether they are calling a constructor or
not. Also, I'm inclined to think that constructors should use
"init", in keeping with tradition.
A couple inconsistencies that come immediately to my mind about
D2 are
1. Function calling is foo!(x, y)(z) but declaration is foo(x,
y)(int z)
And the compiler doesn't always offer a good error message.
I'm seeing
"function declaration without return type. (Note that
constructors are always named 'this')"
"no identifier for declarator myFunction!(Range)(Range r)"
2. Ref parameters are declared as (ref int x) but are not allowed
to be called as (ref x) -- then again, maybe it's not a real
inconsistency, but I'm annoyed. It prevents my code from
self-documenting properly.
Obviously, D is easy compared to C++, but no language should be
judged by such a low standard of learnability. So I am also
bothered by various things about D that feel unintuitive:
1. Enums. Since most enums are just a single value, they are
named incorrectly.
2. immutable int[] func()... does not return an immutable array
of int[]?
3. 0..10 in a "foreach" loop is not a range. It took me awhile to
find the equivalent range function, whose name is quite baffling:
"iota(10)"
4. Eponymous templates aren't distinct enough. Their syntax is
the same as a normal template except that the outer and inner
members just happen to have the same name. This confused me the
other day when I was trying to understand some code by Nick,
which called a method inside an eponymous templates via another
magic syntax, UFCS (I like UFCS, but I might be a little happier
if free functions had to request participation in it.)
5. The meaning is non-obvious when using "static import" and
advanced imports like "import a = b : c, d" or "import a : b = c,
d = e" or "import a = b : c = d".
6. the syntax of is(...)! It looks like a function or operator
with an expression inside, when in fact the whole thing is one
big operator. It's especially not obvious that "is(typeof(foo +
bar))" means "test whether foo+bar is a valid and meaningful
expression".
Making matters worse, the language itself and most of its
constructs are non-Googlable. For example if you don't remember
how do declare the forwarding operator (alias this), what do you
search for? If you see "alias _suchAndSuch this" and don't know
what it means, what do you search for? (one might not think of
removing the middle word and searching for that).
I even have trouble finding stuff in TDPL e-book. The place where
templates are discussed is odd: section 7.5 in chapter 7,
"user-defined types", even though the template statement doesn't
actually define a type. I know, I should just read the book
again... say, where's the second edition? I got so disappointed
when I reached the end of chapter 13 and it was followed by an
index. No UFCS or traits or ranges mentioned in there anywhere...
compile-time function evaluation is mentioned, but the actual
acronym CTFE is not.
I also hope something will be changed about contracts. I am
unlikely to ever use them if there's no option to keep SOME of
them in release builds (I need them to work at all boundaries
between different parties' code, e.g. official API boundaries,
and it is preferable to keep them in all cases that they don't
hurt performance; finally, we should consider that the class that
contains the contracts may not know its own role in the program,
so it may not know whether to assert or enforce is best). Plus,
the syntax is too verbose. Instead of
in {
