date:20140527


On Tuesday, 27 May 2014 at 02:52:48 UTC, Etienne Cimon wrote:
I've been looking at the GC and found that the main problem is 
that there's no clear information about the pointers. At least 
smart pointers have some info inside them but GC pointers are 
completely plain 4-8 bytes and nothing else.


On 64 bit platform 8 bytes is sufficient if you control the 
allocator:


1. Avoid allocating non-GC memory from specific address range.
2. Set a max-size for GC allocated objects.

Then the test becomes this:

if ((ptr  NONGCMASK)==0){
   heapinfo_ptr = ptrMASK;

  // process ptr
}

Does D support plugins with dll written in D ?

2014-05-27 Thread chmike via Digitalmars-d


Hello,

note that D is still very new to me.

The documentation for 
http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary is 
a bit too terse to answer my question.


I would like to know if it would allow to use Object.factory() 
with the classes defined in the loaded library and if the GC 
would manage data allocated with new in the code of the library.


Does the loaded dll need to be defined as a module or something 
like that ?

Re: Member function pointers

2014-05-27 Thread d coder via Digitalmars-d

On Mon, Jun 10, 2013 at 10:13 PM, Jacob Carlborg d...@me.com wrote:

 On 2013-06-10 18:34, Manu wrote:

 On 11 June 2013 02:26, Jacob Carlborg d...@me.com mailto:d...@me.com

 wrote:

 On 2013-06-10 17:40, David Nadlinger wrote:

 Let me try to summarize it in code:

 ---
 class A { void foo(); }
 auto memberFun = (A.foo).funcptr;

 auto a = new A;
 memberFun(a);
 ---


 Why is this better than a delegate?


 It's not 'better', it's different.


 class A { void foo(); }
 auto memberFun = (A.foo).funcptr;

 auto a = new A;
 void delegate () dg;
 dg.funcptr = memberFun;
 dg.ptr = cast(void*) a;
 dg();

 The details can be hidden in a function call. Sure, a delegate could be
 type safe but still don't see the point.

 --
 /Jacob Carlborg


Greetings

Apologies for bringing up this year old thread.

With https://github.com/D-Programming-Language/dmd/pull/3181 getting
merged, it is no longer feasible to directly assign dg.funcptr (which is
not an lvalue now). The problem is that the code suggested by David also
does not work.

Is there an alternative?

Regards
- Puneet

Questions about the scope/Exception machinery


Hello dear D fellows :D,

The problem boils down to this.

I try to write a Software which should be as compact as possible.
This means that i don't like to use any exception handling (which
appears to be hardly integrated into the language, not that good
for demoscene/OS dev stuff).
So i ran into the first issue, scope expressions.

When i write

  scope(exit) foo();

it seems that it generates exception ahndling code. Is this the
case even if the called function and the callee are both nothrow
decorated? Can i force the compiler to generate goto code instead
of the exception handling stuff?

Re: Questions about the scope/Exception machinery


ok I found a old thread about it, just delete this thread please

Re: Questions about the scope/Exception machinery

2014-05-27 Thread Daniel Kozak via Digitalmars-d

Dne Tue, 27 May 2014 14:02:04 +0200 Qox via Digitalmars-d  
digitalmars-d@puremagic.com napsal(a):



ok I found a old thread about it, just delete this thread please




This is mail list so it is not possible to delete thread. Btw, can you  
post link to the thread which you find.

Re: Questions about the scope/Exception machinery


The thread is

http://forum.dlang.org/thread/dtcxszysceiopzwew...@forum.dlang.org?page=1
Title scope(exit) without exception handling?

Re: Member function pointers

2014-05-27 Thread d coder via Digitalmars-d

https://github.com/D-Programming-Language/dmd/pull/3181

Daniel asked me to use this. And it works.

Use something like:

union U
{
  void delegate(int) dg;
  struct
  {
void* ptr;
void function(int) funcptr;
  }
}
U u;
u.dg = dg;
u.funcptr = ...;
u.ptr = ...;

Regards
- Puneet

Re: Questions about the scope/Exception machinery


nothrow doesn't seem to work with the recent dmd compiler :(
I know it because _d_local_unwind2() is still called.

Seems as if I need another more ugly (but still nicer than C++) 
solution. Mixins which jump on an error to a label...hell I love 
low level languages (Java is in this sense crap because they 
disallow [usefull] constructs like goto, templates, ...)


the code will look like this (usage)

 mixin(onError(condition, handling0, handlingCallback, 
parameter0, parameter1));


the CTFE function onError checks the condition, if it is false it 
copies the parameters into variables and jumps to the label named 
after handling0.


on the end of the function there will be

 mixin(errorHandling(cast(int)0, [handling0, 
handlingCallback, ...]));


which writes the goto labels, handling code etc which looks like 
this


 label_handleFoo:
 handleFoo();
 label_handling0:
 handlingCallback(handling0_parameter0, handling0_parameter1);
 return cast(int)0;

a bit ugly but not so ugly as C++ ... any better ideas?

Re: Questions about the scope/Exception machinery

