Re: Array ops give sharing violation under Windows 7 64 bit?
On 3/25/2012 2:50 PM, Kagamin wrote: Microsoft has antivirus bundled with windows. Go to security center and see whether Windows Defender is working. Well, I'll be hornswoggled. That did the trick! Defender has a feature where it will to real time scanning of new executables. Apparently, it was trying to scan the exe's built by the test suite while the test suite was trying to rewrite them. I just disabled my dev directory from Defender scanning it. Thanks!
Re: Poll of the week - How long have you been in the D world?
On 26 March 2012 14:18, dnewbie wrote: > Just out of curiosity, is D attracting new users? Are the old > users running? Place your vote here > http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f Looks like a fairly even spread so far, (27 votes). The higher bracket is low, but it is also 6-10 years, D hasn't been around much longer than that <.< -- James Miller
Re: How to use D for cross platform development?
On 2012-03-25 15:04:34 +, Jacob Carlborg said: A third option for Objective-C would be to use a fork of DMD that makes it possible to directly interface with Objective-C, just as it's possible with C. I'm not sure of the status of this project but an alpha has been released. It is not up to date with the latest DMD versions. The project is on hold as I'm working on other things. But it can compile code if you target the Apple's 32-bit Legacy Objective-C runtime. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Poll of the week - How long have you been in the D world?
Just out of curiosity, is D attracting new users? Are the old users running? Place your vote here http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f
Re: Proposal: user defined attributes
On Sunday, 25 March 2012 at 15:24:18 UTC, Jacob Carlborg wrote:
On 2012-03-22 02:23, Tove wrote:
mixin(attr(q{struct Foo
{
@NonSerialized int x;
@NonSerialized int y;
int z;
}}));
void main()
{
auto m = [ __traits(allMembers, Foo) ];
writeln("Normal members of Foo:", m);
auto n = [ __traits(allMembers, Foo_Serializable) ];
writeln("Serializable members of Foo:", n);
}
Just really ugly and it creates a new type, completely
unnecessary if D supported user defined attributes.
Well... "eye of the beholder"... I think that's exactly the
beautiful part, because:
1) The original type is 100% unaltered...
2) Easy for the compiler to optimize the new type away as it's
never instantiated, nor used beyond ctfe reflection i.e. 0
runtime overhead.
3) It trivially allows using the built-in traits system everyone
already is familiar with.
but I wonder if one can do better with a mixin template,
accessing it's "parent"...
Re: When do you use templates instead of CTFE?
On Monday, March 26, 2012 12:39:36 James Miller wrote: > Often I end up using the same function in CTFE and runtime. That's pretty much the idea behind CTFE in the first place. - Jonathan M Davis
Re: When do you use templates instead of CTFE?
On 26 March 2012 12:35, Jonathan M Davis wrote: > On Sunday, March 25, 2012 17:55:56 Nick Sabalausky wrote: >> Yea, the general rule of thumb is "If you can do it with CTFE, then do so, >> otherwise use templates." > > Generally, you end up having to use templates for stuff that operates on > types, whereas CTFE works for stuff that can be normal functions. > > - Jonathan M Davis Often I end up using the same function in CTFE and runtime. -- James Miller
Re: How to use D for cross platform development?
On Mar 25, 2012 7:34 PM, "Jonathan M Davis" wrote: > > On Monday, March 26, 2012 09:55:00 James Miller wrote: > > On 26 March 2012 09:44, Iain Buclaw wrote: > > > A spork of druntime, yes. > > > > A spork? I've never heard that before... > > http://en.wikipedia.org/wiki/Spork > > Not that it has anything to do with software... > > - Jonathan M Davis I like it. Not separated just a set of patches.
Re: When do you use templates instead of CTFE?
On Sunday, March 25, 2012 17:55:56 Nick Sabalausky wrote: > "Timon Gehr" wrote in message > news:jkkbqv$2pvu$3...@digitalmars.com... > > > On 03/24/2012 07:42 AM, Dan wrote: > >> Since there is CTFE, I keep running into, do I really need this as a > >> template parameter? Why not put this in a constructor. And so on... > > > > You use templates in combination with CTFE if > > > > - You have to perform computations on types. > > - You want template instantiation syntax. > > > > (If this is the only reason, the template will just wrap a CTFE > > > > computation) > > Yea, the general rule of thumb is "If you can do it with CTFE, then do so, > otherwise use templates." Generally, you end up having to use templates for stuff that operates on types, whereas CTFE works for stuff that can be normal functions. - Jonathan M Davis
Re: BitC, Rust, dog food and more
On 03/25/2012 12:41 PM, Nick Sabalausky wrote: "Walter Bright" wrote in message news:jknr78$1g8q$1...@digitalmars.com... So why hasn't dmd been subject to all sorts of safety errors (like buffer overruns, uninitialized pointers, etc.)? Because you're cleverly using very D-like C++ ;) Cart/horse: D is a lot like the parts of C++ that work well.
Re: How to use D for cross platform development?
On Monday, March 26, 2012 09:55:00 James Miller wrote: > On 26 March 2012 09:44, Iain Buclaw wrote: > > A spork of druntime, yes. > > A spork? I've never heard that before... http://en.wikipedia.org/wiki/Spork Not that it has anything to do with software... - Jonathan M Davis
Re: Getting around the non-virtuality of templates
On Mon, 26 Mar 2012 00:36:08 +0200, Stewart Gordon wrote: I'm coming up against some interesting challenges while porting stuff in my utility library to D2. Firstly, D2 uses opBinary and opOpAssign, rather than the operator-specific op* and op*Assign. While the latter still work, they aren't mentioned in the current D2 docs. Which would imply that they're on the way out; however, there's no mention at https://github.com/D-Programming-Language/d-programming-language.org/blob/master/deprecate.dd (See also http://d.puremagic.com/issues/show_bug.cgi?id=7779 ) Still, it seems clear that opBinary/opOpAssign is the D2 way of doing it. But it has the drawback that, because it's a template, it isn't virtual. One way about it is to keep the D1-style op functions and make opUnary/opBinary/opOpAssign call these. But is there a better way? The other isn't a D2-specific issue, though D2 increases the significance of it. I have a method with the signature Set opAnd(bool delegate(Element) dg) I would like to enable a user of the library to pass in a delegate whose parameter is any type to which Element is implicitly convertible. This could be the same type as Element with the top-level constancy changed (probably the main use case), or a type that is distinct beyond the constancy level. Turning it into a template Set opAnd(E)(bool delegate(E) dg) would address this, but prevent overriding with the appropriate code for each set implementation. Who else has been faced with this problem? Have you found a good way of dealing with it? Stewart. I believe the officially vetted answer is to have the templated calls forward to virtual functions. Of course, if you need to do something specific before handing it there, you're out of luck.
Something wrong with dmd's -c command?
Response file:
dmd.rsp:
compile.d
ignored.d
main.d
parse.d
serialize.d
types.d
util.d
xml.d
ae\utils\xml.d
ae\utils\xmlrpc.d
gen\common.d
gen\typemaps.d
gen\types.d
gen\generator.d
gen\util.d
messagepack\msgpack.d
-ofdoxy.exe
$ dmd @dmd.rsp
OK, exe is built (win32). Now let's try compiling module-by-module via
-c and then linking:
make.bat:
@echo off
dmd -c -I.. -ofcompile.obj compile.d
dmd -c -I.. -ofignore.obj ignored.d
dmd -c -I.. -ofmain.obj main.d
dmd -c -I.. -ofparse.obj parse.d
dmd -c -I.. -ofserialize.obj serialize.d
dmd -c -I.. -oftypes.obj types.d
dmd -c -I.. -ofutil.obj util.d
dmd -c -I.. -ofxml.obj xml.d
dmd -c -I.. -ofae_utils_xml.obj ae\utils\xml.d
dmd -c -I.. -ofae_utils_xmlrpc.obj ae\utils\xmlrpc.d
dmd -c -I.. -ofgen_common.obj gen\common.d
dmd -c -I.. -ofgen_typemaps.obj gen\typemaps.d
dmd -c -I.. -ofgen_types.obj gen\types.d
dmd -c -I.. -ofgen_generator.obj gen\generator.d
dmd -c -I.. -ofgen_util.obj gen\util.d
dmd -c -I.. -ofmsgpack.obj messagepack\msgpack.d
dmd compile.obj ignore.obj main.obj parse.obj serialize.obj types.obj
util.obj xml.obj ae_utils_xml.obj ae_utils_xmlrpc.obj gen_common.obj
gen_typemaps.obj gen_types.obj gen_generator.obj gen_util.obj
msgpack.obj
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
main.obj(main)
Error 42: Symbol Undefined
_D6object54__T16AssociativeArrayTAyaTxS9doxyparse5types8VariableZ16AssociativeArray6lengthMFNdZk
main.obj(main)
Error 42: Symbol Undefined
_D6object58__T16AssociativeArrayTAyaTxS9doxyparse5types11FuncTypedefZ16AssociativeArray6lengthMFNdZk
main.obj(main)
Error 42: Symbol Undefined
_D6object53__T16AssociativeArrayTAyaTxS9doxyparse5types7TypedefZ16AssociativeArray6lengthMFNdZk
main.obj(main)
Error 42: Symbol Undefined
_D6object52__T16AssociativeArrayTAyaTxS9doxyparse5types6DefineZ16AssociativeArray6lengthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object29__T16AssociativeArrayTAyaTxiZ16AssociativeArray6lengthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object29__T16AssociativeArrayTkTxAyaZ16AssociativeArray6lengthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object29__T16AssociativeArrayTAyaTxkZ16AssociativeArray6lengthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object112__T16AssociativeArrayTAyaTxS9doxyparse5t1βFunctionBaseVEŀʠTϱZњ?engthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object50__T16AssociativeArrayTAyaTxS9doxyparse5types4EnumZ16AssociativeArray6lengthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object32__T16AssociativeArrayTAyaTxAAyaZ16AssociativeArray6lengthMFNdZk
xml.obj(xml)
Error 42: Symbol Undefined
_D6object112__T16AssociativeArrayTAyaTxS9doxyparse5t1βFunctionBaseVEŀʠTϰZњ?engthMFNdZk
--- errorlevel 11
>Exit code: 11
All of these seem related to associative arrays.
If you demangle one of the symbols via std.demangle it becomes:
@property uint object.AssociativeArray!(immutable(char)[],
const(doxyparse.types.FuncTypedef)).AssociativeArray.length()
I can tell this is needed for the following symbol in my
'doxyparse.types' module:
struct Member
{
FuncTypedef[string] funcTypedefs;
}
FuncTypedef is defined as:
struct FuncTypedef
{
string ID;
string name;
string type;
string[] parameters;
string returnType;
}
There is nothing in the directory up from the current folder (-I..)
except the base folder of the project, so I don't think DMD is picking
up modules from unrelated directories.
I can't test with older versions of DMD because my project then ICEs.
I'd try with GDC, but apparently GDC has .length set as a ulong even
though I'm running x86, so I get compilation errors there.
I'll have to reduce this to make a test-case.. but has anyone had
issues like these before?
Re: Getting around the non-virtuality of templates
On 26 March 2012 11:36, Stewart Gordon wrote: > I'm coming up against some interesting challenges while porting stuff in my > utility library to D2. > > Firstly, D2 uses opBinary and opOpAssign, rather than the operator-specific > op* and op*Assign. While the latter still work, they aren't mentioned in > the current D2 docs. Which would imply that they're on the way out; however, > there's no mention at > https://github.com/D-Programming-Language/d-programming-language.org/blob/master/deprecate.dd > > (See also > http://d.puremagic.com/issues/show_bug.cgi?id=7779 ) > > Still, it seems clear that opBinary/opOpAssign is the D2 way of doing it. > But it has the drawback that, because it's a template, it isn't virtual. > One way about it is to keep the D1-style op functions and make > opUnary/opBinary/opOpAssign call these. But is there a better way? > > The other isn't a D2-specific issue, though D2 increases the significance of > it. I have a method with the signature > > Set opAnd(bool delegate(Element) dg) > > I would like to enable a user of the library to pass in a delegate whose > parameter is any type to which Element is implicitly convertible. This > could be the same type as Element with the top-level constancy changed > (probably the main use case), or a type that is distinct beyond the > constancy level. Turning it into a template > > Set opAnd(E)(bool delegate(E) dg) > > would address this, but prevent overriding with the appropriate code for > each set implementation. > > Who else has been faced with this problem? Have you found a good way of > dealing with it? > > Stewart. Non-virtuality of templates is a general problem at the moment. The issues seem to be around how to handle inheritance of template arguments, and how to dispatch the functions based on a combination of template arguments and class hierarchy. This is a hard problem with no obvious answer. in terms of trying to work around it, perhaps compile-time reflection could help, I haven't encountered this before, but that's where I would start. -- James Miller
Re: How to use D for cross platform development?
On 25 March 2012 21:55, James Miller wrote: > On 26 March 2012 09:44, Iain Buclaw wrote: >> A spork of druntime, yes. > > A spork? I've never heard that before... > It's constantly merged from upstream, however we keep any GDC-specific differences in-house. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Getting around the non-virtuality of templates
I'm coming up against some interesting challenges while porting stuff in my utility library to D2. Firstly, D2 uses opBinary and opOpAssign, rather than the operator-specific op* and op*Assign. While the latter still work, they aren't mentioned in the current D2 docs. Which would imply that they're on the way out; however, there's no mention at https://github.com/D-Programming-Language/d-programming-language.org/blob/master/deprecate.dd (See also http://d.puremagic.com/issues/show_bug.cgi?id=7779 ) Still, it seems clear that opBinary/opOpAssign is the D2 way of doing it. But it has the drawback that, because it's a template, it isn't virtual. One way about it is to keep the D1-style op functions and make opUnary/opBinary/opOpAssign call these. But is there a better way? The other isn't a D2-specific issue, though D2 increases the significance of it. I have a method with the signature Set opAnd(bool delegate(Element) dg) I would like to enable a user of the library to pass in a delegate whose parameter is any type to which Element is implicitly convertible. This could be the same type as Element with the top-level constancy changed (probably the main use case), or a type that is distinct beyond the constancy level. Turning it into a template Set opAnd(E)(bool delegate(E) dg) would address this, but prevent overriding with the appropriate code for each set implementation. Who else has been faced with this problem? Have you found a good way of dealing with it? Stewart.
Re: When do you use templates instead of CTFE?
"Timon Gehr" wrote in message news:jkkbqv$2pvu$3...@digitalmars.com... > On 03/24/2012 07:42 AM, Dan wrote: >> Since there is CTFE, I keep running into, do I really need this as a >> template parameter? Why not put this in a constructor. And so on... >> >> > > You use templates in combination with CTFE if > > - You have to perform computations on types. > - You want template instantiation syntax. > (If this is the only reason, the template will just wrap a CTFE > computation) Yea, the general rule of thumb is "If you can do it with CTFE, then do so, otherwise use templates."
Re: Array ops give sharing violation under Windows 7 64 bit?
On Saturday, 24 March 2012 at 19:22:03 UTC, Walter Bright wrote: On 3/24/2012 12:18 PM, Xinok wrote: If you have an antivirus, try disabling it before compiling. I have a brand new vanilla install of Windows 7 home premium. Microsoft has antivirus bundled with windows. Go to security center and see whether Windows Defender is working.
Re: BitC, Rust, dog food and more
"deadalnix" wrote in message news:jko00q$1pif$1...@digitalmars.com... > Le 25/03/2012 22:38, James Miller a écrit : >> On 26 March 2012 08:41, Nick Sabalausky wrote: >>> >>> Because you're cleverly using very D-like C++ ;) >>> >> >> Unsurprising from, you know, the creator of D... >> >> That said, having a D compiler in D would be cool, simply because >> every language needs a bootstrapped compiler :P. Also, their are other >> arguments that apply well to bootstrapped compilers, like improving >> the language improves the compiler, which improves the language. It's >> also a complicated enough endeavour that it showcases D well. I don't >> think that we should replace DMD with it, but it would be a cool >> project. >> >> -- >> James Miller > > ddmd seems to provide a working frontend written in D. I think this > project should be more promoted (eventually become the main d frontend ?). The problem with ddmd (at least the original, as opposed to the newer ddmd-clean fork) is that the approach it used for incorporating new changes from dmd proved to be unsustainable. I think ddmd has, unfortunately, proven that the only realistic approach to having a full D compiler (or frontend) written in D, would be for dmd itself to just take the plunge and migrate to D. (And in the meantine, if someone wants a whole D frontend that's accessible from D, they're better off with D bindings to the C++-based D frontend.) But of course switching dmd from C++ to D could create difficulties with bootstrapping. For example, porting it to a new platform would require using an existing D cross-compiler. It'd mostly just be braggng rights anyway, and we have more important things to address (like iOS/Android IMO). Heck, Haxe is doing pretty well for itself, and it's not self-hosted, it's written in ocaml. As far as ddmd-clean, that might be ok since it's just lex/parse, not semantics, and the lexer/parser doesn't need to change much. But once you add the semantics/CTFE/etc in there, then the approach of "developed in parallel in two different langauges" is just too impractical.
Re: How to use D for cross platform development?
On 26 March 2012 09:44, Iain Buclaw wrote: > A spork of druntime, yes. A spork? I've never heard that before... -- James Miller
Re: BitC, Rust, dog food and more
On 03/25/2012 10:49 PM, deadalnix wrote: Le 25/03/2012 22:38, James Miller a écrit : On 26 March 2012 08:41, Nick Sabalausky wrote: Because you're cleverly using very D-like C++ ;) Unsurprising from, you know, the creator of D... That said, having a D compiler in D would be cool, simply because every language needs a bootstrapped compiler :P. Also, their are other arguments that apply well to bootstrapped compilers, like improving the language improves the compiler, which improves the language. It's also a complicated enough endeavour that it showcases D well. I don't think that we should replace DMD with it, but it would be a cool project. -- James Miller ddmd seems to provide a working frontend written in D. I think this project should be more promoted (eventually become the main d frontend ?). I don't think that would buy a lot. DDMD is more or less a direct translation of DMD. A frontend written in D should be written from scratch so that it does not suffer from design decisions taken in the C++ code that would have been different in D code.
Re: BitC, Rust, dog food and more
On 26 March 2012 09:49, deadalnix wrote: > > ddmd seems to provide a working frontend written in D. I think this project > should be more promoted (eventually become the main d frontend ?). I have seen it, and it looks good. But there are reasons why the DMD front-end is in C++, I think Walter has explained why on occasion before, but it basically boils down to: its easier for other compiler developers to understand + integrate with C++ code when building the compiler back-end than if they had to interface with D code. -- James Miller
Re: How to use D for cross platform development?
On 25 March 2012 21:31, Jacob Carlborg wrote: > On 2012-03-25 18:20, Alex Rønne Petersen wrote: > >> About ARM support: That's not strictly true. D on ARM should work fine >> at this point in time if you build druntime/phobos in GDC with >> -fno-section-anchors (there is even some experimental Android support). >> But indeed, no iOS support. > > > Ok, I didn't know about that. Is GDC using its own runtime? > > -- > /Jacob Carlborg A spork of druntime, yes. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: BitC, Rust, dog food and more
Le 25/03/2012 22:38, James Miller a écrit : On 26 March 2012 08:41, Nick Sabalausky wrote: Because you're cleverly using very D-like C++ ;) Unsurprising from, you know, the creator of D... That said, having a D compiler in D would be cool, simply because every language needs a bootstrapped compiler :P. Also, their are other arguments that apply well to bootstrapped compilers, like improving the language improves the compiler, which improves the language. It's also a complicated enough endeavour that it showcases D well. I don't think that we should replace DMD with it, but it would be a cool project. -- James Miller ddmd seems to provide a working frontend written in D. I think this project should be more promoted (eventually become the main d frontend ?).
Re: BitC, Rust, dog food and more
On 26 March 2012 08:41, Nick Sabalausky wrote: > > Because you're cleverly using very D-like C++ ;) > Unsurprising from, you know, the creator of D... That said, having a D compiler in D would be cool, simply because every language needs a bootstrapped compiler :P. Also, their are other arguments that apply well to bootstrapped compilers, like improving the language improves the compiler, which improves the language. It's also a complicated enough endeavour that it showcases D well. I don't think that we should replace DMD with it, but it would be a cool project. -- James Miller
Re: How to use D for cross platform development?
On 2012-03-25 18:20, Alex Rønne Petersen wrote: About ARM support: That's not strictly true. D on ARM should work fine at this point in time if you build druntime/phobos in GDC with -fno-section-anchors (there is even some experimental Android support). But indeed, no iOS support. Ok, I didn't know about that. Is GDC using its own runtime? -- /Jacob Carlborg
Re: BitC, Rust, dog food and more
"Walter Bright" wrote in message news:jknr78$1g8q$1...@digitalmars.com... > > So why hasn't dmd been subject to all sorts of safety errors (like buffer > overruns, uninitialized pointers, etc.)? > Because you're cleverly using very D-like C++ ;)
Re: BitC, Rust, dog food and more
On 3/25/2012 10:31 AM, bearophile wrote: One more disadvantage of not using D (or a language safer than C/C++) to implement a safe language as D is that the compiler will have many more bugs, so while you program in the implemented language (D) you will find many D compiler bugs. Today I think that it's very hard to create a reliable language writing its compiler in a not reliable language. Oh, rubbish. Vanishingly few of the reported DMD compiler bugs would have been caught by using a safe(r) language. The bugs have been logic errors, usually due to making improvements in the D language and failing to account for all of the effects of those improvements in the compiler. So why hasn't dmd been subject to all sorts of safety errors (like buffer overruns, uninitialized pointers, etc.)? It's because I've been writing C/C++ code for 30 years now. For the first 10 years, my code suffered a lot from those sort of bugs. Over time, the code had less and less of them. I simply learned to avoid them. It's like playing the guitar - do it enough and you eventually learn to avoid all the more basic mistakes. Don't take this as an argument that we don't need safe(r) languages. We do. I don't see a reason for programmers to spend 10 years suffering in the wilderness to learn to avoid making certain kinds of mistakes.
Re: BitC, Rust, dog food and more
On 03/25/2012 07:31 PM, bearophile wrote: ... So we moved to a "monomorphization" scheme for Rust 0.2, which is basically like C++ template instantiation, only without the overhead of reparsing all the code from scratch.< What are doing D/DMD regarding this? D templates do not require reparsing. I don't think C++ templates do either (there are strange disambiguation rules such as object.template member), but the standard allows reparsing afaik.
BitC, Rust, dog food and more
BitC has tried to become a verified system language, but its author has decided to stop its development because of some problems that he has described in a post. This is a thread of discussions about that post: http://news.ycombinator.com/item?id=3749860 One of the most interesting comments is from a developer of the Rust language (pcwalton), that currently is at the top of the thread. It also shows how much design work is going into Rust (a system language developed by Mozilla), that is going to become quite different from D. It will be hard to translate Rust programs to D. One advantage of D over Rust is that you know Java, C, Python and C++, it doesn't take too much time to learn D. While Rust contains several less commonly known things (typeclasses, region inference, etc). Two quotations from the first post by pcwalton: >I think that one of the most important things to underscore is that we would >have never found these things so early unless we had written the Rust compiler >in Rust itself. It forces us to use the language constantly, and we quickly >find pain points. I highly encourage all languages to do the same; it's a >great way to find and shake out design issues early.< Eating your own dog food is quite important for a language, especially if it's a low-level language. D has chosen the pragmatic approach of using almost-C++ as its implementation language, but this has caused (and it is causing) some disadvantages too. One more disadvantage of not using D (or a language safer than C/C++) to implement a safe language as D is that the compiler will have many more bugs, so while you program in the implemented language (D) you will find many D compiler bugs. Today I think that it's very hard to create a reliable language writing its compiler in a not reliable language. You can't write the SPARK compiler in something different than SPARK and hope that SPARK will come out as a reliable language :-) Because reliability is not just in the programs written in the language, it also comes from the compiler used to compile it. >So we moved to a "monomorphization" scheme for Rust 0.2, which is basically >like C++ template instantiation, only without the overhead of reparsing all >the code from scratch.< What are doing D/DMD regarding this? Bye, bearophile
Re: std.ffi?
Alex Rønne Petersen wrote: > Hi, > > I implemented a simple binding/wrapper for libffi in D a while > back[1]. We have successfully used this to implement native function > invocation in MCI's IR interpreter. I'm wondering if there is any > interest in making this a standard module in Phobos (std.ffi or so). > If so, I'm willing to put in some effort to sanitize and properly > document the API. > > This means that we will be depending on libffi. I don't know how > people feel about this. FWIW, the library is available on virtually > any POSIX system (including OS X). Only Windows doesn't have it. Is it possible to add a plain conversion of the header files to Deimos https://github.com/D-Programming-Deimos? Adding a higher level wrapper on top of the plain conversion to Phobos may be a good idea. But ultimately a package manager should address these issues. Jens
Re: Regex performance
Hello everyone, I'm the author of the blog post. First of all, thanks so much for the interest in my problem. I had no idea that the D community was so active (a fact that pleases me greatly). A quick update. I've written a small benchmark based on my real code and I'm now getting *significantly* better performance from my D code. I'm currently trying to figure out what I'm doing differently in my original program. At this point I am assuming that I have an error in my code which causes the D program to do much more work that its Ruby counterpart (although I am currently unable to find it). When I know more I will let you know. James Blewitt
std.ffi?
Hi, I implemented a simple binding/wrapper for libffi in D a while back[1]. We have successfully used this to implement native function invocation in MCI's IR interpreter. I'm wondering if there is any interest in making this a standard module in Phobos (std.ffi or so). If so, I'm willing to put in some effort to sanitize and properly document the API. This means that we will be depending on libffi. I don't know how people feel about this. FWIW, the library is available on virtually any POSIX system (including OS X). Only Windows doesn't have it. [1] https://github.com/lycus/libffi-d -- - Alex
Re: How to use D for cross platform development?
On 25-03-2012 17:04, Jacob Carlborg wrote: On 2012-03-25 13:12, Bennie Copeland wrote: Hello all. I'm sorry if this has been addressed before. For a little background. I've been studying C++ with the intention of doing cross platform work on Windows, OSX, and eventually iOS and some other mobile OSes. My plan was to write cross platform shared libraries for the core functionality and implement the GUI using Win32, Cocoa, etc. Well, while C++ is powerful, I'm finding it a beast to work with. I kept thinking about abandoning C++ altogether and using C# with Mono until I stumbled upon D. D sounds exactly like what I am looking for, powerful yet productive and native. First I have to say that D is a great language for doing cross platform development. But for iOS there are a couple of big problems. The reference D compiler, DMD, does not have an ARM-backend. There are other compilers available though: LDC, the DMD frontend on the LLVM backend and GDC, the DMD frontend on the GCC backend. Second big problem is the D runtime does not support ARM. As far as I know, no one has ever used D on iOS. About ARM support: That's not strictly true. D on ARM should work fine at this point in time if you build druntime/phobos in GDC with -fno-section-anchors (there is even some experimental Android support). But indeed, no iOS support. My question however is how to do D cross platform development. I can't seem to find any recent information about it. From what I have gathered so far it seems, shared libraries are possible on win/osx/linux, but only when linked against other D code. For linking against C, I can create a DLL in windows, but I can't create an .so in linux, and no information at all about OSX. Some of the information I found is years old and I can't tell if the situation has changed. There is nothing in the FAQ about libraries. And googling provides little information. You should be able to create shared libraries for linking with C code. You just need to make sure you initialize the D runtime. I'm not entirely sure about the status for creating shared libraries, not sure if the runtime has been modified to support that on all platforms. I think Windows and Linux is good to go but I don't think the runtime is not ready yet for Mac OS X. So, is it possible to write the core of an application in a cross platform D library that can be callable by C, C++, or Objective-C to provide the GUI elements? If not, is it possible to write a C wrapper around the library that is then callable by C, C++ or Objective-C? How have others approached this situation? Besides the library issues, what other issues or gotchas should I look out for in regards to cross platform development? When it comes to providing a GUI for your application there are a couple of choices: * Directly access the native GUI operations of the operating system * Use a cross platform GUI library For directly accessing the native GUI of the operating system there are again various options. First option, C wrapper. A C wrapper works for all languages you need to interact with: C, C++ and Objective-C. D has limited support for interfacing directly with C++. For example, D understand the C++ mangling and you can call virtual C++ functions from D. This could be another idea, or used together with C wrappers. http://dlang.org/cpp_interface.html For interfacing with Objective-C there are a couple of options as well. One option is to use C wrappers. Another is to use the Objective-C runtime functions to get be able to create Objective-C class and methods from D. There are two projects that have gone this road and created a fully working, fully automatic bridge between D and Objective-C. Although it turned out to not be usable in practice. A third option for Objective-C would be to use a fork of DMD that makes it possible to directly interface with Objective-C, just as it's possible with C. I'm not sure of the status of this project but an alpha has been released. D/Objective-C bridge: http://dsource.org/projects/dstep D/Objective-C bridge: http://michelf.com/projects/d-objc-bridge/ DMD fork: http://michelf.com/projects/d-objc/ Cross platform GUI libraries. Here are again several options: * DWT - Port of SWT. Uses the native operations of the operating system. Supports Windows (win32) and Linux (GTK+). Support for Mac OS X (Cocoa) is worked on. http://dsource.org/projects/dwt * gtkD - Bindings to GTK. Does not use the native drawing operations of the operating system. Available on all platforms. http://dsource.org/projects/gtkd * QtD - Bindings to Qt. Use the native drawing operations of the operating system (I think). Available on all platforms. Not sure if this is developed any more. http://dsource.org/projects/qtd * wxD - Bindings to wxWidgets. Use the native drawing operations of the operating system. Available on all platforms. Not sure of the status. http://wxd.sourceforge.net/ -- - Alex
Re: Mono-D@GSoC - Mentor needed
Jacob Carlborg wrote: Maybe the C# code go call the D code? The rest of MonoDevelop is written in C#. It's probably easier to interface with the IDE being written in C# and a port to D wouldn't bring anything new. I think it would be great to eventually port Alex's parser to D and make a stand alone D IDE but that's a much bigger project and doesn't help D in any critical way right now. Having an established cross-platform IDE support D in a way that's competitive to MS Visual Studios, does.
Re: Mono-D@GSoC - Mentor needed
On 2012-03-25 15:41, Armnin Kazmi wrote: I can't really agree here. Lets take the GSOC-List as the list of crucial points about the D language ecosystem which need to be fixed asap. All other stuff is extra and not even close as important. (Don't forget the mono-D plugin is written in C#, hence porting would be required with the implications of having to keep D and C# code in sync). Please don't let us lose focus here again... Maybe the C# code go call the D code? -- /Jacob Carlborg
Re: Why CTFE I/O would be awesome: No-Build-Tool Custom Build Steps
On 2012-03-23 02:12, Nick Sabalausky wrote:
(I'm branching this off from "Three Unlikely Successful Features of D")
At least one way I think CTFE I/O could be a really big thing:
A library could include any custom build steps it needed (or at least
pre-build steps) *in* the library itself without the library's user needing
to deal with buildscripts/buildtools. You can *kinda* do it now, but it
requires all the processing be done within the naturally-slow and
memory-hungry CTFE interpreter (compared to just running already-compiled
native code), and *everything* will be recomputed on every compile whether
it needs to be or not. So it'd be more of a curiosity right now than a real
professional approach. But with CTFE I/O, that can change, and I think that
could be a very big thing:
For example (and I apologize if this sounds like shameless promotion of my
project - but it's a good example of the scenarios I have in mind), the
typical expected workflow in most cases for Goldie Parsing System is like
this:
1. Run 'goldie-grmc' to compile your grammar definition from the BNF-like
GRM file to a CGT file ("compiled grammar tables" - ie, precomputed LALR and
DFA tables). This can take some real non-trivial time for non-trivial
grammars. 'Couse, I think I can still optimize it more, but the nature of
LALR still prevents this step from scaling well even when natively compiled,
let alone if it were to be run inside CTFE.
2. Run 'goldie-staticlang' on the CGT file to generate a D library
custom-tailered for your grammar.
3. Compile your program (which imports the generated D files from
'goldie-static'').
Obviously there's improvements I can still make, such allowing
'goldie-staticlang' to optionally do the job of 'goldie-grmc' (thus merging
steps 1 and 2). Or, it should be possible to make 'goldie-staticlang' (minus
any 'goldie-grmc' features) a CTFE-based library instead of an external
tool, once some DMD bugs are fixed. But there's *still* a custom build step
required, which you have to manually add into your buildscript, or even run
manually. And while that build step could theoretically be made CTFE-able,
it would be much less efficient, and would *considerably* slow down compile
times for *every* compile.
But:
If CTFE had I/O, I'm pretty sure I could set things up so that *all* you'd
need to do is step 3: import Goldie and compile your program. Then, inside
Goldie, there would be some CTFE that checks if the CGT file is missing or
out-of-date, and if so (and *only* if so), invokes 'goldie-grmc' on it
automatically - which will run at *full* natively-compiled efficiency. Then
it would do the same for 'goldie-staticlang' (although it should be
reasonable to make 'goldie-staticlang' an CTFE-based library instead of an
external tool, just with some existing DMD bugs fixed). And finally it would
import your either-already-existing-or-freshly-rebuilt custom-tailered D
library. Hell, it could even rebuild 'goldie-grmc' itself if it needed to!
All CTFE needs is system(), file I/O, and date/time stuff, and then need for
buildsystems could be heavily reduced and make external tools/libs easier to
use. I can see that being a big selling point for D.
That might even make it possible (though I haven't really thought it
through) to implement the dependency-searching feature of RDMD as a library.
Wouldn't you need to make sure DMD sees the correct D file before seeing
the other files?
--
/Jacob Carlborg
Re: Proposal: user defined attributes
On 2012-03-22 15:31, Artur Skawina wrote: For run-time accessible custom attributes (if those are even necessary), the lib solution wouldn't be much different than a built-in one anyway. artur Accessing the custom attributes at runtime are necessary. Serialization is one example that could take advantage of that. -- /Jacob Carlborg
Re: Proposal: user defined attributes
On 2012-03-22 08:17, Manu wrote: By this logic, I might as well stick with C++. It's 'possible' to do everything I need, but it makes my cry myself to sleep at night, and wastes insane amounts of time. Code simplicity and cleanliess on the front end IS important, it makes code reasable, maintainable. In a large code team, if someone has to go out of their way to understand some code, chances are, they won't understand it, and make improper or damaging changes to it. Or make improper implementations based on it. This will destroy your code across 5 years or so. In gamedev, the average engine codebase lasts 10+ years. Yes, I completely agree. -- /Jacob Carlborg
Re: Proposal: user defined attributes
On 2012-03-22 02:23, Tove wrote:
mixin(attr(q{struct Foo
{
@NonSerialized int x;
@NonSerialized int y;
int z;
}}));
void main()
{
auto m = [ __traits(allMembers, Foo) ];
writeln("Normal members of Foo:", m);
auto n = [ __traits(allMembers, Foo_Serializable) ];
writeln("Serializable members of Foo:", n);
}
Just really ugly and it creates a new type, completely unnecessary if D
supported user defined attributes.
--
/Jacob Carlborg
Re: What about putting array.empty in object.d?
On 2012-03-21 23:25, Simen Kjærås wrote:
I hope you mean canFind!("true")([3, 4, 5]);. canFind!"a" fails for
arrays where all elements are 0.
Yes. I'm not really familiar with canFind or std.algorithms in general.
--
/Jacob Carlborg
Re: How to use D for cross platform development?
On 2012-03-25 13:12, Bennie Copeland wrote: Hello all. I'm sorry if this has been addressed before. For a little background. I've been studying C++ with the intention of doing cross platform work on Windows, OSX, and eventually iOS and some other mobile OSes. My plan was to write cross platform shared libraries for the core functionality and implement the GUI using Win32, Cocoa, etc. Well, while C++ is powerful, I'm finding it a beast to work with. I kept thinking about abandoning C++ altogether and using C# with Mono until I stumbled upon D. D sounds exactly like what I am looking for, powerful yet productive and native. First I have to say that D is a great language for doing cross platform development. But for iOS there are a couple of big problems. The reference D compiler, DMD, does not have an ARM-backend. There are other compilers available though: LDC, the DMD frontend on the LLVM backend and GDC, the DMD frontend on the GCC backend. Second big problem is the D runtime does not support ARM. As far as I know, no one has ever used D on iOS. My question however is how to do D cross platform development. I can't seem to find any recent information about it. From what I have gathered so far it seems, shared libraries are possible on win/osx/linux, but only when linked against other D code. For linking against C, I can create a DLL in windows, but I can't create an .so in linux, and no information at all about OSX. Some of the information I found is years old and I can't tell if the situation has changed. There is nothing in the FAQ about libraries. And googling provides little information. You should be able to create shared libraries for linking with C code. You just need to make sure you initialize the D runtime. I'm not entirely sure about the status for creating shared libraries, not sure if the runtime has been modified to support that on all platforms. I think Windows and Linux is good to go but I don't think the runtime is not ready yet for Mac OS X. So, is it possible to write the core of an application in a cross platform D library that can be callable by C, C++, or Objective-C to provide the GUI elements? If not, is it possible to write a C wrapper around the library that is then callable by C, C++ or Objective-C? How have others approached this situation? Besides the library issues, what other issues or gotchas should I look out for in regards to cross platform development? When it comes to providing a GUI for your application there are a couple of choices: * Directly access the native GUI operations of the operating system * Use a cross platform GUI library For directly accessing the native GUI of the operating system there are again various options. First option, C wrapper. A C wrapper works for all languages you need to interact with: C, C++ and Objective-C. D has limited support for interfacing directly with C++. For example, D understand the C++ mangling and you can call virtual C++ functions from D. This could be another idea, or used together with C wrappers. http://dlang.org/cpp_interface.html For interfacing with Objective-C there are a couple of options as well. One option is to use C wrappers. Another is to use the Objective-C runtime functions to get be able to create Objective-C class and methods from D. There are two projects that have gone this road and created a fully working, fully automatic bridge between D and Objective-C. Although it turned out to not be usable in practice. A third option for Objective-C would be to use a fork of DMD that makes it possible to directly interface with Objective-C, just as it's possible with C. I'm not sure of the status of this project but an alpha has been released. D/Objective-C bridge: http://dsource.org/projects/dstep D/Objective-C bridge: http://michelf.com/projects/d-objc-bridge/ DMD fork: http://michelf.com/projects/d-objc/ Cross platform GUI libraries. Here are again several options: * DWT - Port of SWT. Uses the native operations of the operating system. Supports Windows (win32) and Linux (GTK+). Support for Mac OS X (Cocoa) is worked on. http://dsource.org/projects/dwt * gtkD - Bindings to GTK. Does not use the native drawing operations of the operating system. Available on all platforms. http://dsource.org/projects/gtkd * QtD - Bindings to Qt. Use the native drawing operations of the operating system (I think). Available on all platforms. Not sure if this is developed any more. http://dsource.org/projects/qtd * wxD - Bindings to wxWidgets. Use the native drawing operations of the operating system. Available on all platforms. Not sure of the status. http://wxd.sourceforge.net/ -- /Jacob Carlborg
digitalmars-d@puremagic.com
On 03/25/2012 06:00 AM, Tyro[17] wrote:
> I am trying to figure out the cause of my problem in the following post:
>
> http://forum.dlang.org/thread/qfbugjkrerfboqhvj...@forum.dlang.org
Sorry that I missed your question there. :(
> and encountered something peculiar about reading strings. Whenever a
> distinct terminator is indicated in the input format (ex. " %s@", @
> being the terminator), readf() leaves the terminator on the input buffer
> after reading the data. If no terminator is specified the only way to
> indicate end of input is to use ctrl-d (ctrl-z on windows), however that
> causes the eof indicator to be set to true and the stream is marked as
> empty for all future attempts to access stdin.
>
> void main(string[] args)
> {
> string s1;
> double d;
> string s2;
>
> writeln("Enter a @ terminated string (multiline ok):");
> readf(" %s@", &s1);
> auto arr = s1.split();
>
> if (!stdin.eof()) {
> writeln("The stream is not empty.");
> } else {
> writeln("The stream is empty.");
> }
> writeln("Enter another string (terminated with cntrl-d|ctrl-z):");
I am not sure about the cntrl-d|ctrl-z part though. Since it terminates
the input, the program should not be able to read any more characters.
> readf(" %s", &s2); // No matter how many read attempts
I advise reading string by readln(). You can call chomp() to get rid of
whitespace around it:
while (s2.length == 0) {
s2 = chomp(readln());
}
This has been my understanding of the matter: [1]
There are surprises even when reading strings from the console.
Being character arrays, strings can contain control characters like '\n'
as well. When reading strings from the input, the control character that
corresponds to the Enter key that is pressed at the end of console input
becomes a part of the string as well. Further, because there is no way
to tell readf() how many characters to read, it continues to read until
the end of the entire input. For these reasons, readf() does not work as
intended when reading strings:
> // are made after this point, none of them will work.
> // Insert \n after %s to see difference.
>
> writeln("Enter a decimal value:");
> readf(" %s", &d);
> //readf(" %s", &d);
> //readf(" %s", &d);
> //readf(" %s", &d);
> //readf(" %s", &d);
>
> if (!stdin.eof()) {
> writeln("The stream is not empty.");
> } else {
> writeln("The stream is empty.");
> }
>
> writeln("d = ", d);
> writeln("arr = ", arr);
> writeln("s = ", s2);
> }
>
> Is there no way to indicate eof without marking the stream (buffer?) as
> empty for all future uses after encountering cntrl-d/cntrl-z during
> string input? I would expect to be able to terminate string input with
> cntrl-d/cntrl-z without rendering the input stream inaccessible.
>
> Thanks,
> Andrew
With the change above (and assuming that we don't end the stream), the
rest of the reads succeed for me.
Ali
[1] http://ddili.org/ders/d.en/strings.html
Re: Use tango.core.Atomic.atomicLoad and atomicStore from Tango
Here is code:
import Integer = tango.text.convert.Integer;
import tango.math.random.Random;
import tango.core.Thread;
import tango.core.Atomic;
class MyThread :Thread {
bool* log;
this( bool* log ) {
super(&run);
this.log = log;
}
void run() {
auto rand = new Random();
if( rand.uniformR(2) == 0 ) {
//atomicStore!(msync.raw, bool)(*log, false);
//alias atomicStore!(msync.raw, bool) A;
//A.atomicStore(*log);
atomicStore!(msync.acq, bool).atomicStore(log);
}
}
}
void main(char[][] args) {
int n = Integer.parse(args[1]);
bool log = true;
for(int i = 0; i < n; i++)
(new MyThread( &log )).start();
}
Here are errors when I compiling program:
Error: function tango.core.Atomic.atomicStore!(cast(msync)5,b
ool,bool) does not match parameter types ()
Error: expected 2 function arguments, not 0
Error: no property 'atomicStore' for type 'void'
Error: function expected before (), not 1 of type int
I dont know what is wrong.
Re: Mono-D@GSoC - Mentor needed
On Saturday, 24 March 2012 at 03:07:10 UTC, dnewbie wrote: On Tuesday, 20 March 2012 at 22:52:13 UTC, James Miller wrote: A bit of a side note, but is there any way that some of this work could be made more standalone, even if somebody else has to take up the work to finish it and make it truly standalone. I personally can't stand fully integrated environments, but I do like things like code completion and the like, so it would be nice to be able to use these features in, for example, vim. I don't know how feasible this is, but it's worth mentioning. -- James Miller Yes!! I want a standalone version too. I like Mono-D very much, however, not being able to type the "~" key in MonoDevelog is really annoying. I can't really agree here. Lets take the GSOC-List as the list of crucial points about the D language ecosystem which need to be fixed asap. All other stuff is extra and not even close as important. (Don't forget the mono-D plugin is written in C#, hence porting would be required with the implications of having to keep D and C# code in sync). Please don't let us lose focus here again... 1. We need a proper IDE 2. We need the GC problems/issues get fixed (3. an official gc-less runtime) At least I consider those points crucial for the success of D. CTFE etc. are (very) nice things, but don't make the very core of D any stable now.
Re: How to use D for cross platform development?
On 25 March 2012 13:22, maarten van damme wrote: > Op 25 maart 2012 13:12 schreef Bennie Copeland het > volgende: > >> For linking against C, I can create a DLL in windows, but I can't create >> an .so in linux, and no information at all about OSX. > > > From what I've heard this was a certain bug > (http://d.puremagic.com/issues/show_bug.cgi?id=4583) that made it > impossible to generate position independent code and thus no shared objects. > This bug was fixed in dmd version 2.057 so it should work with dmd -c -fPIC > and then use gcc on your platform to create the shared object. > If you don't need/want to use dmd I think gdc is capable of doing it. The rule of thumb generally is if you are able to build a gcc C cross compiler, you can just tack gdc onto it and it will be fine. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
digitalmars-d@puremagic.com
I am trying to figure out the cause of my problem in the
following post:
http://forum.dlang.org/thread/qfbugjkrerfboqhvj...@forum.dlang.org
and encountered something peculiar about reading strings.
Whenever a distinct terminator is indicated in the input format
(ex. " %s@", @ being the terminator), readf() leaves the
terminator on the input buffer after reading the data. If no
terminator is specified the only way to indicate end of input is
to use ctrl-d (ctrl-z on windows), however that causes the eof
indicator to be set to true and the stream is marked as empty for
all future attempts to access stdin.
void main(string[] args)
{
string s1;
double d;
string s2;
writeln("Enter a @ terminated string (multiline ok):");
readf(" %s@", &s1);
auto arr = s1.split();
if (!stdin.eof()) {
writeln("The stream is not empty.");
} else {
writeln("The stream is empty.");
}
writeln("Enter another string (terminated with
cntrl-d|ctrl-z):");
readf(" %s", &s2); // No matter how many read attempts
// are made after this point,
none of them will work.
// Insert \n after %s to see
difference.
writeln("Enter a decimal value:");
readf(" %s", &d);
//readf(" %s", &d);
//readf(" %s", &d);
//readf(" %s", &d);
//readf(" %s", &d);
if (!stdin.eof()) {
writeln("The stream is not empty.");
} else {
writeln("The stream is empty.");
}
writeln("d = ", d);
writeln("arr = ", arr);
writeln("s = ", s2);
}
Is there no way to indicate eof without marking the stream
(buffer?) as empty for all future uses after encountering
cntrl-d/cntrl-z during string input? I would expect to be able to
terminate string input with cntrl-d/cntrl-z without rendering the
input stream inaccessible.
Thanks,
Andrew
Re: Use tango.core.Atomic.atomicLoad and atomicStore from Tango
On 25-03-2012 14:49, Lukasz Durniat wrote: Hi, When I use this function in program I have error during compiling proccess, so someone can show me how use(example) it in proper manner - without errors. I try find some samples or documentations but this dont help. Thanks for any help. You know, we kinda need some code and compiler errors to help you out here. -- - Alex
Use tango.core.Atomic.atomicLoad and atomicStore from Tango
Hi, When I use this function in program I have error during compiling proccess, so someone can show me how use(example) it in proper manner - without errors. I try find some samples or documentations but this dont help. Thanks for any help.
Re: How to use D for cross platform development?
Op 25 maart 2012 13:12 schreef Bennie Copeland het volgende: > For linking against C, I can create a DLL in windows, but I can't create > an .so in linux, and no information at all about OSX. >From what I've heard this was a certain bug ( http://d.puremagic.com/issues/show_bug.cgi?id=4583) that made it impossible to generate position independent code and thus no shared objects. This bug was fixed in dmd version 2.057 so it should work with dmd -c -fPIC and then use gcc on your platform to create the shared object. If you don't need/want to use dmd I think gdc is capable of doing it. Maarten
How to use D for cross platform development?
Hello all. I'm sorry if this has been addressed before. For a little background. I've been studying C++ with the intention of doing cross platform work on Windows, OSX, and eventually iOS and some other mobile OSes. My plan was to write cross platform shared libraries for the core functionality and implement the GUI using Win32, Cocoa, etc. Well, while C++ is powerful, I'm finding it a beast to work with. I kept thinking about abandoning C++ altogether and using C# with Mono until I stumbled upon D. D sounds exactly like what I am looking for, powerful yet productive and native. My question however is how to do D cross platform development. I can't seem to find any recent information about it. From what I have gathered so far it seems, shared libraries are possible on win/osx/linux, but only when linked against other D code. For linking against C, I can create a DLL in windows, but I can't create an .so in linux, and no information at all about OSX. Some of the information I found is years old and I can't tell if the situation has changed. There is nothing in the FAQ about libraries. And googling provides little information. So, is it possible to write the core of an application in a cross platform D library that can be callable by C, C++, or Objective-C to provide the GUI elements? If not, is it possible to write a C wrapper around the library that is then callable by C, C++ or Objective-C? How have others approached this situation? Besides the library issues, what other issues or gotchas should I look out for in regards to cross platform development?
Re: Using D for Soft Synth development
Thanks for the advices. I used bcd.gen to create the binding stubs in D. I will make a more lightweight D integration than the lv2-c++-tools. I will post the results on GitHub when simple examples are working.
Re: Array ops give sharing violation under Windows 7 64 bit?
On 24.03.2012 19:55, Walter Bright wrote:
I've been upgrading to a Windows 64 bit box. Running the D test suite, I
ran into a very strange problem. Here's the program:
---
extern(C) int printf(const char*, ...);
int main()
{
byte[3] a;
byte[3] b;
byte[3] c;
a[] = b[] + c[];
printf("Success\n");
return 0;
}
---
I run it from a cc.bat file that has the contents:
--
..\dmd test
test
..\dmd test
--
and the result is:
--
C:\test>..\dmd test
C:\test>test
Success
C:\test>..\dmd test
GetLastError = 32 test.exe
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Error 3: Cannot Create File test.exe
--- errorlevel 1
---
Note the failure to write out test.exe. I instrumented Optlink to figure
out why, and the CreateFile() returns error 32, which is "The process
cannot access the file because it is being used by another process."
If you run the commands by typing them in (not via a .bat file) it
works. If the array
operations are removed, it works. It works on Windows XP.
I'm mystified. Does anyone have any ideas?
Bug 6660. I don't understand it, but the minimal test case is very
simple, just a few asm instructions, no function calls.
As I reported there, all that is required is a use of CPUID 2 or 4. Any
use of CPUID 1 or 3 doesn't trigger the bug.
It seems to me as though somehow, one processor is being kept alive
after the process has ended.
I wasn't sure if this was an OS issue or a processor issue. But if
you're seeing this after upgrading an individual machine, it definitely
has to be a Windows 7 bug. I'm relieved to hear that someone else can
reproduce it.
