Re: Parameterized unit testing and benchmarking of phobos
On 10/08/2014 11:37 PM, Robert burner Schadek wrote: Lately, I find myself wondering, if I should add parameterized unit tests to std.string, because the last few bugs I fixed where not caught by tests, as the test-data was not good enough. I know random data is not perfect either, but it would be good addition IMO. https://github.com/MartinNowak/qcheck Haven't used it for quite a while, file a bug report if anything doesn't work.
Re: D2 (Debian) + MSSQL
On 14/10/14 08:11, Sergey wrote: Wrong, I need to have: $ dmd test_tds_connect.d tds.d You can use "rdmd" to compile and run an application: $ rdmd test_tds_connect.d It will automatically find all (D) dependencies for "test_tds_connect" and compile those as well. But you still need to link with the C library, as in the C example. $ rdmd -L-lsybdb test_tds_connect.d "-L" is the linker flag. -- /Jacob Carlborg
Re: UFCS in C++
On 14/10/14 03:55, Steven Schveighoffer wrote: The concept is in D1 for arrays since as long as I've ever used D. As far as I recall, it was an accidental feature of arrays and perhaps associative arrays. Might be a bit hard to track down that. -- /Jacob Carlborg
Re: D2 (Debian) + MSSQL
On Tuesday, 14 October 2014 at 04:46:19 UTC, Sergey wrote: I try to do in this: D version: http://pastebin.com/7tGyytDh Tds file: http://pastebin.com/JCA8XQH0 C version: http://pastebin.com/FWJM4B6X First I checked the C version. When I did this: $ gcc -o connect_mssql connect_mssql.c I got these errors: /tmp/ccmW3YHR.o: In function `main': connect_mssql.c:(.text+0x18): undefined reference to `dbinit' connect_mssql.c:(.text+0x50): undefined reference to `dblogin' connect_mssql.c:(.text+0xaf): undefined reference to `dbsetlname' connect_mssql.c:(.text+0xce): undefined reference to `dbsetlname' connect_mssql.c:(.text+0xed): undefined reference to `dbsetlname' connect_mssql.c:(.text+0x12d): undefined reference to `dbsetlname' connect_mssql.c:(.text+0x14c): undefined reference to `tdsdbopen' connect_mssql.c:(.text+0x19b): undefined reference to `dbuse' connect_mssql.c:(.text+0x1dd): undefined reference to `dbloginfree' connect_mssql.c:(.text+0x1f4): undefined reference to `dbcmd' connect_mssql.c:(.text+0x203): undefined reference to `dbsqlexec' connect_mssql.c:(.text+0x245): undefined reference to `dbresults' connect_mssql.c:(.text+0x277): undefined reference to `dbbind' connect_mssql.c:(.text+0x2a9): undefined reference to `dbbind' connect_mssql.c:(.text+0x2e4): undefined reference to `dbnextrow' connect_mssql.c:(.text+0x2f8): undefined reference to `dbfreebuf' connect_mssql.c:(.text+0x307): undefined reference to `dbclose' connect_mssql.c:(.text+0x30c): undefined reference to `dbexit' collect2: error: ld returned 1 exit status And then I added this: "-l sybdb" and it works. $ gcc -o connect_mssql connect_mssql.c -l sybdb $ ./connect_mssql (I got some data from sql server) Then I tried to do it on D: $ dmd test_tds_connect.d And I received similar errors: test_tds_connect.o: In function `_Dmain': test_tds_connect.d:(.text._Dmain+0x64): undefined reference to `dbinit' test_tds_connect.d:(.text._Dmain+0x88): undefined reference to `dblogin' test_tds_connect.d:(.text._Dmain+0xc4): undefined reference to `dbsetluser' test_tds_connect.d:(.text._Dmain+0xdb): undefined reference to `dbsetlpwd' test_tds_connect.d:(.text._Dmain+0xf2): undefined reference to `dbsetlapp' test_tds_connect.d:(.text._Dmain+0x12c): undefined reference to `dbsetlhost' test_tds_connect.d:(.text._Dmain+0x140): undefined reference to `dbopen' test_tds_connect.d:(.text._Dmain+0x18c): undefined reference to `dbuse' test_tds_connect.d:(.text._Dmain+0x1df): undefined reference to `dbloginfree' test_tds_connect.d:(.text._Dmain+0x1f0): undefined reference to `dbcmd' test_tds_connect.d:(.text._Dmain+0x1fe): undefined reference to `dbsqlexec' test_tds_connect.d:(.text._Dmain+0x22b): undefined reference to `dbresults' test_tds_connect.d:(.text._Dmain+0x243): undefined reference to `dbbind' test_tds_connect.d:(.text._Dmain+0x25b): undefined reference to `dbbind' test_tds_connect.d:(.text._Dmain+0x273): undefined reference to `dbbind' test_tds_connect.d:(.text._Dmain+0x281): undefined reference to `dbnextrow' test_tds_connect.d:(.text._Dmain+0x2d4): undefined reference to `dbfreebuf' test_tds_connect.d:(.text._Dmain+0x2df): undefined reference to `dbclose' test_tds_connect.d:(.text._Dmain+0x2e4): undefined reference to `dbexit' collect2: error: ld returned 1 exit status --- errorlevel 1 I need to add sybdb when building on D? How to do it? Thanks in advance. Wrong, I need to have: $ dmd test_tds_connect.d tds.d test_tds_connect.o: In function `_Dmain': tds.d:(.text._Dmain+0x64): undefined reference to `dbinit' tds.d:(.text._Dmain+0x88): undefined reference to `dblogin' tds.d:(.text._Dmain+0x140): undefined reference to `dbopen' tds.d:(.text._Dmain+0x18c): undefined reference to `dbuse' tds.d:(.text._Dmain+0x1df): undefined reference to `dbloginfree' tds.d:(.text._Dmain+0x1f0): undefined reference to `dbcmd' tds.d:(.text._Dmain+0x1fe): undefined reference to `dbsqlexec' tds.d:(.text._Dmain+0x22b): undefined reference to `dbresults' tds.d:(.text._Dmain+0x243): undefined reference to `dbbind' tds.d:(.text._Dmain+0x25b): undefined reference to `dbbind' tds.d:(.text._Dmain+0x273): undefined reference to `dbbind' tds.d:(.text._Dmain+0x281): undefined reference to `dbnextrow' tds.d:(.text._Dmain+0x2d4): undefined reference to `dbfreebuf' tds.d:(.text._Dmain+0x2df): undefined reference to `dbclose' tds.d:(.text._Dmain+0x2e4): undefined reference to `dbexit' test_tds_connect.o: In function `dbsetluser': tds.d:(.text.dbsetluser+0x18): undefined reference to `dbsetlname' test_tds_connect.o: In function `dbsetlpwd': tds.d:(.text.dbsetlpwd+0x18): undefined reference to `dbsetlname' test_tds_connect.o: In function `dbsetlapp': tds.d:(.text.dbsetlapp+0x18): undefined reference to `dbsetlname' test_tds_connect.o: In function `dbsetlhost': tds.d:(.text.dbsetlhost+0x18): undefined reference to `dbsetlname' collect2: error: ld returned 1 exit status --- errorlevel 1
Re: Windows drivers written in D
On Monday, 13 October 2014 at 23:28:05 UTC, Piotrek wrote: On Monday, 13 October 2014 at 21:50:20 UTC, eles wrote: Short answer is: yes, you cand write, but you cannot compile. Wait, what? Do you mean link or maybe load? I don't write Linux kernel modules, but I bet you can get it working. Check out the "betterC" switch to get away with runtime dependences. There were some post related to minimal executables recently. Piotrek Yes, I should have a second look at betterC
Re: D2 (Debian) + MSSQL
I try to do in this: D version: http://pastebin.com/7tGyytDh Tds file: http://pastebin.com/JCA8XQH0 C version: http://pastebin.com/FWJM4B6X First I checked the C version. When I did this: $ gcc -o connect_mssql connect_mssql.c I got these errors: /tmp/ccmW3YHR.o: In function `main': connect_mssql.c:(.text+0x18): undefined reference to `dbinit' connect_mssql.c:(.text+0x50): undefined reference to `dblogin' connect_mssql.c:(.text+0xaf): undefined reference to `dbsetlname' connect_mssql.c:(.text+0xce): undefined reference to `dbsetlname' connect_mssql.c:(.text+0xed): undefined reference to `dbsetlname' connect_mssql.c:(.text+0x12d): undefined reference to `dbsetlname' connect_mssql.c:(.text+0x14c): undefined reference to `tdsdbopen' connect_mssql.c:(.text+0x19b): undefined reference to `dbuse' connect_mssql.c:(.text+0x1dd): undefined reference to `dbloginfree' connect_mssql.c:(.text+0x1f4): undefined reference to `dbcmd' connect_mssql.c:(.text+0x203): undefined reference to `dbsqlexec' connect_mssql.c:(.text+0x245): undefined reference to `dbresults' connect_mssql.c:(.text+0x277): undefined reference to `dbbind' connect_mssql.c:(.text+0x2a9): undefined reference to `dbbind' connect_mssql.c:(.text+0x2e4): undefined reference to `dbnextrow' connect_mssql.c:(.text+0x2f8): undefined reference to `dbfreebuf' connect_mssql.c:(.text+0x307): undefined reference to `dbclose' connect_mssql.c:(.text+0x30c): undefined reference to `dbexit' collect2: error: ld returned 1 exit status And then I added this: "-l sybdb" and it works. $ gcc -o connect_mssql connect_mssql.c -l sybdb $ ./connect_mssql (I got some data from sql server) Then I tried to do it on D: $ dmd test_tds_connect.d And I received similar errors: test_tds_connect.o: In function `_Dmain': test_tds_connect.d:(.text._Dmain+0x64): undefined reference to `dbinit' test_tds_connect.d:(.text._Dmain+0x88): undefined reference to `dblogin' test_tds_connect.d:(.text._Dmain+0xc4): undefined reference to `dbsetluser' test_tds_connect.d:(.text._Dmain+0xdb): undefined reference to `dbsetlpwd' test_tds_connect.d:(.text._Dmain+0xf2): undefined reference to `dbsetlapp' test_tds_connect.d:(.text._Dmain+0x12c): undefined reference to `dbsetlhost' test_tds_connect.d:(.text._Dmain+0x140): undefined reference to `dbopen' test_tds_connect.d:(.text._Dmain+0x18c): undefined reference to `dbuse' test_tds_connect.d:(.text._Dmain+0x1df): undefined reference to `dbloginfree' test_tds_connect.d:(.text._Dmain+0x1f0): undefined reference to `dbcmd' test_tds_connect.d:(.text._Dmain+0x1fe): undefined reference to `dbsqlexec' test_tds_connect.d:(.text._Dmain+0x22b): undefined reference to `dbresults' test_tds_connect.d:(.text._Dmain+0x243): undefined reference to `dbbind' test_tds_connect.d:(.text._Dmain+0x25b): undefined reference to `dbbind' test_tds_connect.d:(.text._Dmain+0x273): undefined reference to `dbbind' test_tds_connect.d:(.text._Dmain+0x281): undefined reference to `dbnextrow' test_tds_connect.d:(.text._Dmain+0x2d4): undefined reference to `dbfreebuf' test_tds_connect.d:(.text._Dmain+0x2df): undefined reference to `dbclose' test_tds_connect.d:(.text._Dmain+0x2e4): undefined reference to `dbexit' collect2: error: ld returned 1 exit status --- errorlevel 1 I need to add sybdb when building on D? How to do it? Thanks in advance.
Re: Will D ever get optional named parameters?
On 10/13/14, 4:18 PM, Walter Bright wrote:
On 10/13/2014 7:23 AM, Ary Borenszweig wrote:
On 10/13/14, 5:47 AM, Walter Bright wrote:
On 10/13/2014 1:29 AM, "岩倉 澪" wrote:
Are there good reasons not to add something like this to the language,
or is it
simply a matter of doing the work? Has it been discussed much?
Named parameters interact badly with overloading.
Could you give an example?
Nothing requires function overloads to use the same names in the same
order for parameters. "color" can be the name for parameter 1 in one
overload and for parameter 3 in another and not be there at all for a
third.
Parameters need not be named in D:
int foo(long);
int foo(ulong x);
Named parameters are often desired so that default arguments need not be
in order at the end:
int foo(int x = 5, int y);
int foo(int y, int z);
To deal with all this, a number of arbitrary rules will have to be
created. Overloading is already fairly complex, with the implemented
notions of partial ordering. Even if this could all be settled, is it
worth it? Can anyone write a document explaining this to people? Do
people really want pages and pages of specification for this?
One simple thing we did in Crystal is to allow invoking a function with
named arguments only for arguments that have a default value. For example:
void foo(int x, int y = 2, int z = 3) { ... }
foo(x, y: 10);
foo(x, y: 10, z: 20);
foo(x, z: 30)
But not this:
foo(x: 10)
The logic behind this is that named arguments are usually wanted when
you want to replace one of the default values while keeping the others'
defaults. You could specify names for arguments that don't have a
default value, but that only gives a small readability aid. Changing a
default value in the middle is a new feature.
This greatly simplifies the logic, since parameter reordering can only
happen for names that have default values and you can always fill the
gaps. Also, default values can also appear last in a function signature.
Stil Haus Kitchens
I searched for over a month and then came across Stilhaus Kitchens who beat everyone's price by a long way.
Re: @safety of Array
On Tuesday, 14 October 2014 at 01:47:10 UTC, Brad Roberts via Digitalmars-d wrote: That's why I asked the question I did. The core question isn't about what the current implementation is or does but about where it should end up. Should Array be usable in @safe code. It should but it can't unless something like `scope` is implemented. We can't have @safe in standard library that doesn't hold @safe promises.
Re: UFCS in C++
On 10/13/2014 6:55 PM, Steven Schveighoffer wrote: On 10/13/14 2:50 PM, Walter Bright wrote: On 10/13/2014 1:53 AM, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_xfy_vs_fxy/ and: https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_xfy_vs_fxy/cl8fil5 Anyone remember just when it appeared in D? (It's not in D1.) The concept is in D1 for arrays since as long as I've ever used D. I can't see the version exactly that added UFCS, but 2.058 (2011) says: * Allow 1.userproperty syntax Which I think is when it was really added. -Steve Thanks!
Re: UFCS in C++
On 10/13/14 2:50 PM, Walter Bright wrote: On 10/13/2014 1:53 AM, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_xfy_vs_fxy/ and: https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_xfy_vs_fxy/cl8fil5 Anyone remember just when it appeared in D? (It's not in D1.) The concept is in D1 for arrays since as long as I've ever used D. I can't see the version exactly that added UFCS, but 2.058 (2011) says: * Allow 1.userproperty syntax Which I think is when it was really added. -Steve
Re: Will D ever get optional named parameters?
On Monday, 13 October 2014 at 10:53:50 UTC, ketmar via Digitalmars-d wrote: if we'll add proper AA literals, they can be used instead. methinks. I think this would be a decent alternative. On Monday, 13 October 2014 at 16:08:08 UTC, ponce wrote: Work-around I see a lot in C++: --- bool filled = true; drawCircle(filled); --- instead of: --- drawCircle(true); --- This doesn't provide all the benefit of named parameters (in particular, their use in combination with default arguments Other workarounds include associative arrays, and the so-called "Named Parameter Idiom" http://www.parashift.com/c++-faq-lite/named-parameter-idiom.html
Re: @safety of Array
On 10/13/2014 1:28 PM, monarch_dodra via Digitalmars-d wrote: On Monday, 13 October 2014 at 17:16:40 UTC, Brad Roberts via Digitalmars-d wrote: On 10/13/2014 7:47 AM, Andrei Alexandrescu via Digitalmars-d wrote: On 10/12/14, 5:41 PM, Brad Roberts via Digitalmars-d wrote: I know it's a tricky implementation, but let's focus on the goal.. should Array be usable in @safe code? Yes. In order for that to be 100% automatically checkable, we need the rules restricting escape of addresses of returns by reference. -- Andrei 100% checkable isn't required right now. For it to be used in an @safe context all that's needed is liberal use of @trusted. That can be refined over time to a more checked version. We shouldn't wait for checkability. Will one of you experts in the impl of Array volunteer to make the appropriate changes? The issue is that it's *not* safe though. You can escape the reference, destroy it, and end up with a dangling pointer. Arbitrarily marking things as trusted seriously undermines what safe means. @trusted should be used with extreme caution. That's why I asked the question I did. The core question isn't about what the current implementation is or does but about where it should end up. Should Array be usable in @safe code. So far: Jakob: focused on impl Andrei: yes Monarch: focused on impl I totally agree that @trusted must be used with lots of caution. But my point in that post was that impl isn't the issue and requiring that everything be fixed and perfect also isn't the issue. If we don't know and understand where we want to be, the chances of accidentally landing there are rather low. More and more code is being created in Phobos all the time, and it's use in @safe code is largely an afterthought. Please don't derail this thread and talk about process.. keep this thread focused on Array. Thanks, Brad
Re: Worse is better?
On Monday, 13 October 2014 at 14:58:08 UTC, Ola Fosheim Grøstad wrote: Nice to have, but not critical to success IMO. Templates are absolutely critical for any new system level programming language for me to even consider it. I had my share of pain emulating those in plain C and don't want to ever do it again.
Re: Will D ever get optional named parameters?
On 10/13/2014 4:09 PM, bearophile wrote:
bachmeier:
def foo(x: int = 1000, y: double = 0.0): double {}
If you later change the names to something more informative
def foo(reps: int = 1000, variance: double = 0.0): double {}
You can use:
double foo(int deprecated(x) reps=100, deprecated(y) variance=0.0) {...}
Please, no.
Re: Windows drivers written in D
On Monday, 13 October 2014 at 21:50:20 UTC, eles wrote: Short answer is: yes, you cand write, but you cannot compile. Wait, what? Do you mean link or maybe load? I don't write Linux kernel modules, but I bet you can get it working. Check out the "betterC" switch to get away with runtime dependences. There were some post related to minimal executables recently. Piotrek
Re: Will D ever get optional named parameters?
bachmeier:
def foo(x: int = 1000, y: double = 0.0): double {}
If you later change the names to something more informative
def foo(reps: int = 1000, variance: double = 0.0): double {}
You can use:
double foo(int deprecated(x) reps=100, deprecated(y)
variance=0.0) {...}
Bye,
bearophile
Re: What are the worst parts of D?
On Tue, 14 Oct 2014 00:09:17 +0300 ketmar via Digitalmars-d wrote: let's stop hijacking this thread. here is The Official Thread for cmdcon-ng: http://forum.dlang.org/thread/mailman.772.1413240502.9932.digitalmar...@puremagic.com signature.asc Description: PGP signature
cmdcon-ng official thread
Hello. to stop hijacking ranting thread i created this one for my cmdcon-ng module. see some history here: http://forum.dlang.org/post/mailman.769.1413234569.9932.digitalmar...@puremagic.com for now cong is not ready for official announce, but you can play with it, here is git repo: http://repo.or.cz/w/cong.d.git enjoy, and happy hacking! signature.asc Description: PGP signature
Re: What are the worst parts of D?
as i see that some peopele are eager to play with cmdcon-ng, i setup a git repo with it: http://repo.or.cz/w/cong.d.git lay your hands while it hot! the code is little messy (there are some napoleonian plans which aren't made into it), but it should work. at least with unittests and sample. enjoy, and happy hacking! signature.asc Description: PGP signature
Re: UFCS in C++
On Monday, 13 October 2014 at 17:29:56 UTC, Paulo Pinto wrote: Am 13.10.2014 um 10:53 schrieb Peter Alexander: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... Just noticed that Herb Sutter also presented one, http://isocpp.org/files/papers/N4165.pdf Yes, this was a much better idea than UFCS. Having a syntax that supports IDE and tooling could justify having two syntaxes for the same thing even though it does pollute the namespace for questionable gains.
Re: Worse is better?
Am 13.10.2014 um 23:56 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Monday, 13 October 2014 at 19:00:37 UTC, Paulo Pinto wrote: But no better than Algol or PL/... variants. There were other alternatives. Algol compilers required a lot more RAM than BCPL (~120k vs ~20k) :) If you wish, I can enumerate other alternatives with compatible memory requirements. :) It was a matter of luck being tied to UNIX, just like JavaScript is tied to the browser, having a few of the key developers spread into American universities outside AT&T, and creating workstation startups that succeed in the market. Outside of the workstation market based on UNIX systems and a few universities, barely anyone was using C in Europe. If those startups that paved the way to likes of Sun, SGI among others, had failed to capture the market, C would just be another footnote in the history of programming languages. -- Paulo
Re: Worse is better?
On Monday, 13 October 2014 at 19:00:37 UTC, Paulo Pinto wrote: But no better than Algol or PL/... variants. There were other alternatives. Algol compilers required a lot more RAM than BCPL (~120k vs ~20k) :)
Re: What are the worst parts of D?
On Monday, 13 October 2014 at 21:09:29 UTC, ketmar via Digitalmars-d wrote: as i can't publish my current version of cmdcon, i decided to write another one from scratch. Cool, looks like a fun module to play with! :-)
Re: Windows drivers written in D
On Monday, 13 October 2014 at 18:16:08 UTC, marisalovesusall wrote: D is a system programming language, so is it possible to write drivers in D? Windows drivers, as example, or Linux. See those links, with the mention that thy are quite outdated. But is better than nothing: http://iainbuclaw.wordpress.com/2010/05/22/writing-a-linux-kernel-module-in-d/ http://wiki.osdev.org/D_Bare_Bones Short answer is: yes, you cand write, but you cannot compile. Until most of D's runtime/stdlib is replaced by some Linux kernel equivalent, just as the C's ones are. In the case of D, full port is far harder than of C, due to more complexity.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, 13 October 2014 at 17:15:34 UTC, John Colvin wrote: The only argument that's left is: "I don't mind you breaking my code by fixing bugs in the implementation, but I do mind when it's for cleaning/changing the language/phobos". In light of recent comments from heavyweight users saying "please break my code in the name of improving the language and libraries", I don't think it holds much water. Well, in this case we don't necessarily need to break anyone's code, it would be possible to stop at deprecation. But generally speaking, I agree with you, which is why I was hoping to move the debate to, "What are the circumstances under which these breaks are possible," rather than "Should we/shouldn't we".
Re: UFCS in C++
:-)Ali, you made my day!
Actually, there are references to D in that article. One of those is
even about considering D as an "alternative". An excerpt from page 10:
void alternative(D& d)// an alternative to consider
{
// ...
}
Re: What are the worst parts of D?
Dne 13.10.2014 v 23:09 ketmar via Digitalmars-d napsal(a): > as i can't publish my current version of cmdcon, i decided to write > another one from scratch. it contains alot less of mixin() codegens, > can do everything cmdcon.d can do and has structs/classes already > working. this is the excerpt from testing code: Nice! That's what I call a can-do attitude :) I just happen to have a nice place in code where it can get used. I'm looking forward for playing with it. Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: UFCS in C++
On 10/13/2014 01:53 AM, Peter Alexander wrote:
Looks like Bjarne has proposed UFCS for C++
http://isocpp.org/files/papers/N4174.pdf
No mention of D though...
Actually, there are references to D in that article. One of those is
even about considering D as an "alternative". An excerpt from page 10:
void alternative(D& d)// an alternative to consider
{
// ...
}
Ali
"I am NOT kidding!" :)
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 13:34:23 +0200
Martin Drašar via Digitalmars-d wrote:
> Ok, thanks for your answers. If you get your code to publishable
> state, I am sure a lot of people will be interested.
as i can't publish my current version of cmdcon, i decided to write
another one from scratch. it contains alot less of mixin() codegens,
can do everything cmdcon.d can do and has structs/classes already
working. this is the excerpt from testing code:
import cong; // our console module
@ConName("intVar00")
@ConHelp("simple int variable")
@ConDescription("this is just an int variable.\nordinary one, nothing
special.")
__gshared int v0 = 42;
__gshared string v1 = "hi!";
class A {
int i = 42;
string s = "hello";
this () {}
this (string v) { s = v; }
int bar () { writeln("BAR: s=", s); return 666; }
void foo (float[] ff) {}
}
__gshared A a; // yes, this can be null
void foo (int n, string s="hi", double d=0.666) {
writefln("n=%s; s=[%s]; d=%s", n, s, d);
}
struct S {
int i = 666;
string s = "bye";
int sbar () { writeln("SBAR: s=", s); return 666; }
void sfoo (float[] ff) {}
}
__gshared S s;
S s1;
void main (string[] args) {
writeln("known commands:");
foreach (auto n; conGetKnownNames()) writeln(" ", n);
writeln("---");
a = new A();
conExecute("a bar"); // virtual method call for object instance
a.s = "first change";
conExecute("a bar");
a = new A("second change");
conExecute("a bar"); // virtual method call for ANOTHER object
instance
foreach (auto arg; args[1..$]) {
try {
writeln("# ", arg);
conExecute(arg);
} catch (Exception e) {
writeln("***ERROR: ", e.msg);
}
}
}
mixin(ConRegisterAll); // register 'em all!
==
known commands:
intVar00
a
foo
v1
s
---
(autoregistration rocks!)
some sample commands and results:
# intVar00
intVar00 42 (Int)
# foo 42
n=42; s=[hi]; d=0.666
# a i
a.i 42 (Int)
# a bar
BAR: s=second change
# s sbar
SBAR: s=bye
by default `mixin(ConRegisterAll);` tries to register all suitable
public symbols. one can use @ConIgnore UDA to ignore symbol and some
other UDAs to change name, add help and so on. alas, there is no way to
get Ddoc info in compile-time (what a pity!).
you can't register pointer objects (i.e. `__gshared int *a` will not
pass). it's doable (class fields are such objects internally), but i
just don't need this.
i also found some bugs in compilers (both dmd and gdc), but aren't
ready to dustmite and report 'em yet. GDC just segfaults now, but DMD
works.
there is also bug in CDGC, which took me a whole day of useless code
motion (i forgot that i'm using DMD built with CDGC ;-).
so the base mechanics is in place, i need to debug some things and
write simple sample with eventloop and telnet.
new code includes only WTFPL'ed parts, so it probably will be WTFPLed
too.
hope to finish this until weekend.
signature.asc
Description: PGP signature
Re: Windows drivers written in D
On Monday, 13 October 2014 at 18:16:08 UTC, marisalovesusall wrote: D is a system programming language, so is it possible to write drivers in D? Windows drivers, as example, or Linux. In short: You can write in D everything you can in C. And there is good place called D.Learn for starters. Anyway, with all sympathy I have, please use google for it. E.g http://stackoverflow.com/questions/763/how-should-i-get-started-on-writing-device-drivers "Writing a device driver can be pretty simple, or it can be almost arbitrarily complicated. For instance, I've been involved in a project where it took six of us almost three years to solve ONE bug in a device driver. " I do writing/debugging drivers on my daily basis. Rewarding, fun, frustrating... So go for it. D has additional bonus as good looking syntax/modules etc. BTW. Don't use Windows and Linux in the same sentence ;) Drivers are platform specific if you pass register map step. Please share what you achieved. Wringing drivers is for the elite ;) Piotrek
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, October 13, 2014 19:59:13 deadalnix via Digitalmars-d wrote: > The right path forward seems to be deprecating now, but not > removing before dfix can do something good about it. I don't know that we need to wait for dfix, but we never remove deprecated stuff from the language very quickly anyway. So, I expect that it'll be around for at least a year or two before we look at actually removing it, so dfix will presumably be able to take care of it long before we're looking to remove it anyway. - Jonathan M Davis
Re: @safety of Array
Example:
ref int getAsRef(int a) @safe //Magic!
{
RefCounted!int rc = a;
return rc.getPayload();
}
I wouldn't want to be on the calling end of this "safe"
function...
Re: @safety of Array
On Monday, 13 October 2014 at 17:16:40 UTC, Brad Roberts via Digitalmars-d wrote: On 10/13/2014 7:47 AM, Andrei Alexandrescu via Digitalmars-d wrote: On 10/12/14, 5:41 PM, Brad Roberts via Digitalmars-d wrote: I know it's a tricky implementation, but let's focus on the goal.. should Array be usable in @safe code? Yes. In order for that to be 100% automatically checkable, we need the rules restricting escape of addresses of returns by reference. -- Andrei 100% checkable isn't required right now. For it to be used in an @safe context all that's needed is liberal use of @trusted. That can be refined over time to a more checked version. We shouldn't wait for checkability. Will one of you experts in the impl of Array volunteer to make the appropriate changes? The issue is that it's *not* safe though. You can escape the reference, destroy it, and end up with a dangling pointer. Arbitrarily marking things as trusted seriously undermines what safe means. @trusted should be used with extreme caution.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sunday, 12 October 2014 at 23:25:57 UTC, Martin Nowak wrote: Automatic code rewriting is what might make syntax deprecations more feasible in 6 month. Perhaps, but this change is so straightforward that I would expect that even a very large codebase could be updated in a very short space of time. The main counterargument against this change is that it's yet another change that require people to rewrite their code. Also the pull simply deprecates certain code, but for good acceptance we also need to educate D users why we're doing this change and must make updating code as painless as possible. A tool like dfix will become more important with every line of D code that is written. Too often we're only looking at phobos. I'm sorry, but that won't cut it. People have been asking for this change since like forever. This whole problem could be gone by now, and at the time there was no release that won't make you rewrite your code anyway. No it is like, "we didn't made the change at the time for bad reason, and now we don't want to make the change because we made a bad decision at the time and change is more costly now".
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, 13 October 2014 at 16:00:21 UTC, Joseph Rushton Wakeling wrote: On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote: Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way. Indeed, but the choice of _when_ to remove can in practice be quite free, no? It would be possible to put in place this deprecation warning and wait for years before acting on it. This is one thing I'd love major versions to be used for. Deprecate bunch of things iteratively, remove them completely in D 3.xx.yy ; aggregate bunch of new deprecated things and release D 4.xx.yy etc.
Re: Will D ever get optional named parameters?
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote:
From what I've found, there was some work on this in the past
(http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj:40forum.dlang.org),
but a pull request was never made/I don't seem to find
discussion about adding it as a feature anywhere.
I think optional named parameters would be a nice addition,
either to the core language, or something like the monadic
solution from that old thread in phobos.
Are there good reasons not to add something like this to the
language, or is it simply a matter of doing the work? Has it
been discussed much?
My limited Scala experience from several years ago suggests this
is not something worth doing. The names of parameters are part of
the API. Suppose you have a method like
def foo(x: int = 1000, y: double = 0.0): double {}
If you later change the names to something more informative
def foo(reps: int = 1000, variance: double = 0.0): double {}
you've potentially broken existing code. Maybe there are better
approaches than that of Scala, but doing anything like that to D
would be a huge mistake for little gain. (I write a lot of R
code, for which named parameters are the norm, so I understand
the convenience.)
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sunday, 12 October 2014 at 21:51:33 UTC, Jonathan M Davis via Digitalmars-d wrote: Perhaps, but this change is so straightforward that I would expect that even a very large codebase could be updated in a very short space of time. And since it'll be generating deprecation messages - not errors - and it's for a practice that we've already been discouraging for some time now, I don't think that waiting for dfix buys us much. I totally agree that it would be nice to have, but I don't see it as a showstopper at all. The only significant problem I see is dmd's headergen, because if that's putting const on the left, then it'll generate code that will then be warned about, which would definitely be bad. The ddoc generation should be fixed to, but that can be done later, because the semantics won't have changed; it's just that if you do it in your own code, you'll get a deprecation message. I'd very much like to see this change made sooner rather than later. I think that it continues to harm us as long as it isn't changed, and the change really doesn't cost much even if your whole codebase needs to be updated, because it's very simple and straightforward. - Jonathan M Davis The right path forward seems to be deprecating now, but not removing before dfix can do something good about it.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sunday, 12 October 2014 at 09:29:08 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 11/10/14 11:16, Walter Bright via Digitalmars-d wrote:
On 10/10/2014 4:16 PM, Joseph Rushton Wakeling via
Digitalmars-d wrote:
I agree with that general sentiment, but doesn't this patch
only deprecate
left-hand-side function attributes?
Only some of them, others remain:
pure int foo() { ... }
Not good. If LHS function attributes are to be deprecated, it
really ought to be all or nothing.
No. Let me explain. In
qualifier(type) identifier();
qualifier apply to type. This is all good, as expected.
In
attribute type identifier();
attribute apply to identifier. identifier is a function here, and
it make sense to apply pure on a function.
The problem with type qualifier on a function, is that they do
not make any sense. For some reason, a type qualifier used on a
function will qualify the implicit parameter.
It is confusing the hell out of everybody as there is a thing on
which is make sense to apply the qualifier to (the return type)
and a thing where it does not make sense (the function) but for
some reason, when you apply it on the function it has a "magic"
meaning. That is the surprise effect.
Re: Will D ever get optional named parameters?
On 2014-10-13 19:18:38 +, Walter Bright said: On 10/13/2014 7:23 AM, Ary Borenszweig wrote: On 10/13/14, 5:47 AM, Walter Bright wrote: On 10/13/2014 1:29 AM, "岩倉 澪" wrote: Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much? Named parameters interact badly with overloading. Could you give an example? Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third. Parameters need not be named in D: int foo(long); int foo(ulong x); Named parameters are often desired so that default arguments need not be in order at the end: int foo(int x = 5, int y); int foo(int y, int z); To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this? Not to mention, that despite C# supporting this, MSFT's code analysis generates a warning and instead recommends providing more overloads. -S.
Re: Will D ever get optional named parameters?
On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote: On 10/13/2014 7:23 AM, Ary Borenszweig wrote: On 10/13/14, 5:47 AM, Walter Bright wrote: On 10/13/2014 1:29 AM, "岩倉 澪" wrote: Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much? Named parameters interact badly with overloading. Could you give an example? Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third. Parameters need not be named in D: int foo(long); int foo(ulong x); Named parameters are often desired so that default arguments need not be in order at the end: int foo(int x = 5, int y); int foo(int y, int z); To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this? The only thing I like named parameters for is to avoid the following foo(5 /* count */, true /* enableSpecialFunctionality */) I like the documentation, but comments in the middle does feel cumbersome. Tooling could add that automatically of course. The C# syntax is slightly better: foo(count: 5, enableSpecialFunctionality: true) I don't care for or need the ability to reorder parameters, nor do I want additional rules to remember vis-a-vis overloading and optional parameters. And I don't want a trivial name change in parameters to break my code - functions already have complete signatures, enforcing names just adds one more thing which could break people for no real benefit. Sometimes I think features are proposed for the language which more rightly belong in tooling.
Re: Will D ever get optional named parameters?
On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote: Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third. Parameters need not be named in D: int foo(long); int foo(ulong x); Named parameters are often desired so that default arguments need not be in order at the end: int foo(int x = 5, int y); int foo(int y, int z); To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this? If you have several functions that take optional arguments, like the following: int foo(bool b = false, int n, float f = 0.0f); int foo(float n, bool b = false, float f = 0.0f); foo(2, b: true); foo(3.0f, f: 1.0f); Wouldn't it only be necessary to overload on the non-optional arguments? Extending this, if a functional has only optional arguments, then there can only be one version of it. int foo(int n = 0, bool b = false, float f = 0.0f); //Error: cannot overload two functions with no non-optional parameters. int foo(float n = 0.0f, bool b = false, float f = 0.0f);
Re: Will D ever get optional named parameters?
On 10/13/2014 7:23 AM, Ary Borenszweig wrote: On 10/13/14, 5:47 AM, Walter Bright wrote: On 10/13/2014 1:29 AM, "岩倉 澪" wrote: Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much? Named parameters interact badly with overloading. Could you give an example? Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third. Parameters need not be named in D: int foo(long); int foo(ulong x); Named parameters are often desired so that default arguments need not be in order at the end: int foo(int x = 5, int y); int foo(int y, int z); To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this?
Re: Worse is better?
Am 13.10.2014 um 20:38 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Monday, 13 October 2014 at 16:28:13 UTC, Paulo Pinto wrote: It had a killer application called UNIX, just like JavaScript has the browser or Objective-C has the iPhone I doubt it would ever suceeded on its own. I probably would, since it was better than http://en.wikipedia.org/wiki/BCPL But no better than Algol or PL/... variants. There were other alternatives.
Re: UFCS in C++
On 10/13/2014 1:53 AM, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_xfy_vs_fxy/ and: https://www.reddit.com/r/programming/comments/2j3kr4/proposal_for_unified_call_syntax_for_c_xfy_vs_fxy/cl8fil5 Anyone remember just when it appeared in D? (It's not in D1.)
Re: Worse is better?
On Monday, 13 October 2014 at 16:28:13 UTC, Paulo Pinto wrote: It had a killer application called UNIX, just like JavaScript has the browser or Objective-C has the iPhone I doubt it would ever suceeded on its own. I probably would, since it was better than http://en.wikipedia.org/wiki/BCPL
Windows drivers written in D
D is a system programming language, so is it possible to write drivers in D? Windows drivers, as example, or Linux.
Re: std.json sucessor
Am 13.10.2014 19:40, schrieb Kiith-Sa: On Monday, 13 October 2014 at 17:21:44 UTC, Sönke Ludwig wrote: Am 13.10.2014 16:36, schrieb Daniel Murphy: "Sönke Ludwig" wrote in message news:m1ge08$10ub$1...@digitalmars.com... Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing. I suppose a 4GB single-line json file is still possible. If we make that assumption, we'd have to change it from size_t to ulong, but my feeling is that this case (format error at >4GB && human tries to look at that place using an editor) should be rare enough that we can make the compromise in favor of a smaller struct size. What are you using the location structs for? In D:YAML they're only used for info about errors, so I use ushorts and ushort.max means "65535 or more". Within the package itself they are also only used for error information. But they are also generally available with each token/node/value, so people could do very different things with them.
Re: std.json sucessor
On 10/13/14, 10:21 AM, Sönke Ludwig wrote: Am 13.10.2014 16:36, schrieb Daniel Murphy: "Sönke Ludwig" wrote in message news:m1ge08$10ub$1...@digitalmars.com... Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing. I suppose a 4GB single-line json file is still possible. If we make that assumption, we'd have to change it from size_t to ulong, but my feeling is that this case (format error at >4GB && human tries to look at that place using an editor) should be rare enough that we can make the compromise in favor of a smaller struct size. Agreed. -- Andrei
Re: std.json sucessor
On Monday, 13 October 2014 at 17:21:44 UTC, Sönke Ludwig wrote: Am 13.10.2014 16:36, schrieb Daniel Murphy: "Sönke Ludwig" wrote in message news:m1ge08$10ub$1...@digitalmars.com... Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing. I suppose a 4GB single-line json file is still possible. If we make that assumption, we'd have to change it from size_t to ulong, but my feeling is that this case (format error at >4GB && human tries to look at that place using an editor) should be rare enough that we can make the compromise in favor of a smaller struct size. What are you using the location structs for? In D:YAML they're only used for info about errors, so I use ushorts and ushort.max means "65535 or more".
Re: UFCS in C++
Am 13.10.2014 um 10:53 schrieb Peter Alexander: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... Just noticed that Herb Sutter also presented one, http://isocpp.org/files/papers/N4165.pdf -- Paulo
Re: std.json sucessor
Am 13.10.2014 16:36, schrieb Daniel Murphy: "Sönke Ludwig" wrote in message news:m1ge08$10ub$1...@digitalmars.com... Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing. I suppose a 4GB single-line json file is still possible. If we make that assumption, we'd have to change it from size_t to ulong, but my feeling is that this case (format error at >4GB && human tries to look at that place using an editor) should be rare enough that we can make the compromise in favor of a smaller struct size.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sunday, 12 October 2014 at 11:24:17 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote: On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d wrote: D2 is, for the most part, excellent in this respect, but it could and should be even better. Well-managed, well-documented and well-publicized breaking changes in support of usability and correctness are desirable, not something to be avoided. I should add here -- I recognize the basic problem that faces any language when you have newcomers (or potential corporate adopters) downloading the latest compiler, downloading some codebase of interest to them, and finding that it doesn't build because of a backwards-incompatible change. Even when that change was 100% justified, you risk being seen as unstable, untrustworthy, etc., and many people are not patient enough to stick around to hear that justification. I used to think that this was a valid point w.r.t. rejecting changes. Over the last year of actually trying to get work done in D, I've changed my tune somewhat: At this stage, almost every release will break any project that has a decent sized code-base, *without considering any language changes or regressions*! Fixing *any* rejects-valid or accepts-invalid bug can break peoples code.[1] Adding a new symbol in phobos can break peoples code. The only way of getting meaningful stability is to slow down a lot. If we're going to keep moving fast (even just fixing bugs), then it is unavoidable that we will break people's code. We can afford a little more breakage on top of the inevitable (and undeniably necessary) pile - even for quite minor gains - as long as they are changes that can be easily managed by project maintainers.[2] The only argument that's left is: "I don't mind you breaking my code by fixing bugs in the implementation, but I do mind when it's for cleaning/changing the language/phobos". In light of recent comments from heavyweight users saying "please break my code in the name of improving the language and libraries", I don't think it holds much water. [1] The "code that was already broken" is often dodgy. What constitutes broken code? There's a lot of very fragile code out there that is doing it's job just fine, in the limited circumstances it's used. [2] By easily managed I don't mean sed-able, or even tooling-fixable. For me it pivots on being able to maintain one code-base that will compile with multiple compiler versions. An example where this fails: @nogc, being an attribute, isn't aliasable, meaning you can't version it out neatly. #PleaseBreakMyCode but also #PleaseProvideScalableMeansForMeToProvideBackwardsCompatabilityToMyUsersWhoBuildMyCodeOnAVarietyOfSystemsWithAVarietyOfCompilers Hmm, not so catchy :)
Re: @safety of Array
On 10/13/2014 7:47 AM, Andrei Alexandrescu via Digitalmars-d wrote: On 10/12/14, 5:41 PM, Brad Roberts via Digitalmars-d wrote: I know it's a tricky implementation, but let's focus on the goal.. should Array be usable in @safe code? Yes. In order for that to be 100% automatically checkable, we need the rules restricting escape of addresses of returns by reference. -- Andrei 100% checkable isn't required right now. For it to be used in an @safe context all that's needed is liberal use of @trusted. That can be refined over time to a more checked version. We shouldn't wait for checkability. Will one of you experts in the impl of Array volunteer to make the appropriate changes?
Re: UFCS in C++
On Monday, 13 October 2014 at 09:32:58 UTC, Francesco Cattoglio wrote: On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... Seriously, not even a mention? Ok, I'm mad. Can I be mad? If you want but from what I recall the idea for UFCS came from an article by Scott Meyers where he writes about how he wishes C++ had this feature[1]. http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 (haven't read it or the archives in awhile so I may be summarizing history incorrectly)
Re: Worse is better?
Am 13.10.2014 um 17:04 schrieb eles: On Monday, 13 October 2014 at 14:58:08 UTC, Ola Fosheim Grøstad wrote: On Monday, 13 October 2014 at 13:56:20 UTC, eles wrote: On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: Nice to have, but not critical to success IMO. Of course is not that critical, because C succeeded without, but still nice to have. It had a killer application called UNIX, just like JavaScript has the browser or Objective-C has the iPhone I doubt it would ever suceeded on its own. -- Paulo
Re: UFCS in C++
On Mon, 13 Oct 2014 16:14:36 + ponce via Digitalmars-d wrote: > UFCS could be fun in C++ with dependence on import order and the > best-match rule. c++ coders love to fight with their tools. ;-) signature.asc Description: PGP signature
Re: Will D ever get optional named parameters?
On Mon, 13 Oct 2014 16:08:07 + ponce via Digitalmars-d wrote: > Work-around I see a lot in C++: > > --- > > bool filled = true; > drawCircle(filled); > > --- > > instead of: > > --- > > drawCircle(true); > > --- it's not the same, i thing. for this we have Flag in std.typecons, for example. signature.asc Description: PGP signature
Re: UFCS in C++
On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... UFCS could be fun in C++ with dependence on import order and the best-match rule.
Re: Will D ever get optional named parameters?
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote: From what I've found, there was some work on this in the past (http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj:40forum.dlang.org), but a pull request was never made/I don't seem to find discussion about adding it as a feature anywhere. I think optional named parameters would be a nice addition, either to the core language, or something like the monadic solution from that old thread in phobos. Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much? Work-around I see a lot in C++: --- bool filled = true; drawCircle(filled); --- instead of: --- drawCircle(true); ---
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Monday, 13 October 2014 at 15:58:05 UTC, Joseph Rushton Wakeling wrote: On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote: I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos... Yes, you are right. Mea culpa, I misinterpreted. OTOH, there is some cleaning needed, I think, complex types being prime example.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote: Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way. Indeed, but the choice of _when_ to remove can in practice be quite free, no? It would be possible to put in place this deprecation warning and wait for years before acting on it.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sunday, 12 October 2014 at 19:33:40 UTC, eles wrote: I beg forgiveness, but I think it was a timid suggestion to clean up a bit Phobos... No. I actually think it's a very good thing that it's possible to preserve old, obsolete modules in Phobos. As long as everything is covered in a strict deprecation warning to let everyone understand it is obsolete, it's better to keep the code there for backwards compatibility than gratuitously remove it, because of the risks of breakage to old codebases. For the same reason, I'm happy to see LHS attributes be deprecated, but not for support for them to be removed.
Re: UFCS in C++
On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... UFCS in Pascal http://forum.lazarus.freepascal.org/index.php/topic,26025.45.html
Re: Will D ever get optional named parameters?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/10/14 09:47, Walter Bright via Digitalmars-d wrote: > On 10/13/2014 1:29 AM, "岩倉 澪" wrote: >> Are there good reasons not to add something like this to the >> language, or is it simply a matter of doing the work? Has it been >> discussed much? > > Named parameters interact badly with overloading. Groovy handles this OK. (Python handles this fine by not having even a whiff of the possibility of overloading ;-) - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQ78kYACgkQ+ooS3F10Be/mswCg20q2hDsmPBYkJpwr1c03fjVj KVkAn1pmkQGjN2OATRbuDHHWu2xN9SyE =hPA7 -END PGP SIGNATURE-
Re: DIP66 - Multiple alias this
On 10/11/2014 7:23 AM, IgorStepanov wrote:
class A
{
int i;
alias i this;
}
class B
{
int i;
alias i this;
}
class C
{
A a;
B b;
alias a this;
alias b this;
}
My preferred solution would be to reject the 2nd alias
declaration outright.
I don't see any value in intentionally creating the above
pattern, _if_ it occurs then it's most likely due to an
unintentional side-effect of a re-factoring, thus it should error
out as close as possible to the real error.
Re: Stats on D usage/download ?
On 10/13/14, 2:22 AM, chmike wrote: Where could I find stats on D usage and compiler download ? Shouldn't such information be made clearly visible on the homepage menu ? This would provide feedback on the adoption and popularity of D. Heh, incidentally I'm just putting together such stats, initially on my own website. E.g. http://erdani.com/d/downloads.daily.png plots the 28-day moving average of daily direct downloads. I'll announce things once I have everything finished. -- Andrei
Re: RFC: std.json sucessor
On 10/13/14, 4:45 AM, Sönke Ludwig wrote: Am 13.10.2014 13:33, schrieb Jacob Carlborg: On 13/10/14 09:39, Sönke Ludwig wrote: ** At four words per token, Location seems pretty bulky. How about reducing line and column to uint? Single line JSON files >64k (or line counts >64k) are no exception 64k? Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing. Yah, one uint for each. -- Andrei
Re: Consistent bugs with dmd -O -inline in a large project
On Monday, 13 October 2014 at 14:53:24 UTC, ketmar via Digitalmars-d wrote: On Mon, 13 Oct 2014 14:28:49 + OlaOst via Digitalmars-d wrote: Here too. I just managed to pare it down to 2 files: care to fill bugreport? Added to https://issues.dlang.org/show_bug.cgi?id=13244
Re: RFC: std.json sucessor
On 10/13/14, 4:48 AM, Sönke Ludwig wrote: Am 13.10.2014 13:37, schrieb Jacob Carlborg: On 22/08/14 00:35, Sönke Ludwig wrote: Following up on the recent "std.jgrandson" thread [1], I've picked up the work (a lot earlier than anticipated) and finished a first version of a loose blend of said std.jgrandson, vibe.data.json and some changes that I had planned for vibe.data.json for a while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json JSONToken.Kind and JSONParserNode.Kind could be "ubyte" to save space. But it won't save space in practice, at least on x86, due to alignment, and depending on what the compiler assumes, the access can also be slower that way. Correct. -- Andrei
Re: Worse is better?
On Monday, 13 October 2014 at 14:58:08 UTC, Ola Fosheim Grøstad wrote: On Monday, 13 October 2014 at 13:56:20 UTC, eles wrote: On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: Nice to have, but not critical to success IMO. Of course is not that critical, because C succeeded without, but still nice to have.
Re: Worse is better?
On Monday, 13 October 2014 at 13:56:20 UTC, eles wrote: On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: ... From a system level language I don't really need: - templates This is the no. 1 feature that I would like to have in a system level programming languages such as hypothetical "C with templates" In practice I use few templates in low level code. I might start out with a template, and then end up using something concrete for various reasons (performance, needed to modify the ADT as the code base evolve, memory layout, desire for transparent source code). Nice to have, but not critical to success IMO.
Re: Consistent bugs with dmd -O -inline in a large project
On Mon, 13 Oct 2014 14:28:49 + OlaOst via Digitalmars-d wrote: > Here too. I just managed to pare it down to 2 files: care to fill bugreport? signature.asc Description: PGP signature
Re: @safety of Array
On 10/12/14, 5:41 PM, Brad Roberts via Digitalmars-d wrote: I know it's a tricky implementation, but let's focus on the goal.. should Array be usable in @safe code? Yes. In order for that to be 100% automatically checkable, we need the rules restricting escape of addresses of returns by reference. -- Andrei
Re: std.json sucessor
"Sönke Ludwig" wrote in message news:m1ge08$10ub$1...@digitalmars.com... Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing. I suppose a 4GB single-line json file is still possible.
Re: Consistent bugs with dmd -O -inline in a large project
"Lumi Pakkanen" wrote in message
news:choqmgtkydoxleape...@forum.dlang.org...
I'm creating a somewhat large hobby project with D. I'm enjoying the ride
so far. Unit tests and contract programming have saved me from long bug
hunts, but today I ran into a bug that seems to be caused by the -O
and -inline flags with dmd.
Without the flags the program runs correctly, but -O produces wrong
results consistently and -inline seems to cause memory corruption.
Now my problem here is that the program has over 5000 lines of code with
interdependencies running everywhere so I'm not sure if it's possible to
come up with a neat small program that demonstrates the problem for a bug
report.
What should I do? Am I stuck with not using -O and -inline for now, hoping
that things will improve in the future?
There are a few techniques to try and track this sort of thing down.
0. Build dmd from the lastest master and see if it works (if you haven't
done this already). The bug may have been fixed.
1. As others have suggested, run dustime on your code. It's magical.
2. Do a binary search, compiling with some modules not using -inline (or
instead with -O). Then, do the same with functions within the module,
moving them to another module (or using d/di split) to prevent inlining.
When the caller function is found, disable inlining of the potential
problematic callees by adding asm { nop; } or similar to their body.
3. Spend some quality time with a debugger and a disassembler, tracing back
from the fault to find out where it all went wrong. This becomes more
difficult, but still possible if the call stack is corrupted. This could be
the fastest or the slowest method depending on your luck. Usual debugging
tools like valgrind may be a huge help.
4. Switching word size (-m32/-m64) may make the problem go away, if that's
an option for your project.
Re: Consistent bugs with dmd -O -inline in a large project
On Monday, 13 October 2014 at 13:11:13 UTC, Gary Willoughby wrote:
On Monday, 13 October 2014 at 09:18:01 UTC, Chris wrote:
I have the same problem. If I don't use -O it works fine
(-inline is ok). If I use it, I get an error when executing
the program.
I had the same about a year ago, thought i was going crazy and
refactored the program and it went away. Never did find out
what was causing it.
Here too. I just managed to pare it down to 2 files:
-- main.d --
import std.algorithm;
import failsinline;
void main()
{
auto fail = new FailsInline();
}
-- main.d --
-- failsinline.d --
import std.algorithm;
import std.array;
void failsinline()
{
auto transform = (int i) => i;
[0].map!transform.array;
}
-- failsinline.d --
'rdmd main.d' works fine.
'rdmd -inline main.d' gives object.Error@(0): Access Violation.
Removing the std.algorithm import from main.d makes it work fine.
Same issue in dmd 2.066, 2.066-rc2 and 2.067-b1.
Re: Will D ever get optional named parameters?
On 10/13/14, 5:47 AM, Walter Bright wrote: On 10/13/2014 1:29 AM, "岩倉 澪" wrote: Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much? Named parameters interact badly with overloading. Could you give an example?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On 09/10/14 17:32, francesco cattoglio wrote: On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote: Kenji just proposed a slightly controversial pull request so I want to reach out for more people to discuss it's tradeoffs. It's about deprecating function qualifiers on the left hand side of a function. I'm all for it Then at some future point we could apply the left hand side qualifiers to the return type, e.g. `const int foo();` == `const(int) foo();` I know it's not happening anytime soon, but I'm against this second idea. This will be an extra annoyance when "porting" old D code to a new version. Just removing the currently ambiguous attribute on the left should be plenty. No need to try to mimic C in this regard. +1
Re: Worse is better?
On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: ... From a system level language I don't really need: - templates This is the no. 1 feature that I would like to have in a system level programming languages such as hypothetical "C with templates" Add D's scope() statement. - exceptions Even those, sometimes you would like to have them. - fibers - garbage collection I have not so much against GC, but not having RAII is a real issue for me and I blame GC for that.
Re: Worse is better?
On Monday, 13 October 2014 at 13:12:48 UTC, Alex Ogheri wrote: On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: ... From a system level language I don't really need: - templates - exceptions - fibers - garbage collection Ada, Modula-3 ? :) Did not Modula 3 had generics, so... templates but MUCH BETTER ? exceptions ? and garbage collection too ? in Modula 3 I see only just fibers missing of the mentioned Features... Well, it had real OS threads. I was being ironic, as for as much as I like D, at least those languages were already used to implement real OS. The fact that they did not made the jump to mainstream, is another matter. -- Paulo
Re: Refined types [almost OT]
On Monday, 13 October 2014 at 08:20:15 UTC, thedeemon wrote: Ridiculous, I'm positive that D fully supports refined types in the language. Please check your facts. Meta, go home, you're drunk. That was a joke.
Re: Worse is better?
On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: ... From a system level language I don't really need: - templates - exceptions - fibers - garbage collection Ada, Modula-3 ? :) Did not Modula 3 had generics, so... templates but MUCH BETTER ? exceptions ? and garbage collection too ? in Modula 3 I see only just fibers missing of the mentioned Features...
Re: Consistent bugs with dmd -O -inline in a large project
On Monday, 13 October 2014 at 09:18:01 UTC, Chris wrote: I have the same problem. If I don't use -O it works fine (-inline is ok). If I use it, I get an error when executing the program. I had the same about a year ago, thought i was going crazy and refactored the program and it went away. Never did find out what was causing it.
Re: Worse is better?
On Mon, 13 Oct 2014 12:40:18 + via Digitalmars-d wrote: > On Monday, 13 October 2014 at 10:51:54 UTC, ketmar via > Digitalmars-d wrote: > > AST macros! AST macros can do almost anything! ;-) > > Including making it impossible to add new features to the > language... :) with AST macros everyone can add new feature to the language! almost all ERs can be closed with "write AST macro!" ;-) signature.asc Description: PGP signature
Re: Worse is better?
On Monday, 13 October 2014 at 11:39:26 UTC, Paulo Pinto wrote: On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: ... From a system level language I don't really need: - templates - exceptions - fibers - garbage collection Ada, Modula-3 ? :) Ada would actually be a nice starting point. :)
Re: Stats on D usage/download ?
On Monday, 13 October 2014 at 12:28:58 UTC, NimrodTheShlomo wrote: On Monday, 13 October 2014 at 09:22:35 UTC, chmike wrote: Where could I find stats on D usage and compiler download ? Shouldn't such information be made clearly visible on the homepage menu ? This would provide feedback on the adoption and popularity of D. Hi. A.A has posted something about that a few weeks ago: http://forum.dlang.org/thread/lu6mhc$t2k$1...@digitalmars.com forgot to say: everybody who has or used to have the dl stats of their softs knows that one dl does not mean "usage".It's even worth in the commercial world (demo, sharewares), e.g: for 100 dl you'll get 1 licence bought. People downloads some things and doesn't give a fuckin damn about...So the previous link is not reliable. Maybe take 10% for real usage as it's free and mostly open source.
Re: Worse is better?
On Monday, 13 October 2014 at 10:51:54 UTC, ketmar via Digitalmars-d wrote: AST macros! AST macros can do almost anything! ;-) Including making it impossible to add new features to the language... :)
Re: Stats on D usage/download ?
On Monday, 13 October 2014 at 09:22:35 UTC, chmike wrote: Where could I find stats on D usage and compiler download ? Shouldn't such information be made clearly visible on the homepage menu ? This would provide feedback on the adoption and popularity of D. Hi. A.A has posted something about that a few weeks ago: http://forum.dlang.org/thread/lu6mhc$t2k$1...@digitalmars.com
Re: RFC: std.json sucessor
Am 13.10.2014 13:37, schrieb Jacob Carlborg: On 22/08/14 00:35, Sönke Ludwig wrote: Following up on the recent "std.jgrandson" thread [1], I've picked up the work (a lot earlier than anticipated) and finished a first version of a loose blend of said std.jgrandson, vibe.data.json and some changes that I had planned for vibe.data.json for a while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json JSONToken.Kind and JSONParserNode.Kind could be "ubyte" to save space. But it won't save space in practice, at least on x86, due to alignment, and depending on what the compiler assumes, the access can also be slower that way.
Re: RFC: std.json sucessor
Am 13.10.2014 13:33, schrieb Jacob Carlborg: On 13/10/14 09:39, Sönke Ludwig wrote: ** At four words per token, Location seems pretty bulky. How about reducing line and column to uint? Single line JSON files >64k (or line counts >64k) are no exception 64k? Oh, I've read "both line and column into a single uint", because of "four words per token" - considering that "word == 16bit", but Andrei obviously meant "word == (void*).sizeof". If simply using uint instead of size_t is meant, then that's of course a different thing.
Re: Will D ever get optional named parameters?
On 13/10/14 10:47, Walter Bright wrote: Named parameters interact badly with overloading. Nothing says that named parameters means that you can pass the arguments in any order. The linked forum post points to an implementation that requires the arguments to be passed in the regular order. -- /Jacob Carlborg
Re: DIP66 - Multiple alias this
On Monday, 13 October 2014 at 00:54:13 UTC, Steven Schveighoffer
wrote:
On 10/12/14 7:16 PM, IgorStepanov wrote:
On Sunday, 12 October 2014 at 23:02:13 UTC, Steven
Schveighoffer wrote:
On 10/10/14 6:10 PM, IgorStepanov wrote:
You can write foo(c.shadow); This isn't hard.
Ok, I understood you, let's listen to what others say
Right, you can get around it.
But the issue here is, that I feel like is(T: U) means (from
dlang.org):
is ( Type : TypeSpecialization )
The condition is satisfied if Type is semantically correct
and it is
the same as or can be implicitly converted to
TypeSpecialization.
This means is(C : int) should indicate that C can implicitly
convert
to int. But in your DIP, it does not. I think this is
incorrect.
Hmm. I've written case (my previous post), when returning
false from
is(T: S), where T has many pathes to S is dangerous.
OK, I didn't understand your case before, but I just got it.
I understand what you mean, but this isn't anything new -- one
can cause weird problems by creating diamond-pattern interfaces
also. I do not actually think it is dangerous, because one
would not leave an error call in their code. So for a future
change to a library to "mystically" make a function start
working is not a danger, because said code wasn't sitting there
broken in the first place.
I will note, that for diamond problem interfaces, the compiler
seems to take a different track than your DIP:
interface A {}
interface B : A {}
interface C : A {}
class X : B, C {}
static assert(is(X : A));
void main()
{
A a = new C; // works, not sure if it's B.A or C.A
}
I know this is a different problem -- we aren't pointing at two
different concrete implementations.
-Steve
This is fundamentally different situation: interfaces haven't a
state, thus don't care what interface will be getted: B.C or C.C.
Moreover, we can think that we have only one base C (like virtual
inherited class in C++).
Alias this case requires a completely different approach.
Re: Worse is better?
On Monday, 13 October 2014 at 11:07:39 UTC, Ola Fosheim Grøstad wrote: ... From a system level language I don't really need: - templates - exceptions - fibers - garbage collection Ada, Modula-3 ? :)
Re: RFC: std.json sucessor
On 22/08/14 00:35, Sönke Ludwig wrote: Following up on the recent "std.jgrandson" thread [1], I've picked up the work (a lot earlier than anticipated) and finished a first version of a loose blend of said std.jgrandson, vibe.data.json and some changes that I had planned for vibe.data.json for a while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json JSONToken.Kind and JSONParserNode.Kind could be "ubyte" to save space. -- /Jacob Carlborg
Re: RFC: std.json sucessor
On 13/10/14 09:39, Sönke Ludwig wrote: ** At four words per token, Location seems pretty bulky. How about reducing line and column to uint? Single line JSON files >64k (or line counts >64k) are no exception 64k? -- /Jacob Carlborg
Re: UFCS in C++
On Mon, 13 Oct 2014 11:04:05 + Paulo Pinto via Digitalmars-d wrote: > I am starting to be afraid what C++17 or C++20 might look like. a monster praying "kl me..." ;-) signature.asc Description: PGP signature
Re: Worse is better?
On Friday, 10 October 2014 at 21:54:32 UTC, Peter Alexander wrote: On Friday, 10 October 2014 at 21:11:20 UTC, Ola Fosheim Grostad wrote: On Friday, 10 October 2014 at 09:00:17 UTC, Peter Alexander wrote: You can't have simple, expressive, and low level control. Why not? It's just something I believe from experience. Ok, beliefs are good, but one should not limit visions by them. The gist of my reasoning is that to get low level control you need to specify things. When those things are local and isolated, all is good, but often the things you specify bleed across interfaces and affect either all the implementations (making things more complex) or all the users (making things less expressive). I don't think there is anything that prevents a language from: 1. Allow the user to specify the constraints and let the system fill in the details. 2. Let the user guide the search down to the low level details for efficiency. So, from a theoretical point of view I'd say it should be possible to go from high to low level with a reasonable simple language at the cost of an advanced compiler. If you can specify how a program should work and let a human being construct a program from it that works from the specification alone, then a "competent" compiler/expert system should be able to do the same thing. For example, consider the current memory allocation/management debate. I cannot think of a possible way to handle this that simultaneously: (a) gives users full control over how every function allocates/manages memory (control). (b) makes the implementation of those functions easy (simple). (c) makes it easy to compose functions with different management policies (expressive). I think the compiler should handle memory management and let the user configure the compiler. It is rather obvious that the compiler sometimes should to instantiate two different versions of the same function based on usage on the call site, so if you don't let the compiler handle this then achieving the optimization potential becomes difficult. Another point: compiling code to run on allocated activation records is not the same as having it compile for a call-stack. If you want lots of fibers you have to give up the concept of a stack and stick to activation records. It is also a more generic concept (Simula used it to represent both objects and memory function blocks, they had the same internal representation). Maybe there's a way to do it, but if there is I imagine that language and programming experience is going to be vastly different from what we have now (in any language). Probably. So if you are going to support low level programming then it is better to focus on the low level and be a bit more reluctant to add high level features. From a system level language I don't really need: - templates - exceptions - fibers - garbage collection I'd rather have basic building blocks and some kind of well designed deductive capability. Type systems are deductive in nature, so I think deductive compile time evaluation makes sense.
Re: UFCS in C++
On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... After going through most of the CppCon videos during the weekend, I am starting to be afraid what C++17 or C++20 might look like. Even Ada 2012 seems to be simpler to deal with. -- Paulo
Re: Will D ever get optional named parameters?
On Mon, 13 Oct 2014 08:29:40 + "岩倉 澪" via Digitalmars-d wrote: > I think optional named parameters would be a nice addition, > either to the core language, or something like the monadic > solution from that old thread in phobos. if we'll add proper AA literals, they can be used instead. methinks. signature.asc Description: PGP signature
