Re: Tutorials section on vibed.org
Am 05.01.2016 um 05:19 schrieb Charles: On Monday, 4 January 2016 at 18:42:32 UTC, Sönke Ludwig wrote: Am 04.01.2016 um 19:04 schrieb Pradeep Gowda: On Monday, 4 January 2016 at 14:31:21 UTC, Sönke Ludwig wrote: Added! The footer of the website still says 2012-2014. Please fix that! Fixed, thanks! Looks like this on my phone (ignore the volume overlay, screenshot key is dumb): http://imgur.com/ynuZUpq I'll fix that next. The media queries are still primitive ATM.
Re: DMD now does Dwarf style exception handling!
On Saturday, 2 January 2016 at 21:16:38 UTC, Walter Bright wrote: What I've been working on for the last month or so. https://github.com/D-Programming-Language/dmd/pull/5324 For Linux 64 anyway. Anyone who wants to do PRs to extend it to Linux 32, OSX and FreeBSD, feel free! Unfortunately, this is of no help with Win64, which uses its own unique system. DMD for Win32 already can catch C++ exceptions, but Win32 is a dead platform. This is an enabling technology that will confer on D the ability to catch C++ exceptions, which is key to interaction with native C++ libraries. Next up: actually catching C++ exceptions! Thanks to everyone who helped out with this. Is this hack required for dmd 2.070 to get stack-trace on Linux 64? -- import etc.linux.memoryerror; static if (is(typeof(registerMemoryErrorHandler))) registerMemoryErrorHandler(); -- -- Ilya
Re: Proposal: Database Engine for D
On Mon, 04 Jan 2016 16:59:47 +, Piotrek wrote: > SQL is no magic. True. You could equivalently have a string containing valid D code, accompanied by CTFE parsers that will determine which indices to use. This has typically been considered an antipattern. It tends to work poorly with refactoring tools, for instance, and there's an assumption that string literals are data and not code. C#'s system of lambda expressions that you can access as expression trees keeps the benefits of writing everything in the same language.
Re: TIOBE December 2015 - D rose 5 positions
On Monday, 4 January 2016 at 20:25:09 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2016 at 11:12:49 UTC, Joakim wrote: I don't think Go's even hit the second tier yet, ie python and ruby, certainly not in the first tier with Java and C, though tough for such a young language to get up there. Well, Go and Swift are the two languages that are having a steep increasing curve on Google Trends. The other languages are either flat or going down (Java and C++). Because they're much higher up. I think the curve matters more right now. People don't want to do manual memory management and want simple syntax and decent speed, but not necessarily optimal speed (80% is good enough?). That's what I perceive anyway. That's D's corner of the market, it was there long before Go and Swift came after it. :) Of course, D doesn't get the hype and automatic usage that those languages get because they're from Google and Apple, but quality wins out in the medium-term. WebAsm will provide some form of concurrency also. Further, there are plans to eventually provide access to the DOM and all web APIs Yes, but it will take like 2-5 years before it gets adopted. WebWorkers are getting available now. (I am using it already.) Maybe not 4-5, but yes, they're over-engineering a lot of this stuff and adoption will take years. Javascript use was driven by its monopoly in the browser, but that's soon going away. The most common reason given for using it on the server was to use the same language on the server and client, but that reasoning will now work _against_ javascript, as you'll be able to compile your server language to WebAsm instead. That will cripple javascript, and full access to the DOM from WebAsm will kill it off. I don't know. EcmaScript7 with TypeScript gradual typing might turn out to beat other scripting languages like Lua, Dart and even Python, Ruby... I have not looked at ECMAScript 7, but I have difficulty believing any variant of javascript can ever beat out most of those other scripting languages on the server. I am thinking of using WebAsm for the application engine and TypeScript + Angular2 for user interface. Unfortunately I don't know of any suitable WebAsm runtime-less language. D3 maybe? :) I'm sure it will be pretty easy to recompile D2 to WebAsm using ldc, as llvm will support it, so ldc can be easily modified to support it. Of course, the entire web stack could be obsoleted in the meantime, which I think is actually the most likely outcome. In 20 years. Unlikely, did you read that Tim Bray article I linked last summer? https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014 Any time a tech gets so bloated and complex, it's ripe to be unseated by something simpler. Look at how Windows made no headway on mobile and Intel has almost no share in smartphones, largely because they haven't been able to get their power budget down. The bloated web stack is long overdue for similar disruption.
Re: Tutorials section on vibed.org
On Monday, 4 January 2016 at 18:42:32 UTC, Sönke Ludwig wrote: Am 04.01.2016 um 19:04 schrieb Pradeep Gowda: On Monday, 4 January 2016 at 14:31:21 UTC, Sönke Ludwig wrote: Added! The footer of the website still says 2012-2014. Please fix that! Fixed, thanks! Looks like this on my phone (ignore the volume overlay, screenshot key is dumb): http://imgur.com/ynuZUpq
Re: Proposal: Database Engine for D
On Mon, 04 Jan 2016 08:55:53 +0100, Jacob Carlborg wrote: > If D had better operator overloading or supported AST macros, opEquals > would not return true. It would return a new proxy that overloads the || > operator. The rest of the post falls apart from this mistake. Not proposing language changes was an intentional feature, not a mistake.
Re: core.atomic bug? windows 2008r2 dmd 2.69.2 x64
On Tuesday, 5 January 2016 at 00:58:57 UTC, sdv wrote:
struct sts
{
size_t a1;
struct m1{
size_t a9;
size_t a10;
}
shared m1 t1;
}
int main(string[] argv)
{
auto y1 = new sts();
cas(&y1.t1,y1.t1,y1.t1);
return 0;
}
align(16)//<<<---fix
struct sts
{
size_t a1;
struct m1{
size_t a9;
size_t a10;
}
shared m1 t1;
}
int main(string[] argv)
{
auto y1 = new sts();
cas(&y1.t1,y1.t1,y1.t1);
return 0;
}
good
Re: Proposal: Database Engine for D
FWIW, were I proposing a "Database Engine for D" I'd be proposing a B+Tree that was restricted to storing explicit data (no pointers or other indirection...including strings, you'd need to specify fixed size arrays of char, wchar, or dchar). There would be one "type"/file, and the "type" would be given by a struct that contained no pointers either obvious or hidden (i.e., dynamic arrays, strings, etc.). This would be for simplicity of implementation and basic functionality. Later I would consider implementing secondary keys which would be implemented as databases storing only the key value and the record number. Since records are of fixed size, sorting them would be trivial, but only the secondary keys would provide this option because you want the record number of the main file to be reliable and invariant. SQL seems like a poor fit to D. At some point one might consider a fancier front end to the database that would allow indirections, but that's a whole can of worms, with threats of multiple copies that have different values for items that started out pointing to the same variable. On 01/04/2016 12:39 PM, Andrei Alexandrescu via Digitalmars-d wrote: On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote: Rusts macros show it can be done well. Do you have a few examples handy? Thanks. -- Andrei
Re: DMD now does Dwarf style exception handling!
On 1/4/2016 4:18 PM, Dan Olson wrote: Very cool. Is it conceivable that DMD, GDC, and LDC might one day share common support code in druntime (personality, etc)? Could be many benefits like a larger test population. Probably not the personality routine, though that won't matter.
Re: DMD now does Dwarf style exception handling!
On Sunday, 3 January 2016 at 02:05:38 UTC, Walter Bright wrote: On 1/2/2016 4:17 PM, Jack Stouffer wrote: What is involved in catching C++ exceptions? Was this the hard part of the whole thing? DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step. Useless work. Almost nobody will throw exceptions from C++ code to D code. Same old same old : Walter could fix regressions, but instead he found a new nice useless toy to play, and after that, it will be a cause of new regressions. That's why D is always dead in the water.
core.atomic bug? windows 2008r2 dmd 2.69.2 x64
struct sts
{
size_t a1;
struct m1{
size_t a9;
size_t a10;
}
shared m1 t1;
}
int main(string[] argv)
{
auto y1 = new sts();
cas(&y1.t1,y1.t1,y1.t1);
return 0;
}
Re: DMD now does Dwarf style exception handling!
Walter Bright writes: > What I've been working on for the last month or so. > > https://github.com/D-Programming-Language/dmd/pull/5324 > > For Linux 64 anyway. Anyone who wants to do PRs to extend it to Linux > 32, OSX and FreeBSD, feel free! Unfortunately, this is of no help with > Win64, which uses its own unique system. DMD for Win32 already can > catch C++ exceptions, but Win32 is a dead platform. > > This is an enabling technology that will confer on D the ability to > catch C++ exceptions, which is key to interaction with native C++ > libraries. > > Next up: actually catching C++ exceptions! > > Thanks to everyone who helped out with this. Very cool. Is it conceivable that DMD, GDC, and LDC might one day share common support code in druntime (personality, etc)? Could be many benefits like a larger test population. -- Dan
Re: Google Summer of Code 2016
On Thursday, 31 December 2015 at 23:58:32 UTC, Craig Dillabaugh wrote: The deadline for the Google Summer of Code, 2016 is February 19th. Which means we have about a month and a half to put something together. For the time being I've recycled last years projects (with one dropped so far): http://wiki.dlang.org/GSOC_2016_Ideas#Ideas Since we were rejected with, more or less, the same set of proposals last year it seems unlikely we would succeed this year with the same lineup. So some new ideas (or some refreshing of the existing ideas) would be helpful. clip Happy New Year to everyone. Craig Just bumping my own thread here. Is there any interest is doing a GSOC application this year within the community? I don't mind doing the admin work, but having even a couple of solid new ideas for projects would improve the odds of a successful application.
Re: Proposal: Database Engine for D
What is Boost.Sprint? I haven't heard of it, and can't find it. Thanks! -- Andrei I believe he meant Boost Spirit http://www.boost.org/doc/libs/1_60_0/libs/spirit/doc/html/spirit/introduction.html Zz
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 20:07:55 UTC, Walter Bright wrote: On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote: It is important that this works. But it should be possible to create an operator algebra for any type: arithmetic types are a very small subset of types used in computing. What do you suggest when the operators and precedence of the desired algebraic type simply do not map cleanly onto C++ operators and precedence grammar? Allow users to define their own operators and redefine the precedence? Where is the line that shouldn't be crossed? On this point specifically, I'm still considering attempting to write a DIP because it would be very useful to have some user-defined operators available. Take the OCaml/F# approach where they provide a set of acceptable characters for operators and define precedence automatically (depending on first character of the name). (And definitely don't do the Haskell thing where any binary function can be turned into an infix op.) -Wyatt
Re: Proposal: Database Engine for D
On 01/04/2016 02:50 PM, rsw0x wrote: D did wonders in making template metaprogramming usable compared to C++, but sometimes it feels like trying to pound nails in with a screwdriver. Do you have examples of that awkwardness happening? Is it suitable to supplement those with CTFE? -- Andrei
Re: Proposal: Database Engine for D
On 01/04/2016 01:25 PM, Russel Winder via Digitalmars-d wrote: What is the problem with having the << and >> operators do input output. Very object-oriented. What is the connection between using shift operators for I/O and object orientation? But it would be D. Boost.Sprint code may look like EBNF, but it is C++. [snip] I avoid regular expressions except when editing using ed, sed, or emacs, so I cannot properly comment on the above. However I find Boost.Sprint a very sensible way of using compile-time meta-object protocols. You write a grammar in EBNF in the source code, and the compiler writes the parser. Excellent use of internal DSL. And type safe. I don't think regexen were the point as much as an example. What is Boost.Sprint? I haven't heard of it, and can't find it. Thanks! -- Andrei
Re: Proposal: Database Engine for D
On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote: Rusts macros show it can be done well. Do you have a few examples handy? Thanks. -- Andrei
Re: TIOBE December 2015 - D rose 5 positions
On Monday, 4 January 2016 at 11:12:49 UTC, Joakim wrote: I don't think Go's even hit the second tier yet, ie python and ruby, certainly not in the first tier with Java and C, though tough for such a young language to get up there. Well, Go and Swift are the two languages that are having a steep increasing curve on Google Trends. The other languages are either flat or going down (Java and C++). I think the curve matters more right now. People don't want to do manual memory management and want simple syntax and decent speed, but not necessarily optimal speed (80% is good enough?). That's what I perceive anyway. WebAsm will provide some form of concurrency also. Further, there are plans to eventually provide access to the DOM and all web APIs Yes, but it will take like 2-5 years before it gets adopted. WebWorkers are getting available now. (I am using it already.) Javascript use was driven by its monopoly in the browser, but that's soon going away. The most common reason given for using it on the server was to use the same language on the server and client, but that reasoning will now work _against_ javascript, as you'll be able to compile your server language to WebAsm instead. That will cripple javascript, and full access to the DOM from WebAsm will kill it off. I don't know. EcmaScript7 with TypeScript gradual typing might turn out to beat other scripting languages like Lua, Dart and even Python, Ruby... I am thinking of using WebAsm for the application engine and TypeScript + Angular2 for user interface. Unfortunately I don't know of any suitable WebAsm runtime-less language. D3 maybe? :) Of course, the entire web stack could be obsoleted in the meantime, which I think is actually the most likely outcome. In 20 years.
Re: Proposal: Database Engine for D
On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote:
On Mon, 2016-01-04 at 01:44 -0800, Walter Bright via Digitalmars-d
wrote:
1. Make doing C++ style iostreams hard.
What is the problem with having the << and >> operators do input
output. Very object-oriented.
I'm surprised you'd ask. I thought this was well known.
1. ugly as hell
2. not exception safe
3. not thread safe
4. interleaved output in the middle of lines when writing to both stdout and
stderr
2..4 are caused by inability to encapsulate a sequence of these operations.
2. Prevent clever use of operator overloading and expression
templates to create
languages that look like D, but are NOT.
But it would be D. Boost.Sprint code may look like EBNF, but it is C++.
#define BEGIN {
#define END }
is still C++, too.
3. Work well when using operator overloading to implement arithmetic
types.
It is important that this works. But it should be possible to create an
operator algebra for any type: arithmetic types are a very small subset
of types used in computing.
What do you suggest when the operators and precedence of the desired algebraic
type simply do not map cleanly onto C++ operators and precedence grammar? Allow
users to define their own operators and redefine the precedence? Where is the
line that shouldn't be crossed?
I avoid regular expressions except when editing using ed, sed, or
emacs, so I cannot properly comment on the above. However I find
Boost.Sprint a very sensible way of using compile-time meta-object
protocols. You write a grammar in EBNF in the source code, and the
compiler writes the parser. Excellent use of internal DSL. And type
safe.
EBNF doesn't map onto C++ operators and precedence, either. It's still a hack:
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form
With CFTE, the user can actually write actual EBNF.
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 18:28:15 UTC, Russel Winder wrote: On Mon, 2016-01-04 at 01:45 -0800, Walter Bright via Digitalmars-d wrote: On 1/3/2016 11:40 PM, Jacob Carlborg wrote: > There's of course AST macros as well, which have many other > good > use cases. > Unfortunately you don't like those either :( Neither Andrei nor I have changed our minds on that one. Pity I like good AST transforms: Groovy, Scala, Lisp, Clojure, Rust… C++ template meta-programming isn't really my cup of tea. Rusts macros show it can be done well. I agree heavily with this, it feels like an arbitrary limitation. D did wonders in making template metaprogramming usable compared to C++, but sometimes it feels like trying to pound nails in with a screwdriver. I think just looking at the kind of stuff being done in languages that enable AST macros might change minds.
Re: vibe.d benchmarks
Am 30.12.2015 um 21:32 schrieb yawniek: Sönke is already on it. http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/29110 i guess its not enough, there are still things that make vibe.d slow. i quickly tried https://github.com/nanoant/WebFrameworkBenchmark.git which is really a very simple benchmark but it shows about the general overhead. single core results against go-fasthttp with GOMAXPROCS=1 and vibe distribution disabled on a c4.2xlarge ec2 instance (archlinux): (...) its sad. Can you try with the latest GIT master? There are some important optimizations which are not in 0.7.26 (which has at least one performance regression).
Re: Tutorials section on vibed.org
Am 04.01.2016 um 19:04 schrieb Pradeep Gowda: On Monday, 4 January 2016 at 14:31:21 UTC, Sönke Ludwig wrote: Added! The footer of the website still says 2012-2014. Please fix that! Fixed, thanks!
Re: Proposal: Database Engine for D
On Mon, 2016-01-04 at 01:45 -0800, Walter Bright via Digitalmars-d wrote: > On 1/3/2016 11:40 PM, Jacob Carlborg wrote: > > There's of course AST macros as well, which have many other good > > use cases. > > Unfortunately you don't like those either :( > > Neither Andrei nor I have changed our minds on that one. Pity I like good AST transforms: Groovy, Scala, Lisp, Clojure, Rust… C++ template meta-programming isn't really my cup of tea. Rusts macros show it can be done well. -- 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: Proposal: Database Engine for D
On Mon, 2016-01-04 at 01:44 -0800, Walter Bright via Digitalmars-d wrote: > On 1/1/2016 3:33 AM, Russel Winder via Digitalmars-d wrote: > > Or alternative 4, fix D so that proper operator definition can be > > achieved. > > The way D's operator overloading is designed is not a mistake. It's > limitations > are a feature, not a bug. It was deliberately set up to: > > 1. Make doing C++ style iostreams hard. What is the problem with having the << and >> operators do input output. Very object-oriented. > 2. Prevent clever use of operator overloading and expression > templates to create > languages that look like D, but are NOT. But it would be D. Boost.Sprint code may look like EBNF, but it is C++. > 3. Work well when using operator overloading to implement arithmetic > types. It is important that this works. But it should be possible to create an operator algebra for any type: arithmetic types are a very small subset of types used in computing. > For example, I've seen operator overloading used in C++ to turn it > into a > sort-of regex language. The failures of it are: > > 1. Sort-of because C++ operator precedence and prefix/postfix grammar > is > different than that of regex, so it can't be emulated correctly. > > 2. It is visually indistinguishable from C++ code. You simply cannot > look at a > piece of code and tell it is regex with utterly different meaning, > rather than > the usual meanings. > > 3. Any error messages from misuse are utterly and totally > incomprehensible, > because the compiler is designed to compile C++ and gives C++ > messages, not > regex messages. > > 4. C++ ETs are legendary in their tendency to consume all the memory > in the > computer and take incredibly long to compile. Most fail when the > expressions > exceed a rather small level of complexity because of this. > > My not-so-humble opinion is these sorts of DSLs are technical > demonstrations, > but not useful nor desirable tools. > > *** > So, what does D do? > > http://dlang.org/phobos/std_regex.html > > D enables CTFE to write a PROPER compile time regex language, with > correct regex > grammar, correct regex tokens, regex-specific error messages, etc. > And it works > great! It's not a hack, compromise, or workaround. It's a real, > embedded DSL. > And it's faster than any other regex engine on the market. I avoid regular expressions except when editing using ed, sed, or emacs, so I cannot properly comment on the above. However I find Boost.Sprint a very sensible way of using compile-time meta-object protocols. You write a grammar in EBNF in the source code, and the compiler writes the parser. Excellent use of internal DSL. And type safe. -- 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: extern(C++, ns)
On Monday, 4 January 2016 at 15:02:05 UTC, Manu wrote: Yeah, I've used this process before. Last time I reported a raft of LDC bugs I spent a few days doing this... but it's very laborious, and I don't have time to do it. I'm doing this work on borrowed time as it is. Did you try dustmite? I usually set it up and let it run for a night on larger projects and it managed to reduce the bug every time so far. I need to feel productive and like I'm making progress, otherwise it fails to compete for timeshare with other high priority goals >_< Thats the problem with D at the moment, if it works its great, but if it doesn't, especially if you are on untested terrain like extern(C++) you loose tons of time.
Re: Proposal: Database Engine for D
On Mon, 2016-01-04 at 13:09 +, John Colvin via Digitalmars-d wrote: > […] > not sure when I'd use that though... At a trivial level that nonetheless leads to functionality that can be used more sensibly, think of testing factorial. You want property-based testing, but also you want a (well usually two) table of examples. Python via pytest.mark.parametrize does the latter very well. Hypothesis does the former. Spock enables both very easily. It is know that the tests for the Java driver to MongoDB relies on table-driven and property-based testing, mostly using Spock. -- 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: Tutorials section on vibed.org
On Monday, 4 January 2016 at 14:31:21 UTC, Sönke Ludwig wrote: Added! The footer of the website still says 2012-2014. Please fix that!
Re: Proposal: Database Engine for D
On Sunday, 3 January 2016 at 23:22:17 UTC, Jakob Jenkov wrote: You could just target your database at data analysis. Then you don't need to care about ACID, transactions etc. Just load all the data into memory, and start analyzing it. Also, you'd typically be scanning over large parts of the data set for each query, so you may not need to support a full query language. Just what is needed for data analysis. Later you can modify your engine to support ACID, more expressive query language etc. That's the plan:) Except no dedicated query language is planned. At least that's my vision based on what I know about D and databases currently. On one of the projects I am working on right now, we will also implement our own database engine. We need it to integrate tightly with the rest our architecture, and the only way to do that is to roll our own. We will also not be using SQL because SQL is so limiting. So, I'd say "go ahead" - you can only learn something from the project. I've "reinvented a lot of wheels" over the years, and each time I came out smarter than before. Not every reinvention was a success, but I always learned something from the process. Thanks! So at least one more soul believing that D can approach the SQL expressiveness in db domain. Cheers Piotrek
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 07:59:40 UTC, Jacob Carlborg wrote: On 2016-01-04 00:50, Andrei Alexandrescu wrote: This may in fact be good signal that an approach based on expression templates is not the most appropriate for D. -- Andrei This whole thread has already discussed and showed that D operator overloading is lacking in terms of expression templates. The post by Chris assumes no language changes. If D supported overloading all operators the opEquals method would not return true, it would return a proxy that overloaded the || operator. The whole lambda expression would only generate a single query. The rest of the post falls apart from this mistake. But most of the posts are related to DSL (->SQL). What do you think about solution where no DSL, VM or other intermediate layer is used? Also I have a theory that SQL appeared because of limiting expressiveness of other programming languages (like C) ;) Cheers Piotrek
Re: Proposal: Database Engine for D
On Sunday, 3 January 2016 at 19:48:42 UTC, Abdulhaq wrote: My two pence, if you want it to be fast then it must have a good implementation of indices. Your filter functions should not actually start collecting real records, but instead should simply change the way that the cursor traverses the underlying data store. You will need good query 'compilation' like the big boys do, which work out which tables and indices to use and in which order, based on stats of the data / indices. Agree (I mentioned about proxies before). But I'm not sure about "good query compilation" thing. Good storage management should do. Rest can be done in user code. If you want ACID then SQL seems like a good approach to me, certainly I wouldn't want anything ORM-like for updating / inserting data. Well. Some people really like SQL. I'm not one of them. I'm neither a fan of ORM+SQL. But I think ACID is not only reserved for SQL. There a number of good libraries out there already, SQLite obviously springs to mind. The SQLite project is great. It would be a fun project but perhaps a lot more work than you realised if you really want isolation levels, speed etc. Yes, I know. But one step at a time. It's a some kind of fun for me as well ;) Cheers Piotrek
Re: OT: std.logger was Re: std.experimental Timeline
Yes the cast is ugly, but then I'm writing dynamic content into stack arrays. I actually have a patch in the pipeline for this,. That patch require to change the protection for beginLogMsg, logMsgPart, finishLogMsg from protected to public and bye bye cast. logMsgPart already takes a const(char)[]. I actually thought the protection was public to begin with. Anyway, if people have issues with std.(experimental.)logger, please write to the forum, bugzilla, github, or directly to me.
Re: Proposal: Database Engine for D
On Saturday, 2 January 2016 at 20:47:37 UTC, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you
want this query to finish soonish. So you need to use an index.
But a full index scan isn't so great; you want to do an index
lookup if possible.
Correct.
That's simple enough; we generate proxy types to record what
properties you're using and what operations you're performing.
PersonProxy records that you're accessing a field 'surname',
gives a StringFieldProxy, and that records that you're checking
for equality with the string "Slughorn". The lambda returns
true when opEquals returns true.
But people write queries that are more complex than that, like:
people.filter!(x => x.surname == "Slughorn" || x.age <= 17);
First time you run this, x.surname.opEquals("Slughorn") returns
true and the expression as a whole returns true. You missed the
second part of the expression. That's bad.
So we need to evaluate this lambda twice per parameter.
Hmm. Probably we don't think about the "proxy" term in the same
way.
When I mentioned proxy I thought about a skeleton object to
access parts of the original heavy object. So in fact, filter
works on proxy and one evaluation is performed no matter how
complex the condition is. The proxy is responsible to retrieve
needed data. Additionally (I haven't mentioned it yet) we can
provide mechanism for data integrity when joining separate
objects.
You might be able to support queries as large as ten
comparisons in a reasonable timeframe. But for all but the most
trivial queries, it'll be faster to use SQL.
SQL is no magic. You can write a code to beat any SQL planner.
Also I think you had "joins" in mind which I guess are the
biggest problem for performance.
But "What if I tell there is no SQL" Not even under the hood.
Piotrek
Re: OT: std.logger was Re: std.experimental Timeline
On Monday, 4 January 2016 at 13:48:16 UTC, Robert burner Schadek wrote: On Monday, 4 January 2016 at 10:58:09 UTC, Jonathan M Davis wrote: So, to work for them, they would need std.experimental.logger to accept something like const(char)[] or an arbitrary ranges of characters and to not allocate inside of any of its logging functions. Any requirement to convert to string (be it by the user of the logger or inside of the logger itself) doesn't work with their requirements. as said above, no Logger has to allocate for logging, and no string has to be created. An allocation schema was selected however, to make multi threading work by default. Creating a user specific Logger that fits the Logger interface and that uses a static buffer to write the data to is properly less than 20 lines of code. Well, looking at your implementation in your other post, you're able to make it work by casting to string when it's not actually a string. So, you're circumventing the type system to make it work. Depending on what the base class does with the resulting string, it may work, but there's no guarantee that it will, especially if you end up deriving your logger class from a 3rd party one. For this code to be safe, msg in LogEntry really needs to be const(char)[] and not string. I'm not particularly familiar with std.experimental.logger as it stands, by I would guess that to fit Sociomantic's requirements, it would need to either manage to log without actually constructing any array of characters (e.g. by printing each of its elements in turn without actually putting them together first), or it would need to reuse a buffer every time it created the line to log (which would incur the cost of copying the characters but wouldn't normally have to allocate). But I don't know how well that fits in with the logger being hierarchical via classes (which solves other design requirements) or how close the current implementation is to that. Certainly, being forced to use classes does prevent the logger from using some of the typical techniques that we use (particularly with regards to ranges). So, the logger definitely presents some challenges that most other Phobos code doesn't have to deal with. :| Though obviously, you'd be more aware of that than anyone. :) - Jonathan M Davis If you guess of their requirements is correct, std.experimental.logger fulfills the requirements. Only by doing a risky cast that happens to work in a reduced example but does not work in the general case. Now, the changes required to avoid the cast should be minimal and straightforward, but as long as a cast to string is required in order to avoid allocating a string, the logger doesn't safely support avoiding allocations. My guess is that it didn't even occur to Dicebot to make the cast, but I doubt that he would be happy with that solution anyway, particularly given the recent PR and related discussion on adding message to Throwable (which returns const(char)[]): https://github.com/D-Programming-Language/druntime/pull/1445 Regardless, Dicebot will obviously have to talk with you about their requirements and why he thinks that std.logger doesn't fit them. - Jonathan M Davis
Re: vibe.d benchmarks
On Monday, 4 January 2016 at 10:32:41 UTC, Daniel Kozak wrote: V Sat, 02 Jan 2016 03:00:19 + Etienne Cimon via Digitalmars-d napsáno: On Friday, 1 January 2016 at 11:38:53 UTC, Daniel Kozak wrote: > On Thursday, 31 December 2015 at 18:23:17 UTC, Etienne Cimon > wrote: >> [...] > > ? With libasync, you can run multiple instances of your vibe.d server and the linux kernel will round robin the incoming connections. Yes, but I speak about one instance of vibe.d with multiple workerThreads witch perform really bad with libasync Yes, I will investigate this.
Re: extern(C++, ns)
On Sunday, 3 January 2016 at 17:53:38 UTC, Walter Bright wrote:
On 1/3/2016 9:14 AM, Marc Schütz wrote:
On Sunday, 3 January 2016 at 16:18:13 UTC, Walter Bright wrote:
No. If D is to support C++ namespaces, it has to support
declaring the same
identifier for different purposes in different namespaces.
C++ namespaces have
different scopes in C++. Doing anything else would make it
impossible to
connect to perfectly legitimate C++ programs. The WHOLE POINT
of C++
namespaces is to support declaring the same identifier in
different namespaces.
Yes, but the point of `extern(C++, ns)` is NOT to achieve the
same in D! D has
its own mechanisms for that, primarily the module system, as
well as hacks like
static structs. And I don't see how Manu's suggestion would
make it impossible
to link to some C++ programs. Can you give an example?
I did. You quoted it below :-)
But this is evidently not an example where it's "impossible to
connect to perfectly legitimate C++ programs", because there are
at least two practical ways to do so: 1) using the static struct
hack, and 2) placing the symbols into separate modules.
namespace ns1 { int identifier; }
namespace ns2 { int identifier; }
And why shouldn't they? It's correct and legitimate C++ code.
I guess in reality this would not be a frequent thing. Most
real C++ code will
have both instances of `identifier` declared in different
header files, and D's
modules will usually closely mirror those, so they will end up
in different
modules on the D side.
My experience with "who would ever write such code" is they
exist and you cannot wish them away. In a more general case, we
should allow as much C++ compatibility as we can, because every
shortcoming will be complained about at length. And, as Manu
pointed out, one is often not able to adjust the C++ side of
the bridge.
Besides, this isn't even an edge case. It's what C++ namespaces
are for.
I don't agree with this. Their primary purpose is to avoid name
collisions between symbols from different projects (or parts of a
project), or to establish a symbol hierarchy independent from the
source tree layout, but not to allow the same symbol several
times in the same header file. That may happen in a few cases as
a side effect, but I wouldn't say that's what they are made for.
In the rare case
That's a vast assumption. Manu is one programmer out of a
million.
Indeed I don't have statistics, but I think it's a reasonable
assumption. We're talking about a very specific case here: that
one C++ header declares symbols in several parallel (non-nested)
namespaces. This is the only way the kinds of collision described
by you can appear, if we stick to a 1:1 mapping between C++
headers and D modules. Do you have any real-world examples of
that? I looked at several large C++ projects on Github, but
couldn't find a single instance.
Offhand, I can't think at the moment why that wouldn't work,
but using structs as C++ namespaces did have problems I don't
recall at the moment, and:
1. It's ugly.
2. You're an expert, and it's wrong - the fields need to be
'static'. How will others fare?
Yeah, my bad. But note that it's easy to recognize that mistake:
it will fail to compile the first time you try to access one of
the members.
3. I suspect that this ugly thing will become "best practice",
and we won't be able to fix it in a backwards compatible way.
I merely wanted to show that there is a workaround if you
absolutely need them to be declared in the same module. As Manu
suggested, the usual and recommended way to handle this situation
would be to put them in separate modules, along with other
symbols in that namespace, no matter in which header file they
are declared.
4. Structs carry other baggage with them, such as 'init'
fields, TypeInfo's, default member functions, etc.
5. I don't share the opinion that a C++ namespace introducing a
scope, just as it does in C++, is something weird and
unexpected.
It is an unexpected behaviour for `extern`: neither `extern(C)`,
`extern(D)`, `extern(C++)`, `extern(Objective-C)`, nor any other
affect scoping or symbol lookup, only mangling and calling
convention.
Re: extern(C++, ns)
On 4 January 2016 at 02:10, Andrei Alexandrescu via Digitalmars-d wrote: > On 1/3/16 12:19 AM, Manu via Digitalmars-d wrote: >> >> I know I'll just get complaints from people to submit bugs; I have >> submit lots, and in many cases, I've tried to, but they're almost >> impossible to produce in isolation, only when a project gets 'real', ie, >> big enough that it's realistic in scope does it all start to break down. >> It's really hard to reduce a bug that I don't understand, somewhere >> among a program with 30-ish interconnected modules. > > > What I do is make a fresh copy of the project tree, and then start pruning > (heh) that down. Prune, rebuild, prune, rebuild etc. Whatever makes the > error go away put back in (editor "undo" is handy). It takes some getting > used to but it's an effective tool for reducing a bug to its essentials. I > suspect in your case e.g. no function definition is even necessary - only > declarations. -- Andrei Yeah, I've used this process before. Last time I reported a raft of LDC bugs I spent a few days doing this... but it's very laborious, and I don't have time to do it. I'm doing this work on borrowed time as it is. I need to feel productive and like I'm making progress, otherwise it fails to compete for timeshare with other high priority goals >_< The thing is, it's wasted effort anyway, because it's almost all a symptom of a bad design that should be changed for design reasons alone, regardless of bugs. Walter has already submit a patch for what I think is the key non-design-related bug causing me problems. I expect that'll lead to a lot less random errors and misdiagnoses when hacking at the main task of working-around the problems caused by broken design. I wonder if there's chance of getting the fix into 2.070? That would be really rocking.
Re: OT: std.logger was Re: std.experimental Timeline
As talk is cheap, here is the code: http://dpaste.dzfl.pl/ba4df05339f6 not 20 lines but for 99 lines you get two Loggers and some tests.
Re: IAllocator
On 01/03/2016 11:50 PM, Rikki Cattermole wrote: On 04/01/16 11:44 AM, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=15509 is up. Any takers? -- Andrei Now I'm worried, this will break a lot of my code. May break if you use the IAllocator type explicitly a lot; you need to change that name. I'm just not convinced that RefCounted is the correct tool for this job. It may not because it gives access to the underlying interface, which I'd rather keep encapsulated. I think a hand-defined proxy struct around the IAllocator type is the ticket. It changes the allocator type. IAllocator is an interface for a reason. It allows swapping things out without worrying about implementation and using templates. That won't go away. I guess I need to write the code to fully explain what's needed. Andrei
Re: Proposal: Database Engine for D
On 01/04/2016 01:49 AM, rumbu wrote: On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu wrote: Second, ET as a mechanism for SQL interface has other inherent limitations. Consider the "LIKE" operator in SQL, which has no ET equivalent in C++ with similar syntax, and no direct equivalent in LINQ. That doesn't mean the respective languages are broken. LINQ transforms StartsWith, EndsWith and Contains methods in LIKE queries under the hood since Entity Framework 4.0 (8 years ago). Also, when in doubt, there is an entire namespace dedicated to LINQ queries with direct SQL equivalents (including LIKE) - https://msdn.microsoft.com/en-us/library/system.data.linq.sqlclient.sqlmethods(v=vs.110).aspx Misunderstanding. Please re-read what I wrote. -- Andrei
Re: Proposal: Database Engine for D
On 01/04/2016 07:39 AM, Jacob Carlborg wrote: If you can't use the host language, i.e. Person.where(e => e.name == "John");, what's the point of inventing a new DSL? Why not just use SQL if the DSL needs to be in a string anyway. I agree. A CTFE SQL parser with automatic variable binding would be pretty rad. Not to mention it would by design take care of things like string injection attacks etc. Also: finding SQL syntax errors during compilation of D code... priceless. -- Andrei
Re: Proposal: Database Engine for D
On 01/04/2016 08:09 AM, John Colvin wrote:
On Monday, 4 January 2016 at 12:28:47 UTC, Russel Winder wrote:
I must now try creating a D version of the pytest.mark.parametrize
decorator – unless someone already has and I have just missed it.
I quick look at pytest.mark.parametrize suggests it could be implemented
with UDAs and a test-runner that finds all declarations a module
(recursively) and does all the relevant logic (e.g. that's got more than
one instance of parametrize, so do some sort of cartesian product of the
inputs) and actually runs the test.
The main thing that python has here over D is that D's UDAs can't
directly modify the function they're attached to, but I don't think
that's necessary for parametrize.
Interestingly, functions can query their own attributes:
@(3) auto attr()
{
return __traits(getAttributes, attr)[0];
}
unittest
{
assert(attr() == 3);
}
not sure when I'd use that though...
For computed attributes in template functions. -- Andrei
Re: Tutorials section on vibed.org
Am 04.01.2016 um 13:49 schrieb bachmeier: On Monday, 4 January 2016 at 09:53:45 UTC, Sönke Ludwig wrote: I've just added a sub page on vibed.org to collect links to all existing vibe.d tutorials [1]. If you know of any additional ones, or would like to have an existing one removed, please leave a quick comment: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/29242/ Thanks! [1]: https://vibed.org/tutorials Mike Parker's book "Learning D" has a long chapter devoted to vibe.d. Added!
Re: extern(C++, ns)
On 4 January 2016 at 03:53, Walter Bright via Digitalmars-d
wrote:
> On 1/3/2016 9:14 AM, Marc Schütz wrote:
>>
>> I guess in reality this would not be a frequent thing. Most real C++ code
>> will
>> have both instances of `identifier` declared in different header files,
>> and D's
>> modules will usually closely mirror those, so they will end up in
>> different
>> modules on the D side.
>
>
> My experience with "who would ever write such code" is they exist and you
> cannot wish them away.
There's nothing wrong with it if they do, they can easily address the
situation, and they would almost certainly do so by default as they
naturally structure the API into modules.
> In a more general case, we should allow as much C++
> compatibility as we can, because every shortcoming will be complained about
> at length. And, as Manu pointed out, one is often not able to adjust the C++
> side of the bridge.
How would this ever lead to adjustment of the C++ code in any case?
That's not an issue here.
We're going to mangle the appropriate C++ symbol either way, what
we're discussing is purely about the D code, and not making it awkward
for the D users.
It's not a 'shortcoming' to let the D coder lay out their modules how
they want to, that's normal expected behaviour. Anything that inhibits
the ability to organise your D code is a shortcoming, and this
behaviour is the biggest shortcoming of the extern(C++) experience by
far. It's cause for a bunch of really awkward problems, and it's
completely pointless; we have modules!
This behaviour inhibits C++ namespaces with the same name as the top
level D package (surely this is the 99% _expected_ case), and it also
needlessly reduces the pool of compatible namespaces to valid D
identifiers; a pointless restriction. You're arguing for "as much C++
compatibility as we can", while arguing for something that does
nothing but inhibit C++ compatibility, make it needlessly painful for
the D lib coder, and surprising and unconventional to the end-user...
this is Schrodinger's argument.
This decision impacts _every_ extern(C++) definition everywhere! They
all need to be aliased around into the appropriate locations where
they should have been defined in the first place. That's messy, hard
to follow, hard to explain, and hard to maintain.
Also the risk of 'invalid' C++ namespace names, which is an absurd
problem to have, only possible under this design since every C++
namespace name must also be a valid D identifier, is much greater than
your hypothetical non-problem case. I have already run into this
multiple times.
I am demonstrating legitimate real-world problems with the design, and
you hold fast to a broken design, because it protects against a single
hypothetical 'problem' with a trivial and natural solution.
I don't understand how it's possible to hold an objective resistance
to this change.
>> the same identifier actually does appear twice in the same
>> module, static structs can be used:
>>
>> struct ns1 {
>> extern(C++, ns1):
>> int identifier;
>> }
>> struct ns2 {
>> extern(C++, ns2):
>> int identifier;
>> }
>
>
> Offhand, I can't think at the moment why that wouldn't work, but using
> structs as C++ namespaces did have problems I don't recall at the moment,
> and:
>
> 1. It's ugly.
> 2. You're an expert, and it's wrong - the fields need to be 'static'. How
> will others fare?
> 3. I suspect that this ugly thing will become "best practice", and we won't
> be able to fix it in a backwards compatible way.
'Best practice' would be to make another module. It's not so much
'best practice' as, 'normal D behaviour'.
> 4. Structs carry other baggage with them, such as 'init' fields, TypeInfo's,
> default member functions, etc.
No structs, just make another module! >_< .. that's what they're for,
that's how you do it in D!
> 5. I don't share the opinion that a C++ namespace introducing a scope, just
> as it does in C++, is something weird and unexpected.
Because we're not writing C++ code, we're writing D code, and any
deviation from normal D behaviour should surely be taken as weird and
unexpected.
The fact that the lib was compiled from C++ code is uninteresting,
irrelevant, and possibly even unknown to the library user. As far as
they know, they're using a D lib, with an API presented to them in D's
terms. That's the point of writing bindings. Almost all the quality D
bindings I've ever used have made adaptations to present nicely for D
use, and extern(C++) is no different; the binding author will organise
their D modules in a sensible and logical manner wrt the api.
C libs are small and flat enough that they can sometimes get away with
direct 'machine' translation, but a good C++ binding will almost
certainly require some care by the binding author to make it work
nicely with D semantics, and feel natural to D users. This
hypothetical problem you're attached to will tend to iron out
naturally, and even if not, the workaround is trivial; put it
Re: OT: std.logger was Re: std.experimental Timeline
On Monday, 4 January 2016 at 10:58:09 UTC, Jonathan M Davis wrote: If I understand correctly (based on previous statements by Dicebot), the problem is that at Sociomantic, they reuse buffers heavily. So, they basically don't use string much of anywhere and instead use some combination of char[] and const(char)[] (so that the array elements can be given new values without reallocating), and std.experimental.logger - like a lot of typical D code - uses string, which means that when they log a message with std.experimental.logger, their buffer has to be copied into a string, which means that an allocation occurs, which in their environment is unacceptable. FileLogger is a Logger that can be used after only one allocation. new FileLogger; Everything else (logging, ...) does not require a single allocation. If you look at the documentation above [1] you will understand why. Building a MultiLogger (Logger of Loggers) that forwards the calls to the log functions to the contained Loggers without allocation is also trivial. Logging into a passed in buffer is also trivial (as long as you buffer is big enough for the data to log, but that is design problem). So, to work for them, they would need std.experimental.logger to accept something like const(char)[] or an arbitrary ranges of characters and to not allocate inside of any of its logging functions. Any requirement to convert to string (be it by the user of the logger or inside of the logger itself) doesn't work with their requirements. as said above, no Logger has to allocate for logging, and no string has to be created. An allocation schema was selected however, to make multi threading work by default. Creating a user specific Logger that fits the Logger interface and that uses a static buffer to write the data to is properly less than 20 lines of code. I'm not particularly familiar with std.experimental.logger as it stands, by I would guess that to fit Sociomantic's requirements, it would need to either manage to log without actually constructing any array of characters (e.g. by printing each of its elements in turn without actually putting them together first), or it would need to reuse a buffer every time it created the line to log (which would incur the cost of copying the characters but wouldn't normally have to allocate). But I don't know how well that fits in with the logger being hierarchical via classes (which solves other design requirements) or how close the current implementation is to that. Certainly, being forced to use classes does prevent the logger from using some of the typical techniques that we use (particularly with regards to ranges). So, the logger definitely presents some challenges that most other Phobos code doesn't have to deal with. :| Though obviously, you'd be more aware of that than anyone. :) - Jonathan M Davis If you guess of their requirements is correct, std.experimental.logger fulfills the requirements. [1] https://github.com/D-Programming-language/phobos/blob/master/std/experimental/logger/core.d#L812
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 11:19:38 UTC, Walter Bright wrote: ou didn't address my points. Have you used C++ ETs for production? They fall apart in real world use for the reasons I mentioned. It's one thing to read a paper about something, and another to use it for something larger than will fit on a slide. You are assuming template expressions. I am not. The main overhead when interacting with databases is network traffic, building the query should be done at runtime. No need for templates. I am in favour of having a clean core language (minimal language after desugaring/lowering) that can be manipulated using term rewriting/symbolic manipulation (or ast macros). But that sounds more like D4 than D2...?
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 12:28:47 UTC, Russel Winder wrote:
I must now try creating a D version of the
pytest.mark.parametrize decorator – unless someone already has
and I have just missed it.
I quick look at pytest.mark.parametrize suggests it could be
implemented with UDAs and a test-runner that finds all
declarations a module (recursively) and does all the relevant
logic (e.g. that's got more than one instance of parametrize, so
do some sort of cartesian product of the inputs) and actually
runs the test.
The main thing that python has here over D is that D's UDAs can't
directly modify the function they're attached to, but I don't
think that's necessary for parametrize.
Interestingly, functions can query their own attributes:
@(3) auto attr()
{
return __traits(getAttributes, attr)[0];
}
unittest
{
assert(attr() == 3);
}
not sure when I'd use that though...
Re: Tutorials section on vibed.org
On Monday, 4 January 2016 at 09:53:45 UTC, Sönke Ludwig wrote: I've just added a sub page on vibed.org to collect links to all existing vibe.d tutorials [1]. If you know of any additional ones, or would like to have an existing one removed, please leave a quick comment: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/29242/ Thanks! [1]: https://vibed.org/tutorials Mike Parker's book "Learning D" has a long chapter devoted to vibe.d.
Re: extern(C++, ns)
On 4 January 2016 at 02:18, Walter Bright via Digitalmars-d
wrote:
> On 1/3/2016 3:25 AM, Manu via Digitalmars-d wrote:
>>
>> On 3 January 2016 at 18:03, Walter Bright via Digitalmars-d
>> wrote:
>>>
>>>
>>> C++ doesn't have a module structure,
>>
>>
>> It's called the filesystem ;) .. People use folders and filenames to
>> describe what would be 'modules' in C, if C was said to have modules.
>> Sometimes they make namespaces that match the filesystem ;)
>
>
> I know how C++ name scoping works, after all, I implemented a C++ compiler.
> C++ doesn't have modules, and doesn't even have a semantic notion of files.
> You can pretend it has them, but when you talk about "edge cases not
> working", they aren't going to work in spades here.
That doesn't really matter though, we're talking about practical
bindings to C++ libraries here. It's a practical notion; it's natural
to want to distribute the symbols among D modules that logically
relate to the structure/layout of the C/C++ .h files. Or even adapt it
slightly to fit among D modules more naturally to the D user.
It's not a reasonable binding solution to tell the user they import
one uber-module with the entire C++ lib. That's the only case where
extern(C++, "ns") separating symbols by namespace is actually
meaningful. If they're spread among respective D modules, as they
would be, the name collision naturally won't happen, and it's very
convenient to resolve if it does occur.
>> This!!! You're on to it!!
>> That's exactly what I want; I ***REALLLY*** want the compiler to emit
>> that error message in that exact situation!
>> Please, please can we have that? :)
>
>
> No. If D is to support C++ namespaces, it has to support declaring the same
> identifier for different purposes in different namespaces. C++ namespaces
> have different scopes in C++. Doing anything else would make it impossible
> to connect to perfectly legitimate C++ programs. The WHOLE POINT of C++
> namespaces is to support declaring the same identifier in different
> namespaces.
The point of supporting C++ namespaces is for mangling, and nothing
more. We just want the linker to link.
D already has a module system, it's excellent, and we want to use it
exactly how it is. Its soul purpose is to allow you to declare the
same identifier multiple times under different module namespaces.
I don't want to see any change to D's standard naming patterns (as
seen by the D library consumer) because the linker is linking to
something that was compiled from C++. It should have no impact on D's
normal naming/scoping rules.
If the declaration is in the D module x.y, then the identifier is
x.y.Identifier, just like EVERYTHING. If I didn't want it to be there,
I would put it somewhere else. If I wanted it under x.y.ns.Identifier,
I would make a module x.y.ns and put it there.
If I have C++ ns1::X and ns2::X, then I can make respective D modules
x.y.ns1 and x.y.ns2 and put each declaration of X in each one...
normal D name resolution applies.
I really don't understand what the problem is? There must be something
I'm completely missing, because it makes no sense to me to make it
impossible for the user to place the declaration where they want it,
with no opt-out.
There's nothing problematic or inconvenient about separating symbols
with the same names into separate modules, that's what you do in D.
We're not writing C++ code, we're writing a D api for use by normal D
code. We're only *linking* to a C++ binary, and that's irrelevant to
the user of the lib. They don't want to see weird C++ details creeping
into the API, it would make no sense to the consumer. It should look
like any normal D api to them.
>> This would solve a lot of awkward issues.
>
>
> It'd be a river of bug reports, because sure as shootin', people are going
> to try to interface to this C++ code:
>
> namespace ns1 { int identifier; }
> namespace ns2 { int identifier; }
>
> And why shouldn't they? It's correct and legitimate C++ code.
Sure, and they would have almost certainly made a module 'ns1' and
another module 'ns2', and put each 'identifier' in their respective
place. That's the natural thing to do as a D programmer, and if
someone complains as you say, suggest they make another module for the
other symbol...
I don't believe the situation you propose will emerge; it would be
unnatural for a D user to expect that 2 symbols with the same name
would coexist in one module, and if it does, the solution is extremely
simple, and works well... just as well as all other normal D code.
Surely a D consumer of a C++ library would assume that the different
C++ namespaces have been sensibly mapped to D modules appropriately by
the person who wrote the bindings? The bindings will have been written
and organised to present comfortably to a D user.
>> Oh yeah, I just remembered another great case, I had this in C++:
>>namespace delegate {}
>> 'delegate' is not a valid identifier in D, I was going to come in here
>> and bang the drum
Re: Proposal: Database Engine for D
On 2016-01-04 12:14, Sebastiaan Koppe wrote: But then you are back to square one with regards to queries. If you can't use the host language, i.e. Person.where(e => e.name == "John");, what's the point of inventing a new DSL? Why not just use SQL if the DSL needs to be in a string anyway. -- /Jacob Carlborg
Re: Proposal: Database Engine for D
On 2016-01-04 10:44, Walter Bright wrote: So, what does D do? http://dlang.org/phobos/std_regex.html D enables CTFE to write a PROPER compile time regex language, with correct regex grammar, correct regex tokens, regex-specific error messages, etc. And it works great! It's not a hack, compromise, or workaround. It's a real, embedded DSL. And it's faster than any other regex engine on the market. And how would you do that for SQL. Build a CTFE SQL database? -- /Jacob Carlborg
Re: Proposal: Database Engine for D
On Mon, 2016-01-04 at 08:29 +, rsw0x via Digitalmars-d wrote: > […] > compiler plugins like Rust to enable AST macros could fix this > but walter and andrei seem extremely opposed to any form of > macros so we end up with ugly heavily templated ugly band-aids Rust may have macros, in fact it has two sorts, but they are not as useful as you might at first think. The macro system as in Rust stable is not up to the task of doing code generation such that you can replicate PyTest's pytest.mark.parametrize decorator in Rust. The compiler plugins that would allow this are only allowed in Rust nightly and are forbidden in Rust beta and stable. Rust nightly is effectively a totally different platform to Rust beta or stable, which is undermining the Rust platform. I must now try creating a D version of the pytest.mark.parametrize decorator – unless someone already has and I have just missed it. > shame, because I think D will quickly lose their lead in the > metaprogramming area if Rust keeps it up - e.g, someone already > made a GC Plugin for rust's compiler I think Rust and not C++17 is the biggest threat to D just now. I am still intending to rewrite Me TV in D. -- 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: Proposal: Database Engine for D
On 1/4/2016 2:34 AM, Ola Fosheim Grøstad wrote: On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote: My not-so-humble opinion is these sorts of DSLs are technical demonstrations, but not useful nor desirable tools. Well, this is wrong. They are desirable and work with tooling, editors, code completion etc. And also allow user extensions if done right. You didn't address my points. Have you used C++ ETs for production? They fall apart in real world use for the reasons I mentioned. It's one thing to read a paper about something, and another to use it for something larger than will fit on a slide.
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 07:48:14 UTC, Jacob Carlborg wrote:
Perhaps I'm missing something obvious but there are several
problems with this:
1. What happens when you use more than one query for the same
table at the same scope? In the above case, "Person" is already
defined the second time "db" is invoked. It's not possible to
add fields for already declared structs. Unless you use some
form of opDispatch backed by an associative array of variants
While it wasn't apparent, when I said "later" I meant "later" in
git's history. The second version would be in a future commit,
i.e. when changes are made. Then you can diff it and generate
migration code. (Obviously this requires the DSL to be in a
separate file without other code. We used to have such a
reflective system in place in our continuous deployment. It would
look at the changes in git since the last deployment and when
certain files changed it knew it had to do certain stuff.)
2. What happens if I want to execute a custom query in a
function, i.e. a query that is only used once. Will it generate
the sturct inside the function or am I forced to always use
this mixin at module level?
I suppose you need to declare each and every query in the DSL.
But you might be on to something ugly in what I am proposing.
Having said that, facebook seems to be going the DSL route.
https://facebook.github.io/graphql and
https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html
Another benefit of a DSL is that you can generate code for other
languages. For instance you could generate a JS, Swift or Android
client.
I still think it's a lot easier to declare the struct with
standard D code. I don't think the DSL adds any value in this
case. Just do something like:
@db struct Person
{
string name;
int age;
}
The @db attribute would allow to create the migrations.
But then you are back to square one with regards to queries.
Re: TIOBE December 2015 - D rose 5 positions
On Monday, 4 January 2016 at 08:34:06 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2016 at 05:47:40 UTC, Joakim wrote: according to github, which has nothing to do with D (there are several more miscategorized like that, look at #22 in the above list). Yes, DTrace files also end with ".d"... Not the cocos2d files though, no excuse there. Those are good hypotheses, not sure you can say OSS usage is a good _indicator_ yet, especially since I wouldn't say Go has taken off. I think it has, it might taper off early and be displaced by Swift, but it seems healthy. Rust appears to have hit an early plateu. I don't think Go's even hit the second tier yet, ie python and ruby, certainly not in the first tier with Java and C, though tough for such a young language to get up there. On the contrary, I suspect that we've passed "Peak JS", with WebAsm about to cripple it. How come? I would expect new programmers to be focused on JavaScript as they grew up with the less dysfunctional implementation. I don't think we are anywhere near "peak js". WebWorkers are coming now, and they change the game by providing isolated threads with fast message passing of heaps/arrays. Which I think is pretty good. WebAsm will provide some form of concurrency also. Further, there are plans to eventually provide access to the DOM and all web APIs: https://github.com/WebAssembly/design/blob/master/GC.md Javascript use was driven by its monopoly in the browser, but that's soon going away. The most common reason given for using it on the server was to use the same language on the server and client, but that reasoning will now work _against_ javascript, as you'll be able to compile your server language to WebAsm instead. That will cripple javascript, and full access to the DOM from WebAsm will kill it off. Of course, the entire web stack could be obsoleted in the meantime, which I think is actually the most likely outcome.
Re: OT: std.logger was Re: std.experimental Timeline
On Monday, 4 January 2016 at 09:24:44 UTC, Robert burner Schadek wrote: On Sunday, 3 January 2016 at 21:37:28 UTC, Dicebot wrote: Haven't found any issues with std.allocator so far but std.logger definitely is not Phobos ready per my requirements. I have been recently re-evaluating it as possible replacement for old Tango logger we use and found that in several places it forces unnecessary GC allocations and/or immutability (i.e. https://github.com/D-Programming-Language/phobos/blob/master/std/experimental/logger/core.d#L742 requires that log message must be formatted into immutable string before it can be passed to another logger). This is a deal breaker that can possibly require major API change to fix. I do not follow. 1. Tango passes a const(char)[] around [1]. What is the difference? 2. Have you looked at the doc and the impl. of FileLogger? They both show an easy how to implement a Logger without the GC. With that it is also trivial to make a MultiLogger that does not allocate. BTW, the default implementation is a direct result of the "by default multi-threading safe" requirement brought up multiple times during reviews. [1] https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d#L1297 If I understand correctly (based on previous statements by Dicebot), the problem is that at Sociomantic, they reuse buffers heavily. So, they basically don't use string much of anywhere and instead use some combination of char[] and const(char)[] (so that the array elements can be given new values without reallocating), and std.experimental.logger - like a lot of typical D code - uses string, which means that when they log a message with std.experimental.logger, their buffer has to be copied into a string, which means that an allocation occurs, which in their environment is unacceptable. So, to work for them, they would need std.experimental.logger to accept something like const(char)[] or an arbitrary ranges of characters and to not allocate inside of any of its logging functions. Any requirement to convert to string (be it by the user of the logger or inside of the logger itself) doesn't work with their requirements. I'm not particularly familiar with std.experimental.logger as it stands, by I would guess that to fit Sociomantic's requirements, it would need to either manage to log without actually constructing any array of characters (e.g. by printing each of its elements in turn without actually putting them together first), or it would need to reuse a buffer every time it created the line to log (which would incur the cost of copying the characters but wouldn't normally have to allocate). But I don't know how well that fits in with the logger being hierarchical via classes (which solves other design requirements) or how close the current implementation is to that. Certainly, being forced to use classes does prevent the logger from using some of the typical techniques that we use (particularly with regards to ranges). So, the logger definitely presents some challenges that most other Phobos code doesn't have to deal with. :| Though obviously, you'd be more aware of that than anyone. :) - Jonathan M Davis
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote: My not-so-humble opinion is these sorts of DSLs are technical demonstrations, but not useful nor desirable tools. Well, this is wrong. They are desirable and work with tooling, editors, code completion etc. And also allow user extensions if done right. Symbols should not be referenced as strings. That's bad. That's textual macro processing.
Re: vibe.d benchmarks
V Mon, 4 Jan 2016 08:37:10 +0100 Sönke Ludwig via Digitalmars-d napsáno: > Am 31.12.2015 um 13:44 schrieb Daniel Kozak via Digitalmars-d: > > > > vibe.d has (probably) bug it use threadPerCPU instead of corePerCPU > > in setupWorkerThreads, here is a commit which make possible to > > setup it by hand. > > > > https://github.com/rejectedsoftware/vibe.d/commit/f946c3a840eab4ef5f7b98906a6eb143509e1447 > > > > (I just modify vibe.d code to use all my 4 cores and it helps a lot) > > > > To use more threads it must be setup with distribute option: > > > > settings.options |= HTTPServerOption.distribute; > > //setupWorkerThreads(4); // works with master > > listenHTTP(settings, &hello); > > For me, threadsPerCPU correctly yields the number of logical cores > (i.e. coresPerCPU * 2 for hyper threading enabled CPUs), which is > usually the optimal number of threads*. What numbers did you > get/expect? > On my AMD FX4100 (4 cores) and my AMD AMD A10-7850K(4 core) it is return 1. > One actual issue could be that, judging by the name, these functions > would yield the wrong numbers for multi-processor systems. I didn't > try that so far. Do we have a function in Phobos/Druntime to get the > number of processors? > > * Granted, HT won't help for pure I/O payloads, but worker threads > are primarily meant for computational tasks.
Re: vibe.d benchmarks
V Sat, 02 Jan 2016 03:00:19 + Etienne Cimon via Digitalmars-d napsáno: > On Friday, 1 January 2016 at 11:38:53 UTC, Daniel Kozak wrote: > > On Thursday, 31 December 2015 at 18:23:17 UTC, Etienne Cimon > > wrote: > >> On Thursday, 31 December 2015 at 13:29:49 UTC, Daniel Kozak > >> wrote: > >>> On Thursday, 31 December 2015 at 12:09:30 UTC, Etienne Cimon > >>> wrote: > [...] > >>> > >>> When I use HTTPServerOption.distribute with libevent I get > >>> better performance but with libasync it drops from 2 > >>> req/s to 80 req/s. So maybe some another performance problem > >> > >> I launch libasync programs as multiple processes, a bit like > >> postgresql. The TCP listening is done with REUSEADDR, so the > >> kernel can distribute it and it scales linearly without any > >> fear of contention on the GC. My globals go in redis or > >> databases > > > > ? > > With libasync, you can run multiple instances of your vibe.d > server and the linux kernel will round robin the incoming > connections. Yes, but I speak about one instance of vibe.d with multiple workerThreads witch perform really bad with libasync
Re: Stripping Data Symbols (Win64)
On Friday, 1 January 2016 at 13:57:01 UTC, Rainer Schuetze wrote: Please note that building with -lib puts every function/declaration into it's own object file inside the library, and unused class declarations are no longer in the linked executable. Ok, that is very good information. I should be able to build a test case out of that. Kind Regards Benjamin Thaut
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu
wrote:
Second, ET as a mechanism for SQL interface has other inherent
limitations. Consider the "LIKE" operator in SQL, which has no
ET equivalent in C++ with similar syntax, and no direct
like(Person.Name,"peter%")
Person.Name == pattern("peter%")
On another example, C++'s overloading of &&, ||, and the comma
operator are considered downright disastrous and are
unrecommended by virtually all coding standards and guidelines,
Guideline means that you should think hard about it before you do
break it. A guidelines does not mean that you never should do it.
It means you should only break the guideline when you have good
reasons to do so.
If you can overload "and" and "or", you also can implement
ternary logic, fuzzy logic and other logics. In some cases that
is desirable.
In C++ features were abused when they were new because people
were eager to stretch new features to the limits. This is not a
problem in regular C++ programs. And in the case of C++
iostreams, it has become an idiom that isn't causing any
problems. C++ programmers are never confused by shift and output
operators.
But if this is a big deal the easy solution is to add unicode
operators without default behaviour.
String processing is not an acceptable alternative, it ruins
tooling. You should essentially never be able to turn a symbol
into a string and vice versa. D unfortunately allows you to do
it. That is a mal-feature aka a textual macro feature.
You can't really say that D has gotten rid of macros when you
actually encourage using macro-like textual substitution features
in place of processing proper symbols. That is an outdated 70s
paradigm.
Tutorials section on vibed.org
I've just added a sub page on vibed.org to collect links to all existing vibe.d tutorials [1]. If you know of any additional ones, or would like to have an existing one removed, please leave a quick comment: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/29242/ Thanks! [1]: https://vibed.org/tutorials
Re: Proposal: Database Engine for D
On 1/1/2016 3:37 AM, Russel Winder via Digitalmars-d wrote: On Fri, 2016-01-01 at 10:45 +, Ola Fosheim Grøstad via Digitalmars- d wrote: In D1 Walter made a point about restricting operator overloading to discourage reuse of operators. In D2 there are many ways to Java also went the route of "operator definition is too hard for programmers to deal with so we will not allow it". "Also" is the wrong word. See my other post in this thread for why that was done, and no, it is not Java's reason. It has nothing to do with "too hard for programmers".
Re: Proposal: Database Engine for D
On 1/3/2016 11:40 PM, Jacob Carlborg wrote: There's of course AST macros as well, which have many other good use cases. Unfortunately you don't like those either :( Neither Andrei nor I have changed our minds on that one.
Re: Proposal: Database Engine for D
On 1/1/2016 3:33 AM, Russel Winder via Digitalmars-d wrote: Or alternative 4, fix D so that proper operator definition can be achieved. The way D's operator overloading is designed is not a mistake. It's limitations are a feature, not a bug. It was deliberately set up to: 1. Make doing C++ style iostreams hard. 2. Prevent clever use of operator overloading and expression templates to create languages that look like D, but are NOT. 3. Work well when using operator overloading to implement arithmetic types. For example, I've seen operator overloading used in C++ to turn it into a sort-of regex language. The failures of it are: 1. Sort-of because C++ operator precedence and prefix/postfix grammar is different than that of regex, so it can't be emulated correctly. 2. It is visually indistinguishable from C++ code. You simply cannot look at a piece of code and tell it is regex with utterly different meaning, rather than the usual meanings. 3. Any error messages from misuse are utterly and totally incomprehensible, because the compiler is designed to compile C++ and gives C++ messages, not regex messages. 4. C++ ETs are legendary in their tendency to consume all the memory in the computer and take incredibly long to compile. Most fail when the expressions exceed a rather small level of complexity because of this. My not-so-humble opinion is these sorts of DSLs are technical demonstrations, but not useful nor desirable tools. *** So, what does D do? http://dlang.org/phobos/std_regex.html D enables CTFE to write a PROPER compile time regex language, with correct regex grammar, correct regex tokens, regex-specific error messages, etc. And it works great! It's not a hack, compromise, or workaround. It's a real, embedded DSL. And it's faster than any other regex engine on the market.
OT: std.logger was Re: std.experimental Timeline
On Sunday, 3 January 2016 at 21:37:28 UTC, Dicebot wrote: Haven't found any issues with std.allocator so far but std.logger definitely is not Phobos ready per my requirements. I have been recently re-evaluating it as possible replacement for old Tango logger we use and found that in several places it forces unnecessary GC allocations and/or immutability (i.e. https://github.com/D-Programming-Language/phobos/blob/master/std/experimental/logger/core.d#L742 requires that log message must be formatted into immutable string before it can be passed to another logger). This is a deal breaker that can possibly require major API change to fix. I do not follow. 1. Tango passes a const(char)[] around [1]. What is the difference? 2. Have you looked at the doc and the impl. of FileLogger? They both show an easy how to implement a Logger without the GC. With that it is also trivial to make a MultiLogger that does not allocate. BTW, the default implementation is a direct result of the "by default multi-threading safe" requirement brought up multiple times during reviews. [1] https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d#L1297
Re: TIOBE December 2015 - D rose 5 positions
On Monday, 4 January 2016 at 05:47:40 UTC, Joakim wrote: according to github, which has nothing to do with D (there are several more miscategorized like that, look at #22 in the above list). Yes, DTrace files also end with ".d"... Those are good hypotheses, not sure you can say OSS usage is a good _indicator_ yet, especially since I wouldn't say Go has taken off. I think it has, it might taper off early and be displaced by Swift, but it seems healthy. Rust appears to have hit an early plateu. You seem to have gotten that quote from the README for the OSS project, but we were talking about the stack at Docker, the company. I have no idea. They appear to have both Go and Python projects on Github, and some other languages. I think D has a real complexity problem, so anything we can do to make it simpler _while still maintaining its power_ would be welcomed. That's a good starting point! :) You think there were more hours billed by programmers for javascript in 2015 than any one of Java, C, C#, or C++? I doubt it. Yes, I think Java and JavaScript are on top. On the contrary, I suspect that we've passed "Peak JS", with WebAsm about to cripple it. How come? I would expect new programmers to be focused on JavaScript as they grew up with the less dysfunctional implementation. I don't think we are anywhere near "peak js". WebWorkers are coming now, and they change the game by providing isolated threads with fast message passing of heaps/arrays. Which I think is pretty good.
Re: Proposal: Database Engine for D
On Monday, 4 January 2016 at 07:55:53 UTC, Jacob Carlborg wrote:
On 2016-01-02 21:47, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you
want this
query to finish soonish. So you need to use an index. But a
full index
scan isn't so great; you want to do an index lookup if
possible.
That's simple enough; we generate proxy types to record what
properties
you're using and what operations you're performing.
PersonProxy records
that you're accessing a field 'surname', gives a
StringFieldProxy, and
that records that you're checking for equality with the string
"Slughorn".
The lambda returns true when opEquals returns true.
But people write queries that are more complex than that, like:
people.filter!(x => x.surname == "Slughorn" || x.age <= 17);
First time you run this, x.surname.opEquals("Slughorn")
returns true and
the expression as a whole returns true. You missed the second
part of the
expression. That's bad.
If D had better operator overloading or supported AST macros,
opEquals would not return true. It would return a new proxy
that overloads the || operator. The rest of the post falls
apart from this mistake.
compiler plugins like Rust to enable AST macros could fix this
but walter and andrei seem extremely opposed to any form of
macros so we end up with ugly heavily templated ugly band-aids
shame, because I think D will quickly lose their lead in the
metaprogramming area if Rust keeps it up - e.g, someone already
made a GC Plugin for rust's compiler
Re: Proposal: Database Engine for D
On 2016-01-04 00:50, Andrei Alexandrescu wrote: This may in fact be good signal that an approach based on expression templates is not the most appropriate for D. -- Andrei This whole thread has already discussed and showed that D operator overloading is lacking in terms of expression templates. The post by Chris assumes no language changes. If D supported overloading all operators the opEquals method would not return true, it would return a proxy that overloaded the || operator. The whole lambda expression would only generate a single query. The rest of the post falls apart from this mistake. -- /Jacob Carlborg
Re: Proposal: Database Engine for D
On 2016-01-02 21:47, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you want this
query to finish soonish. So you need to use an index. But a full index
scan isn't so great; you want to do an index lookup if possible.
That's simple enough; we generate proxy types to record what properties
you're using and what operations you're performing. PersonProxy records
that you're accessing a field 'surname', gives a StringFieldProxy, and
that records that you're checking for equality with the string "Slughorn".
The lambda returns true when opEquals returns true.
But people write queries that are more complex than that, like:
people.filter!(x => x.surname == "Slughorn" || x.age <= 17);
First time you run this, x.surname.opEquals("Slughorn") returns true and
the expression as a whole returns true. You missed the second part of the
expression. That's bad.
If D had better operator overloading or supported AST macros, opEquals
would not return true. It would return a new proxy that overloads the ||
operator. The rest of the post falls apart from this mistake.
--
/Jacob Carlborg
