Re: Need direction guide
Sam Hu wrote: > I have learnt C++ for years and can write simple and short toys.I have been following and learning D for quite a while but I can do nothing except finding ppl like you giant seems just write libs at this moment.I believe D2 is getting mre powerful and stronger but it seems to me just a legend.So right at this moment,I am wondering: > 1.Whether D1 is useful to do something,or it is quite worth to wait for the stable or "finalized" verison of D2?If yes,what can one do using D1,I mean not just a toy,a test product,rather an serious tool? D1 is very useful and mature imho, you can do anything with it that it was designed for and them some more. The choice of D1 or D2 is not too difficult: D2 itself is still changing, compiler may have more bugs, and there are very, very few libraries for it. Even the dsss build tool does not work with latest versions of dmd2. This means: only usable for learning, building libraries and generally if you want to stay on top of the bleeding edge. Not so suitable for making applications yet. > 2.Are those feathers in D2 vital while D1 does not have?Or all these features are just for experienced programmers,a beginner can just ignore them at present? Both are true I think. They really are important improvements, but not in a way that makes D1 incomplete without them. > I am lost although I like D so much than C++.I would like to spend as much time as learning C++ and want to gain as much as gain C++ can offer me.Any constructive suggestions or guideline would be much appreicated. > > Regards, > Sam Is your goal for now *just* to learn D? Then you could start making toy programs with D2. Is your goal to learn D and make some cool programs? Then D1 will make that easier. Happy programming!
Re: D styled data format, Json failed
Saaa wrote: > > I looked at the JSON format and it seems very inefficient at loading arrays > as it isn't limited to one type per array. > This is nice when you want to save a small array with different typed > elements but for my purposes this is kind of a performance problem. > > This is why I will try and get suggestions again about the D-styled format I > tried to suggest a few threads ago :) > > Let me suggest a simple example: > (Please tell me when something isn't obvious :) > I guess you will have to write this one yourself, it will be to D what JSON is to javascript ;) I wonder how much of an performance improvement you will get though when loading data at runtime. You still have to parse and check everything since it remains a text based format. I know of one other solution but that's again not available for D: google protobuf: http://code.google.com/p/protobuf/ This uses a text-based format for describing the structure of the data, but the actual data can be in an optimized binary format.
Phobos2029 algorithm example can't compile
double[] a=[3.0,4,7,11,3,2,5];
auto ret=reduce!("a+a","a+b*b")(0.0,0.0,a);
phobos2Ex.d(13): Error: template
std.algorithm.Reduce!("a+a","a+b*b").reduce(E,Range) does not match any
function template declaration
phobos2Ex.d(13): Error: template
std.algorithm.Reduce!("a+a","a+b*b").reduce(E,Range) cannot deduce template
function from argument types !()(double,double,double[])
*** Errors occurred during this build ***
What's wrong here?Help.
Re: D styled data format, Json failed
"Saaa" wrote in message
news:gtlrs3$1b9...@digitalmars.com...
>
> I looked at the JSON format and it seems very inefficient at loading
> arrays as it isn't limited to one type per array.
> This is nice when you want to save a small array with different typed
> elements but for my purposes this is kind of a performance problem.
>
> This is why I will try and get suggestions again about the D-styled format
> I tried to suggest a few threads ago :)
>
> Let me suggest a simple example:
> (Please tell me when something isn't obvious :)
>
> ---file.dat
> //comment
> int number = 10;
>
> float [3][2] simpleArray = [
> [0.1, 0.2, 0.3],
> [0.4, 0.5, 0.6]];
> --
>
> ---main.d
> static import ddata;
> void main()
> {
> char[][] file = read (`file.dat`);
> int i;
> char c;
>
> ddata.get(file,'number',i);
> ddata.get(file,'number',c); //type fail, thus returns -1 or throws an
> exception
>
> float [3][2] a;
>
> ddata.get(file,'simpleArray',a);
> ddata.write(file,'simpleArrayCopy', a);
>
> a[0][0] =3.0;
>
> ddata.write(file,'simpleArray', a);
>
> write('file.dat', file);
> }
> --
>
> resulting data file:
>
> ---file.dat
> //comment
> int number = 10;
>
> float [3][2] simpleArray = [
> [3.0, 0.2, 0.3],
> [0.4, 0.5, 0.6]];
>
> float [3][2] simpleArrayCopy = [
> [0.1, 0.2, 0.3],
> [0.4, 0.5, 0.6]];
> --
>
>
I've run into similar problems when I wanted to save lots of stuff to a
file, and be able to load them again.
Huge multi-dimensional arrays seem to be an issue with JSON and similar..
Such a file writer as you propose would be very handy to have.
Re: "".dup is null
On Mon, 04 May 2009 12:09:09 -0400, Georg Wrede wrote: If I remember correctly, string literals are stored with a null appended, so as to make them easier to use with OS calls, etc. Could it be that "" stores a 1-byte string, consisting with just this null? Then this behavior would be understandable. Yes, that makes complete sense, thanks. -Steve
Re: "".dup is null
Steven Schveighoffer wrote:
On Mon, 04 May 2009 10:22:49 -0400, Qian Xu
wrote:
Steven Schveighoffer wrote:
I think you might have a bug?
"".dup is the same as s.dup, not sure why you would expect it to be
not-null.
-Steve
If I have not explained clearly.
Here is the full code:
char[] s;
assert(s is null);
assert(s.dup is null);
assert("" !is null); // OK
assert("".dup !is null); // FAILED
At least the last two lines behave not consistent.
Either both are failed, or both are passed.
OK, your original post was this:
assert( s.dup is null); // OK
assert("".dup !is null); // FAILED
The compiler always returns a null array if you dup an empty array. The
reason being: why allocate memory for something that is zero length?
If anything, the oddity is this line:
assert("" !is null);
If I remember correctly, string literals are stored with a null
appended, so as to make them easier to use with OS calls, etc. Could it
be that "" stores a 1-byte string, consisting with just this null? Then
this behavior would be understandable.
But of course, no memory is allocated for literals, so at least needless
memory allocation does not occur.
To be consistent, I think assert("" is null); should pass, but it's a
minor inconsistency at best.
I usually never compare arrays to null for this reason...
-Steve
Re: "".dup is null
On Mon, 04 May 2009 10:22:49 -0400, Qian Xu
wrote:
Steven Schveighoffer wrote:
I think you might have a bug?
"".dup is the same as s.dup, not sure why you would expect it to be
not-null.
-Steve
If I have not explained clearly.
Here is the full code:
char[] s;
assert(s is null);
assert(s.dup is null);
assert("" !is null); // OK
assert("".dup !is null); // FAILED
At least the last two lines behave not consistent.
Either both are failed, or both are passed.
OK, your original post was this:
assert( s.dup is null); // OK
assert("".dup !is null); // FAILED
The compiler always returns a null array if you dup an empty array. The
reason being: why allocate memory for something that is zero length?
If anything, the oddity is this line:
assert("" !is null);
But of course, no memory is allocated for literals, so at least needless
memory allocation does not occur.
To be consistent, I think assert("" is null); should pass, but it's a
minor inconsistency at best.
I usually never compare arrays to null for this reason...
-Steve
Re: "".dup is null
Steven Schveighoffer wrote:
> On Mon, 04 May 2009 09:46:57 -0400, Qian Xu
> wrote:
>
>> Hi All,
>>
>> The following code will throw an exception:
>> char[] s;
>> assert( s.dup is null); // OK
>> assert("".dup !is null); // FAILED
>>
>> "".dup is expectly also an empty string.
>> Is this a compiler bug?
>>
>
> I think you might have a bug?
>
> "".dup is the same as s.dup, not sure why you would expect it to be
> not-null.
>
> -Steve
They are not the same. s is null. "" is an empty string. empty string and
null are definitely two thing.
Re: "".dup is null
Steven Schveighoffer wrote:
> I think you might have a bug?
>
> "".dup is the same as s.dup, not sure why you would expect it to be
> not-null.
>
> -Steve
If I have not explained clearly.
Here is the full code:
char[] s;
assert(s is null);
assert(s.dup is null);
assert("" !is null); // OK
assert("".dup !is null); // FAILED
At least the last two lines behave not consistent.
Either both are failed, or both are passed.
Re: "".dup is null
On Mon, 04 May 2009 09:46:57 -0400, Qian Xu
wrote:
Hi All,
The following code will throw an exception:
char[] s;
assert( s.dup is null); // OK
assert("".dup !is null); // FAILED
"".dup is expectly also an empty string.
Is this a compiler bug?
I think you might have a bug?
"".dup is the same as s.dup, not sure why you would expect it to be
not-null.
-Steve
"".dup is null
Hi All,
The following code will throw an exception:
char[] s;
assert( s.dup is null); // OK
assert("".dup !is null); // FAILED
"".dup is expectly also an empty string.
Is this a compiler bug?
--Qian
Re: Need direction guide
On Mon, May 4, 2009 at 5:52 AM, Sam Hu wrote: > I do know many projects there written by D1,but how come D1 seems to ppl > just a pass-by,please correct me if I am wrong. Where do you get that impression? Most code that has been written in D has been written in D1. Most D libraries are D1-only or at least D1-compatible. There is a very small number of D2 projects, and given how much D2 and Phobos 2 are changing, I doubt that they're terribly stable. If you get the impression that since most of the discussions are about D2 then D1 is dead, well, no. It's just that D1 doesn't (and can't) change anymore, so there's no point discussing it.
Re: Need direction guide
On Mon, May 4, 2009 at 5:55 AM, Sam Hu wrote: > Correctness: > But to be honest,almost all D members in the forum are a bit lost for the > going of D1 vs D2--- > Here the "the forum "I mean the Chinese D forums. Then more of you should speak up in the newsgroups. Walter doesn't speak Chinese.
Re: Need direction guide
Correctness: But to be honest,almost all D members in the forum are a bit lost for the going of D1 vs D2--- Here the "the forum "I mean the Chinese D forums.
Re: Need direction guide
Hi Denis, Thanks so much for your prompt response. > > 1.Whether D1 is useful to do something,or it is quite worth to wait for > > the stable or "finalized" verison of D2?If yes,what can one do using > > D1,I mean not just a toy,a test product,rather an serious tool? > > It is very funny that you write that. D1 is a stable language and there is a > lot of code written using it. > There is absolutely nothing that can be written in C++ and can't be in D > (unless you are writing for a memory-limited embedded device). > In fact, D is a lot more powerful than C++ already, and it allows to you > complete the same task faster and with less code. > I do know many projects there written by D1,but how come D1 seems to ppl just a pass-by,please correct me if I am wrong. > > I am lost although I like D so much than C++.I would like to spend as > > much time as learning C++ and want to gain as much as gain C++ can offer > > me. Any constructive suggestions or guideline would be much appreicated. > > > > I'd suggest you to write more code, experience and knowledge comes with > practice. Pick a project and start writing code. Whenever you find a > difficulty, ask in newsgroups or in IRC (you usually get instant help there). > I'd also recommend you to find some people that use/learn D and speak your > language. For example, if you speak Chinese, d-programming-language-china.org > is a great resource for you. I believe there are a lot of people that would > be glad to help. > Yes,you are right, I am a member of d-programming-language-china.org.Actually there is another one D forum which I think is more open,serious,intuitive and productive: http://dlang.group.javaeye.com/ and I has tried to translate several Phobos lib into Chinese just as the others did. But to be honest,almost all D members in the forum are a bit lost for the going of D1 vs D2.We felt that D1 is workable but less less power than D2 or C++( almost not worth to use),D2 is what we expected and what we want but it seems we can never get it to work. Thanks again. Sam
Re: DLLs and headaches
D2; but actually, it kinda works. It crashes on freeing the library, but it loads fine. If I use std.stdio, link says that primary.__ModuleInfo is missing, but that just means it crashes during compile/link. That said, I'm very dissapointed that Runtime doesn't support Posix yet. Means I'll have to roll it myself anyway. -[Unknown] Don wrote: Unknown W. Brackets wrote: This is kinda complicated, hopefully someone will still read it and try it. DLLs typically don't have access to the host process. Sometimes, when creating plugins, such access may be desirable. The typical solution is to have the host and plugins both load a secondary DLL. I've tried to replicate this with D. I have a stub program, a "primary" dll, and a "plugin" dll. Although the solution in itself does work, I'm having a lot of problems and they seem related to D. But, maybe I'm just doing it all wrong? If I import std.stdio in a DLL, it won't compile. Period. Otherwise, the primary DLL never finishes - it just dies when it frees the plugin library. Is this D1 or D2? If D2 -- I haven't been able to get D2 DLLs to work at all. They just crash during the initialization (something to do with initialising the thread-locals, I think, but I haven't been able to track it down completely).
Re: Need direction guide
On Mon, 04 May 2009 12:29:54 +0400, Sam Hu wrote: I have learnt C++ for years and can write simple and short toys.I have been following and learning D for quite a while but I can do nothing except finding ppl like you giant seems just write libs at this moment.I believe D2 is getting mre powerful and stronger but it seems to me just a legend.So right at this moment,I am wondering: 1.Whether D1 is useful to do something,or it is quite worth to wait for the stable or "finalized" verison of D2?If yes,what can one do using D1,I mean not just a toy,a test product,rather an serious tool? It is very funny that you write that. D1 is a stable language and there is a lot of code written using it. There is absolutely nothing that can be written in C++ and can't be in D (unless you are writing for a memory-limited embedded device). In fact, D is a lot more powerful than C++ already, and it allows to you complete the same task faster and with less code. 2.Are those feathers in D2 vital while D1 does not have?Or all these features are just for experienced programmers,a beginner can just ignore them at present? I believe there is little difference between programming in D1 or D2 for a novice, but I'd recommend sticking with D1 for now because it is more stable, has a lot more code pre-written for you, common problems are solved, more experts available etc. I am lost although I like D so much than C++.I would like to spend as much time as learning C++ and want to gain as much as gain C++ can offer me. Any constructive suggestions or guideline would be much appreicated. I'd suggest you to write more code, experience and knowledge comes with practice. Pick a project and start writing code. Whenever you find a difficulty, ask in newsgroups or in IRC (you usually get instant help there). I'd also recommend you to find some people that use/learn D and speak your language. For example, if you speak Chinese, d-programming-language-china.org is a great resource for you. I believe there are a lot of people that would be glad to help. There is also russian community located at dprogramming.ru Regards, Sam
Need direction guide
I have learnt C++ for years and can write simple and short toys.I have been following and learning D for quite a while but I can do nothing except finding ppl like you giant seems just write libs at this moment.I believe D2 is getting mre powerful and stronger but it seems to me just a legend.So right at this moment,I am wondering: 1.Whether D1 is useful to do something,or it is quite worth to wait for the stable or "finalized" verison of D2?If yes,what can one do using D1,I mean not just a toy,a test product,rather an serious tool? 2.Are those feathers in D2 vital while D1 does not have?Or all these features are just for experienced programmers,a beginner can just ignore them at present? I am lost although I like D so much than C++.I would like to spend as much time as learning C++ and want to gain as much as gain C++ can offer me.Any constructive suggestions or guideline would be much appreicated. Regards, Sam
Re: DLLs and headaches
Unknown W. Brackets wrote: This is kinda complicated, hopefully someone will still read it and try it. DLLs typically don't have access to the host process. Sometimes, when creating plugins, such access may be desirable. The typical solution is to have the host and plugins both load a secondary DLL. I've tried to replicate this with D. I have a stub program, a "primary" dll, and a "plugin" dll. Although the solution in itself does work, I'm having a lot of problems and they seem related to D. But, maybe I'm just doing it all wrong? If I import std.stdio in a DLL, it won't compile. Period. Otherwise, the primary DLL never finishes - it just dies when it frees the plugin library. Is this D1 or D2? If D2 -- I haven't been able to get D2 DLLs to work at all. They just crash during the initialization (something to do with initialising the thread-locals, I think, but I haven't been able to track it down completely).
DLLs and headaches
This is kinda complicated, hopefully someone will still read it and try it.
DLLs typically don't have access to the host process. Sometimes, when
creating plugins, such access may be desirable. The typical solution is
to have the host and plugins both load a secondary DLL.
I've tried to replicate this with D. I have a stub program, a "primary"
dll, and a "plugin" dll.
Although the solution in itself does work, I'm having a lot of problems
and they seem related to D. But, maybe I'm just doing it all wrong?
If I import std.stdio in a DLL, it won't compile. Period. Otherwise,
the primary DLL never finishes - it just dies when it frees the plugin
library.
There are a bunch of files, unfortunately. Listing below:
--- test.d ---
import std.c.stdio;
import primary;
extern (C)
void* gc_getProxy();
// Just a stub to load the primary code.
int main()
{
printf("Entering main().\n");
primary_init(gc_getProxy());
int ret = primary_main();
primary_terminate();
printf("Exiting main().\n");
return ret;
}
-
--- plugin.d ---
import core.runtime;
import std.c.stdio;
import std.c.windows.windows;
import primary;
extern (Windows)
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
{
switch (ulReason)
{
case DLL_PROCESS_ATTACH:
printf("DLL_PROCESS_ATTACH -> plugin\n");
Runtime.initialize();
break;
case DLL_PROCESS_DETACH:
printf("DLL_PROCESS_DETACH -> plugin\n");
Runtime.terminate();
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
return false;
}
return true;
}
// This is just here to load a plugin and export anything.
export void dummy()
{
}
-
--- plugin.def ---
LIBRARY plugin
DESCRIPTION 'Plugin Example'
EXETYPE NT
CODEPRELOAD DISCARDABLE
DATAPRELOAD SINGLE
-
--- primary.d ---
import std.c.windows.windows;
import core.runtime;
import std.c.stdio;
// SKIP_RUNTIME uses Windows instead of Runtime.*, makes no difference.
// FAIL2 shows that it won't even compile with std.stdio.
version (FAIL2)
import std.stdio;
extern (Windows)
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
{
switch (ulReason)
{
case DLL_PROCESS_ATTACH:
printf("DLL_PROCESS_ATTACH -> primary\n");
Runtime.initialize();
break;
case DLL_PROCESS_DETACH:
printf("DLL_PROCESS_DETACH -> primary\n");
Runtime.terminate();
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
return false;
}
return true;
}
extern (C)
{
void gc_setProxy(void* p);
void gc_clrProxy();
}
export void primary_init(void* gc)
{
printf("primary_init()\n");
gc_setProxy(gc);
}
export void primary_terminate()
{
printf("primary_terminate()\n");
gc_clrProxy();
}
export int primary_main()
{
HMODULE h;
FARPROC fp;
bool unloaded;
printf("Start Dynamic Link...\n");
version (SKIP_RUNTIME)
h = LoadLibraryA("plugin.dll");
else
h = cast(HMODULE) Runtime.loadLibrary("plugin.dll");
if (h is null)
{
printf("error loading plugin.dll\n");
return 1;
}
version (FAIL2)
writefln("hi");
version (SKIP_RUNTIME)
unloaded = FreeLibrary(h) != 0;
else
unloaded = Runtime.unloadLibrary(h);
if (!unloaded)
{ printf("error freeing plugin.dll\n");
return 1;
}
printf("End...\n");
return 0;
}
-
--- primary.def ---
LIBRARY primary
DESCRIPTION 'Primary Program'
EXETYPE NT
CODEPRELOAD DISCARDABLE
DATAPRELOAD SINGLE
-
--- compilation ---
echo === Compile the primary DLL.
dmd primary.d primary.def -g -L/map
implib /noi /system primary.lib primary.dll
echo === Compile the example plugin.
dmd plugin.d plugin.def primary.lib -g -L/map
echo === Compile the stub.
dmd test.d primary.lib -g
-
Anyone know anything?
-[Unknown]
