[OT?] C compiler written form scratch in D
Hello, I'd like to announce that I am going to be writing a C-compiler in D. Without flex or bison or anything like that. Just pure handwritten D. I will shoot videos of my progress, and I will explain how a compiler really works. If you think that is like HandmadeHero you are right! Caseys videos inspired my to do this. I hope that some of you will be watching this. Please tell me what you think if that announcement, and feel free to ask anything you like. Regards Stefan (Uplink_Coder).
Re: [OT?] C compiler written form scratch in D
On Sunday, 7 December 2014 at 19:13:42 UTC, Stefan Koch wrote: Please tell me what you think if that announcement, and feel free to ask anything you like. Nice and some useful links: https://www.reddit.com/r/programming/comments/2latu2/c4_c_in_4_functions/ http://homepage.ntlworld.com/edmund.grimley-evans/cc500/ https://github.com/alexfru/SmallerC good luck, Matheus.
Re: [OT?] C compiler written form scratch in D
On Sunday, 7 December 2014 at 20:17:30 UTC, MattCoder wrote: On Sunday, 7 December 2014 at 19:13:42 UTC, Stefan Koch wrote: Please tell me what you think if that announcement, and feel free to ask anything you like. Nice and some useful links: https://www.reddit.com/r/programming/comments/2latu2/c4_c_in_4_functions/ http://homepage.ntlworld.com/edmund.grimley-evans/cc500/ https://github.com/alexfru/SmallerC good luck, Matheus. Thanks for thoose links! Intresting stuff.
Re: DIP69 - Implement scope for escape proof references
On Sunday, 7 December 2014 at 06:52:38 UTC, Sebastiaan Koppe wrote: On Saturday, 6 December 2014 at 12:38:24 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 December 2014 at 04:31:48 UTC, Sebastiaan Koppe wrote: I am a big proponent of dataflow analyses, but I got the feeling people think is it pretty hard. I think D is in a good position to use the information available in assert* and in contracts for that. Other languages have to use dedicated tools for that. In a latter step, D could even formalize this into, as discussed in other threads, VRP sub-language. But, for the time being, the leverage offered by assert and in /out is available there to be used. *yes, I know the war between assert and assume
Re: DIP69 - Implement scope for escape proof references
On 2014-12-07 01:49, Manu via Digitalmars-d wrote:
I have std.simd sitting here, and I really want to finish it, but I
still don't have the tools to do so.
I need, at least, forceinline to complete it, but that one *is*
controversial - we've talked about this for years.
GDC and LDC both have a forceinline, so I could theoretically support
those compilers, but then I can't practically make use of them without
some sort of attribute aliasing system, otherwise I need to triplicate
the code for each compiler, just to insert a different (compiler
specific) forceinline attribute name. It'd be really great if we
agreed on just one.
I don't know about LDC but at least GDC allows you to use UDA's instead
of a pragma. Then you can create a dummy attribute for DMD (and LDC):
version (GNU)
import gcc.attribute
else
{
struct attribute
{
string attr;
}
}
@attribute(forceinline) void foo ();
--
/Jacob Carlborg
Re: DIP69 - Implement scope for escape proof references
On Friday, 5 December 2014 at 23:58:41 UTC, Walter Bright wrote:
On 12/5/2014 8:48 AM, Marc Schütz schue...@gmx.net wrote:
scope ref int foo();
scope ref int bar1(ref int a) {
return a;
}
scope ref int bar2(scope ref int a) {
return a;
}
ref int bar3(ref int a) {
return a;
}
ref int bar4(scope ref int a) {
return a;
}
void baz(scope ref int a);
Which of the following calls would work?
foo().bar1().baz();
yes
foo().bar2().baz();
no - cannot return scope ref parameter
foo().bar3().baz();
yes
foo().bar4().baz();
no, cannot return scope ref parameter
I understand that scope will not allow the contents of the
variable to escape the lifetime of a declaration. But can you
explain why bar1() works, but bar2() doesn't? Isn't the body of
bar2() in the line `foo().bar2();` part of the declaration?
Besides, what does it mean to return a `scope ref int`? Does it
mean that the content of the variable that is returned is not
allowed to escape the scope of the calling site? Huh?
It seemed so easy when you gave the example.
On Friday, 5 December 2014 at 20:55:55 UTC, Walter Bright wrote:
It means that this code will be safe:
void foo(scope int* p);
p = malloc(n);
foo(p);
free(p);
The rest is all the nuts and bolts of making that work.
Re: DIP69 - Implement scope for escape proof references
On 7 Dec 2014 10:40, Jacob Carlborg via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2014-12-07 01:49, Manu via Digitalmars-d wrote:
I have std.simd sitting here, and I really want to finish it, but I
still don't have the tools to do so.
I need, at least, forceinline to complete it, but that one *is*
controversial - we've talked about this for years.
GDC and LDC both have a forceinline, so I could theoretically support
those compilers, but then I can't practically make use of them without
some sort of attribute aliasing system, otherwise I need to triplicate
the code for each compiler, just to insert a different (compiler
specific) forceinline attribute name. It'd be really great if we
agreed on just one.
I don't know about LDC but at least GDC allows you to use UDA's instead
of a pragma. Then you can create a dummy attribute for DMD (and LDC):
version (GNU)
import gcc.attribute
else
{
struct attribute
{
string attr;
}
}
@attribute(forceinline) void foo ();
You can add shorthand aliases for them too. :)
@forceinline void foo ();
Re: Do everything in Java…
On 6/12/2014 5:45 a.m., Dicebot wrote: In my opinion OOP is very unfriendly for testing as a paradigm in general. The very necessity to create mocks is usually an alarm. I am curious how you would write tests without mocks.
Re: Do everything in Java…
That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. Poor guys, working 7 days a week, 40 hours a day...
Re: DIP69 - Implement scope for escape proof references
On Sunday, 7 December 2014 at 06:52:38 UTC, Sebastiaan Koppe wrote: How would it break anything though? Wouldn't functions eligible for `consume` already have the programmer ensuring the arguments haven't escaped before/after the function call? In case they did a bad job - sure it would break - but it would have been a bug. I don't think the breakage is a serious problem in this case, so I obviously agree with you… But, the deep-rooted problem is that you actually need different properties associated with pointers to do this properly: unique, single-threaded shared, multi-threaded shared, gc, non-owning… And this could be resolved with templates and having the compiler recognize pointer resolutions that lead to the same lower level code (to avoid bloat). But the D authors don't want ownership related pointertypes… and I can't see that work. I am a big proponent of dataflow analyses, but I got the feeling people think is it pretty hard. Couldn't find much detailed papers on it, so I don't know. You can do it in a simpler and conservative fashion and accept false positives (or negatives) so that you here-and-there have to inject annotations like this: trust me I have proven that this property holds here, then let the compiler infer the rest. With a good IDE this should be no biggie: just inject suggestions in the code and let the programmer confirm/refine them. If you want to guarantee memory-safety you should do it with a single uniform mechanism, trying to do it bit-by-bit special casing is not a good idea. So given the current approach, I'm inclined to turn off @safe, make everything @nogc, write my own libraries with unique_ptr/shared_ptr and call it a day… The current approach does not address situations where I run into memory related bugs in my own code.
Re: Help with d_language subreddit on Reddit
On Friday, 5 December 2014 at 23:25:11 UTC, Walter Bright wrote: https://www.reddit.com/r/d_language/ It's the default, and is kinda boring. Compare with the rust subreddit: http://www.reddit.com/r/rust/ While not great, it's much better than ours. We don't need the subreddit. We have these forums. Rust has their own forum, but it's for implementers. Most of their discussions/announcements happen at reddit. That's why it is more active and maintained. We already have an active forum here for everything, so we don't need another one. No point splitting the community. Just leave the qznc bot their to cross post announcements, but I don't think there's any value in trying to have, or promote, two separate forums.
Fedora equivalent of D-Apt
I wonder if Copr could be used to create a Fedora project repository for all the D bits and pieces in the way that D-Apt does things for Debian? https://fedorahosted.org/copr/wiki/UserDocs -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Do everything in Java…
On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote: Solved in Scala: - operator overloading - properties - that + optional (), a library writer still can enforce () to be used - only and exactly one class - any number in any combination - everything class - sort of, it has 'object' clause (just like 'class') that can be thought as a kind of namespace or a singleton if you love OOP. Not fixed: - unsigend types - nothing here unless Java adds support - pasing by value - there are immutable and value types (e.g. Tuples) but I think they are references behind the scenes - no templates, but you may use AST macros which is even more powerful Scala tries to make things nicer by providing higher level abstractions but with tiny bit more poking JVM origins still are unpleasantly notable. The whole Function1 .. Function22 trait thing has made me laugh very hard when reading the spec originally :)
Re: Do everything in Java…
On Saturday, 6 December 2014 at 07:56:48 UTC, Paulo Pinto wrote: On Saturday, 6 December 2014 at 01:53:03 UTC, Rikki Cattermole wrote: On 6/12/2014 5:45 a.m., Dicebot wrote: In my opinion OOP is very unfriendly for testing as a paradigm in general. The very necessity to create mocks is usually an alarm. I really need to start saving quotes. This is definitely a keeper! Except that in procedural code that option doesn't even exist, so no testing without going to the network. Not really. In procedural code you don't have that much coupling between data and behaviour which makes creating mocks as easy as filling the struct instance fields and passing it as an argument. However I was not speaking about plain procedural/imperative paradigm as better alternative but functional and generic ones. First one helps with eliminating state in general. Second one allows to use the very same mocks in much more light-weight way because no runtime binding is necessary - no dependency injection stuff and unnecessary interfaces, just using stub policy is enough.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds
the missing semantics for the 'scope' storage class in order to
make it possible to pass a reference to a function without it
being possible for it to escape.
This, among other things, makes a ref counting type practical.
It also makes it more practical to use other storage allocation
schemes than garbage collection.
It does not make scope into a type constructor, nor a general
type-annotation system.
It does not provide an ownership system, though it would
complement one.
Thanks a lot of trying to move forward with this. Also glad to
see DIP36 didn't vanish completely useless :P It will take me
some time to provide a detailed response so I'll post a summary
of my impression first.
I recognize and respect your attempt to go for most simple
solution that is still useful in practice. Can't say I am happy
about it but it is better to have something working than awesome
plans that never get implemented. In this context trying to get
most of scope as storage class seems right.
But from existing cases it doesn't seem working good enough. For
example, not being able to represent idiom of `scope ref int
foo(scope ref int x) { return x; }` seems very limiting. There
are also issues that pop up because of missing transitivity.
Maybe this can be fixed within existing proposal, maybe not.
Right now I don't have any strong opinion.
I also don't consider `ref` design as a storage class any kind of
success at all and generally agree with Manu on this topic. At
the same time alternative proposals that make it a qualifier
(like Marc did) do impact existing language much more and this no
small concern.
This won't be easy.
Re: Do everything in Java…
On Sunday, 7 December 2014 at 13:47:09 UTC, Dicebot wrote:
However I was not speaking about plain procedural/imperative
paradigm as better alternative but functional and generic ones.
First one helps with eliminating state in general. Second one
allows to use the very same mocks in much more light-weight way
because no runtime binding is necessary - no dependency
injection stuff and unnecessary interfaces, just using stub
policy is enough.
To give some examples from personal experience of what frustrates
me in typical OOP testing approach:
Imagine we have a simple cache class that internally communicates
with external dht:
class Cache
{
private DhtClient client;
this(string addr) { this.client = new DhtClient(addr); }
}
Now we want to test it which implies adding mock client.
Canonical way do it is by dependency injection and interface:
class Cache
{
private IDhtClient client;
this(IDhtClient client) { this.client = client; }
}
And know what? This just plain sucks. Not only you are now forced
to modify yoru application code in many places to just comply to
test-related changes that don't help actual app. You also
introduce unnecessary interface indirection potentially killing
inlining opportunities in the process.
Same stuff with policy approach:
class CacheT(DhtClient)
{
static assert (isDhtClient!DhtClient);
private DhtClient client;
this(string addr) { this.client = new DhtClient(addr); }
}
alias Cache = CacheT!DhtClient;
Effectively the same code as sample 1 and makes no difference for
rest of the application. And how would I test it?
alias TestCache = CacheT!StubDhtClient;
No changes to application, no extra indirections, same effective
testing coverage. Much better.
And, of course, any utility functions that contain complex logic
are better moved to free functions so that those can be tested
with no relation to other code at all.
Recent repetitive spam?
I wonder if it is me or everyone is receiving some sort of kitchen-related spam via the mailing list? The email ID or keywords they are using seem to be relatively predictable and unrelated to programming so I wonder whether the listadmin hasn't had the time to kick out this intruder? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Do everything in Java…
On Sun, Dec 07, 2014 at 11:03:13AM +, via Digitalmars-d wrote: That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. Poor guys, working 7 days a week, 40 hours a day... Haha, oops. I meant 40 hours * 5 days a week * 50 people = 1 man hours of work. Still a lot. T -- Hi. 'Lo.
Re: Do everything in Java…
On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote: Haha, oops. I meant 40 hours * 5 days a week * 50 people = 1 man hours of work. Still a lot. The long work hours is why the US is ahead of Europe.
Re: Do everything in Java…
On Sunday, 7 December 2014 at 15:44:55 UTC, Ola Fosheim Grøstad wrote: On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote: Haha, oops. I meant 40 hours * 5 days a week * 50 people = 1 man hours of work. Still a lot. The long work hours is why the US is ahead of Europe. IIRC the country with longest working hours in the EU is Greece.
Re: Do everything in Java…
On Sunday, 7 December 2014 at 15:46:59 UTC, John Colvin wrote: IIRC the country with longest working hours in the EU is Greece. The hours seem longer when it is hot…
Re: Do everything in Java…
On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote: On Sun, Dec 07, 2014 at 11:03:13AM +, via Digitalmars-d wrote: That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. Poor guys, working 7 days a week, 40 hours a day... Haha, oops. I meant 40 hours * 5 days a week * 50 people = 1 man hours of work. Still a lot. No, I don't think you mean that either... (Hint: how many hours are in a day?)
Re: Do everything in Java…
On Sun, Dec 07, 2014 at 04:01:36PM +, via Digitalmars-d wrote: On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote: On Sun, Dec 07, 2014 at 11:03:13AM +, via Digitalmars-d wrote: That's 40 hours * 7 days * 50 developers = 14000 man-hours worth of work. Poor guys, working 7 days a week, 40 hours a day... Haha, oops. I meant 40 hours * 5 days a week * 50 people = 1 man hours of work. Still a lot. No, I don't think you mean that either... (Hint: how many hours are in a day?) Hahaha... you're right, I'm not thinking straight. OK, so it's 40*50 = 200 man-hours per week. Hmph... I'm about two orders of magnitude off. *hangs head in shame* T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
Re: DIP69 - Implement scope for escape proof references
On 2014-12-07 11:50, Iain Buclaw via Digitalmars-d wrote: You can add shorthand aliases for them too. :) @forceinline void foo (); Good point. -- /Jacob Carlborg
Re: Do everything in Java…
On Sunday, 7 December 2014 at 16:08:27 UTC, H. S. Teoh via Digitalmars-d wrote: Hahaha... you're right, I'm not thinking straight. OK, so it's 40*50 = 200 man-hours per week. Hmph... I'm about two orders of magnitude off. log10(40/8) = 0.6989700043360189 orders of magnitude…
Re: DIP69 - Implement scope for escape proof references
On 05/12/2014 23:58, Walter Bright wrote: 2) `scope ref` return values cannot be stored. scope ref int foo(); void bar(scope ref int a); foo().bar();// allowed scope tmp = foo(); // not allowed tmp.bar(); Right From the DIP: The lifetime of a scope return value is the lifetime of an rvalue. It may not be copied in a way that extends its life. With part of the example: scope int* foo(); ... int* p = foo(); // Error, lifetime(p) is infin; Maybe the error should be 'scope return value cannot be stored', because otherwise p could be inferred as scope.
Re: DIP69 - Implement scope for escape proof references
On 04/12/2014 12:55, bearophile wrote:
Regarding array literals, some people proposed a syntax for fixed-size
arrays to avoid heap-allocations (the s after the array literal):
void foo(int[2]) {}
void bar(scope int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
I think even if the compiler could infer them as static arrays, it may
still be useful to be explicit sometimes. We can already use a library
template:
template staticArray(items...)
{
import std.traits;
alias T = CommonType!items[items.length];
enum T staticArray = [items];
}
auto s = staticArray!(1, 2);
static assert(is(typeof(s) == int[2]));
bar(staticArray!(1, 2));
This might also make the proposed 'int[$] = [...];' syntax unnecessary.
I think jmdavis once wrote something similar - although I've used enum
here in case it helps avoid function template bloat.
Re: std::string responsible for half the allocations in chrome
On Saturday, 6 December 2014 at 16:32:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton Wakeling via Digitalmars-d wrote: On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ? Immutable, because then you can freely use slices as substrings without worrying that the substring you hand to function X might get modified by unrelated function Y while function X is not quite done with processing it yet. At the same time, immutable means that if you do need to do any string manipulation, you need to copy the string first. I think whether immutable means more or less allocations than mutable/const is actually more dependent on application design than anything, and some applications can't afford the copying that using immutable requires.
Re: Do everything in Java…
On Sunday, 7 December 2014 at 13:39:38 UTC, Dicebot wrote: On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote: Solved in Scala: - operator overloading - properties - that + optional (), a library writer still can enforce () to be used - only and exactly one class - any number in any combination - everything class - sort of, it has 'object' clause (just like 'class') that can be thought as a kind of namespace or a singleton if you love OOP. Not fixed: - unsigend types - nothing here unless Java adds support - pasing by value - there are immutable and value types (e.g. Tuples) but I think they are references behind the scenes - no templates, but you may use AST macros which is even more powerful Scala tries to make things nicer by providing higher level abstractions but with tiny bit more poking JVM origins still are unpleasantly notable. The whole Function1 .. Function22 trait thing has made me laugh very hard when reading the spec originally :) .NET is no different http://msdn.microsoft.com/en-us/library/dd402872%28v=vs.110%29.aspx This is what happens when generics don't support variable number of types. -- Paulo
Re: Do everything in Java…
07-Dec-2014 16:39, Dicebot пишет: On Saturday, 6 December 2014 at 09:07:34 UTC, Dmitry Olshansky wrote: Solved in Scala: - operator overloading - properties - that + optional (), a library writer still can enforce () to be used - only and exactly one class - any number in any combination - everything class - sort of, it has 'object' clause (just like 'class') that can be thought as a kind of namespace or a singleton if you love OOP. Not fixed: - unsigend types - nothing here unless Java adds support - pasing by value - there are immutable and value types (e.g. Tuples) but I think they are references behind the scenes - no templates, but you may use AST macros which is even more powerful Scala tries to make things nicer by providing higher level abstractions but with tiny bit more poking JVM origins still are unpleasantly notable. It actually quite successful at making things more coherent and extensible (something directly opposite to original Java). There are downsides, type erasure is the most unavoidable trait. The whole Function1 .. Function22 trait thing has made me laugh very hard when reading the spec originally :) Aye. The good things is that while e.g. (Int,Int) has type Tuple2![Int,Int] it's at least compiler-generated. -- Dmitry Olshansky
Re: Do everything in Java…
06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет: On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via Digitalmars-d wrote: [...] primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) Primitive types are scheduled for removal, leaving only reference types. [...] Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? With great success. Sounds like I will never consider Java for computation-heavy tasks then... Interestingly working with JVM for the last 2 years the only problem I've found is memory usage overhead of collections and non-trivial objects. In my tests performance of simple numeric code was actually better with Scala (not even plain Java) then with D (LDC), for instance. -- Dmitry Olshansky
Re: Recent repetitive spam?
On 12/7/2014 7:25 AM, Shriramana Sharma via Digitalmars-d wrote: I wonder if it is me or everyone is receiving some sort of kitchen-related spam via the mailing list? The email ID or keywords they are using seem to be relatively predictable and unrelated to programming so I wonder whether the listadmin hasn't had the time to kick out this intruder? I delete spam from the n.g., but there's not much I can do about the mailing list.
Re: DIP69 - Implement scope for escape proof references
On 12/7/2014 6:12 AM, Dicebot wrote:
But from existing cases it doesn't seem working good enough. For example, not
being able to represent idiom of `scope ref int foo(scope ref int x) { return x;
}` seems very limiting.
scope ref int foo(ref int x);
will do it.
I also don't consider `ref` design as a storage class any kind of success at all
and generally agree with Manu on this topic. At the same time alternative
proposals that make it a qualifier (like Marc did) do impact existing language
much more and this no small concern.
My experience with C++ ref as type qualifier is very, very bad. It's a special
case EVERYWHERE. Doing type deduction with it is an exercise in a completely
baffling set of rules and a different rule for every occasion - Scott Meyers has
a great piece on this.
There are probably only a handful of people on the planet who actually
understand C++ ref. I wished very hard to avoid that with D ref.
Re: Do everything in Java…
On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry Olshansky wrote: 06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет: On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via Digitalmars-d wrote: [...] primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) Primitive types are scheduled for removal, leaving only reference types. [...] Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? With great success. Sounds like I will never consider Java for computation-heavy tasks then... Interestingly working with JVM for the last 2 years the only problem I've found is memory usage overhead of collections and non-trivial objects. In my tests performance of simple numeric code was actually better with Scala (not even plain Java) then with D (LDC), for instance. Got an example? I'd be interested to see a numerical-code example where the JVM can beat the llvm/gcc backends on a real calculation (even if it's a small one).
Re: Find symbol in unknown module at compile time?
On Sunday, 7 December 2014 at 06:25:48 UTC, ketmar via Digitalmars-d wrote: On Sun, 07 Dec 2014 05:42:31 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: what you actually want is some cross-module compile-time data storage. this is impossible to implement. at least to make it reliable. with separate compilation, for example, you can't get list of all modules, 'cause we can link other unimported modules to the final executable. this is somethimes useful with extern, for example. and there is no such thing as main module too, so there is no root for symbols. besides, some templates can be not instantiated at the time you doing compile-time reflection, for example. that is why my console-ng requires that register all mixin must be the last line in the module. with some efforts and hackery you can walk all imported modules, but this can fail at unexpected places. tl;dr: things aren't that easy when it comes to compile-time reflection. either live that to runtime or write compile-time wrappers and restrict compile-time reflection usage to well-defined places and patterns. I think I understand what you mean. I've been surprised with the way D is able to handle circular references, but I guess there still has to be some order of initialization at the end of the day. Thinking about my current design, I believe there are places where circular references could cause problems, but that I have yet to find them because I haven't properly tested against a large/complicated codebase. I think the best plan for me would be to store all reflection information in the reflection module itself as local static variables of templates, i.e. Meyers singleton style. This would disallow me from reflecting private members, but would greatly simplify my design. Also, the mixin could then be used exclusively for registering runtime reflection, and be placed anywhere. I would like to be able to reflect private members though... Is there any way to give a module private access to an unrelated module? I'm thinking of something like placing a pragma at the top of a module or adding a qualifier to a module declaration. #pragma privileged or module reflection privileged; I understand that packages are meant to solve this problem for regular code, but given the fact that D has such a comprehensive reflection system, it would be nice to have this special case.
Re: Do everything in Java…
On Sat, Dec 6, 2014 at 7:26 AM, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: Primitive types are scheduled for removal, leaving only reference types. Are you referring to: http://openjdk.java.net/jeps/169 ?
Re: Do everything in Java…
08-Dec-2014 00:36, John Colvin пишет:
On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry Olshansky wrote:
06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет:
On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via
Digitalmars-d wrote:
[...]
primitive are passed by value; arrays and user defined types are
passed by reference only (killing memory usage)
Primitive types are scheduled for removal, leaving only reference
types.
[...]
Whoa. So they're basically going to rely on JIT to convert those boxed
Integers into hardware ints for performance?
With great success.
Sounds like I will never
consider Java for computation-heavy tasks then...
Interestingly working with JVM for the last 2 years the only problem
I've found is memory usage overhead of collections and non-trivial
objects. In my tests performance of simple numeric code was actually
better with Scala (not even plain Java) then with D (LDC), for instance.
Got an example? I'd be interested to see a numerical-code example where
the JVM can beat the llvm/gcc backends on a real calculation (even if
it's a small one).
It was trivial Gaussian integration.
http://en.wikipedia.org/wiki/Gaussian_quadrature
I do not claim code is optimal or anything, but it's line for line.
// D version
import std.algorithm, std.stdio, std.datetime;
auto integrate(double function(double) f, double a, double b, int n){
auto step = (b-a)/n;
auto sum = 0.0;
auto x = a;
while(xb)
{
sum += (f(x) + f(x+step))*step/2;
x += step;
}
return sum;
}
long timeIt(){
StopWatch sw;
sw.start();
auto r = integrate(x = x*x*x, 0.0, 1.0, 100);
sw.stop();
return sw.peek().usecs;
}
void main(){
auto estimate = timeIt;
foreach(_; 0..1000)
estimate = min(estimate, timeIt);
writef(%s sec\n, estimate/1e6);
}
// Scala version
def integrate(f: Double = Double, a: Double, b: Double, n : Int):
Double = {
val step = (b-a)/n;
var sum = 0.0;
var x = a;
while(xb)
{
sum += (f(x) + f(x+step))*step/2;
x += step;
}
sum
}
def timeIt() = {
val start = System.nanoTime();
val r = integrate(x = x*x*x, 0.0, 1.0, 100);
val end = System.nanoTime();
end - start
}
var estimate = timeIt;
for ( _ - 1 to 1000 )
estimate = Math.min(estimate, timeIt)
printf(%s sec\n, estimate/1e9);
--
Dmitry Olshansky
Re: Do everything in Java…
On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry Olshansky
wrote:
08-Dec-2014 00:36, John Colvin пишет:
On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry Olshansky
wrote:
06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет:
On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via
Digitalmars-d wrote:
[...]
primitive are passed by value; arrays and user defined
types are
passed by reference only (killing memory usage)
Primitive types are scheduled for removal, leaving only
reference
types.
[...]
Whoa. So they're basically going to rely on JIT to convert
those boxed
Integers into hardware ints for performance?
With great success.
Sounds like I will never
consider Java for computation-heavy tasks then...
Interestingly working with JVM for the last 2 years the only
problem
I've found is memory usage overhead of collections and
non-trivial
objects. In my tests performance of simple numeric code was
actually
better with Scala (not even plain Java) then with D (LDC),
for instance.
Got an example? I'd be interested to see a numerical-code
example where
the JVM can beat the llvm/gcc backends on a real calculation
(even if
it's a small one).
It was trivial Gaussian integration.
http://en.wikipedia.org/wiki/Gaussian_quadrature
I do not claim code is optimal or anything, but it's line for
line.
// D version
import std.algorithm, std.stdio, std.datetime;
auto integrate(double function(double) f, double a, double b,
int n){
auto step = (b-a)/n;
auto sum = 0.0;
auto x = a;
while(xb)
{
sum += (f(x) + f(x+step))*step/2;
x += step;
}
return sum;
}
long timeIt(){
StopWatch sw;
sw.start();
auto r = integrate(x = x*x*x, 0.0, 1.0, 100);
sw.stop();
return sw.peek().usecs;
}
void main(){
auto estimate = timeIt;
foreach(_; 0..1000)
estimate = min(estimate, timeIt);
writef(%s sec\n, estimate/1e6);
}
// Scala version
def integrate(f: Double = Double, a: Double, b: Double, n :
Int): Double = {
val step = (b-a)/n;
var sum = 0.0;
var x = a;
while(xb)
{
sum += (f(x) + f(x+step))*step/2;
x += step;
}
sum
}
def timeIt() = {
val start = System.nanoTime();
val r = integrate(x = x*x*x, 0.0, 1.0, 100);
val end = System.nanoTime();
end - start
}
var estimate = timeIt;
for ( _ - 1 to 1000 )
estimate = Math.min(estimate, timeIt)
printf(%s sec\n, estimate/1e9);
on my machine (Haswell i5) I get scala as taking 1.6x as long as
the ldc version.
I don't know scala though, I compiled using -optimise, are there
other arguments I should be using?
Re: Do everything in Java…
08-Dec-2014 01:38, John Colvin пишет: On Sunday, 7 December 2014 at 22:13:50 UTC, Dmitry Olshansky wrote: 08-Dec-2014 00:36, John Colvin пишет: On Sunday, 7 December 2014 at 19:56:49 UTC, Dmitry Olshansky wrote: 06-Dec-2014 18:33, H. S. Teoh via Digitalmars-d пишет: On Sat, Dec 06, 2014 at 03:26:08PM +, Russel Winder via Digitalmars-d wrote: [...] primitive are passed by value; arrays and user defined types are passed by reference only (killing memory usage) Primitive types are scheduled for removal, leaving only reference types. [...] Whoa. So they're basically going to rely on JIT to convert those boxed Integers into hardware ints for performance? With great success. Sounds like I will never consider Java for computation-heavy tasks then... Interestingly working with JVM for the last 2 years the only problem I've found is memory usage overhead of collections and non-trivial objects. In my tests performance of simple numeric code was actually better with Scala (not even plain Java) then with D (LDC), for instance. Got an example? I'd be interested to see a numerical-code example where the JVM can beat the llvm/gcc backends on a real calculation (even if it's a small one). It was trivial Gaussian integration. http://en.wikipedia.org/wiki/Gaussian_quadrature I do not claim code is optimal or anything, but it's line for line. [snip] on my machine (Haswell i5) I get scala as taking 1.6x as long as the ldc version. I don't know scala though, I compiled using -optimise, are there other arguments I should be using? There is no point in -optimise at least I do not recall using it. What's your JVM ? It should be Oracle's HotSpot not OpenJDK. -- Dmitry Olshansky
Re: DIP69 - Implement scope for escape proof references
Nick Treleaven: This might also make the proposed 'int[$] = [...];' syntax unnecessary. Or might not. The [$] proposal is very refined. Bye, bearophile
Re: DIP69 - Implement scope for escape proof references
Walter Bright: There are probably only a handful of people on the planet who actually understand C++ ref. I wished very hard to avoid that with D ref. When C++ programmers say that D-style ranges can't do everything C++ iterators can do, they seem to miss that sometimes it's a good idea to adopt a simpler language feature, that doesn't cover 100% usages, if it covers 80-90% of the cases, and has a simpler syntax, and simpler semantics to understand for the programmer. (The comment above is not about DIP69). Bye, bearophile
Re: Do everything in Java…
On Sun, Dec 07, 2014 at 04:58:23PM +, via Digitalmars-d wrote: On Sunday, 7 December 2014 at 16:08:27 UTC, H. S. Teoh via Digitalmars-d wrote: Hahaha... you're right, I'm not thinking straight. OK, so it's 40*50 = 200 man-hours per week. Hmph... I'm about two orders of magnitude off. log10(40/8) = 0.6989700043360189 orders of magnitude… Yes, and now I get to hang 0.3948500216800940239 of my head in shame instead. T -- Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. -- Gene Wirchenko
Re: std::string responsible for half the allocations in chrome
On Sun, Dec 07, 2014 at 06:08:51PM +, Sean Kelly via Digitalmars-d wrote: On Saturday, 6 December 2014 at 16:32:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton Wakeling via Digitalmars-d wrote: On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ? Immutable, because then you can freely use slices as substrings without worrying that the substring you hand to function X might get modified by unrelated function Y while function X is not quite done with processing it yet. At the same time, immutable means that if you do need to do any string manipulation, you need to copy the string first. I think whether immutable means more or less allocations than mutable/const is actually more dependent on application design than anything, and some applications can't afford the copying that using immutable requires. True, but at least if mutation is expected you could use char[] instead, which still allows cheap slicing and appending without invalidating other references to the data. In C, people pass char* everywhere without any indication of whether mutation will be expected or not (const char* is sadly not consistently used outside the stdlib... and in some places even in the stdlib). This means that whenever you're unsure, you have to strdup() yet again. D's string isn't 100% ideal though... there *are* some places in Phobos that traffick in string even where const(char)[] or char[] might make more sense. One side-effect of this is certain functions being overly eager in heap allocation because they take string but have to mutate the input, so they have to dup/idup to make the change and then return it -- again as string. The next function that has to do something else with that return value will again have to allocate all over again. T -- Живёшь только однажды.
Re: Help with d_language subreddit on Reddit
On 12/7/2014 4:34 AM, Peter Alexander wrote: We don't need the subreddit. We have these forums. Rust has their own forum, but it's for implementers. Most of their discussions/announcements happen at reddit. That's why it is more active and maintained. We already have an active forum here for everything, so we don't need another one. No point splitting the community. Just leave the qznc bot their to cross post announcements, but I don't think there's any value in trying to have, or promote, two separate forums. It's a good point, but I do feel that we should at least add some helpful links like in the rust subreddit sidebar.
Re: DIP69 - Implement scope for escape proof references
On 12/7/2014 2:58 PM, bearophile wrote: When C++ programmers say that D-style ranges can't do everything C++ iterators can do, they seem to miss that sometimes it's a good idea to adopt a simpler language feature, that doesn't cover 100% usages, if it covers 80-90% of the cases, and has a simpler syntax, and simpler semantics to understand for the programmer. I agree, but it's hard to find that sweet spot. I think Java definitely went too far, and Go went too far for my taste. (The comment above is not about DIP69). Yes, it is :-)
Re: Find symbol in unknown module at compile time?
On Sun, 07 Dec 2014 21:44:51 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: I would like to be able to reflect private members though... Is there any way to give a module private access to an unrelated module? nope. and i hope there will be no such thing. ;-) I understand that packages are meant to solve this problem for regular code, but given the fact that D has such a comprehensive reflection system, it would be nice to have this special case. you either want to inspect something from the outside and then it's not private, or it's private and invisible to the strangers. by introducing hacks you killing the protection idiom altogether. if you need to modify the module you want to inspect to insert pragma... well, make the necessary things 'package'-protected and and inspector to the package: you modified the module anyway. if you want to allow external pragmas that allows poking private module data... well, just make everything in that module public, you just killed the whole protection thing. ;-) what i really want to say is that if you need to even know about private members from the outside of the module, something is very-very wrong. dump the idea that reflection can do at least *something* with private parts. that's bad. that's dangerous. that's dirty. *nobody* can know anything about object internals except the object and his close friends living in the same module. either don't make it private or pretend that it's non-existant for the outside world. signature.asc Description: PGP signature
Re: Recent repetitive spam?
On Sun, 7 Dec 2014 20:55:04 +0530 Shriramana Sharma via Digitalmars-d digitalmars-d@puremagic.com wrote: I wonder if it is me or everyone is receiving some sort of kitchen-related spam via the mailing list? not that many. something about 5-6 letters withing a month (at it's maximum). The email ID or keywords they are using seem to be relatively predictable and unrelated to programming so I wonder whether the listadmin hasn't had the time to kick out this intruder? i see that my local spam filter started to catching that crap. i believe that after some more messages i will not see that anymore. maybe you can try to use local bayesian filter too? this isn't the list-wide solution, but at least it can clean your mail. ;-) signature.asc Description: PGP signature
Re: Help with d_language subreddit on Reddit
On Sunday, 7 December 2014 at 12:35:00 UTC, Peter Alexander wrote: We don't need the subreddit. We have these forums. Rust has their own forum, but it's for implementers. Most of their discussions/announcements happen at reddit. That's why it is more active and maintained. We already have an active forum here for everything, so we don't need another one. No point splitting the community. Just leave the qznc bot their to cross post announcements, but I don't think there's any value in trying to have, or promote, two separate forums. Personally I feel like the more the merrier.
problem with size_t and an easy solution
Hello. i don't like `size_t`. for many month i avoied using it wherever that was possible, 'cause i feel something wrong with it. and today i found the soultion! let's see how other D types are named: `int`, `uint`, `byte` (oh, well, this name sux), `ulong`. see the pattern? so i decided to rename `size_t` to `usize`. and you know what? it immidiately started to be familiar. like a thing that was always here, simply dressed in patches. let's face it: that ugly '_t' is alien to D. this is an ugly leftover from C, and this leftover is nonsence. it will not really help anyone, but it immideately turns D code to badly-looking crap. see for yourself: size_t countSomeElements(); and usize countSomeElements(); `size_t` looking like an alien here, ruining all the style. i propose to introduce `usize` and `sptrdiff` along with those '_t' uglyness, and then slowly migrate all the code to the new names. yes, this is another cosmetic issue, but let me tell you that such purely cosmetic things are really important for those who just starting to learn the language. it's impossible to write nice D code with `size_t`: we have either alias it each time or use `uint`/`ulong` to make our code looks good. really, i've seen people who using `uint` instead of `size_t`, 'cause with size_t my code looks ugly, and i tired of aliasing that shit every time. ah, yep, their code sux for 64 bits, but: i know that 64-bit size_t is... 64-bit. i'll fix that later, maybe. uglyness leads to bad code. let's kill `size_t` for good! p.s. some of you may think that i'm trolling. i can assure you that this post is not trolling, this is just another try to talk about purely cosmetic issues and how they hurts the language, especially for beginners. when beginner see such pure cosmetic issue, he starting to think that the whole language is a mess: hey, this is such easy to fix, but they never bother to... i bet the other parts of the language are even worse. and you know what? it's enough to make such mistake two or three times to make people believe that D is a dirty and hackish language without clear style. this is gly is *the* *argument*. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 01:30:35 UTC, ketmar via Digitalmars-d wrote: Hello. i don't like `size_t`. for many month i avoied using it wherever that was possible, 'cause i feel something wrong with it. and today i found the soultion! let's see how other D types are named: `int`, `uint`, `byte` (oh, well, this name sux), `ulong`. see the pattern? so i decided to rename `size_t` to `usize`. and you know what? it immidiately started to be familiar. like a thing that was always here, simply dressed in patches. let's face it: that ugly '_t' is alien to D. this is an ugly leftover from C, and this leftover is nonsence. it will not really help anyone, but it immideately turns D code to badly-looking crap. see for yourself: size_t countSomeElements(); and usize countSomeElements(); `size_t` looking like an alien here, ruining all the style. i propose to introduce `usize` and `sptrdiff` along with those '_t' uglyness, and then slowly migrate all the code to the new names. yes, this is another cosmetic issue, but let me tell you that such purely cosmetic things are really important for those who just starting to learn the language. it's impossible to write nice D code with `size_t`: we have either alias it each time or use `uint`/`ulong` to make our code looks good. really, i've seen people who using `uint` instead of `size_t`, 'cause with size_t my code looks ugly, and i tired of aliasing that shit every time. ah, yep, their code sux for 64 bits, but: i know that 64-bit size_t is... 64-bit. i'll fix that later, maybe. uglyness leads to bad code. let's kill `size_t` for good! p.s. some of you may think that i'm trolling. i can assure you that this post is not trolling, this is just another try to talk about purely cosmetic issues and how they hurts the language, especially for beginners. when beginner see such pure cosmetic issue, he starting to think that the whole language is a mess: hey, this is such easy to fix, but they never bother to... i bet the other parts of the language are even worse. and you know what? it's enough to make such mistake two or three times to make people believe that D is a dirty and hackish language without clear style. this is gly is *the* *argument*. I would like if usize wasn't implictly convertable to uint or ulong
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 01:50:44 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
I would like if usize wasn't implictly convertable to uint or
ulong
me too, but this change is too radical. it will not break any of my
own code ('cause i used to write casts for that stupid 64-bit systems to
shut up), but i doubt that other people will agree with such change.
signature.asc
Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 02:04:58 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 01:50:44 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
I would like if usize wasn't implictly convertable to uint or
ulong
me too, but this change is too radical. it will not break any
of my
own code ('cause i used to write casts for that stupid 64-bit
systems to
shut up), but i doubt that other people will agree with such
change.
Why not keep size_t implictly convertable but disallow it for
usize.
Re: problem with size_t and an easy solution
On Mon, 08 Dec 2014 02:29:49 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 8 December 2014 at 02:04:58 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 08 Dec 2014 01:50:44 +
Freddy via Digitalmars-d digitalmars-d@puremagic.com wrote:
I would like if usize wasn't implictly convertable to uint or
ulong
me too, but this change is too radical. it will not break any
of my
own code ('cause i used to write casts for that stupid 64-bit
systems to
shut up), but i doubt that other people will agree with such
change.
Why not keep size_t implictly convertable but disallow it for
usize.
'cause there is no such type as `size_t` (and `usize` for that matter).
`size_t` is defined as the alias for the corresponding unsigned
integral type, and so i did with `usize`.
so both `size_t` and `usize` are actually `uint`/`ulong`. so they not
just convertible, they are the same type.
signature.asc
Description: PGP signature
Re: Find symbol in unknown module at compile time?
if you want to allow external pragmas that allows poking private module data... well, just make everything in that module public, you just killed the whole protection thing. ;-) This is what I mean, but I don't think it would 'kill' anything. It's not like I'm suggesting that cast(public) be added to the language. I'm suggesting a special case pragma or something that can be added to a module that is responsible for reflection, to allow that module to do it's job. I don't think what I am suggesting is that radical. It's basically the same thing as casting away const. Also, I don't think the problem is the feature, so much as the programmers that would start adding '#pragma privileged' to all their files without a good reason. what i really want to say is that if you need to even know about private members from the outside of the module, something is very-very wrong. For a publicly released library, I would agree, but if you wanted to use runtime reflection to tweak some variables during the development process, this would save you the trouble of having to modify your interface to allow it.
Re: Find symbol in unknown module at compile time?
On Mon, 08 Dec 2014 02:58:45 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: if you want to allow external pragmas that allows poking private module data... well, just make everything in that module public, you just killed the whole protection thing. ;-) This is what I mean, but I don't think it would 'kill' anything. It's not like I'm suggesting that cast(public) be added to the language. I'm suggesting a special case pragma or something that can be added to a module that is responsible for reflection, to allow that module to do it's job. i believe that if you need to access some private module thingys, that thingys are made private erroneously. I don't think what I am suggesting is that radical. It's basically the same thing as casting away const. i'm still sure that compiler should forbid such casts. there should be no way to remove 'const' after it's sticked. Also, I don't think the problem is the feature, so much as the programmers that would start adding '#pragma privileged' to all their files without a good reason. but they will. ;-) you know, just in case or to speedup the things. btw, i think that default module protection must be private, not public. having module imports as private by default but everything else as public is confusing. what i really want to say is that if you need to even know about private members from the outside of the module, something is very-very wrong. For a publicly released library, I would agree, but if you wanted to use runtime reflection to tweak some variables during the development process, this would save you the trouble of having to modify your interface to allow it. if you need to tweak something private... well, it's not private anymore, there must be public API to do that. that API can be version'd out later (or documented). signature.asc Description: PGP signature
Re: Find symbol in unknown module at compile time?
While I hear a lot of experienced programmers take this point of view, I still don't really understand or agree with it. I believe a good language should facilitate good design, but I don't think it should force it. I imagine this type of principal may simplify code review for large projects, but haven't experienced it first hand. Anyways, Thanks for the input ;)
Re: Do everything in Java…
On Sunday, 7 December 2014 at 15:46:59 UTC, John Colvin wrote: On Sunday, 7 December 2014 at 15:44:55 UTC, Ola Fosheim Grøstad wrote: On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote: Haha, oops. I meant 40 hours * 5 days a week * 50 people = 1 man hours of work. Still a lot. The long work hours is why the US is ahead of Europe. IIRC the country with longest working hours in the EU is Greece. On the same statistical oddity, France has an extremely high productivity per hour. Mostly because people work longer than the official hours. These stats are so screwed up by the different policies in each country and the way people cheat them that I'm not sure we can conclude much from them.
Re: D Meetup in SF?
On Saturday, 6 December 2014 at 13:54:23 UTC, Vic wrote: On Saturday, 6 December 2014 at 01:37:03 UTC, deadalnix wrote: On Friday, 5 December 2014 at 20:08:30 UTC, Vic wrote: http://www.meetup.com/D-Lang-Sillicon-Valley in Sunnyvale. First meeting in Jan., and then every 6 weeks Room holds 2 - 500, sponsored by Apakau Looking for co-organizers to meet w/ ahead of first meeting. I can go over a step by step of setting up Eclipse, DUB, vibe-D at fist meeting and take it from there. Is that new ? I was unaware of this. Not sure I'll be able to come as I have no car, but I'll try to figure out something. If you Cal-Train, we will pick up at station. Awesome. Then I'm most likely in. If not that one the next one.
Re: Do everything in Java…
On Monday, 8 December 2014 at 04:09:19 UTC, deadalnix wrote: On Sunday, 7 December 2014 at 15:46:59 UTC, John Colvin wrote: On Sunday, 7 December 2014 at 15:44:55 UTC, Ola Fosheim Grøstad wrote: On Sunday, 7 December 2014 at 15:41:12 UTC, H. S. Teoh via Digitalmars-d wrote: On the same statistical oddity, France has an extremely high productivity per hour. Mostly because people work longer than the official hours. Well, that is true. If 24 hours aren't enough (to finish the task), then you could work at night, too.
Re: Symbol lookup rules and imports
On 12/3/14 8:00 AM, H. S. Teoh via Digitalmars-d wrote: I'm finding it harder and harder to accept Walter's stance that symbol lookups should be kept simple and free from complications and convoluted corner cases, etc.. Except that it is*already* full of convoluted pitfalls and corner cases you must avoid, as illustrated above. I wish we would just acknowledge that the current symbol lookup / import rules (or at least the implementation thereof) are inadequate, and find a clean solution to this long-standing issue, instead of hoping that denying the problem will somehow, magically, make it all go away. I agree we need to take a closer look at name lookup now that local imports are becoming more popular. This may be one of those cases in which simpler language rules transfer complexity to the user. Andrei
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 12/3/14 10:10 AM, Martin Nowak wrote: On Tuesday, 2 December 2014 at 17:10:12 UTC, Jacob Carlborg wrote: DMD 2.066.1 is missing in the Digitalmars FTP. The release candidates are present but the final release is missing. This breaks DVM. I asked several times that it gets uploaded, but never received any response. Let's try it again. Binaries can be found here https://dlang.dawg.eu/downloads/dmd.2.066.1/ or here http://downloads.dlang.org/releases/2014/. Please mirror them to ftp.digitalmars.com. I'm in Australia with limited connectivity (bandwidth cap etc). Walter? -- Andrei
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 2014-12-08 08:12, Andrei Alexandrescu wrote: I'm in Australia with limited connectivity (bandwidth cap etc). Walter? Walter has already taken care of it. -- /Jacob Carlborg
Re: Accented Characters and Counting Syllables
On Saturday, 6 December 2014 at 22:37:19 UTC, Nordlöw wrote: Given the fact that static assert(é.length == 2); I was surprised that static assert(é.byCodeUnit.length == 2); static assert(é.byCodePoint.length == 2); string already iterates over code points. So byCodePoint doesn't have to do anything on it, and it just returns the same string again. string's .length is the number of code units. It's not compatible with the range primitives. That's why hasLength is false for string (and wstring). Don't use .length on ranges without checking hasLength. So, while é.byCodeUnit and é.byCodePoint have equal `.length`s, they have different range element counts.
Re: Sorted Array Wrapper Range
On Saturday, 6 December 2014 at 14:50:02 UTC, Nordlöw wrote: On Saturday, 6 December 2014 at 14:14:18 UTC, Tobias Pankrath wrote: Because a RandomAccessRange has no means to grow in general. Compare your proposed wrapper to http://dlang.org/phobos/std_container.html#.BinaryHeap So what should the basic operations in a SortedRange wrapper template be? And how should the wrapped type be restricted? Something like this https://github.com/Panke/phobos/blob/std_container_sorted/std/container/sorted.d It should additionally support c.remove(r), c.removeKey(k), opIn and insertFront/removeFront if the underlying store supports them. But that's pretty much it, I'd say. Sadly, the unittest using an Array!int as store does not compile because of of linker errors. I'm using rdmd -unittest -main std/container/sorted.d but that does not work with std/container/array.d as well. So, my setup seems to be broken.
Re: Accented Characters and Counting Syllables
On Saturday, 6 December 2014 at 22:37:19 UTC, Nordlöw wrote: static assert(é.byCodePoint.length == 2); Huh? Why is byCodePoint.length even defined?
Re: Accented Characters and Counting Syllables
On Sunday, 7 December 2014 at 13:24:28 UTC, Marc Schütz wrote: On Saturday, 6 December 2014 at 22:37:19 UTC, Nordlöw wrote: static assert(é.byCodePoint.length == 2); Huh? Why is byCodePoint.length even defined? because string has ElementType dchar (i.e. it already iterates by codepoint), which means that byCodePoint is just the identity function.
Re: Accented Characters and Counting Syllables
On Sunday, 7 December 2014 at 13:24:28 UTC, Marc Schütz wrote:
On Saturday, 6 December 2014 at 22:37:19 UTC, Nordlöw wrote:
static assert(é.byCodePoint.length == 2);
Huh? Why is byCodePoint.length even defined?
import std.uni;
pragma(msg, typeof(é.byCodePoint));
= string
Something's very broken...
It's this definition in std.uni:
Range byCodePoint(Range)(Range range)
if(isInputRange!Range is(Unqual!(ElementType!Range) ==
dchar))
{
return range;
}
`Unqual!(ElementType!string)` is indeed `dchar` because of
auto-decoding.
Filed as bug:
https://issues.dlang.org/show_bug.cgi?id=13829
Re: Accented Characters and Counting Syllables
On Saturday, 6 December 2014 at 23:11:49 UTC, H. S. Teoh via Digitalmars-d-learn wrote: This is a Unicode issue. What you want is neither byCodeUnit nor byCodePoint, but byGrapheme. A grapheme is the Unicode equivalent of what lay people would call a character. A Unicode character (or more precisely, a code point) is not necessarily a complete grapheme, as your example above shows; it's just a numerical value that uniquely identifies an entry in the Unicode character database. T Ok, thanks. I just noticed that byGrapheme() lacks bidirectional access. Further it also lacks graphemeStrideBack() in complement to graphemeStride()? Similar to stride() and strideBack(). Is this difficult to implement?
Re: Accented Characters and Counting Syllables
On Sun, Dec 07, 2014 at 02:30:13PM +, Nordlöw via Digitalmars-d-learn wrote: On Saturday, 6 December 2014 at 23:11:49 UTC, H. S. Teoh via Digitalmars-d-learn wrote: This is a Unicode issue. What you want is neither byCodeUnit nor byCodePoint, but byGrapheme. A grapheme is the Unicode equivalent of what lay people would call a character. A Unicode character (or more precisely, a code point) is not necessarily a complete grapheme, as your example above shows; it's just a numerical value that uniquely identifies an entry in the Unicode character database. T Ok, thanks. I just noticed that byGrapheme() lacks bidirectional access. Further it also lacks graphemeStrideBack() in complement to graphemeStride()? Similar to stride() and strideBack(). Is this difficult to implement? Not sure, but I wouldn't be surprised if it is. Unicode algorithms are generally non-trivial. T -- Who told you to swim in Crocodile Lake without life insurance??
Re: threading issues with D - C - Python
On Saturday, 6 December 2014 at 00:40:49 UTC, Ellery Newcomer wrote: On 12/04/2014 10:55 PM, Ellery Newcomer wrote: I guess tomorrow I can try messing around with thread_attachThis, as the fullcollect happening in #2 might be screwing with python data. But you aren't really passing anything from python to d or vice versa, so I'm not sure why the gc would need to know about the python threads. by gum, thread_attachThis and thread_detachThis fix the issue! now to figure out how to use them in the general case. This is great.. Thank you. I'm looking forward to being able to try the finished result.
Re: threading issues with D - C - Python
On 12/07/2014 03:12 PM, Michael wrote: On Saturday, 6 December 2014 at 00:40:49 UTC, Ellery Newcomer wrote: On 12/04/2014 10:55 PM, Ellery Newcomer wrote: I guess tomorrow I can try messing around with thread_attachThis, as the fullcollect happening in #2 might be screwing with python data. But you aren't really passing anything from python to d or vice versa, so I'm not sure why the gc would need to know about the python threads. by gum, thread_attachThis and thread_detachThis fix the issue! now to figure out how to use them in the general case. This is great.. Thank you. I'm looking forward to being able to try the finished result. It would be great if there were some convenient hook in python to stick these calls. Near as I can tell, there isn't. That leaves you with either explicitly calling attach and detach with an exposed api, or pyd obsessively checking whether the current thread is registered. Actually, I suppose with a thread local flag the latter wouldn't be too bad. Mind if I incorporate your example into pyd's test suite?
[Issue 6256] [patch] std.algorithm.map does not support static arrays and has 'length' for narrow strings.
https://issues.dlang.org/show_bug.cgi?id=6256 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #6 from Jonathan M Davis issues.dl...@jmdavisprog.com --- If you want to argue for a special overload for static arrays, please open a new enhancement request. However, in general, I think that supporting static arrays with range-based functions is just asking for trouble, because they're not ranges (e.g. popFront does not and cannot work for them). So, I think that benchmarks which show a significant improvement with static arrays being special-cased would be required for it to be worth considering. --
[Issue 13827] New: Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827
Issue ID: 13827
Summary: Internal Compiler Error: null field
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
mixin template VectorImpl() {
this(A...)(auto ref in A args) {
uint k;
foreach(ref v; args)
flat[k++] = cast(T)v;
}
}
struct Matrix(T, uint _M, uint _N = _M) {
enum {
M = _M, //rows
N = _N, //columns
C = M * N, // count of elements
isVector = N == 1 || M == 1,
}
private static defaultMatrix() {
T arr[M][N] = void;
foreach(i, ref v; arr) {
v[] = 0;
static if(M == N) v[i] = 1;
}
return arr;
}
union {
T[N][M] A = defaultMatrix;
T[C] flat;
}
mixin VectorImpl;
}
alias Vector(T, uint M) = Matrix!(T, 1, M);
alias Vector3 = Vector!(float, 3);
enum isMatrix(T) = is(T == Matrix!A, A...);
template isVector(T) {
static if(isMatrix!T) enum isVector = T.isVector;
else enum isVector = false;
}
enum S = Vector3(1, 2, 3);
void main() {
}
main.d(6): Error: Internal Compiler Error: null field flat
main.d(6): Error: cannot determine length of this.flat at compile time
main.d(50):called from here: Matrix([[0.00F, 0.00F,
0.00F]], ).this(1, 2, 3)
Maybe one can reduce it more. This code compiles on 2.066.
--
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827
--- Comment #1 from Temtaime temta...@gmail.com ---
Reduced more:
struct Matrix(T, uint N) {
private static defaultMatrix() {
T arr[N];
return arr;
}
union {
T[N] A = defaultMatrix;
T[N] flat;
}
this(A...)(auto ref in A args) {
uint k;
foreach(ref v; args)
flat[k++] = cast(T)v;
}
}
enum S = Matrix!(int, 3)(1, 2, 3);
--
[Issue 13828] New: std.random not @nogc aware
https://issues.dlang.org/show_bug.cgi?id=13828 Issue ID: 13828 Summary: std.random not @nogc aware Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: alil...@gmail.com std.random doesn't contain @nogc. I stumbled upon it since I have @nogc audio callbacks that involves noise generator that calls std.random.uniform, and this function isn't @nogc. --
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org ---
struct Matrix(T) {
private static defaultMatrix() {
T arr[3];
return arr;
}
union {
T[3] A = defaultMatrix;
T[3] flat;
}
this (T v) {
flat[0] = v;
}
}
enum S = Matrix!int(42);
--
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827 --- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org --- p.s. i'm not even sure that this is supposed to work in compile-time. --
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827 --- Comment #4 from Temtaime temta...@gmail.com --- Thanks. It worked in 2.066. :) P.S. +1 for 42 --
[Issue 13829] New: std.uni.byCodePoint for strings has length
https://issues.dlang.org/show_bug.cgi?id=13829
Issue ID: 13829
Summary: std.uni.byCodePoint for strings has length
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: schue...@gmx.net
import std.uni;
static assert(__traits(compiles, é.byCodePoint.length));
pragma(msg, typeof(é.byCodePoint)); // = string
The problem is that `byCodePoint(w?string.init)` returns its argument
(string/wstring) which of course defines `length`, instead of a wrapper that
doesn't.
The reason is once again auto-decoding. In std/uni.d(6644):
Range byCodePoint(Range)(Range range)
if(isInputRange!Range is(Unqual!(ElementType!Range) == dchar))
{
return range;
}
`Unqual!(ElementType!string)` is of course `dchar`.
Brought up in this discussion:
http://forum.dlang.org/thread/ovzcetxbrdblpmyiz...@forum.dlang.org#post-ovzcetxbrdblpmyizdjr:40forum.dlang.org
--
[Issue 13829] std.uni.byCodePoint for strings has length
https://issues.dlang.org/show_bug.cgi?id=13829 --- Comment #1 from Marc Schütz schue...@gmx.net --- In case it wasn't clear: For strings and wstrings, determining the actual number of code points is an O(n) operation and should therefore not be available via length at all. The current implementation returns the number of code units, not of code points. --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 Marc Schütz schue...@gmx.net changed: What|Removed |Added CC||schue...@gmx.net --- Comment #3 from Marc Schütz schue...@gmx.net --- FWIW, I can't reproduce it on x86_64 Linux with DMD master. I've even raised the multiplier up to 128000, and RES stayed at a modest 19MB. --
[Issue 13420] double.nan unusable as AA key
https://issues.dlang.org/show_bug.cgi?id=13420 --- Comment #12 from Marc Schütz schue...@gmx.net --- (In reply to Martin Nowak from comment #10) Maybe the AA implementation should assert that keys added to it should be equal to themselves. Sorry for breaking your code, but this check seems exaggerated. An AA implementation has to rely on a working equality comparison and hash. As floats are builtin types we should special case the AA implementation to perform some extra checks, e.g. disallow NaN as key value. See bug 13581 for an enhancement request. I don't think we should special-case floats. As you said, AA has to rely on a working equality comparison and hash, and the way to verify that is to use an assert. --
[Issue 6196] with statement with single statement breaks linking
https://issues.dlang.org/show_bug.cgi?id=6196 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Andrej Mitrovic andrej.mitrov...@gmail.com --- (In reply to hsteoh from comment #8) Seems to have been fixed in git HEAD; could you re-test? Yeah I can confirm it works now.. although I'm worried it's just a side-effect of any import changes we might have made within std.stdio, and the actual problem not being properly fixed. We'll see if it resurfaces. --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 --- Comment #4 from Ben Grabham dl...@chillichef.com --- The initial test was on: DMD64 D Compiler v2.066.1 I just tested it on (dmd master): DMD v2.067-devel-8ff302a DEBUG It takes up insane amounts of memory on both. (only tested on mac) --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 Ben Grabham dl...@chillichef.com changed: What|Removed |Added CC||dl...@chillichef.com --- Comment #9 from Ben Grabham dl...@chillichef.com --- I just hit this bug too and I wasn't so fortunate as to realise that classes that implement an interface need override but classes that extend and abstract class which implements an interface must not have the override attribute. Please make it consistent! --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de --- AFAIK the heap on OSX starts 0x 0x1__, so your b members create false pointers into the memory chunks into the arrays allocated in the while(true) loop. That's why they are never collected. You might want to try one of the proposed precise GCs: https://github.com/D-Programming-Language/druntime/pull/1022 or https://github.com/D-Programming-Language/druntime/pull/1057 --
[Issue 1829] Inline assembler cannot get label addresses
https://issues.dlang.org/show_bug.cgi?id=1829 Orvid King blah38...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||blah38...@gmail.com Resolution|--- |FIXED --- Comment #10 from Orvid King blah38...@gmail.com --- It appears I failed to add the word fixes to the description of the commit, so this wasn't auto-marked as resolved when the PR was merged. --
[Issue 13830] New: Circular dependency between interface and implementation segfault the compiler
https://issues.dlang.org/show_bug.cgi?id=13830
Issue ID: 13830
Summary: Circular dependency between interface and
implementation segfault the compiler
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pro.mathias.l...@gmail.com
I tried to use the CRTP in D to generate an interface at compile time based on
another interface and the implementation. Unfortunately, it segfaulted the
compiler.
import std.stdio, std.traits;
template RESTServer(I, Impl) {
private abstract class IRESTServer/* : I*/ {
//final override void test() { assert(0); }
void test(Context ctx);
}
int abuseTheCompiler() {
foreach (method; __traits(allMembers, Impl)) {
foreach (overload; MemberFunctionsTuple!(Impl, method))
{
pragma(msg, __traits(identifier, overload));
}
}
return 42;
}
static assert(abuseTheCompiler());
alias RESTServer = IRESTServer;
}
struct Context { string ip; }
interface MyAPI { void test(); }
class MyAPIImpl : RESTServer!(MyAPI, MyAPIImpl) {
override:
void test(Context ctx) {
writeln(ctx.ip);
}
}
void main() {
auto c = new MyAPIImpl();
c.test(Context(10.24.50.42));
}
Question: should such code be valid ? It allows an interesting pattern for code
generators.
--
[Issue 12971] Missing REX prefix for 8 bit register access
https://issues.dlang.org/show_bug.cgi?id=12971 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added Summary|DMD inline asm outputs |Missing REX prefix for 8 |wrong AND instruction |bit register access --- Comment #3 from safety0ff.bugz safety0ff.b...@gmail.com --- Likely affects SPL, BPL, SIL and DIL since they all require REX. --
[Issue 1829] Inline assembler cannot get label addresses
https://issues.dlang.org/show_bug.cgi?id=1829 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #11 from bearophile_h...@eml.cc --- (In reply to Orvid King from comment #10) It appears I failed to add the word fixes to the description of the commit, so this wasn't auto-marked as resolved when the PR was merged. I'd like to see somewhere a working example of jump table in D. --
[Issue 6256] [patch] std.algorithm.map does not support static arrays and has 'length' for narrow strings.
https://issues.dlang.org/show_bug.cgi?id=6256 --- Comment #7 from bearophile_h...@eml.cc --- (In reply to Jonathan M Davis from comment #6) So, I think that benchmarks which show a significant improvement with static arrays being special-cased would be required for it to be worth considering. I agree. --
[Issue 13831] New: DMD crash
https://issues.dlang.org/show_bug.cgi?id=13831
Issue ID: 13831
Summary: DMD crash
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: mrsmit...@yandex.ru
Crashes both on windows and linux, both m32 and m64.
Tested with 2.066, 2.066.1, master
---
struct Vector()
{
}
struct ChunkCoord
{
union
{
struct
{
short x;
}
Vector!() vector;
}
}
struct Chunk
{
this(ChunkCoord)
{
coord = coord;
}
ChunkCoord coord;
static Chunk* unknownChunk = new Chunk(ChunkCoord());
}
---
--
[Issue 13831] DMD crash
https://issues.dlang.org/show_bug.cgi?id=13831 Mr. Smith mrsmit...@yandex.ru changed: What|Removed |Added Keywords||ice --
[Issue 13831] DMD crash
https://issues.dlang.org/show_bug.cgi?id=13831 --- Comment #1 from Mr. Smith mrsmit...@yandex.ru --- Created attachment 1459 -- https://issues.dlang.org/attachment.cgi?id=1459action=edit Crash dump --
[Issue 13830] Circular dependency between interface and implementation segfault the compiler
https://issues.dlang.org/show_bug.cgi?id=13830 Dicebot pub...@dicebot.lv changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #1 from Dicebot pub...@dicebot.lv --- Does changing `Impl` to alias parameter instead of type parameter change anything? Anyway, compiler shouldn't crash. Please paste here exact ICE error line too. --
[Issue 13668] [ICE] unable to compile __traits(allMembers...)
https://issues.dlang.org/show_bug.cgi?id=13668 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #3 from Kenji Hara k.hara...@gmail.com --- *** Issue 13830 has been marked as a duplicate of this issue. *** --
[Issue 13830] Circular dependency between interface and implementation segfault the compiler
https://issues.dlang.org/show_bug.cgi?id=13830 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara k.hara...@gmail.com --- The segfault is a dup of issue 13668, and fortunately it's already fixed in git-head. *** This issue has been marked as a duplicate of issue 13668 *** --
[Issue 13832] New: delegates that return ref do not output correctly to .di file
https://issues.dlang.org/show_bug.cgi?id=13832 Issue ID: 13832 Summary: delegates that return ref do not output correctly to .di file Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com The source code: alias ref int delegate() dg_t; when compiled with: dmd -c -H test.d yields a .di file with: alias int delegate() dg_t; in it. The 'ref' got dropped, but it is still there as part of the type. --
[Issue 5050] No way to declare delegates with ref return
https://issues.dlang.org/show_bug.cgi?id=5050 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- You can do it with an alias: alias ref int delegate(ref int) dg_t; dg_t r = ...; --
[Issue 12114] buildNormalizedPath shouldn't normalize current path to empty string
https://issues.dlang.org/show_bug.cgi?id=12114 Thibaut CHARLES cro...@gmail.com changed: What|Removed |Added CC||cro...@gmail.com --- Comment #2 from Thibaut CHARLES cro...@gmail.com --- What should happen if you do buildNormalizedPath(., ) ? --
