Re: dmd makes D appear slow
On 30 May 2015 05:25, "ketmar via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote: > > > * I don't mean to down-play GDC, but it can't give us Windows or iOS, > > which are critical targets. > > just to note: ARM is supported in GDC (althru i never tested that support > myself), and there are semi-official windows builds of GDC. > > so GDC can give us windows support (it's simply not required by many GDC > users for the time), but this is relatively easy to fix. > When he says Windows, he means MSVC, gcc backend will never support interfacing that ABI (at least I see no motivation as of writing).
Re: dlang.org build broken
On Friday, 29 May 2015 at 21:56:43 UTC, Steven Schveighoffer wrote: And BTW, how can we get the ddoc build to be part of the auto tester? Not as good as testing PRs, but I added an hourly cronjob to the staging site. At least now I'll know if something we merged broke building the website.
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 00:50:39 UTC, Steven Schveighoffer wrote: I suggest first we build a library AA that sits beside real AA, even if it doesn't . Then we create a test suite to prove that the library AA can be a drop in replacement. Then replace it :) Writing the AA is NOT the problem, but I doubt we can get compatible enough to replace the built-in AA. Rather it'll require to deprecate a few built-in AA semantics and adding operator and literal extensions for the library type. Hence the proposal to start with a HQ library AA and incrementally converge them.
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 01:32:26 UTC, IgorStepanov wrote:
- attributes
We will able to deprecate attribute violations in transitional
version (with vtbl).
Yes, we'd have to deprecate attribute issues of the built-in AA
before we can switch.
Maybe that's already to disruptive.
- literals (especially polysemous initializers, i.e.
ubyte[ubyte] aa = [0:1, 1:2])
Yes, this is the first main trouble.
We could possibly make the array of types polysemeous as well and
deduce the type from the constructor argument.
- implicit tail const conversion Val[Key] -> const(Val)[Key]
May be we may add "alias this"-es for all all those variants?
Something like ...
struct AA(K, V)
{
alias getCKeyMval this;
alias getMKeyCval this;
alias getCKeyCval this;
@property {
ref AA!(const(K), V) getCKeyMval() { return
*cast(typeof(return)*)&this; }
ref AA!(K, const(V)) getMKeyCval() { return
*cast(typeof(return)*)&this; }
ref AA!(const(K), const(V)) getCKeyCval() { return
*cast(typeof(return)*)&this; }
}
}
"overload" by return type? Maybe.
We should start to try to find and solve them.
The list is pretty long, there are lots of unknowns.
I'd rather choose an incremental approach that allows for
intermediate failure.
Re: dmd makes D appear slow
On 30 May 2015 1:41 pm, "weaselcat via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote: >> >> >> Both you and ketmer are evil. >> I'm liking these ideas... >> >> Now we just need some pretty and nice packages for e.g. Windows for ldc with debugger full support and we will be good. >> Last time I looked llvm still needs a lot of work for Windows unfortunately. It may be time to direct some people to help them out ;) > > > LDC seemed to work for the author of the blog on windows after fixing a path issue. After a quick look in the LDC NG, it seems to be mostly(?) working. There's a big difference between compiling a few lines of code, and building a project with particular requirements, dependencies on various foreign libs, cross language linkage, etc. Ldc does a valiant effort, but there are still quite a lot of gaps. I can't hold that against them, the whole dmd community needs to take gdc/ldc as first class considerations.
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 08:50:21 UTC, Vladimir Panteleev wrote: http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1 Sorry, working link: http://forum.dlang.org/post/asvcbsvfcxznwypttojk@192.168.0.1
Re: Proof of concept - library AA
On Friday, 29 May 2015 at 22:41:13 UTC, Martin Nowak wrote: 2. What issues disallows us to implement full library AA? Except .stringof, .mangleof, and other compiler magic. I see only two issues: opIndexCreate and building aa from literals. - error messages - attributes - literals (especially polysemous initializers, i.e. ubyte[ubyte] aa = [0:1, 1:2]) - implicit tail const conversion Val[Key] -> const(Val)[Key] - lots of magic around making Key const - delete aa[key] - lots of other small details (grep for Taarray in src/expression.c) This is a heavily used built-in type, we can't risk a rewrite that breaks lots of code. Not sure how much this is a problem but implicit conversion from null may also be an issue: http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1
Re: shared libs for OSX
On 2015-05-30 01:03, bitwise wrote: No, it opens the image for the main program, even if called from a shared lib. And that void* which is returned is actually a "mach_header*", if I recall correctly. Not sure if this is true. I see, it was mostly a guess. -- /Jacob Carlborg
Re: dlang.org build broken
On 5/30/15 4:06 AM, Vladimir Panteleev wrote: On Friday, 29 May 2015 at 21:56:43 UTC, Steven Schveighoffer wrote: And BTW, how can we get the ddoc build to be part of the auto tester? Not as good as testing PRs, but I added an hourly cronjob to the staging site. At least now I'll know if something we merged broke building the website. thanks! -Steve
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 19:04:05 UTC, weaselcat wrote: Not to mention that GDC and LDC benefit heavily from GCC and LLVM respectively, these aren't exactly one man projects(e.g, Google, Redhat, Intel, AMD etc contribute heavily to GCC and LLVM is basically Apple's baby.) Google, Intel, AMD, Imagination, ... also contribute to LLVM. I think most companies contributing to GCC contribute to LLVM, too. Regards, Kai
Re: dmd makes D appear slow
On Friday, 29 May 2015 at 19:04:05 UTC, weaselcat wrote: Maybe this should be brought up on LDC's issue tracker(that is, slower compilation times compared to dmd.) Although it might have already been discussed. We are aware of this: https://github.com/ldc-developers/ldc/issues/830 Regards, Kai
Re: Why aren't you using D at work?
On 2015-05-29 15:45, rumbu wrote: Tahngo was nice but not supported anymore, I expect these features in phobos. It's supported in the sense that someone always makes sure it works with latest DMD. -- /Jacob Carlborg
Re: Progress on Adam Wilson's Graphics API?
On 30/05/2015 10:28 p.m., Bastiaan Veelo wrote: On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote: Is there any progress on the graphics API Adam Wilson is working on? Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk To my knowledge, it was just too large of a project so was abandoned.
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote: Is there any progress on the graphics API Adam Wilson is working on? Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk
Re: Why aren't you using D at work?
On 2015-05-29 16:03, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: But interoperability matters more. Like, I am likely to use Swift for ios/osx GUI, but need a companion language for the core application engine. C++ is most likely today. If Rust or D makes integration with Swift easy then I would consider a switch. For Swift interfacing with C++ you would need a C or Objective-C layer. With the Objective-C support in D (if it will ever be merged) you could have a more direct interface, but it would be limited to the Objective-C subset. -- /Jacob Carlborg
Re: Why aren't you using D at work?
On 2015-05-28 16:38, Manu via Digitalmars-d wrote: I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? I have never (seriously) suggested to use D at my work and rarely even think about it because I feel it's hard to justify. We're mostly developing the backend part of a web based system, with a lot of services. Currently we're using Ruby for basically all code. There's a couple services written in Go (for performance reason) and one or two legacy systems in Java. We don't have a lot of the issues others have posted here. We don't need to run on Andriod/iOS, we don't need a GUI and our code is not as performance sensitive that we need to use @forceinline or SIMD. The biggest issue I see is the lack of libraries. I have not investigated exactly what we would need but what I do know we need is: * Web framework (vibe.d could be used) * ORM * Connection to Postgres * A good testing framework (i.e. something like RSpec) That's the bare minimum I can think of for now. I know there exist Dub packages for some of these but with Ruby it feels much more "safe" to use. The Ruby community is so much bigger, so many more developers are using the same libraries we're using compared to how it would be in D. It's not like Rails or RSpec are suddenly going to disappear. The GC might be another issue, at least if you look at how many objects are created in Ruby. But in D it would be easier to avoid heap allocations. -- /Jacob Carlborg
stream == range ?
Do the classic streams still make sense when we have Ranges ? finally a stream is an input range that saves, isn't it ?
Re: dmd makes D appear slow
Honestly I've never taken DMD to be "the production compiler". I've always left that to the GNU compilers. GDC has all the magic and years of work with it's backend, so I'm not sure how dmd can compare. As others of said, it's really the frontend that DMD is providing that matters; once you have that you can more or less just stick that onto which ever backend works for you. Though DMD is definitely not entirely useless, I use it all the time, mainly for prototypes, quick builds, and testing libraries. Also if someone is to do speed tests to see how powerful D is, how clueless would they have to be to check only dmd? You don't just compile C++ with MSVC, and then say "Welp, it looks like C++ is just slow and shitty". :P You can probably safely dismiss any speed test that shows you only one compiler. So personally I vote that speed optimizations on DMD are a waste of time at the moment.
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 30 May 2015 at 10:29:44 UTC, Rikki Cattermole wrote: On 30/05/2015 10:28 p.m., Bastiaan Veelo wrote: On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote: Is there any progress on the graphics API Adam Wilson is working on? Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk To my knowledge, it was just too large of a project so was abandoned. But was it a conscious decision to drop it, or did it just die? Would different design decisions have made a difference? What are the lessons that can be learned from Aurora for any future graphics initiatives?
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 1:18 a.m., Bastiaan Veelo wrote: On Saturday, 30 May 2015 at 10:29:44 UTC, Rikki Cattermole wrote: On 30/05/2015 10:28 p.m., Bastiaan Veelo wrote: On Saturday, 3 May 2014 at 09:56:38 UTC, Nordlöw wrote: Is there any progress on the graphics API Adam Wilson is working on? Adam Wilson's DConf '14 talk [1] was an interesting and promising one. After that there were some commits a month later, but nothing after that. I haven't seen discussions or other activity on the graphics front since. Now another DConf has passed, and I wonder what happened to Aurora? Were there technical reasons that it hasn't progressed much further, and if so, can these be addressed? [1] https://youtu.be/PRbK7jk0jrk To my knowledge, it was just too large of a project so was abandoned. But was it a conscious decision to drop it, or did it just die? Would different design decisions have made a difference? What are the lessons that can be learned from Aurora for any future graphics initiatives? From what I can tell, just not enough man power so it just stopped. But the lesson is pretty simple. Start small and dream big. What I'm saying is we really don't have the basic infrastructure for such an amazing project. One day, just not today. Great example, if you wanted to play some music cross platform what D library what you use? Hint good luck, none really exist. What about window creation? Well Devisualization.Window (author) but what would about integration into OSX's menu or Windows notification area? Again you've got a problem.
Re: shared libs for OSX
On Sat, 30 May 2015 05:06:34 -0400, Jacob Carlborg wrote: On 2015-05-30 01:03, bitwise wrote: No, it opens the image for the main program, even if called from a shared lib. And that void* which is returned is actually a "mach_header*", if I recall correctly. Not sure if this is true. I see, it was mostly a guess. Not sure how accurate this code[1] is, but it seems dlopen returns a pointer to the image itself, which has a function machHeader(); http://www.opensource.apple.com/source/dyld/dyld-353.2.1/src/dyldAPIs.cpp dlopen returns magic numbers(RTLD_MAIN_ONLY or RTLD_DEFAULT) if you pass null, and sometimes it "|"s a 1 with the image pointer. So we can't really use it to get at the header. Bit
Bad Sound Quality on Livestreamed Videos
The livestreaming videos just published are really frustrating to watch because lots of stuttering in speech about once every 20 seconds or so and sometimes difficult to here what people say. Where there other recordings done aswell that will be made public soon?
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 08:51:31 UTC, Vladimir Panteleev
wrote:
On Saturday, 30 May 2015 at 08:50:21 UTC, Vladimir Panteleev
wrote:
http://localhost/post/asvcbsvfcxznwypttojk@192.168.0.1
Sorry, working link:
http://forum.dlang.org/post/asvcbsvfcxznwypttojk@192.168.0.1
We may say that AA!(K, V)* should be recognized as V[K] by
compiler. However in this case we will found another problem:
opIndexAssign will unable to allocate memory for the new AA
instance, because it can't modify `this` pointer.
Otherwise, implicit casting _from_ another type is a unsolvable
task now.
Please, remind, why we don't want to add possibility of implicit
casting from another type (not as default constructor behaviour,
of course)?
Something like
struct Foo
{
int a;
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
{
return Foo(val);
}
}
Re: Proof of concept - library AA
struct Foo
{
int a;
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
{
return Foo(val);
}
}
void test(Foo foo, int i)
{
assert(foo.a == i);
}
test(42, 42); ->
test(Foo.opImplicitConstructFrom(42), 42);
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 2:27 a.m., ketmar wrote: On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one.
Re: dmd makes D appear slow
On Sat, 30 May 2015 12:00:57 +, Kyoji Klyden wrote: > So personally I vote that speed optimizations on DMD are a waste of time > at the moment. it's not only waste of time, it's unrealistic to make DMD backend's quality comparable to GDC/LDC. it will require complete rewrite of backend and many man-years of work. and GDC/LDC will not simply sit frozen all this time. signature.asc Description: PGP signature
Re: Progress on Adam Wilson's Graphics API?
On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: > Great example, if you wanted to play some music cross platform what D > library what you use? SDL audio. ;-) signature.asc Description: PGP signature
Re: Bad Sound Quality on Livestreamed Videos
On Saturday, 30 May 2015 at 14:12:10 UTC, Per Nordlöw wrote: The livestreaming videos just published are really frustrating to watch because lots of stuttering in speech about once every 20 seconds or so and sometimes difficult to here what people say. Where there other recordings done aswell that will be made public soon? Yes, the livestream was impromptu and set up by an attendee, the organizers filmed proper video which will be put online eventually.
Re: Progress on Adam Wilson's Graphics API?
On Sun, 31 May 2015 02:28:51 +1200, Rikki Cattermole wrote: > On 31/05/2015 2:27 a.m., ketmar wrote: >> On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: >> >>> Great example, if you wanted to play some music cross platform what D >>> library what you use? >> SDL audio. ;-) > > Okay lets ignore libraries that is not D. Like that one. i bet Devisualisation is using Xlib/XCB, so it's out of competition too, for example. ;-) signature.asc Description: PGP signature
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 2:31 a.m., ketmar wrote: On Sun, 31 May 2015 02:28:51 +1200, Rikki Cattermole wrote: On 31/05/2015 2:27 a.m., ketmar wrote: On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one. i bet Devisualisation is using Xlib/XCB, so it's out of competition too, for example. ;-) Well then lets call a spade a spade and start writing our own operating system shall we? Personally I think it is more reasonable to assume certain libraries will be installed. Such as for Windows user32 and GDI. Where by there is no real alternatives. Like X11 for *nix. In other words, system libraries are fine to use. As you have no real choice in the matter. Now SDL on the other hand, you cannot assume will be installed or available. Unless you want to go bundling that or using static libraries. Still defeats the purpose of expanding D's library base.
Re: Bad Sound Quality on Livestreamed Videos
On Saturday, 30 May 2015 at 14:27:22 UTC, Joakim wrote: Yes, the livestream was impromptu and set up by an attendee, the organizers filmed proper video which will be put online eventually. Nice. Thx.
I won a school game-creation competition!
So hey everyone! I am very happy to say that I won a game-creation contest, called "LBS Game Awards 2015", where I entered with my console game DRPG, which is written in D. I didn't win the best game, but I won the "best newcomer"-award! I am really grateful to all of you who have helped me with the struggles during development. With out you, the D community, I am almost certain the game wouldn't be what it is today! Chatting with the the people on #d has really been amazing, and again, I'm very happy that the whole community is as friendly as it is! Just some shoutouts to people who really have helped me a lot: Adam D. Ruppe, Danol, ketmar, jA_cOp, CyberShadow. You have always helped me when I needed it. Thank you :)
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 30 May 2015 at 14:28:57 UTC, Rikki Cattermole wrote: On 31/05/2015 2:27 a.m., ketmar wrote: SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one. I think that is unnecessarily limiting. I do see your point about distribution, but using C libraries is a common thing with solutions (packaging the DLLs with you, instructing users to install it, using system package managers, etc.) and their availability is one of D's strengths.
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 30 May 2015 at 13:35:47 UTC, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? Hint good luck, none really exist. I'm slowly getting through my simpleaudio.d What about window creation? Well Devisualization.Window (author) but what would about integration into OSX's menu or Windows notification area? Again you've got a problem. My simpledisplay.d can do the Windows notification area. But there's a lot more that needs to get done that I haven't gotten around to yet. If I can ever quit my day job, I'll start going nuts on this again :)
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
I briefly mentioned this at the dconf and thinking about it a bit
more, I think there's only two cases where we want implicit
construction: function argument lists and function return values.
(The syntax doesn't really matter, but I'd do it similar to C++
and just slap an @implicit on a regular constructor).
So:
struct Foo { @implicit this(typeof(null)) {} }
Foo test() {
return null;
}
Right now, that return null would say "cannot implicitly convert
null to Foo". But since it is on a return statement and we have
an implicit constructor, it would automatically rewrite that to
return Foo(null); and be happy with it.
Note that this does NOT change
Foo foo = null;
because that already works with a standard constructor today!
Similarly, foo = null is handled with opAssign. So no change
needed there.
Anyway, the trickier case is function calls:
void test(Foo) {}
test(null); // should do test(Foo(null));
How does that interact with operator overloading? (I'd note that
C++ does this so we could always borrow their rules too.) My
proposal would be that if something matches exactly without
implicit conversion, use that. Otherwise, try the implicit
construction and issue an error if more than one match.
This would work the same as arrays today:
void a(int[]) {}
void a(long[]) {}
void a(typeof(null)) {}
void main() { a(null); }
That compiles. Comment the third line though and get:
b.d(5): Error: b.a called with argument types (typeof(null))
matches both:
b.d(1): b.a(int[] _param_0)
and:
b.d(2): b.a(long[] _param_0)
So I think that's doable and shouldn't break any existing code as
it is a new opt-in keyword. Just will have to watch for
regression bugs...
But that'd take care of the null problem with library AAs and
I could use it to make my var type all the more wild :P
Re: D casually mentioned and dismissed + a suggestion
On 05/13/2015 05:29 AM, Maxim Fomin wrote: On Wednesday, 13 May 2015 at 09:20:36 UTC, Bienlein wrote: "You are making a cool project and we'd like to contribute to it, but we don't know and neither feel like studying this silly D". This is indeed a problem for many newly created languages. Scala has somewhat managed to create its own eco system with Akka, Spark, Spray in a specialized area like concurrent programming and big data. Also because Scala has found some liking in academical circles (e.g. Spark, Scala STM). I don't know how things will look like for Kotlin. Maybe there will be a niche for Android development. For Groovy there is basically only Grails as a killer application. Giving how D is similar to C/C++ I am surprised that non-familiriarity with D is a big problem. Programming novices (ie, 90% of of professional programmers, ever since "java houses" and the web) and HR personnel don't understand that the vast majority pf programming skills are easily transferable between languages. They think it's all like Chinese vs French.
Re: Bad Sound Quality on Livestreamed Videos
On Saturday, 30 May 2015 at 14:12:10 UTC, Per Nordlöw wrote: The livestreaming videos just published are really frustrating to watch because lots of stuttering in speech about once every 20 seconds or so and sometimes difficult to here what people say. Sorry about that, the WiFi wasn't quite up to the task at some points. Hopefully it was still better than nothing :)
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 15:24:49 UTC, Adam D. Ruppe wrote:
On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))
I briefly mentioned this at the dconf and thinking about it a
bit more, I think there's only two cases where we want implicit
construction: function argument lists and function return
values. (The syntax doesn't really matter, but I'd do it
similar to C++ and just slap an @implicit on a regular
constructor).
So:
struct Foo { @implicit this(typeof(null)) {} }
Foo test() {
return null;
}
Right now, that return null would say "cannot implicitly
convert null to Foo". But since it is on a return statement and
we have an implicit constructor, it would automatically rewrite
that to return Foo(null); and be happy with it.
Note that this does NOT change
Foo foo = null;
because that already works with a standard constructor today!
Similarly, foo = null is handled with opAssign. So no change
needed there.
Anyway, the trickier case is function calls:
void test(Foo) {}
test(null); // should do test(Foo(null));
How does that interact with operator overloading? (I'd note
that C++ does this so we could always borrow their rules too.)
My proposal would be that if something matches exactly without
implicit conversion, use that. Otherwise, try the implicit
construction and issue an error if more than one match.
This would work the same as arrays today:
void a(int[]) {}
void a(long[]) {}
void a(typeof(null)) {}
void main() { a(null); }
That compiles. Comment the third line though and get:
b.d(5): Error: b.a called with argument types (typeof(null))
matches both:
b.d(1): b.a(int[] _param_0)
and:
b.d(2): b.a(long[] _param_0)
So I think that's doable and shouldn't break any existing code
as it is a new opt-in keyword. Just will have to watch for
regression bugs...
But that'd take care of the null problem with library AAs
and I could use it to make my var type all the more wild :P
This would also greatly improve Variant and Algebraic
Re: Bad Sound Quality on Livestreamed Videos
On 5/30/15 8:37 AM, John Colvin wrote: On Saturday, 30 May 2015 at 14:12:10 UTC, Per Nordlöw wrote: The livestreaming videos just published are really frustrating to watch because lots of stuttering in speech about once every 20 seconds or so and sometimes difficult to here what people say. Sorry about that, the WiFi wasn't quite up to the task at some points. Hopefully it was still better than nothing :) Much better; I really enjoyed the livestream. And the quality was pretty good, considering its impromptu nature. Many thanks!
Re: Proof of concept - library AA
On Saturday, 30 May 2015 at 15:24:49 UTC, Adam D. Ruppe wrote: On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote: static Foo opImplicitConstructFrom(T)(T val) if(is(T : int)) I briefly mentioned this at the dconf and thinking about it a bit more, I think there's only two cases where we want implicit construction: function argument lists and function return values. (The syntax doesn't really matter, but I'd do it similar to C++ and just slap an @implicit on a regular constructor). What did people say about this idea?
Re: dmd makes D appear slow
On Saturday, 30 May 2015 at 14:29:56 UTC, ketmar wrote: On Sat, 30 May 2015 12:00:57 +, Kyoji Klyden wrote: So personally I vote that speed optimizations on DMD are a waste of time at the moment. it's not only waste of time, it's unrealistic to make DMD backend's quality comparable to GDC/LDC. it will require complete rewrite of backend and many man-years of work. and GDC/LDC will not simply sit frozen all this time. +1 for LDC as first class! D would become a lot more appealing if it could take advantage of the LLVM tooling already available! Regarding the speed problem - One could always have LDC have a nitro switch, where it simply runs less of the expensive passes, thus reducing the codegen quality, but improving speed. Would that work? I'm assuming the "slowness" in LLVM comes from the optimization passes. Would clang's thread-sanitizer and address-sanitizer be adaptable and usable with D as well?
Re: dmd makes D appear slow
On Saturday, 30 May 2015 at 17:00:18 UTC, Márcio Martins wrote: Would clang's thread-sanitizer and address-sanitizer be adaptable and usable with D as well? these are already usable from LDC. make sure you use the -gcc=clang flag.
Re: dmd makes D appear slow
On 30 May 2015 19:05, "via Digitalmars-d" wrote: > > On Saturday, 30 May 2015 at 14:29:56 UTC, ketmar wrote: >> >> On Sat, 30 May 2015 12:00:57 +, Kyoji Klyden wrote: >> >>> So personally I vote that speed optimizations on DMD are a waste of time >>> at the moment. >> >> >> it's not only waste of time, it's unrealistic to make DMD backend's >> quality comparable to GDC/LDC. it will require complete rewrite of backend >> and many man-years of work. and GDC/LDC will not simply sit frozen all >> this time. > > > +1 for LDC as first class! > > D would become a lot more appealing if it could take advantage of the LLVM tooling already available! > > Regarding the speed problem - One could always have LDC have a nitro switch, where it simply runs less of the expensive passes, thus reducing the codegen quality, but improving speed. Would that work? I'm assuming the "slowness" in LLVM comes from the optimization passes. > I'd imagine the situation is similar with GDC. For large compilations, it's the optimizer, for small compilations, it's the linker. Small compilations is at least solved by switching to shared libraries. For larger compilations, only using -O1 optimisations should be fine for most programs that aren't trying to beat some sort of benchmark.
Re: dmd makes D appear slow
On 30/05/15 03:57, Steven Schveighoffer wrote: I saw the slide from Liran that shows your compiler requirements :) I can see why it's important to you. Then you misunderstood Liran's slides. Our compile resources problem isn't with GDC. It's with DMD. Single object compilation requires more RAM than most developers machines have, resulting in a complicated "rsync to AWS, run script there, compile, fetch results" cycle that adds quite a while to the compilation time. Conversly, our problem with GDC is that IT !@$#%&?!@# PRODUCES ASSEMBLY THAT DOES NOT MATCH THE SOURCE. I have not seen LDC myself, but according to Liran, situation there is even worse. The compiler simply does not finish compilation without crashing. But compiled code outlives the compiler execution. It's the wart that persists. So does algorithmic code that, due to a compiler bugs, produces an assembly that does not implement the correct algorithm. When doing RAID parity calculation, it is imperative that the correct bit gets to the correct location with the correct value. If that doesn't happen, compilation speed is the least of your problems. Like Liran said in the lecture, we are currently faster than all of our competition. Still, in a correctly functioning storage system, the RAID part needs to take considerable amount of the total processing time under load (say, 30%). If we're losing x3 speed because we don't have compiler optimizations, the system, as a whole, is losing about half of its performance. But I don't see how speed of compiler should sacrifice runtime performance. Our plan was to compile with DMD during the development stage, and then switch to GDC for code intended for deployment. This plan simply cannot work if each time we try and make that switch, Liran has to spend two months, each time yanking a different developer from the work said developer needs to be doing, in order to figure out which line of source gets compiled incorrectly. -Steve Shachar
Re: dmd makes D appear slow
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote: When he says Windows, he means MSVC, gcc backend will never support interfacing that ABI (at least I see no motivation as of writing). I thought that's what MINGW was. A gcc backend that interfaces with the Windows ABI. Isn't it? Shachar
Re: dmd makes D appear slow
On 30 May 2015 at 20:38, Shachar Shemesh via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 30/05/15 03:57, Steven Schveighoffer wrote: > > I saw the slide from Liran that shows your compiler requirements :) I >> can see why it's important to you. >> > > Then you misunderstood Liran's slides. > > Our compile resources problem isn't with GDC. It's with DMD. Single object > compilation requires more RAM than most developers machines have, resulting > in a complicated "rsync to AWS, run script there, compile, fetch results" > cycle that adds quite a while to the compilation time. > > Conversly, our problem with GDC is that IT !@$#%&?!@# PRODUCES ASSEMBLY > THAT DOES NOT MATCH THE SOURCE. > > Got any bug reports to back that up? I should probably run the testsuite with optimisations turned on sometime.
Re: I won a school game-creation competition!
That is great news! Congratulations on your project. That must have been a good learning practice, while demonstrating D language to other people.
Re: I won a school game-creation competition!
On Saturday, 30 May 2015 at 14:48:53 UTC, Vladde Nordholm wrote: So hey everyone! I am very happy to say that I won a game-creation contest, called "LBS Game Awards 2015", where I entered with my console game DRPG, which is written in D. I didn't win the best game, but I won the "best newcomer"-award! I am really grateful to all of you who have helped me with the struggles during development. With out you, the D community, I am almost certain the game wouldn't be what it is today! Chatting with the the people on #d has really been amazing, and again, I'm very happy that the whole community is as friendly as it is! Just some shoutouts to people who really have helped me a lot: Adam D. Ruppe, Danol, ketmar, jA_cOp, CyberShadow. You have always helped me when I needed it. Thank you :) here is the link i suppose: http://lbsgameawards.se/project.php?id=208
Re: I won a school game-creation competition!
On Saturday, 30 May 2015 at 20:42:14 UTC, extrawurst wrote: On Saturday, 30 May 2015 at 14:48:53 UTC, Vladde Nordholm wrote: So hey everyone! I am very happy to say that I won a game-creation contest, called "LBS Game Awards 2015", where I entered with my console game DRPG, which is written in D. I didn't win the best game, but I won the "best newcomer"-award! I am really grateful to all of you who have helped me with the struggles during development. With out you, the D community, I am almost certain the game wouldn't be what it is today! Chatting with the the people on #d has really been amazing, and again, I'm very happy that the whole community is as friendly as it is! Just some shoutouts to people who really have helped me a lot: Adam D. Ruppe, Danol, ketmar, jA_cOp, CyberShadow. You have always helped me when I needed it. Thank you :) here is the link i suppose: http://lbsgameawards.se/project.php?id=208 The game starts normally but when I press 'S', then the game shuts down. What am I doing wrong?
Re: I won a school game-creation competition!
On Saturday, 30 May 2015 at 20:53:29 UTC, Dennis Ritchie wrote: On Saturday, 30 May 2015 at 20:42:14 UTC, extrawurst wrote: here is the link i suppose: http://lbsgameawards.se/project.php?id=208 The game starts normally but when I press 'S', then the game shuts down. What am I doing wrong? I saw the same problem (access violation), but it doesn't occur if I rebuild it from source.
Re: Progress on Adam Wilson's Graphics API?
On Sun, 31 May 2015 02:35:22 +1200, Rikki Cattermole wrote: > Personally I think it is more reasonable to assume certain libraries > will be installed. Such as for Windows user32 and GDI. > Where by there is no real alternatives. Like X11 for *nix. > In other words, system libraries are fine to use. As you have no real > choice in the matter. while you are right about windows GDI, with GNU/Linux you can find, for example, wayland or DirectFB setup without X11 emulation layer at all. so assuming that X11 is always there is not exactly right. > Now SDL on the other hand, you cannot assume will be installed or > available. Unless you want to go bundling that or using static > libraries. Still defeats the purpose of expanding D's library base. installing wide-known libraries is very easy on most modern OSes. the biggest mistake community can do is start rewriting *everything* in D for the sake of "some user might need that so we have to have that, written in D". that is what C interop does: allows us to reuse already written and debugged code. but i can agree that more wrappers and more system API coverage in distribution bundle will be fine. now, for example, one can't do more or less serious windows programming with DMD "out of the box". *that* is the problem, not absense of some 3rd-party library. signature.asc Description: PGP signature
Re: I won a school game-creation competition!
On 5/30/15 7:48 AM, Vladde Nordholm wrote: So hey everyone! I am very happy to say that I won a game-creation contest, called "LBS Game Awards 2015", where I entered with my console game DRPG, which is written in D. I didn't win the best game, but I won the "best newcomer"-award! I am really grateful to all of you who have helped me with the struggles during development. With out you, the D community, I am almost certain the game wouldn't be what it is today! Chatting with the the people on #d has really been amazing, and again, I'm very happy that the whole community is as friendly as it is! Just some shoutouts to people who really have helped me a lot: Adam D. Ruppe, Danol, ketmar, jA_cOp, CyberShadow. You have always helped me when I needed it. Thank you :) Congratulations! -- Andrei
Re: dmd makes D appear slow
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d wrote: > On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote: >> >> >> When he says Windows, he means MSVC, gcc backend will never support >> interfacing that ABI (at least I see no motivation as of writing). >> > I thought that's what MINGW was. A gcc backend that interfaces with the > Windows ABI. Isn't it? If your program is isolated, MinGW is fine. Great even! But the Windows ecosystem is built around Microsoft's COFF formatted libraries (as produced by Visual Studio), and most Windows libs that I find myself working with are closed-source, or distributed as pre-built binaries. You can't do very large scale work in the Windows ecosystem without interacting with the MS ecosystem, that is, COFF libs, and CV8/PDB debuginfo. Even if we could use MinGW, we ship an SDK ourselves, and customers would demand COFF libs from us. LLVM is (finally!) addressing this Microsoft/VisualC-centric nature of the Windows dev environment... I just wish they'd hurry up! It's about 10 years overdue.
Re: Why aren't you using D at work?
I have been doing my first serious attempt at D after convincing other people that it was the way to go quite a few years ago. (My copy of "The D Programming Language" doesn't have Andrei's name on it so it would have been around that time) and these are the things which are fresh for me. I had no idea that it was so easy to call C code from my D code, and how little effort I had to go to disguise the fact that it was C code thanks mostly to UFCS and @property. This makes it feasible to write bindings on the fly and makes me a lot less hesitant to try using it for any job I could use C or C++. So far so good. Now lets get to the friction points. Tooling - it's still a step down from what I am used to with C/C++ on linux. This is now for me at the point where it is acceptable but not great. Documentation - What is there is generally quite good, also quite terse. I am not seeing a huge number D specific results whenever I search on any issues I am having with my code. The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language.
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 30 May 2015 at 14:35:29 UTC, Rikki Cattermole wrote: On 31/05/2015 2:31 a.m., ketmar wrote: On Sun, 31 May 2015 02:28:51 +1200, Rikki Cattermole wrote: On 31/05/2015 2:27 a.m., ketmar wrote: On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one. i bet Devisualisation is using Xlib/XCB, so it's out of competition too, for example. ;-) Well then lets call a spade a spade and start writing our own operating system shall we? Personally I think it is more reasonable to assume certain libraries will be installed. Such as for Windows user32 and GDI. Where by there is no real alternatives. Like X11 for *nix. In other words, system libraries are fine to use. As you have no real choice in the matter. Now SDL on the other hand, you cannot assume will be installed or available. Unless you want to go bundling that or using static libraries. Still defeats the purpose of expanding D's library base. Why do people always want to reinvent such well tested libraries? Slap a nice D API over the top and reuse the hard work of others. Besides SDL is pretty much ubiquitous on all platforms D supports. You could even package up dependencies with your bindings and the end-user wouldn't have to worry. Honestly though if someone isn't willing to learn how to obtain SDL for their chosen platform, even if it requires building from source. then they should probably forgo programming as a career or hobby. bye, lobo
Re: As discussed in DConf2015: Python-like keyword arguments
On 2015-05-29 12:27:02 +, Jacob Carlborg said: And here's an implementation with language support which allows named arguments but not reordering the arguments [2]. Originally implemented by Michel Fortin. [2] https://github.com/jacob-carlborg/dmd/tree/named_parameters I didn't know you revived that thing too. Nice. Make sure you take note of the related comments between Walter and me here: https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a At some point my plans about this changed and I wanted to implement named arguments differently so it'd work for template arguments too. But I never go to it. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 3:08 a.m., Adam D. Ruppe wrote: On Saturday, 30 May 2015 at 13:35:47 UTC, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? Hint good luck, none really exist. I'm slowly getting through my simpleaudio.d What about window creation? Well Devisualization.Window (author) but what would about integration into OSX's menu or Windows notification area? Again you've got a problem. My simpledisplay.d can do the Windows notification area. But there's a lot more that needs to get done that I haven't gotten around to yet. If I can ever quit my day job, I'll start going nuts on this again :) I sorta excluded your work on purpose. Even though it is damn good work!
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 9:56 a.m., ketmar wrote: On Sun, 31 May 2015 02:35:22 +1200, Rikki Cattermole wrote: Personally I think it is more reasonable to assume certain libraries will be installed. Such as for Windows user32 and GDI. Where by there is no real alternatives. Like X11 for *nix. In other words, system libraries are fine to use. As you have no real choice in the matter. while you are right about windows GDI, with GNU/Linux you can find, for example, wayland or DirectFB setup without X11 emulation layer at all. so assuming that X11 is always there is not exactly right. In most cases it is and will be for a while yet. Although you are right in saying it should also support others. Now SDL on the other hand, you cannot assume will be installed or available. Unless you want to go bundling that or using static libraries. Still defeats the purpose of expanding D's library base. installing wide-known libraries is very easy on most modern OSes. the biggest mistake community can do is start rewriting *everything* in D for the sake of "some user might need that so we have to have that, written in D". that is what C interop does: allows us to reuse already written and debugged code. but i can agree that more wrappers and more system API coverage in distribution bundle will be fine. now, for example, one can't do more or less serious windows programming with DMD "out of the box". *that* is the problem, not absense of some 3rd-party library. I agree completely, but we do need good abstractions in e.g. phobos that we all agree upon. It doesn't matter what implementations go in however. As long as there is enough for out of the box experience.
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 1:26 p.m., lobo wrote: On Saturday, 30 May 2015 at 14:35:29 UTC, Rikki Cattermole wrote: On 31/05/2015 2:31 a.m., ketmar wrote: On Sun, 31 May 2015 02:28:51 +1200, Rikki Cattermole wrote: On 31/05/2015 2:27 a.m., ketmar wrote: On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one. i bet Devisualisation is using Xlib/XCB, so it's out of competition too, for example. ;-) Well then lets call a spade a spade and start writing our own operating system shall we? Personally I think it is more reasonable to assume certain libraries will be installed. Such as for Windows user32 and GDI. Where by there is no real alternatives. Like X11 for *nix. In other words, system libraries are fine to use. As you have no real choice in the matter. Now SDL on the other hand, you cannot assume will be installed or available. Unless you want to go bundling that or using static libraries. Still defeats the purpose of expanding D's library base. Why do people always want to reinvent such well tested libraries? Slap a nice D API over the top and reuse the hard work of others. Besides SDL is pretty much ubiquitous on all platforms D supports. You could even package up dependencies with your bindings and the end-user wouldn't have to worry. Honestly though if someone isn't willing to learn how to obtain SDL for their chosen platform, even if it requires building from source. then they should probably forgo programming as a career or hobby. bye, lobo You're missing a large part of what I'm saying. For people just learning the language and getting started, saying go download x for your platform won't be enough. Look at how we are handling curl right now. No, for any e.g. library or window creation libraries and likes. Must have an agreed interface that is not specific to e.g. SDL. SDL may implement them. But out of the box experience must not rely on 3rd party. E.g. such an image library there wouldn't be a JPEG implementation but would be a PNG one. Because of the complexity of implementing a JPEG reader/writer. Which is ridiculously hard compared to PNG which is actually really simple.
Re: Why aren't you using D at work?
On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote: I have been doing my first serious attempt at D after convincing other people that it was the way to go quite a few years ago. (My copy of "The D Programming Language" doesn't have Andrei's name on it so it would have been around that time) and these are the things which are fresh for me. I had no idea that it was so easy to call C code from my D code, and how little effort I had to go to disguise the fact that it was C code thanks mostly to UFCS and @property. This makes it feasible to write bindings on the fly and makes me a lot less hesitant to try using it for any job I could use C or C++. So far so good. Now lets get to the friction points. Tooling - it's still a step down from what I am used to with C/C++ on linux. This is now for me at the point where it is acceptable but not great. Documentation - What is there is generally quite good, also quite terse. I am not seeing a huge number D specific results whenever I search on any issues I am having with my code. The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language. Ahh std.xml, it's been that way for years. We NEED to get that replaced. Although don't hold your breath :/
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 3:07 a.m., Adam D. Ruppe wrote: On Saturday, 30 May 2015 at 14:28:57 UTC, Rikki Cattermole wrote: On 31/05/2015 2:27 a.m., ketmar wrote: SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one. I think that is unnecessarily limiting. I do see your point about distribution, but using C libraries is a common thing with solutions (packaging the DLLs with you, instructing users to install it, using system package managers, etc.) and their availability is one of D's strengths. As I've already said, out of the box experience should not rely on 3rd party. But nobody is stopping you for using an implementation that does use it ;)
Re: Why aren't you using D at work?
On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d wrote: > On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote: [...] > >The Standard Library. I want to use D so I can do more with less > >hours writing code and less hours debugging code. Having a high > >quality standard library really helps this - unfortunately for me the > >first thing I needed from the standard library was xml parsing, which > >the documentation tells me is sub par and will be replaced in the > >near future, There is no indication of what I might like to use > >instead. Do I now use one of the other xml libraries floating around, > >bind a C based one or roll my own. All this eats into the efficiency > >that I am gaining by virtue of D being a really nice language. > > > > > Ahh std.xml, it's been that way for years. > We NEED to get that replaced. Although don't hold your breath :/ What we *really* need, like almost everything else in D, is for somebody to get sufficiently provoked by the sorry state of the current std.xml to write something better and push it through the review process. Until then, further discussion is unlikely to make any difference. T -- Famous last words: I *think* this will work...
Re: Progress on Adam Wilson's Graphics API?
On Sunday, 31 May 2015 at 02:16:02 UTC, Rikki Cattermole wrote: As I've already said, out of the box experience should not rely on 3rd party. Rely on, no. But package? Sure. I'd be ok with built-in etc.c.sdl bindings and such. Perhaps dub obsoletes this idea, but if someone is willing to use a C xml lib or sdl or whatever, sufficiently popular (defined simply by "someone took the time to write the bindings and open the PR") libs having bindings in there would be nice in a C-batteries included sense.
Re: Why aren't you using D at work?
On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote: On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d wrote: On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote: [...] The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language. Ahh std.xml, it's been that way for years. We NEED to get that replaced. Although don't hold your breath :/ What we *really* need, like almost everything else in D, is for somebody to get sufficiently provoked by the sorry state of the current std.xml to write something better and push it through the review process. Until then, further discussion is unlikely to make any difference. T That's a given at this stage. I've read the XML spec, its almost as bad as x86. Okay not quite but still. That's how far I got.
Re: Uphill
On 05/22/2015 01:16 PM, Chris wrote: On Friday, 22 May 2015 at 17:05:10 UTC, H. S. Teoh wrote: Agreed, D does have its warts and dark corners, but overall it's extremely awesome. I just can't bring myself to starting new projects in any other language these days True, true. If I have the choice, it's D. If it's another language, I very soon start to miss D's features. I've pretty much sworn off all other languages[1]. Life's too damn short to even touch them. I'd sooner switch careers than waste any more of my life on those other langs. [1] (Aside from occasional nemerle if I need CLR.)
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 2:38 p.m., Adam D. Ruppe wrote: On Sunday, 31 May 2015 at 02:16:02 UTC, Rikki Cattermole wrote: As I've already said, out of the box experience should not rely on 3rd party. Rely on, no. But package? Sure. I'd be ok with built-in etc.c.sdl bindings and such. Perhaps dub obsoletes this idea, but if someone is willing to use a C xml lib or sdl or whatever, sufficiently popular (defined simply by "someone took the time to write the bindings and open the PR") libs having bindings in there would be nice in a C-batteries included sense. The way I view it is (lets use image as example). Phobos would include an abstraction, a set of implementations and creation hooks. The creation hooks would allow converting to and importing certain formats. Basically global AA full of e.g. delegates to do so. Now a dub library could implement the abstractions, register there hooks and wala. You can now read a png image, jpeg or what ever and not really care about the implementation and it just works. But if you need to you could convert it to an SDL image and use it with SDL. So now a very low entry point for new implementations and usages but also a high gain in interoperability between implementations.
Re: Why aren't you using D at work?
so is std.xml the exception? How many other parts of the standard library are like that? On Sun, May 31, 2015 at 12:37 PM, Rikki Cattermole via Digitalmars-d wrote: > On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote: >> >> On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via >> Digitalmars-d wrote: >>> >>> On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote: >> >> [...] The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language. >>> >>> >>> Ahh std.xml, it's been that way for years. >>> We NEED to get that replaced. Although don't hold your breath :/ >> >> >> What we *really* need, like almost everything else in D, is for somebody >> to get sufficiently provoked by the sorry state of the current std.xml >> to write something better and push it through the review process. Until >> then, further discussion is unlikely to make any difference. >> >> >> T >> > > That's a given at this stage. > I've read the XML spec, its almost as bad as x86. Okay not quite but still. > That's how far I got.
Re: Uphill
On 05/28/2015 04:55 AM, Chris wrote: "If it's for free, it must be sh*t", I often hear people say. Maybe we should have a D Enterprise Edition (DEE) and sell it for $1,000. Believe me, people would take to it like ducks take to water. Indeed. There's an MBA born every minute ;)
Re: Why aren't you using D at work?
On 31/05/2015 3:03 p.m., Danni Coy via Digitalmars-d wrote: so is std.xml the exception? How many other parts of the standard library are like that? On Sun, May 31, 2015 at 12:37 PM, Rikki Cattermole via Digitalmars-d wrote: On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote: On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d wrote: On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote: [...] The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language. Ahh std.xml, it's been that way for years. We NEED to get that replaced. Although don't hold your breath :/ What we *really* need, like almost everything else in D, is for somebody to get sufficiently provoked by the sorry state of the current std.xml to write something better and push it through the review process. Until then, further discussion is unlikely to make any difference. T That's a given at this stage. I've read the XML spec, its almost as bad as x86. Okay not quite but still. That's how far I got. std.json I believe and maybe one or two others. But std.xml is the one without a real clear alternative in the D ecosystem.
Re: Why aren't you using D at work?
On 31 May 2015 at 13:03, Danni Coy via Digitalmars-d wrote: > so is std.xml the exception? How many other parts of the standard > library are like that? Lots. Check out std.json ;)
Re: Uphill
On 28 May 2015 at 19:23, Rikki Cattermole via Digitalmars-d wrote: > On 28/05/2015 8:55 p.m., Chris wrote: >> >> On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: >>> >>> On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: >>> Only when I can sell D to customers that put money into this kind of stuff >>> >>> >>> if customers are deciding which technologies to use... ok then, they can >>> do their work without my help, 'cause they are so knowledgeable. >> >> >> It's funny that people spend millions on technologies that makes >> mediocre or crap languages better, but they would never invest in >> something like D, because they dread the investment. I think it's >> because D doesn't have a price tag attached to it. "If it's for free, it >> must be sh*t", I often hear people say. Maybe we should have a D >> Enterprise Edition (DEE) and sell it for $1,000. Believe me, people >> would take to it like ducks take to water. > > > Or we put together a D consultancy firm, perhaps as part of D's future > foundation? > > Starting at e.g. bug fixes ext. with price tag ranges on them. > Perhaps even a price tag on working on DIP's. I would put my money on the table.
Re: Uphill
On 31/05/2015 3:52 p.m., Manu via Digitalmars-d wrote: On 28 May 2015 at 19:23, Rikki Cattermole via Digitalmars-d wrote: On 28/05/2015 8:55 p.m., Chris wrote: On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: Only when I can sell D to customers that put money into this kind of stuff if customers are deciding which technologies to use... ok then, they can do their work without my help, 'cause they are so knowledgeable. It's funny that people spend millions on technologies that makes mediocre or crap languages better, but they would never invest in something like D, because they dread the investment. I think it's because D doesn't have a price tag attached to it. "If it's for free, it must be sh*t", I often hear people say. Maybe we should have a D Enterprise Edition (DEE) and sell it for $1,000. Believe me, people would take to it like ducks take to water. Or we put together a D consultancy firm, perhaps as part of D's future foundation? Starting at e.g. bug fixes ext. with price tag ranges on them. Perhaps even a price tag on working on DIP's. I would put my money on the table. Now we just need either Walter or Andrei to weigh in on this idea. And perhaps somebody willing to step up and lead this. Laeeth Isharc perhaps? As I know he is interested in this area already and has the skills to back it up.
Re: As discussed in DConf2015: Python-like keyword arguments
On Sat, 30 May 2015 21:59:53 -0400, Michel Fortin wrote:
> On 2015-05-29 12:27:02 +, Jacob Carlborg said:
>
>> And here's an implementation with language support which allows named
>> arguments but not reordering the arguments [2]. Originally implemented
>> by Michel Fortin.
>>
>> [2] https://github.com/jacob-carlborg/dmd/tree/named_parameters
>
> I didn't know you revived that thing too. Nice.
>
> Make sure you take note of the related comments between Walter and me
> here:
> https://github.com/michelf/dmd/
commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a
>
> At some point my plans about this changed and I wanted to implement
> named arguments differently so it'd work for template arguments too.
> But I never go to it.
my work now allows this:
string test (string a, string b="wow", string c="heh") {
return a~b~c;
}
void main () {
enum str = test(c: "cc", a: "aa");
assert(str == "aawowcc");
}
and this:
void test(A...) (A a) {
import std.stdio;
foreach (auto t; a) writeln(t);
}
void main () {
test(x: 33.3, z: 44.4, a: , , d:"Yehaw");
}
but still not this:
string test(T) (T a, string b="wow", string c="heh") {
import std.conv : to;
return to!string(a)~b~c;
}
void main () {
enum str = test(c: "cc", a: 42); // can't
//enum str = test(a: 42, c: "cc"); // WORKS
assert(str == "42wowcc");
}
i have to add reorder checks to template resoultion code yet.
also, no support for named "!" args.
the patch is fairly simple and almost non-intrusive (one big function in
mtype.c and processing of NamedArgExp at different visitors). .di
generation is supported too.
signature.asc
Description: PGP signature
Re: Uphill
On 5/24/2015 9:03 AM, Andrei Alexandrescu wrote: On 5/24/15 1:20 AM, weaselcat wrote: IMO I think the worst thing C++ has done is blatantly ignore features that have been 'killer' in D(see: the reaction to the static_if proposal) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html -- Andrei The proposal: Proposal: static if declaration http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf The rebuttal: "Static If" Considered http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf Quoted from the rebuttal: The static if feature recently proposed for C++ [1, 2] is fundamentally flawed, and its adoption would be a disaster for the language. The feature provides a single syntax with three distinct semantics, depending on the context of use. The primary mechanism of these semantics is to avoid parsing in branches not taken. This will make programs harder to read, understand, maintain, and debug. It would also impede and possibly prevent the future development of other language features, such as concepts. Furthermore, the adoption of this feature would seriously compromise our ability to produce AST- based tools for C++, and therefore put C++ at a further disadvantage compared to other modern languages vis a vis tool support. It would make C++ a lower-level language.
Re: Progress on Adam Wilson's Graphics API?
On Sunday, 31 May 2015 at 02:14:53 UTC, Rikki Cattermole wrote: You're missing a large part of what I'm saying. I understand what you're saying, I just disagree ;) I'd argue well tested and maintained dependencies are more important than what language they are written in. For people just learning the language and getting started, saying go download x for your platform won't be enough. Look at how we are handling curl right now. No, for any e.g. library or window creation libraries and likes. Must have an agreed interface that is not specific to e.g. SDL. SDL may implement them. But out of the box experience must not rely on 3rd party. s/bindings/wrapper/ Sorry, I should be more specific, but as I said in my earlier post; slap a nice D interface over the top of the C library. In D this is trivial. E.g. such an image library there wouldn't be a JPEG implementation but would be a PNG one. Because of the complexity of implementing a JPEG reader/writer. Which is ridiculously hard compared to PNG which is actually really simple. Again, I wonder why would you reimplement what you get from libpng? Think of all the real world tests, tweaks and optimization you're throwing away by not using libpng. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. The effort of that alone would be greater than what is currently required from Phobos devs and end-users with a 'C' dependency. If dub supported compiling C that would be awesome for my own bindings/wrappers. bye, lobo
Re: Progress on Adam Wilson's Graphics API?
On 31/05/2015 4:46 p.m., lobo wrote: On Sunday, 31 May 2015 at 02:14:53 UTC, Rikki Cattermole wrote: You're missing a large part of what I'm saying. I understand what you're saying, I just disagree ;) I'd argue well tested and maintained dependencies are more important than what language they are written in. For people just learning the language and getting started, saying go download x for your platform won't be enough. Look at how we are handling curl right now. No, for any e.g. library or window creation libraries and likes. Must have an agreed interface that is not specific to e.g. SDL. SDL may implement them. But out of the box experience must not rely on 3rd party. s/bindings/wrapper/ Sorry, I should be more specific, but as I said in my earlier post; slap a nice D interface over the top of the C library. In D this is trivial. E.g. such an image library there wouldn't be a JPEG implementation but would be a PNG one. Because of the complexity of implementing a JPEG reader/writer. Which is ridiculously hard compared to PNG which is actually really simple. Again, I wonder why would you reimplement what you get from libpng? Think of all the real world tests, tweaks and optimization you're throwing away by not using libpng. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. The effort of that alone would be greater than what is currently required from Phobos devs and end-users with a 'C' dependency. If dub supported compiling C that would be awesome for my own bindings/wrappers. bye, lobo I think you are thinking of it a little too much as being mutually exclusive. It's not. There is no reason not to use e.g. libpng for an image implementation. But the important thing atleast for phobos is to have an out of the box will work for most people implementation. Dub would be the amazing way to distribute more image format implementations. So it would be opt-in for e.g. libpng. I'm atleast trying to hit a middle ground to make everyone happy. A nice interchangeable image interface, some common image implementations ready to go and of course the ability to add better implementations on the fly. It's a lot better then the alternatives. Where by you must know the type to use the format or you must have c libraries to make it of any use at all.
Re: Uphill
On 5/30/15 8:55 PM, Rikki Cattermole wrote: On 31/05/2015 3:52 p.m., Manu via Digitalmars-d wrote: On 28 May 2015 at 19:23, Rikki Cattermole via Digitalmars-d wrote: On 28/05/2015 8:55 p.m., Chris wrote: On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: Only when I can sell D to customers that put money into this kind of stuff if customers are deciding which technologies to use... ok then, they can do their work without my help, 'cause they are so knowledgeable. It's funny that people spend millions on technologies that makes mediocre or crap languages better, but they would never invest in something like D, because they dread the investment. I think it's because D doesn't have a price tag attached to it. "If it's for free, it must be sh*t", I often hear people say. Maybe we should have a D Enterprise Edition (DEE) and sell it for $1,000. Believe me, people would take to it like ducks take to water. Or we put together a D consultancy firm, perhaps as part of D's future foundation? Starting at e.g. bug fixes ext. with price tag ranges on them. Perhaps even a price tag on working on DIP's. I would put my money on the table. Now we just need either Walter or Andrei to weigh in on this idea. And perhaps somebody willing to step up and lead this. Speaking only for myself, I'll look into how the foundation can facilitate such paid consultancy. (Probably poorly if it's non-profit.) The practical issue I see is with the geographical distribution of participants. Probably a strong entrepreneur could overcome these issues. -- Andrei
Re: As discussed in DConf2015: Python-like keyword arguments
ok, last sample now works too. ;-) signature.asc Description: PGP signature
Re: Progress on Adam Wilson's Graphics API?
On Sunday, 31 May 2015 at 04:46:51 UTC, lobo wrote: Again, I wonder why would you reimplement what you get from libpng? I've actually had people ask me what magic I did with my png.d because it often generates smaller files than libpng. It is easier to use an leaving out unnecessary bits made it faster and more efficient! (for our use cases, the full lib is surely useful for other cases) The thing with those libraries is they do everything, which makes them bigger and more complex. There's a place for that, sure, but it isn't necessarily better. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. Fun fact: curl is actually pretty buggy... and a pain to use too. I like it and use it for a lot of things, but I also replaced it (and again, like with the png, a lot of the things it does aren't necessary for me anyway)
Re: Why aren't you using D at work?
On Saturday, 30 May 2015 at 10:25:19 UTC, Jacob Carlborg wrote: For Swift interfacing with C++ you would need a C or Objective-C layer. With the Objective-C support in D (if it will ever be merged) you could have a more direct interface, but it would be limited to the Objective-C subset. If D is as easier to integrate than Objective-C++ (which basically is C+14 with Objective-C tacked on) and with the same level of ARM support then that could be a real selling point. You would also need Android support though. (Since writing in C/C++ is a stepping stone to porting iOS apps to Android).
Re: Uphill
On Sunday, 31 May 2015 at 04:18:32 UTC, Walter Bright wrote: Furthermore, the adoption of this feature would seriously compromise our ability to produce AST- based tools for C++, and therefore put C++ at a further disadvantage compared to other modern languages vis a vis tool support. I find it hilarious that they can say that in a language that needs a preprocessor. Macros (and mixins) destroy AST-based tools, not things like "static if" that are right there in the AST.
Re: Uphill
On Sunday, 31 May 2015 at 06:03:36 UTC, Brian Schott wrote: I find it hilarious that they can say that in a language that needs a preprocessor. Macros (and mixins) destroy AST-based tools, not things like "static if" that are right there in the AST. That's not right. "static if" is just as bad as macros and affects partial evaluation. Besides I think C++ is moving away from macros, and I believe it is a stated goal for BS to do so. I don't use macros in C++ anymore.
