D2 port of Tango
I just wanted to get the word out about a little project me and a few other people been working on for the few past months, in case anyone feels like helping out (or just as an FYI). This project is the D2 port of the Tango framework library. You can read about it here: https://github.com/SiegeLord/Tango-D2 We are currently a little more than half way done in terms of modules fiddled with. Currently there are 181 modules ported out of approximately 343 (give or take 20). Currently only the dmd compiler and Linux platform are supported... but obviously we want to get all the other platforms/compilers as time goes on. I'm guessing at the current rate of porting we'll be done in about half a year. Now, the project is actually two projects in one. The first project is a D2 port proper that tries to keep API semantics the same as the D1 original. I preside over this aspect, and you can see the rough porting guidelines in the repository. This is the 'd2port' branch in my repository. The second project is a more ambitious effort to rewrite some aspects of Tango without preserving semantics or anything. mtachrono presides over this aspect, so you can talk to him about the motivations behind it. This is the 'master' branch in my repository. That's all. Cheers. -SiegeLord
Re: The CAPI Manifesto
On 10/16/2011 9:28 PM, Jude Young wrote: Please excuse my ignorance, but several types in D do not currently translate well into C. For example, strings in D are not '\0' terminated, which breaks with C. This is incorrect. String literals in D are 0 terminated, as in C. C has a convention that strings are 0 terminated, but it isn't part of the core language. In D, you can terminate a string with 0 if you want to, or not. This is not usually a problem, and it's easy to wrap the function in the translated header file to automate that particular process. This would fall under attempting to fix the api, which would be beyond the scope of the library. It seems that your proposal would disallow this particular example. The translation code would have to be somewhere, what is the argument against allowing it? D access to the C API should be direct, and not include hidden costs like translation layers. In my (admittedly ignorant) opinion, it seems that allowing the automatic translation of D types to C types would fit very well, otherwise you'll have to add them yourself every time you wish to call C. C doesn't actually even have a 'string' type.
Re: dmd.conf change for Ubuntu 11.10
On 10/15/2011 08:03 AM, Trass3r wrote: Am 14.10.2011, 22:05 Uhr, schrieb Justin Whear jus...@economicmodeling.com: Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent linker errors referencing librt. -L-lphobos2 needs to be added to DFLAGS before -L-lrt. I spent a long time trying to figure the problem out before I realized that gcc was tacking on a -lphobos2 to the END of the command (after the -lrt flag). This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may explain the behavior, I'm not sure. That page is about Natty though, i.e. 11.04. Strangely I used 11.04 for quite some time and didn't experience any problems. Yeah, I noticed that, too - I'm on 11.04 again, and I can compile fine now. No page like that exists for Oneiric that I can find, so it's definitely worth more looking in to.
Re: The CAPI Manifesto
On 10/16/2011 10:24 PM, Gor Gyolchanyan wrote: I think there might be a few tricks to improve the C API without adding any new code. For example, replace by-pointer parameter declarations with _out_ parameters when applicable (the underlying function signature is the same), replace const parameters with in parameters, etc. This won't change the C API a single bit (won't even add new code), but will vastly improve readability and sometimes safety of the API. In other cases, some minor additions could be made, for example: libjpeg provides API to register error handlers, instead of setting errno and such. Those kind of situations could be used to throw exceptions. It only takes a static this() and a few lines of code. In case those kind of modifications/additions are made, there could be a standard way to disable them and use the original version. If you want to add a layer on top of the C API, that would be fine. std.zlib is an example of that. But the idea of CAPI is NOT to add a layer. Not fix, extend, refactor, improve, etc. Just the thinnest possible direct calls to the C API. Any improvements, fixes, whatever, should be a separate project. I know the urge to do these fixes can be overpowering, but they end badly every time. It's like trying to mix the language's lexer up with the semantic analysis :-) They really are better off being separate and distinct. For one thing, it makes the inevitable maintenance *FAR* easier, as those C APIs will change. Updating the corresponding D module becomes simple then - just a line by line comparison and tweaking. There would be no tearing of hair and rending of garments. For another it means you'll have to regenerate the C documentation, but with all the changes you made. Then, as the C guys improve their documentation, your layer falls behind, gets neglected, and finally sucks in comparison.
Re: The CAPI Manifesto
On Mon, 17 Oct 2011 08:24:26 +0300, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: For example, replace by-pointer parameter declarations with _out_ parameters when applicable (the underlying function signature is the same) Note that this would make it nearly impossible to pass null pointers. A human would need to decide if a null pointer can be specified, or the converter would need to be aware of proprietary extensions which specify such things (e.g. Microsoft's __in). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: The CAPI Manifesto
On 10/16/2011 11:21 PM, Vladimir Panteleev wrote: On Mon, 17 Oct 2011 08:24:26 +0300, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: For example, replace by-pointer parameter declarations with _out_ parameters when applicable (the underlying function signature is the same) Note that this would make it nearly impossible to pass null pointers. A human would need to decide if a null pointer can be specified, or the converter would need to be aware of proprietary extensions which specify such things (e.g. Microsoft's __in). Right. You could also annotate C API functions with pure, @safe, etc., but you'd have to be very careful that those functions actually were that way, and would not violate those attributes in the future.
Re: The CAPI Manifesto
Fair enough, thanks for the time. I found a thin D binding to ncurses, and 'fixed' it to work with D2. If y'all get this up and running, this code will probably be better than starting from scratch. In any case, I think that CAPI is exactly the type of thing that D needs going forward. I really hope that CAPI gets good support. On Mon, Oct 17, 2011 at 12:55 AM, Walter Bright newshou...@digitalmars.comwrote: On 10/16/2011 9:28 PM, Jude Young wrote: Please excuse my ignorance, but several types in D do not currently translate well into C. For example, strings in D are not '\0' terminated, which breaks with C. This is incorrect. String literals in D are 0 terminated, as in C. C has a convention that strings are 0 terminated, but it isn't part of the core language. In D, you can terminate a string with 0 if you want to, or not. This is not usually a problem, and it's easy to wrap the function in the translated header file to automate that particular process. This would fall under attempting to fix the api, which would be beyond the scope of the library. It seems that your proposal would disallow this particular example. The translation code would have to be somewhere, what is the argument against allowing it? D access to the C API should be direct, and not include hidden costs like translation layers. In my (admittedly ignorant) opinion, it seems that allowing the automatic translation of D types to C types would fit very well, otherwise you'll have to add them yourself every time you wish to call C. C doesn't actually even have a 'string' type.
Re: User packages/libs (Was: Just starting out)
On 2011-10-16 18:46, Russel Winder wrote: On Sat, 2011-10-15 at 13:24 +0200, Jacob Carlborg wrote: [ . . . ] I'm working on a package manger for D: Do the D packages like being stored in a manger? ;-) Hehe maybe. -- /Jacob Carlborg
Re: The CAPI Manifesto
On 2011-10-17 04:18, Ary Manzana wrote: On 10/16/11 11:02 PM, Walter Bright wrote: Brad and I were talking about some D code that needed openssl support, when we ran into the same old problem: No D files corresponding to the openssl C .h files. It's not that these are a big problem to create, it's just that they are not done, and it tends to turn off people from using D. D is binary API compatible with C, but only with a corresponding D import file. This, out of the box, makes D *harder* to use than C. Lots of people roll their own, but that work is hard to find and haphazard. This problem keeps coming up again and again. So I propose creating, on github.com/D-Programming-Language, a new repository called CAPI. So you would put every interface to every possible C code there? In Ruby if you want to have very efficient code you'd implement it as C extensions. For that, you create wrappers in Ruby for C. Now, big part of the standard library has extensions for the most needed things. Everything else, like bindings to an efficient xml parser, are made by different people that public them as gems. Having a public gem repository it's really easy to find bindings for whatever you want. They don't need to be part of the standard library. And it wouldn't make sense, having so much functionality out there available as C code. So I'd suggest having D headers for the most common things in phobos and focusing on a tool like rubygems. It would give such a big boost to the language. I also can't imagine how that big repository would work. You'd copy the remote file locally? What if that file gets fixes? You'd copy it again? Or maybe you'd git checkout everything from that repository locally and synchronize it from time to time, with the chance of breaking existing code... Having gems and versioning them should make all these problems disappear. Maybe there is an openssl header in D. The problem is that there might be many, and they don't know each other, and google is a maze to find such things. Already working on a package manager for D: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D https://github.com/jacob-carlborg/orbit/ -- /Jacob Carlborg
Re: The CAPI Manifesto
On 2011-10-17 04:02, Walter Bright wrote: Brad and I were talking about some D code that needed openssl support, when we ran into the same old problem: No D files corresponding to the openssl C .h files. It's not that these are a big problem to create, it's just that they are not done, and it tends to turn off people from using D. D is binary API compatible with C, but only with a corresponding D import file. This, out of the box, makes D *harder* to use than C. I'm working on a Clang based tool for automatically converting C header files to D modules. -- /Jacob Carlborg
Re: Catching a hot potato
If you overwrite your own memory (even partially), that's a bug of equal severity as the segfault. In fact, it's a much worse bug, since segfault is easy to miss and a silent memory overwrite is arguably one of the hardest things to catch. That's why things like contracts, invariants and unittests exist: to ensure correct logic. Both the contracts and the sigsegv handler would do the same thing: kick the DLL (or .so) out of the address space and go on doing anything else, that still works (and prevent that DLL from being loaded again, perhaps). The worst thing, that could happen is, when the bad DLL overwrote somethig in another (good) DLL. In which case the bad DLL would be unloaded due to sigsegv handler and the good DLL would be unloaded due to an invariant failure. Even if they are the only ones and the entire app basically crashed, the difference is, that this way i can know for sure, who's fault was the crash and the good DLL (despite it's invariant failure) will be loaded next time (as opposed to the bad one). Taking good measures about a DLL with a faulty logic is better, then just crashing completely without any idea why it happened. The point is, that if a given app would support third-party extensions as DLLs (for maximal performance), it shouldn't compromise the stability of the app. On Mon, Oct 17, 2011 at 9:37 AM, Andrew Wiley wiley.andre...@gmail.com wrote: On Sun, Oct 16, 2011 at 11:54 PM, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: If the user tries to read unallocated memory, the memory can't possibly get corrupted, since nothing is getting changed. If the user tried to write to unallocated memory, the segfault should _prevent_ it by throwing an OS-level exception (the sigsegv). Throwing if _after_ the invalid write makes no sense. You can't save anything, because your own data is not touched. Depending on the implementation, either some other process's memory would be touched or nothing at all (internally unmapped region). I think the rumors of corrupted memory after sigsegv is boloney. Otherwise the whole sigsegv idea is pointless (you could just as well get terminated right away). The problem is that there's no guarantee that you *only* wrote outside your allocated virtual memory. You could have a bad pointer, overwrite half your program's data, then hit an invalid address and segfault. There are many scenarios in which bad writes *don't* cause segfaults (they may be incorrect, but they're still legal), so you can't really assume much about your program's state when you segfault.
Re: The CAPI Manifesto
That sounds good. Now D projects will have a mother and a father. Phobos is the mother, which is always there for you and is the first one you'll go to if you need help :-) Diemos is the father, which is the backbone of your software family, who you rely on to do all the hard work for you. :-) It's generally a good idea to separate our own code from an external one, which we provide support for. And if the remote modules proposal gets implemented, there would be no problems with using Diemos if it won't get included in DMD package. On Mon, Oct 17, 2011 at 7:55 AM, Walter Bright newshou...@digitalmars.com wrote: On 10/16/2011 8:17 PM, Vladimir Panteleev wrote: I think the name's fine. I don't see 4-letter word is already taken as a valid argument, considering the huge number of users. There's a GitHub user called phobos and one called tools, etc. Also, I'm pretty sure the D standard library is named after Mars's moon, considering that D was originally named Mars Programming Language (after the company name, Digital Mars). I thought maybe Diemos.
Re: The CAPI Manifesto
Unless CAPI is trademarked, I think we're in good shape. when i hear of CAPI i instantly think of this: http://www.capi.org/pages/home.php
Re: The CAPI Manifesto
Yeah. Diemos is much better, IMO. On Mon, Oct 17, 2011 at 12:30 PM, Mirko Pilger pil...@cymotec.de wrote: Unless CAPI is trademarked, I think we're in good shape. when i hear of CAPI i instantly think of this: http://www.capi.org/pages/home.php
Gsoc Mentor summit
Are there ideas on what it would be worth bringing/presenting at the Goggle Summer of Code Mentor Summit (aside obviously my experience with it)? Any good D-connected (or maybe not) topic, or open source relevant topic... Well I will have to present that, so if I think that I cannot do it, I might drop a good topic. Anyway if someone has good ideas (and I suppose some will come up during the conference itself), please tell. I will also try to give a feedback here about it. ciao Fawzi
Re: The CAPI Manifesto
On Oct 16, 2011, at 7:02 PM, Walter Bright wrote: The CAPI Manifesto -- CAPI is a collection of C header files to publicly available C libraries and their translations to D. The idea is that if, in C, to interface to a library one would write: #include foo.h then the corresponding D code would look like: import foo; If the C header file has a name that is a D keyword, an underscore will be appended to the D module name. If a C type name matches a C function name (stat), the type name will have a _t appended. There's also the occasional issue of something that doesn't translate into D. As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like $2003 that are the versions which should be called on newer versions of the OS. I'm still not sure of the best way to handle this, since D doesn't have macros.
To share or not to share, this is the question.
The shared keyword makes it's user regret ever trying to use it.
This keyword has a single purpose: it generates frustration at compile-time.
Enough with the emotions.
I'm trying to make a Win32 multi-threaded warpper, which allows to
efficiently create Win32 windows, that immediately start processing
their messages in a separate thread (which will eventually get
migrated into a thread pool).
As i was trying to deal with the shared-ness, i found out about this:
shared class T
{
alias void* v;
static assert(is(v == shared));
}
this fails the static assert. I don't see any point of this. Why on
earth would one want a non-shared nested type in a shared class?
By far the most frustrating thing about this is the fact, that the
supposedly great std.concurrency.spawn function is completely useless,
because it fails it's no local aliases assert, when i pass _this_ in
the function, which is of a shared class type.
This happends only when that class has a HWND member. If i replace the
HWND with an int, it starts working.
My second question is: why the deuce isn't HWND member shared too
inside my class?
I'm sorry for the language. It's just that _shared_ keyword is doing
it's job very nicely: it generates a compile-time frustration REALLY
big, REALLY fast.
Also, it seems, that DMD isn't aware, that any extern(C) automatically
implies _gshared parameters for functions and members for structs,
which would automatically remove all problems with shared-ness in C
code. This is even more frustrating because now i need to cast
everything to non-shared.
Re: Lion-compatibilty emergency release,
On Oct 16, 2011, at 8:00 AM, Heywood Floyd wrote: Sean Kelly Wrote: On Aug 3, 2011, at 8:06 AM, David Nadlinger wrote: As you might know, the current druntime release contains a GC bug which causes hard to track down crashes due to premature garbage collection in combination with the OS X Lion ASLR Is this fix alone sufficient for the test suite to pass on Lion? I blew away my Lion partition a while back and haven't had a chance to re-create and test. Is this still the case in D2.055? Dare I upgrade to Lion yet? (Is there perhaps a bug I can vote for or something?) It should be fine. The OSX box used by the D Auto-Tester runs Lion.
Re: To share or not to share, this is the question.
Gor Gyolchanyan Wrote: My second question is: why the deuce isn't HWND member shared too inside my class? It should not be shared. And you shouldn't ever pass HWND across threads.
Re: To share or not to share, this is the question.
The point is not in the HWND itself, but in the fact, that a shared class has a non-shared member. Isn't shared supposed to be transitive? On Mon, Oct 17, 2011 at 2:55 PM, Kagamin s...@here.lot wrote: Gor Gyolchanyan Wrote: My second question is: why the deuce isn't HWND member shared too inside my class? It should not be shared. And you shouldn't ever pass HWND across threads.
Re: The CAPI Manifesto
Am 17.10.2011, 10:20 Uhr, schrieb Gor Gyolchanyan gor.f.gyolchan...@gmail.com: That sounds good. Now D projects will have a mother and a father. Phobos is the mother, which is always there for you and is the first one you'll go to if you need help :-) Diemos is the father, which is the backbone of your software family, who you rely on to do all the hard work for you. :-) It's generally a good idea to separate our own code from an external one, which we provide support for. And if the remote modules proposal gets implemented, there would be no problems with using Diemos if it won't get included in DMD package. On Mon, Oct 17, 2011 at 7:55 AM, Walter Bright newshou...@digitalmars.com wrote: On 10/16/2011 8:17 PM, Vladimir Panteleev wrote: I think the name's fine. I don't see 4-letter word is already taken as a valid argument, considering the huge number of users. There's a GitHub user called phobos and one called tools, etc. Also, I'm pretty sure the D standard library is named after Mars's moon, considering that D was originally named Mars Programming Language (after the company name, Digital Mars). I thought maybe Diemos. Deimos, people, its Deimos .
Re: The CAPI Manifesto
I'm working on a Clang based tool for automatically converting C header files to D modules. Great! Does it work yet?
Re: To share or not to share, this is the question.
Gor Gyolchanyan Wrote: The point is not in the HWND itself, but in the fact, that a shared class has a non-shared member. Isn't shared supposed to be transitive? It's transitive for data. Alias is not data.
Re: The CAPI Manifesto
On 2011-10-17 13:27, Steve Teale wrote: I'm working on a Clang based tool for automatically converting C header files to D modules. Great! Does it work yet? Well, yes. Some parts of it. I have mostly focused on converting Objective-C headers. I have also started to rewrite the tool to use libclang instead of embed it straight into clang. https://github.com/jacob-carlborg/clang https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: etc.curl
2011/10/16 simendsjo simend...@gmail.com On 17.10.2011 02:28, Brad Roberts wrote: What's the state of etc.curl? Where is it in the review queue? Thanks, Brad And as a side note: Is anyone using it on Windows? DMD doesn't ship with the necessary libraries, and I cannot find the correct version of zlib to use with the versions of libcurl I've tried. I've been using it on Windows for a long time. I think what I used is the zip package containing libcurl and the correct version of zlib for Win32 - Generic on this page: http://curl.haxx.se/download.html
Re: The CAPI Manifesto
On 2011-10-17 10:21:45 +, Sean Kelly s...@invisibleduck.org said: On Oct 16, 2011, at 7:02 PM, Walter Bright wrote: The CAPI Manifesto -- CAPI is a collection of C header files to publicly available C libraries and their translations to D. The idea is that if, in C, to interface to a library one would write: #include foo.h then the corresponding D code would look like: import foo; If the C header file has a name that is a D keyword, an underscore will be appended to the D module name. If a C type name matches a C function name (stat), the type name will have a _t appended. Hum, but _t in C stands for typedef. Wouldn't it be better to just append an underscore like for module names, that'd make only one rule to remember. There's also the occasional issue of something that doesn't translate into D. As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like $2003 that are the versions which should be called on newer versions of the OS. I'm still not sure of the best way to handle this, since D doesn't have macros. I think what D needs to handle that is some pragma to manually specify the mangled name of a given function. Why would you need macros? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: To share or not to share, this is the question.
I don't get it. HWND is an alias for void*. void* is data. what do you mean, alias is not data? On Mon, Oct 17, 2011 at 3:50 PM, Kagamin s...@here.lot wrote: Gor Gyolchanyan Wrote: The point is not in the HWND itself, but in the fact, that a shared class has a non-shared member. Isn't shared supposed to be transitive? It's transitive for data. Alias is not data.
Re: eating inout dogfood
On Fri, 14 Oct 2011 20:21:59 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-10-14 20:05:09 +, Steven Schveighoffer
schvei...@yahoo.com said:
I don't think the compiler will auto-convert someTemplate!(inout(V)) to
e.g. someTemplate!(const(V)). Does that work? I know that for
instance, I can't do this:
struct S(T)
{
T * x;
}
S!(int) ptr;
S!(const(int)) cptr = ptr;
So I wouldn't expect the compiler to do the above translation either...
Perhaps you can add this to the struct:
void this(U)(in S!U other) if (__traits(compiles, this.x = other.x))
{
this.x = other.x;
}
If that works, maybe a similar approach could be used to solve the
problem with inout: if you can construct the requested type from the
provided one it get converted automatically at the call site.
This looks promising. However, I seem to recall D specifically
disallowing implicit conversion using a constructor...
Is this going to fly with Walter?
-Steve
Re: immutable range
On Sun, 16 Oct 2011 07:37:03 -0400, kenji hara k.hara...@gmail.com wrote:
I got an idea.
import std.range;
template isImmutableInputRange(R)
{
enum bool isImmutableInputRange = is(typeof(
{
R r;// can define a range object
if (r.empty) {} // can test for empty
auto r2 = r.nextFront(); // can invoke nextFront()
auto h = r2.front; // can get the front of the range
}));
}
template isImmutableForwardRange(R)
{
enum bool isImmutableForwardRange = isImmutableInputRange!R
is(typeof(
{
R r1;
R r2 = r1.save; // can call save against a range object
}));
}
template isImmutableBidirectionalRange(R)
{
enum bool isImmutableBidirectionalRange = isImmutableForwardRange!R
is(typeof(R.init.back()) == typeof(R.init.front()))
is(typeof({ R r; auto r2 = r.nextBack(); }));
}
void immutableForeach(R, E)(R r, scope void delegate(E) dg)
if (isImmutableInputRange!R is(ElementType!R : E))
{
if (r.empty)
return;
dg(r.front);
immutableForeach(r.nextFront(), dg);// tail recursion
}
void immutableForeachReverse(R, E)(R r, scope void delegate(E) dg)
if (isImmutableBidirectionalRange!R is(ElementType!R : E))
{
if (r.empty)
return;
dg(r.back);
immutableForeachReverse(r.nextBack(), dg); // tail recursion
}
const struct Range
{
int[] arr;
@property int front() const { return arr[0]; }
@property bool empty() const { return arr.length 0; }
const(Range) nextFront() const { return Range(arr[1..$]); }
const(Range) save() const { return this; }
@property int back() const { return arr[$-1]; }
const(Range) nextBack() { return Range(arr[0..$-1]); }
}
static assert(isImmutableInputRange!Range);
static assert(isImmutableForwardRange!Range);
static assert(isImmutableBidirectionalRange!Range);
void main()
{
const r = Range([1,2,3]);
int i = 0;
immutableForeach(r, (int v)
{
assert(v == ++i);
});
int j = 3;
immutableForeachReverse(r, (int v)
{
assert(v == j--);
});
}
Kenji Hara
I don't think this scales well. Not only are you introducing a new type
of range, you are introducing a new *class* of range. One which does not
work with any existing algorithms.
The solution must be compatible with all the existing range functions
(which do not modify data), or it doesn't work.
-Steve
Re: dmd.conf change for Ubuntu 11.10
On Mon, 17 Oct 2011 01:56:47 -0400, Matt Soucy mso...@csh.rit.edu wrote: On 10/15/2011 08:03 AM, Trass3r wrote: Am 14.10.2011, 22:05 Uhr, schrieb Justin Whear jus...@economicmodeling.com: Changes to gcc or ld in Ubuntu 11.10 require a small addition to prevent linker errors referencing librt. -L-lphobos2 needs to be added to DFLAGS before -L-lrt. I spent a long time trying to figure the problem out before I realized that gcc was tacking on a -lphobos2 to the END of the command (after the -lrt flag). This page: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition may explain the behavior, I'm not sure. That page is about Natty though, i.e. 11.04. Strangely I used 11.04 for quite some time and didn't experience any problems. Yeah, I noticed that, too - I'm on 11.04 again, and I can compile fine now. No page like that exists for Oneiric that I can find, so it's definitely worth more looking in to. http://d.puremagic.com/issues/show_bug.cgi?id=6822 Just ran into this today after upgrading last week. -Steve
Re: To share or not to share, this is the question.
On 17.10.2011 14:24, Gor Gyolchanyan wrote:
The shared keyword makes it's user regret ever trying to use it.
This keyword has a single purpose: it generates frustration at compile-time.
Enough with the emotions.
I'm trying to make a Win32 multi-threaded warpper, which allows to
efficiently create Win32 windows, that immediately start processing
their messages in a separate thread (which will eventually get
migrated into a thread pool).
As i was trying to deal with the shared-ness, i found out about this:
shared class T
{
alias void* v;
I guess the problem is here: v is void * and not shared at all. Alias is
not affected by outer shared decl, shared applies only to members:
fields and functions. In a sense, an alias is merely using the same name
scope.
Imagine if you semantics (i.e. shared affects aliases) worked, then how
would you declare a *not* shared type alias inside of it ?
This won't work:
alias Unqual!(void*) v;
--
Dmitry Olshansky
Re: Catching a hot potato
On Sat, 15 Oct 2011 08:18:59 -0400, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: Thanks for the detailed answer. Example of when i would like to recover from a segfault: I have different independent parts of an app, which MAY cooperate. If, however, one of them crashes (e.g. they come from different sources) the other one will continue to work but without the cooperation functionality. A segfault means something has attempted reading/writing to a memory location that was not allocated. Note that this does *not* necessarily mean dereferencing null. The worst case scenario is that something has invalidly written to *allocated* memory before your program reads from/writes to unallocated memory. Usually this is a result of the usage of the now-corrupted allocated memory. For instance, a module that caused the segfault might *not* be the module which misbehaved! It could have been a rogue third module which corrupted the memory in the segfaulting module. Closing the segfaulting module does no good. Catching a segfault and continuing the program is a very bad idea. You have no idea what valid memory was corrupted before the segfault occurred, or who did it. The only logical thing to do is exit the program, maybe attempting to print a stack trace (which might fail if the stack is corrupt). -Steve
Re: Catching a hot potato
On Mon, 17 Oct 2011 00:54:31 -0400, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: If the user tries to read unallocated memory, the memory can't possibly get corrupted, since nothing is getting changed. If the user tried to write to unallocated memory, the segfault should _prevent_ it by throwing an OS-level exception (the sigsegv). Throwing if _after_ the invalid write makes no sense. You can't save anything, because your own data is not touched. Depending on the implementation, either some other process's memory would be touched or nothing at all (internally unmapped region). I think the rumors of corrupted memory after sigsegv is boloney. Otherwise the whole sigsegv idea is pointless (you could just as well get terminated right away). sigsegv is often the *symptom*, not the *cause* of corrupted memory. Of course sigsegv cannot corrupt memory. But corrupted memory often makes a segv occur (and quite often not anywhere near where the real problem is). It's why memory corruption is the *worst* bug to deal with. Your best bet is to close the application, and possibly print a stack trace. Trying to continue is like continuing to drive when you get a flat tire. You are just going to keep damaging your car! -Steve
Re: To share or not to share, this is the question.
Ok, but if i declared a member of type v it should be shared, right?
since i'd essentially declare it to be void*, which gets the enclosing
class's shared attribute.
This is what i did for a class, that contains a HWND member. But the
std.concurrency.spawn function flipped me off and said, that i'm not
supposed to send over an object with unshared aliases.
What's the logic behind this? the HWND should be shared.
I know, i already found out, that HWND is strictly single-threaded,
but the point here is to understand why does the spawn function think
it's unshared.
On Mon, Oct 17, 2011 at 4:45 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
On 17.10.2011 14:24, Gor Gyolchanyan wrote:
The shared keyword makes it's user regret ever trying to use it.
This keyword has a single purpose: it generates frustration at
compile-time.
Enough with the emotions.
I'm trying to make a Win32 multi-threaded warpper, which allows to
efficiently create Win32 windows, that immediately start processing
their messages in a separate thread (which will eventually get
migrated into a thread pool).
As i was trying to deal with the shared-ness, i found out about this:
shared class T
{
alias void* v;
I guess the problem is here: v is void * and not shared at all. Alias is not
affected by outer shared decl, shared applies only to members: fields and
functions. In a sense, an alias is merely using the same name scope.
Imagine if you semantics (i.e. shared affects aliases) worked, then how
would you declare a *not* shared type alias inside of it ?
This won't work:
alias Unqual!(void*) v;
--
Dmitry Olshansky
Re: Catching a hot potato
On Sun, 16 Oct 2011 12:49:22 -0400, Norbert Nemec norb...@nemec-online.de wrote: In fact, I have been wondering about the very same issue. Indeed, it seems to be possible to catch SIGSEGV in userspace, there even is a library for this http://libsigsegv.sourceforge.net/ I have never used it myself, but it would certainly be interesting to hear about any experience you might make. Note that this is intended to allow user space page-fault handling. A segmentation fault means memory that is not allocated is written to. The underlying cause is actually a hardware page fault, which cues the OS to handle it. Many times, it's handled by the OS simply loading the missing page from swap, and you never get the segv signal. If the OS isn't aware of the memory being valid, it issues a SEGV signal to the process. The libsigsegv is for doing funky things like loading pages from a database or something that the OS does not support. It's not for handling seg faults due to memory corruption. -Steve
Re: Catching a hot potato
I see. That's what i said: overwritten allocated memory is the hardest-to-find bug. But you've shown me, that i can't possibly track down the misbehaving module by catching a sigsegv. There has to be a way to make thrid-party DLL usage safe and rid the user from dunno-why crashes. The user at least needs to know which DLL to throw away. Any ideas how it could be achieved? On Mon, Oct 17, 2011 at 4:54 PM, Steven Schveighoffer schvei...@yahoo.com wrote: On Mon, 17 Oct 2011 00:54:31 -0400, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: If the user tries to read unallocated memory, the memory can't possibly get corrupted, since nothing is getting changed. If the user tried to write to unallocated memory, the segfault should _prevent_ it by throwing an OS-level exception (the sigsegv). Throwing if _after_ the invalid write makes no sense. You can't save anything, because your own data is not touched. Depending on the implementation, either some other process's memory would be touched or nothing at all (internally unmapped region). I think the rumors of corrupted memory after sigsegv is boloney. Otherwise the whole sigsegv idea is pointless (you could just as well get terminated right away). sigsegv is often the *symptom*, not the *cause* of corrupted memory. Of course sigsegv cannot corrupt memory. But corrupted memory often makes a segv occur (and quite often not anywhere near where the real problem is). It's why memory corruption is the *worst* bug to deal with. Your best bet is to close the application, and possibly print a stack trace. Trying to continue is like continuing to drive when you get a flat tire. You are just going to keep damaging your car! -Steve
Re: eating inout dogfood
On 2011-10-17 12:26:17 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Fri, 14 Oct 2011 20:21:59 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Perhaps you can add this to the struct:
void this(U)(in S!U other) if (__traits(compiles, this.x = other.x))
{
this.x = other.x;
}
If that works, maybe a similar approach could be used to solve the
problem with inout: if you can construct the requested type from the
provided one it get converted automatically at the call site.
This looks promising. However, I seem to recall D specifically
disallowing implicit conversion using a constructor...
Is this going to fly with Walter?
For some reason I couldn't make it work with the constraint, but this
works fine with the current compiler:
struct S(T)
{
this(U)(in S!U other)
{
this.x = other.x;
}
T * x;
}
void main()
{
S!(int) ptr;
S!(const(int)) cptr = ptr;
}
Whether it's intended or not I don't know. Ask Walter.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: To share or not to share, this is the question.
Kagamin Wrote: Gor Gyolchanyan Wrote: My second question is: why the deuce isn't HWND member shared too inside my class? It should not be shared. And you shouldn't ever pass HWND across threads. Huh, well, looks like HWND can be shared, see e.g. PostMessage function http://msdn.microsoft.com/en-us/library/ms644944%28VS.85%29.aspx but it seems there's quite restricted set of functions which can deal with a shared handle.
Re: Lion-compatibilty emergency release,
Sean Kelly Wrote: It should be fine. The OSX box used by the D Auto-Tester runs Lion. Wonderful! Thanks! /HF
Re: The CAPI Manifesto
On 2011-10-17 14:01, Michel Fortin wrote: On 2011-10-17 10:21:45 +, Sean Kelly s...@invisibleduck.org said: On Oct 16, 2011, at 7:02 PM, Walter Bright wrote: The CAPI Manifesto -- CAPI is a collection of C header files to publicly available C libraries and their translations to D. The idea is that if, in C, to interface to a library one would write: #include foo.h then the corresponding D code would look like: import foo; If the C header file has a name that is a D keyword, an underscore will be appended to the D module name. If a C type name matches a C function name (stat), the type name will have a _t appended. Hum, but _t in C stands for typedef. Wouldn't it be better to just append an underscore like for module names, that'd make only one rule to remember. There's also the occasional issue of something that doesn't translate into D. As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like $2003 that are the versions which should be called on newer versions of the OS. I'm still not sure of the best way to handle this, since D doesn't have macros. I think what D needs to handle that is some pragma to manually specify the mangled name of a given function. Why would you need macros? Perhaps the macro is used to determine if foo or foo$2003 is supposed to be called, based on some condition. -- /Jacob Carlborg
Re: [std.database]
On Sun, 16 Oct 2011 02:13:05 -0400, Steve Teale steve.te...@britseyeview.com wrote: There's a discussion going on about Windows header files that has discussed whether header files can be copyright. Header files may be an issue with the database implementations. For example my mysql.d is a straight translation of mysql.h (and a couple of others). Does that mean it is tainted by GPL and I can't make it Boost? A direct translation is a derivative work. So yes, it must be GPL. However, there must be ways around this. I believe headers have certain rules in most licenses. You will definitely need some sort of non-translated header though. I'm not a license expert, so I don't know to what lengths you need to go to re-license the header. However, what about mysql itself? If the header is GPL, so is the library, no? I'm assuming you are not reimplementing the mysql client lib? Linking against a GPL library is definitely not going to be acceptable in a phobos module. -Steve
Re: Catching a hot potato
On Mon, 17 Oct 2011 09:04:06 -0400, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: I see. That's what i said: overwritten allocated memory is the hardest-to-find bug. But you've shown me, that i can't possibly track down the misbehaving module by catching a sigsegv. There has to be a way to make thrid-party DLL usage safe and rid the user from dunno-why crashes. The user at least needs to know which DLL to throw away. Any ideas how it could be achieved? No. How do you know which DLL is the culprit? As others have said, some modern browsers have eschewed the DLL model for a process-based one in order to prevent crashes of the whole application. My suggestion would be to create some sort of IPC via shared memory/semaphores. That should be quite fast, and then the damage is only limited to shared memory. -Steve
Re: Catching a hot potato
Good point. I guess IPC optimizations can bring it to the level of ultra-fast separate-process extension mechanism. On Mon, Oct 17, 2011 at 5:50 PM, Steven Schveighoffer schvei...@yahoo.com wrote: On Mon, 17 Oct 2011 09:04:06 -0400, Gor Gyolchanyan gor.f.gyolchan...@gmail.com wrote: I see. That's what i said: overwritten allocated memory is the hardest-to-find bug. But you've shown me, that i can't possibly track down the misbehaving module by catching a sigsegv. There has to be a way to make thrid-party DLL usage safe and rid the user from dunno-why crashes. The user at least needs to know which DLL to throw away. Any ideas how it could be achieved? No. How do you know which DLL is the culprit? As others have said, some modern browsers have eschewed the DLL model for a process-based one in order to prevent crashes of the whole application. My suggestion would be to create some sort of IPC via shared memory/semaphores. That should be quite fast, and then the damage is only limited to shared memory. -Steve
Re: The CAPI Manifesto
Michel Fortin michel.for...@michelf.com wrote in message news:j7h5gp$2d7n$1...@digitalmars.com... I think what D needs to handle that is some pragma to manually specify the mangled name of a given function. Why would you need macros? I've got a patch to do this, in the pragma_mangle branch of my fork. One day I'll get around to fixing it up and making a pull request.
Re: [std.database]
On Mon, 17 Oct 2011 09:42:13 -0400, Steven Schveighoffer wrote: On Sun, 16 Oct 2011 02:13:05 -0400, Steve Teale steve.te...@britseyeview.com wrote: There's a discussion going on about Windows header files that has discussed whether header files can be copyright. Header files may be an issue with the database implementations. For example my mysql.d is a straight translation of mysql.h (and a couple of others). Does that mean it is tainted by GPL and I can't make it Boost? A direct translation is a derivative work. So yes, it must be GPL. However, there must be ways around this. I believe headers have certain rules in most licenses. You will definitely need some sort of non-translated header though. I'm not a license expert, so I don't know to what lengths you need to go to re-license the header. However, what about mysql itself? If the header is GPL, so is the library, no? I'm assuming you are not reimplementing the mysql client lib? Linking against a GPL library is definitely not going to be acceptable in a phobos module. -Steve Hmm, I just did a quick check, and the MySQL client/server protocol is GPL also, so there's nowhere to go. How do Python and PHP communicate with MySQL. Is it just that they have the clout to get a dispensation from MySQL AB? Does this stuff have to go in some repository like the proposed Deimos (a figure representing dread in Greek Mythology) where you will presumably often encounter dread licensing gotchas? Steve
Re: The CAPI Manifesto
On 2011-10-17 13:41:14 +, Jacob Carlborg d...@me.com said: On 2011-10-17 14:01, Michel Fortin wrote: On 2011-10-17 10:21:45 +, Sean Kelly s...@invisibleduck.org said: There's also the occasional issue of something that doesn't translate into D. As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like $2003 that are the versions which should be called on newer versions of the OS. I'm still not sure of the best way to handle this, since D doesn't have macros. I think what D needs to handle that is some pragma to manually specify the mangled name of a given function. Why would you need macros? Perhaps the macro is used to determine if foo or foo$2003 is supposed to be called, based on some condition. Indeed. The condition is which OS release you're targeting. That can be accomplished today through static ifs. Although it'd be a little more verbose since you'd have to repeat the function prototype. If we had a way to do conditional attributes in D it'd be awesome for this use case. It could work this way for instance: static if (MAC_OS_X_VERSION_MIN_REQUIRED == 10.5) @deprecated_in_os_x_10_5 = deprecated; else @deprecated_in_os_x_10_5 = /* nothing */; @deprecated_in_os_x_10_5 void some_function_deprecated_in_os_x_10_5(); Or this way for the special mangled names: static if (MAC_OS_X_VERSION_MIN_REQUIRED == 10.5) @darwin_alias(name) = pragma(symbol_name, name ~ $UNIX2003); else @darwin_alias(name) = pragma(symbol_name, name); @darwin_alias(fwrite) size_t fwrite(const void * /*__restrict*/, size_t, size_t, FILE * /*__restrict*/); Internally, when the compiler sees @darwin_alias(fwrite) it just replaces it with the attributes @darwin_alias was supposed to be. Note that I'm *not* proposing a macro system: this would work at the semantic level as a special kind of attribute. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: [std.database]
Steve Teale Wrote: Hmm, I just did a quick check, and the MySQL client/server protocol is GPL also, so there's nowhere to go. That was fixed. How do Python and PHP communicate with MySQL. Is it just that they have the clout to get a dispensation from MySQL AB? MySQL license has FLOSS exception: opensource software can use MySQL, but not *relicense* its code. http://mysql.com/about/legal/licensing/foss-exception/ Though boost is not in the list.
Re: [std.database]
On Mon, 17 Oct 2011 10:25:13 -0400, Steve Teale steve.te...@britseyeview.com wrote: On Mon, 17 Oct 2011 09:42:13 -0400, Steven Schveighoffer wrote: On Sun, 16 Oct 2011 02:13:05 -0400, Steve Teale steve.te...@britseyeview.com wrote: There's a discussion going on about Windows header files that has discussed whether header files can be copyright. Header files may be an issue with the database implementations. For example my mysql.d is a straight translation of mysql.h (and a couple of others). Does that mean it is tainted by GPL and I can't make it Boost? A direct translation is a derivative work. So yes, it must be GPL. However, there must be ways around this. I believe headers have certain rules in most licenses. You will definitely need some sort of non-translated header though. I'm not a license expert, so I don't know to what lengths you need to go to re-license the header. However, what about mysql itself? If the header is GPL, so is the library, no? I'm assuming you are not reimplementing the mysql client lib? Linking against a GPL library is definitely not going to be acceptable in a phobos module. -Steve Hmm, I just did a quick check, and the MySQL client/server protocol is GPL also, so there's nowhere to go. Protocol cannot be copyrighted. A protocol is carefully formatted data, but not *MySQL's* data, it's *your* data. If they want to attempt to say my passing select name, bar, gobbledegook from myPrivateDatabase to a server makes my code GPL, be my guest, I don't even think I'd need a lawyer to defend that :) Here is a good post discussing it: http://krow.livejournal.com/684068.html?thread=2670116 But the library can be copyrighted (and the protocol description). Given mysql's sales model (and the company behind it), you would need a very meticulously documented process to clean-room implement it in a way that could be defended, and even then Walter may not go for inclusion in phobos, he is allergic to even the *notion* that something might be challenged in court being in D/phobos. How do Python and PHP communicate with MySQL. Is it just that they have the clout to get a dispensation from MySQL AB? little searching reveals: http://www.mysql.com/about/legal/licensing/foss-exception/ Note PHP and Python are both in the license list, whereas Boost is not :( Does this stuff have to go in some repository like the proposed Deimos (a figure representing dread in Greek Mythology) where you will presumably often encounter dread licensing gotchas? I'd imagine so. Another option is to reimplement libmysql. Sorry :( -Steve
Re: Selective and renamed imports
Timon Gehr wrote:
Does
public import foo : bar;
work as expected with your pull request?
Yes. But it doesn't merge the symbol either, so if foo.bar is a function
a.d --
public import foo : bar;
void bar() {}
b.d --
import a;
// will only see the bar defined in a.d.
Maybe public selective imports should actually behave the same way as
aliases? Alternatively it could be an error: 'bar' hides publicly imported
symbol of the same name
Re: [std.database]
A direct translation is a derivative work. So yes, it must be GPL. However, there must be ways around this. I believe headers have certain rules in most licenses. Steve, do you think this provides any relief http://www.mysql.com/about/legal/licensing/foss-exception/ Steve
Re: [std.database]
On Mon, 17 Oct 2011 10:56:45 -0400, Kagamin s...@here.lot wrote: Steve Teale Wrote: Hmm, I just did a quick check, and the MySQL client/server protocol is GPL also, so there's nowhere to go. That was fixed. That is good news! do you have a supporting link? Or is it something that quietly went away? -Steve
Re: [std.database]
Steve Teale Wrote: There's a discussion going on about Windows header files that has discussed whether header files can be copyright. Header files may be an issue with the database implementations. For example my mysql.d is a straight translation of mysql.h (and a couple of others). Does that mean it is tainted by GPL and I can't make it Boost? You can't license mysql.d under terms of boost, you can ask Oracle to include boost into the foss exception list and license mysql.d under terms of mysql foss exception, but first you should ask Walter whether he wants code under terms of foss exception in phobos.
Re: [std.database]
On Mon, 17 Oct 2011 11:00:13 -0400, Steve Teale steve.te...@britseyeview.com wrote: A direct translation is a derivative work. So yes, it must be GPL. However, there must be ways around this. I believe headers have certain rules in most licenses. Steve, do you think this provides any relief http://www.mysql.com/about/legal/licensing/foss-exception/ I know our messages crossed paths probably, but for completeness, no, I don't think this allows relief. Boost is not listed as an allowed exception. But this doesn't matter anyways. The *end product*, not phobos, must be licensed free and open source under the boost license. This is an important distinction. This means, effectively, even if boost was included on the list, and we put mysql client bindings in phobos, in order to ship with mysql client library the user of phobos would have to license *their* product under boost! Even if they didn't ship the source for their application, anyone who obtained the application source through any means would be free to copy it at will. This limitation is too severe for inclusion in the core library of a language such as D, which might be used in closed-source settings. Note that php and python are somewhat open-source anyways since they are interpreted, and commonly you do not need to distribute the source of your server-side code for it to be used. -Steve
Re: [std.database]
On Mon, 17 Oct 2011 11:11:37 -0400, Kagamin s...@here.lot wrote: Steven Schveighoffer Wrote: That is good news! do you have a supporting link? Or is it something that quietly went away? http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocoldiff=5078oldid=4374 I have shown this to a guy who was going to reimplement a mysql client based on those docs. That is good! Since 2007, huh I'm surprised I could find no discussion on this, it seems like it would be a big deal for those who wanted to reimplement mysql clients. -Steve
Re: [std.database]
Kagamin wrote: Steven Schveighoffer Wrote: That is good news! do you have a supporting link? Or is it something that quietly went away? http://forge.mysql.com/w/index.php?title=MySQL_Internals_ClientServer_Protocoldiff=5078oldid=4374 I have shown this to a guy who was going to reimplement a mysql client based on those docs. You probably meant me. If we create MySQL client without using C bindings then we would have one of the fastest bindings at all. It may attract some people who write web apps to D. The same applies to PostgreSQL for which I wrote client without using a C binding. I know it adds some maintaining effort but we may choose opportunistic approach. Use direct access where possible and fallback to C lib otherwise. Another argument for using direct access is easy deployment of applications, especially when client resides in the std library.
Re: [std.database]
Steven Schveighoffer Wrote: That is good! Since 2007, huh I'm surprised I could find no discussion on this http://krow.livejournal.com/684068.html?thread=2674468#t2674468
Re: [std.database]
Steve Teale Wrote: Header files may be an issue with the database implementations. For example my mysql.d is a straight translation of mysql.h (and a couple of others). Does that mean it is tainted by GPL and I can't make it Boost? As an alternative why not make ODBC bindings? This way you'll be able to use virtually any database. ODBC is the most important database binding.
Re: [std.database]
On Mon, 17 Oct 2011 11:37:43 -0400, Kagamin s...@here.lot wrote: Steven Schveighoffer Wrote: That is good! Since 2007, huh I'm surprised I could find no discussion on this http://krow.livejournal.com/684068.html?thread=2674468#t2674468 Yes, I saw that. But that is hardly discussion in the community. :) In any case, it's good that it's gone. I'm all for a d-based mysql protocol implementation, and it looks like the only legal option anyways (if you want it in phobos, that is). -Steve
Re: [std.database]
On 17.10.2011 17:26, Piotr Szturmaj wrote: You probably meant me. If we create MySQL client without using C bindings then we would have one of the fastest bindings at all. It may attract some people who write web apps to D. The same applies to PostgreSQL for which I wrote client without using a C binding. Why would a reimplementation be much faster? Is the C library slow? Or is there any overhead I'm not thinking of?
Re: [std.database]
On Mon, 17 Oct 2011 11:40:44 -0400, Kagamin wrote: Steve Teale Wrote: Header files may be an issue with the database implementations. For example my mysql.d is a straight translation of mysql.h (and a couple of others). Does that mean it is tainted by GPL and I can't make it Boost? As an alternative why not make ODBC bindings? This way you'll be able to use virtually any database. ODBC is the most important database binding. We are/were heading down the road of having ODBC as one of the options, but what's the status of its header files I wonder? But it sounds to me as if Walter's CAPI concept should be expanded to have three directories - C headers, equivalent D interfaces, and derived works. Steve
Re: [std.database]
simendsjo wrote: On 17.10.2011 17:26, Piotr Szturmaj wrote: You probably meant me. If we create MySQL client without using C bindings then we would have one of the fastest bindings at all. It may attract some people who write web apps to D. The same applies to PostgreSQL for which I wrote client without using a C binding. Why would a reimplementation be much faster? Is the C library slow? Or is there any overhead I'm not thinking of? There is always a function call overhead and also most of the fields are returned as strings, whereas in underlying protocol they are encoded binary, i.e. int is not sent as its decimal string representation but as 4 bytes. This saves some time taken by string to int conversion (parsing).
Re: [std.database]
On 17.10.2011 17:55, Piotr Szturmaj wrote: simendsjo wrote: On 17.10.2011 17:26, Piotr Szturmaj wrote: You probably meant me. If we create MySQL client without using C bindings then we would have one of the fastest bindings at all. It may attract some people who write web apps to D. The same applies to PostgreSQL for which I wrote client without using a C binding. Why would a reimplementation be much faster? Is the C library slow? Or is there any overhead I'm not thinking of? There is always a function call overhead and also most of the fields are returned as strings, whereas in underlying protocol they are encoded binary, i.e. int is not sent as its decimal string representation but as 4 bytes. This saves some time taken by string to int conversion (parsing). I see. I've looked a bit at the C library, and it seems the protocol isn't very stable. Trying to support older MySQL versions and keep up with protocol changes might be (too) tedious.
Re: [std.database]
simendsjo wrote: On 17.10.2011 17:55, Piotr Szturmaj wrote: simendsjo wrote: On 17.10.2011 17:26, Piotr Szturmaj wrote: You probably meant me. If we create MySQL client without using C bindings then we would have one of the fastest bindings at all. It may attract some people who write web apps to D. The same applies to PostgreSQL for which I wrote client without using a C binding. Why would a reimplementation be much faster? Is the C library slow? Or is there any overhead I'm not thinking of? There is always a function call overhead and also most of the fields are returned as strings, whereas in underlying protocol they are encoded binary, i.e. int is not sent as its decimal string representation but as 4 bytes. This saves some time taken by string to int conversion (parsing). I see. I've looked a bit at the C library, and it seems the protocol isn't very stable. Trying to support older MySQL versions and keep up with protocol changes might be (too) tedious. PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones.
Re: [std.database]
PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. Steve
Re: [std.database]
On 17.10.2011 18:16, Piotr Szturmaj wrote: simendsjo wrote: On 17.10.2011 17:55, Piotr Szturmaj wrote: simendsjo wrote: On 17.10.2011 17:26, Piotr Szturmaj wrote: You probably meant me. If we create MySQL client without using C bindings then we would have one of the fastest bindings at all. It may attract some people who write web apps to D. The same applies to PostgreSQL for which I wrote client without using a C binding. Why would a reimplementation be much faster? Is the C library slow? Or is there any overhead I'm not thinking of? There is always a function call overhead and also most of the fields are returned as strings, whereas in underlying protocol they are encoded binary, i.e. int is not sent as its decimal string representation but as 4 bytes. This saves some time taken by string to int conversion (parsing). I see. I've looked a bit at the C library, and it seems the protocol isn't very stable. Trying to support older MySQL versions and keep up with protocol changes might be (too) tedious. PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. Since 2003? That's pretty impressive! About MySql: The reason D is missing a lot of wrappers and libraries is the lack of manpower. This duplicated effort sounds like too much job at the current time. I think more people will flock to D once modules such as database and web-programming exists, and then more focus can go into optimizing.
Re: The CAPI Manifesto
Well then my vote goes for let's do it. Simple bindings can be started right away, probably by copying from dsource bindings and doing any modifications necessary. For non-trivial C headers we can discuss them here methinks.
Re: [std.database]
As an alternative why not make ODBC bindings? This way you'll be able to use virtually any database. ODBC is the most important database binding. I can't find any definitive source for the ODBC header files. I've seen various versions that seem to make conflicting copyright claims or to have conflicting license statements. Does anyone have what might be considered to be a definitive version of these? Steve
Re: [std.database] at compile time
Sure, here it is: http://pastebin.com/KSyuk8HN
Usage would be something like:
import std.stdio;
import ccb.io.automap_table;
mixin( MapTables!(import(school_system.sql), true) );
void main()
{
Student a = new Student;
a.student_name = John Smith;
a.term = 1;
writeln(a.student_name, , , a.term);
students.insert(new Student());
students.commit();
}
The sql file can be generated like so:
$ mysqldump -d -h dbhost -u username -p password database_name
Note that it's super hacky, literally written on the spur of the moment. I
have a much cleaner, more robust version, but it currently sends the
compiler into an infinite loop and I haven't touched it in a couple months.
Justin
Am 14.10.2011 22:29, schrieb Justin Whear:
This is actually possible now. I wrote a little CTFE parser for CREATE
TABLE... statements, used mysql to dump a db, then used import() to
include the dump and parse it at compile-time. I was actually using it to
generate classes which mapped to the contents of each table (i.e. a
things table would result in a Thing class which mapped the fields as
properties). Obviously you need to keep the db dump up to date via an
external tool.
Cool! Hesitate to share the code?
Re: The CAPI Manifesto
I like it! :)
Re: Catching a hot potato
On 17.10.2011 14:54, Steven Schveighoffer wrote: Your best bet is to close the application, and possibly print a stack trace. Trying to continue is like continuing to drive when you get a flat tire. You are just going to keep damaging your car! To stick with this nice analogy: Trying to recover fully from a segfault is indeed like continuing to ride with a flat tire. Bad idea! Accepting the system default segfault handling is like abandoning the whole valuable truckload just because of a flat tire. Not such a good idea either. Sure, an emergency save may fail because of the memory corruption, but there is a very good chance that it still works because the essential data structures happen to be unaffected.
Re: Catching a hot potato
Am 17.10.2011, 15:04 Uhr, schrieb Gor Gyolchanyan gor.f.gyolchan...@gmail.com: I see. That's what i said: overwritten allocated memory is the hardest-to-find bug. But you've shown me, that i can't possibly track down the misbehaving module by catching a sigsegv. There has to be a way to make thrid-party DLL usage safe and rid the user from dunno-why crashes. The user at least needs to know which DLL to throw away. Any ideas how it could be achieved? You can't possibly track down the module? Not with a 100% hit rate of course - you'd need to separate the memory for that. But if you want to go with hacks, I think the following could work for you in most cases, assuming you trust your main application to not send invalid data to your modules: Look at the stack in your sigsegv handler. Assign the return addresses to locations inside the loaded libraries and print a list of all 'involved' code modules at the point of the seg fault. If you only call into a single library at a time (no callbacks) you only need to look at the top of the stack. Parse /proc/self/smaps for example, to know what memory range belongs to which module. Crazy enough?
Re: Catching a hot potato
On Mon, 17 Oct 2011 13:21:39 -0400, Norbert Nemec norb...@nemec-online.de wrote: On 17.10.2011 14:54, Steven Schveighoffer wrote: Your best bet is to close the application, and possibly print a stack trace. Trying to continue is like continuing to drive when you get a flat tire. You are just going to keep damaging your car! To stick with this nice analogy: Trying to recover fully from a segfault is indeed like continuing to ride with a flat tire. Bad idea! Accepting the system default segfault handling is like abandoning the whole valuable truckload just because of a flat tire. Not such a good idea either. Oh, well, that's up to the application design. I once designed a system backed by a database that could be restarted and using the data in the database could pick up exactly where it left off. You could call this the AAA of application recovery :) In many cases, the valuable truckload of an application is quickly and easily recreated. Sure, an emergency save may fail because of the memory corruption, but there is a very good chance that it still works because the essential data structures happen to be unaffected. Or there's a chance it saves corrupted data, and screws your entire database, or whatever. It all depends on the situation. Is it recommended not to catch segfaults? Definitely. Should you ever do it? Maybe, but don't rely on the resulting data for mission critical applications. The only reason I can see to continue is to try and debug the issue, not to continue running the program. You're better off designing your application to recover via restarting. -Steve
Re: [std.database]
Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale steve.te...@britseyeview.com: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. Steve Do people not upgrade their database to MySQL 5? I never had to deal with that and especially large complicated databases. If it is easy to upgrade to MySQL 5 and it is faster and more secure there are probably few *actively developed* projects accessing MySQL 4 DBs. (MySQL 5 is pretty much exactly 6 years old now.)
Re: [std.database]
On Monday, October 17, 2011 09:38 Steve Teale wrote: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. However, if we go with an appropriately pluggable approach with the DB engines, then it should be perfectly possible to have a 3rd party library which provides a DB engine for mysql which you can then use with Phobos if your program is GPL or GPL-compatible. So, no it won't be in Phobos if we have to use the C headers, but that doesn't necssarily mean that it couldn't be used with Phobos' DB solution. - Jonathan M Davis
Re: [std.database]
Am 17.10.2011, 19:46 Uhr, schrieb Marco Leise marco.le...@gmx.de: Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale steve.te...@britseyeview.com: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. Steve Do people not upgrade their database to MySQL 5? I never had to deal with that and especially large complicated databases. If it is easy to upgrade to MySQL 5 and it is faster and more secure there are probably few *actively developed* projects accessing MySQL 4 DBs. (MySQL 5 is pretty much exactly 6 years old now.) I found this: http://www.gentoo.org/doc/en/mysql-upgrading.xml#doc_chap1 Leaving away the safety net it looks like a call to mysql_upgrade_shell is all that's needed in the general case.
Re: Catching a hot potato
Am 17.10.2011, 19:35 Uhr, schrieb Steven Schveighoffer schvei...@yahoo.com: On Mon, 17 Oct 2011 13:21:39 -0400, Norbert Nemec norb...@nemec-online.de wrote: On 17.10.2011 14:54, Steven Schveighoffer wrote: Your best bet is to close the application, and possibly print a stack trace. Trying to continue is like continuing to drive when you get a flat tire. You are just going to keep damaging your car! To stick with this nice analogy: Trying to recover fully from a segfault is indeed like continuing to ride with a flat tire. Bad idea! Accepting the system default segfault handling is like abandoning the whole valuable truckload just because of a flat tire. Not such a good idea either. Oh, well, that's up to the application design. I once designed a system backed by a database that could be restarted and using the data in the database could pick up exactly where it left off. You could call this the AAA of application recovery :) In many cases, the valuable truckload of an application is quickly and easily recreated. Sure, an emergency save may fail because of the memory corruption, but there is a very good chance that it still works because the essential data structures happen to be unaffected. Or there's a chance it saves corrupted data, and screws your entire database, or whatever. It all depends on the situation. Is it recommended not to catch segfaults? Definitely. Should you ever do it? Maybe, but don't rely on the resulting data for mission critical applications. The only reason I can see to continue is to try and debug the issue, not to continue running the program. You're better off designing your application to recover via restarting. -Steve If an application tends to crash (like a few versions of Delphi did), an auto-save feature will help. If you lose between 1-10 minutes of work at a maximum you can probably live with that. I don't think it is a shame if the application crashes when it is heavily plugin based. You just need to accept and consider that in the application design. OpenOffice has auto-save, Eclipse can restore previous installation states (i.e. before installing a plugin) etc.
Re: The CAPI Manifesto
+1 Let's do it!
Re: [std.database]
On 17.10.2011 19:46, Marco Leise wrote: Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale steve.te...@britseyeview.com: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. Steve Do people not upgrade their database to MySQL 5? I never had to deal with that and especially large complicated databases. If it is easy to upgrade to MySQL 5 and it is faster and more secure there are probably few *actively developed* projects accessing MySQL 4 DBs. (MySQL 5 is pretty much exactly 6 years old now.) You'll always find people not upgrading technology for various reasons. We continue to use MySQL 4 at work for an internal legacy application because it just works and we _know_ upgrading will be a lot of work. And see how IE6 is still in use. I'm not advocating that D should strive to support legacy technologies though. I don't think Win98 or earlier are supported either.
Re: [std.database]
On 2011-10-17 19:55, Jonathan M Davis wrote: On Monday, October 17, 2011 09:38 Steve Teale wrote: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. However, if we go with an appropriately pluggable approach with the DB engines, then it should be perfectly possible to have a 3rd party library which provides a DB engine for mysql which you can then use with Phobos if your program is GPL or GPL-compatible. So, no it won't be in Phobos if we have to use the C headers, but that doesn't necssarily mean that it couldn't be used with Phobos' DB solution. - Jonathan M Davis I think that the Phobos database API needs to support database drivers written by third part users, that can be easily plugged in, for exactly the above mentioned reason. -- /Jacob Carlborg
Re: [std.database]
On Monday, October 17, 2011 11:07 simendsjo wrote: On 17.10.2011 19:46, Marco Leise wrote: Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale steve.te...@britseyeview.com: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. Steve Do people not upgrade their database to MySQL 5? I never had to deal with that and especially large complicated databases. If it is easy to upgrade to MySQL 5 and it is faster and more secure there are probably few *actively developed* projects accessing MySQL 4 DBs. (MySQL 5 is pretty much exactly 6 years old now.) You'll always find people not upgrading technology for various reasons. We continue to use MySQL 4 at work for an internal legacy application because it just works and we _know_ upgrading will be a lot of work. And see how IE6 is still in use. I'm not advocating that D should strive to support legacy technologies though. I don't think Win98 or earlier are supported either. There is code in druntime and Phobos which special-cases for Windows 98 and earlier (e.g. std.file using the A functions instead of the W functions if the version of Windows that you're running on is too old to have the W functions). Now, personally, I would love it if we just said that you have to have at least Win2k if not WinXP. It would be _great_ to be able to assume at least Vista, since it added a number of useful functions, but XP is still too prevalent for that to be reasonable. Regardless, supporting older versions of Windows is just plain irritating, since it restricts what you can do, and D is new enough and Win2k old enough that I find it perfectly reasonable to insist that you have WinXP or newer, but that's not what we're doing at this point. - Jonathan M Davis
Re: [std.database]
On 2011-10-17 20:07, simendsjo wrote: On 17.10.2011 19:46, Marco Leise wrote: Am 17.10.2011, 18:38 Uhr, schrieb Steve Teale steve.te...@britseyeview.com: PostgreSQL's protocol is stable since 2003, but MySQL's is not very friendly indeed. Phobos might follow opportunistic path and support direct access with recent MySQL versions and C wrapper for older ones. But it looks like the C wrapper approach for MySQL won't fly for Phobos because of the GPL taint. MySQL support might have to be consigned to the Deimos 'derived works' directory. Either that or Phobos only supports versions 5.xx. Steve Do people not upgrade their database to MySQL 5? I never had to deal with that and especially large complicated databases. If it is easy to upgrade to MySQL 5 and it is faster and more secure there are probably few *actively developed* projects accessing MySQL 4 DBs. (MySQL 5 is pretty much exactly 6 years old now.) You'll always find people not upgrading technology for various reasons. We continue to use MySQL 4 at work for an internal legacy application because it just works and we _know_ upgrading will be a lot of work. And see how IE6 is still in use. I'm not advocating that D should strive to support legacy technologies though. I don't think Win98 or earlier are supported either. We can start with supporting the latest version and if there is a demand for earlier versions those can be provided by third party or similar if they can't be included in Phobos. -- /Jacob Carlborg
Re: etc.curl
Den 17-10-2011 03:48, Jonathan M Davis skrev: On Sunday, October 16, 2011 17:28:58 Brad Roberts wrote: What's the state of etc.curl? Where is it in the review queue? It was reviewed and determined that more work was needed before voting, so it's going to require another review. And the author hasn't posted about it since. As soon as it's ready, it'll probably go to the top of the review queue, but as far as I know, it's not ready for further review yet. - Jonathan M Davis There is progress on std.curl (renaming is one of the review fixes) but there has been other stuff keeping me from putting much time into it atm. The review comments have been very useful and as a result the API will change a bit. I personally think the improved API is much better. I have not tried etc.curl out on anything but linux myself. /Jonas
Re: [std.database]
On Fri, 14 Oct 2011 14:23:32 +, Steve Teale wrote: OK, for what it's worth, the compiler generated documentation (well, more or less) for my mysqlD effort is now on my web site. http://britseyeview.com/software/mysqld/ Updated this so it now also has database and table listings, column metadata, and details of stored functions and procedures. Added Command methods specialized on stored functions and procedures. Only one comment so far, so it's either absolute crap or perfect. Steve
Re: [std.database] at compile time
Justin Whear: That's very similar to what I wrote in my database.d https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Mine is super hacky, but hey, it works for me. I write up my tables as .sql files anyway so it's no added hassle. Then the mysql.queryDataObject function can create a dynamic object for a query. It works reasonably well.
Re: [std.database]
On 17.10.2011 20:24, Jonathan M Davis wrote: There is code in druntime and Phobos which special-cases for Windows 98 and earlier (e.g. std.file using the A functions instead of the W functions if the version of Windows that you're running on is too old to have the W functions). Now, personally, I would love it if we just said that you have to have at least Win2k if not WinXP. It would be_great_ to be able to assume at least Vista, since it added a number of useful functions, but XP is still too prevalent for that to be reasonable. Regardless, supporting older versions of Windows is just plain irritating, since it restricts what you can do, and D is new enough and Win2k old enough that I find it perfectly reasonable to insist that you have WinXP or newer, but that's not what we're doing at this point. I'm not even sure W2K support is in great demand. Even XP is on a strong downwards slope, and Win7 has a greater share of the market now. XP is still needed for several years, but Win98...? When was the last time anyone encountered Win98? Does anyone even make software with Win98 support anymore? I doubt D looses any market share by ditching support for operating systems that doesn't even have vendor support. If it restricts usage on newer operating systems I'm in favor of dropping it, but I guess there's a good reason why Win98 is supported (or just legacy from 10 years back..?)
Re: [std.database]
On Monday, October 17, 2011 11:37 simendsjo wrote: On 17.10.2011 20:24, Jonathan M Davis wrote: There is code in druntime and Phobos which special-cases for Windows 98 and earlier (e.g. std.file using the A functions instead of the W functions if the version of Windows that you're running on is too old to have the W functions). Now, personally, I would love it if we just said that you have to have at least Win2k if not WinXP. It would be_great_ to be able to assume at least Vista, since it added a number of useful functions, but XP is still too prevalent for that to be reasonable. Regardless, supporting older versions of Windows is just plain irritating, since it restricts what you can do, and D is new enough and Win2k old enough that I find it perfectly reasonable to insist that you have WinXP or newer, but that's not what we're doing at this point. I'm not even sure W2K support is in great demand. Even XP is on a strong downwards slope, and Win7 has a greater share of the market now. XP is still needed for several years, but Win98...? When was the last time anyone encountered Win98? Does anyone even make software with Win98 support anymore? I doubt D looses any market share by ditching support for operating systems that doesn't even have vendor support. If it restricts usage on newer operating systems I'm in favor of dropping it, but I guess there's a good reason why Win98 is supported (or just legacy from 10 years back..?) There have been bug reports on it (so someone is using D with Windows 98), and Walter seems to think that D should run on as much as it possibly can. So, it looks like until we have a solid reason why we _can't_ reasonably support Windows 98, we're going to. - Jonathan M Davis
Re: etc.curl
On 17.10.2011 13:54, Jimmy Cao wrote: 2011/10/16 simendsjo simend...@gmail.com mailto:simend...@gmail.com On 17.10.2011 02:28, Brad Roberts wrote: What's the state of etc.curl? Where is it in the review queue? Thanks, Brad And as a side note: Is anyone using it on Windows? DMD doesn't ship with the necessary libraries, and I cannot find the correct version of zlib to use with the versions of libcurl I've tried. I've been using it on Windows for a long time. I think what I used is the zip package containing libcurl and the correct version of zlib for Win32 - Generic on this page: http://curl.haxx.se/download.html I seem to remember that was the page I used, but I'll try again. Thanks.
Re: The CAPI Manifesto
Am 17.10.2011 12:21, schrieb Sean Kelly: On Oct 16, 2011, at 7:02 PM, Walter Bright wrote: The CAPI Manifesto -- CAPI is a collection of C header files to publicly available C libraries and their translations to D. The idea is that if, in C, to interface to a library one would write: #include foo.h then the corresponding D code would look like: import foo; If the C header file has a name that is a D keyword, an underscore will be appended to the D module name. If a C type name matches a C function name (stat), the type name will have a _t appended. There's also the occasional issue of something that doesn't translate into D. As one slightly weird example, some of the the Posix routines in OSX have alternates with odd suffixes like $2003 that are the versions which should be called on newer versions of the OS. I'm still not sure of the best way to handle this, since D doesn't have macros. What about function-like macros, e.g. the Linux/POSIX cmsg stuff (CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_LEN() etc) needed to use functions like recvmsg() and sendmsg()? Will there be a direct D translation of the functionality or will they be omitted completely? Cheers, - Daniel
Shared Delegates
Okay, I realize there have been some discussions about this, but I have a
few questions about shared delegates because right now they are definitely
broken, but I'm not sure how.
Take this code example:
synchronized class Thing {
void doSomeWork(void delegate() work) {
work();
}
void work() {}
}
void main() {
auto th = new Thing();
th.doSomeWork(th.work);
}
This doesn't compile because the type of th.work is void delegate()
shared, which cannot be cast implicitly to void delegate().
My first question would be whether that type is correct. It's true that the
data pointer of the delegate points to a shared object, but given that the
function locks it, does that really matter in this case? I guess I'm just
not clear on the exact meaning of shared in general, but it seems like
whether the data is shared or not is irrelevant when the delegate points to
a public member of a synchronized class. If it was a delegate pointing to a
private/protected member (which should be illegal in this case), that would
not be true.
If that type is correct, the problem is that void delegate() shared
doesn't parse as a type (there is a workaround because you can create
variables of this type through alias and typeof).
What, exactly, is wrong here?
Re: Shared Delegates
On 2011-10-17 20:33:59 +, Andrew Wiley wiley.andre...@gmail.com said:
Okay, I realize there have been some discussions about this, but I have a
few questions about shared delegates because right now they are definitely
broken, but I'm not sure how.
Take this code example:
synchronized class Thing {
void doSomeWork(void delegate() work) {
work();
}
void work() {}
}
void main() {
auto th = new Thing();
th.doSomeWork(th.work);
}
This doesn't compile because the type of th.work is void delegate()
shared, which cannot be cast implicitly to void delegate().
My first question would be whether that type is correct. It's true that the
data pointer of the delegate points to a shared object, but given that the
function locks it, does that really matter in this case? I guess I'm just
not clear on the exact meaning of shared in general, but it seems like
whether the data is shared or not is irrelevant when the delegate points to
a public member of a synchronized class. If it was a delegate pointing to a
private/protected member (which should be illegal in this case), that would
not be true.
If that type is correct, the problem is that void delegate() shared
doesn't parse as a type (there is a workaround because you can create
variables of this type through alias and typeof).
What, exactly, is wrong here?
I think what's wrong is that a shared delegate should implicitly
convert to a non-shared one. The delegate is shared since it can be
called safely from any thread, and making it non-shared only prevent
you from propagating it to more thread so it's not harmful in any way.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Simple features that I've always missed from C...
Some trivial binary operations that never had an expression in C/C++, I'd love consideration for an operator or some sort of intrinsic for these. *Roll/Rotate:* I'm loving the '' operator, but I could often really do with a rotate operator useful in many situations... '|' perhaps... something like that? This is ugly: a = (a x) | ((unsigned)a (sizeof(a)/8 - x)); ... and I'm yet to see a compiler that will interpret that correctly. Additionally, if a vector type is every added, a rotate operator will become even more useful. *Count leading/trailing zeroes:* I don't know of any even slightly recent architecture that doesn't have opcodes to count loading/trailing zeroes, although they do exist, so perhaps this is a little dubious. I'm sure this could be emulated for such architectures, but it might be unreasonably slow if used... *Min/Max operators:* GCC has the lovely ? and ? operators... a ? b == min(a, b) .. Why this hasn't been adopted by all C compilers is beyond me. Surely this couldn't be much trouble to add? Again, super useful in vector/maths heavy code too. *Predecated selection:* Float, vector, and often enough even int math can really benefit from using hardware select opcodes to avoid loads/stores. In C there is no way to express this short of vendor specific intrinsics again. 'a b ? a : b' seems like a simple enough expression for the compiler to detect potential for a predecated select opcode (but in my experience, it NEVER does), however, when considering vector types, the logic isn't so clear in that format. Since hardware vectors implement component-wise selection, the logical nature of the ?: operator doesn't really make sense. This could easily be considered an expansion of min/max... 'a ? b', 'a ? b', 'a ==? b', 'a !=? b', etc. seems pretty natural if you're happy to accept GCC's '?' operators, and give the code generator the opportunity to implement these things using hardware support. C is terrible at expressing these concepts, resulting in architecture/compiler specific intrinsics for each of them. Every time I've ever written a maths library, or even just optimised some maths heavy routines, these things come up, and I end up with code full of architecture/platform/compiler ifdef's. I'd like to think they should be standardised intrinsic features of the language (not implemented in the standard library), so the code generator/back end has the most information to generate proper code... Cheers guys - Manu
Re: The CAPI Manifesto
On 10/17/2011 1:24 PM, Daniel Gibson wrote:
What about function-like macros, e.g. the Linux/POSIX cmsg stuff
(CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_LEN() etc) needed to use functions like
recvmsg() and sendmsg()?
Will there be a direct D translation of the functionality or will they be
omitted completely?
Consider:
#define FOO(x) bar((x) + 1)
Do this:
int FOO()(int x) { return bar(x) + 1; }
Note that it's a function template with no template parameters. This will enable
it to be header only and not require linking to some library to resolve FOO().
Re: The CAPI Manifesto
Regan Heath re...@netmail.co.nz wrote in message news:op.v3h9w20554x...@puck.auriga.bhead.co.uk... I like it! :) vote++
Re: Just starting out
Jesse Phillips jessekphillip...@gmail.com wrote in message news:j78djv$1sr3$1...@digitalmars.com... On Thu, 13 Oct 2011 20:49:01 -0400, Nick Sabalausky wrote: One thing I'd been thinking of adding to mine was an alternate function that just waited for a single keystroke (rather than a line of text + Enter). I think I once had it working on Tango, IIRC, but then I switched to D2/Phobos and couldn't figure out how to use Phobos to wait for a single keystroke w/o then waiting for Enter. There isn't a C call to do something like this. In windows you can make a call to system(pause), but that doesn't provide custom text, isn't cross platform, and apparently if you close the terminal it will start executing code for the time it takes to shut down (i.e. unpause). Linux you have to pull out an curses trick to manipulate the terminal I believe, also not cross platform. It would be nice to get. What I meant was to also retreive the key pressed. But it sounds like that would still have the same problem.
Re: Just starting out
There's a call like this but it's nonstandard. getch() maybe? Sent from my iPhone On Oct 17, 2011, at 2:54 PM, Nick Sabalausky a@a.a wrote: Jesse Phillips jessekphillip...@gmail.com wrote in message news:j78djv$1sr3$1...@digitalmars.com... On Thu, 13 Oct 2011 20:49:01 -0400, Nick Sabalausky wrote: One thing I'd been thinking of adding to mine was an alternate function that just waited for a single keystroke (rather than a line of text + Enter). I think I once had it working on Tango, IIRC, but then I switched to D2/Phobos and couldn't figure out how to use Phobos to wait for a single keystroke w/o then waiting for Enter. There isn't a C call to do something like this. In windows you can make a call to system(pause), but that doesn't provide custom text, isn't cross platform, and apparently if you close the terminal it will start executing code for the time it takes to shut down (i.e. unpause). Linux you have to pull out an curses trick to manipulate the terminal I believe, also not cross platform. It would be nice to get. What I meant was to also retreive the key pressed. But it sounds like that would still have the same problem.
Re: The CAPI Manifesto
On 17/10/11 10:33 PM, Walter Bright wrote:
On 10/17/2011 1:24 PM, Daniel Gibson wrote:
What about function-like macros, e.g. the Linux/POSIX cmsg stuff
(CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_LEN() etc) needed to use
functions like
recvmsg() and sendmsg()?
Will there be a direct D translation of the functionality or will they be
omitted completely?
Consider:
#define FOO(x) bar((x) + 1)
Do this:
int FOO()(int x) { return bar(x) + 1; }
Note that it's a function template with no template parameters. This
will enable it to be header only and not require linking to some
library to resolve FOO().
int FOO()(int x) { return bar(x + 1); }
would probably work better :-)
+1 for CAPI btw.
Re: Simple features that I've always missed from C...
Manu: *Roll/Rotate:* I'm loving the '' operator, but I could often really do with a rotate operator useful in many situations... '|' perhaps... something like that? This is ugly: a = (a x) | ((unsigned)a (sizeof(a)/8 - x)); I have asked for a rotate intrinsic in Phobos, but Walter has added a rewrite rule instead, that turns D code to a rot. Personal experience has shown me that it's easy to write the operation in a slightly different way (like with signed instead of unsigned values) that causes a missed optimization. So I prefer still something specific, like a Phobos intrinsic, to explicitly ask for this operation to every present and future D compiler, with no risk of mistakes. *Min/Max operators:* GCC has the lovely ? and ? operators... a ? b == min(a, b) .. Why this hasn't been adopted by all C compilers is beyond me. Surely this couldn't be much trouble to add? Again, super useful in vector/maths heavy code too. This is cute. Surely max/min is a common operation to do, but often I have to find a max or min of a collection, where I think this operator can't be used. I don't think this operator is necessary, and it makes D code a bit less readable for people that don't know D. *Predecated selection:* Float, vector, and often enough even int math can really benefit from using hardware select opcodes to avoid loads/stores. In C there is no way to express this short of vendor specific intrinsics again. I don't understand what you are asking here. Please show an example. There is an enhancement request that asks to support vector operations like this too (some CPUs support something like this in hardware): int[] a = [1,2,3,4]; int[] b = [4,3,2,1]; auto c = a[] b[]; assert(c == [false, false, true, true]); Are operations like this what you are asking for here? Bye, bearophile
Re: The CAPI Manifesto
With D being binary compatible with C, i don't know why we worry on such things. Wasn't being able to access C libraries the point? If it wasn't, what is the worthwhile point for this constraint? Wouldn't (sorry for the poor horse) separate compilers solve the most problems (if not all) we face on these issues? C never changes and every compiler vendor have an implementation. -- import anyapi; // anyapi would be a D module or a C header (anyapi.h...) in directory paths. -- Structs are pod in both languages. Matching of the standard types is something we can take care of with documentation (RTFM) and with compiler errors generated (when we call functions from the other language). Sorry once again if this should sound stupid or impossible to implement (if so, someone please enlighten me), it probably is because everytime we open this discussion i feel i am the only one seeing the big picture, the potential of D. On Mon, 17 Oct 2011 05:02:52 +0300, Walter Bright newshou...@digitalmars.com wrote: Brad and I were talking about some D code that needed openssl support, when we ran into the same old problem: No D files corresponding to the openssl C .h files. It's not that these are a big problem to create, it's just that they are not done, and it tends to turn off people from using D. D is binary API compatible with C, but only with a corresponding D import file. This, out of the box, makes D *harder* to use than C. Lots of people roll their own, but that work is hard to find and haphazard. This problem keeps coming up again and again. So I propose creating, on github.com/D-Programming-Language, a new repository called CAPI. The CAPI Manifesto -- CAPI is a collection of C header files to publicly available C libraries and their translations to D. The idea is that if, in C, to interface to a library one would write: #include foo.h then the corresponding D code would look like: import foo; Each C .h file would have a corresponding .d file. Each C directory would have a corresponding D directory, for example: #include bar/foo.h // C import bar.foo; // D The top level directory of each library will have two subdirectories: C/ D/ and there will be a one-to-one correspondence of files and directory structure between them. The D import files will be a rote translation of the corresponding C .h file. No attempt will be made to fix, improve, or extend the C api. No attempt will be made to duplicate the C documentation, or replace it in any way. There will be no unittests. Every effort will be made to avoid needing any D specific binary files. When an updated version of the C header files becomes available, those will get checked into the C subdirectory tree, and then the corresponding D files will get updated. Version tags used must match the version tags used by the C API files. The license used for the D versions should match the C ones, as they are a derived work.
Re: The CAPI Manifesto
On Monday, October 17, 2011 17:09 so wrote: With D being binary compatible with C, i don't know why we worry on such things. Wasn't being able to access C libraries the point? If it wasn't, what is the worthwhile point for this constraint? Wouldn't (sorry for the poor horse) separate compilers solve the most problems (if not all) we face on these issues? C never changes and every compiler vendor have an implementation. -- import anyapi; // anyapi would be a D module or a C header (anyapi.h...) in directory paths. -- Structs are pod in both languages. Matching of the standard types is something we can take care of with documentation (RTFM) and with compiler errors generated (when we call functions from the other language). Sorry once again if this should sound stupid or impossible to implement (if so, someone please enlighten me), it probably is because everytime we open this discussion i feel i am the only one seeing the big picture, the potential of D. The problem is that for C code to be usable in D code, the C declarations must be redone in D, since D can't just include header files. Translating C header files to D is a pain and time consuming, and it would benefit us all to have a place to go to find common C headers translated to D so that such work doesn't have to be duplicated. Hence CAPI has been proposed. And if we're going to have it, it also benefits us to be organized about how we lay it out. Programmers can name modules in their code whatever they want, but being organized about how modules are named and laid out in a large project such as this makes it much easier to maintain and find what you want in it. - Jonathan M Davis
Re: Just starting out
Sean Kelly s...@invisibleduck.org wrote in message news:mailman.151.1318889150.24802.digitalmar...@puremagic.com... There's a call like this but it's nonstandard. getch() maybe? Sent from my iPhone IIRC, I think I tried that but there was some problem. Either it still waited for Enter, or it didn't wait at all, or something like that. --- Not sent from an iPhone.
