Re: Static convertability testing?
On Thu, 12 Feb 2015 19:09:45 +, Chris Williams wrote: Is there something like isConvertible() in the library somewhere? there is at least `std.traits.isImplicitlyConvertible`: http://dlang.org/phobos/std_traits.html#isImplicitlyConvertible signature.asc Description: PGP signature
Static convertability testing?
I have a template function that gets values out of a tree of
variant types. My goal is to be able to write code like;
node.get!string(path, to, leaf);
Inside get(), I would like to use std.conv to dynamically convert
(where able) to the target type (T) or, if that is not possible,
to return T.init.
If I wanted to force the user to request the correct type as is
stored in the structure, I could write code like:
switch (leafType) {
case STRING:
static if (is(T : string)) {
return leftValue;
}
else {
return T.init
}
break;
...
But since I want to allow all possiblities that std.conv
supports, I want something like:
static if (isConvertible!(T, string)) {
return leftValue.to!T;
}
else {
return T.init;
}
Is there something like isConvertible() in the library somewhere?
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 11:10:34 +, ponce wrote: On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|. with big visibility people will fill your mailbox with reports, if any. ;- ) signature.asc Description: PGP signature
Re: Comparing function pointers
On 2/12/2015 3:40 AM, Freddy wrote:
import std.stdio;
auto test1(){
void testFunc(){
}
return testFunc;
}
auto test2(){
uint a;
void testFunc(){
a=1;
}
return testFunc;
}
void main(){
writeln(test1()==test1());//true
writeln(test2()==test2());//false
}
Is the intended behavior?
Read the section of the documentation about Delegates, Function
Pointers, and Closures [1]. Neither of your pointers are actually
function pointers. They are both delegates. The second one, as ketmar
said, is a closure because it's a delegate with state. To get a function
pointer from an inner function, the inner function must be static.
Function pointers can't have state.
```
import std.stdio;
void printAnInt( int function() fptr ) {
writeln( From function pointer: , fptr() );
}
void printAnInt( int delegate() dg ) {
writeln( From a delegate: , dg() );
}
void main() {
static int foo() { return 1; }
int bar() { return 2; }
printAnInt( foo );
printAnInt( bar );
}
```
[1] http://dlang.org/function.html#closures
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 08:55:43 UTC, Jonathan M Davis wrote: On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. Really what it comes down to is that if you want deterministic destruction, you _don't_ use managed resources. You use malloc and free rather than new and the GC. Granted, that's way uglier than it should be right now, because the allocator stuff hasn't been finished yet, but it's really what's required if you want an object on the heap to have a deterministic lifetime. Memory that's managed by a GC just doesn't work that way. That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 08:14:49 UTC, Mike Parker wrote: On 2/12/2015 6:42 AM, ketmar wrote: this problem has very easy solition: we should stop calling class dtors destructors, and rename them to finalizers. Absolutely. So many people coming from C++ see destructor and want to use them as they did in C++. How often do we see people coming on here wondering why they can't get deterministic destruction out of class destructors? Of course, it's too late to change anything now, but we need a big, obvious link from the docs and the wiki and anywhere else people can read about destructors to a page that explains how D class destructors are not C++ class destructors. http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. and it can't be managed by GC too. that's why it has it's own crappy pseudo-gc implementation with refcounting. *and* it's memory managemet too, heh. signature.asc Description: PGP signature
Re: Is there an object on given memory address?
Or send a hash of the object along with the memory address, then query the GC wether the memory is still allocated. This part sounds interesnting. How does that GC querying thing works exactly?
Re: GC has a barbaric destroyng model, I think
On 2/12/2015 6:09 PM, weaselcat wrote: On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management. I'm not complaining. I'm simply suggesting that the very word destructor likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are.
Re: Cannot use the same template arguments on function as the ones on struct
Thanks, everyone.
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 10:04:29 UTC, tcak wrote: BTW, I have already got the address of object into a size_t type variable and sent it. That is not the problem part. How reliable do you want? You would have to either pin the object by registering a root to it to prevent it from being moved or freed. http://dlang.org/phobos/core_memory.html#.GC.addRoot Or send a hash of the object along with the memory address, then query the GC wether the memory is still allocated.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote: On 2/12/2015 6:09 PM, weaselcat wrote: On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management. I'm not complaining. I'm simply suggesting that the very word destructor likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are. What I think is that the GC should simply never call the destructors. The GC calling class destructors is currently a 50% solution that provide illusory correctness.
Re: GC has a barbaric destroyng model, I think
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, m_tex);
glTexImage2D(); // texture in video memory
}
~this()
{
// release texture in video memory
glDeleteTextures(1, m_tex);
}
}
void foo()
{
// we do some operations...
A[] arrA = new A[1_000_000];
for (int i; iarr.length; i++)
arrA[i] = new A(); // generate texture
// do some operations... and return without explicit disposing
of arrA
}
main(...)
{
while(app.isNotExit)
{
foo();
}
}
if GC does not guarantee the calling of dtor we can't be sure
that some textures will be destroyed.
It will be followed by overflowing of the video memory.
And it is obvious, becouse we have no way to detect when the
objects are destroyed.
The video memory will leaks.
Starting a HTTPS session with D
Hi We have a network traffic logger module at office. We need to a tool which creates simple traffic with different protocols and test our product's output to see if we parse the headers correctly or not. And of course I proposed writing this tool with D!!! When it comes to create a HTTP session it is very easy auto content = get(dlang.org); But I couldn't find any examples about https. Do I have to use a C library like libcurl for it. Or is there a native way do solve my problem. Regards Erdem
Re: Cannot use the same template arguments on function as the ones on struct
Thank you!
What is the Correct way to Malloc in @nogc section?
I'm currently trying to write a personal Associate Array class
that can be used in @nogc sections. Obviously, this means I'll
want to use malloc/free, however I'm not sure what the Correct
way to do this is. In a few places online I've seen code for
custom _new and _delete functions similar to this:
[code]
T _new(T, Args...) (Args args) {
size_t objSize;
static if(is (ValType == class))
objSize = __traits(classInstanceSize, T);
else
objSize = T.sizeof;
void* tmp = core.stdc.stdlib.malloc(objSize);
if (!tmp) throw new Exception(Memory allocation failed);
void[] mem = tmp[0..objSize];
T obj = emplace!(T, Args)(mem, args);
return obj;
}
void _delete(T)(T obj) {
clear(obj);
core.stdc.stdlib.free(cast(void*)obj);
}
[/code]
The Exception obviously uses the GC, and would need to be
replaced with a printf or something; however, emplace doesn't
have a @nogc replacement that I know of. What I'd like to know,
from people much more knowledgeable about the ins and outs of D,
is what the Best or Correct way to allocate and deallocate
within @nogc sections?
PS: Tangentially related, what hashing algorithm does D use? I've
seen people suggest using typeid(object).toHash(object);
however, toHash isn't @nogc, so I need to write my own Hashing
function. For the sake of consistency and peace of mind, I'd
really like to match mine as closely to Ds internal one as
possible.
Re: What is the Correct way to Malloc in @nogc section?
I realized the above _new has an issue with emplace depending on whether it's a class (reference type) or not. Class c = emplace() works, but something like string s = emplace() does not. Is doing string s = *emplace() safe and okay? Or is there a better way to handle the differences between allocating a Class with malloc vs a non-Class?
Re: What is the Correct way to Malloc in @nogc section?
On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote:
I'm currently trying to write a personal Associate Array class
that can be used in @nogc sections. Obviously, this means I'll
want to use malloc/free, however I'm not sure what the
Correct way to do this is. In a few places online I've seen
code for custom _new and _delete functions similar to this:
[code]
T _new(T, Args...) (Args args) {
size_t objSize;
static if(is (ValType == class))
objSize = __traits(classInstanceSize, T);
else
objSize = T.sizeof;
void* tmp = core.stdc.stdlib.malloc(objSize);
if (!tmp) throw new Exception(Memory allocation failed);
void[] mem = tmp[0..objSize];
T obj = emplace!(T, Args)(mem, args);
return obj;
}
void _delete(T)(T obj) {
clear(obj);
core.stdc.stdlib.free(cast(void*)obj);
}
[/code]
The Exception obviously uses the GC, and would need to be
replaced with a printf or something; however, emplace doesn't
have a @nogc replacement that I know of. What I'd like to know,
from people much more knowledgeable about the ins and outs of
D, is what the Best or Correct way to allocate and
deallocate within @nogc sections?
PS: Tangentially related, what hashing algorithm does D use?
I've seen people suggest using typeid(object).toHash(object);
however, toHash isn't @nogc, so I need to write my own Hashing
function. For the sake of consistency and peace of mind, I'd
really like to match mine as closely to Ds internal one as
possible.
This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.
Re: GC has a barbaric destroyng model, I think
On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. Really what it comes down to is that if you want deterministic destruction, you _don't_ use managed resources. You use malloc and free rather than new and the GC. Granted, that's way uglier than it should be right now, because the allocator stuff hasn't been finished yet, but it's really what's required if you want an object on the heap to have a deterministic lifetime. Memory that's managed by a GC just doesn't work that way. - Jonathan M Davis
Re: GC has a barbaric destroyng model, I think
On 2/12/2015 6:42 AM, ketmar wrote: this problem has very easy solition: we should stop calling class dtors destructors, and rename them to finalizers. Absolutely. So many people coming from C++ see destructor and want to use them as they did in C++. How often do we see people coming on here wondering why they can't get deterministic destruction out of class destructors? Of course, it's too late to change anything now, but we need a big, obvious link from the docs and the wiki and anywhere else people can read about destructors to a page that explains how D class destructors are not C++ class destructors.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management.
Is there an object on given memory address?
Is there any reliable way to determine whether there is a certain type of object in memory at a given address? I am going to send the memory address of an object to another program over pipes. Then after a while, other program will send that memory address, and main program will try to address the object. (Please do not concern about security). What I am worried about is whether the object is still there, or garbage collector has already removed it, or another object has come on same address.
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 10:03:18 UTC, tcak wrote: Is there any reliable way to determine whether there is a certain type of object in memory at a given address? I am going to send the memory address of an object to another program over pipes. Then after a while, other program will send that memory address, and main program will try to address the object. (Please do not concern about security). What I am worried about is whether the object is still there, or garbage collector has already removed it, or another object has come on same address. BTW, I have already got the address of object into a size_t type variable and sent it. That is not the problem part.
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
Truth be told, D has no guideline for deterministic destruction of managed resources.
Re: Why hibernated does not create tables automatically?
how to update table schema automatically:
this()
{
mdb = new MysqlDB(connStr);
auto conn = mdb.lockConnection();
scope(exit) conn.close();
MysqlOrmUtil.updateTableSchema!(Customer)(conn);
MysqlOrmUtil.updateTableSchema!(Card)(conn);
MysqlOrmUtil.updateTableSchema!(Agent)(conn);
}
Re: Why hibernated does not create tables automatically?
here is how to use:
@UniqueIndex(id,[id])
class Card
{
@NotNull()
@Auto()
long id;
string pwd;
long agentId;
bool valid;
long rmb;
long createDate;
long soldDate;
long chargeDate;
}
public Card[] getAllCards(long page,long pageSize)
{
Connection conn = mdb.lockConnection();
scope(exit) conn.close();
string sql = select * from Card;
Card[] ret = MysqlOrmUtil.exeQueryToObjArr!Card(sql,conn);
return ret;
}
public void createCards(long agentId,long rmb,long count)
{
long curTime = now();
Connection conn = mdb.lockConnection();
scope(exit) conn.close();
for(int i=0; icount; i++)
{
Card card = new Card();
card.agentId = agentId;
card.createDate = curTime;
card.pwd = createCardPwd();
card.rmb = rmb;
card.valid = true;
string sql =
MysqlOrmUtil.genInsertSqlWithoutId(id,card);
MysqlOrmUtil.exeSql(sql,conn);
}
}
Re: Why hibernated does not create tables automatically?
finally ,I write a orm tool to replace hibernated, it is simple,
and it is easy to use, and every thing in control.
It is free to copy ,improve.
module mysqlormutil;
import vibe.d;
import std.stdio;
import mysql.connection;
import mysql.db;
struct NotNull
{
}
struct Auto
{
}
struct Index
{
string name;
string [] cols;
}
struct UniqueIndex
{
string name;
string[] cols;
}
class TableIndexInfo
{
public string indexName;
public string[] cols;
public bool isUnique;
}
class MysqlOrmUtil
{
//更新表结构
public static void updateTableSchema(CLS)(Connection conn)
{
MysqlOrmInternalUtil.updateTableSchema!(CLS)(conn);
}
//生成replace语句，保存整个对象
public static string genSaveAllSql(CLS)(ref CLS obj)
{
return MysqlOrmInternalUtil.genSaveAllSql!(CLS)(obj);
}
public static string genInsertSqlWithoutId(CLS)(string
idColName,ref CLS obj)
{
return
MysqlOrmInternalUtil.genInsertSqlWithoutId!(CLS)(idColName,obj);
}
public static ulong exeSql(string sql,Connection conn)
{
return MysqlOrmInternalUtil.exeSql(sql,conn);
}
public static CLS exeQueryToObj(CLS)(string sql,Connection conn)
{
return MysqlOrmInternalUtil.exeQueryToObj!(CLS)(sql,conn);
}
public static CLS exeQueryToStruct(CLS)(string sql,Connection
conn)
{
return MysqlOrmInternalUtil.exeQueryToStruct!(CLS)(sql,conn);
}
public static CLS[] exeQueryToObjArr(CLS)(string sql,Connection
conn)
{
return MysqlOrmInternalUtil.exeQueryToObjArr!(CLS)(sql,conn);
}
public static CLS[] exeQueryToStructArr(CLS)(string
sql,Connection conn)
{
return MysqlOrmInternalUtil.exeQueryToStructArr!(CLS)(sql,conn);
}
}
class MysqlOrmInternalUtil
{
__gshared static string[string] dToMysql ;
shared static this()
{
dToMysql[int] = int;
dToMysql[long] = bigint(20);
dToMysql[string] = varchar(128);
dToMysql[bool] = tinyint(1);
}
public static string getMysqlType(string dtype)
{
return dToMysql[dtype];
}
public static CLS[] exeQueryToObjArr(CLS)(string sql,Connection
conn)
{
Command cmd = Command(conn);
cmd.sql = sql;
ResultSet rs = cmd.execSQLResult();
CLS[] ret = resultSetToObjArray!(CLS)(rs);
return ret;
}
public static CLS[] exeQueryToStructArr(CLS)(string
sql,Connection conn)
{
Command cmd = Command(conn);
cmd.sql = sql;
ResultSet rs = cmd.execSQLResult();
CLS[] ret = resultSetToStructArray(rs);
return ret;
}
public static CLS exeQueryToObj(CLS)(string sql,Connection conn)
{
Command cmd = Command(conn);
cmd.sql = sql;
ResultSet rs = cmd.execSQLResult();
CLS ret = new CLS;
resultSetToObj!(CLS)(rs);
return ret;
}
public static CLS exeQueryToStruct(CLS)(string sql,Connection
conn)
{
Command cmd = new Command(conn);
cmd.sql = sql;
ResultSet rs = cmd.execSQLResult();
CLS ret;
resultSetToStruct!(CLS)(rs);
return ret;
}
public static ulong exeSql(string sql,Connection conn)
{
Command cmd = Command(conn);
cmd.sql = sql;
ulong ret;
cmd.execSQL(ret);
return ret;
}
public static CLS[] resultSetToObjArray(CLS)(ref ResultSet rs)
{
CLS[] arr;
foreach(Row row ; rs)
{
CLS obj = new CLS;
rowToObjOrStruct!(CLS)(rs,row,obj);
arr ~= obj;
}
return arr;
}
public static CLS resultSetToObj(CLS)(ref ResultSet rs)
{
if(rs.length == 0)
{
return null;
}
CLS ret = new CLS;
resultSetToObjOrStruct!(CLS)(rs,ret);
return ret;
}
public static CLS[] resultSetToStructArray(CLS)(ref ResultSet rs)
{
CLS[] arr;
foreach(Row row ; rs)
{
CLS obj;
rowToObjOrStruct(row,obj);
arr ~= obj;
}
return arr;
}
public
Derelict OpenGL basic program does not work but OpenGL does not say anything is wrong?
I've begun writing some basic OpenGL code using DerelictGL3 but I've hit a wall. I've managed to open a window (with DerelictSDL2) and call basic OpenGL functions such as glClear(). Still I can not get a basic triangle up and running. glError() does not return anything and when compiling, linking, and validating the shaders I get no errors. My code is located at: https://github.com/BennetLeff/PhySim
Re: Static convertability testing?
On Thursday, February 12, 2015 19:09:45 Chris Williams via Digitalmars-d-learn
wrote:
I have a template function that gets values out of a tree of
variant types. My goal is to be able to write code like;
node.get!string(path, to, leaf);
Inside get(), I would like to use std.conv to dynamically convert
(where able) to the target type (T) or, if that is not possible,
to return T.init.
If I wanted to force the user to request the correct type as is
stored in the structure, I could write code like:
switch (leafType) {
case STRING:
static if (is(T : string)) {
return leftValue;
}
else {
return T.init
}
break;
...
But since I want to allow all possiblities that std.conv
supports, I want something like:
static if (isConvertible!(T, string)) {
return leftValue.to!T;
}
else {
return T.init;
}
Is there something like isConvertible() in the library somewhere?
There are traits in std.traits for testing stuff like
isImplicitlyConvertibel, but std.conv.to is _way_ too fancy to expect any of
the traits in std.traits to tell you whether std.conv.to supports a
particular conversion (and there's every possibility that what std.conv.to
can do will increase from one release to another). By far the simplest way
(and probably the _only_ way realistically) would be to test std.conv.to
itself. Something like
is(typeof({auto t = to!T(string.init);}))
should do the trick for strings, and if you have a variable that you want to
convert from and not just strings, then you could do something like
is(typeof({auto t = to!T(myVar);}))
- Jonathan M Davis
Re: What is the Correct way to Malloc in @nogc section?
On Thursday, 12 February 2015 at 23:27:51 UTC, Kitt wrote: The Exception obviously uses the GC, and would need to be replaced with a printf or something; however, emplace doesn't have a @nogc replacement that I know of. What I'd like to know, from people much more knowledgeable about the ins and outs of D, is what the Best or Correct way to allocate and deallocate within @nogc sections? This issue, as well as PS: Tangentially related, what hashing algorithm does D use? I've seen people suggest using typeid(object).toHash(object); however, toHash isn't @nogc, so I need to write my own Hashing function. For the sake of consistency and peace of mind, I'd really like to match mine as closely to Ds internal one as possible. this one, are related to the loss of guarantee attributes when using TypeInfo methods, most recently discussed in this thread[1]. It is essentially a bug, and a work in progress. The correct way to handle OOM in D is to call core.exception.onOutOfMemoryError: --- if (auto p = malloc(...)) /* use p */ else onOutOfMemoryError(); // Throws OutOfMemoryError without allocating memory --- [1] http://forum.dlang.org/post/krccldftrbbczahas...@forum.dlang.org
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote: sure. but when it comes, for example, for big data structures with complex cross-references, you'll inevitably found that you either leaking memory, or writing your own half-backed semi-working GC realization. ah, good luck doing effecient refcounting on slices, for example. and they aren't even remotely complex. Well. What is the trouble if dtors are always (it is garanteed) called by GC before their phisical destroying? It will help to avoid many awkward situations.
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 13:21:07 +, Paulo Pinto wrote: On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references. The only downsize it that it isn't as simple as a C++ destructor. but we have scopes and weak references in D too! i'm still enraged that i can't overload `new` and forced to use ugly `emplace!` and friends, but otherwise it's possible (albeit a little burdensome) to do refcounting for interfaces. what is bad is that programmer has to be *very* careful with that. even seasoned programmers can made some errors here, that's why reference counting should be as much compiler-controlled as it can be. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 13:55:20 +, Andrey Derzhavin wrote: On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote: sure. but when it comes, for example, for big data structures with complex cross-references, you'll inevitably found that you either leaking memory, or writing your own half-backed semi-working GC realization. ah, good luck doing effecient refcounting on slices, for example. and they aren't even remotely complex. Well. What is the trouble if dtors are always (it is garanteed) called by GC before their phisical destroying? It will help to avoid many awkward situations. that blocks various GC realizations or making 'em ineffective. yes, there is only one working GC realization for D now, but it doesn't mean that we can't have others in the future. even such seemingly simple task as calling dtor in the same thread where ctor was called is very difficult (how would you do that with concurrent GC, for example?). what to do with HUGE data structure, which is anchored in object with finalizer? (we now have ALOT of unused memory, yet still can't free it, as it is locked, waiting for finalizer call) and alot of other troubles. actually, it's not a GC weakness, it's a bug in programmer's way of thinking. just stop thinking that GC is simply a hidden free, that's not right. you can do manual resource management with `scope(exit)`, for example (just call `.close()` method or something), but you shouldn't expect that GC will (and should) do the same. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. Manual memory management should be possible in D, see for example https://github.com/Dgame/m3
Re: Starting a HTTPS session with D
On Thursday, 12 February 2015 at 12:11:27 UTC, Kadir Erdem Demir wrote: Hi We have a network traffic logger module at office. We need to a tool which creates simple traffic with different protocols and test our product's output to see if we parse the headers correctly or not. And of course I proposed writing this tool with D!!! When it comes to create a HTTP session it is very easy auto content = get(dlang.org); But I couldn't find any examples about https. Do I have to use a C library like libcurl for it. Or is there a native way do solve my problem. No, you can keep using std.net.curl. You just need to tell curl how to verify server certificates. On Windows, if you are using the curl library included with DMD 2.066.1, curl will use the Windows certificate store. Otherwise, you need to provide a trusted CA bundle: auto http = HTTP(); http.handle.set(CurlOption.cainfo, path/to/ca-bundle.crt); Or, to completely disable verification: http.handle.set(CurlOption.ssl_verifypeer, false); Then: get(https://dlang.org;, http);
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 12:10:21 +, Andrey Derzhavin wrote: if GC does not guarantee the calling of dtor we can't be sure that some textures will be destroyed. It will be followed by overflowing of the video memory. And it is obvious, becouse we have no way to detect when the objects are destroyed. The video memory will leaks. that is the way garbage collection works. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thu, 12 Feb 2015 12:52:02 +, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. sure. but when it comes, for example, for big data structures with complex cross-references, you'll inevitably found that you either leaking memory, or writing your own half-backed semi-working GC realization. ah, good luck doing effecient refcounting on slices, for example. and they aren't even remotely complex. signature.asc Description: PGP signature
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references. The only downsize it that it isn't as simple as a C++ destructor. -- Paulo
Re: How to write asia characters on console?
On Sunday, 8 February 2015 at 05:57:31 UTC, Lave Zhang wrote:
Hi,
My first D program is like this:
---
import std.stdio;
void main(string[] args)
{
dstring s1 = hello你好d;
writeln(s1);
}
---
But the output is not correct(and my console codepage is 936):
C:\D\dmd2\samples\ddmd hello.d -offilename hello.exe
C:\D\dmd2\samples\dhello.exe
hello浣犲ソ
thanks.
add such code is better than use 'chcp 65001' for exe's consumer.
extern(C) int setlocale(int, char*);
static this()
{
import core.stdc.wchar_;
fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)china);
}
---
module cnsetlocale;
import std.stdio;
extern(C) int setlocale(int, char*);
static this()
{
import core.stdc.wchar_;
fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)china);
}
void main()
{
printf(a！！\n);
writefln(%s,hello,中文！！);
string msg=你好！！;
string msg1=去看电影吗？;
string msg2=是吗？;
a(msg2);
writefln(the string is %s \n %s %s
and %s,msg,msg1,msg2,你要去哪儿玩？);
writeln(公园？, 电影院？);
readln;
}
void a(string msg2)
{
writefln(the string is %s,msg2);
}
dmd hello //only such simple
'printf' is error,but for consumer is better,because they don't
need change any things,so don't use the 'printf' function .
If only test for yourself,you can add such codes for your main :
import std.process;
executeShell(chcp 65001);
then,change the Font to 'Lucida Console'
after 'dmd hello'
( if you don't want use 65001,then open cmd,chcp 936 ,and change
the Font to '宋体')
ok.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 12:10:22 UTC, Andrey Derzhavin
wrote:
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, m_tex);
glTexImage2D(); // texture in video memory
}
~this()
{
// release texture in video memory
glDeleteTextures(1, m_tex);
}
}
void foo()
{
// we do some operations...
A[] arrA = new A[1_000_000];
for (int i; iarr.length; i++)
arrA[i] = new A(); // generate texture
// do some operations... and return without explicit disposing
of arrA
}
main(...)
{
while(app.isNotExit)
{
foo();
}
}
if GC does not guarantee the calling of dtor we can't be sure
that some textures will be destroyed.
It will be followed by overflowing of the video memory.
And it is obvious, becouse we have no way to detect when the
objects are destroyed.
The video memory will leaks.
Exactly. That's why it's wrong to rely on the GC if you need
deterministic resource management. It's simply the wrong tool for
that.
Unfortunately, the right tools are a bit awkward to use, for
the time being. I still have hopes that we can finally get our
act together and get a usable `scope` implementation, which can
then be used to provide better library defined container types
as well as efficient reference counting.
Re: Starting a HTTPS session with D
get(https://dlang.org;, http); It works as I wanted, thanks a lot . Regards Erdem
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote: Exactly. That's why it's wrong to rely on the GC if you need deterministic resource management. It's simply the wrong tool for that. Unfortunately, the right tools are a bit awkward to use, for the time being. I still have hopes that we can finally get our act together and get a usable `scope` implementation, which can then be used to provide better library defined container types as well as efficient reference counting. If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 11:11:53 UTC, ponce wrote: On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote: On 2/12/2015 6:09 PM, weaselcat wrote: On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote: Truth be told, D has no guideline for deterministic destruction of managed resources. +1 don't complain about people wondering why class destructors don't work when there's no _real_ way to do it in D beyond 'drop down to C level and get going.' D is absolutely horrid for resource management. I'm not complaining. I'm simply suggesting that the very word destructor likely plays a role in the misconception that class destructors behave as they do in C++. However, I do think that when moving from one language to another, there has to be a certain expectation that things are going to be different and it shouldn't be a surprise when they are. What I think is that the GC should simply never call the destructors. The GC calling class destructors is currently a 50% solution that provide illusory correctness. s/class destructors/any destructors/ It now calls struct destructors, too, IIRC, at least when the structs are in GC managed arrays.
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 11:14:05 UTC, tcak wrote: Or send a hash of the object along with the memory address, then query the GC wether the memory is still allocated. This part sounds interesnting. How does that GC querying thing works exactly? std [doc][1] is your friend but if you need guidance. --- import core.memory : GC; bool is_gc_allocated = addrOf(ptd) != null; --- [1]: http://dlang.org/phobos/core_memory.html#.GC.addrOf
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 11:10:35 UTC, ponce wrote: On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:04:27 +, ponce wrote: http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors I've also made one for D can't do real-time because it has a stop-the-world GC http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread And one for D doesn't have ADTs http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching i believe that yor work needs more official highlighting. maybe it worth having the links right on the front page of dlang.org Thanks :) but I'm not 100% sure about the correctness of it all. More like 80% :|. You can put links in wiki: http://wiki.dlang.org/Articles
Re: Cannot use the same template arguments on function as the ones on struct
On Wednesday, 11 February 2015 at 22:24:53 UTC, anonymous wrote: On Wednesday, 11 February 2015 at 22:14:44 UTC, MrSmith wrote: http://dpaste.dzfl.pl/5f1d5d5d9e19 Instead I need to use template constraint which is less compact. http://dpaste.dzfl.pl/571ae84d783e Why such behavior happens? Seems to work when you add an empty template argument list to `accepter()`, making it `accepter!()()`: http://dpaste.dzfl.pl/2ec186453907 So, compiler bug, I guess? The error message says it tried !()(), but explicit !()() actually works. And the empty template argument list should be optional anyway. It would be a compiler bug. As far as I know, accepter() and accepter!()() has no difference in IFTI. I filed the issue in bugzilla. https://issues.dlang.org/show_bug.cgi?id=14174 Kenji Hara
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim Grøstad wrote: then query the GC wether the memory is still allocated. This is racy, though. Someone (or the GC) could have freed the object in the meantime, and a new object of potentially different type could have taken its place. You won't get around pinning it.
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz wrote: On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim Grøstad wrote: then query the GC wether the memory is still allocated. This is racy, though. Someone (or the GC) could have freed the object in the meantime, and a new object of potentially different type could have taken its place. You won't get around pinning it. It will statistically work for objects that are large and have high entropy. Just hash the fields you want to be the same. If entropy is a problem add a unique instance id that is a large random bit string and make sure it is cleared when the object is released. It's the same technique used for IDs in distributed systems under the assumption that the probability of hardware failure is larger than the probability of a ID collision... but you have to do the math to be sure that the probability of failure is acceptable.
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 16:27:21 UTC, Ola Fosheim Grøstad wrote: On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz wrote: On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim Grøstad wrote: then query the GC wether the memory is still allocated. This is racy, though. Someone (or the GC) could have freed the object in the meantime, and a new object of potentially different type could have taken its place. You won't get around pinning it. It will statistically work for objects that are large and have high entropy. Just hash the fields you want to be the same. If entropy is a problem add a unique instance id that is a large random bit string and make sure it is cleared when the object is released. It's the same technique used for IDs in distributed systems under the assumption that the probability of hardware failure is larger than the probability of a ID collision... but you have to do the math to be sure that the probability of failure is acceptable. Whoaa, that's just horrible! *shudder*
Re: Is there an object on given memory address?
On Thursday, 12 February 2015 at 16:56:24 UTC, Marc Schütz wrote: Whoaa, that's just horrible! *shudder* I know, but it works.
Re: GC has a barbaric destroyng model, I think
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote: On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin wrote: If we can't relay on GC wholly, there is no need for GC. All of the objects, that I can create, I can destroy manually by myself, without any doubtful GC destroying attempts. Manual memory management should be possible in D, see for example https://github.com/Dgame/m3 And since today it is @safe wherever possible.
