Budget Kitchen Sale Abbots Langley
Budget Kitchen Sale Abbots Langley. Thirty Ex Display Kitchens To Clear. W w w e x d i s p l a y k i t c h e n s 1 c o u k £ 595 Each with appliances.Tel 0 1 6 1 6 6 9 4 7 8 5
Re: Revert attributes to their defaults with default keywords
On Sat, 10 Jan 2015 02:47:00 +
Meta via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 9 January 2015 at 14:26:26 UTC, aldanor wrote:
It could work both ways at the same time.
Maybe even something like default(pred) final(pred) nothrow
-- if pred is compile-time-true, reset all attributes and then
add final/nothrow; if it's compile-time-false, disable final
and enable nothrow.
@disable is also currently a keyword.
pure nothrow @safe @nogc immutable
Test
{
//doSomething is nothrow @safe @nogc immutable
@disable(pure) void doSomething() {}
//getAnInt is pure @nogc immutable
@disable(nothrow, @safe) int getAnInt() {}
//typeof(n) == int
@disable(immutable) int n;
}
This is also useful for templated functions, methods, etc. It
allows one to tell the compiler that the function in question
should never have a particular attribute inferred for it.
//doSomethingElse will never be inferred as pure,
//but may be inferred as nothrow, @safe, or @nogc
@disable(pure) void doSomethingElse()() {}
i chose to go with `@impure`, `@canthrow` and `@gc`. the fact is that
adding new inverted attributes requres adding new STC flags into the
compiler. this is very intrusive change. yed UDAs can be checked just
before we set `FUNCFLAG*Inprocess`. this was ALOT easier than hunting
down all the places where i need to take care on new STC flags.
yes, this is ugly hack with ugly new set of attributes, but it's way
easier to support for me. and as i have no hope of taking something
like this into mainline (at least not sooner than another year pass),
maintenance costs becomes very important. complex PR will rot soon and
rotten PR will never make it into mainline.
signature.asc
Description: PGP signature
Re: For those ready to take the challenge
On Saturday, 10 January 2015 at 02:10:04 UTC, Jesse Phillips
wrote:
On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote:
https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro
Link to answer in D:
http://codegolf.stackexchange.com/a/44417/13362
I think byLine is not necessary. By default . will not match line
breaks.
One statement solution:
import std.net.curl, std.stdio;
import std.algorithm, std.regex;
void main() {
get(http://www.stroustrup.com/C++.html;)
.matchAll(`a.*?href=(.*)`)
.map!(m = m[1])
.each!writeln();
}
Requires Phobos PR#2024 ;)
Re: Why doesn't mktspec() use clock_gettime?
On Saturday, 10 January 2015 at 03:17:50 UTC, Andrei Alexandrescu wrote: On 1/9/15 6:13 PM, weaselcat wrote: On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote: cc Sean Kelly https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/config.d#L28 Looks like that use has been disable with static if (false). What was the reason? A coworker spent a few hours debugging a matter that pointed to this issue. He removed the false and replaced CLOCK_REALTIME with CLOCK_MONOTONIC in our druntime tree. Any insight into the matter? How should we address it by supporting multiple clock types portably? Thanks, Andrei https://github.com/D-Programming-Language/druntime/commit/998739c Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andrei I believe it's a POSIX system function, requires librt.
[Issue 13964] InputRange!T doesn't have save method
https://issues.dlang.org/show_bug.cgi?id=13964 --- Comment #3 from Luís Marques l...@luismarques.eu --- (In reply to Ketmar Dark from comment #1) input ranges are not required to have `.save`. this is forward ranges which are: http://dlang.org/phobos/std_range.html#isForwardRange Right. I do know that, zombie mode... --;; --
Re: Utah Valley University is a sponsor of DConf 2015
On 01/09/2015 03:33 PM, MattCoder wrote: a good excuse to take my visa!). :D I encourage everyone to apply for visa as soon as possible. US visa process can be frustratingly delayed depending on many unknown factors. Ali
Re: Why doesn't mktspec() use clock_gettime?
On Fri, 09 Jan 2015 19:17:49 -0800 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1/9/15 6:13 PM, weaselcat wrote: On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote: cc Sean Kelly https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/config.d#L28 Looks like that use has been disable with static if (false). What was the reason? A coworker spent a few hours debugging a matter that pointed to this issue. He removed the false and replaced CLOCK_REALTIME with CLOCK_MONOTONIC in our druntime tree. Any insight into the matter? How should we address it by supporting multiple clock types portably? Thanks, Andrei https://github.com/D-Programming-Language/druntime/commit/998739c Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andrei on older GNU/Linux systems it requires -lrt. it doesn't with relatively new glibc (something that is 1.5 year old is ok, AFAIR), and i see no reasons to be conservative here, but... signature.asc Description: PGP signature
Re: Utah Valley University is a sponsor of DConf 2015
On 1/9/15 3:33 PM, MattCoder wrote: On Friday, 9 January 2015 at 21:10:11 UTC, Andrei Alexandrescu wrote: Please spread the news: https://twitter.com/D_Programming/status/553642281941860352 ... Many thanks to UVU and especially its Computer Science Department Chair, Chuck Allison, who was instrumental in making this happen. Awesome! Questions: 1) There will be no kickstarter this year? No. 2) I'm from another country, and I'd like to participate/attend this year, do you already know about prices for tickets etc? (And this will be a good excuse to take my visa!). :D We haven't yet decided. If you fly from outside North America, travel costs may likely dominate. Andrei
Is it possible to collect object usage information during compilation?
Let me preface this by saying I only have a general conceptual understanding of compilers and know nothing about actual implementation. One common problem with Object-Relational Mapping (ORM) is what data to load and when. There is basically 2 options: 1. Load everything: This certainly works, but is very inefficient, particularly when you have a large number of fields or, even worse, have a derived field that causes a join on one or more tables. If you need all the data this is fine, but most of the time only a small subset is actually used. (lazy loading can mitigate some issues, but introduces other problems) 2. Specify what fields to populate: This can work, but makes more work for the user, adds complexity to user code, and often introduces bugs particularly over time as code changes. Implementation details are leaking into the interface. Basically, I'm looking for a way to look ahead to see what properties on an object are actually referenced (or not referenced) so we know what data needs to be loaded. Simple analysis for things like unused scope variables already exist, but this is needed for properties on each instance of a class (or struct). I guess this would require the compiler to make 2 passes once to trace each object and a second to do something with the data collected. This would potential cost a lot in compilation time so there would probably need to be some sort of annotation on the definition to indicate this type of check is necessary. I might be crazy, but it seems like the compiler has all the information necessary to figure this out and it would make user code simpler, less error prone, and more efficient. So does anybody have any idea on how to actually achieve this? -Dave
Adding UVU as a sponsor
https://github.com/D-Programming-Language/dconf.org/pull/35 Andrei
Wrapping a C library with its own GC + classes vs refcounted structs
Hi all,
I was wondering what's the most D-idiomatic way of dealing with a
C library (or rather writing wrappers for a C library) that does
its own GC via reference counting. The objects are identified and
passed around by integer ids only; most functions like find me
an object foo in object bar return an id and increase a refcount
internally; in rare cases, a borrowed reference is returned.
Whenever refcount drops to zero, the id becomes invalid and the
memory (and possibly the id as well) gets eventually reused. Some
C functions may explicitly or implicitly release IDs so there's
also a problem of tracking whether a live D object refers to a
live C object.
Since the main concern here is wrapping the C library, the only
data that is stored in D objects is the object id, so the objects
are really lightweight in that sense. However, there's a logical
hierarchy of objects that would be logical to reflect in D types
either via inheritance or struct aliasing.
The main question here is whether it's most appropriate in this
situation to use D classes and cross the fingers relying on D's
GC to trigger C's GC (i.e., ~this() to explicitly decrease
refcount in the C library), or use refcounted structs (or
something else?). I think I understand how RefCounted works but
can't see how exactly it is applicable in cases like this or what
are the consequences of using it.
My initial naive guess was to use classes in D to encapsulate
objects (to be able to use inheritance), so the code for the base
class looks along the lines of:
class ID {
protected int id;
private static shared Registry registry;
this(int id) { // assume that refcount was already increased
in C
this.id = id;
registry.store(this); // store weakref to track zombie
objects
}
~this() @nogc {
if (c_is_valid(id) c_refcount(id) 0)
c_decref(id);
registry.remove(this);
}
}
class ConcreteTypeA(ID) { ... }
class ConcreteTypeB(ID) { ... }
where the weak static registry is required to keep track of live
D objects that may refer to dead C objects and has to be
traversed once in a while.
However there's something sketchy about doing it this way since
the lifetimes of objects are not directly controlled, plus there
are situations where a temporary object is only required to exist
in function's scope and is naturally expected to be released upon
exit from the scope.
A related thread:
http://forum.dlang.org/thread/lmneclktewajznvfd...@forum.dlang.org
Re: Why doesn't mktspec() use clock_gettime?
On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote: cc Sean Kelly https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/config.d#L28 Looks like that use has been disable with static if (false). What was the reason? A coworker spent a few hours debugging a matter that pointed to this issue. He removed the false and replaced CLOCK_REALTIME with CLOCK_MONOTONIC in our druntime tree. Any insight into the matter? How should we address it by supporting multiple clock types portably? Thanks, Andrei https://github.com/D-Programming-Language/druntime/commit/998739c
Re: Why doesn't mktspec() use clock_gettime?
On 1/9/15 6:13 PM, weaselcat wrote: On Saturday, 10 January 2015 at 02:03:17 UTC, Andrei Alexandrescu wrote: cc Sean Kelly https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/config.d#L28 Looks like that use has been disable with static if (false). What was the reason? A coworker spent a few hours debugging a matter that pointed to this issue. He removed the false and replaced CLOCK_REALTIME with CLOCK_MONOTONIC in our druntime tree. Any insight into the matter? How should we address it by supporting multiple clock types portably? Thanks, Andrei https://github.com/D-Programming-Language/druntime/commit/998739c Thanks. What library would that be? Is it unavailable on some platforms? If always available, couldn't we just link with it? -- Andrei
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 08:46:41 UTC, Vladimir Panteleev wrote: * I still have reservations about using Disqus. I'm quite happy with the self hosted isso comments on my blog. https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html#isso-thread
[Issue 6574] Erroneous recursive call in template instantiation
https://issues.dlang.org/show_bug.cgi?id=6574 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/cad8d0e8b8201f3ae303241fed62afbb086b7be7 fix Issue 6574 - Erroneous recursive call in template instantiation Improve mangling scheme to distinguish instantiations with specialized template parameters. If a template argument matches to specialized template parameter, the argument is mangled with prefix 'H'. https://github.com/D-Programming-Language/dlang.org/commit/416e78085d70c964c29136fe2707b9efec4c1980 Merge pull request #750 from 9rnsr/fix6574 Issue 6574 - Erroneous recursive call in template instantiation --
Re: For those ready to take the challenge
On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Link to answer in D: http://codegolf.stackexchange.com/a/44417/13362
Re: Revert attributes to their defaults with default keywords
On Friday, 9 January 2015 at 14:26:26 UTC, aldanor wrote:
It could work both ways at the same time.
Maybe even something like default(pred) final(pred) nothrow
-- if pred is compile-time-true, reset all attributes and then
add final/nothrow; if it's compile-time-false, disable final
and enable nothrow.
@disable is also currently a keyword.
pure nothrow @safe @nogc immutable
Test
{
//doSomething is nothrow @safe @nogc immutable
@disable(pure) void doSomething() {}
//getAnInt is pure @nogc immutable
@disable(nothrow, @safe) int getAnInt() {}
//typeof(n) == int
@disable(immutable) int n;
}
This is also useful for templated functions, methods, etc. It
allows one to tell the compiler that the function in question
should never have a particular attribute inferred for it.
//doSomethingElse will never be inferred as pure,
//but may be inferred as nothrow, @safe, or @nogc
@disable(pure) void doSomethingElse()() {}
Why doesn't mktspec() use clock_gettime?
cc Sean Kelly https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/config.d#L28 Looks like that use has been disable with static if (false). What was the reason? A coworker spent a few hours debugging a matter that pointed to this issue. He removed the false and replaced CLOCK_REALTIME with CLOCK_MONOTONIC in our druntime tree. Any insight into the matter? How should we address it by supporting multiple clock types portably? Thanks, Andrei
Re: For those ready to take the challenge
On 1/9/15 6:10 PM, Jesse Phillips wrote: On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Link to answer in D: http://codegolf.stackexchange.com/a/44417/13362 Nailed it. -- Andrei
Re: Utah Valley University is a sponsor of DConf 2015
On Friday, 9 January 2015 at 21:10:11 UTC, Andrei Alexandrescu wrote: Please spread the news: https://twitter.com/D_Programming/status/553642281941860352 ... Many thanks to UVU and especially its Computer Science Department Chair, Chuck Allison, who was instrumental in making this happen. Awesome! Questions: 1) There will be no kickstarter this year? 2) I'm from another country, and I'd like to participate/attend this year, do you already know about prices for tickets etc? (And this will be a good excuse to take my visa!). :D Matheus.
Re: We need a DConf 2015 logo
On 1/9/15 11:08 AM, Adam D. Ruppe wrote: On Friday, 9 January 2015 at 16:05:12 UTC, Andrei Alexandrescu wrote: Folks, I have no tools and no know-how about images. Could someone please upload a png to imgur.com. Thanks. -- Andrei I'm not sure if they wanted to do other changes, but I just resized it to a more reasonable resolution and got the file 10x smaller. http://arsdnet.net/dlogo.png you can do save image as on that Is it just me, or is the page a little bare as compared to dconf2013/14? -Steve
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 15:36:21 + FrankLike via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 09 Jan 2015 13:54:00 + Robert burner Schadek via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via Digitalmars-d-learn wrote: if you *really* concerned with speed here, you'd better consider using regular expressions. as regular expression can be precompiled and then search for multiple words with only one pass over the source string. i believe that std.regex will use variation of Thomson algorithm for regular expressions when it is able to do so. IMO that is not sound advice. Creating the state machine and running will be more costly than using canFind or indexOf how basically only compare char by char. If speed is really need use strstr and look if it uses sse to compare multiple chars at a time. Anyway benchmark and then benchmark some more. std.regex can use CTFE to compile regular expressions (yet it sometimes slower than non-CTFE variant), and i mean that we compile regexp before doing alot of searches, not before each single search. if you have alot of words to match or alot of strings to check, regexp can give a huge boost. sure, it all depends of code patterns. import std.regex; auto ctr = ctRegex!(`(home|office|sea|plane)`); auto c2 = !matchFirst(He is in the sea., ctr).empty; -- Test by auto r = benchmark!(f0,f1, f2, f3,f4,f5)(10_); Result is : filter is 42ms 85us findAmong is 37ms 268us foreach indexOf is 37ms 841us canFind is 13ms canFind indexOf is 39ms 455us ctRegex is 138ms 1. stop doing captures in regexp, this will speedup the comparison. 2. your sample is very artificial. i was talking about alot more keywords and alot longer strings. sorry, i wasn't told that clear enough. signature.asc Description: PGP signature
Re: We're looking for a Linuy Systems Admin!
Iain Buclaw via Digitalmars-d-announce, el 9 de January a las 11:30 me escribiste: On 9 January 2015 at 11:29, Iain Buclaw ibuc...@gdcproject.org wrote: On 9 January 2015 at 11:22, Joseph Rushton Wakeling via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 16:13:24 UTC, Iain Buclaw via Digitalmars-d-announce wrote: The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com. Alternatively, a motivational cover letter and resume will do, too. For now. Tempting, I was wondering if there are any Sysadmin/Devops positions within Sociomantic... :-) Yea, get your certificate of superpowers in! :-) It's January, so I'm doing my annual re-write - no harm in submitting I guess. Though I've never used Linuy before, is it like Linux? :-) Is just a test to see how much candidates are into details. We never have typos, much less make mistakes. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ever tried? Ever failed? - Try again! Fail better!
Re: We need a DConf 2015 logo
On 1/9/15 8:15 AM, Steven Schveighoffer wrote: On 1/9/15 11:08 AM, Adam D. Ruppe wrote: On Friday, 9 January 2015 at 16:05:12 UTC, Andrei Alexandrescu wrote: Folks, I have no tools and no know-how about images. Could someone please upload a png to imgur.com. Thanks. -- Andrei I'm not sure if they wanted to do other changes, but I just resized it to a more reasonable resolution and got the file 10x smaller. http://arsdnet.net/dlogo.png you can do save image as on that Is it just me, or is the page a little bare as compared to dconf2013/14? It's not you, it's me :o). All - contributions to the website dconf.org are gladly welcome. This is a place when a little work can have a big and immediate impact. If half of the energy devoted to just bickering in this group would be put to good use, we could move mountains. Please, we need your work. Thanks. Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/8/15 4:01 PM, Steven Schveighoffer wrote: On 1/8/15 10:41 AM, Andrei Alexandrescu wrote: On 1/8/15 4:18 AM, Steven Schveighoffer wrote: Thoughts? I can put together a pull for core.stdc.* if it makes sense. Blurb LGTM, please make it happen. Also let's experiment with the ///'s. Just to put a semaphore on this, I'm partway through doing this, please don't someone else do it too, it's tedious work :) https://github.com/D-Programming-Language/druntime/pull/1091 -Steve
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 15:57:21 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 09 Jan 2015 15:36:21 + FrankLike via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 09 Jan 2015 13:54:00 + Robert burner Schadek via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via Digitalmars-d-learn wrote: if you *really* concerned with speed here, you'd better consider using regular expressions. as regular expression can be precompiled and then search for multiple words with only one pass over the source string. i believe that std.regex will use variation of Thomson algorithm for regular expressions when it is able to do so. IMO that is not sound advice. Creating the state machine and running will be more costly than using canFind or indexOf how basically only compare char by char. If speed is really need use strstr and look if it uses sse to compare multiple chars at a time. Anyway benchmark and then benchmark some more. std.regex can use CTFE to compile regular expressions (yet it sometimes slower than non-CTFE variant), and i mean that we compile regexp before doing alot of searches, not before each single search. if you have alot of words to match or alot of strings to check, regexp can give a huge boost. sure, it all depends of code patterns. import std.regex; auto ctr = ctRegex!(`(home|office|sea|plane)`); auto c2 = !matchFirst(He is in the sea., ctr).empty; -- Test by auto r = benchmark!(f0,f1, f2, f3,f4,f5)(10_); Result is : filter is 42ms 85us findAmong is 37ms 268us foreach indexOf is 37ms 841us canFind is 13ms canFind indexOf is 39ms 455us ctRegex is 138ms 1. stop doing captures in regexp, this will speedup the comparison. 2. your sample is very artificial. i was talking about alot more keywords and alot longer strings. sorry, i wasn't told that clear enough. Yes. regex doing 'a lot more keywords and a lot longer strings' will be better. Thank you.
Re: NaCl/Emscripten
On Friday, 9 January 2015 at 15:27:08 UTC, Mengu wrote: Don't know if there's any interest but Adam D. Ruppe has hacked DMD to output JavaScript. You should be able to find it somewhere on the newsgroup. guess you're talking about dtojs: https://github.com/adamdruppe/dtojs. I haven't updated that for a long time though, it probably won't work at all anymore and it was never really production ready. I wouldn't try it on a professional job.
Re: An idea for commercial support for D
On Friday, 9 January 2015 at 14:43:02 UTC, Dicebot wrote: On Friday, 9 January 2015 at 12:21:35 UTC, Joakim wrote: To be honest if something like this would ever happen my first move would be to reach company leadership and discuss possible full forking of D compiler as a simple matter of ensuring business safety. This scheme introduces unacceptable amount of risks for customer. I see, so some outside devs selling patches to other companies poses unacceptable risk for your company. Funny how such a stone-age relic move seems to have such an effect on you. ;) In essence, Sociomantic is already running a forked compiler, D1, as it isn't publicly maintained anymore, so I'm not sure what the difference is or why we should care what you do. It poses unacceptable risk of company becoming hostage of ecosystem were buying closed patches is only way to use the tool effectively. In software world where even .NET goes open-source there is simply no reason why would one agree on such terms. See my response to Joe above, most devs rely on closed toolchains. Funny how they all avoid becoming hostages. Right now quite some of other developers contribute to D2 toolchain and related projects even if it is not directly used. It makes sense exactly because project is fully open - there is a good trust that such work won't get wasted and/or abused and sit there until its actually needed, encouraging other people to contribute in the meanwhile. It won't work that way with hybrid model. I don't see how other devs selling paid patches will affect the mentioned aspects of OSS devs working on D. Simply claiming that it won't work that way anymore is not an argument. Selling of software in any for is a relict of stone age and we must help it get forgotten. Funny, how does Sociomantic make money again? Oh right, by selling access to their closed-source software. I guess because it's on a server and the business logic doesn't run on the customer's device, that's _completely_ different from selling of software. ;) Or maybe Sociomantic is about to open source all their code and go pure FOSS! I look forward to the announcement. There are so many ridiculous statements here. 1) Selling services is indeed much different from selling software and much more honest. When you sell a program you don't really sell anything of value - it is just bunch of bytes that costs you nothing to copy. When you sell service you don't just sell access to same software running on the server but continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time. This is actually something of value and charging for that is more widely accepted as just. The only ridiculous statement I see here is your claim that building a desktop/mobile program doesn't also require continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time. Both server and desktop/mobile software are widely considered worth charging for: it is highly idiosyncratic and self-rationalizing for you to claim that one is significantly different from the other. 2) We don't even sell plain service access - it is more delicate than that, exactly to ensure that our client don't feel like product hostages and get encouraged to try with no big commitment. You can contact our sales department for more details ;) You take money and create mostly closed-source software: those are the only details that matter in this discussion. 3) There are indeed plans for open-sourcing at least base libraries we use. It is taking very long because making something public in a way that won't hit you back is damn tricky legally these days and it is blocked in legal department for quite a while. No announcement because no idea how long may it take. Sociomantic has always been generous with the D community, I don't mean to imply you haven't. But unless you open-source all your code, you're employing a hybrid closed-source model, exactly the kind of model you're objecting to here. :) Funny how it's good for Sociomantic but not anybody else. At the same time offering more commercial support is something very desired for business and something I'd like to see extended. Right now pretty much only available option is to reach Walter personally and agree on some contract with DigitalMars which is both limited by manpower of a single person and not advertised in any way. I have no doubt that you'd rather someone worked for you for peanuts on a support contract, rather than making more money off a productized D compiler. But what you should consider is the latter is likely better for D and your preferred approach is not preferred by everybody else. Yes, I am much in favor of paying for actual effort and not helping make money from nothing like it has happened with Microsoft. It both more honest from
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 09 Jan 2015 13:54:00 + Robert burner Schadek via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via Digitalmars-d-learn wrote: if you *really* concerned with speed here, you'd better consider using regular expressions. as regular expression can be precompiled and then search for multiple words with only one pass over the source string. i believe that std.regex will use variation of Thomson algorithm for regular expressions when it is able to do so. IMO that is not sound advice. Creating the state machine and running will be more costly than using canFind or indexOf how basically only compare char by char. If speed is really need use strstr and look if it uses sse to compare multiple chars at a time. Anyway benchmark and then benchmark some more. std.regex can use CTFE to compile regular expressions (yet it sometimes slower than non-CTFE variant), and i mean that we compile regexp before doing alot of searches, not before each single search. if you have alot of words to match or alot of strings to check, regexp can give a huge boost. sure, it all depends of code patterns. import std.regex; auto ctr = ctRegex!(`(home|office|sea|plane)`); auto c2 = !matchFirst(He is in the sea., ctr).empty; -- Test by auto r = benchmark!(f0,f1, f2, f3,f4,f5)(10_); Result is : filter is 42ms 85us findAmong is 37ms 268us foreach indexOf is 37ms 841us canFind is 13ms canFind indexOf is 39ms 455us ctRegex is 138ms
Re: @api: One attribute to rule them All
On Friday, 9 January 2015 at 11:40:28 UTC, Dicebot wrote: I think that push for more inference / WPO is an important goal for D. However I had somewhat more radical and generic changes in mind, ones that don't add new keywords or semantics but rather strictly define what existing ones mean. This was supposed to be turned into a DIP at some point (possibly after consulting with Walter) but here is the draft outline: - separate compilation in basic C sense becomes illegal - minimal legal unit of separate compilation is defined as static library - any time library gets built, it _must_ be distributed with matching .di interfaces. If there are original .d files imported, one must not try to link prebuilt library. This last one is where all the threats from bad linking seem to come from. - .di generation is split in two modes: 1) 'minimal' (API) which only writes exported symbols and ignores even public ones. All inferred attributes gets written explicitly there. This is what gets recommended for public distribution (even if it is source-only distribution) and what defines stable API. 2) 'full' mode which is similar to existing .di generation but with all attributes explicitly written to all functions. It is approach recommended for creating intermediate built artifacts (such as dub building of dependencies). To sum up: All .di function signatures will now be generated with both explicit and inferred attributes. The keyword 'export' will be overloaded with a new meaning, toggled on and off by a compiler flag which generates .di files based on that meaning. Correct? Stability of (1) headers can be validated mechanically by compiler / external tool in such scenario. As you may notice no new keywords / language concepts are proposed, it is only about more strict definition of standard development flow. It also opens well-defined borderline for any WPO. If solving the problem at the level of the command line with the help of the existing 'export' attribute is more flexible and robust, then I'm all for it. The first thing to find out is if anyone will have a problem overloading the meaning of 'export' for this purpose. I can't think of a reason they would, unless people are currently using 'export' in some niche way which would be ruined by the new flag. Needs a lot of work before any serious destruction of course but should give some overall feeling of what I am going at. We both agree that full covariant inference should be the default. It seems like the first step is to introduce it using an opt-in compiler flag (e.g. -infer). I'm not sure how .di files and mangled names should be generated using this flag though. The goal is to get the kinks out of the inference process before making it the default. What's step two, though?
Re: We need a DConf 2015 logo
On 1/9/15 8:08 AM, Adam D. Ruppe wrote: On Friday, 9 January 2015 at 16:05:12 UTC, Andrei Alexandrescu wrote: Folks, I have no tools and no know-how about images. Could someone please upload a png to imgur.com. Thanks. -- Andrei I'm not sure if they wanted to do other changes, but I just resized it to a more reasonable resolution and got the file 10x smaller. http://arsdnet.net/dlogo.png you can do save image as on that Thanks! https://github.com/D-Programming-Language/dconf.org/pull/32 -- Andrei
[Issue 13958] New: RangeError with impure map
https://issues.dlang.org/show_bug.cgi?id=13958
Issue ID: 13958
Summary: RangeError with impure map
Product: D
Version: D2
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: critical
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: john.loughran.col...@gmail.com
//incBug.d
import std.stdio, std.algorithm, std.array;
static a = [a, b, c, d, e, f, g, h, i];
void main()
{
size_t idx = 0;
writeln(a.map!(s = s ~ a[idx++]).joiner(, ));
}
$ rdmd incBud.g
core.exception.RangeError@incBug.d(9): Range violation
5 incBug 0x0001012a0ca1 D6incBug7__arrayZ +
41
6 incBug 0x0001012a1053 nothrow @safe
immutable(char)[]
incBug.main().__lambda1!(immutable(char)[]).__lambda1(immutable(char)[]) + 67
7 incBug 0x0001012a12b4 nothrow @property
@safe immutable(char)[]
std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult.front()
+ 108
8 incBug 0x0001012a213b nothrow @safe void
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result.popFront() + 211
9 incBug 0x0001012a32be void
std.stdio.File.LockingTextWriter.put!(std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result).put(std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result) + 134
10 incBug 0x0001012a322d void
std.range.doPut!(std.stdio.File.LockingTextWriter,
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result).doPut(ref std.stdio.File.LockingTextWriter, ref
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result) + 37
11 incBug 0x0001012a3204 void
std.range.put!(std.stdio.File.LockingTextWriter,
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result).put(ref std.stdio.File.LockingTextWriter,
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result) + 20
12 incBug 0x0001012a2cea void
std.format.formatRange!(std.stdio.File.LockingTextWriter,
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result, char).formatRange(ref
std.stdio.File.LockingTextWriter, ref
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result, ref std.format.FormatSpec!(char).FormatSpec) + 298
13 incBug 0x0001012a2b87 void
std.format.formatValue!(std.stdio.File.LockingTextWriter,
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result, char).formatValue(std.stdio.File.LockingTextWriter,
ref
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result, ref std.format.FormatSpec!(char).FormatSpec) + 47
14 incBug 0x0001012a2b30 void
std.format.formatGeneric!(std.stdio.File.LockingTextWriter,
std.algorithm.joiner!(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).joiner(std.algorithm.__T9MapResultS246incBug4mainFZ9__lambda1TAAyaZ.MapResult,
immutable(char)[]).Result,
char).formatGeneric(std.stdio.File.LockingTextWriter, const(void)*, ref
std.format.FormatSpec!(char).FormatSpec) + 64
15
Re: Game development
On Friday, 9 January 2015 at 06:26:19 UTC, ketmar via Digitalmars-d wrote: On Fri, 09 Jan 2015 05:35:04 + Ras via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thursday, 8 January 2015 at 18:03:48 UTC, ketmar via Digitalmars-d wrote: On Thu, 08 Jan 2015 17:31:49 + NVolcz via Digitalmars-d digitalmars-d@puremagic.com wrote: engines) and why do you want to write the engine in C++ and the logic in D? i bet he thinking that D is a fancy scripting language with native performance. No i dont. I want to use D language for as much as possible. The reason I want to use C++ for the engine is that it always has full support for DirectX. so i was wrong here. i'm sorry. yet you'd better explain your reasons right in the question next time, so other people can jump right to the answering, without guessing first what you *really* want to do and *why*. as you talking about full support for DirectX, i'm supposing that your engine will support 3D environments? so you'd better start with writing the engine itself, and don't think about D here. just don't use things like multiple inheritance or excessive templating. when you'll get a solid working engine, it will be time to discuss how to build D interop with it, exploiting your engine's architecture as much as possible. or just start writing the engine in D. maybe you'll consider using OpenGL instead of DirectX, as we not only have bindings for OpenGL, but OpenGL is much more portable. so eventually your engine may be ported to MacOS X, for example, without rewriting the whole rendering part. Well i had to know if it was possible.
Re: Parameterized enum does not work
On Friday, 9 January 2015 at 07:52:50 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 07:50:53 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 06:17:53 UTC, Andre wrote:
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
What are you trying to do?
OK I probably see it now :):
import std.stdio;
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
writeln(lpad14!(123));
}
However this is only for compile time, if you want runtime
version you need something like this:
import std.stdio;
string lpad(ubyte length)(long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
alias lpad14 = lpad!14;
void main()
{
writeln(lpad14(123));
}
Re: We need a DConf 2015 logo
On Friday, 9 January 2015 at 08:24:40 UTC, Colin wrote: It shouldn't just be similar, it should be the same one I feel. Me too. I don't think a complete re-brand of D is needed for the conference? Changing the logo will mean that all sites containing this logo i.e. main site, wiki's, documentation, blogs, etc. will need to be updated too or major confusion will arise to what exactly this conference is about.
Re: An idea for commercial support for D
On Friday, 9 January 2015 at 04:33:53 UTC, Joakim wrote: I have little idea why you're going into all these detailed business cases that have nothing to do with the two separate concepts I've laid out, but what the hell, I'll bite. Start listing: 1. What alternatives the seller has. 2. What alternatives the buyer has for all likely use scenarios. And you you'll see why your model is either inferior or similar to existing models. Selling patches is basically no different from selling plugins without QA. That's not very attractive. For plugins to work in the market you need a customer that buys incremental upgrades (like musicians who spend all their money on gear hunting for the next big sound). D is not ready for 3., I don't see many using it for that. It's mostly 1. and 2., and they will pay some amount for features or polish they need, though obviously not as much as 3. However, D has been used for 3. at Sociomantic, where they were willing to develop a concurrent GC and other features to make it more capable for their particular use. It is possible that other companies would similarly try to use it for 3. but outsource development of such key features that they need, though unlikely, simply because 3. is just a much bigger bet. You are speaking as if people don't sell customized systems. They do. They sell a customization service or they sell niche products where you negotiate the price with each customer. That way you can give the customer good value and still be able to charge a premium. Make your pricing public and you end up with lower margins and have to sell more. The problem is, if there is a market for more, then there is a market for a new independent product too. This is all general business strategy that has essentially nothing to do with the specific ideas in this thread. I'm not sure what connection you're trying to make. Then read it again. You are writing as if you are offering something new. You are not. So every development tool vendor in the world who gives away a free starter tool and then charges for an upgrade, or even those in-store displays where they let you try out some food for free before you buy more of it, is a drug dealer? Yes, there are some superficial similarities, but I'd call it more try before you buy. Vendors of expensive software ignored (turned a blind eye to) piracy for a long time because it eroded the market for the less expensive competing products and gave themselves increased market share. Then they formed an alliance to address piracy to combat piracy and enforce purchases. Other vendors sell cheap LE versions of their products to erode the market for competitors, then they stop selling LE versions of their product forcing an upgrade to a more expensive product for customers who are then locked in. The differences are in the original post. A regular closed source vendor is simply a collection of developers who pool their patches together and sell them compiled into a closed build of the compiler. In this case, the developers would not all work for a single company, but the customer would still get a build with some assortment of closed patches from some selection of independent paid devs compiled in. Why would a company want to depend on a conglomerate of individuals? No contract, no sale. You need to be accountable if you are going to charge real money. Without being accountable there is no quality. The quality of FOSS is entirely dependent on volume (lots of users testing it). Also, the customer would eventually receive the patches under an OSS license, the boost license which this project uses, after a delay based on a funding and time limit. A regular closed source vendor usually does not do this. But the customer don't want the patches. They want a working tool with support. Building your own tool is more expensive than buying an expensive ready-made. Who are you customers? Define scenarios that are concrete. Without concrete scenarios all you are left with is hand-waving.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
iday, 9 January 2015 at 07:41:07 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 09 Jan 2015 07:10:14 +
FrankLike via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
On Thursday, 8 January 2015 at 15:15:59 UTC, Robert burner
Schadek wrote:
use canFind like such:
bool a = canFind(strs,s) = 1;
let the compiler figger out what the types of the parameter
are.
canFind is work for such as :
bool x = canFind([exe,lib,a,dll],a );
but can't work for
canFind([exe,lib,a,dll],hello.lib);
So I very want to let the function 'indexOfAny' do the same
work.
Thank you.
Frank
be creative! ;-)
import std.algorithm, std.stdio;
void main () {
string fname = hello.exe;
import std.path : extension;
if (findAmong([fname.extension], [.exe, .lib, .a,
.dll]).length) {
writeln(got it!);
} else {
writeln(alas...);
}
}
note the dots in extension list.
yet you can do it even easier:
import std.algorithm, std.stdio;
void main () {
string fname = hello.exe;
import std.path : extension;
if ([.exe, .lib, .a,
.dll].canFind(fname.extension)) {
writeln(got it!);
} else {
writeln(alas...);
}
}
as you obviously interested in extension here -- check only that
part! ;-)
Sorry,it's only a example .Thank you work hard,but it's
not what I want.
'indexOfAny ' function should do this work.
”he is at home ,[home,office,”sea,plane], in
C#,IndexOfAny can do it,what about in D?
I know findAmong can do it,but use two function .
Thank you.
Re: NaCl/Emscripten
On 9 January 2015 at 19:51, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 9 January 2015 at 09:28:22 UTC, Manu via Digitalmars-d wrote: I was gonna start hacking around to see what the limitations are with Emscripten on D code tonight. Has anyone done any serious investigation here? NaCl is a more useful target, but I think that will rely on a special build of LDC... has there been discussion about that before? I have read the standard on ASM.js and some on NaCl. I think you will run into trouble with the GC on both NaCl and ASM.js. If you don't target ASM.js, then you probably could a completely new backend for D that use the standard javascript collector and still get some of the benefits. Remember that only Firefox support ASM.js. I can probably get by with @nogc. There's no threading in asm.js either, so that might be a spanner. Maybe -betterc would be usable out of the box...
Re: We need a DConf 2015 logo
On Thursday, 8 January 2015 at 23:05:22 UTC, Piotrek wrote: The logo with new the perspective (the text) looks nice. I like it. May I ask if there was any inspiration? E.g I see a reference to the Interstallar movie as it was the best movie of 2014 for me ;) http://www.wired.com/wp-content/uploads/2014/09/Interstellar_ALT_Artowrk-660x1030.jpeg I liked Interstellar but that happy ending was so far-fetched I would have preferred the film to end before it. Many inspirations: http://www.pixeljoint.com/files/icons/wizard5__r1195353121.png https://github.com/p0nce/dido/blob/master/resources/dido.png https://medium.com/@erikdkennedy/7-rules-for-creating-gorgeous-ui-part-1-559d4e805cda
Re: D idioms list
On Friday, 9 January 2015 at 05:58:09 UTC, ketmar via Digitalmars-d-announce wrote: p.p.s. maybe it's worth adding Artur's code sample[1] too, to show that extended structure can be passed to functions which requires original one? it's not obvious, at least for me. ;-) [1] http://forum.dlang.org/post/mailman.4332.1420752329.9932.digitalmars-d-annou...@puremagic.com I didn't knew alias this does object slicing. Will add it.
Re: Fastest Way of Accessing Entries in an AA
On Friday, January 09, 2015 07:51:27 Foo via Digitalmars-d-learn wrote:
On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Friday, January 09, 2015 00:20:07 Foo via
Digitalmars-d-learn wrote:
You know, that you kan reuse the result of the in operator by
AAs?
example:
auto ptr = key in aa;
ptr ? *ptr : ValueType.init
This idiom is quite common:
if(auto ptrToValue = key in aa)
{
}
though I'm not sure that that quite fits in with what Nordlow
seems to be
trying to do with init. aa.get probably does a better job of
that, though
looking at the implementation for get, it's basically doing
what you're
suggesting:
auto p = key in aa;
return p ? *p : defaultValue;
though that has the downside of using a lazy parameter for the
default
value, which is convenient but doesn't do great things for
performance.
- Jonathan M Davis
I just wasn't sure that he knows about it.
Oh, he might not have known about it (certainly, the fact that he called in
and then [] in his origanal code implies that he didn't), and it was
definitely useful to tell him. My point was simply that get applies better
for his use case than using in directly. In general though, in is of _far_
more use than [], precisely because it combines asking whether the element
is there and getting it into one command. Personally, I pretty much never
use [] on AAs.
- Jonathan M Davis
Re: We need a DConf 2015 logo
On Friday, 9 January 2015 at 07:25:22 UTC, Jacob Carlborg wrote: On 2015-01-09 03:38, Andrei Alexandrescu wrote: Take a look! http://dconf.org https://github.com/D-Programming-Language/dconf.org/pull/31 The font is different compared to the PNG in the zip. The one on the site has a serif font. I find the new font as fitting as the old one. But the PNG render is too high-res for the web.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 09:36:01 +
FrankLike via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Sorry,it's only a example .Thank you work hard,but it's
not what I want.
'indexOfAny ' function should do this work.
”he is at home ,[home,office,”sea,plane], in
C#,IndexOfAny can do it,what about in D?
I know findAmong can do it,but use two function .
Thank you.
be creative! ;-)
import std.algorithm, std.stdio;
void main () {
string s = he is at plane;
if (findAmong!((string a, string b) = b.canFind(a))([s], [home,
office, sea, plane]).length) {
writeln(got it!);
} else {
writeln(alas...);
}
}
or:
import std.algorithm, std.stdio;
void main () {
string s = he is at home;
if ([home, office, sea, plane].canFind!((a, string b) =
b.canFind(a))(s)) {
writeln(got it!);
} else {
writeln(alas...);
}
}
signature.asc
Description: PGP signature
Re: We need a DConf 2015 logo
On Friday, 9 January 2015 at 07:25:54 UTC, Jacob Carlborg wrote: On 2015-01-08 23:40, ponce wrote: There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change. Shouldn't the logo look at least somewhat similar to the one on dlang.org? It shouldn't just be similar, it should be the same one I feel. The new logo is pretty snazzy though!
NaCl/Emscripten
I'm looking at another potential opportunity to get D into the office, but the target's for this particular project are NaCL and/or Emscripten. I was gonna start hacking around to see what the limitations are with Emscripten on D code tonight. Has anyone done any serious investigation here? NaCl is a more useful target, but I think that will rely on a special build of LDC... has there been discussion about that before? Can any of the LDC guys chime in on the possibility?
Re: Parameterized enum does not work
Thanks a lot.
Kind regards
André
On Friday, 9 January 2015 at 07:59:51 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 07:52:50 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 07:50:53 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 06:17:53 UTC, Andre wrote:
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
What are you trying to do?
OK I probably see it now :):
import std.stdio;
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
writeln(lpad14!(123));
}
However this is only for compile time, if you want runtime
version you need something like this:
import std.stdio;
string lpad(ubyte length)(long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
alias lpad14 = lpad!14;
void main()
{
writeln(lpad14(123));
}
Re: NaCl/Emscripten
On Friday, 9 January 2015 at 09:28:22 UTC, Manu via Digitalmars-d wrote: I was gonna start hacking around to see what the limitations are with Emscripten on D code tonight. Has anyone done any serious investigation here? NaCl is a more useful target, but I think that will rely on a special build of LDC... has there been discussion about that before? I have read the standard on ASM.js and some on NaCl. I think you will run into trouble with the GC on both NaCl and ASM.js. If you don't target ASM.js, then you probably could a completely new backend for D that use the standard javascript collector and still get some of the benefits. Remember that only Firefox support ASM.js.
Re: We need a DConf 2015 logo
On Friday, 9 January 2015 at 08:28:55 UTC, Gary Willoughby wrote: On Friday, 9 January 2015 at 08:24:40 UTC, Colin wrote: It shouldn't just be similar, it should be the same one I feel. Me too. I don't think a complete re-brand of D is needed for the conference? Changing the logo will mean that all sites containing this logo i.e. main site, wiki's, documentation, blogs, etc. will need to be updated too or major confusion will arise to what exactly this conference is about. I have counted the PyCon websites and indeed more than half of them have _some_ reference to the Python logo, either in form or colour. http://pyconuk.org/ http://www.pycon.kr/2014/ What I could do is add two circles like the D logo.
Tuples not working?
import std.stdio;
import std.typecons;
void main()
{
alias TL = Tuple!(int, long, float);
foreach (i, T; TL)
writefln(TL[%d] = %s, i, typeid(T));
}
Why is this not working?
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error:
need 'this' for '_expand_field_0' of type 'int'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error:
need 'this' for '_expand_field_1' of type 'long'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error:
need 'this' for '_expand_field_2' of type 'float'
Tried to compile using dmd 2.066 and dmd 2.067. Code taken
directly from dlang website here (http://dlang.org/tuple.html).
Thanks.
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 12:08 PM, Martin Nowak wrote: On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: One thing that may be misleading about this -- our headers don't include *everything* from C-land. What's missing? They should just match their C counterparts. Andrei had the idea to put the blurb in one place as a macro, so we can change it quite easily if you can think of a better statement. See here: https://github.com/D-Programming-Language/dlang.org/pull/752 -Steve
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 12:08 PM, Martin Nowak wrote: On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: One thing that may be misleading about this -- our headers don't include *everything* from C-land. What's missing? They should just match their C counterparts. Perhaps they do, I don't think we should guarantee it though. For instance, a macro may not be suited to be included in D because we have better options. -Steve
[Issue 13810] ICE in e2ir does not assert
https://issues.dlang.org/show_bug.cgi?id=13810 --- Comment #5 from Steven Schveighoffer schvei...@yahoo.com --- Another case that probably would have slipped through if I hadn't known this :) forum.dlang.org/post/foyqzngnnobtsjkur...@forum.dlang.org --
Re: For those ready to take the challenge
Huh, looking at the answers on the website, they're mostly using regular expressions. Weaksauce. And wrong - they don't find ALL the links, they find the absolute HTTP urls!
Re: For those ready to take the challenge
On Friday, 9 January 2015 at 16:55:30 UTC, Justin Whear wrote:
Was excited to give it a try, then remembered...std.xml :(
Well, as the author of my dom.d, I think it counts as a first
party library when I use it!
---
import arsd.dom;
import std.net.curl;
import std.stdio, std.algorithm;
void main() {
auto document = new Document(cast(string)
get(http://www.stroustrup.com/C++.html;));
writeln(document.querySelectorAll(a[href]).map!(a=a.href));
}
---
prints:
[snip ... http://www.morganstanley.com/;,
http://www.cs.columbia.edu/;, http://www.cse.tamu.edu;,
index.html, C++.html, bs_faq.html, bs_faq2.html,
C++11FAQ.html, papers.html, 4th.html, Tour.html,
programming.html, dne.html, bio.html, interviews.html,
applications.html, glossary.html, compilers.html]
Or perhaps better yet:
import arsd.dom;
import std.net.curl;
import std.stdio;
void main() {
auto document = new Document(cast(string)
get(http://www.stroustrup.com/C++.html;));
foreach(a; document.querySelectorAll(a[href]))
writeln(a.href);
}
Which puts each one on a separate line.
Re: dco how to specify Jpath?
On Sunday, 21 December 2014 at 07:43:14 UTC, FrankLike wrote: On Thursday, 20 November 2014 at 10:48:17 UTC, Suliman wrote: I am playing with dco. And it's look very helpful for tiny projects. I can't understand is it's possible to add to dco.ini Jpath? I am talking about something like: dflags=-JD:\code\d\App1\source\ but when I am trying to compile code with dco it's can't find import. I looked at source code and it's look like it's do not support dflags... https://github.com/FrankLIKE/dco/tree/master/source In dco.ini importPath= -I..\\source // modity it to your source In dco 0.1.0,you can get the 'local.ini' by 'dco -ini'. You can config project in local.
Re: Ready to make page-per-item ddocs the default?
On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: One thing that may be misleading about this -- our headers don't include *everything* from C-land. What's missing? They should just match their C counterparts.
Re: For those ready to take the challenge
On Fri, 09 Jan 2015 13:50:28 +, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking- stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Was excited to give it a try, then remembered...std.xml :(
Re: For those ready to take the challenge
On Fri, 09 Jan 2015 17:18:42 +, Adam D. Ruppe wrote: Huh, looking at the answers on the website, they're mostly using regular expressions. Weaksauce. And wrong - they don't find ALL the links, they find the absolute HTTP urls! Yes, I noticed that. `script src=http://app.js`/script` isn't a hyperlink. Wake up sheeple!
Re: NaCl/Emscripten
On Friday, 9 January 2015 at 12:46:41 UTC, Jacob Carlborg wrote: On 2015-01-09 10:28, Manu via Digitalmars-d wrote: I'm looking at another potential opportunity to get D into the office, but the target's for this particular project are NaCL and/or Emscripten. I was gonna start hacking around to see what the limitations are with Emscripten on D code tonight. Has anyone done any serious investigation here? NaCl is a more useful target, but I think that will rely on a special build of LDC... has there been discussion about that before? Can any of the LDC guys chime in on the possibility? Don't know if there's any interest but Adam D. Ruppe has hacked DMD to output JavaScript. You should be able to find it somewhere on the newsgroup. guess you're talking about dtojs: https://github.com/adamdruppe/dtojs.
Re: Game development
On Friday, 9 January 2015 at 13:22:14 UTC, Mike Parker wrote: On 1/9/2015 2:35 PM, Ras wrote: No i dont. I want to use D language for as much as possible. The reason I want to use C++ for the engine is that it always has full support for DirectX. D has built-in support for COM and can interop with DX just fine. So how can I get started with Directx programming in D? Could you give me a link to maybe a binding or some projects on github?
Re: We need a DConf 2015 logo
On 1/9/15 1:39 AM, ponce wrote: On Friday, 9 January 2015 at 07:25:22 UTC, Jacob Carlborg wrote: On 2015-01-09 03:38, Andrei Alexandrescu wrote: Take a look! http://dconf.org https://github.com/D-Programming-Language/dconf.org/pull/31 The font is different compared to the PNG in the zip. The one on the site has a serif font. I find the new font as fitting as the old one. But the PNG render is too high-res for the web. Folks, I have no tools and no know-how about images. Could someone please upload a png to imgur.com. Thanks. -- Andrei
Re: We need a DConf 2015 logo
On Friday, 9 January 2015 at 16:05:12 UTC, Andrei Alexandrescu wrote: Folks, I have no tools and no know-how about images. Could someone please upload a png to imgur.com. Thanks. -- Andrei I'm not sure if they wanted to do other changes, but I just resized it to a more reasonable resolution and got the file 10x smaller. http://arsdnet.net/dlogo.png you can do save image as on that
Re: Ready to make page-per-item ddocs the default?
On Fri, Jan 09, 2015 at 11:46:47AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. [...] Isn't this caused by the fact that the various *REF*/*LINK* macros insert gratuitous nbsp;'s after the link? I ran into this several times while rewriting std.algorithm docs, and it's very annoying, since it precludes using these macros in many places where I'd like to use them. I've had to rephrase sentences just so the extraneous spaces don't show up in the wrong place. T -- Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton
Re: Ready to make page-per-item ddocs the default?
On 01/09/2015 07:35 PM, Andrei Alexandrescu wrote: Maybe Calypso could be used for that? -- Andrei What's calypso, can't find anything.
Re: An idea for commercial support for D
On Friday, 9 January 2015 at 06:43:01 UTC, Joakim wrote: On Tuesday, 6 January 2015 at 22:37:40 UTC, anonymous wrote: [...] As far as I know there are companies that employ developers to work on open source software, with their patches open-sourced immediately. I'm assuming the employer can direct where exactly the effort goes. That's essentially it, no? A few companies may do that, but he referred to paying for fixes you want right away but getting patches other companies paid for for free. I don't know of any commercial support model where that happens. When two companies hire two different guys to work on the same OSS project, each company pays for the patches of their guy, while getting the patches of the other guy for free. For example, I just googled paid linux developers and came across an article [1] that states: Within that field Red Hat topped that chart with 12% followed by Inte with 8% IBM and Novell with 6% each and Oracle 3%. Despite the clear commercial rivalry between those players central kernel development worked well Corbet noted. Now it might be that they hold back patches for some time to gain an advantage over the competition. But it's my uneducated impression that they don't. [...] Yes, _anything_ you pay for is a competitive advantage for you. He seems to think only the direct features of your product are your competitive advantage, but indirect costs like this also affect the price and overall quality of your product, at least relative to other products in the market, which are just as important. [...] Businesses generally don't sink money into stuff that provides them no competitive advantage. Therefore, the counter-proposal is pure fantasy. I would have guessed that business is happy to invest when the return is right. Business wouldn't say no to making more money just because someone else makes more money, too, would they? Of course, strategic considerations have to be factored in there. Like harming or benefitting a competitor. But also brand image and whatever else. [...] The win for the customer is that they're getting a patch that would not otherwise exist, not sure what's more clear than that. Sure, but this is all about how it's a bigger win than open-sourcing the patch right away. [...] I'm not sure exactly what you by mean by competitors buying patches collectively. If you mean that all the companies pool together and fund OSS development, how do you keep some outlier from not contributing any money, using the resulting OSS code, then undercutting you on price? I assumed that the competitors know each other. That would make it an all-or-none deal. And the obvious choice would be to split the cost. When there may be serious unkown competition, it becomes unfeasible, I guess. [...] I don't know what the minor/occasional contributors think, so who knows how they'd react to such a move, but D could well afford to lose them if it gets several paid devs and some new OSS contributors from the resulting larger D community in return. :) The cost-benefit on that is a no-brainer, you have to go paid. The 'if' is the thing. Lose too many volunteers while attracting not enough business and whoops you're going in the wrong direction. Also, personally I like volunteerism. But that's just me. [...] Since no core dev has expressed any interest in this thread, that is the likely route. But even if they did, no other member of the D community has any claim on their time. Their contributions to D are donations of their time. For a member of the D community to say they can't also sell some of their D-related time to willing buyers is utter nonsense. Again, it's not that anyone has any right to make demands of anyone. Of course, anyone can start their own closed fork of D [2]. But, depending on a thousand details, if the right/wrong people do it, it may hurt the popularity of D. Similarly, if Walter proclaimed that D was a big mistake and that he favours Go or Rust or whatever now, no one has any right to demand he keeps working on D, but it would probably be a bad move for the popularity of D. [1] http://apcmag.com/linux-now-75-corporate.htm [2] As far as the involved licences allow for that. Not a lawyer. Not legal advice. etc. yadda yadda
Cast a struct to void*
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type S
to type void*
}
Is there are a good reason for this being disallowed?
Re: Cast a struct to void*
On Friday, 9 January 2015 at 18:25:42 UTC, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type
S to type void*
}
Is there are a good reason for this being disallowed?
You'd expect `cast(void*)s == s.p`? That doesn't work for any
type of p. You can do it with a slightly fancier (and more
dangerous) cast: `*cast(void**)s`.
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 10:10 AM, Steven Schveighoffer wrote: On 1/9/15 12:08 PM, Martin Nowak wrote: On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: One thing that may be misleading about this -- our headers don't include *everything* from C-land. What's missing? They should just match their C counterparts. Perhaps they do, I don't think we should guarantee it though. For instance, a macro may not be suited to be included in D because we have better options. Maybe Calypso could be used for that? -- Andrei
Re: Cast a struct to void*
On 01/09/2015 10:25 AM, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type S to
type void*
}
Is there are a good reason for this being disallowed?
I know two options:
a)
alias p this;
b)
auto opCast(T : void*)()
{
return p;
}
Ali
Re: Cast a struct to void*
On Friday, 9 January 2015 at 18:35:56 UTC, anonymous wrote:
On Friday, 9 January 2015 at 18:25:42 UTC, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type
S to type void*
}
Is there are a good reason for this being disallowed?
You'd expect `cast(void*)s == s.p`? That doesn't work for any
type of p.
I was expecting it to work regardless of the type of p. I have an
8 byte (on x86_64) struct which I want to reinterpret as a void*
You can do it with a slightly fancier (and more dangerous)
cast: `*cast(void**)s`.
Yuk. Better than nothing though. Thanks :)
Re: Tuples not working?
On 01/09/2015 10:42 AM, Jonathan Marler wrote:
import std.stdio;
import std.typecons;
void main()
{
alias TL = Tuple!(int, long, float);
foreach (i, T; TL)
writefln(TL[%d] = %s, i, typeid(T));
}
Why is this not working?
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error: need
'this' for '_expand_field_0' of type 'int'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error: need
'this' for '_expand_field_1' of type 'long'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error: need
'this' for '_expand_field_2' of type 'float'
Tried to compile using dmd 2.066 and dmd 2.067. Code taken directly
from dlang website here (http://dlang.org/tuple.html). Thanks.
Broken documentation presumable because the feature changed later on.
The code works if you we std.typetuple.TypeTuple:
import std.stdio;
import std.typetuple;
void main()
{
alias TL = TypeTuple!(int, long, float);
foreach (i, T; TL)
writefln(TL[%d] = %s, i, typeid(T));
}
Ali
Re: Cast a struct to void*
On 1/9/15 1:50 PM, John Colvin wrote:
On Friday, 9 January 2015 at 18:35:56 UTC, anonymous wrote:
On Friday, 9 January 2015 at 18:25:42 UTC, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type S to
type void*
This is actually a compiler bug! I will check to make sure it's not
already filed, and file if it's not. However, I don't think the code
should work, it just shouldn't print e2ir.
}
Is there are a good reason for this being disallowed?
You'd expect `cast(void*)s == s.p`? That doesn't work for any type of p.
I was expecting it to work regardless of the type of p. I have an 8 byte
(on x86_64) struct which I want to reinterpret as a void*
You can do it with a slightly fancier (and more dangerous) cast:
`*cast(void**)s`.
Yuk. Better than nothing though. Thanks :)
This is what reinterpret_cast from C++ does.
-Steve
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 10:46 AM, Steven Schveighoffer wrote: On 1/9/15 12:08 PM, Martin Nowak wrote: On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: One thing that may be misleading about this -- our headers don't include *everything* from C-land. What's missing? They should just match their C counterparts. Andrei had the idea to put the blurb in one place as a macro, so we can change it quite easily if you can think of a better statement. See here: https://github.com/D-Programming-Language/dlang.org/pull/752 Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei
Re: Bare-metal programming in D (was GSOC - Holiday Edition)
09-Jan-2015 05:07, Mike пишет: On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky wrote: Truth be told none of listed in this thread feel fundamental to me. It looks more like a set of patches to each specific problem in the compiler or run-time. Yeah, run-time would better be more customizable, but it's just our *current* run-time it's not the language. Perhaps high-impact would be a better word than fundamental. I think moving runtime hooks out of the compiler to .di files and Adam Ruppe's proposal to move TypeInfo to the runtime are great ideas. These are good. I expect more customization points to come as bare-metal stuff moves along. high-impact - I'm not sure I follow? Nobody would notice much except those messing with the compiler and custom run-times. The change itself might be a couple dozen of lines worth. I could understand horror that tweaking something in a compiler may instill but D's compiler is rapidly evolving. I see nothing fundamental in how it depends on run-time and vise-versa, everything is tweakable and we break binary compatibility (and not only that) with every release. Enhancement 11666 [1] is another. That really highlighted a design problem in the runtime for me. If the runtime had better separation of language, platform (OS and architecture) and library, the ports would simply have their own folder in the runtime rather than their own repository. The controversy that followed the pull requests in an attempt address 11666 clearly shows the problems that high coupling to the platform can cause. If the platform were encapsulated and decoupled from the language implementation, we'd already be well on our way. [1] - https://issues.dlang.org/show_bug.cgi?id=11666 This issue mostly affects embedded targets that run full-fledged OS. Somehow I see it as a minor issue. No matter how we pile up platform-specific headers - somebody got to put it somewhere. A couple of conventions were discussed with various drawbacks. Many C projects do this in ad-hoc fashion and survive just fine. There is no inherent design problem or something unfixable - we just need more ports. Also I'm thinking that bare-metal stuff would simply have its own run-time complying with some _spec_ of what compiler expects. Working out that spec and importantly language feature sets would be awesome. But I've been watching how such changes are perceived here, and I'm skeptical they would be accepted because so much in the language is potentially affected by them. We can just ask for them again and see. It's important to voice concerns because there is so much of stuff going on that some important issues may easily slip under radar. What usually works best in prioritizing stuff is highlighting that some actual project is having a problem with issue X, Y and Z. Due to the fact that they only benefit a few bare-metal folks, but impact the full language Again I'm not sure how? In fact nobody would notice a damn thing. Layout of internals of D run-time are just that. A toolkit will need to provide e.g build/fetch with a bootstrap script: - a ready to-go D cross-compiler(s) might be with some patches to disable language features for better experience etc. That's more-or-less what I've suggested in this thread. If that happened, I could get behind the items you listed below. But I don't know how to proceed with the compiler, that's not my interest nor within my current ability. Johannes has been exploring this territory, however, which is encouraging. Great. This helps me understand what is the main impediment at the moment. With that in mind I think we can formulate our GSOC plan better. As far as I can tell it can focus on 2 paths: a) Get embedded-savy student to work on MCU support and stuff while delegating most compiler tweaks to mentor(s) and core team. b) Get a student interested in compilers to deliver on getting robust cross-compiler with minimal run-time. Getting actual boards to work is then delegated to mentors. I am in favor of a). - a stripped run-time instead of Phobos (come on C/C++ folks use something much unlike standard library either) - linker scripts for a (growing) set of MCUs - I/O library and register definitions for MCUs (preferably a tool to auto-generate such) - a modified driver that passes all kinds of right options for a given MCU That's a minimum for other Bare Metal D projects to even start to take off. Ideally other tools include debugger, high-level libraries for peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and so on. Let me add that I think the -betterC switch, or similar, is too blunt an instrument. I'd like to have the flexibility to fine tune the language features (even on individual types) for the platform and/or application I'm building. And while compiler switches and attributes may help, I think delegating features from the compiler to the runtime is a better
Re: Ready to make page-per-item ddocs the default?
On Friday, 9 January 2015 at 20:00:27 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Jan 09, 2015 at 11:46:47AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. [...] Isn't this caused by the fact that the various *REF*/*LINK* macros insert gratuitous nbsp;'s after the link? I ran into this several times while rewriting std.algorithm docs, and it's very annoying, since it precludes using these macros in many places where I'd like to use them. I've had to rephrase sentences just so the extraneous spaces don't show up in the wrong place. T In this case there is a span class=pln /span that is 16px wide and occupies exactly the space you want to get rid of. It only shows up when viewing the HTML using the Chrome developer tools (F12). It's not in the page source.
Re: Ready to make page-per-item ddocs the default?
On 01/09/2015 09:29 PM, Tobias Pankrath wrote: In this case there is a span class=pln /span that is 16px wide and occupies exactly the space you want to get rid of. It only shows up when viewing the HTML using the Chrome developer tools (F12). It's not in the page source. It's highlighted as D source.
Rust 1.0 alpha
Rust is moving towards stability: «The alpha release is part of our transition into stability guarantees. While we’re not ready to make full stability guarantees yet, this release cycle moves us much closer to that 1.0 goal. When 1.0-beta1 is released six weeks from now, these important remaining APIs will be stable. Code that compiles on the beta release should do so with minimal changes on 1.0 final as well.» http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 12:35 PM, Martin Nowak wrote: On 01/09/2015 09:29 PM, Tobias Pankrath wrote: In this case there is a span class=pln /span that is 16px wide and occupies exactly the space you want to get rid of. It only shows up when viewing the HTML using the Chrome developer tools (F12). It's not in the page source. It's highlighted as D source. Found Waldo. Please review. https://github.com/D-Programming-Language/dlang.org/pull/756 -- Andrei
Re: Bare-metal programming in D (was GSOC - Holiday Edition)
On Friday, 9 January 2015 at 20:24:55 UTC, Dmitry Olshansky wrote: Great. This helps me understand what is the main impediment at the moment. With that in mind I think we can formulate our GSOC plan better. As far as I can tell it can focus on 2 paths: a) Get embedded-savy student to work on MCU support and stuff while delegating most compiler tweaks to mentor(s) and core team. b) Get a student interested in compilers to deliver on getting robust cross-compiler with minimal run-time. Getting actual boards to work is then delegated to mentors. I am in favor of a). I've found that I can only get so far with a), unless you are willing to be rather tolerant with what D currently offers. It could be enough for a summer project, though, and I suppose it could help highlight some of D's current shortcomings in this domain. Eventually, though, a) will need b), and I think b) cannot be done properly without changes in the compiler. Mike
Re: Ready to make page-per-item ddocs the default?
On 2015-01-09 20:46, Andrei Alexandrescu wrote: Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei Is it just me or are the actual declarations missing? -- /Jacob Carlborg
Please merge
https://github.com/D-Programming-Language/dconf.org/pull/32 -- thanks! Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 11:58 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Jan 09, 2015 at 11:46:47AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. [...] Isn't this caused by the fact that the various *REF*/*LINK* macros insert gratuitous nbsp;'s after the link? No, I looked; I think it's because of the newline thereafter. -- Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 12:59 PM, Jacob Carlborg wrote: On 2015-01-09 20:46, Andrei Alexandrescu wrote: Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei Is it just me or are the actual declarations missing? Oh yah :o). Steve? -- Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 1:18 PM, Andrei Alexandrescu wrote: On 1/9/15 1:17 PM, Andrei Alexandrescu wrote: On 1/9/15 12:59 PM, Jacob Carlborg wrote: On 2015-01-09 20:46, Andrei Alexandrescu wrote: Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei Is it just me or are the actual declarations missing? Oh yah :o). Steve? -- Andrei http://dlang.org/library-prerelease/core/stdc/errno.html does list the enum values. -- Andrei ... albeit wrongly: https://issues.dlang.org/show_bug.cgi?id=13961 -- Andrei
Utah Valley University is a sponsor of DConf 2015
Please spread the news: https://twitter.com/D_Programming/status/553642281941860352 We're happy to announce the first sponsor of DConf 2015: Utah Valley University. In addition to providing conference venue, UVU will cover room rental fees and simplify logistics and paperwork. Many thanks to UVU and especially its Computer Science Department Chair, Chuck Allison, who was instrumental in making this happen. This is great news, and hopefully a precedent to be followed. Thanks, Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 1:17 PM, Andrei Alexandrescu wrote: On 1/9/15 12:59 PM, Jacob Carlborg wrote: On 2015-01-09 20:46, Andrei Alexandrescu wrote: Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei Is it just me or are the actual declarations missing? Oh yah :o). Steve? -- Andrei http://dlang.org/library-prerelease/core/stdc/errno.html does list the enum values. -- Andrei
One more easy task for the website
Pliz pliz. https://issues.dlang.org/show_bug.cgi?id=13962 Andrei
[Issue 13962] New: http://dlang.org/phobos/object.html is formatted with the old style
https://issues.dlang.org/show_bug.cgi?id=13962 Issue ID: 13962 Summary: http://dlang.org/phobos/object.html is formatted with the old style Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: and...@erdani.com The jump anchors don't look like Phobos'. --
Re: An idea for commercial support for D
On Wednesday, 7 January 2015 at 02:08:45 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote: On 06/01/15 07:14, Joakim via Digitalmars-d wrote: I don't think such people matter, ie they're a very small but vocal minority. Also, these people are deeply irrational, as every piece of hardware they're using comes with many closed binary blobs. They are either ignorant of this fact or just choose to make silly demands anyway. This is a pretty bad habit you have, to just dismiss people rather than to try and understand the substance and detail of their concerns and requirements. You seem to see non-free is a deal-breaker as some sort of fundamentalist position. That's because it _is_ a fundamentalist position, that almost nobody holds. You yourself point out that you don't hold it, because you're perfectly willing to use linux with binary blobs. The only bad habit I see here is your repeated imposition of such a silly position on D, despite my repeatedly engaging with the substance and detail of the issues you raise and pointing out all the flaws with such thinking. In fact, it's almost invariably contextual and highly dependent on the particular use-case and the particular needs that someone has in a particular piece of software. For example, I'm not particularly happy about the existence of binary blobs or drivers in my Linux kernel, but it has very little practical effect on my ability to use Linux-based OS's, the sustainability of Linux development, or its reliability as a platform. It's mostly a PITA for the kernel devs themselves and distro manufacturers who have to debug problems caused by these proprietary components. So your point is that non-free is _not_ a deal-breaker when it comes to the OS or some other tech further down the stack, which doesn't _directly_ impinge on your commercial and product goals like a compiler does. That's perfectly pragmatic, but it doesn't sound like non-free is really a deal-breaker for you, maybe just for certain key tools. But by contrast I would be extremely reluctant to base my software business around a development toolchain with proprietary components, or where I feared that might become part of the toolchain's business model in future. Why? Because that enables someone else, whose interests may be different to mine, to exert control over my ability to fulfil my commercial and product goals. The moment you accept a proprietary component into your toolchain, you're at risk of Pay us more or we stop supporting this thing you are dependent on, and because it's proprietary, you simply don't have the same options to find another supplier. That's not zealotry or moralism or absolutist, it's basic business sense, and it's not a hard decision to reach when there are so many excellent free development toolchains out there, whose development models are _not_ based on limiting access to new features or fixes. That _is_ zealotry: it's so paranoid that it's _not_ basic business sense for the vast majority of developers who employ proprietary toolchains, like MS Visual Studio or Embarcadero. The way the bulk of devs avoid the Pay us more or we stop support problem is by using programming languages with a common spec and with multiple competing commercial implementations, so they can always switch compilers. Switching is certainly not costless, but it puts a cap on how much your original compiler vendor can extort you, because if the cost of switching is less than their extortion attempt, you'll switch. Also, the ultimate deterrent to such potential extortion is all the other customers who'd then switch when you publicized such behavior, as they know they'd be next to receive such a shakedown. In any case, I suggest you reread the linked Phoronix article from my original post where I wrote about the benefits of such hybrid models. One of the major benefits of hybrid models is that if you don't like what a vendor is doing, you can still fork their OSS code. So if one paid D compiler vendor tried to pull such a move on you, there would very likely be other vendors you could easily switch to. :) Heh, the whole point of the sarcastic comment was to point out the obvious conflict in their position. :) There isn't any conflict in their position. If you don't see it, that's probably because you don't perceive some important distinctions that they are concerned with ... This would mean something if you would lay out why there's no conflict, rather than hand-waving about important distinctions that you don't know either. Since you can't, I must be right. :) Most commercial adopters are going to consider it very important to have a support option that says, If you have a serious blocker, you can pay us money to guarantee that it gets fixed. They are not going to be at all happy about a support option that says, If we develop a fix, then you are not going to get it in a timely
Re: NASA/JPL Rules for writing Critical Software
Walter Bright newshou...@digitalmars.com wrote in message news:m8n4c2$2ovq$1...@digitalmars.com... http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf Misra is also a good set of guidelines to follow... http://www.misra.org.uk/ -=mike=-
Re: DConf 2015 Call for Submissions is now open
On Thursday, 8 January 2015 at 10:31:58 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 6 January 2015 at 23:24, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Hello, Exciting times! DConf 2015 will take place May 27-29 2015 at Utah Valley University in Orem, UT. Awesome, that runs over my birthday (28th). My friends and family won't be too pleased. :-) Iain Hey that is my birthday as well :) Same deal.
Re: Alignment of dynamic arrays
Robert burner Schadek: IMO, If you slice a double array it is always aligned. Because doubles are 8 bytes long aka 64bit which would align them to every fourth 16bit boundary. If you have a 16-byte aligned array of doubles and you slice the first double away, what's the alignment of the result? Bye, bearophile
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 2:14 AM, Jacob Carlborg wrote: On 2015-01-08 22:01, Steven Schveighoffer wrote: core.stdc.config is not technically a standard C header, and it seems pretty strange. I'm going to leave that one alone unless someone objects. Shouldn't this then be documented like any other druntime/Phobos module. Sure, that is fine by me. But I'm not going to do it, as I don't know what it's for :) -Steve
Re: Alignment of dynamic arrays
On 1/9/15 6:08 AM, Robert burner Schadek wrote: On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote: Luc Bourhis: With auto a = new double[1000], is there any guarantee that a.ptr is aligned on a 16-byte boundary? Arrays are aligned on a 16-byte. But if you slice them, this alignment can be broken. IMO, If you slice a double array it is always aligned. Because doubles are 8 bytes long aka 64bit which would align them to every fourth 16bit boundary. not 16 bit, 16 byte. -Steve
∅MQD 1.0.0-alpha released - now with full ∅MQ 4.0 support
∅MQD is a D library that wraps the low-level C API of the ∅MQ (aka. ZeroMQ) messaging framework. It is a rather thin wrapper that maps closely to the C API, while making it safer, easier and more pleasant to use. The API is designed to feel familiar to existing ∅MQ users, yet natural to D users. With this release, the latest stable ∅MQ version (4.0.x) is supported in full, including the new security mechanisms. I'm going to let it linger in the alpha release stage for a while, in the hope that you guys will try it out and give me some feedback and bug reports. Please let me know of any issues via the GitHub issue tracker. For more information, check out the following links. GitHub/README: https://github.com/kyllingstad/zmqd API docs: https://kyllingstad.github.io/zmqd/zmqd.html DUB package:http://code.dlang.org/packages/zmqd
Re: We're looking for a Linuy Systems Admin!
On Friday, 9 January 2015 at 11:30:23 UTC, Iain Buclaw via Digitalmars-d-announce wrote: Though I've never used Linuy before, is it like Linux? :-) Lack of post editing capabilities in NG ensures our shame will be eternal :)
Re: NASA/JPL Rules for writing Critical Software
On Friday, 9 January 2015 at 10:37:43 UTC, Mike James wrote: Walter Bright newshou...@digitalmars.com wrote in message news:m8n4c2$2ovq$1...@digitalmars.com... http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf Misra is also a good set of guidelines to follow... http://www.misra.org.uk/ -=mike=- The interesting part of those rules is that in the end, C + rules + static analyzer ends up being the type of language that the C designers decided to ignore. -- Paulo
Re: An idea for commercial support for D
You have already proposed this idea once and were explained in great detail why it doesn't work. To be honest if something like this would ever happen my first move would be to reach company leadership and discuss possible full forking of D compiler as a simple matter of ensuring business safety. This scheme introduces unacceptable amount of risks for customer. Selling of software in any for is a relict of stone age and we must help it get forgotten. At the same time offering more commercial support is something very desired for business and something I'd like to see extended. Right now pretty much only available option is to reach Walter personally and agree on some contract with DigitalMars which is both limited by manpower of a single person and not advertised in any way. This is same issue as one that was mentioned when discussing vibe.d - having clearly communicated option to get a paid support to fix any issues you may encounter is possible deal-breaker for anyone considering risks of putting bet on D for next project.
Re: An idea for commercial support for D
On Friday, 9 January 2015 at 11:40:47 UTC, Joakim wrote: Perhaps you're not a native speaker of the English language, but it is difficult to follow all the logical leaps you're making, as one point seems completely disconnected from the other and none seem connected to the topics from this thread. I expect you to connect the dots when they are obvious. But that's just distracting to those of us who are only interested in the narrow topic under discussion. Where you stick to the topic, I've often agreed with you. Everything needs a context, and you need to try connect the dots. You don't seem particulary interested in making the connections. But you are not the only person in the D forums who are struggling with the bigger picture. Which is why D probably never will be finished.
Revert attributes to their defaults with default keywords
I often have code like this:
class A {
final:
nothrow:
...
some methods
...
}
Problem comes when I need add methods which for eg.: throws or
need to be virtual.
I can put them before final: but this is not perfect, because I
prefer when methods are place in specific order (method abc call
method asd so asd is bellow abc and so on).
So today I download dmd source and make some small modification
(only few lines) and this is the result:
http://dpaste.dzfl.pl/472afc938397
