Tuple/Typedef question
Is there a way to get Tuple (and Typedef) from the std.typecons module to generate a new type that is unique on every instantiation? What I mean is: alias T1 = Tuple!(int, int); alias T2 = Tuple!(int, int); writeln(__traits(isSame, T1, T2)); // prints true When using Typedef, the types are still the same: alias T1New = Typedef!(T1); alias T2New = Typedef!(T2); writeln(__traits(isSame, T1New, T2New)); // still prints true The documentation of Typedef says: Typedef allows the creation of a unique type which is based on an existing type. Unlike the alias feature, Typedef ensures the two types are not considered as equals. Shouldn't the second part at least print false then?
Re: Is anyone working on a D source code formatting tool?
Can this problem be solve on Text Editor level? I use Sublime, and I need some tool for code formating. Maybe there is any ready to use addons for D?
Re: Is anyone working on a D source code formatting tool?
On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote: On 1/10/2015 12:17 PM, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? Next question - standalone tool, or built in to dmd (like Ddoc)? BTW, I think dfmt would be a significant win for D: 1. people expect this sort of thing these days 2. it tends to end bikeshedding arguments about the right way to format things 3. it'll help standardize the format of D code in the D repositories 4. it's simply nice and convenient! 5. it's a great first step when you're faced with fixing someone else's crap code I don't think it'll be hard to do as a builtin feature of dmd. My only concern about it is if dfmt is changed, then we get faced with a blizzard of changes in the D github repositories. Since Brian Schott already wrote a dfix, it seems easier to make dfmt the same program.
Re: Is anyone working on a D source code formatting tool?
On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote: On 1/10/2015 12:17 PM, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? Next question - standalone tool, or built in to dmd (like Ddoc)? Please don't make the compiler-executable modify source code. It makes makefile editing more dangerous. A standalone tool is appropriate.
Re: Is anyone working on a D source code formatting tool?
On 2015-01-10 23:11, Walter Bright wrote: Next question - standalone tool, or built in to dmd (like Ddoc)? Ideally the dmd front end should be available as a library then dfmt should be a separate tool that uses the same front end library as dmd. But I know that we're not there yet. It's always nice if a tool is built as a library with a with executable on top. This allows for other tools to be built using this library. -- /Jacob Carlborg
Re: Is anyone working on a D source code formatting tool?
On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote: On 1/10/2015 12:17 PM, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? Next question - standalone tool, or built in to dmd (like Ddoc)? BTW, I think dfmt would be a significant win for D: 1. people expect this sort of thing these days 2. it tends to end bikeshedding arguments about the right way to format things 3. it'll help standardize the format of D code in the D repositories 4. it's simply nice and convenient! 5. it's a great first step when you're faced with fixing someone else's crap code I don't think it'll be hard to do as a builtin feature of dmd. My only concern about it is if dfmt is changed, then we get faced with a blizzard of changes in the D github repositories. I guess dfmt is to small for GSOC but could we bundle it with some other important tool to create a bigger task? Best regards, NVolcz
Re: Is anyone working on a D source code formatting tool?
On 1/11/2015 2:00 AM, NVolcz wrote: I guess dfmt is to small for GSOC I'm not so sure. If the code has no comments, it's trivial. Handling comments, though, can be a bit of a challenge.
Re: Why exceptions for error handling is so important
On 1/11/2015 2:48 AM, Walter Bright wrote: To migrate the system to the new disk, the idea was to use Windows Backup/Restore of the image. Unfortunately, Windows Backup would get a ways through the process, then fail with no message beyond an error code. Googling the error code produced a vast number of results, and various schemes for fixing it, some official, some not. None of them were applicable. Many involved loading new drivers, editting the system registry, and all sort of unappealing solutions. BTW, the error code I got from Windows Backup is 0x80070002. Backup's suggestion for what to do next was to run it again (!). Geez.
Re: Is it possible to collect object usage information during compilation?
On 2015-01-11 02:08, DaveG wrote: In the past I have used FreeTDS, through PHP, and it had a lot of problems. This was several years ago and could have been at least partially due to the PHP layer. Last year I messed around with the ODBC wrapper and got amazingly poor performance, I believe the project was abandoned before I figured out the problem. Anybody actually using this in D? I'll have to write some tests and fire up the SQL profiler. We used Ruby on Rails with an SQL Server at my previous work. We used TinyTDS which uses FreeTDS. It worked surprisingly well but it did had some problems. One of those problems were encoding problems, but that mostly because we used an older version of SQL Server. -- /Jacob Carlborg
Re: Is it possible to collect object usage information during compilation?
On 2015-01-10 21:53, DaveG wrote: One final note. You may have noticed I didn't mention the schema syncing problem (keeping database and code in sync). There was a time I would have said that was essential and while it would be nice in a perfect world, I'm comfortable keeping them in sync manually (or semi-manual with scripts). I can generate a bunch of classes from an existing database fairly easily and when I change a table I can manually update a class. If I was writing SQL directly I would have to update my query, this is really no different. Doing validation in unit tests is perfectly acceptable to me. With D you can inspect all fields on a class/struct. Then you can create a migration tool that inspects your models and make sure the database match. -- /Jacob Carlborg
Re: Is it possible to collect object usage information during compilation?
On Saturday, 10 January 2015 at 20:53:47 UTC, DaveG wrote: On Saturday, 10 January 2015 at 18:31:18 UTC, Paolo Invernizzi wrote: I would like to see, someday, something in D that: - can check at compile time the syntax of SQL; - can check at compile time the SQL query statement against the current DB schema; - can read the output of a DB schema dump at CT, and parse it into what is needed for the previous points (more complicated); One final note. You may have noticed I didn't mention the schema syncing problem (keeping database and code in sync). There was a time I would have said that was essential and while it would be nice in a perfect world, I'm comfortable keeping them in sync manually (or semi-manual with scripts). I can generate a bunch of classes from an existing database fairly easily and when I change a table I can manually update a class. If I was writing SQL directly I would have to update my query, this is really no different. Doing validation in unit tests is perfectly acceptable to me. I think basically we have the same feeling over the ORM topic. Doing validation in unit tests is for sure acceptable, but my point is that I would like CT validation of plain SQL query over the current DB schema without having to use an ORM. ;-) --- Paolo
Why exceptions for error handling is so important
Over the last few days, I have been getting weird errors from various programs I run on Windows 7. Programs would just fail, or produce corrupt output (I'm looking at you, Windows Moviemaker). I have a 128Gb SSD drive for my system drive, for speed, and a 4T secondary spinning drive for storage. I knew I was getting nearly out of space on the SSD drive, and had a 256Gb SSD drive ready to swap in. To migrate the system to the new disk, the idea was to use Windows Backup/Restore of the image. Unfortunately, Windows Backup would get a ways through the process, then fail with no message beyond an error code. Googling the error code produced a vast number of results, and various schemes for fixing it, some official, some not. None of them were applicable. Many involved loading new drivers, editting the system registry, and all sort of unappealing solutions. Then I thought, hmm, maybe it's running out of space for temporary files. I deleted a few gigs, tried again, and it worked fine! I transferred to the new disk, had lots of free gigs, and suddenly the various programs that were experiencing mysterious failures all started working properly. What I'm pretty sure is happening is those programs use error codes for error reporting, and then don't check the error codes. This is common practice for C code. I'm a little surprised that with Windows' long history, it still has problems detecting when it runs out of disk space. However, if exceptions are thrown for errors instead, the programmer has to deliberately add code if he wishes to ignore the error.
Re: ddox question
On Saturday, 10 January 2015 at 17:23:24 UTC, Andrei Alexandrescu wrote: In the ddox-generated documentation the heading is e.g. Module std.container. I wanted to style std.container in code font, but can't find where that text is generated. I've searched dlang.org/ and dub/, no avail. Andrei IIUC, you're looking for this: https://github.com/rejectedsoftware/ddox/blob/ce797a3182c1263feb4a6f4c9ce9b88b95d83003/views/layout.dt Which is the base of all layout. But from a quick look (https://github.com/rejectedsoftware/ddox/search?utf8=%E2%9C%93q=h1), the title is the only h1 on the page, so you could just tweak the CSS.
Re: Tuple/Typedef question
On Sun, 11 Jan 2015 11:41:08 + Martin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Is there a way to get Tuple (and Typedef) from the std.typecons module to generate a new type that is unique on every instantiation? What I mean is: alias T1 = Tuple!(int, int); alias T2 = Tuple!(int, int); writeln(__traits(isSame, T1, T2)); // prints true When using Typedef, the types are still the same: alias T1New = Typedef!(T1); alias T2New = Typedef!(T2); writeln(__traits(isSame, T1New, T2New)); // still prints true The documentation of Typedef says: Typedef allows the creation of a unique type which is based on an existing type. Unlike the alias feature, Typedef ensures the two types are not considered as equals. Shouldn't the second part at least print false then? as for `Typedef!` -- you can use it's third arg, cookie: import std.typecons; alias T1 = Tuple!(int, int); alias T2 = Tuple!(int, int); alias T1New = Typedef!(T1, T1.init, t0); alias T2New = Typedef!(T2, T2.init, t1); pragma(msg, __traits(isSame, T1New, T2New)); // false there was a heated discussion about `std.typecons.Typedef`, built-in `typedef` and other related things, but the decision was to keep the status quo. signature.asc Description: PGP signature
Re: D idioms list
On Sat, 2015-01-10 at 14:13 -0800, Walter Bright via Digitalmars-d-announce wrote: On 1/10/2015 1:28 PM, weaselcat wrote: Sorry for the off-topic noise, but where will you be publishing your articles since Dr.Dobbs has closed? Sorry if you have answered this elsewhere. It's a good question. Dr. Dobb's has graciously given me permission to republish them, and I'll post them on http://digitalmars.com/articles. As you can see, I've already done a few of them. Lots more to go. Feel free to send stuff to ACCU's CVu or Overload. http://accu.org/index.php/journal -- 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
Re: @api: One attribute to rule them All
On Friday, 9 January 2015 at 16:14:01 UTC, Zach the Mystic wrote: To sum up: All .di function signatures will now be generated with both explicit and inferred attributes. The keyword 'export' will be overloaded with a new meaning, toggled on and off by a compiler flag which generates .di files based on that meaning. Correct? It is not truly overloading with new meaning. One can argue that existing meaning of export can already be interpreted that way, it is simply not implemented in full power. See DIP45 for some more stuff on topic. As for the rest - I'd better try answering those questions if I ever sit down and actually write it carefully, right now it is more like bunch of vague ideas rolling around with no solid structure.
Re: @api: One attribute to rule them All
On Saturday, 10 January 2015 at 10:47:04 UTC, Marc Schütz wrote: On Friday, 9 January 2015 at 16:14:01 UTC, Zach the Mystic wrote: If solving the problem at the level of the command line with the help of the existing 'export' attribute is more flexible and robust, then I'm all for it. The first thing to find out is if anyone will have a problem overloading the meaning of 'export' for this purpose. I can't think of a reason they would, unless people are currently using 'export' in some niche way which would be ruined by the new flag. This DIP is of relevance: http://wiki.dlang.org/DIP45 Yes, it was partly what started me thinking in this direction, DIP45 is very wise.
Re: Discussion on groupBy
On Saturday, 10 January 2015 at 20:19:14 UTC, Andrei Alexandrescu wrote: groupBy is an important primitive for relational algebra queries on data. Soon to follow are operators such as aggregate() which is a sort of reduce() but operating on ranges of ranges. GroupBy is a very important range. It's one the first one ranges I wrote when starting to write D code (being unsatisfied with the existing group offering). I agree with separating out the non-equivalence relation groupBy. Having both under the same name just confuses matters and makes for complex implementations.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote: The problem with Rust and Go is that they only deliver in theory, while D kicks some asses in practice. How? Eg: at this very moment, D is more stable than Rust, ground truth. I think Rust will hit non-breaking stability (or close to it) because they need it for Servo. What I dislike is that they plan on having a train-schedule where they release every 6 weeks because that model works for browsers. IMO it does not work for browsers. Last week I fixed two browser related bugs, introduced recently by both IE and Chrome. What I want from a programming tool is a stable release that lasts for years, not weeks. Python is at 3.5, yet most people are using Python 2.7, for a reason... In some sense, I think Rust is in a self-indulgent bubble... On the other hand, Rust has somewhat better semantics than D and a working memory model, for those features that Rust do have. Yet, the syntax is... too alien for most C++ programmers IMO. Maybe we should do a comparison thread between D and Rust. It might be interesting, and perhaps encourage some improvements to D. Go is actively behind the times by preventing shared libraries and discouraging exceptions, let alone generics. None of the C++ programmers I know give Go any credit, cause it would make their work more difficult, and it's already pretty difficult. Isn't static linking good enough for servers? When using Go with app engine the code is compiled by Google, seems to be a good model if the language is transparently portable. Go is not a system programming language. next month. But for some reason everything they say has a ring of truth, because it's Mozilla they only do Good Things right? No, but you gotta admit that it is an advantage that Mozilla needs the tool for doing real work. So if they make mistakes, they will suffer from it too. If D was funded for doing real work, then the memory model issues would have been addressed a long time ago. They will come to the same model as D, minimizing code breakage but do it anyway, because it's way more practical. Maybe, but Go has actually done a good job out of it. C was also quite minimal (like Rust), so they might do ok with stability if they make it a principle. And as soon as Servo is interrupted because of internal politics at Mozilla or rebudgeting (ie. very high probability), Rust will be halted in a heartbeat since loosing its purpose. Ever noticed the Rust original designer jumped off ship long ago? I didn't know that, but I've noticed with some unease that Chrome is growing towards monopoly (except in Germany where Firefox is big). That won't happen with D, whatever the ratio of github projects in the fashion industry. Yes, but D depends too much on a single person. Rust and Go does not.
Re: Is anyone working on a D source code formatting tool?
Jacob Carlborg wrote in message news:m8thr2$pag$1...@digitalmars.com... Ideally the dmd front end should be available as a library then dfmt should be a separate tool that uses the same front end library as dmd. But I know that we're not there yet. Well, some of it is. If somebody wants to work on adding the necessary lexer/parser/etc features on the C++ side I'm happy to help get ddmd ready to be used for this. It's always nice if a tool is built as a library with a with executable on top. This allows for other tools to be built using this library. Agreed.
Re: Tuple/Typedef question
I use this Typedef implementation instead:
/// one with non-default initializer
template Typedef(T, istring name, T initval)
{
static assert (name.length, Can't create Typedef with an
empty identifier);
enum Typedef =
(struct ~ name ~
{ ~
T.stringof ~ value = ~ initval.stringof ~ ;
~
alias value this; ~
});
}
/// basic overload
template Typedef(T, istring name)
{
static assert (name.length, Can't create Typedef with an
empty identifier);
enum Typedef =
(struct ~ name ~
{ ~
T.stringof ~ value; ~
alias value this; ~
});
}
unittest
{
mixin(Typedef!(int, MyInt1));
mixin(Typedef!(int, MyInt2));
static assert (!is(MyInt1 : MyInt2));
}
Re: Is anyone working on a D source code formatting tool?
On Sun, 2015-01-11 at 11:04 +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-01-10 23:11, Walter Bright wrote: Next question - standalone tool, or built in to dmd (like Ddoc)? Ideally the dmd front end should be available as a library then dfmt should be a separate tool that uses the same front end library as dmd. But I know that we're not there yet. And written in D :-) It's always nice if a tool is built as a library with a with executable on top. This allows for other tools to be built using this library. dmd, ldc, gdc, dfmt, ddoc, lots of programs one parsing library required. -- 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
Re: Is anyone working on a D source code formatting tool?
On Sat, 2015-01-10 at 14:11 -0800, Walter Bright via Digitalmars-d wrote: On 1/10/2015 12:17 PM, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? Next question - standalone tool, or built in to dmd (like Ddoc)? Why in the compiler, source code formatting is not a compilation issue. Of course the issue is parsing to AST, which the compiler has, but doesn't provide as a library. In Go, the parsing code is separated from the compiler so that different tools can be constructed using different combinations of the same code. Also why in DMD and not in LDC or GDC? BTW, I think dfmt would be a significant win for D: 1. people expect this sort of thing these days Thanks to Python PEP-8 and Go, yes. Personalized code formatting is increasingly a thing of the past, programming languages are now opinionated and fascist when it comes to formatting. Even if the rules are wrong. 2. it tends to end bikeshedding arguments about the right way to format things Except when the tool implements the wrong style. 3. it'll help standardize the format of D code in the D repositories Even if it is the wrong formatting standard? I have to admit that the Phobos format rules make the code look appallingly ugly to me, sufficiently so that I really do not want to work on that codebase. I guess I am biased towards KR C (which I use to drive my C++ style), Java and Go. 4. it's simply nice and convenient! Working with Go in Emacs or LiteIDE is a bit of a joy as you get full reformatting on save. Fortunately I only have two main gripes with the Go formatting style, but no-one has a choice, use the Go style as dictated by the Go team at Google or do not use Go. 5. it's a great first step when you're faced with fixing someone else's crap code Having just taken on a C/C++ codebase, I can agree that manually reformatting is a great way of getting in to the code. Then an automated formatting would contribute as well. I don't think it'll be hard to do as a builtin feature of dmd. It should be a separate tool not a part of one of the three compilers. My only concern about it is if dfmt is changed, then we get faced with a blizzard of changes in the D github repositories. Tough ;-) -- 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
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 06:56:02 UTC, thedeemon wrote: At this moment I only see some popularity comparisons Yes in fact they are talking more about popularity between both languages. and I think they're generally correct... Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon Matheus.
Re: Why exceptions for error handling is so important
What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
Re: Game development
On Sunday, 11 January 2015 at 02:32:00 UTC, ketmar via Digitalmars-d wrote: On Sun, 11 Jan 2015 01:45:25 + dajones via Digitalmars-d digitalmars-d@puremagic.com wrote: *almost* :-) ah, so that was trolling? You keep taking the bait. sure. just be sure to keep it fun enough for me, so i don't get bored. You think it's fun to lose what little credibility you had. i'm so sorry... i was thinking that you're just a lonely old man and have noone to talk with. When you have self professed fantasies about collecting dirty old men you will probably start imagining them everywhere you go. no need to imagine something that i clearly see with my eyes. yet my imagination adding some... juice to the scene. Ok you win, you're more perverted and sick than I am. Congrats. or i just can't realise that shitting their own pants is what they call trolling this times... o tempora, o mores... shitting their own pants Your wit knows no bounds. that's 'cause i'm endlessly smart. I agree, a true genius.
Re: Could D compete in a competition like this?
On Sunday, 11 January 2015 at 13:01:36 UTC, Gary Willoughby wrote: Could D compete in a competition like this? In a nutshell: We give you a bunch of ranked 2D points, then ask you to find the most important ones inside some randomly generated rectangles. Easy, right? Now make it fast, and you could get $5K! http://churchillnavigation.com/challenge/ Can D produce Windows DLL's? Yes. You can do it with DUB, just provide a .def file in your sourceFiles and use targetType: dynamicLibrary. Example: https://github.com/p0nce/dplug/blob/master/examples/distort/dub.json
Re: Why exceptions for error handling is so important
On Sun, 11 Jan 2015 13:06:26 + Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. from my POV it trashes logic with error checking. hey, i don't care if *each* `fwrite()` is successfull, i only care if all of them are ok or at least one (any one) failed! by the way: how many peope put checks for `close()`/`fclose()` return value? it returns no actual data, so why bother... i believe that exceptions are better for error checking: it's hard to ignore errors, error handling logic is clearly separated and so on. signature.asc Description: PGP signature
Re: Why exceptions for error handling is so important
On 1/11/15, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Or a @noignore attribute. Just having that alone could easily catch the mistake of ignoring a return value. I'm really rooting for this, but is anyone else on board? Or perhaps to avoid keyword/attribute bloat, a -noignore switch.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote: Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon more dead is a very subjective term. It is more dead in the sense that you got @nogc and there was a sense of movement towards getting to a workable memory model, but since then nothing has happend. One step forward, then stagnation. The Rust team have announced that they are moving towards a non-breaking stability situation within 6 weeks. And they have a working memory model. Andrei and Walter need to stop focusing on details for a moment and focus more on presenting a great plan within 2 months. Meaning stating goals and plans which gives D a direction that developers want and can believe in. If no clear statements on where D is heading appears in the near future... Well, then I am pretty sure that many of those who prefer D will give Rust a spin when Rust hits 1.0, out of boredom. Rust is not complete feature wise, but a working memory model and stability is more important than having single inheritance and other convenience features... So D is not dead, but is currently in a position where it can be hit by both Go and Rust. The space between Rust (system programming) and Go (server programming) is very tiny.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote: On Sunday, 11 January 2015 at 06:56:02 UTC, thedeemon wrote: At this moment I only see some popularity comparisons Yes in fact they are talking more about popularity between both languages. and I think they're generally correct... Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon Matheus. That guy has been trolling every D thread in the last year. Either way, D is definitely way more popular/active than it was a year ago, especially with a large jump around last summer, but not nearly as much as Go nor Rust at the moment. (D Rust Go at the moment as far as popularity is concerned).
Re: D port of the Dynamic Window Manager (DWM)
On Monday, 5 January 2015 at 06:17:03 UTC, stewart h wrote: Hi, I've ported DWM to D as a learning exercise and thought I'd share it. The repository can be found here: https://bitbucket.org/growlercab/ddwm (Beware, I've only tested it on Arch-Linux 64 bit for about 1 day!) DWM is a minimalist dynamic window manager from suckless. More details on DWM can be found here http://dwm.suckless.org/ The cport branch is where I've done as little as possible to port the C code to D. It really looks like C code and is basically the DWM code compiling with DMD. Under the Downloads section is a build of ddwm-cport to try out if anyone is interested, or build from source as it's pretty easy with dub. The master branch is where I'm learning D, trying new Phobos functions and D style coding. I'm then comparing how the D-style version performs with DDWM.cport and the original DWM in terms of speed and memory. I don't expect the master branch to be stable but cport should work fine. Cheers, Stew Would you be interested in going full fork mode and adding new features to D version? I am big fan of tiling window managers and having one that is written in D and I can easily extend sounds tempting :3
Re: Tuple/Typedef question
On Sunday, 11 January 2015 at 11:52:42 UTC, ketmar via Digitalmars-d-learn wrote: On Sun, 11 Jan 2015 11:41:08 + Martin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Is there a way to get Tuple (and Typedef) from the std.typecons module to generate a new type that is unique on every instantiation? What I mean is: alias T1 = Tuple!(int, int); alias T2 = Tuple!(int, int); writeln(__traits(isSame, T1, T2)); // prints true When using Typedef, the types are still the same: alias T1New = Typedef!(T1); alias T2New = Typedef!(T2); writeln(__traits(isSame, T1New, T2New)); // still prints true The documentation of Typedef says: Typedef allows the creation of a unique type which is based on an existing type. Unlike the alias feature, Typedef ensures the two types are not considered as equals. Shouldn't the second part at least print false then? as for `Typedef!` -- you can use it's third arg, cookie: import std.typecons; alias T1 = Tuple!(int, int); alias T2 = Tuple!(int, int); alias T1New = Typedef!(T1, T1.init, t0); alias T2New = Typedef!(T2, T2.init, t1); pragma(msg, __traits(isSame, T1New, T2New)); // false there was a heated discussion about `std.typecons.Typedef`, built-in `typedef` and other related things, but the decision was to keep the status quo. I can't believe I missed the cookie part. Thanks!
Re: Is this visible to all?
On Sunday, 11 January 2015 at 07:16:46 UTC, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:m8sr3k$2s2e$1...@digitalmars.com... Some links on github are only visible to admins/committers. Is this available to all? https://github.com/pulls?user=D-Programming-Language Andrei You can log out to see if the page is publically visible. Better: open an incognito tab / private window. Then you won't have to log back in.
Re: Tuple/Typedef question
On Sun, 11 Jan 2015 12:00:19 + Martin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: as for `Typedef!` -- you can use it's third arg, cookie: import std.typecons; alias T1 = Tuple!(int, int); alias T2 = Tuple!(int, int); alias T1New = Typedef!(T1, T1.init, t0); alias T2New = Typedef!(T2, T2.init, t1); pragma(msg, __traits(isSame, T1New, T2New)); // false there was a heated discussion about `std.typecons.Typedef`, built-in `typedef` and other related things, but the decision was to keep the status quo. I can't believe I missed the cookie part. Thanks! this part deserves a better explanation in docs, 'cause it's easy to miss the details, especially for those who assumed that each `Typedef!` creates a distinct type. too bad that my writing skills sux (and i'm really biased against the current `Typedef!`). signature.asc Description: PGP signature
Re: GSOC - Holiday Edition
On Sat, 2015-01-10 at 19:30 +, Craig Dillabaugh via Digitalmars-d wrote: 8) Russel Winder and QML ... see #4. Should we drop QML support from our GSOC due to: http://forum.dlang.org/thread/hapeegrotkazppwdn...@forum.dlang.org Or promote it even more with filcuc as a co-mentor as it is active and something can come of it? -- 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
Could D compete in a competition like this?
Could D compete in a competition like this? In a nutshell: We give you a bunch of ranked 2D points, then ask you to find the most important ones inside some randomly generated rectangles. Easy, right? Now make it fast, and you could get $5K! http://churchillnavigation.com/challenge/ Can D produce Windows DLL's?
Re: Why exceptions for error handling is so important
On 1/11/15, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. Or a @noignore attribute. Just having that alone could easily catch the mistake of ignoring a return value. I'm really rooting for this, but is anyone else on board?
Re: An idea for commercial support for D
On Friday, 9 January 2015 at 15:39:13 UTC, Joakim wrote: It poses unacceptable risk of company becoming hostage of ecosystem were buying closed patches is only way to use the tool effectively. In software world where even .NET goes open-source there is simply no reason why would one agree on such terms. See my response to Joe above, most devs rely on closed toolchains. Funny how they all avoid becoming hostages. It doesn't match my observations at all. Of 5 places I worked, 4 actively avoided any closed toolchains unless those promised too much of a benefit and where considered worth the risk. I'd expect this probably to be more common attitude among smaller companies as enterprise relies on lawyers to address such risks and does not care that much. Right now quite some of other developers contribute to D2 toolchain and related projects even if it is not directly used. It makes sense exactly because project is fully open - there is a good trust that such work won't get wasted and/or abused and sit there until its actually needed, encouraging other people to contribute in the meanwhile. It won't work that way with hybrid model. I don't see how other devs selling paid patches will affect the mentioned aspects of OSS devs working on D. Simply claiming that it won't work that way anymore is not an argument. It is matter of licensing. Right now it is all open and company using D can be absolutely sure that it is possible to fork the project at any time while keeping both own contributions and all stuff that was paid for. Closed patches would need to restrict that to prevent simple sharing of such patches resulting in much more complicated situation. It also prevents clash of interests - upstream would be interested in preventing open contributions to areas that are covered by closed patches to make buying them more tempting. 1) Selling services is indeed much different from selling software and much more honest. When you sell a program you don't really sell anything of value - it is just bunch of bytes that costs you nothing to copy. When you sell service you don't just sell access to same software running on the server but continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time. This is actually something of value and charging for that is more widely accepted as just. The only ridiculous statement I see here is your claim that building a desktop/mobile program doesn't also require continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time. Both server and desktop/mobile software are widely considered worth charging for: it is highly idiosyncratic and self-rationalizing for you to claim that one is significantly different from the other. Building requires. Selling/maintaining - doesn't. And pure sell-the-software model pretty much never includes and guaranteed support from the developer. Quite the contrary, those are always tempted to abandon support in favor of making new major version of same software and selling it again for same money. There is also inherent economical issue as such model introduces huge gap between successful companies and contenders (either you cover development losses and get any income on top for free or you don't and go bankrupt) favoring creation of monopolies. It isn't about desktop vs server but about product vs service. 2) We don't even sell plain service access - it is more delicate than that, exactly to ensure that our client don't feel like product hostages and get encouraged to try with no big commitment. You can contact our sales department for more details ;) You take money and create mostly closed-source software: those are the only details that matter in this discussion. Nope, this wasn't at all what I was talking about. My objections is not as much against the fact patches are closed but the fact that you propose to sell _patches_. I despise copyright, not closed software. I am pretty sure company leadership won't me as radical as me on this matter but so far our business model matches my personal beliefs and that keeps me happy :) 3) There are indeed plans for open-sourcing at least base libraries we use. It is taking very long because making something public in a way that won't hit you back is damn tricky legally these days and it is blocked in legal department for quite a while. No announcement because no idea how long may it take. Sociomantic has always been generous with the D community, I don't mean to imply you haven't. But unless you open-source all your code, you're employing a hybrid closed-source model, exactly the kind of model you're objecting to here. :) Funny how it's good for Sociomantic but not anybody else. I hope earlier statements explain the difference. Yes, I am much in favor of paying for actual effort and
How to interface with C++ code or dll?
I am trying to understand how to use C++ lib from D. For my App I need http://www.gdal.org I had read about using C++ libs from D, and understood that there is 2 ways: 1. Make binding - convert .H to .d (I still do not fully understand what is it) 2. Use directly C++ lib (.dll) I decided to start from simple example http://www.gdal.org/warptut.html For compiling it's need #include gdalwarper.h, so I maked gdalwarper.d with tool htod. I know that it's not recommended for usage more, but other tools look too complex for me (I even do not understand how to sun them on Windows). After I had add import gdalwarper.d to my test project. But during compilation it's asked me about other d files, that I included one ny other in App.d file. In the result I got error that: source\cpl_port.d(147): Error: module ctype is in file 'std\c\ctype.d' which can not be read I have got a question. Files that I include is only header files. They do not include any code. How App would run? I should specify C++ source location or what? = Then I decided to look how to use ready dll. As far as I know D have directive pragma(), that allow to import any lib. Also afaik that it support inly import of dll in format of lib. Am I right? And next. How I can understand which lib do I need. All documentation of GDAL assume that programmer will use source code, but not libs. And what I should to do? I download gdal bins, and there is a lot of dlls and I even can't understand which of them I need.
Re: Could D compete in a competition like this?
On Sunday, 11 January 2015 at 13:01:36 UTC, Gary Willoughby wrote: Could D compete in a competition like this? The guts will have to be done in assembly or Intel intrinsics...
Re: Is anyone working on a D source code formatting tool?
On Saturday, 10 January 2015 at 22:11:55 UTC, Walter Bright wrote: On 1/10/2015 12:17 PM, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? Next question - standalone tool, or built in to dmd (like Ddoc)? I think best approach is akin to git subcommands - you can call stuff via `git command` but it in fact runs separate `git-command` binary behind the scene (which can also be used stand-alone). I would love to see DDOC implemented that way too.
Re: Is anyone working on a D source code formatting tool?
On 1/10/15, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? Uncrustify claims D support. http://uncrustify.sourceforge.net/ Yes, and the author is responsive whenever a new D-related bug is filed. I've used Uncrustify successfully with D for many years. It would be nice to have an implementation in D (purely to be able to more easily hack on the tool and configure it to our own liking), but as far as having a tool that works right now - uncrustify is exactly that tool.
Re: Why exceptions for error handling is so important
On Sun, 11 Jan 2015 14:32:21 +0100
Andrej Mitrovic via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 1/11/15, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
What is your opinion of approach advertised by various functional
languages and now also Rust? Where you return error code packed
with actual data and can't access data without visiting error
code too, compiler simply won't allow it.
Or a @noignore attribute. Just having that alone could easily catch
the mistake of ignoring a return value. I'm really rooting for this,
but is anyone else on board?
`if (myfunc()) {}` ;-) it's still easier than
`try myfunc() catch (Exception) {}`.
this is a question of opt-in versus opt-out. i believe that ignoring
errors should be opt-in, not vice versa. and unhandled error MUST
bomb out the app.
signature.asc
Description: PGP signature
Re: Thoughts on replacement languages (Reddit + D)
Reddit seems to have a constant stream of random project in Go posts. There was one this week that was a command line websocket and it was like 40 lines of code. Come on. I'm tempted to start posting every little thing I write in D to it too, but it'd just be spam!
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 13:37:33 UTC, Ola Fosheim Grøstad wrote: On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote: Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon more dead is a very subjective term. It is more dead in the sense that you got @nogc and there was a sense of movement towards getting to a workable memory model, but since then nothing has happend. One step forward, then stagnation. The Rust team have announced that they are moving towards a non-breaking stability situation within 6 weeks. And they have a working memory model. Andrei and Walter need to stop focusing on details for a moment and focus more on presenting a great plan within 2 months. Meaning stating goals and plans which gives D a direction that developers want and can believe in. If no clear statements on where D is heading appears in the near future... Well, then I am pretty sure that many of those who prefer D will give Rust a spin when Rust hits 1.0, out of boredom. Rust is not complete feature wise, but a working memory model and stability is more important than having single inheritance and other convenience features... So D is not dead, but is currently in a position where it can be hit by both Go and Rust. The space between Rust (system programming) and Go (server programming) is very tiny. The problem with Rust and Go is that they only deliver in theory, while D kicks some asses in practice. How? Eg: at this very moment, D is more stable than Rust, ground truth. D has backends for GCC/LLVM/custom, Go has backends for GCC / Plan9, Rust only for LLVM. None of Rust+Go can link with binaries produced by eg. the Microsoft compiler. None of them has Visual Studio integration with debugging support and that is pretty important for native and enterprise programmers. Go is actively behind the times by preventing shared libraries and discouraging exceptions, let alone generics. None of the C++ programmers I know give Go any credit, cause it would make their work more difficult, and it's already pretty difficult. Despite efforts, Rust don't get syntax right. They will enjoy huge amount of complaining as soon as people actually use the language, only to discover it is not fun enough and fun is more important than memory safety without GC. Looks like it inherited its boringness from Ocaml. I don't buy in the Rust team stability guarantees, you can't go from pondering about removing box this very week (the syntax is from this year) then promising stability forever starting next month. But for some reason everything they say has a ring of truth, because it's Mozilla they only do Good Things right? They will come to the same model as D, minimizing code breakage but do it anyway, because it's way more practical. And as soon as Servo is interrupted because of internal politics at Mozilla or rebudgeting (ie. very high probability), Rust will be halted in a heartbeat since loosing its purpose. Ever noticed the Rust original designer jumped off ship long ago? That won't happen with D, whatever the ratio of github projects in the fashion industry.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:03:05 UTC, Adam D. Ruppe wrote: Reddit seems to have a constant stream of random project in Go posts. There was one this week that was a command line websocket and it was like 40 lines of code. Come on. I'm tempted to start posting every little thing I write in D to it too, but it'd just be spam! I still think the best one was the stackoverflow comparison.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:03:05 UTC, Adam D. Ruppe wrote: Reddit seems to have a constant stream of random project in Go posts. There was one this week that was a command line websocket and it was like 40 lines of code. Come on. I'm tempted to start posting every little thing I write in D to it too, but it'd just be spam! You know what, if you push out the projects which are tiny utilities that solves real world problems, then you might get people interested. If you can solve such real world problems in 40 lines of code it is good marketing. Isn't that the foundation of Python's popularity? And perl before that? And php? Just do it! :)
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 15:29:45 UTC, Dicebot wrote: On Sunday, 11 January 2015 at 14:43:08 UTC, Ola Fosheim Grøstad wrote: Maybe we should do a comparison thread between D and Rust. It might be interesting, and perhaps encourage some improvements to D. I am actually writing a Rust guide as read by D developer article now making random notes on topic. But I don't see this affecting D much as most of the things I liked in Rust more were also things I complained about in D for ages before. Looking forward to reading it, I hope you publish it on a website so that it can draw in non-D people too.
Re: An idea for commercial support for D
There are very few monopolies in software, essentially none nowadays. :D :D :D :D :D I have not laughed so hard for quite a while. Modern IT industry is absolutely dominated by monopolies / oligopolies. Hard to reason with you if this is what you see.
Re: An idea for commercial support for D
On Sunday, 11 January 2015 at 16:13:01 UTC, Dicebot wrote: There are very few monopolies in software, essentially none nowadays. :D :D :D :D :D I have not laughed so hard for quite a while. Modern IT industry is absolutely dominated by monopolies / oligopolies. Hard to reason with you if this is what you see. You should really try to keep up to date with recent market share stats: http://www.businessinsider.in/In-Case-You-Dont-Appreciate-How-Fast-The-Windows-Monopoly-Is-Getting-Destroyed-/articleshow/21123434.cms
Re: Is it possible to collect object usage information during compilation?
On Sunday, 11 January 2015 at 09:54:42 UTC, Jacob Carlborg wrote: On 2015-01-11 02:08, DaveG wrote: In the past I have used FreeTDS, through PHP, and it had a lot of problems. This was several years ago and could have been at least partially due to the PHP layer. Last year I messed around with the ODBC wrapper and got amazingly poor performance, I believe the project was abandoned before I figured out the problem. Anybody actually using this in D? I'll have to write some tests and fire up the SQL profiler. We used Ruby on Rails with an SQL Server at my previous work. We used TinyTDS which uses FreeTDS. It worked surprisingly well but it did had some problems. One of those problems were encoding problems, but that mostly because we used an older version of SQL Server. It was probably around 2011 when last I used FreeTDS, and even then I think it was an older version, so it's quite possible those issues have been resolved. My bias against it probably unjustified. We are only targeting Windows anyway so ODBC is probably a safe bet.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 15:44:42 UTC, thedeemon wrote: ...For example, compare these stats: http://www.code2014.com/ http://code2013.herokuapp.com/ Interesting charts. But on the other hand, I remember that sometime ago Andrei posted ( http://forum.dlang.org/thread/lu6mhc$t2k$1...@digitalmars.com ) some numbers: DL | Month 5886 2013-01 5525 2013-02 22799 2013-03 11717 2013-04 6214 2013-05 9614 2013-06 11455 2013-07 16803 2013-08 20835 2013-09 19009 2013-10 20569 2013-11 15742 2013-12 18002 2014-01 20191 2014-02 18651 2014-03 19600 2014-04 21015 2014-05 20962 2014-06 34979 2014-07 34288 2014-08 1088 2014-09-01 ( Just 3 days ). Matheus.
Re: Why exceptions for error handling is so important
to not let ranges succumb to such a problem I wrote: https://github.com/D-Programming-Language/phobos/pull/2724
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 16:30:09 UTC, MattCoder wrote: Yes, that was what I saw on this thread: http://forum.dlang.org/thread/lu6mhc$t2k$1...@digitalmars.com I don't think such statistics matters much. Downloads is a bad measure, retention rate is what you want to measure (the ratio of people trying vs using). Just focus on what works for your projects and whether the maturity level of the tool and the ecosystem supports what you want to do. Different languages appeal to different domains, but with the less popular tools you have to do a lot yourself or create C/C++ bindings. Compare eco-system repositories and you'll get an idea of what profiles different languages have: http://code.dlang.org/ http://godoc.org/-/index https://github.com/search?q=stars%3A%3E10l=rust
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:03:05 UTC, Adam D. Ruppe wrote: Reddit seems to have a constant stream of random project in Go posts. There was one this week that was a command line websocket and it was like 40 lines of code. Come on. I'm tempted to start posting every little thing I write in D to it too, but it'd just be spam! At least it would rise awareness. -- Paulo
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:43:08 UTC, Ola Fosheim Grøstad wrote: Maybe we should do a comparison thread between D and Rust. It might be interesting, and perhaps encourage some improvements to D. I am actually writing a Rust guide as read by D developer article now making random notes on topic. But I don't see this affecting D much as most of the things I liked in Rust more were also things I complained about in D for ages before.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:12:08 UTC, Bauss wrote: On Sunday, 11 January 2015 at 14:03:05 UTC, Adam D. Ruppe wrote: Reddit seems to have a constant stream of random project in Go posts. There was one this week that was a command line websocket and it was like 40 lines of code. Come on. I'm tempted to start posting every little thing I write in D to it too, but it'd just be spam! I still think the best one was the stackoverflow comparison. Correct me if I am wrong, but I think the stackoverflow comparison is in error, as Go has no forum like D's (http://forum.dlang.org).
Re: An idea for commercial support for D
On Sunday, 11 January 2015 at 12:39:03 UTC, Dicebot wrote: On Friday, 9 January 2015 at 15:39:13 UTC, Joakim wrote: It poses unacceptable risk of company becoming hostage of ecosystem were buying closed patches is only way to use the tool effectively. In software world where even .NET goes open-source there is simply no reason why would one agree on such terms. See my response to Joe above, most devs rely on closed toolchains. Funny how they all avoid becoming hostages. It doesn't match my observations at all. Of 5 places I worked, 4 actively avoided any closed toolchains unless those promised too much of a benefit and where considered worth the risk. I'd expect this probably to be more common attitude among smaller companies as enterprise relies on lawyers to address such risks and does not care that much. So you're aware that most programmers do not avoid closed toolchains like four of the places you worked, especially since you worked one place where that wasn't the case. Right now quite some of other developers contribute to D2 toolchain and related projects even if it is not directly used. It makes sense exactly because project is fully open - there is a good trust that such work won't get wasted and/or abused and sit there until its actually needed, encouraging other people to contribute in the meanwhile. It won't work that way with hybrid model. I don't see how other devs selling paid patches will affect the mentioned aspects of OSS devs working on D. Simply claiming that it won't work that way anymore is not an argument. It is matter of licensing. Right now it is all open and company using D can be absolutely sure that it is possible to fork the project at any time while keeping both own contributions and all stuff that was paid for. Closed patches would need to restrict that to prevent simple sharing of such patches resulting in much more complicated situation. Only until those closed patches are paid for. You pay less for a patch than if you were to do the work yourself, since the cost is shared across all the customers who pay for that patch, then you receive it after a funding/time limit. If you really want that patch early, you can always buy out the funding limit or come to some accommodation with the dev, where he licenses it to you with the source. It also prevents clash of interests - upstream would be interested in preventing open contributions to areas that are covered by closed patches to make buying them more tempting. You're assuming that the upstream OSS project devs are also selling closed patches, which none have indicated any interest in doing. Even if they did, I doubt they'd be able to get away with such a move, as it would only make them look bad, and it's trivially easy for the author of the open contribution to make it available in his own github branch. This is quite a silly objection. 1) Selling services is indeed much different from selling software and much more honest. When you sell a program you don't really sell anything of value - it is just bunch of bytes that costs you nothing to copy. When you sell service you don't just sell access to same software running on the server but continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time. This is actually something of value and charging for that is more widely accepted as just. The only ridiculous statement I see here is your claim that building a desktop/mobile program doesn't also require continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time. Both server and desktop/mobile software are widely considered worth charging for: it is highly idiosyncratic and self-rationalizing for you to claim that one is significantly different from the other. Building requires. Selling/maintaining - doesn't. Really? Selling/maintaining cloud services requires continuous efforts for maintaining and improving that software, including developer team costs and server h/w costs over time, but desktop/mobile locally-installed software doesn't? News to me. And pure sell-the-software model pretty much never includes and guaranteed support from the developer. Quite the contrary, those are always tempted to abandon support in favor of making new major version of same software and selling it again for same money. I see, so making major new versions of desktop/mobile software every so often is not continuous efforts for maintaining and improving that software, but updating server software more often is. Funny how you set a magic threshold and define it in your favor. As for the issues you raise with desktop vendors, those are less of a concern with hybrid models, because the buyers have more of an option to fork the OSS core and go elsewhere. There is also inherent economical issue as such model
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 13:57:54 UTC, Kiith-Sa wrote: That guy has been trolling every D thread in the last year. I didn't know that. Glad you said! Either way, D is definitely way more popular/active than it was a year ago, especially with a large jump around last summer but not nearly as much as Go nor Rust at the moment... Yes, that was what I saw on this thread: http://forum.dlang.org/thread/lu6mhc$t2k$1...@digitalmars.com Matheus.
[Issue 12409] Add each function as found in Ruby and jQuery
https://issues.dlang.org/show_bug.cgi?id=12409
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||bearophile_h...@eml.cc
Resolution|FIXED |---
--- Comment #7 from bearophile_h...@eml.cc ---
Reopened because I think the current design of each is too much bug-prone:
void main() {
import std.stdio, std.algorithm;
int[10] a;
a.each!((ref x) = x++);
a.writeln;
a[].each!((ref x, ref i) = x = i);
a.writeln;
a[].each!((ref x, int i) = x = i);
a.writeln;
a[].each!q{ a = i };
a.writeln;
}
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Most Phobos functions don't accept fixed-size arrays. each accepts them, but
takes them by value...
And each accepts functions with a second i argument (and offers the index
i as in the last example), but it ignores it.
This is a mess that will cause many bugs. I suggest to tighten the semantics:
- For uniformity with Phobos it's better to not accept a fixed-size array. If
you want each to accept them, then take them by reference only.
- How do you use the i index with a lambda?
- Wrong functions probably should give a compile-time error.
--
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:43:08 UTC, Ola Fosheim Grøstad wrote: And as soon as Servo is interrupted because of internal politics at Mozilla or rebudgeting (ie. very high probability), Rust will be halted in a heartbeat since loosing its purpose. Ever noticed the Rust original designer jumped off ship long ago? I didn't know that, but I've noticed with some unease that Chrome is growing towards monopoly (except in Germany where Firefox is big). Yep and Mozilla depends almost entirely on Google financially. Scary.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote: On Sunday, 11 January 2015 at 13:37:33 UTC, Ola Fosheim Grøstad wrote: On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote: Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon more dead is a very subjective term. It is more dead in the sense that you got @nogc and there was a sense of movement towards getting to a workable memory model, but since then nothing has happend. One step forward, then stagnation. The Rust team have announced that they are moving towards a non-breaking stability situation within 6 weeks. And they have a working memory model. Andrei and Walter need to stop focusing on details for a moment and focus more on presenting a great plan within 2 months. Meaning stating goals and plans which gives D a direction that developers want and can believe in. If no clear statements on where D is heading appears in the near future... Well, then I am pretty sure that many of those who prefer D will give Rust a spin when Rust hits 1.0, out of boredom. Rust is not complete feature wise, but a working memory model and stability is more important than having single inheritance and other convenience features... So D is not dead, but is currently in a position where it can be hit by both Go and Rust. The space between Rust (system programming) and Go (server programming) is very tiny. The problem with Rust and Go is that they only deliver in theory, while D kicks some asses in practice. How? Eg: at this very moment, D is more stable than Rust, ground truth. D has backends for GCC/LLVM/custom, Go has backends for GCC / Plan9, Rust only for LLVM. None of Rust+Go can link with binaries produced by eg. the Microsoft compiler. None of them has Visual Studio integration with debugging support and that is pretty important for native and enterprise programmers. Go is actively behind the times by preventing shared libraries and discouraging exceptions, let alone generics. None of the C++ programmers I know give Go any credit, cause it would make their work more difficult, and it's already pretty difficult. Despite efforts, Rust don't get syntax right. They will enjoy huge amount of complaining as soon as people actually use the language, only to discover it is not fun enough and fun is more important than memory safety without GC. Looks like it inherited its boringness from Ocaml. I don't buy in the Rust team stability guarantees, you can't go from pondering about removing box this very week (the syntax is from this year) then promising stability forever starting next month. But for some reason everything they say has a ring of truth, because it's Mozilla they only do Good Things right? They will come to the same model as D, minimizing code breakage but do it anyway, because it's way more practical. And as soon as Servo is interrupted because of internal politics at Mozilla or rebudgeting (ie. very high probability), Rust will be halted in a heartbeat since loosing its purpose. Ever noticed the Rust original designer jumped off ship long ago? That won't happen with D, whatever the ratio of github projects in the fashion industry. I am known to complain about some of the Go missing features. However I am closer to use Go than D at work alongside .NET and JVM. Why? Because of Docker. Now with big names adopting Docker, our enterprise customers are looking into it for cloud deployments. D really needs a some kind of killer application/framework. -- Paulo
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote: Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon I understand he's talking not about absolute numbers but about relative popularity/mindshare. And as other languages grow (like Rust) total mindshare of D might decrease. In some metrics absolute numbers also decrease. For example, compare these stats: http://www.code2014.com/ http://code2013.herokuapp.com/
Re: Is it possible to collect object usage information during compilation?
On Sunday, 11 January 2015 at 10:06:53 UTC, Paolo Invernizzi wrote: On Saturday, 10 January 2015 at 20:53:47 UTC, DaveG wrote: On Saturday, 10 January 2015 at 18:31:18 UTC, Paolo Invernizzi wrote: I would like to see, someday, something in D that: - can check at compile time the syntax of SQL; - can check at compile time the SQL query statement against the current DB schema; - can read the output of a DB schema dump at CT, and parse it into what is needed for the previous points (more complicated); One final note. You may have noticed I didn't mention the schema syncing problem (keeping database and code in sync). There was a time I would have said that was essential and while it would be nice in a perfect world, I'm comfortable keeping them in sync manually (or semi-manual with scripts). I can generate a bunch of classes from an existing database fairly easily and when I change a table I can manually update a class. If I was writing SQL directly I would have to update my query, this is really no different. Doing validation in unit tests is perfectly acceptable to me. I think basically we have the same feeling over the ORM topic. Doing validation in unit tests is for sure acceptable, but my point is that I would like CT validation of plain SQL query over the current DB schema without having to use an ORM. ;-) --- Paolo I agree. That's one thing Couldfusion did well that I haven't really seen since. You could write blocks of SQL complete with validation and syntax highlighting (depending on the editor). Because the SQL parser was built in you could then take resultsets returned from the database and perform additional queries on them locally. The problem a SQL parser doesn't solve is writing dynamic queries which require piecing together a bunch of partial statements. This is where an abstraction layer can really be useful. -Dave
Re: Why exceptions for error handling is so important
On Sunday, 11 January 2015 at 13:25:59 UTC, ketmar via Digitalmars-d wrote: On Sun, 11 Jan 2015 13:06:26 + Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. from my POV it trashes logic with error checking. hey, i don't care if *each* `fwrite()` is successfull, i only care if all of them are ok or at least one (any one) failed! This is where monads and applicatives shine. You can describe the general logic (run 'till first error or collect and combine all errors or something else) in one place and then apply this way of error handling throughout with minimal code, and you can often change the error handling approach later just by changing a type, without editing actual function source code.
Re: ddox question
On 1/11/15 3:03 AM, Mathias LANG wrote: On Saturday, 10 January 2015 at 17:23:24 UTC, Andrei Alexandrescu wrote: In the ddox-generated documentation the heading is e.g. Module std.container. I wanted to style std.container in code font, but can't find where that text is generated. I've searched dlang.org/ and dub/, no avail. Andrei IIUC, you're looking for this: https://github.com/rejectedsoftware/ddox/blob/ce797a3182c1263feb4a6f4c9ce9b88b95d83003/views/layout.dt Which is the base of all layout. But from a quick look (https://github.com/rejectedsoftware/ddox/search?utf8=%E2%9C%93q=h1), the title is the only h1 on the page, so you could just tweak the CSS. I don't think the CSS would be enough. The title is Module xxx.yyy. I only need to format xxx.yyy in code font. How do I do that? -- Andrei
Re: Is anyone working on a D source code formatting tool?
On 1/11/2015 4:47 AM, Russel Winder via Digitalmars-d wrote: Next question - standalone tool, or built in to dmd (like Ddoc)? Also why in DMD and not in LDC or GDC? It would be in the DMD front end, so LDC and GDC would it automatically. 1. people expect this sort of thing these days Thanks to Python PEP-8 and Go, yes. Personalized code formatting is increasingly a thing of the past, programming languages are now opinionated and fascist when it comes to formatting. Even if the rules are wrong. The rules are always going to be wrong. But in this case, that's ok. 2. it tends to end bikeshedding arguments about the right way to format things Except when the tool implements the wrong style. Sometimes it's better to just conform. 3. it'll help standardize the format of D code in the D repositories Even if it is the wrong formatting standard? I have to admit that the Phobos format rules make the code look appallingly ugly to me, sufficiently so that I really do not want to work on that codebase. I guess I am biased towards KR C (which I use to drive my C++ style), Java and Go. Really? Like what? After many years of arguing about formatting myself, I decided that I had better things to waste my time on. 4. it's simply nice and convenient! Working with Go in Emacs or LiteIDE is a bit of a joy as you get full reformatting on save. Fortunately I only have two main gripes with the Go formatting style, but no-one has a choice, use the Go style as dictated by the Go team at Google or do not use Go. So you decided to conform rather than not use Go. (Anyhow, I suggest that gofmt is only mandatory if you wish to contribute to offical Go code, not for your own projects.)
Re: Is anyone working on a D source code formatting tool?
On 1/11/2015 5:11 AM, Dicebot wrote: I would love to see DDOC implemented that way too. Ddoc makes use of semantic info, not just an AST. For semantic info, you pretty much need a real compiler.
Re: An idea for commercial support for D
On 11 January 2015 at 16:23, Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 11 January 2015 at 16:13:01 UTC, Dicebot wrote: There are very few monopolies in software, essentially none nowadays. :D :D :D :D :D I have not laughed so hard for quite a while. Modern IT industry is absolutely dominated by monopolies / oligopolies. Hard to reason with you if this is what you see. You should really try to keep up to date with recent market share stats: http://www.businessinsider.in/In-Case-You-Dont-Appreciate-How-Fast-The-Windows-Monopoly-Is-Getting-Destroyed-/articleshow/21123434.cms Why should Monopoly automatically mean Microsoft? ;-)
Re: Ready to make page-per-item ddocs the default?
On 1/9/15 4:17 PM, Andrei Alexandrescu wrote: On 1/9/15 12:59 PM, Jacob Carlborg wrote: On 2015-01-09 20:46, Andrei Alexandrescu wrote: Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei Is it just me or are the actual declarations missing? Oh yah :o). Steve? -- Andrei Apparently, the documentation generator ignores items that are tagged as documented but without any substance. If I compile a simple doc with a /// before an item, it does show up when I do dmd -D. So I have no idea how to make it work for this new doc system. -Steve
Re: Is anyone working on a D source code formatting tool?
On Sun, 11 Jan 2015 12:47:41 + Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: I don't think it'll be hard to do as a builtin feature of dmd. It should be a separate tool not a part of one of the three compilers. i can't see anything wrong with built-in tool. even if it can't be configured to one's tastes, it's still good for occasional contributors, who can stop worrying about code formatting and just write that code. and if it will be configurable (which is not that hard to do -- to some extent), it will be usable for many more people. besides, being part of the compiler this tool has a good chances of being always up-to-date. as there is already .di emitter, i believe that is can be customised further to do full code formatting. the only thing left to solve is comments (not a small one, though). i.e. compiler already has most of the work done, why not reuse it? signature.asc Description: PGP signature
Re: Is anyone working on a D source code formatting tool?
On 2015-01-11 20:20, Walter Bright wrote: Ddoc makes use of semantic info, not just an AST. For semantic info, you pretty much need a real compiler. I've been thinking of that the last couple of days. It should be pretty straightforward to copy-paste the driver part of DMD, i.e the part contains the main function and handling of the command line arguments. Then remove everything that's not needed for Ddoc. -- /Jacob Carlborg
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 18:25:39 UTC, francesco.cattoglio wrote: On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote: None of them has Visual Studio integration with debugging support and that is pretty important for native and enterprise programmers. If I remember correctly, just 2 month ago someone was explaining how they lost a commercial user because D debugging experience was still not good enough by a long shot. And in my daily use, debug experience is still subpar on windows. only to discover it is not fun enough and fun is more important than memory safety without GC. WHAT? Syntax is boring, but I don't get the sense of the sentence Right, might be personal judgement, at this point I was in rant-mode. :) Rust is supposed to replace C++, and it happens working in C++ since years, I can't help but notice we actually have very few memory safety problems, to the point that I question that it's something worth worrying about. At least, more than D does with .init and bound checking. Bjarne himself talks about how language users ask for different things that what they actually want here: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote (see 27:40) Has this changed fundamentally? I'm obviously being the devil's advocate here, but we can't just say D is much more far ahead, we have nothing to fear from Go and Rust, because it's just not true. And I say it as a daily D user, daily facing issues like the horrible invalidMemoryOperationError exception. When does invalidMemoryOperationError happen and how do you avoid it?
Re: Thoughts on replacement languages (Reddit + D)
ponce: Rust is supposed to replace C++, and it happens working in C++ since years, I can't help but notice we actually have very few memory safety problems, Are you always able to detect them? I think languages (and programmers) that don't have a strict attitude toward memory safety will be slowly left behind in the few next years. D is lacking in this (and the scoping management should be able to plug some holes, and in the meantime there is this: https://github.com/D-Programming-Language/dmd/pull/4277 ). Bye, bearophile
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 19:38:12 UTC, bearophile wrote: Are you always able to detect them? I think languages (and programmers) that don't have a strict attitude toward memory safety will be slowly left behind in the few next years. D is lacking in this (and the scoping management should be able to plug some holes, and in the meantime there is this: https://github.com/D-Programming-Language/dmd/pull/4277 ). There are tools to do that: https://software.intel.com/en-us/intel-inspector-xe When we do have a memory safety bug, these tools help, and then I think this wouldn't have happened in D even without @safe. So I don't think D lacking in this.
Re: Is anyone working on a D source code formatting tool?
On 2015-01-11 19:48, Walter Bright wrote: The main problem is what to do about comments, which don't fit into the grammar. A secondary problem is what to do when the line length limit is exceeded, such as for long expressions. clang-format seems to do a pretty good job with both of these. Comments seem to be intact unless they're too long, then they're wrapped. It seems to wrap at a space or other non-identifier character. Same thing with expressions that are too long. You should download it [1] a give it a try on some C++ code. [1] http://llvm.org/releases/download.html -- /Jacob Carlborg
Re: Thoughts on replacement languages (Reddit + D)
On 1/11/15 10:25 AM, francesco.cattoglio wrote: I'm obviously being the devil's advocate here, but we can't just say D is much more far ahead, we have nothing to fear from Go and Rust, because it's just not true. Totally agreed. It's a competitive climate out there, and we need to mind our competition. And I say it as a daily D user, daily facing issues like the horrible invalidMemoryOperationError exception. What is that? Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/11/15 11:26 AM, Steven Schveighoffer wrote: On 1/9/15 4:17 PM, Andrei Alexandrescu wrote: On 1/9/15 12:59 PM, Jacob Carlborg wrote: On 2015-01-09 20:46, Andrei Alexandrescu wrote: Stuff's up! http://dlang.org/library-prerelease/core/stdc/complex.html. I couldn't get rid of the darn space between the header name and the period. -- Andrei Is it just me or are the actual declarations missing? Oh yah :o). Steve? -- Andrei Apparently, the documentation generator ignores items that are tagged as documented but without any substance. If I compile a simple doc with a /// before an item, it does show up when I do dmd -D. So I have no idea how to make it work for this new doc system. Martin Nowak? Sönke Ludwig? Andrei
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 19:49:32 UTC, Andrei Alexandrescu wrote: On 1/11/15 10:25 AM, francesco.cattoglio wrote: And I say it as a daily D user, daily facing issues like the horrible invalidMemoryOperationError exception. What is that? It happens if you try to do a GC operation while the GC is running. The typical cause is allocating in a destructor. (Accessing reference type member variables from class destructor is another way to get a crash, since the GC might collect them first.) There's a handful of memory issues in D, some with the GC and some when you try to avoid the GC, but they typically don't bother me perhaps because I've learned to avoid problematic areas, like non-trivial class destructors.
Re: Is anyone working on a D source code formatting tool?
On 1/11/15 10:48 AM, Walter Bright wrote: On 1/11/2015 9:45 AM, Stefan Koch wrote: I'm powerful writing a parser-generator, that will be able to transform the generated parse-tree back into source automatically. writing a rule-based formatter should be pretty doable. Formatting the AST into text is straightforward, dmd already does that for .di file generation. The main problem is what to do about comments, which don't fit into the grammar. In the first version comments might go through unchanged. A secondary problem is what to do when the line length limit is exceeded, such as for long expressions. I think that's problem #1. Andrei
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 19:38:12 UTC, bearophile wrote: ponce: Rust is supposed to replace C++, and it happens working in C++ since years, I can't help but notice we actually have very few memory safety problems, Are you always able to detect them? When Intel MPX comes you should be able to in debug builds, since you then supposedly cache the bounds for all mallocs. It basically attaches bounds to every pointer with a hardware mechanism for lookups. And you can turn it off at runtime, which turns the MPX instructions into NOP. So you can basically deploy an application with MPX builtin and tell a customer to turn on MPX if there is a problem that is suspected to be memory related. But keep in mind that linear typing also affords safer multi-threading and removes doubts about aliasing which can prevent optimization... How important is it? Time will show YMMV.
Sqlite
Can someone please tell me what I'm doing wrong here, the sql
INSERT statement fails for some reason. I don't fully understand
the callback function yet (I borrowed this from a C tutorial on
the subject), maybe that is the source of the problem?
import etc.c.sqlite3;
import std.stdio;
//stub
extern(C) int aCallback(void *n, int c, char **v, char **col)
{
return 0;
}
void main(){
sqlite3 *db;
int result = sqlite3_open(myDatabase.db, db);
if (result) {
writeln(Failed to open database);
return;
}
//create table
char *msg = null;
result = sqlite3_exec(db, CREATE TABLE people('id INT PRIMARY
KEY NOT NULL, surname TEXT NOT NULL');, aCallback, null, msg);
if (result) {
writeln(Failed to create table);
//tidy up on exit
sqlite3_close(db);
return;
}
//insert record
msg = null;
result = sqlite3_exec(db, INSERT INTO people (id, surname)
VALUES (1, 'Smith');, aCallback, null, msg);
if (result) {
writeln(Failed to insert record);
//tidy up on exit
sqlite3_close(db);
return;
}
sqlite3_free(msg);
sqlite3_close(db);
}
Many thanks
Paul
Re: Build all combinations of strings
On Monday, 11 June 2012 at 19:52:38 UTC, bearophile wrote:
Using that the code is:
import std.string, std.stdio, std.array;
void main() {
auto words = foo bar doo.split();
auto res = permutations!false(words).map!(p = p.join(
))().array();
writeln(res);
}
Is doCopy really needed as an argument here?
Couldn't this be inferred from the mutability of T instead?
Re: Thoughts on replacement languages (Reddit + D)
On 1/11/15 7:29 AM, Dicebot wrote: On Sunday, 11 January 2015 at 14:43:08 UTC, Ola Fosheim Grøstad wrote: Maybe we should do a comparison thread between D and Rust. It might be interesting, and perhaps encourage some improvements to D. I am actually writing a Rust guide as read by D developer article now making random notes on topic. But I don't see this affecting D much as most of the things I liked in Rust more were also things I complained about in D for ages before. That sounds like a very interesting article. Looking forward to it. -- Andrei
Re: Is it possible to collect object usage information during compilation?
On 1/11/15 8:21 AM, DaveG wrote: On Sunday, 11 January 2015 at 09:54:42 UTC, Jacob Carlborg wrote: On 2015-01-11 02:08, DaveG wrote: In the past I have used FreeTDS, through PHP, and it had a lot of problems. This was several years ago and could have been at least partially due to the PHP layer. Last year I messed around with the ODBC wrapper and got amazingly poor performance, I believe the project was abandoned before I figured out the problem. Anybody actually using this in D? I'll have to write some tests and fire up the SQL profiler. We used Ruby on Rails with an SQL Server at my previous work. We used TinyTDS which uses FreeTDS. It worked surprisingly well but it did had some problems. One of those problems were encoding problems, but that mostly because we used an older version of SQL Server. It was probably around 2011 when last I used FreeTDS, and even then I think it was an older version, so it's quite possible those issues have been resolved. My bias against it probably unjustified. We are only targeting Windows anyway so ODBC is probably a safe bet. Should be easy to extract the necessaries for a generic ODBC driver for D from https://github.com/prestodb/presto-odbc. -- Andrei
Re: Thoughts on replacement languages (Reddit + D)
On 1/11/15 8:27 AM, MattCoder wrote: On Sunday, 11 January 2015 at 15:44:42 UTC, thedeemon wrote: ...For example, compare these stats: http://www.code2014.com/ http://code2013.herokuapp.com/ Interesting charts. But on the other hand, I remember that sometime ago Andrei posted ( http://forum.dlang.org/thread/lu6mhc$t2k$1...@digitalmars.com ) some numbers: DL | Month 5886 2013-01 5525 2013-02 22799 2013-03 11717 2013-04 6214 2013-05 9614 2013-06 11455 2013-07 16803 2013-08 20835 2013-09 19009 2013-10 20569 2013-11 15742 2013-12 18002 2014-01 20191 2014-02 18651 2014-03 19600 2014-04 21015 2014-05 20962 2014-06 34979 2014-07 34288 2014-08 1088 2014-09-01 ( Just 3 days ). I just regenerated the 28-day moving average graph: erdani.com/d/downloads.daily.png Andrei
Re: Thoughts on replacement languages (Reddit + D)
On 1/11/15 9:43 AM, Andrei Alexandrescu wrote: I just regenerated the 28-day moving average graph: erdani.com/d/downloads.daily.png http://erdani.com/d/downloads.daily.png that is. -- Andrei
Re: Is anyone working on a D source code formatting tool?
I'm powerful writing a parser-generator, that will be able to transform the generated parse-tree back into source automatically. writing a rule-based formatter should be pretty doable.
Want to make http://dconf.org more attractive?
Please add here! https://github.com/D-Programming-Language/dconf.org/pulls. I'm thinking CSS, design, layout, content, the whole enchilada. dconf.org is a much smaller site than dlang.org and has much fewer constraints., Contributions appreciated! Andrei
Re: Build all combinations of strings
Nordlöw:
Is doCopy really needed as an argument here?
Couldn't this be inferred from the mutability of T instead?
doCopy is useful, if it's true all the permutation arrays are
distinct and dup-ped, otherwise they are all different. It's true
by default, so casual users of that generator will avoid bugs.
You can set it to false to speed up your code.
Later I have refined the idea, you can see it here, that allows
true @nogc code when needed:
struct CartesianPower(bool doCopy=true, T) {
T[] items;
uint repeat;
T[] row;
uint i, maxN;
this(T[] items_, in uint repeat_, T[] buffer) pure nothrow
@safe @nogc {
this.items = items_;
this.repeat = repeat_;
row = buffer[0 .. repeat];
row[] = items[0];
maxN = items.length ^^ repeat;
}
static if (doCopy) {
@property T[] front() pure nothrow @safe @nogc {
return row.dup;
}
} else {
@property T[] front() pure nothrow @safe @nogc {
return row;
}
}
@property bool empty() pure nothrow @safe @nogc {
return i = maxN;
}
void popFront() pure nothrow @safe @nogc {
i++;
if (empty)
return;
uint n = i;
size_t count = repeat - 1;
while (n) {
row[count] = items[n % items.length];
count--;
n /= items.length;
}
}
}
auto cartesianPower(bool doCopy=true, T)(T[] items, in uint
repeat)
pure nothrow @safe {
return CartesianPower!(doCopy, T)(items, repeat, new
T[repeat]);
}
auto cartesianPower(bool doCopy=true, T)(T[] items, in uint
repeat, T[] buffer)
pure nothrow @safe @nogc {
if (buffer.length = repeat) {
return CartesianPower!(doCopy, T)(items, repeat, buffer);
} else {
// Is this correct in presence of chaining?
static immutable err = new Error(buffer.length
repeat);
throw err;
}
}
void main() @nogc {
import core.stdc.stdio;
int[3] items = [10, 20, 30];
int[4] buf;
foreach (p; cartesianPower!false(items, 4, buf))
printf((%d, %d, %d, %d)\n, p[0], p[1], p[2], p[3]);
}
Bye,
bearophile
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote: None of them has Visual Studio integration with debugging support and that is pretty important for native and enterprise programmers. If I remember correctly, just 2 month ago someone was explaining how they lost a commercial user because D debugging experience was still not good enough by a long shot. And in my daily use, debug experience is still subpar on windows. only to discover it is not fun enough and fun is more important than memory safety without GC. WHAT? Syntax is boring, but I don't get the sense of the sentence I don't buy in the Rust team stability guarantees, you can't go from pondering about removing box this very week. They have not broken any promise just yet! :P And I somehow hope they can really manage a high level of stability after discussing throughtly this much about every bikeshed topic (including the recent int/uint change). And as soon as Servo is interrupted because of internal politics at Mozilla or rebudgeting (ie. very high probability), Rust will be halted in a heartbeat since loosing its purpose. Ever noticed the Rust original designer jumped off ship long ago? I do agree that this might be a real risk. But the bus factor for the D project ain't the smallest either. D development could grind to a halt if a handful of developers retire from the project. I'm obviously being the devil's advocate here, but we can't just say D is much more far ahead, we have nothing to fear from Go and Rust, because it's just not true. And I say it as a daily D user, daily facing issues like the horrible invalidMemoryOperationError exception.
Re: D idioms list
On 1/11/2015 4:24 AM, Russel Winder via Digitalmars-d-announce wrote: Feel free to send stuff to ACCU's CVu or Overload. http://accu.org/index.php/journal Good idea!
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 17:44:59 UTC, Andrei Alexandrescu wrote: On 1/11/15 9:43 AM, Andrei Alexandrescu wrote: I just regenerated the 28-day moving average graph: erdani.com/d/downloads.daily.png http://erdani.com/d/downloads.daily.png that is. -- Andrei Considered doing a scatter plot of geolocations (based on ip)?
Re: Thoughts on replacement languages (Reddit + D)
On 1/11/2015 6:48 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: You know what, if you push out the projects which are tiny utilities that solves real world problems, then you might get people interested. If you can solve such real world problems in 40 lines of code it is good marketing. Isn't that the foundation of Python's popularity? And perl before that? And php? Just do it! :) For once, I agree with you :-D I often enjoy reading short programs that illustrate something clever. Some large project, I'm unlikely to start browsing its source.
Re: Thoughts on replacement languages (Reddit + D)
On 1/11/2015 7:29 AM, Dicebot wrote: I liked in Rust more were also things I complained about in D for ages before. I know the feeling. My internal state of the right way to write programs evolves constantly.
Re: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 18:37:31 UTC, Walter Bright wrote: For once, I agree with you :-D You're in denial, you meant like always. ;ˆ]
Re: Is anyone working on a D source code formatting tool?
On 1/11/2015 9:45 AM, Stefan Koch wrote: I'm powerful writing a parser-generator, that will be able to transform the generated parse-tree back into source automatically. writing a rule-based formatter should be pretty doable. Formatting the AST into text is straightforward, dmd already does that for .di file generation. The main problem is what to do about comments, which don't fit into the grammar. A secondary problem is what to do when the line length limit is exceeded, such as for long expressions.
Re: DConf 2015 Call for Submissions is now open
On 10 January 2015 at 20:15, Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 1/10/2015 9:50 AM, Andrei Alexandrescu wrote: On 1/10/15 9:49 AM, Andrei Alexandrescu wrote: On 1/10/15 8:15 AM, Iain Buclaw via Digitalmars-d-announce wrote: In any event, are you doing flash talks this year? I don't think I could find something to spend more than 15 minutes talking about this year. Yes. -- Andrei I should add that gdc is a topic of much interest so pretty much anything you say would be interesting. I compel you to prepare a full talk. -- Andrei I agree. There's no way you don't have interesting things to talk about! For example, what is your process for integrating dmd changes into gdc? What are the advantages/disadvantages of gdc? What are the biggest challenges you face working on gdc? What's the hardest problem you solved with gdc? How can others help out? Etc. Talking about that probably extends a possible talk to 30 minutes, covering two subjects. :o) I could do a talk about GNU + D, which pretty much covers what I've done over the last year, and what I intend to do over the next. Many things are happening - gccjitd (D bindings for JIT library with gcc backend), gdb (D repl in debugger), binutils (GNU ld, nm, objdump getting D demangling support), gdc... Possibly one thing that I find difficult when it comes to considering timing is that I have no notion of *slow down* - this is a common trait with people in general from my region of the UK. It may sound strange, but Londoners are pretty dull in my ears as they can occasionally speak too slow for me to follow (I hear each individual word, but the connection between gets lost). I also found the same when talking my way around the California Bay Area, with the added effect of an American accent that I was never sure if they speaking in sarcasm or not. I digress, I will have to sit down and write some things up and we'll see where I get. Regards, Iain.
Re: Sqlite
On Sun, 11 Jan 2015 20:00:03 +
Paul via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Can someone please tell me what I'm doing wrong here, the sql
INSERT statement fails for some reason. I don't fully understand
the callback function yet (I borrowed this from a C tutorial on
the subject), maybe that is the source of the problem?
import etc.c.sqlite3;
import std.stdio;
//stub
extern(C) int aCallback(void *n, int c, char **v, char **col)
{
return 0;
}
void main(){
sqlite3 *db;
int result = sqlite3_open(myDatabase.db, db);
if (result) {
writeln(Failed to open database);
return;
}
//create table
char *msg = null;
result = sqlite3_exec(db, CREATE TABLE people('id INT PRIMARY
KEY NOT NULL, surname TEXT NOT NULL');, aCallback, null, msg);
if (result) {
writeln(Failed to create table);
//tidy up on exit
sqlite3_close(db);
return;
}
//insert record
msg = null;
result = sqlite3_exec(db, INSERT INTO people (id, surname)
VALUES (1, 'Smith');, aCallback, null, msg);
if (result) {
writeln(Failed to insert record);
//tidy up on exit
sqlite3_close(db);
return;
}
sqlite3_free(msg);
sqlite3_close(db);
}
Many thanks
Paul
if you'll output the error message, you'll see something unusual here:
if (result) {
import std.conv : to;
writeln(Failed to insert record: , to!string(msg));
//tidy up on exit
sqlite3_close(db);
return;
}
Failed to insert record: table people has no column named id
wow! but it has! or isn't it? yep, it hasn't. the error is here:
result = sqlite3_exec(db, CREATE TABLE people('id INT PRIMARY
KEY NOT NULL, surname TEXT NOT NULL');, aCallback, null, msg);
`CREATE TABLE people('...')` is not the syntax you want. i don't know
why sqlite is not rejecting it, but the correct one is this:
result = sqlite3_exec(db, CREATE TABLE people(id INT PRIMARY ~
KEY NOT NULL, surname TEXT NOT NULL);, aCallback, null, msg);
note the single quotes in your code: that is where it all goes wrong. i
don't know where you got that quotes from, but this is not a valid SQL
syntax for `CREATE TABLE`. ;-)
signature.asc
Description: PGP signature
