Re: sockaddr_in and InternetAddress
On Friday, 29 May 2015 at 00:08:10 UTC, Andre Kostur wrote: I'm looking for one of two things: 1) If I have a sockaddr_in, how do I get it into an InternetAddress? First of all, you may not actually need an InternetAddress. Modern code working with addresses should be address-agnostic, so it should take an Address instead. Ideally, you should avoid doing anything address-family-specific - then, it will work with any address family, incl. any introduced in the future. You could: - Create an UnknownAddressReference which uses a pointer to your sockaddr_in. - Create an InternetAddress, then copy the address over its "name" property. 2) If it is agreed that there should be a shorter way, I'm willing to write the code, but would need a little guidance as to where would be the appropriate place to put the code (New overload to parseAddress? New constructor for InternetAddress?) A new constructor for InternetAddress won't hurt.
Re: sockaddr_in and InternetAddress
I would add it as a new constructor to InternetAddress.
In the mean time, you could work around the lack of it by making
a new subclass of InternetAddress that sets the member with your
constructor. Like:
class MyInternetAddress : InternetAddress {
this(sockaddr_in addr) {
this.sin = addr;
}
}
and I think that will work. (Looking at the source, the sin
member is protected which means a subclass can get at it.)
Then you just pass it everywhere InternetAddress is expected and
it ought to just work.
sockaddr_in and InternetAddress
I'm looking for one of two things: 1) If I have a sockaddr_in, how do I get it into an InternetAddress? I can do it with sufficient handwaving using bigEndianToNative and such (pulling out the 4-byte address in there), but I was expecting an easier/shorter method to get the sockaddr_in into an InternetAddress (after all, it's exactly what an InternetAddress is holding internally anyway)? 2) If it is agreed that there should be a shorter way, I'm willing to write the code, but would need a little guidance as to where would be the appropriate place to put the code (New overload to parseAddress? New constructor for InternetAddress?) And... a similar issue for sockaddr_in6 and Internet6Address (although this one's easier since you don't need to deal with the endianness issue).
As discussed in DConf2015: Python-like keyword arguments
I might do a blog post on this, but here's some POC code:
import std.stdio;
import std.range;
import std.typetuple;
import std.traits;
import std.conv;
struct Foo { int i; }
struct Bar { int i; }
struct Baz { int i; }
void func(Foo foo, Bar bar, Baz baz) {
writeln("foo is ", foo);
writeln("bar is ", bar);
writeln("baz is ", baz);
}
auto getStrArgs(alias F, T...)() {
string[] strArgs;
foreach(i, ParamType; ParameterTypeTuple!F) {
enum index = staticIndexOf!(ParamType, T);
static if(index != -1) {
strArgs ~= "args[" ~ index.to!string ~ "]";
} else {
strArgs ~= ParamType.stringof ~ ".init";
}
}
return strArgs;
}
auto kwargs(alias F, T...)(T args) {
enum strArgs = getStrArgs!(F, T);
mixin("return F(" ~ strArgs.join(",") ~ ");");
}
void main() {
kwargs!func(Bar(2), Baz(3), Foo(1));
kwargs!func(Baz(3), Foo(1));
}
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 21:31:08 UTC, ponce wrote: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Video processing: **lack of x86 SIMD intrinsics** that actually work, specifically like the Intel ones. Assembly rarely get you the best available performance (cost of missed inlining, reordering, register spilling and man-mdade instruction scheduling hurt). Intrinsics with killer optimizing back-ends do. We have _some_ intrinsics but they are unusable right now and don't work on both 32-bit and 64-bit. Other than that, I can't think of nothing that is a blocker. Hopefully LLVM auto-vectorizer becomes so good that this point is not that blocking. most of this wouldn't be an issue if dmd backend didn't exist, both LDC and GDC expose GCC vector intrinsics.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Video processing: **lack of x86 SIMD intrinsics** that actually work, specifically like the Intel ones. Assembly rarely get you the best available performance (cost of missed inlining, reordering, register spilling and man-mdade instruction scheduling hurt). Intrinsics with killer optimizing back-ends do. We have _some_ intrinsics but they are unusable right now and don't work on both 32-bit and 64-bit. Other than that, I can't think of nothing that is a blocker. Hopefully LLVM auto-vectorizer becomes so good that this point is not that blocking. Audio processing: few blockers, @nogc tagged in all of Phobos where applicable would be nice, a way to do @nogc locks, OSX shared libraries with support for Mac idiosyncrasies. ARM support for future Mac if that happens. iOS support. 3D rendering: I can't see any blocker. Biggest hurdle is often existing C++ programmers and perceived problems :)
Re: DMD Symbol Reference Analysis Pass
On Thursday, 28 May 2015 at 21:23:59 UTC, Per Nordlöw wrote: On Thursday, 28 May 2015 at 20:54:59 UTC, Andrei Alexandrescu wrote: Cool! What are the incompatibilities keeping it from replacing byLine? -- Andrei Speed-up varies between 2.0 and 2.7 according to recent experiments done using new unittest at BTW: I'm sitting on a very recently bought (fast) laptop with a fast SSD.
Re: DMD Symbol Reference Analysis Pass
On Thursday, 28 May 2015 at 20:54:59 UTC, Andrei Alexandrescu wrote: Cool! What are the incompatibilities keeping it from replacing byLine? -- Andrei Speed-up varies between 2.0 and 2.7 according to recent experiments done using new unittest at https://github.com/nordlow/justd/blob/79cc8bf0766282368f05314d00566e7d234988bd/bylinefast.d#L207 which is currently deactivated. It has worked flawlessly in my applications, so none AFAIK. Note, that I'm not the original author, though, so credits should go to someone else. I've only made some tweaks regarding indentation, symbol naming, @safe, @trusted and changing separator type from dchar to string and probably some more I've forgotten about. BTW, Andrei, there's a new lazy range PR for Phobos on GitHub awaiting review... ;)
Re: DMD Symbol Reference Analysis Pass
On 5/28/15 2:05 PM, "Per =?UTF-8?B?Tm9yZGzDtnci?= " wrote: How faster is bylinefast compared to byline (after the recent improvements)? -- Andrei About 3 times in my measurements. Cool! What are the incompatibilities keeping it from replacing byLine? -- Andrei
Re: DIP78 - macros without syntax extensions
On Tuesday, 26 May 2015 at 20:23:11 UTC, Kagamin wrote: http://wiki.dlang.org/DIP78 - Proposal for a macro system without syntactical extensions to the language. Hence it doesn't allow arbitrary syntax. This is not even remotely enough to make a DIP. You seem to be using some API to build AST nodes, but this API is completely undefined. Generally, you don't want an API to create AST. Both the programmer and the compiler already know one: the language syntax itself.
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? We develop tailor made CRM/ERP solutions, mostly in C# or ASP.net. On the client side, it's obvious why I can't convince anyone to use D (lack of standard GUI, lack of i18n support, unavailability on WinRT/iOS/Android) On the server side, vibe.d cannot compete with asp.net (AD/SQL/Sharepoint/Office integration, Razor syntax, IDE integration, report generation). Therefore I took advantage of a situation we encountered - payroll calculation for a big client (>5 payrolls) took more than 6 hours to complete. So I tried to write some payroll calculation components in D. The main problems encountered were: - lack of a decimal data type - you cannot perform monetary calculation using floating point. - lack of a chinese or japanese calendar in the std.datetime module; - missing of overflow checks for integral data types;
Re: DMD Symbol Reference Analysis Pass
How faster is bylinefast compared to byline (after the recent improvements)? -- Andrei About 3 times in my measurements.
Re: DIP78 - macros without syntax extensions
On 2015-05-28 10:24, Kagamin wrote: Well, that's the point: it's a normal function. But it's not. -- /Jacob Carlborg
Re: Uphill
On Thu, 28 May 2015 08:55:57 +, Chris wrote: > On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: >> On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: >> >>> Only when I can sell D to customers that put money into this kind of >>> stuff >> >> if customers are deciding which technologies to use... ok then, they >> can do their work without my help, 'cause they are so knowledgeable. > > It's funny that people spend millions on technologies that makes > mediocre or crap languages better, but they would never invest in > something like D, because they dread the investment. I think it's > because D doesn't have a price tag attached to it. "If it's for free, it > must be sh*t", I often hear people say. Maybe we should have a D > Enterprise Edition (DEE) and sell it for $1,000. Believe me, people > would take to it like ducks take to water. a nice idea. "you don't want it for free? ok, we'll take your money if you want that." ;-) signature.asc Description: PGP signature
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Thu, 28 May 2015 12:39:52 +, Vladimir Panteleev wrote: > On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: >> SuperFastHash has known distribution problems[1]. > > BTW, something I noticed while browsing Rust docs today: > >> The hashes are all keyed by the thread-local random number generator on >> creation by default. This means that the ordering of the keys is >> randomized, but makes the tables more resistant to denial-of-service >> attacks (Hash DoS). > > http://doc.rust-lang.org/std/collections/struct.HashMap.html > > As I understand, D is certainly vulnerable to Hash DoS. yes. and the interesting thing is that `toHash()` accepts seed, but it's not used in other code. looks to me like low-hanging fruit. signature.asc Description: PGP signature
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Thu, 28 May 2015 12:02:44 +, Per Nordlöw wrote: > On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: >> SuperFastHash has known distribution problems[1]. there is fasthash[2] > > Is there an easy to tweak the default hashing of key type, say `K`, when > using a builtin D AA, say `V[K]`? nope. signature.asc Description: PGP signature
Re: Why aren't you using D at work?
"it's not enterprise-accepted. and there are no D programmers available on the market, think about you suddenly don't want to work anymore (which happens to me sometimes)." not that i really pushing, though, as i have personal reasons to not push hard (language warts). and we don't do many C/C++ code, so it's really not much to replace. signature.asc Description: PGP signature
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I often wonder if others share the importance of mobile cross-compilers? I wonder that sometimes too, considering it's only two people working on them. They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. I can't speak for Dan, who's been getting iOS working, but I just got Android/ARM running a week ago, so it's too early to put out builds. However, it wouldn't take much time to try out the Android/x86 support from source, since the build process is documented on the wiki: http://wiki.dlang.org/Build_DMD_for_Android Who maintains the CI solutions for the various compilers? How hard is it to add CI for the common cross-compilers and publish them? No idea. How many contributors does LDC have these days out of curiosity? Seems like 2-3 regulars. GDC could give Android, but all the other points depend on LLVM. GDC appears to have some support for Android, though it's not clear how much of phobos works: http://wiki.dlang.org/GDC/Installation/Android
Re: Why aren't you using D at work?
On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote: * Forceinline. Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei
Re: Why aren't you using D at work?
I've been fortunate enough to convince management to let me write D code. Up until now it's been mostly tools, but I recently rewrote some of our functionality in D and somehow my team was convinced that we can use the D server to test our client code, with them willing to learn D and modify my code. Atila On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Every place I work has a slightly different set of blockers. I have potential opportunity to involve D in my workplace in multiple key areas, but blockers exist along every path, as follows: Web: * We need NaCl + Emscripten support in LDC. Doesn't need to be comprehensive, just successfully compile code. Emscripten alone may satisfy; probably a much easier target. Core engine/applications: * Android+iOS. (plus also the web targets above in the future) Desktop utilities: * Workable Qt bindings. General friction/resistance from colleagues: * Forceinline. We have SO MUCH CODE that simply must inline. It's non-negotiable, nobody is comfortable to write ranges or properties without forceinline. I can't sell "just trust that the optimiser might maybe hopefully do what you want" to low-level engineers, I've been trying for years. * Debugging experience; it's come a long way, but there's still significant usability inhibitors. I often wonder if others share the importance of mobile cross-compilers? They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. Who maintains the CI solutions for the various compilers? How hard is it to add CI for the common cross-compilers and publish them? The interesting observation I make from that list above, is that barring Qt bindings, everything I list is a problem for LDC. It would seem to that LDC is the most important point of focus for my company at this time. How many contributors does LDC have these days out of curiosity? GDC could give Android, but all the other points depend on LLVM. The trick is getting something (anything) to shift to D in the office, giving other programmers some exposure, and give us a context to experiment with D in application to our particular workload; that is, realtime processing and rendering of geospatial data, an ideal workload for D in my mind! http://udserver.euclideon.com/demo (demo is NaCl + Emscripten, we'd love to have written it in D!)
Re: Why aren't you using D at work?
On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Every place I work has a slightly different set of blockers. I have potential opportunity to involve D in my workplace in multiple key areas, but blockers exist along every path, as follows: Web: * We need NaCl + Emscripten support in LDC. Doesn't need to be comprehensive, just successfully compile code. Emscripten alone may satisfy; probably a much easier target. Core engine/applications: * Android+iOS. (plus also the web targets above in the future) Desktop utilities: * Workable Qt bindings. General friction/resistance from colleagues: * Forceinline. We have SO MUCH CODE that simply must inline. It's non-negotiable, nobody is comfortable to write ranges or properties without forceinline. I can't sell "just trust that the optimiser might maybe hopefully do what you want" to low-level engineers, I've been trying for years. * Debugging experience; it's come a long way, but there's still significant usability inhibitors. I often wonder if others share the importance of mobile cross-compilers? They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. Who maintains the CI solutions for the various compilers? How hard is it to add CI for the common cross-compilers and publish them? The interesting observation I make from that list above, is that barring Qt bindings, everything I list is a problem for LDC. It would seem to that LDC is the most important point of focus for my company at this time. How many contributors does LDC have these days out of curiosity? GDC could give Android, but all the other points depend on LLVM. The trick is getting something (anything) to shift to D in the office, giving other programmers some exposure, and give us a context to experiment with D in application to our particular workload; that is, realtime processing and rendering of geospatial data, an ideal workload for D in my mind! http://udserver.euclideon.com/demo (demo is NaCl + Emscripten, we'd love to have written it in D!) Wait, you work for Euclideon?
Re: Why aren't you using D at work?
I'll soon need to port a 30KLOC server application to windows. It is roughly five years old and written in C using glib2. Parts of it are still version controlled in CVS and the build system is based on autotools. I am quite sure, that there won't be a running/maintainable windows version until we switch away from glib and autotools, but I doubt we will switch to D although there is no _technical_ reason not to.
Re: DMD Symbol Reference Analysis Pass
On 5/28/15 5:38 AM, "Per =?UTF-8?B?Tm9yZGzDtnci?= " wrote: On Wednesday, 27 May 2015 at 15:21:38 UTC, weaselcat wrote: I might be wrong, but I thought dip25 was only enabled in @safe annotated code? I updated bylinefast at https://github.com/nordlow/justd/blob/master/bylinefast.d#L188 How faster is bylinefast compared to byline (after the recent improvements)? -- Andrei
Why aren't you using D at work?
I've been using D in all my personal projects for years now, but I lament coding C at work every day, and I pine for salvation. I seem to have reasonable influence in my workplaces, and I suspect I could have my workplace adopt D, but when considering the notion with other staff, we always seem to encounter hard blockers to migration that stop us in our tracks. I expect I'm not alone. Please share the absolute blockers preventing you from adopting D in your offices. I wonder if there will be common themes emerge? Every place I work has a slightly different set of blockers. I have potential opportunity to involve D in my workplace in multiple key areas, but blockers exist along every path, as follows: Web: * We need NaCl + Emscripten support in LDC. Doesn't need to be comprehensive, just successfully compile code. Emscripten alone may satisfy; probably a much easier target. Core engine/applications: * Android+iOS. (plus also the web targets above in the future) Desktop utilities: * Workable Qt bindings. General friction/resistance from colleagues: * Forceinline. We have SO MUCH CODE that simply must inline. It's non-negotiable, nobody is comfortable to write ranges or properties without forceinline. I can't sell "just trust that the optimiser might maybe hopefully do what you want" to low-level engineers, I've been trying for years. * Debugging experience; it's come a long way, but there's still significant usability inhibitors. I often wonder if others share the importance of mobile cross-compilers? They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. Who maintains the CI solutions for the various compilers? How hard is it to add CI for the common cross-compilers and publish them? The interesting observation I make from that list above, is that barring Qt bindings, everything I list is a problem for LDC. It would seem to that LDC is the most important point of focus for my company at this time. How many contributors does LDC have these days out of curiosity? GDC could give Android, but all the other points depend on LLVM. The trick is getting something (anything) to shift to D in the office, giving other programmers some exposure, and give us a context to experiment with D in application to our particular workload; that is, realtime processing and rendering of geospatial data, an ideal workload for D in my mind! http://udserver.euclideon.com/demo (demo is NaCl + Emscripten, we'd love to have written it in D!)
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Thursday, 28 May 2015 at 12:40:07 UTC, Vladimir Panteleev wrote: As I understand, D is certainly vulnerable to Hash DoS. https://issues.dlang.org/show_bug.cgi?id=14414
Re: DIP78 - macros without syntax extensions
On 5/26/15 2:23 PM, Kagamin wrote: http://wiki.dlang.org/DIP78 - Proposal for a macro system without syntactical extensions to the language. Hence it doesn't allow arbitrary syntax. Quote from dconf W&A ask me anything: Q: "Will we get a macro system" Both Walter and Andrei: "no" Doesn't seem like much of a point for this proposal then. There didn't seem to be any wiggle room. -Steve
Re: smart pointer for interior pointers
On 5/27/15 9:13 PM, ketmar wrote: On Wed, 27 May 2015 17:31:32 -0600, Steven Schveighoffer wrote: But we can solve this with a postblit: seems that you forgot about "move" semantics for structs. under some conditions struct can be "moved", not "copied", so it `memcpy`ed and no postblit will be called. Right, that is a drawback of the first form. You have to ensure that doesn't happen (which is why we say struct interior pointers are illegal). The real proposal doesn't have that issue, and that's actually the point of it :) -Steve
Re: std.database
It seems std.database.sql not std.database. You can't build, for example, a mongodb driver over this. Maybe, but mongodb is a proprietary nosql interface rather than a standard one so I'm not sure that it should be in std. erik
Re: smart pointer for interior pointers
On 5/27/15 6:21 PM, Artur Skawina via Digitalmars-d wrote:
But with alias this, we can define a way to solve all these problems.
struct SPtr(T)
{
ptrdiff_t _offset;
void opAssign(T *orig) { _offset = cast(void *)orig - cast(void *)&this;}
inout(T) *_get() inout { return cast(inout(T)*)((cast(inout(void) *)&this)
+ _offset);}
alias _get this;
}
Basically, instead of storing the pointer, we store the offset to the struct
itself. This works as long as the SPtr instance stays co-located with its
target.
auto a = s.y;
// this 'a' now implicitly converts to 'int', but...
void g(T)(T a);
g(s.y); // ditto.
Yes, both your cases (including the one that I didn't quote) show that
such constructs must be controlled privately. For example, S should
really be written like this:
struct S
{
int x;
private SPtr!int _y;
int *y() {return _y;}
void y(int * newy) { _y = newy; }
}
And it gets kind of sticky from there if you wanted to replace an actual
variable :) For example, y++.
But you can get most of the abilities of a member and still not destroy
the semantic of having it reference the copy.
I actually need this in the project I'm writing, which I'm hoping to get
into Phobos, and I'm either going to define it in that project, or
define it in std.typecons. Maybe the best thing to do is to define it
privately for that module, and then move it somewhere more public if it
turns out to be something that's useful elsewhere.
-Steve
Re: std.database
Maybe make the database providers interfaces instead of
data+dispatch? You're allocating the stuff anyway.
Do you mean inheriting from interfaces like this?
class MysqlStatement : Statement {...}
I need deterministic resource management and I don't think
classes provide that. Using structs with RefCounted internals
seems ideal for this and it appears to be working well.
erik
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: SuperFastHash has known distribution problems[1]. BTW, something I noticed while browsing Rust docs today: The hashes are all keyed by the thread-local random number generator on creation by default. This means that the ordering of the keys is randomized, but makes the tables more resistant to denial-of-service attacks (Hash DoS). http://doc.rust-lang.org/std/collections/struct.HashMap.html As I understand, D is certainly vulnerable to Hash DoS.
Re: is there any reason to use SuperFastHash in druntime? (except speed)
On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote: SuperFastHash has known distribution problems[1]. there is fasthash[2] Is there an easy to tweak the default hashing of key type, say `K`, when using a builtin D AA, say `V[K]`?
Re: std.database
On Thursday, 28 May 2015 at 09:18:53 UTC, Sebastiaan Koppe wrote: That might be, but doing struct-table mappings will open a big can of worms, not to mention all the syntax opinions (optional and default values, table relationships, etc). Beter build layer by layer. In fact, Robert did layered abstraction+frontend design for std.log :)
Re: DMD Symbol Reference Analysis Pass
On Thursday, 28 May 2015 at 11:38:25 UTC, Per Nordlöw wrote: DMD (2.067 and git master) with -dip25 still doesn't complain about ... My guess is that this passes because the internal storage is GC-allocated. I'm sensing we need a new qualifier for this or that there is more logic to come in DMD regarding extensions to DIP-25...
Re: DMD Symbol Reference Analysis Pass
On Wednesday, 27 May 2015 at 15:21:38 UTC, weaselcat wrote: I might be wrong, but I thought dip25 was only enabled in @safe annotated code? I updated bylinefast at https://github.com/nordlow/justd/blob/master/bylinefast.d#L188 to make the unittest @safe and members of @trusted. DMD (2.067 and git master) with -dip25 still doesn't complain about https://github.com/nordlow/justd/blob/master/bylinefast.d#L198 nor https://github.com/nordlow/justd/blob/master/bylinefast.d#L203 ...
Re: Uphill
On Thursday, 28 May 2015 at 09:23:07 UTC, Rikki Cattermole wrote: On 28/05/2015 8:55 p.m., Chris wrote: On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: Only when I can sell D to customers that put money into this kind of stuff if customers are deciding which technologies to use... ok then, they can do their work without my help, 'cause they are so knowledgeable. It's funny that people spend millions on technologies that makes mediocre or crap languages better, but they would never invest in something like D, because they dread the investment. I think it's because D doesn't have a price tag attached to it. "If it's for free, it must be sh*t", I often hear people say. Maybe we should have a D Enterprise Edition (DEE) and sell it for $1,000. Believe me, people would take to it like ducks take to water. Or we put together a D consultancy firm, perhaps as part of D's future foundation? Starting at e.g. bug fixes ext. with price tag ranges on them. Perhaps even a price tag on working on DIP's. Charge them and they will come! :-)
Exhaustive unit tests
I'm referring to this bug/enhancement request:
https://issues.dlang.org/show_bug.cgi?id=14615
I checked the unit test(s) for it (see below), and found that
they only check for the positive case, i.e. that a substitution
takes place, not for the case that no substitution takes place.
The bug referred to above would have been spotted by testing for
a mismatch.
Exactly this kind of optimistic unit testing has happened to me
too. The problem is the "gold standard phenomenon". If you test
your program against a gold standard, you tend to focus only on
this standard and think that everything is all right, once you
meet all the criteria of the standard. However, you forget to
test for deviating, non-standard behavior. I wonder how much of
this is still in Phobos. I'm sure someone has opened a ticket /
PR or something on this, haven't they?
The problem here is that you probably wouldn't have spotted the
flaw in the unit test by running "-unittest -cov". For
replaceFirst yes (although not obvious)
|public R replaceFirst(R, C, RegEx)(R input, RegEx re,
const(C)[] format)
|if(isSomeString!R && is(C : dchar) &&
isRegexFor!(RegEx, R))
|{
36|return replaceFirstWith!((m, sink) =>
replaceFmt(format, m, sink))(input, re);
|}
|// a general skeleton of replaceFirst
|private R replaceFirstWith(alias output, R, RegEx)(R
input, RegEx re)
|if(isSomeString!R && isRegexFor!(RegEx, R))
|{
25|auto data = matchFirst(input, re);
25|if(data.empty)
000|return input; // <== Not tested for
25|auto app = appender!(R)();
25|replaceCapturesInto!output(app, input, data);
25|return app.data;
|}
but not for replaceFirstInto
public @trusted void replaceFirstInto(Sink, R, C, RegEx)
|(ref Sink sink, R input, RegEx re, const(C)[]
format)
|if(isOutputRange!(Sink, dchar) && isSomeString!R
|&& is(C : dchar) && isRegexFor!(RegEx, R))
|{
39|replaceCapturesInto!((m, sink) => replaceFmt(format,
m, sink))
|(sink, input, matchFirst(input, re));
|}
|
|///ditto
|public @trusted void replaceFirstInto(alias fun, Sink, R,
RegEx)
|(Sink sink, R input, RegEx re)
|if(isOutputRange!(Sink, dchar) && isSomeString!R &&
isRegexFor!(RegEx, R))
|{
1|replaceCapturesInto!fun(sink, input,
matchFirst(input, re));
|}
|// the lowest level - just stuff replacements into the
sink
|private @trusted void replaceCapturesInto(alias output,
Sink, R, T)
|(ref Sink sink, R input, T captures)
|if(isOutputRange!(Sink, dchar) && isSomeString!R)
|{
39|sink.put(captures.pre);
|// a hack to get around bogus errors, should be
simply output(captures, sink)
|// "is a nested function and cannot be accessed from"
|static if(isReplaceFunctor!(output, R))
1|sink.put(output(captures)); //"mutator" type of
function
|else
38|output(captures, sink); //"output" type of
function
39|sink.put(captures.post);
|}
package.d is 88% covered
Unit test in std/regex/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L1127
See also:
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L1266
Re: std.database
On Thursday, 28 May 2015 at 04:57:55 UTC, Robert burner Schadek
wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement("insert into table values(?,?)");
stmt.execute("a",1);
stmt.execute("b",2);
stmt.execute("c",3);
struct Table;
Table a, b, c;
con.insert!Table(a);
...
if you use CTFE to create the statement string there is no
reason to reuse it.
it will be string literal, that's even better! Think Big. Think
D
the other code is Java not D
That might be, but doing struct-table mappings will open a big
can of worms, not to mention all the syntax opinions (optional
and default values, table relationships, etc). Beter build layer
by layer.
Besides, some people dont believe the orm hype, and would be
happy to build their own query generation layer on top of a
low-level sql library, not one tainted with ctfe and template
mixins.
Re: Uphill
On 28/05/2015 8:55 p.m., Chris wrote: On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: Only when I can sell D to customers that put money into this kind of stuff if customers are deciding which technologies to use... ok then, they can do their work without my help, 'cause they are so knowledgeable. It's funny that people spend millions on technologies that makes mediocre or crap languages better, but they would never invest in something like D, because they dread the investment. I think it's because D doesn't have a price tag attached to it. "If it's for free, it must be sh*t", I often hear people say. Maybe we should have a D Enterprise Edition (DEE) and sell it for $1,000. Believe me, people would take to it like ducks take to water. Or we put together a D consultancy firm, perhaps as part of D's future foundation? Starting at e.g. bug fixes ext. with price tag ranges on them. Perhaps even a price tag on working on DIP's.
Re: Uphill
On Wednesday, 27 May 2015 at 19:35:35 UTC, ketmar wrote: On Wed, 27 May 2015 13:23:16 +, Paulo Pinto wrote: Only when I can sell D to customers that put money into this kind of stuff if customers are deciding which technologies to use... ok then, they can do their work without my help, 'cause they are so knowledgeable. It's funny that people spend millions on technologies that makes mediocre or crap languages better, but they would never invest in something like D, because they dread the investment. I think it's because D doesn't have a price tag attached to it. "If it's for free, it must be sh*t", I often hear people say. Maybe we should have a D Enterprise Edition (DEE) and sell it for $1,000. Believe me, people would take to it like ducks take to water.
Re: DIP78 - macros without syntax extensions
On Thursday, 28 May 2015 at 06:39:11 UTC, Jacob Carlborg wrote:
Auto myAssert(Auto condition, Auto message)
{
return message;
}
Not so easy to tell that "myAssert" is a macro declaration just
by looking in the module "bar".
Well, that's the point: it's a normal function.
Re: std.database
It seems std.database.sql not std.database. You can't build, for example, a mongodb driver over this. On Thursday, 28 May 2015 at 02:04:31 UTC, Erik Smith wrote: I'm working on a standards grade interface & implementation for database clients in D. It defines a common interface (the implicit kind) and allows for both native and polymorphic drivers. A key feature is a range interface to query results. Here's the project page with the design highlights and examples of usage: https://github.com/cruisercoder/ddb The implementation is in the early stages and only a few things work, but I'm planning to include sqlite, mysql, Oracle, and ODBC reference implementations. I could use some feedback on the basic approach I'm taking and to help ensure that I'm not doing something horribly wrong with my basic D skills. erik
Re: DIP78 - macros without syntax extensions
On Wednesday, 27 May 2015 at 17:03:30 UTC, Artur Skawina wrote:
That already works. Eg:
alias deduceType(Args...) = typeof({
// some complex imperative code to deduce the type from
the args
import std.range;
return
mixin(iota(Args.length).map!q{`Args[`~text(a)~']'}().join("+"));
}());
struct Foo(T...) {
deduceType!(T) value;
}
static assert(is(typeof(Foo!(short, ubyte,
bool).value)==int));
What all these proposals seem to be about is:
a) better introspection (ie exposing a (preferably simplified
and std) AST)
b) AST injection
c) "better" syntax
d) better "optimizations", meaning skipping the emission of
code and data
that is never used at runtime.
artur
Maybe extending capabilities of templates would be a better
direction. They already accept aliases which are essentially
simple hygienic identifier expressions.
Re: std.database
On Thursday, 28 May 2015 at 02:04:31 UTC, Erik Smith wrote: https://github.com/cruisercoder/ddb Maybe make the database providers interfaces instead of data+dispatch? You're allocating the stuff anyway.
Re: std.database
On Thursday, 28 May 2015 at 05:12:34 UTC, Vadim Lopatin wrote:
On Thursday, 28 May 2015 at 05:00:30 UTC, Rikki Cattermole
wrote:
On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement("insert into table values(?,?)");
stmt.execute("a",1);
stmt.execute("b",2);
stmt.execute("c",3);
struct Table;
Table a, b, c;
con.insert!Table(a);
...
if you use CTFE to create the statement string there is no
reason to
reuse it.
it will be string literal, that's even better! Think Big.
Think D
the other code is Java not D
Then you open up table names, property serialization ext. ext.
Please no.
That is an ORM's job. I'm saying this from experience.
Similar project: DDBC https://github.com/buggins/ddbc
Inspired by Java JDBC API.
Currently supports MySQL, PostreSQL, SQLite.
Some time ago I tried a similar thing (not to build a library but
rather to learn D a bit), however I never had time to finish it.
A brief sample of the interface for my Result object:
1. Result's structure not known in advance
// execute simple query using connection c and assign results to r
auto r = c.execute("SELECT int_column, string_column FROM
Table;");
// output column names
writeln(r.names[0], "\t", r.names[1]);
// iterate thru result and output values for each row
for (; !r.empty; r.popFront()) {
writeln(r.front[0], "\t", r.front[1]);
}
2. Result's structure known in advance
// define Sample_Record struct (struct data types must conform to
column types from query)
struct Sample_Record {
int i;
string s;
}
// execute simple query using connection c and assign results to r
auto r = c.execute("SELECT int_column, string_column FROM
Table;");
// assign results to sample_record struct
auto sample_record = r.getRecord!(Sample_Record);
// output sample_record struct values
writeln(sample_record.i, "\t", sample_record.s);
