Re: Are there desktop appications being developed in D currently?
On Sun, 2014-08-10 at 04:37 +, Puming via Digitalmars-d-learn wrote: […] I didn't know about that. I don't actually know much about Rust except the hype on hackernews :-) But nonetheless, this indicates that a serious application like a browser is a good driving force for a language to evolve. There is a Rust user group in London, it is having it's second meeting next week, and I am not going to be able to go :-( The first London Go user group meeting (at which I spoke) was about 20 people, within a year it became 120 people and 80 people unable to get in due to space limitations. Initial meeting were much more tutorial and introductory style, now the Go user group meetings are about applications and experiences, and indeed things that need to change about the language. If the Rust experience is even remotely like the Go experience there will be a strong group of users creating many, many good (and many, many, many bad) systems using it very quickly. As noted earlier in another thread there are maybe two or three D users within 50 miles of London so no meetings actually happen as yet. If we were able to push D as the language Facebook and other large companies are funding development of, this would be a hook to get some people to a meeting, much as Go was funded by Google and Rust is funded by Mozilla — Rust user group meetings are currently at Mozilla's offices in London, Go was originally meeting wherever but is now sponsored by CloudFlare and meets at Forward offices. Step 1 is obviously to have a Meetup group. Noticebly Go and Rust have an International overarching group and then each local group is separate. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: 'with(Foo):' not allowed, why?
I've given my thoughts on the D section. It would be heavily useful as a shorthand for enums you plan on using a lot in a switch case or something, beyond that it could be troublesome...
Re: Are there desktop appications being developed in D currently?
On Sunday, 10 August 2014 at 05:34:49 UTC, thedeemon wrote: On Sunday, 10 August 2014 at 04:41:45 UTC, Puming wrote: Photo processing app: Disk space visualizer and redundancy searcher: A tool for watching some folders and processing video files there... Interesting :-) Unfortunately they are all windows only apps, I don't have a windows machine. If you have Linux they work fine via Wine. Can I link them on my bookmarks about D projects? https://github.com/zhaopuming/awesome-d I'm not in position to decide if they're awesome or not. :) Not sure they fit into that list, but if you want to include a mention, I don't mind for sure. added your organization to : https://github.com/zhaopuming/awesome-d#organizations
Re: Multidimensional slice
On Saturday, 9 August 2014 at 21:03:45 UTC, H. S. Teoh via Digitalmars-d-learn wrote: I think you need 2.066 or later to get this to work. After adding (size_t dim) to opSlice, your code compiles fine with git HEAD. Hi Thanks for the quick reply. Indeed I can get it to work with 2.066 Remi
Re: tuple slicing operator
On Saturday, 9 August 2014 at 19:26:46 UTC, Meta wrote: On Saturday, 9 August 2014 at 16:39:34 UTC, Vlad Levenfeld wrote: I may be misunderstanding the intended semantics of the [] operator but I've come to interpret x[] to mean give me x as a range and this is the meaning I intend when I overload it in my own structs. But - auto z = tuple (1,1,1); pragma (msg, typeof(z)); // Tuple!(int, int, int) pragma (msg, typeof(z[])); // (int, int, int) Tuples are special. Tuple internally keeps a compiler tuple that it aliases to itself. Compiler tuples have a built-in static slice operator that no other type has. Since Tuple aliases a compiler tuple to itself internally, doing `z[]` actually forwards to the compiler tuple's static slice operator This DIP by Dicebot is relevant: http://wiki.dlang.org/DIP63 If implemented, it can be used to overload Tuple's slice operator.
Re: Are there desktop appications being developed in D currently?
On Sunday, 10 August 2014 at 04:37:20 UTC, Puming wrote: On Saturday, 9 August 2014 at 21:46:45 UTC, Peter Alexander wrote: On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote: Yes, rust is a more infantile language compared to D, but people are already using them to create complicate applications like browser! Rust was designed to build Servo. The people building Servo are the people building Rust. With all due respect to Rust, I don't think that counts as endorsement of the language. I didn't know about that. I don't actually know much about Rust except the hype on hackernews :-) But nonetheless, this indicates that a serious application like a browser is a good driving force for a language to evolve. I'm planning on tinkering with D over the next couple months on an idea to replace the web browser, which I laid out on this forum last year: http://forum.dlang.org/thread/tlpikltmamsfmqunn...@forum.dlang.org?page=3#post-dqddjhccpmxhgcssqtol:40forum.dlang.org The browser has gotten way too complex, it's time to design away much of that complexity. On the one hand, this might show D is a good language to try new ideas, instead of simply implementing old, obsolete ones. On the other hand, since it's much simpler, it's not really going to push the language like an overly complex browser might. ;)
Class parameters that are either setable at run-time or compile-time
Hello,
I am new to D. I am sorry if this question was already answered
or if it is trivial. I am having a class. That class takes
several parameters that may be known at either compile time or
run time. I want users of my class to be able to pass the
parameters either as template parameters to the class or to the
constructor of that class. At the moment, I have got the
following code:
class X(int a = some_dummy_value, int b = some_dummy_value)
{
static if (a == some_dummy_value) static immutable int a_
= a;
else immutable int a_;
// etc.
this(int a = some_dummy_value, int b = some_dummy_value) {
static if (a != some_dummy_value) this.a_ = a;
static if (b != some_dummy_value) this.b_ = b;
}
};
This works, as far as I can tell. But there is one problem: users
may forget to provide the value at compile time and run time. In
that case, the members a_, b_ end up with some_dummy_values. Of
course, I can notify the user at run time about this
misbehaviour, but I would prefer to tell them at compile time.
The only solution I am aware of is to use static if in order to
provide one of four constructors depending on the compile time
values of a, b, i.e.
* none provided at compile time,
* a provided at compile time,
* b provided at compile time,
* both provided at compile time.
This is perfectly fine for one or two arguments, but I have
gotten three of them (i.e. 8 constructors) and may want to add
more later on. Since the number of constructors scales
exponentially with the number of parameters, I have a feeling
that this approach won't scale well.
Is there any elegant solution to the problem?
By the way, this is why I am doing this: Depending on the values
of a and b, the class chooses how to implement some parts of its
interface; if a or b are not provided, it may choose generic but
slow fall back implementations. If there is any other solution to
that problem, I also would like to know.
Thanks a lot and I hope this is how this mailing list works!
Best regards,
Markus Mayr
Re: Class parameters that are either setable at run-time or compile-time
On 10/08/2014 10:47 p.m., Markus Mayr wrote:
Hello,
I am new to D. I am sorry if this question was already answered or if it
is trivial. I am having a class. That class takes several parameters
that may be known at either compile time or run time. I want users of my
class to be able to pass the parameters either as template parameters to
the class or to the constructor of that class. At the moment, I have got
the following code:
class X(int a = some_dummy_value, int b = some_dummy_value)
{
static if (a == some_dummy_value) static immutable int a_ = a;
else immutable int a_;
// etc.
this(int a = some_dummy_value, int b = some_dummy_value) {
static if (a != some_dummy_value) this.a_ = a;
static if (b != some_dummy_value) this.b_ = b;
}
};
This works, as far as I can tell. But there is one problem: users may
forget to provide the value at compile time and run time. In that case,
the members a_, b_ end up with some_dummy_values. Of course, I can
notify the user at run time about this misbehaviour, but I would prefer
to tell them at compile time.
The only solution I am aware of is to use static if in order to provide
one of four constructors depending on the compile time values of a, b, i.e.
* none provided at compile time,
* a provided at compile time,
* b provided at compile time,
* both provided at compile time.
This is perfectly fine for one or two arguments, but I have gotten three
of them (i.e. 8 constructors) and may want to add more later on. Since
the number of constructors scales exponentially with the number of
parameters, I have a feeling that this approach won't scale well.
Is there any elegant solution to the problem?
By the way, this is why I am doing this: Depending on the values of a
and b, the class chooses how to implement some parts of its interface;
if a or b are not provided, it may choose generic but slow fall back
implementations. If there is any other solution to that problem, I also
would like to know.
Thanks a lot and I hope this is how this mailing list works!
Best regards,
Markus Mayr
Unless you need to change the defaults of the values being passed in,
don't pass them by template parameters.
Please please please use constructors. They work at both compile time
and runtime.
Remember every change in template parameters equals a new type.
http://dlang.org/class.html#constructors
undefined references
I'm compiling with DMD 2.065 using dub, and I've gotten some undefined reference errors for symbols inside my own project. Trying to run dustmite doesn't help, it keeps reporting that its done in one iteration, and gives me an empty results folder. I've used it before, its pretty straightforward, not sure whats going wrong. I'm not sure what else to try. This is my first encounter with a linker error that didn't have to do with an external library.
Re: Are there desktop appications being developed in D currently?
I wrote a terminal emulator in D a while ago https://github.com/adamdruppe/terminal-emulator terminal emulators are pretty boring as far as desktop applications go though. I have more on my to do list but haven't actually gotten to them yet.
Re: Are there desktop appications being developed in D currently?
My thing works on Windows and Linux btw, though the windows version pipes to the plink program to talk to ssh. It'd be pretty easy to make it a stand alone thing though with a few tweaks, then it could be like an escape sequence handling library.
Communication between D and C with dynamic arrays
In D, arrays are dynamic. However, to the best of my knowledge, in C, they are static. I am having difficulty in imagining how to send D arrays to a C function. My first Idea was to make a pointer to the array. then find the size of the array, which itself is an array, therefore take the pointer to it, then get the dimension of the array, which is an integer, and send the trio of two pointers and the dimesion to the C code. Now this arises two questions : 1. I assume that D allocates a particular space to the array, say N elements, and up to these N elements, you can increment the pointers, to jump to next array element. What happens if the N element space is used up? Does the pointer incrementing method break down? 2. in D pointers are being converted to void * as I read in the reply to another post of mine. I dont remember in my knowledge of C, that they are accepted in C, are they? Do I have to meake a type retrospection every time I get send something to C? Any help is appreciated. PS: is there a built in size operator for arrays in D?
Re: Are there desktop appications being developed in D currently?
Wow, it just happens that I checked your terminal.d code on the list an hour ago :-) Definitely gonna look at it. What do you mean by 'boring'? I think a shell in D would be awesome. I'm planning to make a shell scripting lib in D, I would like it to be very powerful, but my coding skills was holding me back. Here is a list of what I want it to be: 1. multimode. I want it to combine shell and repl, I don't like that in the other repl you lose the ablility to call normal shell commands. So I think this shell could have a multiple mode just like what vi does: you change to a different mode by a key stroke. This will make it seemless to switch between repl mode and shell mode and other modes. 2. repl. 3. shell mode that interacts with repl. For example, the results of each shell command call will be stored in a repl variable for further repl computing. 4. remote mode. A config file sets up remote machines access, then we can call shell commands repl commands as if on the remote machine, and even do them concurrently. It should also make resource/code syncing between machines easy(with rsync and lftp style of remote file management). 5. MVC style input/output. The out put of commands can be formated with a template (with color and indentations, even markdown support). traditional shell outputs are a mess. 6. bookmarks of every thing. Folders\Variables\routine commands\remote resources 7. autocomplete and auto style. write colorful code in the repl. Vi/emacs support of inline editing is also a plus. 8. dub support. You can create a project in the shell, and import dependencies interactly, and the dub.json will be updated as you type. 9. interactive coding building. Interact with editors, and with dub and repl support, we can write code in a interactive way. You try some code in the repl and fit it into the project, no copy/pasting required. All these combined will become a very complicated project, far beyond my ability. Currently I'm only doing item 4 and 5. (item 4 was my initial requirement, we need a tool to manage shell scripts on multiple servers). I heard that someone was writing a repl, but forgot where it is, I'm waiting for it. On Sunday, 10 August 2014 at 13:23:25 UTC, Adam D. Ruppe wrote: I wrote a terminal emulator in D a while ago https://github.com/adamdruppe/terminal-emulator terminal emulators are pretty boring as far as desktop applications go though. I have more on my to do list but haven't actually gotten to them yet.
Re: Are there desktop appications being developed in D currently?
Sorry for my misunderstanding. After looking at your code I realized that your terminal emulator is a GUI application and I was responding about a shell :-) Nonetheless, a terminal emulator is a very interesting tool. On Sunday, 10 August 2014 at 13:25:32 UTC, Adam D. Ruppe wrote: My thing works on Windows and Linux btw, though the windows version pipes to the plink program to talk to ssh. It'd be pretty easy to make it a stand alone thing though with a few tweaks, then it could be like an escape sequence handling library.
Re: Communication between D and C with dynamic arrays
On Sun, 10 Aug 2014 14:26:27 +
seany via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
I am having difficulty in imagining how to send D arrays to a C
function.
do something like this:
=== C SIDE ===
void c_array_processing (int *items, size_t item_count) {
// use items pointer as normal C-like array pointer
...
}
=== D SIDE ===
extern(C) void c_array_processing (int* items, size_t item_count);
int[] arr;
...
arr ~= 42;
...
c_array_processing(arr.ptr, arr.length);
PS: is there a built in size operator for arrays in D?
if you want to get size of all array items, do this:
size_t dataSize = arr[0].sizeof*arr[0].length;
if you want to get the size of the internal array structure... just
don't do that. it's better to not use internal compiler and runtime
structures.
signature.asc
Description: PGP signature
Re: Class parameters that are either setable at run-time or compile-time
On Sunday, 10 August 2014 at 10:47:34 UTC, Markus Mayr wrote:
Hello,
I am new to D. I am sorry if this question was already answered
or if it is trivial. I am having a class. That class takes
several parameters that may be known at either compile time or
run time. I want users of my class to be able to pass the
parameters either as template parameters to the class or to the
constructor of that class. At the moment, I have got the
following code:
class X(int a = some_dummy_value, int b = some_dummy_value)
{
static if (a == some_dummy_value) static immutable int
a_ = a;
else immutable int a_;
// etc.
this(int a = some_dummy_value, int b =
some_dummy_value) {
static if (a != some_dummy_value) this.a_ = a;
static if (b != some_dummy_value) this.b_ = b;
}
};
This works, as far as I can tell. But there is one problem:
users may forget to provide the value at compile time and run
time. In that case, the members a_, b_ end up with
some_dummy_values. Of course, I can notify the user at run time
about this misbehaviour, but I would prefer to tell them at
compile time.
The only solution I am aware of is to use static if in order to
provide one of four constructors depending on the compile time
values of a, b, i.e.
* none provided at compile time,
* a provided at compile time,
* b provided at compile time,
* both provided at compile time.
This is perfectly fine for one or two arguments, but I have
gotten three of them (i.e. 8 constructors) and may want to add
more later on. Since the number of constructors scales
exponentially with the number of parameters, I have a feeling
that this approach won't scale well.
Is there any elegant solution to the problem?
By the way, this is why I am doing this: Depending on the
values of a and b, the class chooses how to implement some
parts of its interface; if a or b are not provided, it may
choose generic but slow fall back implementations. If there is
any other solution to that problem, I also would like to know.
Thanks a lot and I hope this is how this mailing list works!
Best regards,
Markus Mayr
A couple of words (search terms) pop up in my mind:
1) inversion of control / Dependency injection.
The class has a member which does the actual work. This member is
a reference to an object passed in e.g. the constructor.
2) Factory pattern
A Factory determines how the object are created. Don't let the
objects do that themselves. This breaks the single responsibility
'rule'. Note that a Factory works nice together with 1).
3) Inheritance. You could create multiple classes which override
certain functions. This also works with 1) and 2)
Re: Communication between D and C with dynamic arrays
Thank you, so the running out of space problem is taken care of automatically?
Re: Communication between D and C with dynamic arrays
On Sun, 10 Aug 2014 15:24:29 + seany via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Thank you, so the running out of space problem is taken care of automatically? from D side -- yes. just don't store passed pointer on C side, 'cause it can be changed on array resize. but if you want to be able to resize the array from C side, than this is completely different story. D has it's own memory maganer, so you can't easily use malloc() and company from libc. signature.asc Description: PGP signature
Re: Communication between D and C with dynamic arrays
On Sunday, 10 August 2014 at 15:34:30 UTC, ketmar via Digitalmars-d-learn wrote: from D side -- yes. just don't store passed pointer on C side, 'cause it can be changed on array resize. Excellent, So if I have int [] array; void * ptr_to_array = array; /* populate array here */ C_Function(ptr_to_array); /* repopulate array here, the pointer itself may change, but the variable ptr_to_array will be updated accordingly */ C_Function(ptr_to_array); I am okey? Also, similar arguments with structs apply?
Re: Communication between D and C with dynamic arrays
On Sunday, 10 August 2014 at 14:26:29 UTC, seany wrote:
In D, arrays are dynamic. However, to the best of my knowledge,
in C, they are static.
I am having difficulty in imagining how to send D arrays to a C
function.
My first Idea was to make a pointer to the array. then find the
size of the array, which itself is an array, therefore take the
pointer to it, then get the dimension of the array, which is an
integer, and send the trio of two pointers and the dimesion to
the C code.
In D, there both dynamic and static arrays. The static ones are
those whose length is known at compile time, i.e.
int[10] my_numbers;
These are treated as value types, not references. When a function
takes a static array, it receives a copy of the entire array, not
a reference to it:
void foo(int[4] data);
This has no direct equivalent in C.
Then there are dynamic arrays. Under the hood, a dynamic array
with elements of type T is actually a struct (well, it behaves as
if it is one):
struct DynamicArray {
size_t length;
T* ptr;
}
With T being the specific type. (The length and ptr members might
be in the opposite order.) You can always access the length and
pointer of both types of arrays:
void main() {
import std.stdio;
int[2] static_array;
int[] dynamic_array;
writeln(static_array.length); // 2
writeln(dynamic_array.length);// 0
dynamic_array ~= [1,2,3,4]; // append elements
writeln(dynamic_array.length);// 4
// you can even set the length
writeln(dynamic_array); // [1, 2, 3, 4]
dynamic_array.length = 2;
writeln(dynamic_array); // [1, 2]
// growing fills the array with default value
dynamic_array.length = 4;
writeln(dynamic_array); // [1, 2, 0, 0]
// slicing
dynamic_array = static_array[]; // dyn.a. now points to
stat.a.
// dynamic_array.length == static_array.length
// dynamic_array.ptr== static_array.ptr
}
The details of arrays in D are described here:
http://dlang.org/arrays
As for communicating with C, it depends.
Some C functions only take a pointer to an array. They either
already know the length from somewhere else, or they use a
special value in the array as a signal that the array ends there.
The latter is typically used for strings, which are defined to
end with a 0 byte. For passing arrays to these C functions, you
can use the `ptr` property; alternatively, you can take the
address of the first element.
extern(C) my_c_func(int* data);
int[] a = [1,2,3,4,5];
my_c_func(a.ptr);
my_c_func((a[0]));
Of course, you may need to make sure that the array actually
contains the magic value at its end. For strings, this can be
done with std.string.toStringz:
http://dlang.org/phobos/std_string.html#.toStringz
In most cases, however, the C function also accepts the length of
the array. For these, you need to use the `length` property:
extern(C) my_other_c_func(int* data, size_t length);
int[] b = [6,7,8,9];
my_other_c_func(b.ptr, b.length);
Now this arises two questions :
1. I assume that D allocates a particular space to the array,
say N elements, and up to these N elements, you can increment
the pointers, to jump to next array element.
What happens if the N element space is used up? Does the
pointer incrementing method break down?
Yes, the array elements are stored next to each other in memory,
without gaps. By default, D checks whether you are still inside
the bounds of the array, and raises an error if you access an
element outside of the bounds. But this only works if you access
the array directly using an index, or slicing:
int[] a = [10,11,12,13];
writeln(a[0]); // 10
writeln(a[3]); // 13
//writeln(a[4]); // ERROR
// slicing: indices 1 (incl.) up to 3 (excl.)
writeln(a[1 .. 3]);// [11, 12]
// length is represented by $
writeln(a[2 .. $]);// [12, 13]
//writeln(a[0 .. 5]); // ERROR
You mentioned incrementing a pointer. This does work, just like
in C, but if you do this, you are responsible for checking the
array bounds. The language cannot help you there. If you access
something outside of the array, it's undefined behaviour:
int[] a = [20,30,40,50];
int* b = a.ptr;
writeln(*b); // 20
writeln(b[0]); // 20
writeln(b[0 .. 4]);// [20, 30, 40, 50]
//writeln(b[0 .. $]); // doesn't compiler, length is unknown
b++;
writeln(b[0]); // 30
//writeln(b[100]); // ???
// might print garbage, might crash, might eat your
harddisk...
2. in D pointers are being converted to void * as I read in the
reply to another post of mine. I dont remember in my knowledge
of C, that they are accepted in C, are they? Do I have to meake
a type retrospection every time I get
Re: Communication between D and C with dynamic arrays
On Sunday, 10 August 2014 at 15:37:41 UTC, seany wrote: On Sunday, 10 August 2014 at 15:34:30 UTC, ketmar via Digitalmars-d-learn wrote: from D side -- yes. just don't store passed pointer on C side, 'cause it can be changed on array resize. Excellent, So if I have int [] array; void * ptr_to_array = array; Don't do that. `array` is not the same as `array.ptr`. Use `array.ptr`. `array` would be a pointer to the local variable `array`. /* populate array here */ C_Function(ptr_to_array); /* repopulate array here, the pointer itself may change, but the variable ptr_to_array will be updated accordingly */ C_Function(ptr_to_array); I am okey? I'm not sure if you got that right: ptr_to_array will not be updated automatically. You have to do that yourself. Also, if C_Function has only one parameter which is a pointer, make sure the array has the proper length, or that is has a proper terminator element (char* arguments must usually be zero-terminated).
Re: Are there desktop appications being developed in D currently?
On Sunday, 10 August 2014 at 14:28:33 UTC, Puming wrote: What do you mean by 'boring'? I think a shell in D would be awesome. tbh I think shells are a bit boring too, but like you said in the other message, they are two different things. But a terminal emulator isn't much of a gui because all it displays is text (and mine actually can display pictures too) - no buttons, text areas, checkboxes, etc. like typically comes to mind when you think of a desktop gui app. I've been slowly writing a miniature gui widget library too, with the goal of zero dependencies and 300kb compiled executables... but I just haven't had the time. Whenever I need a quick gui for a personal project I've actually been outputting html or something and reading the response with my cgi.d. html forms cover like 95% of my use cases. 5. MVC style input/output. The out put of commands can be formated with a template (with color and indentations, even markdown support). traditional shell outputs are a mess. I like what Windows Powershell does - it talks in objects which can be formatted to string or passed to other commands that understand them. For a while, I was toying with doing that in D too. I don't remember where I put the file (a super-simplified version is in my book somewhere though)... but the shell commands were actually just D functions that return strongly typed stuff. When composing them, it calls the function directly and communicating with external commands it does some simple toString serialization and deserialization so that works too. But I haven't finished it in great part because I find regular old bash to work well enough for me. 7. autocomplete and auto style. write colorful code in the repl. Vi/emacs support of inline editing is also a plus. gnu readline which bash uses allows the editing and autocomplete which is cool.
opApply outside of struct/class scope
I'm trying to implement a opApply outside of struct scope
struct A{
int[] arr;
}
int opApply(ref A a,int delegate(ref int) dg){
return 0;
}
void main(){
A a;
foreach(i;a){//i just want it to compile
}
}
when i try compiling, the compiler errors:
test.d(9): Error: invalid foreach aggregate a
Is there any why i can put a opApply outside of a struct scope,if
so is there any why that the opApply can be templated
Re: opApply outside of struct/class scope
On Sunday, 10 August 2014 at 18:45:00 UTC, Freddy wrote: Is there any why i can put a opApply outside of a struct scope No overloaded operators in D can be put outside of a struct or class. They have to be member functions. - Jonathan M Davis
Re: opApply outside of struct/class scope
On Sunday, 10 August 2014 at 18:58:50 UTC, Jonathan M Davis wrote: No overloaded operators in D can be put outside of a struct or class. They have to be member functions. If I remember right, opApply was somewhat broken and only worked correctly in a few cases. But that was 18 months ago, a lot could have happened...
Re: Communication between D and C with dynamic arrays
So here is the final situtaion
I have a file: software_pluginInterface.di
Here I declare :
extern (C): void performComputation(char lib[], char func[],
void* ptr[], int varNum );
// lib and func will be used later
Then i have the corresponding C file: software_pluginInterface.c,
where I declare :
#include stdio.h
#include string.h
void performComputation(char lib[], char func[], void * v[], int
varNum)
{
printf(there are %d variables \n, varNum);
}
then I call this with :
performComputation(A, B, V, to!int(v.count()/3));
A, B are '\0' terminated char arrarys
V is a void pointer array with 6 elements
So I would expect a output like :
there are 2 variables
But I am getting : there are 1557197040 variables
Please help.
Re: Communication between D and C with dynamic arrays
of course I read this : http://dlang.org/interfaceToC.html I have 64 bit OS
Re: Communication between D and C with dynamic arrays
Solved : http://stackoverflow.com/questions/25232194/c-and-d-communication/25232265#25232265
Re: opApply outside of struct/class scope
On Sunday, 10 August 2014 at 19:01:18 UTC, Era Scarecrow wrote: On Sunday, 10 August 2014 at 18:58:50 UTC, Jonathan M Davis wrote: No overloaded operators in D can be put outside of a struct or class. They have to be member functions. If I remember right, opApply was somewhat broken and only worked correctly in a few cases. But that was 18 months ago, a lot could have happened... I'm not aware of opApply being broken, but I never use it, since in most cases where you might use opApply, you can use ranges, and they're far more flexible. But regardless, it's not legal to declare an overloaded operator outside of the type that it's for, so whether you're talking about opApply, opBinary, opAssign, or any other overloaded operator, declaring it as a free function like the OP is trying to do isn't going to work. - Jonathan M Davis
Re: opApply outside of struct/class scope
On Sunday, 10 August 2014 at 21:57:29 UTC, Jonathan M Davis wrote: I'm not aware of opApply being broken, but I never use it, I remember very specifically it was brought up, that opApply was not working correctly and you could only use it with a very specific cases because... the implementation was incomplete? I think the discussion was partially on removing opApply from BitArray and going for a range or array approach instead because the problem would go away, but a lot of this is fuzzy and from memory. I have so much to catch up on :(
Re: opApply outside of struct/class scope
On Sunday, 10 August 2014 at 22:03:28 UTC, Era Scarecrow wrote: I remember very specifically it was brought up, On Wed, Jul 09, 2014 at 03:16:37PM -0700, H. S. Teoh via Digitalmars-d wrote: Judging from this, a big missing piece of the current implementation is the actual enforcement of 'scope'. Or it was that scope was originally suppose to be part of the opApply and that's what i'm thinking about stuff i find in other threads...
Re: Are there desktop appications being developed in D currently?
On Sunday, 10 August 2014 at 18:40:23 UTC, Adam D. Ruppe wrote: On Sunday, 10 August 2014 at 14:28:33 UTC, Puming wrote: What do you mean by 'boring'? I think a shell in D would be awesome. tbh I think shells are a bit boring too, but like you said in the other message, they are two different things. But a terminal emulator isn't much of a gui because all it displays is text (and mine actually can display pictures too) - no buttons, text areas, checkboxes, etc. like typically comes to mind when you think of a desktop gui app. http://xiki.org/ provides a more GUI like terminal that has more gui widgets. xcode's swift language playground also shows a more visiual way of doing repl. I've been slowly writing a miniature gui widget library too, with the goal of zero dependencies and 300kb compiled executables... but I just haven't had the time. Whenever I need a quick gui for a personal project I've actually been outputting html or something and reading the response with my cgi.d. html forms cover like 95% of my use cases. 5. MVC style input/output. The out put of commands can be formated with a template (with color and indentations, even markdown support). traditional shell outputs are a mess. I like what Windows Powershell does - it talks in objects which can be formatted to string or passed to other commands that understand them. Wow, I didn't know about that. This is another thing that windows does better. For a while, I was toying with doing that in D too. I don't remember where I put the file (a super-simplified version is in my book somewhere though)... but the shell commands were actually just D functions that return strongly typed stuff. When composing them, it calls the function directly and communicating with external commands it does some simple toString serialization and deserialization so that works too. But I haven't finished it in great part because I find regular old bash to work well enough for me. 7. autocomplete and auto style. write colorful code in the repl. Vi/emacs support of inline editing is also a plus. gnu readline which bash uses allows the editing and autocomplete which is cool. Thanks, I'll try that.
Re: Communication between D and C with dynamic arrays
On Sun, 10 Aug 2014 19:39:29 + seany via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Solved : http://stackoverflow.com/questions/25232194/c-and-d-communication/25232265#25232265 almost exactly what i wrote in my first reply. except that i wrote about using .ptr and size_t for item counter too. signature.asc Description: PGP signature
Re: opApply outside of struct/class scope
On Sunday, 10 August 2014 at 22:03:28 UTC, Era Scarecrow wrote: On Sunday, 10 August 2014 at 21:57:29 UTC, Jonathan M Davis wrote: I'm not aware of opApply being broken, but I never use it, I remember very specifically it was brought up, that opApply was not working correctly and you could only use it with a very specific cases because... the implementation was incomplete? I think the discussion was partially on removing opApply from BitArray and going for a range or array approach instead because the problem would go away, but a lot of this is fuzzy and from memory. I have so much to catch up on :( IIRC, opApply doesn't play well with various attributes, but I don't remember the details. That's the only issue with opApply that I'm aware of. It looks like you'll have to go digging into those other threads if you want to know what was supposed to be wrong with it. - Jonathan M Davis
Re: opApply outside of struct/class scope
On Monday, 11 August 2014 at 02:03:15 UTC, Jonathan M Davis wrote: IIRC, opApply doesn't play well with various attributes, but I don't remember the details. That's the only issue with opApply that I'm aware of. It looks like you'll have to go digging into those other threads if you want to know what was supposed to be wrong with it. Pretty sure it was the scope keyword rather than opApply. Maybe that it didn't play well with out or inout or some combination, or const or something... http://forum.dlang.org/thread/mailman.1363.1339173331.24740.digitalmars-d-le...@puremagic.com Oh well. Not important enough to keep talking about.
Re: undefined references
Ok, I've gotten to the bottom of this issue but I'm not totally
sure how to submit a bug report for this (no SSCCE: can't get
dustmite to work on it, and the problem won't show itself when I
use the offending module in isolation) so I will try to sum up
the issue and maybe I can provide some useful information for the
devs.
I have a generic Vector struct that is constructed by helper
functions that deduce the length and element type and forward the
arguments to the appropriate constructor. Almost all of them had
a constraint on them that required the length of the vector the
be at least 2, but the Vector class itself had no such
constraint, and one of the helper functions was missing it as
well.
When I added the constraint to either the Vector struct or the
helper function (I've since added them to both) then everything
links fine. It looks like what was happening was that a fill
constructor helper function (intended use: vector!4 (x) =
vector (x, x, x, x)) was routing to a variadic constructor
helper function (vector (args) = vector!(args.length)(args))
that attempted to generate a 1-element vector and somewhere along
the way - linker error.
There are the mangled names that the linker could not resolve
references to:
`_D3evx7vectors16__T6VectorVm1TdZ6Vector6__initZ`
`_D3evx7vectors16__T6VectorVm1TdZ6Vector6__ctorMFNaNbNcNfdZS3evx7vectors16__T6VectorVm1TdZ6Vector`
the second of which demangles to this:
pure nothrow ref @safe evx.vectors.Vector!(1uL, double).Vector
evx.vectors.Vector!(1uL, double).Vector.__ctor(double)
So, there's my one-element vector constructor, which is likely
having a hard time with the following overloads:
this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}
So, while the mistake was mine, this should be an ambiguous
overload error at compile-time, instead of a linker error.
I realize that everyone contributing to D has their hands more
than full, and a bug this rare (assumption based on lack of
search results) is gonna be low-priority, so I'm just making this
post for posterity - maybe it'll help, and of course I'm happy to
try anything and give additional information. If anyone has any
suggestions on how I might go about making a useful bug report
out of this, I'm all ears.
Re: undefined references
On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]
this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}
[snip]
The following gives an error in 2066
struct S(F, size_t L)
{
F[L] c;
this(E...)(E el)
if(E.length == L)
{
foreach(i, e; el) {
c[i]= e;
}
}
this(F e) {
c[0] = e;
}
}
void main()
{
auto s = S!(double, 1)(1);
auto s = S!(double, 3)(1,2,3); // -- ERROR: declaration
hacks.main.s is already defined
}
Cheers,
uri
Re: undefined references
On Monday, 11 August 2014 at 04:02:12 UTC, uri wrote:
On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]
this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}
[snip]
The following gives an error in 2066
struct S(F, size_t L)
{
F[L] c;
this(E...)(E el)
if(E.length == L)
{
foreach(i, e; el) {
c[i]= e;
}
}
this(F e) {
c[0] = e;
}
}
void main()
{
auto s = S!(double, 1)(1);
auto s = S!(double, 3)(1,2,3); // -- ERROR: declaration
hacks.main.s is already defined
}
Cheers,
uri
Bah, never mind me I'm having a moment !
The above example works in 2066 when the second 's' is renamed to
s1, as does this:
auto s = S!(float, 1)(1); // eq: S!(float, 1)(1)
auto s1 = S!(float, 2)(1); // eq: S!(float, 2)(1,nan)
auto s2 = S!(float, 2)(1, 2) // eq: S!(float,2)(1,2)
Cheers,
uri
Identifying 32 vs 64 bit OS?
I am looking at these versions as described here: http://dlang.org/version.html There are X86 and X86_64 version identifiers, but these specifically mention that they are versions for the processor type. Can they also be used to determine if the OS is running in 32 vs 64 bits?
Re: undefined references
On Mon, Aug 11, 2014 at 03:12:43AM +, Vlad Levenfeld via Digitalmars-d-learn wrote: [...] So, while the mistake was mine, this should be an ambiguous overload error at compile-time, instead of a linker error. I realize that everyone contributing to D has their hands more than full, and a bug this rare (assumption based on lack of search results) is gonna be low-priority, so I'm just making this post for posterity - maybe it'll help, and of course I'm happy to try anything and give additional information. If anyone has any suggestions on how I might go about making a useful bug report out of this, I'm all ears. While we generally prefer bug reports for which there is a small reproducible test case, I'd also say that filing a bug is better than not filing a bug, because chances are, *somebody* else out there might have encountered the same problem but haven't bothered to report it. If the problem isn't reported, then your helpful description will just get lost in the dusts of forum history, and it will never get fixed. If it's at least filed, then there's *some* hope somebody will figure out what the problem is and fix it. T -- In order to understand recursion you must first understand recursion.
