Re: Benchmark block
On 2015-03-31 19:05, Jonathan wrote: Well, I don't consider benchmarks a kind of unit test. So maybe just this: It depends on how you look at it. I know Xcode has support for some kind of unit test benchmark. You can assign a upper value to a benchmark and if that value is exceed the benchmark will fail. Kind of like a unit test but it asserts on how long it takes to execute instead of some functionality. -- /Jacob Carlborg
Re: How to avoid code duplication?
Rikki, could you explain? I did not understand where it can help me
Re: How to avoid code duplication?
On 1/04/2015 7:19 p.m., Suliman wrote:
Rikki, could you explain? I did not understand where it can help me
Here is some example code. While I've only implemented one
InputRange!string instance. You would probably have one, for just zip's
and another raw text files. Keep in mind it returns only a single line
from standard input.
In other words, let the range handle reading a line from a file.
import std.range;
import std.stdio;
class Range : InputRange!string {
private {
string buffer;
}
this() {
popFront;
}
@property {
string front() {
return buffer;
}
bool empty() {
return false;
}
}
void popFront() {
buffer = readln();
}
string moveFront() {
string ret = front();
popFront();
return ret;
}
int opApply(int delegate(string) del) {
int result;
while(!empty()) {
result = del(moveFront());
if (result)
break;
}
return result;
}
int opApply(int delegate(size_t, string) del) {
int result;
size_t offset;
while(!empty()) {
result = del(offset, moveFront());
if (result)
break;
offset++;
}
return result;
}
}
void myfunc(InputRange!string input) {
foreach(line; input) {
writeln(GOT [line]: , line);
}
}
void main() {
InputRange!string theRange = new Range();
myfunc(theRange);
}
Re: Travis CI based tests based on 2.066.1 start failing
2015-03-31 14:57 GMT+02:00 Baz via Digitalmars-d digitalmars-d@puremagic.com: On Tuesday, 31 March 2015 at 12:31:14 UTC, Mathias Lang wrote: Importing std.algorithm.searching won't work before. A static if (__VERSION__ = 2067) / else would solve it. 2015-03-31 13:20 GMT+02:00 Baz via Digitalmars-d digitalmars-d@puremagic.com: On Tuesday, 31 March 2015 at 09:52:34 UTC, Baz wrote: @MartinNowak, @klickverbot and @ibuclaw Is is time for 2.067 ? source: https://github.com/kiith-sa/dmarkdown/pull/6 Well...do you get (understand) that I only suggest that Travis should now use 2.067 ? You can use 2.067 by specifying it explicitly (there has already been discussion on this NG). And if you want the default to be 2.067: https://github.com/travis-ci/travis-build/pull/418
Re: DMD compilation speed
Jake The Baker wrote in message news:bmwxxjmcoszhbexot...@forum.dlang.org... As far as memory is concerned. How hard would it be to simply have DMD use a swap file? This would fix the out of memory issues and provide some safety(at least you can get your project to compile. Seems like it would be a relatively simple thing to add? It seems unlikely that having dmd use its own swap file would perform better than the operating system's implementation.
Re: How to avoid code duplication?
On 1/04/2015 6:15 p.m., Suliman wrote:
The situation is next:
I have got the function that get arrays of lognames and logfullname:
void loginsert(string [] lognames, string [] logfullname)
{
if(logfullname[i].endsWith(txt))
{
auto file = File(logfullname[i], r);
foreach (line; file.byLine)
{
// long manupulation with strings
}
}
}
But now need add supporting passing to function not only txt files, but
also zip archives.
The problem that now I see only one way to do adding zip -- add block:
if(logfullname[i].endsWith(zip))
And in it do everything with unpacking content of archive like:
foreach(ArchiveMember am; zip.directory)
{
string file = cast(string)zip.expand(am);
foreach (line; file.lineSplitter())
{
}
}
and put inside it some same content that I am doing in long
manupulation with strings.
Maybe there is any better way? But I really can't understand it because
auto file = File(logfullname[i], r); can't read unpacked content of
archive.
Use InputRange!string aka an input range which gives you elements. It
can wrap up the behavior for getting the values.
Re: DIP66 1.2 (Multiple) alias this. Continuation of work.
On 2015-03-31 22:01, Andrei Alexandrescu wrote: I made a few editorial passes, no major changes. I think there's still a fly in the ointment. The resolution algorithm goes: 1. If xyz is a symbol (member, method, enum etc) defined inside typeof(obj) then lookup is done. 2. Otherwise, if xyz is a symbol introduced in the base class (where applicable), then lookup is done. 3. Otherwise, if opDispatch!xyz exists, then lookup is done. 4. Otherwise, alias this is attempted transitively, and if xyz is found, then lookup is done. 5. Otherwise an UFCS rewrite is effected. This puts opDispatch in between inheritance and subtyping, which I think we discussed is inappropriate - alias this should be effectively subtyping. If we're really convinced alias this means multiple subtyping, the inherited type should not have a special role. However, it simplifies a lot of things to give one particular subtype a leg up on all others. So I think this would work: 1. If xyz is a symbol (member, method, enum etc) defined inside typeof(obj) then lookup is done. 2. Otherwise, if xyz is a symbol introduced in the base class (where applicable), then lookup is done. 3. Otherwise, if xyz is found at least via either an opDispatch!xyz or alias this conversion, then lookup is done. 4. Otherwise an UFCS rewrite is effected. Should opDispatch or alias this ever be looked up in the base class? -- /Jacob Carlborg
Re: How to avoid code duplication?
Maybe there is way to access of element of archive in the same way as to txt file? I looked, but it's seems that constructor accept only path to file. But I can't understand how to set path to unpacked element of archive.
Re: unittests are really part of the build, not a special run
On 2015-03-31 23:12, Atila Neves wrote:
I actually thought about the whole it should fail to build if any of
the unit tests fail idea 2 or 3 weeks ago, so this sounds good.
WRT to the error messages and their recognition by text editors, a
_massive_ improvement would be compiler-assisted formatting of the
assertion errors. This:
core.exception.AssertError@foo.d(2): Assertion failure
Is not useful when I wrote `assert(foo == 2)`. This, however, is:
tests.encode.testEncodeMoreThan8Bits:
tests/encode.d:166 - Expected: [158, 234, 3]
tests/encode.d:166 - Got: [158, 234]
In Python, my favourite testing framework is py.test. It reflects on the
test code itself and replaces `assert foo == 2` with its own code so
that it looks like this in the output:
def test_foo():
foo = 5
assert foo == 2
E assert 5 == 2
It also recognises things like `assert x in xs`, which is obviously
handy. Since Walter has mentioned the specialness of assert before,
maybe the compiler could recognise at least the most common kinds and
format accordingly (assert ==, assert in, assert is null, assert !is null)?
I kind of agree, RSpec has similar formatting of failed tests. But I
leaning to that this should be handled by a library. RSpec has a lot of
matchers (assertions) and supports custom matchers as well. For example,
for associative arrays RSpec will print a diff of the two objects.
For example, the following test:
describe 'Foo' do
it 'bar' do
{ foo: 3, bar: 4, baz: 5 }.should == { foo: 3, bar: 4, baz: 6 }
end
end
Will print the following failures:
Failures:
1) Foo bar
Failure/Error: { foo: 3, bar: 4, baz: 5 }.should == { foo: 3, bar:
4, baz: 6 }
expected: {:foo=3, :bar=4, :baz=6}
got: {:foo=3, :bar=4, :baz=5} (using ==)
Diff:
@@ -1,4 +1,4 @@
:bar = 4,
-:baz = 6,
+:baz = 5,
:foo = 3,
# ./spec/text_mate/helpers/options_helper_spec.rb:6:in `block (2
levels) in top (required)'
It also prints the comparison operator used.
--
/Jacob Carlborg
Re: I submitted my container library to code.dlang.org
On Tuesday, 31 March 2015 at 21:17:04 UTC, Martin Nowak wrote: Robin Hood sounds like a good idea, but it really isn't. Keep your load factor reasonable and distribute values evenly, then you don't need a LRU lookup. Is there a D version of a hash table with open addressing and quadratic probing? It would be interesting to compare speeds. I like Robin Hood for cache-friendliness, and it works quite well for many combinations of key-value types.
Re: The dmd.conf rant
ketmar wrote in message news:mfft3m$2uuc$6...@digitalmars.com... actually, the fix is very easy: ditch idgen.d in favor of old idgen.c, and patch makefile. both can be done automatically (i did). whoa, i can build DMD without problems again! Not exactly a long-term solution.
Re: The dmd.conf rant
Martin Nowak wrote in message news:mffl5h$107q$1...@digitalmars.com... ### conclusion The lookup order for the config file should be changed to the following. - next to dmd binary (highest precedence so that I can have multiple installations) - per-user conf folder (HOME) (to override the system-wide config) - system-wide conf folder (to allow package installations .deb/.rpm) The current situation is unmaintainable. I agree, although I'm pleased that it's at least _possible_ to manually choose a specific dmd.conf now. Another thing that seems to be missing is a way to say only look at the dmd.conf in the same dir as the binary. That wouldn't be perfect, but would make it a lot easier.
Re: DMD compilation speed
On Wednesday, 1 April 2015 at 04:51:26 UTC, weaselcat wrote: On Wednesday, 1 April 2015 at 04:49:55 UTC, ketmar wrote: On Wed, 01 Apr 2015 02:25:43 +, Random D-user wrote: GC because of some low-end machines. Memory is really cheap these days and pretty much every machine is 64-bits (even phones are trasitioning fast to 64-bits). this is the essense of modern computing, btw. hey, we have this resource! hey, we have the only program user will ever want to run, so assume that all that resource is ours! what? just buy a better box! google/mozilla's developer mantra regarding web browsers. They must have an agreement with DRAM vendor, I see no other explanation...
Re: DWT fails to build with DMD 2.067.0
On Tuesday, 31 March 2015 at 19:54:27 UTC, Jacob Carlborg wrote: On 2015-03-31 21:09, Mike James wrote: Hi, When I run the build using dub I get the following errors... java\lang\util.d(396): Deprecation: typedef is removed java\lang\util.d(405): Deprecation: typedef is removed java\nonstandard\Locale.d(66): Error: cannot append type string to type wchar[] java\nonstandard\Locale.d(89): Error: template instance java.nonstandard.Locale.caltureNameI error instantiating object.Exception@build.d(251): compile error 0x00404C92 0x00405EA1 0x00403DD4 0x00417D32 0x00417D07 0x00417C1F 0x0041076F 0x751F7C04 in BaseThreadInitThunk 0x76F5B54F in RtlInitializeExceptionChain 0x76F5B51A in RtlInitializeExceptionChain Is there an update for DWT using the latest D compiler? Yes, should work now [1]. [1] https://github.com/d-widget-toolkit/dwt/commit/d43ce0cfec48c499cf43f4002e8916158b175847 Thanks. Libs and snippets build no problem. regards, -=mike=-
Re: Named unittests
On Tuesday, 31 March 2015 at 23:53:29 UTC, Andrei Alexandrescu wrote: On 3/31/15 4:38 PM, Martin Nowak wrote: On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote: The reasonable course is to see how far we can get with a library-only solution. Amaury, want to work on that? -- Andrei In any case you should talk to Atila Neves who wrote a really good unittest library. http://code.dlang.org/packages/unit-threaded http://code.dlang.org/packages/dtest It's also used by quite a lot of people already. http://code.dlang.org/api/packages/unit-threaded/stats Atila, is there interest in moving your library to std.experimental? -- Andrei Sure, I can have the PR ready by next week. As mentioned earlier, a UDA to attach a name to a unittest block and then run with that name in the output is 30min work. Making the whole thing std.experimental ready will take a few days. TBH, if I'd known it had a chance of making it in there, I'd've done it ages ago! Atila
Re: The dmd.conf rant
On Wednesday, 1 April 2015 at 02:29:05 UTC, Martin Nowak wrote: [...] ### conclusion The lookup order for the config file should be changed to the following. - next to dmd binary (highest precedence so that I can have multiple installations) - per-user conf folder (HOME) (to override the system-wide config) - system-wide conf folder (to allow package installations .deb/.rpm) The current situation is unmaintainable. How about a sensible default that makes the configuration file unnecessary in most cases? This should be similar to the way %@P% is handled, but relative to the path of the compiler executable rather than the conf file The default for unix-like systems could be: [Environment32] DFLAGS=-I%@E%/../include/dmd/phobos -I@%E@/../include/dmd/druntime/import -L-L@%E@/../lib -L--export-dynamic [Environment64] DFLAGS=-I@%E@/../include/dmd/phobos -I@%E@/../include/dmd/druntime/import -L-L@%E@/../lib64 -L--export-dynamic This should work for both global configurations (/usr/, /usr/local/) and private configurations under your work directory as long as they maintain the same general structure. It would be nice if the default could some also be made to work for a side-by-side checkout of the dmd and druntime repositories with a strategically-placed symlink or some other minimal change. Using dmd.conf should be reserved for exceptions, not the rule.
Re: DMD compilation speed
lobo wrote in message news:vydmnbzapttzjnnct...@forum.dlang.org... I think the main culprit now is my attempts to (ab)use CTFE. After switching to DMD 2.066 I started adding `enum val=f()` where I could. After reading the discussions here I went about reverting most of these back to `auto val=blah` and I'm building again :-) DMD 2.067 is now maxing out at ~3.8GB and stable. Yeah, the big problem is that dmd's interpreter sort of evolved out of the constant folder, and wasn't designed for ctfe. A new interpreter for dmd is one of the projects I hope to get to after DDMD is complete, unless somebody beats me to it.
Re: Named unittests
On Wednesday, 1 April 2015 at 04:42:33 UTC, Shammah Chancellor wrote: I can possibly help with a DIP, but it seems like a very straightforward request? -Shammah Considering the heated debate going on here, I'd say it's not as straightforward as it seems...
Re: dsq-1: open-source software synthesizer
Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: On 30/03/2015 7:26 p.m., ketmar wrote: what i really want to have is libdub. i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay.
Re: dsq-1: open-source software synthesizer
Am 01.04.2015 um 11:32 schrieb ketmar: On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote: You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. i have concerns about API stability, though. it's always better to have officially announced library with some guarantees (we will break API on each release is good too ;-). This will happen soon, when it's ready for the 1.0.0 release. It'll then be subject to the usual SemVer guarantees.
Re: Filling out the wiki - D as a second language
On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote: I started some C# to D stuff here: https://github.com/rumbu13/sharp/blob/master/cstod.md Forgot semicolon in hello world example. Anyway, I'm already asking for help from experienced D users to translate the following concepts in D: - decimal type I heard, there was an implementation of a scaled integer and a rational type. - dynamic types No exact equivalent, opDispatch is similar, but is compile-time. - volatile atomicLoad, atomicStore - boxing/unboxing Variant - multicast delegates - events std.signals (needs rewrite) - yield return input/output ranges - P/Invoke Not really needed for native languages, because they interface with the platform directly. Well, there are utilities like tempCString. - async/await vibe addresses the same problem http://code.dlang.org/packages/vibe-d - linq std.algorithm, std.range, std.array - runtime reflection Nothing builtin, D relies more on compile-time reflection. - serialization http://wiki.dlang.org/Libraries_and_Frameworks#Serialization - inlining only http://wiki.dlang.org/DIP56 - weak references To be implemented in druntime - implicit casting overload Not supported deliberately, as I understand it - COM imports There was some attempt at COM integration, not sure how far it has gone. AFAIK, COM can expose interface as IDispatch, that would save one from parsing the type library manually. - templated functions override Done by redirecting templated function to non-templated one. I'm not asking for solutions (because I know how to implement them in D), I'm asking for guidance about the best D semantics to be used instead. Do things at compile time, allocate as little as possible, in other words, be efficient.
Re: C++ to D
On Tuesday, 31 March 2015 at 20:37:37 UTC, Jeff Jones wrote: Is it possible to modify either a C++ compiler or in code to make classes more D ish? e.g., instead of just the vtable(which, IIRC is slightly different between the two) add the metadata pointer and whatever else? What I'm getting at, is there a somewhat simple way(not creating a new C++ but either through macros, small compiler changes, or whatever) to make C++ objects D compatible instead of the other way? I.e., we can't take anything away from D classes since we will break D. But we should be able to add to C++ classes without breaking C++. If we can add the info that D needs then both should get along happily? I'm mainly talking about a simple code based solution but I'm also curious about how easily this would be by compiler modification. As far as I understand, the memory layout is already compatible. The problematic part seems to be construction. I'd say it's difficult to change anything about that on the C++ side, but I'll let others answer who are more familiar with the inner workings of the compiler.
extending 'import' using 'with'
Just a thought...
How about adding the keyword 'with' to 'import' to save on typing
:-)
import org.eclipse.swt.widgets.Canvas,
org.eclipse.swt.widgets.Composite,
org.eclipse.swt.events.DisposeListener,
org.eclipse.swt.events.DisposeEvent,
org.eclipse.swt.events.PaintListener,
org.eclipse.swt.events.PaintEvent;
import with (org.eclipse.swt) {
widgets.Canvas,
widgets.Composite,
events.DisposeListener,
events.DisposeEvent,
events.PaintListener,
events.PaintEvent;
}
Regards,
-=mike=-
Re: dsq-1: open-source software synthesizer
Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like horrible for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off.
operators in language reference
There is a gapping hole in the language reference: The operators are nowhere described. Ok, most of them are the same as in C and C++, but there are subtle differences (e.g. different precedence) and some are new (the floating point comparisons have their own chapter and they are about to beeing deprecated, but what about , ^^, ^^=, =, ., is, in ?). And even if they where all the same as in C or C++, not everybody comes from those languages and D should be understandable without such kind of background knowledge, I think.
Re: Maxime's micro allocation benchmark much faster ?
On 2015-03-31 at 22:56, Laeeth Isharc wrote: 1mm allocations 2.066: 0.844s 2.067: 0.19s That is great news, thanks! OT: it's a nasty financier's habit to write 1M and 1MM instead of 1k and 1M. :P
Re: Benchmark of D against other languages
Andrei Alexandrescu: Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei Yes, the right default for D language should be final, because lot of programmers are lazy and they don't add attributes. Bye, bearophile
Re: Named unittests
I have PR https://github.com/D-Programming-Language/phobos/pull/2995 open since October 2014. it includes: * extensible haskell like quickcheck * benchmarking with names and record keeping to see progress * offline tool to plot benchmark results with gnuplot * most std.string functions already have benchmarks * makefiles got a new BUILD=benchmark IMO continuous benchmarking of phobos is a must-have feature and a nice marketing tool ( benchmark graphs on dlang.org). Something similar to quickcheck is equally important, to get the test input you didn't expect. I got one and a half comments so far.
Re: The dmd.conf rant
On Wed, 01 Apr 2015 19:16:09 +1100, Daniel Murphy wrote: ketmar wrote in message news:mfft3m$2uuc$6...@digitalmars.com... actually, the fix is very easy: ditch idgen.d in favor of old idgen.c, and patch makefile. both can be done automatically (i did). whoa, i can build DMD without problems again! Not exactly a long-term solution. sure, but it works for now, and will work for a long time, as DDMD transition is a lenghty process. this will not fix the problem, of course, but it provides working workaround for those who don't have a time/desire to fix it properly. besides, it allows to build DMD without DMD. ;-) signature.asc Description: PGP signature
Re: DMD compilation speed
On Wed, 01 Apr 2015 06:21:58 +, deadalnix wrote: On Wednesday, 1 April 2015 at 04:51:26 UTC, weaselcat wrote: On Wednesday, 1 April 2015 at 04:49:55 UTC, ketmar wrote: On Wed, 01 Apr 2015 02:25:43 +, Random D-user wrote: GC because of some low-end machines. Memory is really cheap these days and pretty much every machine is 64-bits (even phones are trasitioning fast to 64-bits). this is the essense of modern computing, btw. hey, we have this resource! hey, we have the only program user will ever want to run, so assume that all that resource is ours! what? just buy a better box! google/mozilla's developer mantra regarding web browsers. They must have an agreement with DRAM vendor, I see no other explanation... maybe vendors just giving 'em free DRAM chips... signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working.
Re: Benchmark of D against other languages
On Tue, 2015-03-31 at 19:52 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/31/15 7:17 PM, weaselcat wrote: posting this knowing that andrei is about to yell at me for not posting this in the reddit thread ;) Yep, while reading I had this loaded in my chamber: Remember that statistically NOBODY is on forum.dlang.org and EVERYBODY is on reddit! -- Andrei Not everybody. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: dsq-1: open-source software synthesizer
On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote: You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time. i have concerns about API stability, though. it's always better to have officially announced library with some guarantees (we will break API on each release is good too ;-). signature.asc Description: PGP signature
Re: I submitted my container library to code.dlang.org
Am Tue, 31 Mar 2015 23:45:28 +0200 schrieb Martin Nowak code+news.digitalm...@dawg.eu: On 03/31/2015 11:12 PM, Martin Nowak wrote: Anyone benchmarked that SipHash? No way we use this for druntime. https://github.com/rurban/smhasher#readme I think we should have a flexible Hash in std.container though, that should allow to use a customized hash function. It's probably more a problem for vibe-d or other server-like applications. Those should make sure to use DOS-safe hash tables. For most applications there's no possibility for DOS attacks using hash tables and we indeed shouldn't make these applications slower.
Re: extending 'import' using 'with'
On Wednesday, 1 April 2015 at 10:21:46 UTC, Mike James wrote:
Just a thought...
How about adding the keyword 'with' to 'import' to save on
typing :-)
import org.eclipse.swt.widgets.Canvas,
org.eclipse.swt.widgets.Composite,
org.eclipse.swt.events.DisposeListener,
org.eclipse.swt.events.DisposeEvent,
org.eclipse.swt.events.PaintListener,
org.eclipse.swt.events.PaintEvent;
import with (org.eclipse.swt) {
widgets.Canvas,
widgets.Composite,
events.DisposeListener,
events.DisposeEvent,
events.PaintListener,
events.PaintEvent;
}
Regards,
-=mike=-
string importSubmodules(string rootModuleName, string[]
subModuleNames) {
import std.algorithm;
import std.array;
string prefix = import ~ rootModuleName ~ '.';
return subModuleNames.map!(name = prefix ~ name ~ ';').join
}
mixin(importSubmodules(org.eclipse.swt, [
widgets.Canvas,
widgets.Composite,
events.DisposeListener,
events.DisposeEvent,
events.PaintListener,
events.PaintEvent
]));
Of course, why be clever here at all and do such things? It's an
editor problem. Write the full import lines out, and if you hate
typing out the path each time, use tricks in your editor to make
that easier, or use an IDE.
Re: Trouble with Cortex-M Hello World
Unfortunately, my attempt to build GDC on my CubieBoard2 failed. However, I decided to change the line slightly, in order to find out exactly what's going wrong... src/start.d:46:12: error: mismatched array lengths, 0 and 3 uint[4]message=[2,cast(uint)hello\r\n.ptr,7]; ^ make: *** [output/src/start.o] Error 1 This means that the arry on the right hand side is actually parsed correctly. It seems that the number [3] or [4] is parsed/read as zero ??
Re: C++ to D
Jeff Jones wrote in message news:bdfjhhkmmwzhdmqtv...@forum.dlang.org... Is it possible to modify either a C++ compiler or in code to make classes more D ish? e.g., instead of just the vtable(which, IIRC is slightly different between the two) add the metadata pointer and whatever else? What I'm getting at, is there a somewhat simple way(not creating a new C++ but either through macros, small compiler changes, or whatever) to make C++ objects D compatible instead of the other way? It sounds like what you're suggesting is similar to the way COM interfaces can be implemented in C - manually matching everything that C doesn't have, like vtables. You could do it with C++ for D, or patch a C++ compiler to do it automatically, but I'd guess there's an easier way for whatever you're trying to accomplish.
[Issue 14387] New: Disallow string literals as assert conditions
https://issues.dlang.org/show_bug.cgi?id=14387
Issue ID: 14387
Summary: Disallow string literals as assert conditions
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: schue...@gmx.net
void foo(int x) {
assert(foo);
static assert(bar);
if(!isXValid(x))
assert(x has the invalid value of ~ x.to!string);
}
These should be disallowed, because it's too easy to forget the `0` as first
argument. Other expression that are concatenations of string literals should be
kept, of course.
--
Re: operators in language reference
On Wednesday, 1 April 2015 at 11:18:26 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:53:57 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 1 April 2015 at 10:39:01 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:06:20 UTC, Dominikus Dittes Scherkl wrote: There is a gapping hole in the language reference: The operators are nowhere described. Ok, most of them are the same as in C and C++, but there are subtle differences (e.g. different precedence) and some are new (the floating point comparisons have their own chapter and they are about to beeing deprecated, but what about , ^^, ^^=, =, ., is, in ?). And even if they where all the same as in C or C++, not everybody comes from those languages and D should be understandable without such kind of background knowledge, I think. http://dlang.org/expression.html This describes what operators (tokens) exist and what operands they can take (form a grammar point of view), but not what they do. You may say that's obvious, but I know languages where even + doesn't do what one might expect. With exception of the ones that are the same in C, I can't spot any that are missing an explanation. I agree that it would be good to have a more beginner friendly description of them all, but to a C(++) programmer I would say that document contains the info they need. Yeah, but scattered all over the different chapters. And not describing those that are the same in C++ is like not describing the types float and short, just because they are the same in C++. I find it lacking if I have to tell a newbie look in the documentation for some other language for the definition of the operators that you can't find here somewhere
Re: The dmd.conf rant
On 3/31/15 9:43 PM, Martin Nowak wrote: That's only half of the story, because without a config dmd doesn't know where to find druntime/phobos or how to link a binary. Everything can be specified in the command line. -- Andrei
Re: foxyproxyvideoutility - problem
Nice post.
Re: dec64 decimal floating point type
On 31/03/2015 7:22 PM, Gary Willoughby wrote: This is an old thread but does any one know if any decimal types were ever implemented? I set off trying to implement DEC64 based on the halffloat module, but never got very far. My main problem is that the assembler in the reference implementation renames all the registers, and as a result I really struggle to follow it A...
[Issue 14207] Assertion failure: '(vd-storage_class (STCout | STCref)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' on line 6724 in file 'interpret.c'
https://issues.dlang.org/show_bug.cgi?id=14207 Nicolas Sicard dran...@gmail.com changed: What|Removed |Added Keywords||CTFE, ice CC||dran...@gmail.com Severity|normal |regression --
Re: The dmd.conf rant
ketmar wrote in message news:mfgdjf$2uuc$6...@digitalmars.com... sure, but it works for now, and will work for a long time, as DDMD transition is a lenghty process. Hopefully not too lengthy!
Re: operators in language reference
On Wednesday, 1 April 2015 at 10:06:20 UTC, Dominikus Dittes Scherkl wrote: There is a gapping hole in the language reference: The operators are nowhere described. Ok, most of them are the same as in C and C++, but there are subtle differences (e.g. different precedence) and some are new (the floating point comparisons have their own chapter and they are about to beeing deprecated, but what about , ^^, ^^=, =, ., is, in ?). And even if they where all the same as in C or C++, not everybody comes from those languages and D should be understandable without such kind of background knowledge, I think. http://dlang.org/expression.html and related http://dlang.org/operatoroverloading.html
Re: operators in language reference
On Wednesday, 1 April 2015 at 10:53:57 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 1 April 2015 at 10:39:01 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:06:20 UTC, Dominikus Dittes Scherkl wrote: There is a gapping hole in the language reference: The operators are nowhere described. Ok, most of them are the same as in C and C++, but there are subtle differences (e.g. different precedence) and some are new (the floating point comparisons have their own chapter and they are about to beeing deprecated, but what about , ^^, ^^=, =, ., is, in ?). And even if they where all the same as in C or C++, not everybody comes from those languages and D should be understandable without such kind of background knowledge, I think. http://dlang.org/expression.html This describes what operators (tokens) exist and what operands they can take (form a grammar point of view), but not what they do. You may say that's obvious, but I know languages where even + doesn't do what one might expect. With exception of the ones that are the same in C, I can't spot any that are missing an explanation. I agree that it would be good to have a more beginner friendly description of them all, but to a C(++) programmer I would say that document contains the info they need.
Re: The dmd.conf rant
On Wednesday, 1 April 2015 at 02:29:05 UTC, Martin Nowak wrote: The lookup order for the config file should be changed to the following. - next to dmd binary (highest precedence so that I can have multiple installations) - per-user conf folder (HOME) (to override the system-wide config) - system-wide conf folder (to allow package installations .deb/.rpm) I've always thought it worked like this :-) So I'm in favour of this change.
Re: dsq-1: open-source software synthesizer
On 1/04/2015 11:07 p.m., Sönke Ludwig wrote: Am 01.04.2015 um 11:33 schrieb Rikki Cattermole: On 1/04/2015 10:28 p.m., Sönke Ludwig wrote: Am 30.03.2015 um 08:34 schrieb Rikki Cattermole: snip Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code. Okay. Nobody can be the best at everything. So it was a compliment :) You've done an excellent job with them. And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front. I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working. I personally usually stay away from using overly strong terms like horrible for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online). I agree, I was quite extreme. In reality we're only talking in shades of grey with a difference of maybe 5 (0 .. 255). There is a reason why most people IRL think I'm a jerk. Always take stuff like this with a grain of salt. It's only meant to make people think about the subject, not as a factoid. On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course. If I was to start doing it, Vibe.d would be next to useless. No you guys are doing a wonderful job. I really can't stress that enough. I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off. There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose.
[Issue 12984] [REG2.068a] ICE on forward reference of derived class from other instantiated class
https://issues.dlang.org/show_bug.cgi?id=12984 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/302d42186a30452ddb0c7bd02f4f8c682a8f4c93 [Fix] Fix incorrect test for issue 12984. Causing commit: 8efa502a209c64a75f682956cab0b3647737c614. --
Re: Maxime's micro allocation benchmark much faster ?
On Wednesday, 1 April 2015 at 10:09:12 UTC, FG wrote: On 2015-03-31 at 22:56, Laeeth Isharc wrote: 1mm allocations 2.066: 0.844s 2.067: 0.19s That is great news, thanks! OT: it's a nasty financier's habit to write 1M and 1MM instead of 1k and 1M. :P Yeah, what's with that? I've never seen it before.
Re: operators in language reference
On Wednesday, 1 April 2015 at 10:39:01 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:06:20 UTC, Dominikus Dittes Scherkl wrote: There is a gapping hole in the language reference: The operators are nowhere described. Ok, most of them are the same as in C and C++, but there are subtle differences (e.g. different precedence) and some are new (the floating point comparisons have their own chapter and they are about to beeing deprecated, but what about , ^^, ^^=, =, ., is, in ?). And even if they where all the same as in C or C++, not everybody comes from those languages and D should be understandable without such kind of background knowledge, I think. http://dlang.org/expression.html This describes what operators (tokens) exist and what operands they can take (form a grammar point of view), but not what they do. You may say that's obvious, but I know languages where even + doesn't do what one might expect. and related http://dlang.org/operatoroverloading.html Yes, this goes further into details what operands an operator take (especially if it is only one or two or more operands), but not what they do - in this chapter this is especially useless, as if I overload an operator, it will do whatever I want it to do even if it is strange as hell. So this is not the right place to describe the default behaviour of an operator (but ok, It should refer to that place --- if only there would be one!).
Re: struct variable initialized with void.
On Tuesday, 31 March 2015 at 16:24:02 UTC, John Colvin wrote: On Tuesday, 31 March 2015 at 16:10:07 UTC, Adam D. Ruppe wrote: On Tuesday, 31 March 2015 at 15:59:53 UTC, John Colvin wrote: Like almost never? I can't think of any reason to ever do that. I mentioned it because of this story: https://www.schneier.com/blog/archives/2008/05/random_number_b.html I'm sure there's better ways to do it, but since a similar technique was used in a high profile product, I thought I'd mention it as a possible use. though I'd recommend against trying this at home for anything serious since there's better sources of more random randomness... In general, I can't think of a worse way of choosing a seed other than a fixed value*. It's actually quite interesting thinking of all the ways it's bad :) More fun than I thought: Depending on the OS and toolchain, you might be looking at anything in the current process (at best). That seed might be directly drawn from user data: an attacker could conceivably now choose your seed. The seed might contain sensitive data: an attacker who can measure the output of the PRNG might be able to work backwards to find the seed, exposing the data. You might always seed 0, or some other fixed value, or something almost always fixed depending on the program state: heavily biased towards certain values, bad for randomness. Based on observable state, an observer could conceivably infer or predict the value of the seed and hence predict future values from the PRNG. and so on...
Re: Named unittests
On 2015-03-31 23:08, Idan Arye wrote: Limiting unittest names to legal identifiers will save a lot of headache when we set our tools to actually use these names. Matching a legal identifier in a text stream is much easier than matching an arbitrary unicode string, even if that string is escaped. I don't see any problem with arbitrary strings. It works perfectly fine in RSpec, which has much better tooling than D. -- /Jacob Carlborg
Re: Named unittests
On 2015-03-31 11:08, Johannes Pfau wrote: But here's the problem: 1) The compile time approach requires some kind of explicit registration of the unittests. At least one mixin per module. 2) This mixin will usually provide a module constructor. But using module constructors will cause issues with cycle detection. When we get RTInfo for modules [1] there shouldn't be any problems. A template will be instantiated once for each module the compiler sees. With that module __traits(getUnitTests) and __traits(allMembers) can be used to access the unit tests, benchmarks, or whatever. Not need for any registration or module constructors. [1] https://github.com/D-Programming-Language/dmd/pull/2271 -- /Jacob Carlborg
[Issue 14388] Assertion failed: (type-ty != Tstruct || ((TypeStruct *)type)-sym == this)
https://issues.dlang.org/show_bug.cgi?id=14388 Nicolas Sicard dran...@gmail.com changed: What|Removed |Added Keywords||ice --
Re: operators in language reference
On Wed, 01 Apr 2015 12:40:24 +, Dominikus Dittes Scherkl wrote: I find it lacking if I have to tell a newbie look in the documentation for some other language for the definition of the operators that you can't find here somewhere newbie should read some textbook first. signature.asc Description: PGP signature
Re: The dmd.conf rant
On Wed, 01 Apr 2015 22:36:39 +1100, Daniel Murphy wrote: ketmar wrote in message news:mfgdjf$2uuc$6...@digitalmars.com... sure, but it works for now, and will work for a long time, as DDMD transition is a lenghty process. Hopefully not too lengthy! i hope too, as i really want to work on my compiler branch with D! ;-) signature.asc Description: PGP signature
Re: extending 'import' using 'with'
people with Java/C/C++/etc. background tend to forget about the power of metaprogramming: they have no such tool at hand, so they don't even think about it. three things that one need to become used of are UFCS (so std.algorighm functions chains nicely), lambdas, and metaprogramming. but that has downside: when you get used to those, you simply can't get back to Java/C/ C++/etc. anymore, they feels like something from the past age... ;-) signature.asc Description: PGP signature
[Issue 14388] New: Assertion failed: (type-ty != Tstruct || ((TypeStruct *)type)-sym == this)
https://issues.dlang.org/show_bug.cgi?id=14388
Issue ID: 14388
Summary: Assertion failed: (type-ty != Tstruct || ((TypeStruct
*)type)-sym == this)
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dran...@gmail.com
Reduced test:
---
struct Data(A a)
{
auto foo()
{
return Data!a.init;
}
}
struct A
{
struct Item {}
immutable(Item)[] items;
this(int dummy)
{
items = [Item()].idup; // No error with .dup
}
}
void main()
{
auto test = Data!(A(42)).init.foo();
}
---
DMD 2.067.0:
Assertion failed: (type-ty != Tstruct || ((TypeStruct *)type)-sym == this),
function semantic, file struct.c, line 929.
--
Speed of horizontal flip
Hi,
I have a bunch of square r16 and png images which I need to flip
horizontally.
My flip method looks like this:
void hFlip(T)(T[] data, int w)
{
import std.datetime : StopWatch;
StopWatch sw;
sw.start();
foreach(int i; 0..w)
{
auto row = data[i*w..(i+1)*w];
row.reverse();
}
sw.stop();
writeln(Img flipped in: , sw.peek().msecs, [ms]);
}
With simple r16 file format its pretty fast, but with RGB PNG
files (2048x2048) I noticed its somewhat slow so I tried to
compare it with C# and was pretty surprised by the results.
C#:
PNG load - 90ms
PNG flip - 10ms
PNG save - 380ms
D using dlib (http://code.dlang.org/packages/dlib):
PNG load - 500ms
PNG flip - 30ms
PNG save - 950ms
D using imageformats
(http://code.dlang.org/packages/imageformats):
PNG load - 230ms
PNG flip - 30ms
PNG save - 1100ms
I used dmd-2.0.67 with -release -inline -O
C# was just with debug and VisualStudio attached to process for
debugging and even with that it is much faster.
I know that System.Drawing is using Windows GDI+, that can be
used with D too, but not on linux.
If we ignore the PNG loading and saving (didn't tried libpng
yet), even flip method itself is 3 times slower - I don't know D
enough to be sure if there isn't some more effecient way to make
the flip. I like how the slices can be used here.
For a C# user who is expecting things to just work as fast as
possible from a system level programming language this can be
somewhat disappointing to see that pure D version is about 3
times slower.
Am I doing something utterly wrong?
Note that this example is not critical for me, it's just a simple
hobby script I use to move and flip some images - I can wait. But
I post it to see if this can be taken somewhat closer to what can
be expected from a system level programming language.
dlib:
auto im = loadPNG(name);
hFlip(cast(ubyte[3][])im.data, cast(int)im.width);
savePNG(im, newName);
imageformats:
auto im = read_image(name);
hFlip(cast(ubyte[3][])im.pixels, cast(int)im.w);
write_image(newName, im.w, im.h, im.pixels);
C# code:
static void Main(string[] args)
{
var files = Directory.GetFiles(args[0]);
foreach (var f in files)
{
var sw = Stopwatch.StartNew();
var img = Image.FromFile(f);
Debug.WriteLine(Img loaded in {0}[ms],
(int)sw.Elapsed.TotalMilliseconds);
sw.Restart();
img.RotateFlip(RotateFlipType.RotateNoneFlipX);
Debug.WriteLine(Img flipped in {0}[ms],
(int)sw.Elapsed.TotalMilliseconds);
sw.Restart();
img.Save(Path.Combine(args[0], test_ +
Path.GetFileName(f)));
Debug.WriteLine(Img saved in {0}[ms],
(int)sw.Elapsed.TotalMilliseconds);
sw.Stop();
}
}
Re: operators in language reference
On Wednesday, 1 April 2015 at 12:40:26 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 1 April 2015 at 11:18:26 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:53:57 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 1 April 2015 at 10:39:01 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:06:20 UTC, Dominikus Dittes Scherkl wrote: There is a gapping hole in the language reference: The operators are nowhere described. Ok, most of them are the same as in C and C++, but there are subtle differences (e.g. different precedence) and some are new (the floating point comparisons have their own chapter and they are about to beeing deprecated, but what about , ^^, ^^=, =, ., is, in ?). And even if they where all the same as in C or C++, not everybody comes from those languages and D should be understandable without such kind of background knowledge, I think. http://dlang.org/expression.html This describes what operators (tokens) exist and what operands they can take (form a grammar point of view), but not what they do. You may say that's obvious, but I know languages where even + doesn't do what one might expect. With exception of the ones that are the same in C, I can't spot any that are missing an explanation. I agree that it would be good to have a more beginner friendly description of them all, but to a C(++) programmer I would say that document contains the info they need. Yeah, but scattered all over the different chapters. I meant just in http://dlang.org/expression.html. All the novel operators are described there, including what they do. And not describing those that are the same in C++ is like not describing the types float and short, just because they are the same in C++. I find it lacking if I have to tell a newbie look in the documentation for some other language for the definition of the operators that you can't find here somewhere Agreed.
Re: The dmd.conf rant
On 2015-04-01 07:00, H. S. Teoh via Digitalmars-d wrote: On Wed, Apr 01, 2015 at 04:28:43AM +0200, Martin Nowak via Digitalmars-d wrote: The lookup order for the config file should be changed to the following. - next to dmd binary (highest precedence so that I can have multiple installations) - per-user conf folder (HOME) (to override the system-wide config) - system-wide conf folder (to allow package installations .deb/.rpm) The current situation is unmaintainable. +1. This is the order that makes the most sense. I'm astonished it wasn't implemented this way from the start. It isn't implemented like that? Then how is it implemented? -- /Jacob Carlborg
Re: dsq-1: open-source software synthesizer
On Thu, 02 Apr 2015 00:54:52 +1300, Rikki Cattermole wrote: There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose. it's even harder, as i sometimes has troubles deciding what should go into a function... signature.asc Description: PGP signature
Re: Trouble with Cortex-M Hello World
Am Wed, 01 Apr 2015 12:56:22 + schrieb Jens Bauer doc...@who.no: Unfortunately, my attempt to build GDC on my CubieBoard2 failed. However, I decided to change the line slightly, in order to find out exactly what's going wrong... src/start.d:46:12: error: mismatched array lengths, 0 and 3 uint[4]message=[2,cast(uint)hello\r\n.ptr,7]; ^ make: *** [output/src/start.o] Error 1 This means that the arry on the right hand side is actually parsed correctly. It seems that the number [3] or [4] is parsed/read as zero ?? I'm not sure if anybody ever used GDC/DMD/LDC on a big-endian system. It could be an endianess issue somewhere in the code. I debugged a misaligned-access bug in the frontend some time ago, bugs like these can result in the weirdest effects. It should compile on the cubieboard though. What exactly failed?
Re: Speed of horizontal flip
tchaloupka: Am I doing something utterly wrong? If you have to perform performance benchmarks then use ldc or gdc. Also disable bound tests with your compilation switches. Sometimes reverse() is not efficient, I think, it should be improved. Try to replace it with a little function written by you. Add the usual pure/nothrow/@nogc/@safe annotations where you can (they don't increase speed much, usually). And you refer to flip as method, so if you are using classes don't forget to make the method final. Profile the code and look for the performance bottlenecks. You can even replace the *w multiplications with an increment of an index each loop, but this time saving is dwarfed by the reverse(). Bye, bearophile
C++ to D
Hi,
Please help rewrite this code to D:
#include iostream
// Peano Arithmetic
struct zero;
template typename T
struct succ {
};
template typename T
struct increment {
using result = succT;
};
template typename T
struct decrement;
template typename T
struct decrementsuccT {
using result = T;
};
template typename A, typename B
struct addition;
template typename A
struct additionA, zero {
using result = A;
};
template typename A, typename T
struct additionA, succT {
using result = typename additionsuccA, T::result;
};
template typename T
struct to_int;
template
struct to_intzero {
static constexpr auto result = 0;
};
template typename T
struct to_intsuccT {
static constexpr auto result = 1 + to_intT::result;
};
template typename T
using inc = typename incrementT::result;
template typename T
using dec = typename decrementT::result;
template typename A, typename B
using add = typename additionA, B::result;
class nil;
template typename T, typename Rest
struct list {
using head = T;
using tail = Rest;
};
template typename T
struct length;
template
struct lengthnil {
static constexpr auto result = 0;
};
template typename Head, typename Tail
struct lengthlistHead, Tail { // pattern-matching
static constexpr auto result = 1 + lengthTail::result;
};
template template typename class Func, class List
struct map;
template template typename class Func
struct mapFunc, nil {
using result = nil;
};
template template typename class Func, class Head, class Tail
struct mapFunc, listHead, Tail { // first-order function
using result = listFuncHead, typename mapFunc,
Tail::result;
};
template template typename, typename class Func, class Init,
class List
struct fold;
template template typename, typename class Func, class Init
struct foldFunc, Init, nil {
using result = Init;
};
template template typename, typename class Func, class Init,
class Head, class Tail
struct foldFunc, Init, listHead, Tail {
using result = FuncHead, typename foldFunc, Init,
Tail::result;
};
template class List
struct sum {
using result = typename foldadd, zero, List::result;
};
int main() {
using one = inczero;
using two = incinczero;
using four = incincincinczero;
using two_plus_one = addtwo, one;
std::cout to_inttwo_plus_one::result std::endl; //
prints 3
using l = listone, listtwo, listfour, nil;
std::cout lengthl::result std::endl; // prints 3
using res = summapinc, l::result::result;
std::cout to_intres::result std::endl; // prints 10
return 0;
}
Re: Named unittests
On 2015-03-31 23:14, Idan Arye wrote:
Building by unittest name! Imagine - instead of placing temporary code
in `main` to develop a new feature or fix a bug, you put in a named
unittest and tell your IDE/build-system to only build that unittest(and
whatever code needed for it to run). You `writeln` stuff to the console,
and when you get some changes to output what you want you change the
`writeln`s to `assert`s and proceed to work on the next step. When you
are done, all you have to do is tidy it up a bit and BAM - without any
special effort you get a unittest that tests that feature/bug you just
worked on.
You just reinvented test driven development ;). It's perfectly possible
to do this with a UDA an a text string as well. UDA's also allows you to
tag the tests. Basically a short name you put on multiple tests, then
tell the test runner to run only those tests, or ignore those.
@tag(foo) @name(this is my test name) unittest {}
$ run-tests -t foo
--
/Jacob Carlborg
Re: Named unittests
On 2015-04-01 00:02, Idan Arye wrote: I think you and I work under different assumptions of the goals for this feature. If we only want unittest names to be something that can be printed when the unittest runner runs the unittests, than a UDA with a string is indeed preferable. If we want something that tools can actually use to refer to a specific unittest, we need a proper identifier(yes, even though it can be implemented in library code because D is Turing-complete...) The tools should, mostly, use the file and line information. -- /Jacob Carlborg
Re: Maxime's micro allocation benchmark much faster ?
On Wednesday, 1 April 2015 at 10:35:05 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:09:12 UTC, FG wrote: On 2015-03-31 at 22:56, Laeeth Isharc wrote: 1mm allocations 2.066: 0.844s 2.067: 0.19s That is great news, thanks! OT: it's a nasty financier's habit to write 1M and 1MM instead of 1k and 1M. :P Yeah, what's with that? I've never seen it before. One cannot entirely escape déformation professionnelle ;) [People mostly write 1,000 but 1mm although 1m is pedantically correct for 1,000). Better internalize the conventions if one doesn't want to avoid expensive mistakes under pressure.
Re: Named unittests
On 2015-03-31 15:31, Dicebot wrote:
Most powerful solution would be to simply put attributes for unittest
blocks in runtime information for tests (using RTTI it should be
possible to define such variadic structure in similar manner as D-style
variadic function arguments).
I think the most powerful and most generic solution would be to:
1. Remove the unittest keyword
2. Make code executable at module scope
3. Add support for trailing delegate syntax
module foo;
unittest(foobar)
{
}
Would be lowered to
unittest(foobar, {
});
Works with benchmark and other things as well.
--
/Jacob Carlborg
CURL to get/set cookies
Hello! I’m having issues with setting a cookie via CURL(std.net.curl). I’ve tried several time over the last week but can’t figure it out. I feel like I've tried every suggestion I found searching the web. Basically - I receive the value set-cookie from a GET request (got this), but have no idea how to feed this into next POST request. Can someone point me in the right direction or provide a snippet of code that I could work from? Thank you! Benjamin Houdeshell
Re: Trouble with Cortex-M Hello World
On Wednesday, 1 April 2015 at 13:59:34 UTC, Johannes Pfau wrote: Am Wed, 01 Apr 2015 12:56:22 + It could be an endianess issue somewhere in the code. I debugged a misaligned-access bug in the frontend some time ago, bugs like these can result in the weirdest effects. Indeed. I had some strange things happening until OpenOCD had the endian bugs squashed. Endian problems does not necessarily have to mean crashes; it could just be some data's high an low bytes being swapped. It should compile on the cubieboard though. What exactly failed? building GCC-4.9.2, so this is not an issue with D. I'll probably be trying to make a build for the next 10 hours. On my G5, however, I managed to get as complete a build as I could, but it involves compiling GCC 4 times total (!) - This gives me C/C++ and D - including libstdc++! -but it takes a couple of hours. ;)
Re: CURL to get/set cookies
There's two ways, you can let curl handle it by setting a cookie jar file: http://dlang.org/phobos/std_net_curl.html#setCookieJar Make the HTTP object and set the jar on it before doing any requests. Then it will be done automatically on that object, saving to the file. If you are manually reading the Set-Cookie header, you can also just use this method: http://dlang.org/phobos/std_net_curl.html#setCookie
Re: unittests are really part of the build, not a special run
On 31/03/2015 19:24, Andrei Alexandrescu wrote: On 3/31/15 9:21 AM, qznc wrote: On Monday, 30 March 2015 at 22:50:21 UTC, Andrei Alexandrescu wrote: Violent agreement here. I was just saying unittests should be part of the build process, not the run process. Running unittests and then the app is a bad idea. Sounds like a good idea to me. Then -unittest should be enabled by default? Probably not; we're looking at two different builds. The build to be deployed has no unittest code at all. I'm starting to see this differently these days (basically since I started to use jenkins for everything): A build you haven't unit tested has implicitly failed. That means the release build that does not have any unit test bits is not deployable. Instead, compile as usual (both debug and release), and run unit tests against both (e.g. to catch compiler bugs in the optimiser). Then for deployment, drop/strip/remove/dont-package the unit test code. Implementationwise it sounds like you want another entry point apart from main, e.g. main_unittest. Then the build process is compile-link-unittest. Afterwards the run process is the usual main call. It makes binaries bigger though. Maybe unittest-specific code can be placed in a special segment, which can be removed during deployment? Interesting. Or could be a dynamically-loaded library. But... crawl before we walk. Andrei
Re: Maxime's micro allocation benchmark much faster ?
On Wednesday, 1 April 2015 at 14:22:57 UTC, Laeeth Isharc wrote: On Wednesday, 1 April 2015 at 10:35:05 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 10:09:12 UTC, FG wrote: On 2015-03-31 at 22:56, Laeeth Isharc wrote: 1mm allocations 2.066: 0.844s 2.067: 0.19s That is great news, thanks! OT: it's a nasty financier's habit to write 1M and 1MM instead of 1k and 1M. :P Yeah, what's with that? I've never seen it before. One cannot entirely escape déformation professionnelle ;) [People mostly write 1,000 but 1mm although 1m is pedantically correct for 1,000). Better internalize the conventions if one doesn't want to avoid expensive mistakes under pressure. well yes, who doesn't always not want to never avoid mistakes? ;) Anyway, as I'm sure you know, the rest of the world assumes SI/metric, or binary in special cases (damn those JEDEC guys!): http://en.wikipedia.org/wiki/Template:Bit_and_byte_prefixes
[Issue 14388] ICE with idup-ed struct literal in template argument
https://issues.dlang.org/show_bug.cgi?id=14388 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All Summary|Assertion failed: (type-ty |ICE with idup-ed struct |!= Tstruct || ((TypeStruct |literal in template |*)type)-sym == this) |argument Severity|normal |major --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4539 --
Re: extending 'import' using 'with'
On Wednesday, 1 April 2015 at 13:35:22 UTC, ketmar wrote: people with Java/C/C++/etc. background tend to forget about the power of metaprogramming: they have no such tool at hand, so they don't even think about it. three things that one need to become used of are UFCS (so std.algorighm functions chains nicely), lambdas, and metaprogramming. but that has downside: when you get used to those, you simply can't get back to Java/C/ C++/etc. anymore, they feels like something from the past age... ;-) I tend to think mixins are used too much myself. They slow down compilation and inflate memory usage a lot. I always weigh the costs against the benefits.
Re: C++ to D
On Wednesday, 1 April 2015 at 13:59:10 UTC, Dennis Ritchie wrote:
snip
You can do this:
import std.typetuple;
//helper for staticReduce
template Alias(alias a)
{
alias Alias = a;
}
// staticReduce should really be in std.typetuple, or
// the soon to arrive std.meta package.
template staticReduce(alias F, TL ...)
if (TL.length = 2)
{
static if (TL.length == 2)
alias staticReduce = Alias!(F!(TL));
else
alias staticReduce
= staticReduce!(F, F!(TL[0..2]), TL[2..$]);
}
enum Add(Args...) = Args[0] + Args[1];
enum Inc(Args...) = Args[0] + 1;
alias staticSum(TL ...) = staticReduce!(Add, TL);
void main()
{
//using two_plus_one = addtwo, one;
enum two_plus_one = 2 + 1;
//std::cout to_inttwo_plus_one::result std::endl;
static assert(two_plus_one == 3);
//using l = listone, listtwo, listfour, nil;
alias l = TypeTuple!(1, 2, 4);
//std::cout lengthl::result std::endl; // prints 3
static assert(l.length == 3);
//using res = summapinc, l::result::result;
enum res = staticSum!(staticMap!(Inc, l));
//std::cout to_intres::result std::endl; // prints 10
static assert(res == 10);
}
but really, there's no point:
import std.algorithm;
//All at compile-time:
static assert(1+2 == 3);
static assert([1,2,4].length == 3);
static assert([1,2,4].map!a+1.sum == 10);
Compile Time Function Evaluation (CTFE) is a very powerful tool
to avoid having to enter in to all that C++ style mess.
Re: extending 'import' using 'with'
On Wednesday, 1 April 2015 at 15:23:59 UTC, w0rp wrote: I tend to think mixins are used too much myself. They slow down compilation and inflate memory usage a lot. I always weigh the costs against the benefits. While true currently, there's a lot of opportunity to improve the situation.
Re: operators in language reference
On Wednesday, 1 April 2015 at 13:36:38 UTC, ketmar wrote: On Wed, 01 Apr 2015 12:40:24 +, Dominikus Dittes Scherkl wrote: I find it lacking if I have to tell a newbie look in the documentation for some other language for the definition of the operators that you can't find here somewhere newbie should read some textbook first. I think the language reference should be a comprehensive document that doesn't technically require someone to know C(++) first to understand. It doesn't necessarily have to be newbie friendly, but it should be complete.
Re: Speed of horizontal flip
On Wednesday, 1 April 2015 at 14:00:52 UTC, bearophile wrote: tchaloupka: Am I doing something utterly wrong? If you have to perform performance benchmarks then use ldc or gdc. I tried it on my slower linux box (i5-2500K vs i7-2600K) without change with these results: C# (mono with its own GDI+ library): Img loaded in 108[ms] Img flipped in 22[ms] Img saved in 492[ms] dmd-2.067: Png loaded in: 150[ms] Img flipped in: 28[ms] Png saved in: 765[ms] gdc-4.8.3: Png loaded in: 121[ms] Img flipped in: 4[ms] Png saved in: 686[ms] ldc2-0_15: Png loaded in: 106[ms] Img flipped in: 4[ms] Png saved in: 610[ms] I'm ok with that, thx.
Re: Speed of horizontal flip
On Wednesday, 1 April 2015 at 16:08:14 UTC, John Colvin wrote: On Wednesday, 1 April 2015 at 13:52:06 UTC, tchaloupka wrote: snip I'm pretty sure that the flipping happens in GDI+ as well. You might be writing C#, but the code your calling that's doing all the work is C and/or C++, quite possibly carefully optimised over many years by microsoft. Yes thats right, load, flip and save are all performed by GDI+ so just pinvoke to optimised code from C#.
Re: Benchmark of D against other languages
On 4/1/15 3:06 AM, Russel Winder via Digitalmars-d wrote: On Tue, 2015-03-31 at 19:52 -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 3/31/15 7:17 PM, weaselcat wrote: posting this knowing that andrei is about to yell at me for not posting this in the reddit thread ;) Yep, while reading I had this loaded in my chamber: Remember that statistically NOBODY is on forum.dlang.org and EVERYBODY is on reddit! -- Andrei Not everybody. Everybody compared to nobody. It's a statistics thing :o). -- Andrei
Re: Named unittests
On 4/1/15 12:46 AM, Atila Neves wrote: On Tuesday, 31 March 2015 at 23:53:29 UTC, Andrei Alexandrescu wrote: On 3/31/15 4:38 PM, Martin Nowak wrote: On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote: The reasonable course is to see how far we can get with a library-only solution. Amaury, want to work on that? -- Andrei In any case you should talk to Atila Neves who wrote a really good unittest library. http://code.dlang.org/packages/unit-threaded http://code.dlang.org/packages/dtest It's also used by quite a lot of people already. http://code.dlang.org/api/packages/unit-threaded/stats Atila, is there interest in moving your library to std.experimental? -- Andrei Sure, I can have the PR ready by next week. As mentioned earlier, a UDA to attach a name to a unittest block and then run with that name in the output is 30min work. Making the whole thing std.experimental ready will take a few days. TBH, if I'd known it had a chance of making it in there, I'd've done it ages ago! Atila Sounds like a plan. Thanks in advance! -- Andrei
Re: operators in language reference
On Wed, 01 Apr 2015 15:25:28 +, John Colvin wrote: On Wednesday, 1 April 2015 at 13:36:38 UTC, ketmar wrote: On Wed, 01 Apr 2015 12:40:24 +, Dominikus Dittes Scherkl wrote: I find it lacking if I have to tell a newbie look in the documentation for some other language for the definition of the operators that you can't find here somewhere newbie should read some textbook first. I think the language reference should be a comprehensive document that doesn't technically require someone to know C(++) first to understand. It doesn't necessarily have to be newbie friendly, but it should be complete. does this including IEEE floating point number description down to bits, for example? as it's essentialy the same thing: requirement to read external sources. i.e. it's good and all that, but where we should draw the line? signature.asc Description: PGP signature
Re: extending 'import' using 'with'
On Wednesday, 1 April 2015 at 13:35:22 UTC, ketmar wrote: people with Java/C/C++/etc. background tend to forget about the power of metaprogramming: they have no such tool at hand, so they don't even think about it. three things that one need to become used of are UFCS (so std.algorighm functions chains nicely), lambdas, and metaprogramming. but that has downside: when you get used to those, you simply can't get back to Java/C/ C++/etc. anymore, they feels like something from the past age... ;-) Actually metaprogramming is how a lot of magic happens in Java and .NET. It just tends to be frowned up in many companies due to maintenance headhaches when one gets too clever.
Re: operators in language reference
On Wednesday, 1 April 2015 at 15:42:31 UTC, ketmar wrote: does this including IEEE floating point number description down to bits, for example? as it's essentialy the same thing: requirement to read external sources. i.e. it's good and all that, but where we should draw the line? At least a reference to another (concurrent!) language is not so good. D aims to replace C/C++, so it should not refer to its definitions. But ok, I've read the expressions chapter again, and most operators are described good enought. For some it is clear from the naming of the operands (AddExpression implies an arithmetic operation of addition/subtraction) but it is not realy explicitly expressed.
Re: Speed of horizontal flip
On Wednesday, 1 April 2015 at 13:52:06 UTC, tchaloupka wrote:
snip
I'm pretty sure that the flipping happens in GDI+ as well. You
might be writing C#, but the code your calling that's doing all
the work is C and/or C++, quite possibly carefully optimised over
many years by microsoft.
Are you even sure that your C# code truly performs a flip? It
could easily just set the iteration scheme and return (like
numpy.ndarray.T does, if you're familiar with python).
dmd does not produce particularly fast code. ldc and gdc are much
better at that.
Sadly, std.algorithm.reserve isn't perhaps as fast as it could be
for arrays of static arrays, at least in theory. Try this, but I
hope that with a properly optimised build from ldc/gdc it won't
make any difference:
void reverse(ubyte[3][] r)
{
immutable last = r.length-1;
immutable steps = r.length/2;
foreach(immutable i; 0 .. steps)
{
immutable tmp = r[i];
r[i] = r[last - i];
r[last - i] = tmp;
}
}
unittest
{
ubyte[3] a = [1,2,3];
ubyte[3] b = [7,6,5];
auto c = [a,b];
c.reverse();
assert(c == [b,a]);
ubyte[3] d = [9,4,6];
auto e = [a,b,d];
e.reverse();
assert(e == [d,b,a]);
auto f = e.dup;
e.reverse;
e.reverse;
assert(f == e);
}
Re: extending 'import' using 'with'
On Wed, 01 Apr 2015 15:23:58 +, w0rp wrote: I tend to think mixins are used too much myself. They slow down compilation and inflate memory usage a lot. I always weigh the costs against the benefits. but they are so handy! i... can't... stop... need... more... mixins... signature.asc Description: PGP signature
Re: operators in language reference
On Wednesday, 1 April 2015 at 15:50:20 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 1 April 2015 at 15:42:31 UTC, ketmar wrote: does this including IEEE floating point number description down to bits, for example? as it's essentialy the same thing: requirement to read external sources. i.e. it's good and all that, but where we should draw the line? At least a reference to another (concurrent!) language is not so good. D aims to replace C/C++, so it should not refer to its definitions. But ok, I've read the expressions chapter again, and most operators are described good enought. For some it is clear from the naming of the operands (AddExpression implies an arithmetic operation of addition/subtraction) but it is not realy explicitly expressed. A table in the wiki with a one-line description and example each would be a nice idea, for a start.
Re: Redirecting dead links on the website
On 04/01/2015 11:20 PM, w0rp wrote: Phobos documentation was restructured, and the new structure is good. However, changing the URLs for the documentation has left behind a few broken links, some of which I'm seeign in Google search results. For example, this page I just saw. http://dlang.org/library/std/traits/ValueType.html We changed dpl-docs format from CamelCase to underscore because Andrei used a case-insensitive file system on OSX. https://github.com/D-Programming-Language/tools/pull/129 We sould track down the old links and redirect to the new documentation pages. I might look into that, it's quite some work though. Can we feed them the sitemap instead? http://dlang.org/library/sitemap.xml I also noticed that we are hosting two different versions of the Phobos documentation, one in one format for 2.066, and another in another format for 2.067. See these two pages for example. http://dlang.org/library/std/traits.html http://dlang.org/phobos/std_traits.html That's intended /library/ is the new documentation generated by ddox/dpl-docs with one page per entity.
Re: Benchmark of D against other languages
Martin Nowak:
GCC5 comes with a big announcement about devirtualization.
https://www.gnu.org/software/gcc/gcc-5/changes.html#general
I have a small question. That page says:
A new set of built-in functions for arithmetics with overflow
checking has been added: __builtin_add_overflow,
__builtin_sub_overflow and __builtin_mul_overflow and for
compatibility with clang also other variants. These builtins have
two integral arguments (which don't need to have the same type),
the arguments are extended to infinite precision signed type, +,
- or * is performed on those, and the result is stored in an
integer variable pointed to by the last argument. If the stored
value is equal to the infinite precision result, the built-in
functions return false, otherwise true. The type of the integer
variable that will hold the result can be different from the
types of the first two arguments. The following snippet
demonstrates how this can be used in computing the size for the
calloc function:
void *
calloc (size_t x, size_t y)
{
size_t sz;
if (__builtin_mul_overflow (x, y, sz))
return NULL;
void *ret = malloc (sz);
if (ret) memset (res, 0, sz);
return ret;
}
On e.g. i?86 or x86-64 the above will result in a mul instruction
followed by a jump on overflow.
Now both GCC and Clang have intrinsics to perform safe integral
operations.
In recent versions of druntime/dmd there are functions to perform
some safe integer operations. So is the API very well compatible
with those intrinsics?
Bye,
bearophile
Re: The dmd.conf rant
On Wednesday, 1 April 2015 at 07:10:20 UTC, Andrei Alexandrescu wrote: Everything can be specified in the command line. -- Andrei This might be a feasible approach for dlang.org or phobos (it's already tedious there), but this doesn't work when you actually want to use a compiler from the command line.
Re: Benchmark of D against other languages
On Wednesday, 1 April 2015 at 22:49:55 UTC, Martin Nowak wrote: On 03/31/2015 08:20 PM, cym13 wrote: https://github.com/kostya/benchmarks We made a massive jump towards the upper ranks. #4 ¹ https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-benchb #2 https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-mandelb #1 https://github.com/kostya/benchmarks/tree/master/base64#user-content-benchmark #13 ² https://github.com/kostya/benchmarks/tree/master/json#user-content-benchmark #2 ³ https://github.com/kostya/benchmarks/tree/master/matmul#user-content-benchmark #4 https://github.com/kostya/benchmarks/tree/master/havlak#user-content-benchmark https://github.com/kostya/benchmarks ¹: Nim outperforms anything else on brainfuck by a large margin because it has the fastest hash table (open addressing, storing values in head). https://github.com/Araq/Nim/blob/57fa8c6d3f535acc79ef8a67a6ef7aef0c7519da/lib/pure/collections/tables.nim#L73 ²: D would probably be #1 with the json pull parser from http://code.dlang.org/packages/std_data_json. ³: Places 2, 3, and 4 thanks to std.numeric.dotProduct. An optimized dense matrix multiplication would get us #1. the benchmark pointed out two sore areas in D(AA and std.json,) would be nice to see AA get updated as I often completely avoid using the built-in AA.
Re: Compile-time errors using Dub/DMD - missing dependencies
On Thursday, 2 April 2015 at 01:32:43 UTC, Cassandra Nix wrote: New questions are sorry, but I have a few minor problems. Where can I find / install these dependencies? /usr/bin/ld: cannot find -levent /usr/bin/ld: cannot find -levent_pthreads /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto They're unhandled C dependencies, but very common ones so I'm surprised you don't have them(at least, the last two.) If you're on linux, event and event_pthreads would be in the libevent package for your distro - on debian/ubuntu it's libevent-dev ssl and crypto would be in libssl-dev If you're not on a debian-based distro just search your package manager for similar packages.
[Issue 11080] assert(`string`) should be forbidden
https://issues.dlang.org/show_bug.cgi?id=11080 --- Comment #28 from Ketmar Dark ket...@ketmar.no-ip.org --- Created attachment 1505 -- https://issues.dlang.org/attachment.cgi?id=1505action=edit don't accept string as condition in `assert` and `static assert` --
Re: The dmd.conf rant
On Wednesday, 1 April 2015 at 19:20:14 UTC, Dicebot wrote: The way I have set it up personally, there is a single /etc/dmd.conf for latest released package and bunch of ~/devel/dlang-X/bin folders, each with own dmd binary and own dmd.conf side by side with that dmd binary - all added to PATH. Seems to pick up the matching one depending on which binary I actually call. Yes, that's what I used for years. but it doesn't work when you need to use the system-wide dmd in ~/devel/dlang-X. That's the current order, the culprit is current directory which overrides anything else and home directory which overrides exe dir. o current directory o home directory o exe directory (windows) o directory off of argv0 o SYSCONFDIR (default=/etc/) (non-windows) == This is what it should be IMHO. o exe directory (windows) o directory off of argv0 o home directory o SYSCONFDIR (default=/etc/) (non-windows) Take the conf from next to the compiler, or look in the home dir which can override the system-wide conf, or look at the system-wide conf. I guess this might be used completely different on Windows, especially considering that the dmd.conf contains VCDIR variables and such. Any info would be welcome.
Re: Benchmark of D against other languages
On Thursday, 2 April 2015 at 04:32:26 UTC, Martin Nowak wrote:
On Thursday, 2 April 2015 at 04:11:02 UTC, weaselcat wrote:
was it a conscious decision to make the AA [] operator not
work like map/etc in C++?
What do you mean?
accessing a non-existing element in C++'s map/unordered_map
inserts the default instead of raising an exception
int main(int argc, char *argv[])
{
std::unordered_mapstd::string, int test;
std::cout test[hello] std::endl;
return 0;
}
prints 0
void main()
{
int[string] test;
writeln(test[hello]);
}
core.exception.RangeError@source/main.d(9): Range violation
Re: lambda code
On Tue, 31 Mar 2015 13:25:46 +, John Colvin wrote: Short answer: no. .codeof for functions is something I've wanted for ages, but no movement so far. 'cause `.codeof` is a can of worms. it is just a bad replace for AST macros, and having it means that internal string representation should be maintained intact for very long time. that's if i got you right and you mean that `.codeof` should return something like javascript's, `.toString` on functions: rebuild string representation of function source code. besides, it is impossible to write `.codeof` for functions without source. ;-) signature.asc Description: PGP signature
Re: Redirecting dead links on the website
On Wednesday, 1 April 2015 at 21:20:49 UTC, w0rp wrote: We sould track down the old links and redirect to the new documentation pages. Working on a fix, will hopefully be deployed tomorrow. https://github.com/D-Programming-Language/dlang.org/pull/951 BTW, we could really need more people with frontend/web skills to help us with dlang.org.
