~ ?
What does this symbol mean in relation to D? ~
Enum type deduction inside templates is not working
Compiler can't deduce type for template struct Pair when using it
with enum argument. There is an example
import std.stdio;
enum Category { first, second, third };
struct Pair(F, S)
{
F first;
S second;
this(F f, S s)
{
first = f;
second = s;
}
}
void main()
{
auto p = Pair(Category.first, first); //It fails
writeln(p);
}
Is it not working for some reason or I'm doing something wrong or
is it just lack of implementation? How I could make this working
without explicit specifying of types?
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 06:12:57 UTC, pgtkda wrote: How I could make this working without explicit specifying of types? sorry, i should read better
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 06:04:20 UTC, Uranuz wrote:
Compiler can't deduce type for template struct Pair when using
it with enum argument. There is an example
import std.stdio;
enum Category { first, second, third };
struct Pair(F, S)
{
F first;
S second;
this(F f, S s)
{
first = f;
second = s;
}
}
void main()
{
auto p = Pair(Category.first, first); //It fails
writeln(p);
}
Is it not working for some reason or I'm doing something wrong
or is it just lack of implementation? How I could make this
working without explicit specifying of types?
is this a solution for your problem?
enum Category { first, second, third };
struct Pair
{
Category cat;
string second;
this(Category cat, string second){
this.cat = cat, this.second = second;
}
}
void main(){
auto p = Pair(Category.first, first);
writeln(p);
}
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 06:14:48 UTC, pgtkda wrote: On Friday, 27 June 2014 at 06:12:57 UTC, pgtkda wrote: How I could make this working without explicit specifying of types? sorry, i should read better Ok. Maybe it was discussed already somewhere, but I am not god in searching in English. Is there any directions about it? How could I work around it? Should I mail some proposal or bug report for it?
Re: ~ ?
On 06/26/2014 10:58 PM, pgtkda wrote: What does this symbol mean in relation to D? ~ It can be used in two ways: 1) When used as a unary operator, it means bitwise complement: assert(~0xaa55aa55 == 0x55aa55aa); 2) When used as a binary operator, it means concatenation: assert(hello ~ world == hello world); auto arr = [ 1, 2 ]; assert(arr ~ 3 == [ 1, 2, 3 ]); When used with assignment, it means appending: auto arr = [ 1, 2 ]; arr ~= 3; assert(arr == [ 1, 2, 3 ]); It can also be used in the special function name ~this(), which is the destructor of a struct or a class. (Related functions: 'static ~this()' and 'shared static ~this()') Ali [1] http://ddili.org/ders/d.en/bit_operations.html [2] http://ddili.org/ders/d.en/arrays.html [3] ddili.org/ders/d.en/special_functions.html
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 06:21:11 UTC, Uranuz wrote:
On Friday, 27 June 2014 at 06:14:48 UTC, pgtkda wrote:
On Friday, 27 June 2014 at 06:12:57 UTC, pgtkda wrote:
How I could make this
working without explicit specifying of types?
sorry, i should read better
Ok. Maybe it was discussed already somewhere, but I am not god
in searching in English. Is there any directions about it? How
could I work around it? Should I mail some proposal or bug
report for it?
I think, D is a typesafe language, therefore you can't use
variables with no type declaration.
One thing you can search for, are templates but even there you
have to define a type:
import std.stdio;
enum Category : string { first = first}
template Pair(T)
{
T t;
T cat;
}
void main()
{
alias Pair!(string) a;
a.cat = Category.first;
a.t = first;
writeln(a.cat, . , a.t);
}
Re: ~ ?
On Friday, 27 June 2014 at 06:33:07 UTC, Ali Çehreli wrote: On 06/26/2014 10:58 PM, pgtkda wrote: What does this symbol mean in relation to D? ~ It can be used in two ways: 1) When used as a unary operator, it means bitwise complement: assert(~0xaa55aa55 == 0x55aa55aa); 2) When used as a binary operator, it means concatenation: assert(hello ~ world == hello world); auto arr = [ 1, 2 ]; assert(arr ~ 3 == [ 1, 2, 3 ]); When used with assignment, it means appending: auto arr = [ 1, 2 ]; arr ~= 3; assert(arr == [ 1, 2, 3 ]); It can also be used in the special function name ~this(), which is the destructor of a struct or a class. (Related functions: 'static ~this()' and 'shared static ~this()') Ali [1] http://ddili.org/ders/d.en/bit_operations.html [2] http://ddili.org/ders/d.en/arrays.html [3] ddili.org/ders/d.en/special_functions.html Thanks :)
GC.calloc(), then what?
1) After allocating memory by GC.calloc() to place objects on it, what else should one do? In what situations does one need to call addRoot() or addRange()? 2) Does the answer to the previous question differ for struct objects versus class objects? 3) Is there a difference between core.stdc.stdlib.calloc() and GC.calloc() in that regard? Which one to use in what situation? 4) Are the random bit patterns in a malloc()'ed memory always a concern for false pointers? Does that become a concern after calling addRoot() or addRange()? If so, why would anyone ever malloc() instead of always calloc()'ing? Ali
Re: Enum type deduction inside templates is not working
I think, D is a typesafe language, therefore you can't use
variables with no type declaration.
One thing you can search for, are templates but even there you
have to define a type:
import std.stdio;
enum Category : string { first = first}
template Pair(T)
{
T t;
T cat;
}
void main()
{
alias Pair!(string) a;
a.cat = Category.first;
a.t = first;
writeln(a.cat, . , a.t);
}
Ok. I know that D is typesafe language, but I'm not going to do
some implicit type casts in there, because type of Category.first
is Category itself but not string or something. In this example
`a.cat = Category.first;` tries to make implicit cast (I don't
remember is it allowed or not)
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote: 1) After allocating memory by GC.calloc() to place objects on it, what else should one do? Use std.conv.emplace. In what situations does one need to call addRoot() or addRange()? Add root creates an internal reference within the GC to the memory pointed by the argument (void* p.) This pins the memory so that it won't be collected by the GC. E.g. you're going to pass a string to an extern C function, and the function will store a pointer to the string within its own data structures. Since the GC won't have access to the data structures, you must addRoot it to avoid creating a dangling pointer in the C data structure. Add range is usually for cases when you use stdc.stdlib.malloc/calloc and place pointers to GC managed memory within that memory. This allows the GC to scan that memory for pointers during collection, otherwise it may reclaim memory which is pointed to my malloc'd memory. 2) Does the answer to the previous question differ for struct objects versus class objects? No. 3) Is there a difference between core.stdc.stdlib.calloc() and GC.calloc() in that regard? Which one to use in what situation? One is GC managed, the other is not. calloc simply means the memory is pre-zero'd, it has nothing to do with C allocation / allocation in the C language 4) Are the random bit patterns in a malloc()'ed memory always a concern for false pointers? Does that become a concern after calling addRoot() or addRange()? If by malloc you're talking about stdc.stdlib.malloc then: It only becomes a concern after you call addRange, and the false pointers potential is only present within the range you gave to addRange. So if you over-allocate using malloc and give the entire memory range to addRange, then any false pointers in the un-intialized portion become a concern. If you're talking about GC.malloc(): Currently the GC zeros the memory unless you allocate NO_SCAN memory, so it only differs in the NO_SCAN case. If so, why would anyone ever malloc() instead of always calloc()'ing? To save on redundant zero'ing.
Re: Enum type deduction inside templates is not working
Seems that I found answer myself. As far as I understand type inference is working only for template functions but not struct or class templates. This is why this not working and enum is not responsible for that. I don't know why I use D enough long but I did not remember this fact.
Re: GC.calloc(), then what?
I realize that my answer isn't completely clear in some cases, if you still have questions, ask away.
Re: Enum type deduction inside templates is not working
There is proposal exists for this topic http://wiki.dlang.org/DIP40
Re: GC.calloc(), then what?
On 06/27/2014 12:53 AM, safety0ff wrote: I realize that my answer isn't completely clear in some cases, if you still have questions, ask away. Done! That's why we are here anyway. :p Ali
Re: GC.calloc(), then what?
Thank you for your responses. I am partly enlightened. :p On 06/27/2014 12:34 AM, safety0ff wrote: On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote: 1) After allocating memory by GC.calloc() to place objects on it, what else should one do? Use std.conv.emplace. That much I know. :) I have actually finished the first draft of translating my memory management chapter (the last one in the book!) and trying to make sure that the information is correct. In what situations does one need to call addRoot() or addRange()? Add root creates an internal reference within the GC to the memory pointed by the argument (void* p.) This pins the memory so that it won't be collected by the GC. E.g. you're going to pass a string to an extern C function, and the function will store a pointer to the string within its own data structures. Since the GC won't have access to the data structures, you must addRoot it to avoid creating a dangling pointer in the C data structure. Additionally and according to the documentation, any other GC blocks will be considered live. So, addRoot makes a true roots where the GC starts its scanning from. Add range is usually for cases when you use stdc.stdlib.malloc/calloc and place pointers to GC managed memory within that memory. This allows the GC to scan that memory for pointers during collection, otherwise it may reclaim memory which is pointed to my malloc'd memory. One part that I don't understand in the documentation is if p points into a GC-managed memory block, addRange does not mark this block as live. http://dlang.org/phobos/core_memory.html#.GC.addRange Does that mean that if I have objects in my addRange'd memory that in turn have references to objects in the GC-managed memory, my references in my memory may be stale? If so, does that mean that if I manage objects in my memory, all their members should be managed by me as well? This seems to bring two types of GC-managed memory: 1) addRoot'ed memory that gets scanned deep (references are followed) 2) addRange'd memory that gets scanned shallow (references are not followed) See, that's confusing: What does that mean? I still hold the memory block anyway; what does the GC achieve by scanning my memory if it's not going to follow references anyway? 2) Does the answer to the previous question differ for struct objects versus class objects? No. 3) Is there a difference between core.stdc.stdlib.calloc() and GC.calloc() in that regard? Which one to use in what situation? One is GC managed, the other is not. calloc simply means the memory is pre-zero'd, it has nothing to do with C allocation / allocation in the C language I know even that much. ;) I find people's malloc+memset code amusing. 4) Are the random bit patterns in a malloc()'ed memory always a concern for false pointers? Does that become a concern after calling addRoot() or addRange()? If by malloc you're talking about stdc.stdlib.malloc then: It only becomes a concern after you call addRange, But addRange doesn't seem to make sense for stdlib.malloc'ed memory, right? The reason is, that memory is not managed by the GC so there is no danger of losing that memory due to a collection anyway. It will go away only when I call stdlib.free. and the false pointers potential is only present within the range you gave to addRange. So if you over-allocate using malloc and give the entire memory range to addRange, then any false pointers in the un-intialized portion become a concern. Repeating myself, that makes sense but I don't see when I would need addRange on a stdlib.malloc'ed memory. If you're talking about GC.malloc(): Currently the GC zeros the memory unless you allocate NO_SCAN memory, so it only differs in the NO_SCAN case. So, the GC's default behavior is to scan the memory, necessitating clearing the contents? That seems to make GC.malloc() behave the same as GC.calloc() by default, doesn't it? So, is this guideline right? GC.malloc() makes sense only with NO_SCAN. If so, why would anyone ever malloc() instead of always calloc()'ing? To save on redundant zero'ing. And again, redundant zero'ing is saved only when used with NO_SCAN. I think I finally understand the main difference between stdlib.malloc and GC.malloc: The latter gets collected by the GC. Another question: Do GC.malloc'ed and GC.calloc'ed memory scanned deep? Ali
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: Thank you for your responses. I am partly enlightened. :p I know you're a knowledgeable person in the D community, I may have stated many things you already knew, but I tried to answer the questions as-is. On 06/27/2014 12:34 AM, safety0ff wrote: Add range is usually for cases when you use stdc.stdlib.malloc/calloc and place pointers to GC managed memory within that memory. This allows the GC to scan that memory for pointers during collection, otherwise it may reclaim memory which is pointed to my malloc'd memory. One part that I don't understand in the documentation is if p points into a GC-managed memory block, addRange does not mark this block as live. [SNIP] See, that's confusing: What does that mean? I still hold the memory block anyway; what does the GC achieve by scanning my memory if it's not going to follow references anyway? The GC _will_ follow references (i.e. scan deeply,) that's the whole point of addRange. What that documentation is saying is that: If you pass a range R through addRange, and R lies in the GC heap, then once there are no pointers (roots) to R, the GC will collect it anyway regardless that you called addRange on it. In other words, prefer using addRoot for GC memory and addRange for non-GC memory. 4) Are the random bit patterns in a malloc()'ed memory always a concern for false pointers? Does that become a concern after calling addRoot() or addRange()? If by malloc you're talking about stdc.stdlib.malloc then: It only becomes a concern after you call addRange, But addRange doesn't seem to make sense for stdlib.malloc'ed memory, right? The reason is, that memory is not managed by the GC so there is no danger of losing that memory due to a collection anyway. It will go away only when I call stdlib.free. addRange almost exclusively makes sense with stdlib.malloc'ed memory. As you've stated: If you pass it GC memory it does not mark the block as live. I believe the answer above clears things up: the GC does scan the range, and scanning is always deep (i.e. when it finds pointers to unmarked GC memory, it marks them.) Conversely, addRoot exclusively makes sense with GC memory. If you're talking about GC.malloc(): Currently the GC zeros the memory unless you allocate NO_SCAN memory, so it only differs in the NO_SCAN case. So, the GC's default behavior is to scan the memory, necessitating clearing the contents? That seems to make GC.malloc() behave the same as GC.calloc() by default, doesn't it? I don't believe it's necessary to clear it, it's just a measure against false pointers (AFAIK.) So, is this guideline right? GC.malloc() makes sense only with NO_SCAN. I wouldn't make a guideline like that, just say that: if you want the memory to be guaranteed to be zero'd use GC.calloc. However, due to GC internals (for preventing false pointers,) GC.malloc'd memory will often be zero'd anyway. If so, why would anyone ever malloc() instead of always calloc()'ing? To save on redundant zero'ing. And again, redundant zero'ing is saved only when used with NO_SCAN. Yup. I think I finally understand the main difference between stdlib.malloc and GC.malloc: The latter gets collected by the GC. Yup. Another question: Do GC.malloc'ed and GC.calloc'ed memory scanned deep? Yes, only NO_SCAN memory doesn't get scanned, everything else does.
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: So, the GC's default behavior is to scan the memory, necessitating clearing the contents? That seems to make GC.malloc() behave the same as GC.calloc() by default, doesn't it? Yes. compare: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L543 to: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L419
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 09:20:53 UTC, safety0ff wrote: Yes. compare: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L543 to: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L419 Actually, I just realized that I was wrong in saying the memory likely be cleared by malloc it's only the overallocation that gets cleared.
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: Thank you for your responses. I am partly enlightened. :p On 06/27/2014 12:34 AM, safety0ff wrote: On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote: But addRange doesn't seem to make sense for stdlib.malloc'ed memory, right? The reason is, that memory is not managed by the GC so there is no danger of losing that memory due to a collection anyway. It will go away only when I call stdlib.free. It is not about that, but about the fact that this unmanaged memory *might contain* references towards managed memory. If you intend to place such references into this particular chunk of memory, then you need to tell GC to scan the memory chunk for references towards managed memory. Otherwise, the GC might ignore this chunk of memory, find elsewhere no references towards a managed object, delete the managed object, then your pointer placed in the unmanaged memory becomes dangling.
What is best way to communicate between computer in local network ?
Hi, I have a linux network and i would like to know if they are a D library to communicate between computer efficiently. I do not know if that is better to use websocket and if they exists into dlang: - http://planet.jboss.org/post/rest_vs_websocket_comparison_and_benchmarks Thanks for your help Regards
Re: ~ ?
On Friday, 27 June 2014 at 05:58:14 UTC, pgtkda wrote: What does this symbol mean in relation to D? ~ ~ D means it's about the best language I've come across so far.
Re: What is best way to communicate between computer in local network ?
On Friday, 27 June 2014 at 12:51:45 UTC, bioinfornatics wrote: I do not know if that is better to use websocket and if they exists into dlang: you could use websocket in D but if you are talking between two separate D programs you can just use a regular socket http://dlang.org/phobos/std_socket.html If you have a copy of my book, I have a brief how-to on std.socket in chapter 2. But for two computers just talking to one another all you have to do is on one: new Socket bind accept and on the other one: new Socket connect See the documentation for info on each of those methods.
Re: What is best way to communicate between computer in local network ?
On Friday, 27 June 2014 at 12:51:45 UTC, bioinfornatics wrote: Hi, I have a linux network and i would like to know if they are a D library to communicate between computer efficiently. I do not know if that is better to use websocket and if they exists into dlang: - http://planet.jboss.org/post/rest_vs_websocket_comparison_and_benchmarks Thanks for your help Regards It's an application and network dependant decision, but I would suggest http://code.dlang.org/packages/zmqd as suitable for most situations.
Re: What is best way to communicate between computer in local network ?
On Friday, 27 June 2014 at 13:03:20 UTC, John Colvin wrote: On Friday, 27 June 2014 at 12:51:45 UTC, bioinfornatics wrote: Hi, I have a linux network and i would like to know if they are a D library to communicate between computer efficiently. I do not know if that is better to use websocket and if they exists into dlang: - http://planet.jboss.org/post/rest_vs_websocket_comparison_and_benchmarks Thanks for your help Regards It's an application and network dependant decision, but I would suggest http://code.dlang.org/packages/zmqd as suitable for most situations. Thanks i go to take a look
Re: What is best way to communicate between computer in local network ?
On Friday, 27 June 2014 at 13:02:55 UTC, Adam D. Ruppe wrote: On Friday, 27 June 2014 at 12:51:45 UTC, bioinfornatics wrote: I do not know if that is better to use websocket and if they exists into dlang: you could use websocket in D but if you are talking between two separate D programs you can just use a regular socket http://dlang.org/phobos/std_socket.html If you have a copy of my book, I have a brief how-to on std.socket in chapter 2. But for two computers just talking to one another all you have to do is on one: new Socket bind accept and on the other one: new Socket connect See the documentation for info on each of those methods. Yes I bought your book i will read this chapter. Thanks
Re: Enum type deduction inside templates is not working
On Fri, Jun 27, 2014 at 06:04:18AM +, Uranuz via Digitalmars-d-learn wrote:
Compiler can't deduce type for template struct Pair when using it with
enum argument. There is an example
import std.stdio;
enum Category { first, second, third };
struct Pair(F, S)
{
F first;
S second;
this(F f, S s)
{
first = f;
second = s;
}
}
void main()
{
auto p = Pair(Category.first, first); //It fails
writeln(p);
}
Is it not working for some reason or I'm doing something wrong or is
it just lack of implementation? How I could make this working without
explicit specifying of types?
Try this:
struct Pair(F, S)
{
F first;
S second;
}
auto pair(F,S)(F f, S s)
{
return Pair!(F,S)(f,s);
}
void main()
{
auto p = pair(Category.first, first);
}
T
--
Don't throw out the baby with the bathwater. Use your hands...
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 07:43:27 UTC, Uranuz wrote:
I don't know why I use D enough long but I did not remember
this fact.
Sometimes we get spoiled by all the amazing/nifty things that do
work, and expect comparable things like this to Just Work. To be
honest, at first I didn't see any issue in what you were doing
either...
One thing you could do in the meantime is to use an instantiator
function. This works just fine:
auto pair(F, S)(F f, S s)
{
return Pair!(F, S)(f, s);
}
void main()
{
auto p = pair(Category.first, first);
writeln(p);
}
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 14:27:46 UTC, H. S. Teoh via Digitalmars-d-learn wrote: Try this: Get out of my head!
Re: import except one?
On Friday, 27 June 2014 at 05:26:09 UTC, Puming wrote: On Thursday, 26 June 2014 at 08:02:24 UTC, bearophile wrote: Puming: I'm using scriptlike, which imports everything from std.process for convienience, but I also need to import another module, which contains a class `Config`, it conflicts with std.process.Config. I don't actually need std.process.Config, but I need many other symbols in scriptlike and std.process. What I want to achieve is to import ALL symbols from scriptlike EXCEPT std.process.Config, something like: ```d import scriptlike: !Config; A similar idea is present in Haskell, but it was refused by Walter. Thanks :-) I wander what was the rationale behind Walter's rejection. IMHO if we have a selective filter mechanism for imports, the complement exclude mechinism works as well. But of cause we are not that far yet, final, nothrow, pure and others don't have their complements either. The use of scriptlike is going to cause you similar problems, it's not for a fine tuning of imports. The problem is that we don't have a complete mechanism to fine tuning the imports. Selective filtering is only half of the cake. Bye, bearophile I wasn't in that particular discussion, but based on history, I imagine Walter's argument was probably along the lines of just use a static import for both modules and use either aliasing or FQN's for the symbols you need. That and inner scope imports.
Regex problem
Cosider this:
ulong regexChk(string haystack, string needle)
{
// haystack and needle are okey
auto r = regex(needle, g);
auto m = match(haystack, r);
// up to here is all fine
return m.hit().count();
}
I want to count the numbers needles is mathced in haystack
But I get the error :
core.exception.AssertError@std.regex(5587): Assertion failure
./niarbyl(_d_assertm+0x26) [0x4e6c26]
./niarbyl() [0x4f45be]
./niarbyl(pure nothrow @property @trusted immutable(char)[]
std.regex.Captures!(immutable(char)[],
ulong).Captures.hit()+0x61) [0x4c8af1]
./niarbyl(pure nothrow @property @trusted immutable(char)[]
std.regex.__T10RegexMatchTAyaS273std5regex15ThompsonMatcherZ.RegexMatch.hit()+0x59)
[0x4c7089]
./niarbyl(ulong niarbyl.regexChk(immutable(char)[],
immutable(char)[])+0x87) [0x4ac85f]
./niarbyl(void niarbyl.setGrammarApllicability()+0x3e3) [0x4accbb]
./niarbyl(_Dmain+0x95) [0x4acd9d]
./niarbyl(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll().void __lambda1()+0x18) [0x4eab9c]
./niarbyl(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x4eaaf6]
./niarbyl(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()+0x30) [0x4eab5c]
./niarbyl(void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate())+0x2a)
[0x4eaaf6]
./niarbyl(_d_run_main+0x1a3) [0x4eaa77]
./niarbyl(main+0x17) [0x4dab0f]
/usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7fe35eb43000]
I dont quite understand. I must be doing some rooki mistake. Help?
Re: Regex problem
On Fri, Jun 27, 2014 at 03:59:47PM +, seany via Digitalmars-d-learn wrote: [...] core.exception.AssertError@std.regex(5587): Assertion failure ./niarbyl(_d_assertm+0x26) [0x4e6c26] ./niarbyl() [0x4f45be] ./niarbyl(pure nothrow @property @trusted immutable(char)[] std.regex.Captures!(immutable(char)[], ulong).Captures.hit()+0x61) [0x4c8af1] [...] Your code works fine on git HEAD, so it seems that this is a bug in std.regex that has since been fixed. It may not do what you *want*, though -- be aware that in the next release, match() will be deprecated and replaced by matchFirst and matchAll, which are more precise in what exactly you want to match. In any case, assertions inside Phobos code is most likely a Phobos bug, since it means that you've somehow managed to get it to go down a code path that the author thought would never happen. T -- Let's eat some disquits while we format the biskettes.
The D2 dictionary chalenge.
Try to make a faster one than http://dpaste.dzfl.pl/aa2ad03cb0dd Post your reply here, existing entries must be included.
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 07:34:55 UTC, safety0ff wrote: On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote: 1) After allocating memory by GC.calloc() to place objects on it, what else should one do? Use std.conv.emplace. And possibly set BlkInfo flags to indicate whether the block has pointers, and the finalize flag to indicate that it's an object. I'd look at _d_newclass in Druntime/src/rt/lifetime.d for the specifics. To be honest, I think the GC interface is horribly outdated, but my proposal for a redesign (first in 2010, then again in 2012 and once again in 2013) never gained traction. In short, what I'd really like to have is a way to tell the GC to allocate an object of type T. Perhaps Andrei's allocators will sort this out and the issue will be moot. For reference: http://lists.puremagic.com/pipermail/d-runtime/2010-August/75.html http://lists.puremagic.com/pipermail/d-runtime/2012-April/001095.html http://lists.puremagic.com/pipermail/d-runtime/2013-July/001840.html
Re: GC.calloc(), then what?
On 06/27/2014 01:49 AM, safety0ff wrote: On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: Thank you for your responses. I am partly enlightened. :p I know you're a knowledgeable person in the D community, I may have stated many things you already knew, but I tried to answer the questions as-is. I appreciated your answers, which were very helpful. What I meant was, I was partially enlightened but still had some questions. I am in much better shape now. :) Ali