Ofcourse this doesn't look that maintainable to me...well, then 
the C++ struct destructor way???

Re: Questions about the scope/Exception machinery

2014-05-27 Thread Mike Parker via Digitalmars-d


On 5/27/2014 9:07 PM, Daniel Kozak via Digitalmars-d wrote:

Dne Tue, 27 May 2014 14:02:04 +0200 Qox via Digitalmars-d
digitalmars-d@puremagic.com napsal(a):


ok I found a old thread about it, just delete this thread please




This is mail list so it is not possible to delete thread. Btw, can you
post link to the thread which you find.


Actually, it's a newsgroup server :)

Re: Questions about the scope/Exception machinery

2014-05-27 Thread Mike Parker via Digitalmars-d


On 5/27/2014 9:43 PM, Qox wrote:

nothrow doesn't seem to work with the recent dmd compiler :(
I know it because _d_local_unwind2() is still called.



notrhow doesn't turn off exception handling. It just doesn't allow you 
to throw from a particular function. From inside a nothrow function, you 
can still call functions that throw, but you have to wrap them in 
try..catch blocks and swallow any exceptions that *are* thrown.

System level language, GC, allocation and typeinfo

The terms system level programming and garbage collection are 
mutually exclusive, but I see the value in GC. However, I cannot 
really come up with a single situation where I don't know what 
kind of allocator I have used when accessing a pointer.


I think it makes a lot of sense to think in the direction of the 
post of Etienne and have allocator based pointer types. With a 
template heavy coding style it becomes less problematic than in a 
language like C. If you go templates all the way. That could 
reduce the amount of scanned memory significantly. Basically I 
think a system level language should have at least 
owned/borrowed, ref counted and gc-pointer types.


I also wonder how often you actually have a need to discriminate 
between more than 255 classes. It seems to me that with whole 
program compilation you could often just use a single byte for 
type info and a switch table for virtual functions. That would 
leave a lot more room for optimization.


When it comes to allocators I am more likely to use a factory for 
creating objects from my own allocator than pooling different 
types in a generic allocator. Except maybe for regions that are 
to be released at once, but I don't use that much. So I wonder if 
it is better to rather spend the effort on partial 
pre-initialization as an optimization for class specific 
factories than trying to be overly generic. By partial 
pre-initialization I mean that you reset used fields when an 
object is freed, thus you don't need to reinitialize vtable 
pointers and avoid calling constructors upon allocation (the 
objects are pre-constructed). Ideally you push object 
construction to time periods where the CPU is idle.


With a performance mindset…

Re: Questions about the scope/Exception machinery

sounds a bit like C++ handling to me, for me *personally* it 
misses also the point about nothrow, because it gurantues 
nothing...which is like in C++ and imho bad...

Re: New pointer type for GC


On Tuesday, 27 May 2014 at 03:26:33 UTC, Etienne Cimon wrote:

On 2014-05-26 23:19, Daniel Murphy wrote:
Etienne Cimon  wrote in message 
news:lm0um0$tgh$1...@digitalmars.com...


I think everything everywhere would have to change for this 
to be

possible.


Sounds like never gonna happen.


In terms of logic it's not that complicated, I could change 
DMD, druntime, phobos myself for it. The main problem is that 
the apostrophe is really, a major cultural change


Please, no apostrophe. It'll mess syntax highlighters, and 
possible indenters.

Re: New pointer type for GC

On 2014-05-27 3:56 AM, Ola Fosheim Grøstad 
ola.fosheim.grostad+dl...@gmail.com wrote:

On 64 bit platform 8 bytes is sufficient if you control the allocator:

1. Avoid allocating non-GC memory from specific address range.
2. Set a max-size for GC allocated objects.

Then the test becomes this:

if ((ptr  NONGCMASK)==0){
heapinfo_ptr = ptrMASK;

   // process ptr
}


That's true, though you still need the thread ID for references to 
pointers and you need to be able to pass those pointers to C.


If that's done manually, you end up sanitizing the pointers too often, 
it becomes boilerplate.

Re: New pointer type for GC


On 2014-05-27 9:52 AM, Idan Arye wrote:

Please, no apostrophe. It'll mess syntax highlighters, and possible
indenters.


How about #?

void# ptr;

void## ptr2 = ptr;

assert(sizeof(ptr) == size_t + 3);
assert(szptr_t == sizeof(ptr));
szptr_t ptr2Val = cast(szptr_t) ptr;
char magicNum = ptr2.magic;
dchar threadId = ptr2.thread;
char[3] poolId = ptr.pool;

Re: New pointer type for GC

2014-05-27 Thread Steven Schveighoffer via Digitalmars-d


On Tuesday, 27 May 2014 at 13:58:26 UTC, Etienne wrote:
That's true, though you still need the thread ID for references 
to pointers and you need to be able to pass those pointers to C.


I am not really sure how useful references to gc-pointers is. I 
certainly would trade them in for multiple return values. I also 
think it is reasonable to ban transfer of GC mem to C code if all 
GC mem is accounted for with gc-typed pointers...

Re: Associative Arrays max length? 32bit/64bit

On Mon, 26 May 2014 19:03:22 -0400, H. S. Teoh via Digitalmars-d  
digitalmars-d@puremagic.com wrote:


On Sat, May 24, 2014 at 11:54:47PM -0700, Steven Schveighoffer via  
Digitalmars-d wrote:

On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:

On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer via
Digitalmars-d wrote:
On Sat, 24 May 2014 02:54:01 -0700, FG h...@fgda.pl wrote:
[...]
Really? Then what does TypeInfo.compare(void*, void*) use? For
example here:

 auto key_hash = keyti.getHash(pkey); Entry *e;
 /* ... */
 if (key_hash == e.hash) {
 auto c = keyti.compare(pkey, e + 1);
 if (c == 0) goto Lret;
 }

You know what, you are right. I assumed it used keyti.equals. This
is a bug imo, since opCmp will be used, and opEquals will be
ignored.  Just checking for opCmp == 0 is identical to opEquals,
except some types can define opEquals but not opCmp.

But I don't know if it will get fixed. The whole AA runtime has to
be redone at some point.
[...]

This has been argued over in a druntime pull before. I'm 100% for
changing the above line (and all other instances of it) to use
keyti.equals() instead. But that was shot down due to potential
breakage of existing code. :-( :-( Nevermind the fact that it
probably breaks a lot more *new* code than it ever will break old
code... :-(

Any object/struct that defines opCmp but not opEquals is broken, and
deserves to not work with AAs.

It's a trivial change to add opEquals when opCmp is defined. This change
should happen should happen. What pull request is it?


Sorry for the late response, I've been very busy with other things.

I can't seem to find the PR anymore (it got closed over disagreement
about how things should be fixed), but I did find the branch my code was
in. The bugzilla issue is 10380. Looking at the bug, I see that
apparently Denis has pushed through a hack fix for it:

https://github.com/D-Programming-Language/druntime/pull/736


Hah, looking at that PR, it references the original PR  
(https://github.com/D-Programming-Language/druntime/pull/522). In which I  
commented, I remember this one. And look, there are the rules I outlined :)


But I think there was some indication that a runtime-based version was  
imminent. I don't know what happened to that.


Going to comment again on that PR. We should do something to make our way  
back to sane logic.



It's been far too long that AA's have been broken in druntime.
Somebody should just take the aaA.d out in the back and shoot it, and
replace it with a better implementation. I think users will be far
happier with that.

I don't know that the current implementation is broken, just horrible.
I'd rather focus on getting a full library type able to be up-to-par
with the builtin type, and then switch the implementation over in the
compiler. IIRC, the compiler does some magic (i.e. ignoring certain
attribute requirements) that can't be done for a library type.

[...]

It's not that hard to get a library AA to be on par with the builtin
type. The last time I tried it, though, I got stuck on trying that solve
const issues that even the builtin type doesn't solve correctly. The
main showstopper, however, is the amount of effort it takes to extricate
the current AA implementation from the compiler. There are just too many
places where it relies on compiler magic.


Yes, it would be worth a lot to see if we can create an equivalent AA type  
in the library first, BEFORE trying to replace the builtin AA. The way it  
was done originally, was more of a mess than the fully compiler-defined AA.


But this doesn't mean we can't fix the runtime.

-Steve

Re: New pointer type for GC

On 2014-05-27 10:18 AM, Ola Fosheim Grøstad 
ola.fosheim.grostad+dl...@gmail.com wrote:

On Tuesday, 27 May 2014 at 13:58:26 UTC, Etienne wrote:

That's true, though you still need the thread ID for references to
pointers and you need to be able to pass those pointers to C.


I am not really sure how useful references to gc-pointers is. I
certainly would trade them in for multiple return values. I also think
it is reasonable to ban transfer of GC mem to C code if all GC mem is
accounted for with gc-typed pointers...


I think the GC is the future of D considering it's embedded to the very 
core of the language, and compatibility with C code is ... elementary.


Also, thread IDs in ptr references are to the GC as ref counts are to 
the smart pointers. If you remove the refCount from smart pointers, you 
end up scanning the whole memory to count them don't you? So then, why 
remove the thread ID from GC references, if only to look for them in 
each thread? You slow the GC down by as much total memory there is in 
all threads vs the avg in a thread, AND you remove parallel collection - 
by not having the Thread ID in gc ptr references


So you understand that's exactly why the GC has to stop the world, and 
no gaming platform will ever turn to the default behavior of a language 
if it stops its world. As a matter of fact, I can't see any other way of 
fixing the GC than adding the Thread ID in there :/

Re: Questions about the scope/Exception machinery


On Tuesday, 27 May 2014 at 13:24:08 UTC, Qox wrote:
sounds a bit like C++ handling to me, for me *personally* it 
misses also the point about nothrow, because it gurantues 
nothing...which is like in C++ and imho bad...


It guarantees at compile time that your function will not throw 
an Exception.

Re: New pointer type for GC


On Tuesday, 27 May 2014 at 14:42:34 UTC, Etienne wrote:
I think the GC is the future of D considering it's embedded to 
the very core of the language, and compatibility with C code is 
... elementary.


Well, but then I think you should be required to do manual 
tracking while it is being retained by C code. Basically a ref 
counter that keeps it marked reachable by the gc until released.


You slow the GC down by as much total memory there is in all 
threads vs the avg in a thread, AND you remove parallel 
collection - by not having the Thread ID in gc ptr references


Not if you restrict the gc heap to a set of blocks. You can also 
keep thread info in the heap memoryblock.


behavior of a language if it stops its world. As a matter of 
fact, I can't see any other way of fixing the GC than adding 
the Thread ID in there :/


By having multiple local GCs?

Voldemort declarations inside structs with ctor initialization


Considering something like this:

auto stuff = [1, 2, 3];

struct Foo
{
typeof(stuff.filter!(a != 2)) foo;

this(int = 0)
{
// assume we must initialize foo in ctor,
// for instance because it needs ctor args;
// in this contrived case because 'stuff'
// is not known at compile-time
foo = stuff.filter!(a != 2);
}

auto front() { return foo.front(); }
void popFront() { return foo.popFront(); }
bool empty() { return foo.empty; }
}

If the language allowed foo to be declared using auto (which 
would be deduced from the assignment in the ctor), that would be 
nice, right? Is that too hard to implement? As it stands, in some 
situations the declaration can get rather awkward and unwieldy 
(yes, an alias helps). It also violates the DRY principle, 
requiring changes in two places, when they do occur.


BTW, why doesn't this example work with lambdas (a = a != 2) 
instead of a string mixin (a != 2)?


BTW 2, is `this(int = 0)' the best workaround (still?) for the 
fact that I want the ctor to be called, even if it doesn't really 
require any parameter?

Re: Voldemort declarations inside structs with ctor initialization

2014-05-27 Thread bearophile via Digitalmars-d


Luís Marques:

If the language allowed foo to be declared using auto (which 
would be deduced from the assignment in the ctor), that would 
be nice, right?


This is a kind of flow typing, it's rather useful but it 
introduces several complexities, so I think it's now too much 
late to add it to D.



BTW, why doesn't this example work with lambdas (a = a != 2) 
instead of a string mixin (a != 2)?


I think lambda instantiations defines a different type. So it's 
incompatible.




BTW 2, is `this(int = 0)' the best workaround (still?)


I think it's not a good workaround.

Bye,
bearophile

Re: Thanks for a great DConf

2014-05-27 Thread Bastiaan Veelo via Digitalmars-d


On Saturday, 24 May 2014 at 23:37:44 UTC, aliyome wrote:

On Saturday, 24 May 2014 at 20:34:03 UTC, monarch_dodra wrote:
On Saturday, 24 May 2014 at 17:40:29 UTC, Nick Sabalausky 
wrote:
I'm looking forward to the YouTube reruns for the talks I 
still missed. (I still can't believe I missed Andrei's 
keynote!)


+1 please.


me too. +1


+1, thanks.

Re: Voldemort declarations inside structs with ctor initialization


On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:
BTW, why doesn't this example work with lambdas (a = a != 2) 
instead of a string mixin (a != 2)?


I think lambda instantiations defines a different type. So it's 
incompatible.


Incompatible with what? I meant changing it in both the 
declaration and the initialization.



BTW 2, is `this(int = 0)' the best workaround (still?)


I think it's not a good workaround.


What should I use then?

Re: Voldemort declarations inside structs with ctor initialization


On Tuesday, 27 May 2014 at 15:40:04 UTC, Luís Marques wrote:

On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:
BTW, why doesn't this example work with lambdas (a = a != 2) 
instead of a string mixin (a != 2)?


I think lambda instantiations defines a different type. So 
it's incompatible.


Incompatible with what? I meant changing it in both the 
declaration and the initialization.


Lambdas are not cached, so each lambda is unique even if it's 
code is the same:


void main(){
pragma(msg,(int a)=a); //prints __lambda1
pragma(msg,(int a)=a); //prints __lambda2
}


At any rate, you can't use lambdas(neither `delegate` nor 
`function`) when declaring a member of class or struct, since D 
will treat it as a method(rather than a static function) and 
complain about the `this` reference.

Re: New pointer type for GC

On 2014-05-27 10:54 AM, Ola Fosheim Grøstad 
ola.fosheim.grostad+dl...@gmail.com wrote:

On Tuesday, 27 May 2014 at 14:42:34 UTC, Etienne wrote:

I think the GC is the future of D considering it's embedded to the
very core of the language, and compatibility with C code is ...
elementary.


Well, but then I think you should be required to do manual tracking
while it is being retained by C code. Basically a ref counter that keeps
it marked reachable by the gc until released.


You slow the GC down by as much total memory there is in all threads
vs the avg in a thread, AND you remove parallel collection - by not
having the Thread ID in gc ptr references


Not if you restrict the gc heap to a set of blocks. You can also keep
thread info in the heap memoryblock.


behavior of a language if it stops its world. As a matter of fact, I
can't see any other way of fixing the GC than adding the Thread ID in
there :/


By having multiple local GCs?



You're right, it's obviously easier to keep it as the same pointer 
syntax but hijack the stdlib malloc functions to forcibly go through the GC.


If the GC controls everything, you can keep the info in 8 byte pointers.

- The GC always returns an libc-incompatible pointer value
- Dereferencing should call the resolver from the GC to process it with 
the libc-compatible value (possibly just removing the last couple bytes)
- Sending a pointer through extern(C) should call the sanitizer which 
resolves the real pointer through the GC and sends that
- The last bytes of a pointer would contain thread ID for void** and 
poolID for void*

- This would only work on x64 platforms

Re: New pointer type for GC


On Tuesday, 27 May 2014 at 16:47:38 UTC, Etienne wrote:
You're right, it's obviously easier to keep it as the same 
pointer syntax but hijack the stdlib malloc functions to 
forcibly go through the GC.


That is an option, and having a hijacked malloc would probably 
also make it possible to optimize out uneccessary allocations as 
well as inline allocations.


If you have a GC-pointer type and ban transitions to regular 
pointers unless they are borrowed pointers then that would also 
be ok (you don't need to hijack malloc then).

Re: System level language, GC, allocation and typeinfo

On 2014-05-27 9:06 AM, Ola Fosheim Grøstad 
ola.fosheim.grostad+dl...@gmail.com wrote:

I think it makes a lot of sense to think in the direction of the post of
Etienne and have allocator based pointer types. With a template heavy
coding style it becomes less problematic than in a language like C. If
you go templates all the way. That could reduce the amount of scanned
memory significantly. Basically I think a system level language should
have at least owned/borrowed, ref counted and gc-pointer types.


I agree about this.

The GC could be optimized under x86_64, with 18,446,744,073,709,551,615 
possible values you don't exactly have any computers with 18 exabytes 
(18,000 petabytes) of memory. This is a lot of wasted space that could 
be used to make the GC lookups at O(1) speed with parallel collection.

Re: Voldemort declarations inside structs with ctor initialization


On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:

Luís Marques:

If the language allowed foo to be declared using auto (which 
would be deduced from the assignment in the ctor), that would 
be nice, right?


This is a kind of flow typing, it's rather useful but it 
introduces several complexities, so I think it's now too much 
late to add it to D.


Not necessarily. The first assignment of a member in a 
constructor is already treated as special, so I guess we're 
halfway there.

Re: Voldemort declarations inside structs with ctor initialization

2014-05-27 Thread Andrei Alexandrescu via Digitalmars-d


On 5/27/14, 6:26 AM, Idan Arye wrote:

On Tuesday, 27 May 2014 at 15:40:04 UTC, Luís Marques wrote:

On Tuesday, 27 May 2014 at 15:06:53 UTC, bearophile wrote:

BTW, why doesn't this example work with lambdas (a = a != 2)
instead of a string mixin (a != 2)?


I think lambda instantiations defines a different type. So it's
incompatible.


Incompatible with what? I meant changing it in both the declaration
and the initialization.


Lambdas are not cached, so each lambda is unique even if it's code is
the same:

 void main(){
 pragma(msg,(int a)=a); //prints __lambda1
 pragma(msg,(int a)=a); //prints __lambda2
 }


At any rate, you can't use lambdas(neither `delegate` nor `function`)
when declaring a member of class or struct, since D will treat it as a
method(rather than a static function) and complain about the `this`
reference.


I think there was either or both a discussion and a bug report on this, 
but can't find either. Basically we need to clarify what it means to 
compare two function literals for equality. -- Andrei

Re: Voldemort declarations inside structs with ctor initialization


On Tuesday, 27 May 2014 at 17:23:24 UTC, Marc Schütz wrote:
Not necessarily. The first assignment of a member in a 
constructor is already treated as special, so I guess we're 
halfway there.


That's what I was thinking. *crosses fingers*

Re: Voldemort declarations inside structs with ctor initialization

On Tuesday, 27 May 2014 at 17:22:43 UTC, Andrei Alexandrescu 
wrote:
I think there was either or both a discussion and a bug report 
on this, but can't find either. Basically we need to clarify 
what it means to compare two function literals for equality. -- 
Andrei


I remember the thread where the consensus seemed to be that 
hashing was the way to go. I think it's just that nobody ever 
implemented it.

Re: System level language, GC, allocation and typeinfo

2014-05-27 Thread MachMit via Digitalmars-d

On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad 
wrote:
...However, I cannot really come up with a single situation 
where I don't know what kind of allocator I have used when 
accessing a pointer


Heap allocation in D is up to the user. Can you imagine something 
like http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry 
for being an arsh) fuckin good memory manager...It's for user or 
RT allocations, it detects leaks, etc...It should be a source of 
inspiration for the top-notch D guys...

Re: Voldemort declarations inside structs with ctor initialization

2014-05-27 Thread Andrei Alexandrescu via Digitalmars-d


On 5/27/14, 7:51 AM, Meta wrote:

On Tuesday, 27 May 2014 at 17:22:43 UTC, Andrei Alexandrescu wrote:

I think there was either or both a discussion and a bug report on
this, but can't find either. Basically we need to clarify what it
means to compare two function literals for equality. -- Andrei


I remember the thread where the consensus seemed to be that hashing was
the way to go. I think it's just that nobody ever implemented it.


Hmmm, are you sure? What about alpha renaming? -- Andrei

Re: System level language, GC, allocation and typeinfo

2014-05-27 Thread Andrei Alexandrescu via Digitalmars-d


On 5/27/14, 7:59 AM, MachMit wrote:

On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad wrote:

...However, I cannot really come up with a single situation where I
don't know what kind of allocator I have used when accessing a
pointer


Heap allocation in D is up to the user. Can you imagine something like
http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry for being
an arsh) fuckin good memory manager...It's for user or RT allocations,
it detects leaks, etc...It should be a source of inspiration for the
top-notch D guys...


Is there a white paper available for FastMM? Couldn't find any. -- Andrei

Re: Voldemort declarations inside structs with ctor initialization

2014-05-27 Thread H. S. Teoh via Digitalmars-d

On Tue, May 27, 2014 at 08:17:26AM -1000, Andrei Alexandrescu via Digitalmars-d 
wrote:
 On 5/27/14, 7:51 AM, Meta wrote:
 On Tuesday, 27 May 2014 at 17:22:43 UTC, Andrei Alexandrescu wrote:
 I think there was either or both a discussion and a bug report on
 this, but can't find either. Basically we need to clarify what it
 means to compare two function literals for equality. -- Andrei
 
 I remember the thread where the consensus seemed to be that hashing
 was the way to go. I think it's just that nobody ever implemented it.
 
 Hmmm, are you sure? What about alpha renaming? -- Andrei

If we want to be technically correct, we would have to define function
literal comparison as being true iff the two functions produce an
identical computation. So:

(x) = true

would have to be equal to:

(x) = solveFermatsLastTheorem()

But unfortunately, this kind of equivalence is unsolvable in the general
case (it requires solving the halting problem), and infeasible except
for the most trivial cases (the compiler has to spend way too much time
to compute equivalence).

Hashing gives a crude first approximation that's both easy to implement,
fast, works in the cases where this issue came up in the first place,
and doesn't require solving unsolvable problems.

Alpha-renaming is not hard to support if the compiler just assigns each
declared identifier in the function literal to a numerical id. So a
literal like:

(xcoor,ycoor) = sqrt(xcoor*xcoor, ycoor*ycoor)

and

(x,y) = sqrt(x*x, y*y)

would both get translated to:

(id1, id2) = sqrt(id1*id1, id2*id2)

and so they would compare as equal. This does require a little more
effort on the part of the compiler, though -- you'd have to walk the AST
of the function body.

I wouldn't go any farther than this, because this quickly approaches the
no-man's land of whether (x) = x+x+x should compare equal to (y) = y*3
(if floating-point is involved the two functions may *not* in fact be
equivalent, for example), whether to compare equal if two different
functions get optimized to the same assembly code (which may differ
depending on compiler / compile flags), etc..

Honestly, I don't see the need even for alpha-renaming -- I can't
imagine a use case where you'd want to do something like that. I think
straight up hashing of the function body is Good Enough(tm).


T

-- 
Once bitten, twice cry...

Re: System level language, GC, allocation and typeinfo

2014-05-27 Thread Wyatt via Digitalmars-d

On Tuesday, 27 May 2014 at 18:19:14 UTC, Andrei Alexandrescu 
wrote:

On 5/27/14, 7:59 AM, MachMit wrote:
On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad 
wrote:
...However, I cannot really come up with a single situation 
where I

don't know what kind of allocator I have used when accessing a
pointer


Heap allocation in D is up to the user. Can you imagine 
something like
http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry 
for being
an arsh) fuckin good memory manager...It's for user or RT 
allocations,
it detects leaks, etc...It should be a source of inspiration 
for the

top-notch D guys...


Is there a white paper available for FastMM? Couldn't find any. 
-- Andrei


I Googled a little and found this, but nothing with larger scale: 
http://edn.embarcadero.com/article/33416#27ImplementationDetails


-Wyatt

Re: System level language, GC, allocation and typeinfo

On Tuesday, 27 May 2014 at 18:19:14 UTC, Andrei Alexandrescu 
wrote:

Is there a white paper available for FastMM? Couldn't find any.


http://sourceforge.net/p/fastmm/code/HEAD/tree/FastMM4_Readme.txt

Re: Voldemort declarations inside structs with ctor initialization

On Tuesday, 27 May 2014 at 18:54:05 UTC, H. S. Teoh via 
Digitalmars-d wrote:
Honestly, I don't see the need even for alpha-renaming -- I 
can't
imagine a use case where you'd want to do something like that. 
I think

straight up hashing of the function body is Good Enough(tm).


T


Hashing the function body is not enough - you must also consider 
the closure!


template Template(alias func){
bool Template=func();
}

void foo(){
int a;
writeln(Template!(()=is(typeof(a) : char))); //prints 
false

}

void bar(){
char a;
writeln(Template!(()=is(typeof(a) : char))); //prints 
true

}

If two delegates must have exactly the same scope, the usefulness 
of the hashing will be quite limited, but in many cases the same 
lambda can be declared in different scopes and still be the same. 
It all depends on how the lambda uses the closure - and checking 
this will be quite hard to implement...

Re: System level language, GC, allocation and typeinfo

2014-05-27 Thread MachMit via Digitalmars-d

On Tuesday, 27 May 2014 at 18:19:14 UTC, Andrei Alexandrescu 
wrote:

On 5/27/14, 7:59 AM, MachMit wrote:
On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad 
wrote:
...However, I cannot really come up with a single situation 
where I

don't know what kind of allocator I have used when accessing a
pointer


Heap allocation in D is up to the user. Can you imagine 
something like
http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry 
for being
an arsh) fuckin good memory manager...It's for user or RT 
allocations,
it detects leaks, etc...It should be a source of inspiration 
for the

top-notch D guys...


Is there a white paper available for FastMM? Couldn't find any. 
-- Andrei


The source file is documented IIRC. It could be a source of 
inspiration for the allocators (There is something about that in 
D you've introduced a few monthes ago, I think...), or maybe a 
branch/sub-set, GC-free, version of D arrays and classes.


But it was mainly written for the previous-decade delphi.(D7 to 
D2009), the point is it contains some optimized version of memcpy 
and memmove (inline asm partially comming from the fastcode 
project(http://fastcode.sourceforge.net/ for the x86 arch. at 
least...) But At this time the memory model was the same as D 
except that you (the programmer) were the GC...Otherwise the 
compilo was inserting some automatic cleanup code for locally 
allocated data(even when standing in the heap...)...


However something like this would be better than some user call 
to malloc/realloc...(because it internally handles the hardware 
spec...i.e

when copying: the page size, vector operations).

Re: Voldemort declarations inside structs with ctor initialization


On Tuesday, 27 May 2014 at 19:39:23 UTC, Idan Arye wrote:
Hashing the function body is not enough - you must also 
consider the closure!


template Template(alias func){
bool Template=func();
}

void foo(){
int a;
writeln(Template!(()=is(typeof(a) : char))); //prints 
false

}

void bar(){
char a;
writeln(Template!(()=is(typeof(a) : char))); //prints 
true

}

If two delegates must have exactly the same scope, the 
usefulness of the hashing will be quite limited, but in many 
cases the same lambda can be declared in different scopes and 
still be the same. It all depends on how the lambda uses the 
closure - and checking this will be quite hard to implement...


If I remember correctly, the main use-case of comparing lambda 
functions was for cases like this:


auto rb1 = make!(RedBlackTree!(int, (a, b) = a  b))([4, 2, 3, 
1]);
auto rb2 = make!(RedBlackTree!(int, (a, b) = a  b))([4, 2, 3, 
1]);

assert(is(typeof(rb1) == typeof(rb2))); //FAIL
assert(rb1 == rb2); //FAIL

Note that this code passes if you define a top-level function 
less and pass it to make. Functions don't have function 
pointers, only delegates, so as a first step we could implement 
hashing for functions, which don't have to deal with all this 
context pointer business. Also, couldn't you achieve the same for 
delegates if you specify that only @pure @nogc delegates can be 
compared?

Re: auto-tester hardware donations

2014-05-27 Thread Jerry via Digitalmars-d

Brad Roberts via Digitalmars-d digitalmars-d@puremagic.com writes:

 On 5/25/14, 7:54 AM, monarch_dodra via Digitalmars-d wrote:
 On Saturday, 24 May 2014 at 17:58:08 UTC, Brad Roberts via Digitalmars-d 
 wrote:
 As discussed a little at the conference, the auto-tester is almost always 
 hardware bound.  In
 other words, it's building flat out 24/7.  More hardware == faster updates 
 to build status.  If
 anyone wants to provide hardware to help there's a number of ways to do so. 
  Here's my order of
 preference:

 1) you have a machine you host somewhere and can provide me remote access 
 to.
 - this could be a bare metal host or a vm

 At this point, I'd MUCH rather have hardware that doesn't live in my house. 
  I've got too many
 already.  But I also don't want to turn down good equipment.  So, please 
 reach out to me privately
 if you'd like to help out: bra...@puremagic.com

 Thanks,
 Brad

 Would there be any way to be able to set-up and configure the machines on 
 our end, and to register
 them into the auto-testers once they are ready to go?

I'd be willing to run some autotesting in my house.  Granting remote
access, not so much :-)

How hard would it be to turn the autotester client into such a pull system?

Jerry

Re: auto-tester hardware donations

2014-05-27 Thread Brad Roberts via Digitalmars-d

On 5/27/14, 1:41 PM, Jerry via Digitalmars-d wrote:

Brad Roberts via Digitalmars-d digitalmars-d@puremagic.com writes:

On 5/25/14, 7:54 AM, monarch_dodra via Digitalmars-d wrote:

On Saturday, 24 May 2014 at 17:58:08 UTC, Brad Roberts via Digitalmars-d wrote:

As discussed a little at the conference, the auto-tester is almost always
hardware bound. In
other words, it's building flat out 24/7. More hardware == faster updates to
build status. If
anyone wants to provide hardware to help there's a number of ways to do so.
Here's my order of
preference:

1) you have a machine you host somewhere and can provide me remote access to.
- this could be a bare metal host or a vm

At this point, I'd MUCH rather have hardware that doesn't live in my house.
I've got too many
already. But I also don't want to turn down good equipment. So, please reach
out to me privately
if you'd like to help out: bra...@puremagic.com

Thanks,
Brad

Would there be any way to be able to set-up and configure the machines on our end, and to
register
them into the auto-testers once they are ready to go?

I'd be willing to run some autotesting in my house. Granting remote
access, not so much :-)

How hard would it be to turn the autotester client into such a pull system?

Jerry

All of it's 'steady state' operations are pull, or rather driven from the client (pull tasks to
perform, push results). It's maintenance and debugging that's interactive. That's the part I'm
reluctant to loose.

Re: isUniformRNG

2014-05-27 Thread Nick Sabalausky via Digitalmars-d


On 5/24/2014 5:19 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:

On 24/05/14 19:46, Nick Sabalausky via Digitalmars-d wrote:

An initial PR for Hash_DRBG being struct-based and directly part of
std.random


I think that's up to you.  I don't want to hold you back here, but
equally, I feel that crypto functionality probably should be prototyped
in an experimental module before being finalized in the standard library.



Perhaps. In any case, I've tossed up a PR for it (it contains a few 
changes since the latest DAuth version of it). Further HashDRBG 
discussion should probably go there:


https://github.com/D-Programming-Language/phobos/pull/2208

Destroy


It's something that's too important to get right (and properly reviewed).

Re: Fixing More Warnings in DMD?

2014-05-27 Thread andro via Digitalmars-d


On Monday, 26 May 2014 at 20:58:22 UTC, Nordlöw wrote:

I've recent fixed a few warnings in D here:

https://github.com/D-Programming-Language/dmd/pull/3543

At the end of the thread I asked:

Should I continue fixing GLUE, BACK and ROOT or focus on 
remaining warnings in DMD?


but Walter has not responded so I'm asking it here once again.

Comments anyone?


Well, I gathered some of warnings I have come across while doing 
some code browsning.


https://github.com/D-Programming-Language/dmd/pull/3598

Re: Voldemort declarations inside structs with ctor initialization


On Tuesday, 27 May 2014 at 20:02:34 UTC, Meta wrote:

On Tuesday, 27 May 2014 at 19:39:23 UTC, Idan Arye wrote:
Hashing the function body is not enough - you must also 
consider the closure!


   template Template(alias func){
   bool Template=func();
   }

   void foo(){
   int a;
   writeln(Template!(()=is(typeof(a) : char))); //prints 
false

   }

   void bar(){
   char a;
   writeln(Template!(()=is(typeof(a) : char))); //prints 
true

   }

If two delegates must have exactly the same scope, the 
usefulness of the hashing will be quite limited, but in many 
cases the same lambda can be declared in different scopes and 
still be the same. It all depends on how the lambda uses the 
closure - and checking this will be quite hard to implement...


If I remember correctly, the main use-case of comparing lambda 
functions was for cases like this:


auto rb1 = make!(RedBlackTree!(int, (a, b) = a  b))([4, 2, 3, 
1]);
auto rb2 = make!(RedBlackTree!(int, (a, b) = a  b))([4, 2, 3, 
1]);

assert(is(typeof(rb1) == typeof(rb2))); //FAIL
assert(rb1 == rb2); //FAIL

Note that this code passes if you define a top-level function 
less and pass it to make. Functions don't have function 
pointers, only delegates, so as a first step we could implement 
hashing for functions, which don't have to deal with all this 
context pointer business. Also, couldn't you achieve the same 
for delegates if you specify that only @pure @nogc delegates 
can be compared?


Well, it won't work for the example that opened this 
thread(converted to use lambdas).


As for limiting the delegate version to ones that use @pure and 
@nogc, take another look at my example. The lambdas don't 
allocate anything so they're obviously @nogc. As for @pure, they 
doesn't have any side effects, and depend only on their 
arguments(they don't have arguments, and they are constant 
functions) and their scope(which happens to be mutable, but you 
could easily make it immutable and nothing will change).

Re: auto-tester hardware donations

2014-05-27 Thread Walter Bright via Digitalmars-d


On 5/24/2014 10:57 AM, Brad Roberts via Digitalmars-d wrote:

At this point, I'd MUCH rather have hardware that doesn't live in my house.
I've got too many already.


That's why god made garages :-)

Re: Dev. Collaboration

2014-05-27 Thread chuck via Digitalmars-d



I like the specs. idea. The forum is at
http://d-language-and-libs.proboards.com

Re: Voldemort declarations inside structs with ctor initialization