Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 06:31:13 UTC, Mike Parker wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 06:31:13 UTC, Mike Parker wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
---
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T: T)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
---
here it's selected correctly without explicit instantiation. But
honestly i don't know why since the asterisk is removed from the
T it looks quite incorrect.
Template type deduction and specialization
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
[Issue 14610] New: 'null this' assertion missing in 2.067
https://issues.dlang.org/show_bug.cgi?id=14610
Issue ID: 14610
Summary: 'null this' assertion missing in 2.067
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: tomerfil...@gmail.com
Consider the following code:
==
struct S {
void foo() {}
}
void main() {
S* s = null;
s.foo();
}
==
It used to crash with null this, e.g.,
core.exception.AssertError@main.d(2): null this
but as of 2.067 it crashes with
core.exception.AssertError@source/main.d(0): Assertion failure
So first of all, the message is undescriptive, and second, the line number is
0, which is very weird.
--
Re: 0 is not a power of 2
On Tuesday, 19 May 2015 at 20:46:09 UTC, Matthias Bentrup wrote:
I think you can make the over/underflow at zero work in your
favor:
bool isPowerOf2(uint x)
{
return (x -x) (x - 1);
}
Very nice
Re: DMD Symbol Reference Analysis Pass
On Wednesday, 20 May 2015 at 08:52:23 UTC, Per Nordlöw wrote:
Does DMD currently do any analysis of references to a symbol in
a given scope? If not where could this information be extracted
(in which visitor/callback) and in what structure should it, if
so, be stored?
I'm guessing
Scope::insert(Dsymbol*s)
{
if (VarDeclaration *vd = s-isVarDeclaration())
{
// ..
is of interest. Is there another member function called everytime
a Dsymbol is referenced?
I'm guessing MODFlags plays a role here aswell.
Re: Template type deduction and specialization
On 5/20/2015 6:35 PM, Daniel Kozak wrote:
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be implicitly
deduced may not have specializations:
Thanks. For the record, the example there is the exact same case.
void Foo(T : T*)(T t) { ... }
int x,y;
Foo!(int*)(x); // ok, T is not deduced from function argument
Foo(y); // error, T has specialization
I was looking for the answer in higher up the page in the
Specializations section under Argument Deduction. Didn't think to look
for it under Function Templates.
Re: 0 is not a power of 2
On Wednesday, 20 May 2015 at 09:49:06 UTC, Temtaime wrote:
First version isn't any slow. It's clear and can be optimized
with gdc:
http://goo.gl/Q7HKcU
Yes, and besides, if one cares about these minor performance
issues, that most likely will disappear in the pipeline if you
are a little bit careful about how you arrange your code, then
one one would be better off letting the compiler take advantage
of statically available information about size:
@always_inline
... allocate(ulong size){
if(size==0) return _my_alloc_zero();
if(is_log2_or_zero(size)) return _my_alloc_log2size(size);
return _my_alloc_nonlog2size(size);
}
So basically a version that preserves the tests that the compiler
most easily can get rid of can lead to faster code even if it in
isolation has a few extra instructions.
Re: ddbc: MySQL/MariaDB: Access Violation
On Monday, 18 May 2015 at 18:54:20 UTC, Suliman wrote: GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; p.s. this command return my: Affected rows: 0 Do you see some stack trace on crash? No. I checked on 2 PC and it's not look like my issue, because result is totally same. If I change void main() to vibed's static this() I get this error. Try running under debugger. See where it's crashed.
Re: Template type deduction and specialization
On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote: I'm using a fairly recent version of dmd master, and it prints out the address for px in both cases when I compile your code. So, if it's printing out 100 for you on the second call, it would appear to be a bug that has been fixed at some point since 2.067 (or whatever version you're using) was released. - Jonathan M Davis I'm using 2.067.0, but according to the section of the docs Daniel pointer me to[1], printing 100 is the correct behavior in the second call. [1] http://dlang.org/template.html#function-templates
Re: ddbc: MySQL/MariaDB: Access Violation
On Monday, 18 May 2015 at 18:54:20 UTC, Suliman wrote: GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; p.s. this command return my: Affected rows: 0 Do you see some stack trace on crash? No. I checked on 2 PC and it's not look like my issue, because result is totally same. If I change void main() to vibed's static this() I get this error. Hi, There's are several related problems with vibe's static this; some needed variables are not initialized at the time static this is executed, that's why you get access violation ( it has nothing to do with permissions ). The solution is to use main(). here are some reported issues related to the problem you have described. https://github.com/mysql-d/mysql-native/issues/53 https://github.com/rejectedsoftware/vibe.d/issues/906
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak c...@dawg.eu --- How ludicrous to have a known race condition in synchronized and not fixing it for 3 years. --
Re: Template type deduction and specialization
On Wed, 20 May 2015 06:31:11 +
Mike Parker via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
Because it cannot deduce type T:
try this:
void printVal(T : T*)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
int* px = x;
printVal(px);
}
It will print error.
My advise is not to use T:T* or T:T[] it works only when explicitly
instantiate. Is better use T:M*,M or T:M[], M because it works
automaticly and you have both types available.
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T:M*,M)(T t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the 100
}
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 09:24:28 UTC, Daniel Kozák wrote:
On Wed, 20 May 2015 06:31:11 +
Mike Parker via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug
(I've been unable to turn up anything in Bugzilla), could
someone in the know explain the rationale behind this?
Because it cannot deduce type T:
try this:
void printVal(T : T*)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
int* px = x;
printVal(px);
}
It will print error.
My advise is not to use T:T* or T:T[] it works only when
explicitly
instantiate. Is better use T:M*,M or T:M[], M because it works
automaticly and you have both types available.
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T:M*,M)(T t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the 100
}
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be implicitly
deduced may not have specializations:
Re: GC Destruction Order
On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote: Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking. And what you're asking. Just for the record: C++ memory management techniques are not designed to work in GC environment. On Wednesday, 20 May 2015 at 03:44:58 UTC, bitwise wrote: Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope. If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time.
Re: Template type deduction and specialization
On 5/20/2015 4:36 PM, Namespace wrote:
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
Thanks, but I'm not looking for alternatives. I'm trying to figure out
why it doesn't work as expected.
DMD Symbol Reference Analysis Pass
Does DMD currently do any analysis of references to a symbol in a given scope? If not where could this information be extracted (in which visitor/callback) and in what structure should it, if so, be stored? Reason: After having read about Rust's data-flow (and in turn escape) analysis I'm very curious about how difficult it would be to add more clever type inference, of for example symbol mutability, based on this analysis. I'm asking again because of the work recently done in DIP-25, that may be related to this problem.
Re: Template type deduction and specialization
On Wednesday, May 20, 2015 06:31:11 Mike Parker via Digitalmars-d-learn wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
Well, if
printVal!(int*)(px);
prints 100, then that's a bug. It should print the address. In fact, it
should be _impossible_ for the second overload of printVal to ever be
instantiated. Think about it. What does T : T* mean? It means that T is
implicitly convertible to T*. And when is a type ever implicitly convertible
to a pointer to itself?
int x = 100;
int y = x;
isn't going to compile, so neither should that second overload ever end up
being used. Use std.traits.isPointer if you want to test for whether a type
is a pointer or not.
I'm using a fairly recent version of dmd master, and it prints out the
address for px in both cases when I compile your code. So, if it's printing
out 100 for you on the second call, it would appear to be a bug that has
been fixed at some point since 2.067 (or whatever version you're using) was
released.
- Jonathan M Davis
Re: DMD Symbol Reference Analysis Pass
On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote: Two cases come to my mind: A: Non-Templated Function: must be @safe (or perhaps @trusted) pure and parameter must qualified as const (or in). B: Templated Function: Usage of parameter in body must be non-mutating; meaning no lhs of assignment op (=, +=, ...), and calls to functions that take parameter as argument must be transitively fulfill A and B.
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 07:27:53 UTC, jklp wrote:
---
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T: T)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
---
here it's selected correctly without explicit instantiation.
But honestly i don't know why since the asterisk is removed
from the T it looks quite incorrect.
No it is correct it is same as:
void printVal(T: int)(T* t) {
writeln(*t);
}
[Issue 14607] dmd crashes intermittently when building in 32 bit mode
https://issues.dlang.org/show_bug.cgi?id=14607 --- Comment #3 from Sobirari Muhomori dfj1es...@sneakemail.com --- https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/affix_allocator.d - maybe this? --
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 20 May 2015 at 00:20:46 UTC, Elie Morisse wrote: On Monday, 18 May 2015 at 12:27:35 UTC, Kagamin wrote: BTW how does it rely on having everything on the D side? Maybe it's enough to have just instance size and method symbols? I'm not sure what you mean. I mean a workaround for current D frontend ability to work with value types: you can represent it as a struct with members of from C++ side and when they are used on the D side you call into C++ side to figure out what code to generate: D side needs not to know they are inherited. If you plan to make all C++ types proper value types, that's the right way to go, I believe.
Re: Request for Features/Ideas: A std.archive package
On Tuesday, 19 May 2015 at 19:28:03 UTC, Liam McSherry wrote: On Tuesday, 19 May 2015 at 18:46:34 UTC, Jacob Carlborg wrote: Support for RAR archives would be nice. It would be nice, but there isn't a great deal of documentation (publicly, at least). The RAR developers provide code for extracting it, but the licence forbids reverse engineering. http://www.rarlab.com/rar/unrarsrc-5.2.7.tar.gz why do you need reverse engineering?
Re: Template type deduction and specialization
On Wednesday, May 20, 2015 07:36:21 Namespace via Digitalmars-d-learn wrote:
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
That mostly works, but you it runs the classic risk of running into problems
with alias this (which is why checking for implicit conversions in static if
or template constraints is so incredibly dangerous if you're not _very_
careful). std.traits defines isPointer as follows:
enum bool isPointer(T) = is(T == U*, U) !isAggregateType!T;
which avoids the alias this problem. Regardless, it's more idiomatic to just
use isPointer.
- Jonathan M Davis
Re: 0 is not a power of 2
First version isn't any slow. It's clear and can be optimized with gdc: http://goo.gl/Q7HKcU And if you matter about dmd - it generates shit all the time.
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 09:35:48 UTC, Jonathan M Davis wrote:
Well, if
printVal!(int*)(px);
prints 100, then that's a bug. It should print the address. In
fact, it
should be _impossible_ for the second overload of printVal to
ever be
instantiated
IMHO thats not true, it should print 100. This is what spec say.
void printVal(T : T*)(T* t) {
writeln(*t);
}
T is deduce to be int so we have
void printVal(int* t) {
writeln(*t);
}
which will print value not address
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/0b41a6205361382930272813a5f6a2baae0c456a cleanup and rewrite rt.critical_ - reuse mutex declarations from rt.monitor_ - fix race condition (incorrect double checked locking) - modernize code for readability - use shared(D_CRITICAL_SECTION)* when dealing with unsynchronized data - replace STI/STD style C constructors - fix Issue 6607 - hopefully fix Issue 14584 - spurious autotester deadlocks --
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 09:35:43 UTC, Daniel Kozak wrote:
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be
implicitly deduced may not have specializations:
OK, having reread this, I'm not clear at all what's going on.
Here, I'm instantiating the templates such that the types are
implicitly deduced from the function arguments and they pick up
the specializations just fine.
```
T sum(T : ulong)(T lhs, T rhs) {
writeln(Integrals);
return cast(T)(lhs + rhs);
}
T sum(T : real)(T lhs, T rhs) {
writeln(Floating Point);
import std.math : round;
return round(lhs + rhs);
}
void main() {
writeln(sum(10L, 20L));
writeln(sum(10.11, 3.22));
}
```
If the documentation is correct, then this shouldn't work, but it
does. It breaks only when specializing on pointers and arrays, in
which case I have to implicitly instantiate.
[Issue 14611] New: socket.localAddress fails on Unix Sockets with longer Path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611
Issue ID: 14611
Summary: socket.localAddress fails on Unix Sockets with longer
Path ( 13 characters)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: dragosc...@gmail.com
import std.file;
import std.stdio;
import std.socket;
void main()
{
string unixSocketNameOk = 1234567890123;
auto sOk = new Socket(AddressFamily.UNIX, SocketType.STREAM);
sOk.bind(new UnixAddress(unixSocketNameOk));
scope (exit) remove(unixSocketNameOk);
writeln(sOk.localAddress);
string unixSocketNameFail = 12345678901234;
auto sFail = new Socket(AddressFamily.UNIX, SocketType.STREAM);
sFail.bind(new UnixAddress(unixSocketNameFail));
scope (exit) remove(unixSocketNameFail);
writeln(sFail.localAddress);
}
Output:
localhost:1234567890123
std.socket.SocketParameterException@std/socket.d(2894): Not enough socket
address storage
--
Re: Request for Features/Ideas: A std.archive package
On Wednesday, 20 May 2015 at 08:26:11 UTC, Kagamin wrote: http://www.rarlab.com/rar/unrarsrc-5.2.7.tar.gz why do you need reverse engineering? UnRAR only extracts RAR archives, there's no facility to create them. If you wanted to create them, you would need to do some form of reverse engineering. UnRAR's licence is also fairly widely considered to be bad. *** ** UnRAR - free utility for RAR archives ** ** ** ** ** ** ~ ** *** **License for use and distribution of ** ** ** ** ** ** ~~~ ** ** ** ** ** ** FREE portable version ~ The source code of UnRAR utility is freeware. This means: 1. All copyrights to RAR and the utility UnRAR are exclusively owned by the author - Alexander Roshal. 2. The UnRAR sources may be used in any software to handle RAR archives without limitations free of charge, but cannot be used to re-create the RAR compression algorithm, which is proprietary. Distribution of modified UnRAR sources in separate form or as a part of other software is permitted, provided that it is clearly stated in the documentation and source comments that the code may not be used to develop a RAR (WinRAR) compatible archiver. 3. The UnRAR utility may be freely distributed. It is allowed to distribute UnRAR inside of other software packages. 4. THE RAR ARCHIVER AND THE UnRAR UTILITY ARE DISTRIBUTED AS IS. NO WARRANTY OF ANY KIND IS EXPRESSED OR IMPLIED. YOU USE AT YOUR OWN RISK. THE AUTHOR WILL NOT BE LIABLE FOR DATA LOSS, DAMAGES, LOSS OF PROFITS OR ANY OTHER KIND OF LOSS WHILE USING OR MISUSING THIS SOFTWARE. 5. Installing and using the UnRAR utility signifies acceptance of these terms and conditions of the license. 6. If you don't agree with terms of the license you must remove UnRAR files from your storage devices and cease to use the utility. Thank you for your interest in RAR and UnRAR. Alexander L. Roshal If UnRAR-derived code was in Phobos, everyone that used Phobos would be required to accept the above licence, or remove the RAR archiving module from their system.
[Issue 6607] critical_.d and critical.c use double check locking the wrong way
https://issues.dlang.org/show_bug.cgi?id=6607 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 --- Comment #9 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/d50aba0083b03659f60c3f157a674d9846d8228f fix Issue 14573 - classes without destructor leak monitor/mutex - set finalize bit when constructing the monitor --
LDC assembly online
Hi all ! I've created a site with assembly of ldc. It uses now latest ldc 2.067 with latest llvm 3.7. I think i'll add gdc and dmd compilers in future. Go ahead and play with it ! http://goo.gl/0Cvfqq
[Issue 14611] socket.localAddress fails on Unix sockets with longer path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611 Dragos Carp dragosc...@gmail.com changed: What|Removed |Added Summary|socket.localAddress fails |socket.localAddress fails |on Unix Sockets with longer |on Unix sockets with longer |Path ( 13 characters) |path ( 13 characters) --
Re: GC Destruction Order
On Wednesday, 20 May 2015 at 08:01:46 UTC, Kagamin wrote: On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote: Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking. And what you're asking. Just for the record: C++ memory management techniques are not designed to work in GC environment. Yes, but D claims to support manual memory management. It seems to get second class treatment though. I'm pretty sure I can PInvoke malloc in C# too ;) On Wednesday, 20 May 2015 at 03:44:58 UTC, bitwise wrote: Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope. If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time. AFAIK D does not provide any built in functionality like Objective-C's 'runOnMainThread', which makes this a painful option.
[Issue 14611] socket.localAddress fails on Unix Sockets with longer Path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611 Dragos Carp dragosc...@gmail.com changed: What|Removed |Added Severity|enhancement |normal --
Re: Request for Features/Ideas: A std.archive package
On Tue, 19 May 2015 20:46:33 +0200, Jacob Carlborg wrote: Support for RAR archives would be nice. considering unrar's license... why, 7zip is better in all ways, and it's opensource. i will really like to see a module to work with 7z archives in Phobos. rar archives will die, almost like ace archives are effectively dead now (and ACE was pretty good for it's time!). signature.asc Description: PGP signature
Re: Template type deduction and specialization
DOC say `may not have` not `must not have` ;-)
On Wed, 20 May 2015 13:24:22 +
Mike Parker via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Wednesday, 20 May 2015 at 09:35:43 UTC, Daniel Kozak wrote:
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be
implicitly deduced may not have specializations:
OK, having reread this, I'm not clear at all what's going on.
Here, I'm instantiating the templates such that the types are
implicitly deduced from the function arguments and they pick up
the specializations just fine.
```
T sum(T : ulong)(T lhs, T rhs) {
writeln(Integrals);
return cast(T)(lhs + rhs);
}
T sum(T : real)(T lhs, T rhs) {
writeln(Floating Point);
import std.math : round;
return round(lhs + rhs);
}
void main() {
writeln(sum(10L, 20L));
writeln(sum(10.11, 3.22));
}
```
If the documentation is correct, then this shouldn't work, but it
does. It breaks only when specializing on pointers and arrays, in
which case I have to implicitly instantiate.
[Issue 14612] New: typeid(interface) returns TypeInfo_Class object
https://issues.dlang.org/show_bug.cgi?id=14612
Issue ID: 14612
Summary: typeid(interface) returns TypeInfo_Class object
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
In the following test code, typeid(i) does not return typeid(J) typed
TypeInfo_Interface, rather it returns typeid(J).info that is TypeInfo_Class.
import std.stdio;
interface I {}
interface J : I {}
class C : J {}
class D : C {}
void main()
{
D d = new D();
Object o = cast(Object)d;
I i = cast(I)d;
writeln(typeid(d) is typeid(D));// true
writeln(typeid(o) is typeid(D));// true
writeln(typeid(i) is typeid(I));// false ?
writeln(typeid(i) is typeid(J));// false ?
writeln(typeid(i) is typeid(D));// false ?
writeln(typeid(i)); // prints 'test.J' !?
// old exp.classinfo property is same with typeid(exp)
writeln(d.classinfo is typeid(D)); // true
writeln(o.classinfo is typeid(D)); // true
writeln(i.classinfo is typeid(J)); // false, same with typeid()
writeln(i.classinfo is typeid(I)); // false, same with typeid()
writeln(i.classinfo is typeid(D)); // false, same with typeid()
writeln( typeid(i) is typeid(J).info); // true
writeln(i.classinfo is typeid(J).info); // true
}
This nonintuitive behavior comes historically from D1.
In D1, ClassInfo, TypeInfo_Class, and TypeInfo_Interface are different classes.
In there, ClassInfo
had had the information of class *and* interface definition in runtime, and two
TypeInfo-s were purely
identity objects that associated with the class/interface types.
In D2, ClassInfo and TypeInfo_Class were merged into one (by issue 3380 ?).
Now ClassInfo is an alias name of TypeInfo_Class.
But, the separation between ClassInfo and TypeInfo_Interface is still there.
And currently, typeid(i) is completely same with i.classinfo, therefore it
still returns ClassInfo == TypeInfo_Class.
-
I think there's two ways to fix the behavior.
1. To make TypeInfo_Interface accessible from runtime interface references. To
do that,
change object.Interface struct as follows:
struct Interface
{
version(none) // old
{
TypeInfo_Class classinfo;
}
else // new
{
TypeInfo_Interface tinfo;
@property TypeInfo_Class classinfo() { return tinfo.info; }
}
void*[] vtbl;
size_t offset;
}
and then the interface vtb[0] will be the runtime TypeInfo_Interface that we
needing.
Pros: We need very little compiler and druntime changes.
Cons: It would add a small runtime cost in the dynamic cast.
See: druntime/src/rt/cast_.d
2. Separate ClassInfo from TypeInfo_Class again and define TypeInfo hierarchy
as follows:
abstract class ClassInfo : TypeInfo { ... }
class TypeInfo_Class : ClassInfo { ... }
class TypeInfo_Interface : ClassInfo { ... }
Pros: By handling ClassInfo, the runtime cost in dynamic cast operation can be
kept same with today's.
Cons: If an user still using the name 'ClassInfo', the code behavior will be
changed.
--
Assertion failure without line
core.exception.AssertError@stackext.d(0): Assertion failure how to handle this? -manfred
Re: 0 is not a power of 2
On 5/19/15 1:46 PM, Matthias Bentrup wrote:
I think you can make the over/underflow at zero work in your favor:
bool isPowerOf2(uint x)
{
return (x -x) (x - 1);
}
Nice code with dmd and gdc. Thanks!
https://github.com/andralex/phobos/commit/ec197ecd203b0ea25201acfeb4fbbb13b2fabb7f
-- Andrei
Re: Dconf Video / Projector Information
Bummer. I was looking forward to the streams.
Re: Assertion failure without line
My first gut idea is to check the file for an assert inside a mixed in string.
std.allocator: FreeList uses simple statistics to control number of items
https://github.com/andralex/phobos/commit/90120fc290bc7840ffbee22766798518b3418e15 There is a bothersome issue with freelists fronting general-purpose allocators (https://en.wikipedia.org/wiki/Free_list): they can grow indefinitely. Because they keep memory allocated in their parent, they cause fragmentation to it. The worst pattern for a freelist is: an application allocates a bunch of blocks of the specific size the freelist is tuned for, then frees most of them and proceeds with allocating other sizes. In that case the large freelist is essentially leaked. My past FreeList implementation had a maximum list length as a parameter. That was quite a primitive way to go about it. But what I want is a way to model the application's behavior and automatically adapt to the allocation patterns. In particular, if demand for blocks of the freelist size dwindles, it should be possible for the freelist length to progressively go down to zero. So there are three possible allocation events: 1. The request is for a fit size and the free list is empty. That's a miss. It will be served from the parent allocator, and upon freeing the block will be added to the free list. 2. The request is for a fit size and the free list is not empty. That's a hit - nice. Serve it from the free list. 3. The request is for an unfit size. That's always served from the parent allocator, and returned to it upon deallocation. What we want is to minimize the likelihood of a miss. Say over the past N allocation requests we have N1, N2, and N3 counts for the three events. Then we can estimate the probability of a miss from these past events: Pmiss = N1 / N Trouble is, all counts keep increasing and there is little adaptation to changing patterns - the stats are averaged over the entire lifetime. It's better to keep stats over a fixed-size rolling window, say the past Nw events. In that case, if a new miss event occurs, we update the estimated miss probability as such: Pmiss = (Pmiss * Nw + 1) / (Nw + 1) That is, in the recent past we've seen Pmiss * Nw misses, now we see one more (+ 1), and we divide everything by the increased number of events. In case of a non-miss (hit or unfit), the update is: Pmiss = Pmiss * Nw / (Nw + 1) Note how the first equation converges to Pmiss = 1 and the second to Pmiss = 0. Nice. In a batch of events Nbatch of which there were Nmiss misses, the update is: Pmiss = (Pmiss * Nw + Nmiss) / (Nw + Nbatch) So after each allocation event, or after a few of them, we have a nice estimate of the probability we're missing the opportunity of allocating off the freelist. What I'm less sure about is how to efficiently wire that information into a feedback loop. Specifically: 1. How to update Pmiss efficiently? Most allocations should be fast, so it shouldn't be update with every call to allocate(). What I have now is I update every K calls. 2. How and when should the estimated Pmiss be used to reduce the size of the freelist? What I do now is when Pmiss is below a fixed threshold, I just periodically yank one element off of it. Better ideas are welcome! Andrei
Re: Request for Features/Ideas: A std.archive package
On Wednesday, 20 May 2015 at 14:43:17 UTC, Kagamin wrote: UnRAR only extracts RAR archives That's what all 3rd party archivers do. Only rarlab software can create rar archives. Which is one reason for not including RAR support, even if it would be nice. I just checked the RAR 5.0 technote, and it only appears to cover the file format. No algorithms are described. So, there doesn't seem to be a way to support RAR without using UnRAR, and using UnRAR doesn't seem too likely due to its licence.
Re: LDC assembly online
On 5/20/15 6:29 AM, Temtaime wrote: Hi all ! I've created a site with assembly of ldc. It uses now latest ldc 2.067 with latest llvm 3.7. I think i'll add gdc and dmd compilers in future. Go ahead and play with it ! http://goo.gl/0Cvfqq Nice! Want to work with Iain and Vladimir to add ldc to asm.dlang.org? -- Andrei
[Issue 14609] [REG2.068a] Github HEAD: DMD assertion failure for valid code
https://issues.dlang.org/show_bug.cgi?id=14609 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6e0a27b19219d1c2cd02fb3319d3e3a9bfabfcd7 fix Issue 14609 - Github HEAD: DMD assertion failure for valid code https://github.com/D-Programming-Language/dmd/commit/ba848af87cbba093ba9947e27090b9ef220f0334 Merge pull request #4672 from 9rnsr/fix14609 [REG2.068a] Issue 14609 - Github HEAD: DMD assertion failure for valid code --
Re: shared libs for OSX
On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote: On 2015-05-20 16:44, bitwise wrote: I tried using a shared library for OSX yesterday. I opened it with dlopen, retrieved my extern(C) function, and called it. All was well, and it seemed to work(wrote to the console with writeln). But, I got a message in the console saying shared libraries were not yet implemented for OSX. What exactly is it that's not working? TLS, module constructors, module/class info, perhaps the GC, similar things. Heh.. That's pretty useless. Any idea on the state of things? Like if there are plans to support this in the near future(few months)? I couldn't find many conversations on this. This kinda-totally ruins my plans(on OSX at least).
[Issue 11738] partialShuffle actually shuffles the entire input
https://issues.dlang.org/show_bug.cgi?id=11738 --- Comment #4 from Ivan Kazmenko ga...@mail.ru --- (In reply to Joseph Rushton Wakeling from comment #3) (In reply to Ivan Kazmenko from comment #2) Disclaimer: I may have misunderstood the issue, in which case, please explain what is the intent here. At first glance, I reckon it's my screw-up misinterpreting the documentation. Sorry about that. :-( I'm not sure how much time I have in the near future, but I don't object to the original patch being reverted. I can submit a PR for that ~tomorrow if you want, seems trivial: change one line of actual code and a few unittests. --
Re: Request for Features/Ideas: A std.archive package
On Wed, 20 May 2015 20:57:32 +0200, Jacob Carlborg wrote: On 2015-05-20 15:46, ketmar wrote: considering unrar's license... why, 7zip is better in all ways, and it's opensource. Doesn't matter, it's still used. BTW, I'm only interested in extracting. `spawnProcess(unrar, x, uselessarchive.rar);` signature.asc Description: PGP signature
Re: LuaD + VisualD link issue
On Tuesday, 12 August 2014 at 22:25:24 UTC, Johnathan Sunders wrote: I'm having an issue with building programs that link with LuaD using VisualD. If I use Dub, it builds without an issue, but generating a project file and compiling it through VisualD results in Error 162: Bad Type Index reference to type 84A9 when linking luad.lib(base). Anyone has any ideas on what may cause this? I've also tried building using the VisualD project on LuaD's GitHub in case it was a missing configuration setting but that has the same issue (running Windows 8 64 bit in case it's relevant). I wondered if you ever found a solution to this issue? I am having exactly the same problem. Basically I did this 1. Generated a simple app with dub and added luad as a dependency. 2. Compiling the app with dub works fine. Can call Lua ok. 3. Asking dub to generate a VisualD project file and then trying to compile the same app in VisualD fails, in my case the error is Error 162: Bad Type Index reference to type 5C55. I have tried copying the VisualD project from the dub's Luad folder into my own solution and compiling it manually, but I run into the same problem. As an aside, I should add that this is an attempt to workaround my original problem - I want to use a dub package (LuaD) in an existing VisualD project that I created using VisualD - not sure if that is possible? Wild guess: There is an enigmatic README.md in the LuaD distribution https://github.com/JakobOvrum/LuaD/blob/master/extlib/README.md which might contain a clue as to the problem. I am running Windows 8 64 bit, the VisualD project is Win32 configuration. Changing the configuration to Win64 yields error ..\luad-master\extlib\lua5.1.lib : fatal error LNK1136: invalid or corrupt file
Re: Request for Features/Ideas: A std.archive package
On Wednesday, 20 May 2015 at 18:57:32 UTC, Jacob Carlborg wrote: On 2015-05-20 15:46, ketmar wrote: considering unrar's license... why, 7zip is better in all ways, and it's opensource. Doesn't matter, it's still used. BTW, I'm only interested in extracting. who still uses rar?
Re: partialShuffle only shuffles subset.
On Tuesday, 19 May 2015 at 14:31:21 UTC, Ivan Kazmenko wrote: On Tuesday, 19 May 2015 at 10:00:33 UTC, BlackEdder wrote: The documentation seems to indicate that partialShuffle: Partially shuffles the elements of r such that upon returning r[0..n] is a random subset of r, (which is what I want), but it seems that partialShuffle actually only shuffles the first subset of the range (which you could do probably also do by [0..n].randomShuffle). This different behaviour was problem created since: https://issues.dlang.org/show_bug.cgi?id=11738. Does anyone know what the intended behaviour is/was? Reading the current documentation and unittests, I now also believe the fix was a mistake. Reopened the issue for now with a comment: https://issues.dlang.org/show_bug.cgi?id=11738#c2 I hope Joseph Rushton Wakeling looks into it soon. Reading the documentation it does appear that the function behaviour is at odds with what is described. I don't know how I came to that misunderstanding. In the short term, if you want a randomly-shuffled random subset of a range, you could get it via something like, original_range.randomSample(n).array.randomShuffle; or maybe better original_range.randomShuffle.randomSample(n);
Re: [dlang website] Up Arrow in library
And what do you use on touch screen devices? The up arrow (on duckduckgo for example) is very convenient. It's one of those little things that are not _strictly_ necessary but often come in handy. I agree that a back to top link under every function would be kinda stupid. But a little arrow that resides unobtrusively in the corner of the browser window does no harm. Any touch screen browser has this feature (On iOS tap on status bar, on Android diagonal swipe or on Windows use the dedicated Home button). On desktop browsers there are various plugins to do that or you can add a favorite/bookmark/star button pointing to javascript:scroll(0,0).
Re: Dconf Video / Projector Information
On Wednesday, 20 May 2015 at 16:45:44 UTC, Bastiaan Veelo wrote: Bummer. I was looking forward to the streams. Maybe somebody in the first rows can live-stream the keynotes, at least. A low-quality video or even just audio would suffice. Last year a couple of colleagues watched the whole conference in the office from 6PM to 1AM and we would like to repeat that if possible. Dragos
[Issue 11738] partialShuffle actually shuffles the entire input
https://issues.dlang.org/show_bug.cgi?id=11738 --- Comment #3 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net --- (In reply to Ivan Kazmenko from comment #2) Disclaimer: I may have misunderstood the issue, in which case, please explain what is the intent here. At first glance, I reckon it's my screw-up misinterpreting the documentation. Sorry about that. :-( I'm not sure how much time I have in the near future, but I don't object to the original patch being reverted. --
Re: Request for Features/Ideas: A std.archive package
On Wednesday, 20 May 2015 at 18:55:11 UTC, Jacob Carlborg wrote: libarchive supports it, which has a BSD license. Yeah, I know that we most likely cannot use it. If RAR support is to be had, interfacing with libarchive is probably going to be the best/easiest way to do it, although it would probably be better to focus on adding support for those archives that don't need an extra library first.
Re: Request for Features/Ideas: A std.archive package
On 2015-05-20 14:19, Liam McSherry wrote: On Wednesday, 20 May 2015 at 08:26:11 UTC, Kagamin wrote: http://www.rarlab.com/rar/unrarsrc-5.2.7.tar.gz why do you need reverse engineering? UnRAR only extracts RAR archives, there's no facility to create them. If you wanted to create them, you would need to do some form of reverse engineering. UnRAR's licence is also fairly widely considered to be bad. I'm only interested in extracting RAR archives. There are many tools that can extract a lot of different archives but only create a couple of them. -- /Jacob Carlborg
DConf parking info and code
Attendees may park in the multi-level parking structure in the middle of campus. Code is 228636. -- Andrei
Re: shared libs for OSX
On 2015-05-20 16:44, bitwise wrote: I tried using a shared library for OSX yesterday. I opened it with dlopen, retrieved my extern(C) function, and called it. All was well, and it seemed to work(wrote to the console with writeln). But, I got a message in the console saying shared libraries were not yet implemented for OSX. What exactly is it that's not working? TLS, module constructors, module/class info, perhaps the GC, similar things. -- /Jacob Carlborg
Re: LDC assembly online
I only edited few config files - i think they can do it by themselves.
Re: Assertion failure without line
Adam D. Ruppe wrote:
assert inside a mixed in string.
None praesent:
private import star, stack;
class StackExtended( T): Stack!T{
Star!T stacked;
this(){ stacked= new Star!T;}
auto opOpAssign( string op, T)( T node){
stacked+= node;
return super+= node;
}
auto opUnary( string op)(){
stacked -= super.max;
return super--;
}
bool opBinaryRight( string op, Tquote)( Tquote elem)
if( is( Tquote:T) ( in==op ))
{
return elem in stacked;
}
}
-manfred
QDBM depot.c translated to D
here i'm presenting[1][2] a simple, but usable and reasonably[3] fast key-value storage in the spirit of GDBM. it is based on Depot[4] layer of QDBM[5] package. it should be compatible with QDBM databases. Depot consists of a single class, and allows you to put, get and del[ete] records. it also supports simple iteration. it keeps it's database in a single disk file. file size is limited to 2GB. Depot doesn't support concurrent access or multiple iterators. Depot is not ACID database, and it doesn't support transactions. Depot is GNU LGPL. refer to QDBM documentation to learn more about it's Depot layer. WARNING! Depot is not heavily tested, and it's API may change in the future. think of it as a proof-of-concept code. althru QDBM is stable, there is no guarantees that i didn't introduced new bugs while porting. [1] http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/depot.d [2] http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/depot_test/dtest01.d [3] reasonably means it doesn't suck... much [4] http://fallabs.com/qdbm/spex.html#depotapi [5] http://fallabs.com/qdbm/index.html signature.asc Description: PGP signature
Re: Dconf Video / Projector Information
Also, when are the videos going to be released this time? I'd like it on youtube as soon as possible.
Re: Request for Features/Ideas: A std.archive package
On 5/20/2015 11:56 AM, Jacob Carlborg wrote: interested in extracting RAR archives. There are many tools that can extract a lot of different archives but only create a couple of them. That's fine, as long as the licensing issue can be worked out, i.e. we can do a Boost implementation. Otherwise, Phobos won't support it, although RAR tools can be provided separately.
[Issue 11738] partialShuffle actually shuffles the entire input
https://issues.dlang.org/show_bug.cgi?id=11738 --- Comment #5 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net --- (In reply to Ivan Kazmenko from comment #4) I can submit a PR for that ~tomorrow if you want, seems trivial: change one line of actual code and a few unittests. Sounds great, thank you :-) --
Re: shared libs for OSX
On Wed, 20 May 2015 17:35:37 -0400, bitwise bitwise@gmail.com wrote: On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote: On 2015-05-20 16:44, bitwise wrote: I tried using a shared library for OSX yesterday. I opened it with dlopen, retrieved my extern(C) function, and called it. All was well, and it seemed to work(wrote to the console with writeln). But, I got a message in the console saying shared libraries were not yet implemented for OSX. What exactly is it that's not working? TLS, module constructors, module/class info, perhaps the GC, similar things. Heh.. That's pretty useless. Any idea on the state of things? Like if there are plans to support this in the near future(few months)? I couldn't find many conversations on this. This kinda-totally ruins my plans(on OSX at least). I've been reading over all the bugs and conversations I can find, but I'm still confused about exactly what's going on here. What I need: -load a dynamic library on OSX using dlopen or Runtime.loadLibrary -use dlsym to retrieve my functions and set up a gc proxy -pull interfaces of classes defined in the dynamic library into my program for use. Not sure how much of this is working properly or not. I'd be willing to throw a couple of bucks at this for a bounty, but I'm not sure how much it's worth though. Any takers for $25? ;) Bit
Re: Request for Features/Ideas: A std.archive package
On 5/20/2015 12:40 PM, Liam McSherry wrote: On Wednesday, 20 May 2015 at 18:55:11 UTC, Jacob Carlborg wrote: libarchive supports it, which has a BSD license. Yeah, I know that we most likely cannot use it. If RAR support is to be had, interfacing with libarchive is probably going to be the best/easiest way to do it, although it would probably be better to focus on adding support for those archives that don't need an extra library first. Clearly, we need a Deimos entry for libarchive. https://github.com/d-programming-deimos
[Issue 7044] Missing a way to control the order of arguments passed to the linker makes impossible to link some programs
https://issues.dlang.org/show_bug.cgi?id=7044 --- Comment #39 from Walter Bright bugzi...@digitalmars.com --- Here's my evil plan: Add a switch -confsection=sectionname which will cause [sectionname] in the config file to be parsed. There can be multiple such switches and sections, they'll be parsed in lexical order. Note that: DFLAGS += string can be handled without adding new features with: DFLAGS = %DFLAGS% string The current way the config file is read twice wreaks havoc with the order in which sections are processed and things like appending to existing environment variables. This all has to be redone, but I'd like a green light on it being an acceptable resolution of this bugzilla issue before investing the effort. (Currently order of evaluation is undocumented.) I decided not to have -version=identifier do this, because inevitably someone will have a problem with it and want another switch to be able to do them independently. Calling it -confsection will place it next to the -conf switch in the documentation, making the connection easily discoverable. --
Re: Template type deduction and specialization
On 05/20/2015 04:10 PM, Mike Parker wrote: On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote: DOC say `may not have` not `must not have` ;-) OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what might be possible. That's the only meaning that I get: The doc means must not. Yet, as you've shown, the behavior does not match the doc. Ali
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote: DOC say `may not have` not `must not have` ;-) OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what might be possible. As in: Employees may not bring unauthorized individuals into the work space. It's very rare to use must not when denying permission.
Re: dmd on centos 6.6
On Thursday, 21 May 2015 at 02:23:55 UTC, Andrei Alexandrescu wrote: Hi folks, I just cloned the latest dmd from github on a Centos 6.6 machine. It has a dmd 2.065 installed. Cloning and building dmd succeeded, then so did druntime. Then after I cloned Phobos I got: std/math.d(2759): Error: number '0x1p-1024' is not representable std/math.d(2762): Error: number '0x1p-1024' is not representable std/math.d(2765): Error: number '0x1p-1024' is not representable std/math.d(2770): Error: number '0x1p-128f' is not representable std/math.d(2773): Error: number '0x1p-128f' is not representable std/math.d(2776): Error: number '0x1p-128f' is not representable Does anyone know what could be happening? Thanks, Andrei http://forum.dlang.org/thread/fbkyfjfofwaoitaxd...@forum.dlang.org
Re: std.allocator: FreeList uses simple statistics to control number of items
What you could do is calculate the average allocation size and std deviantions in a moving window, and the z-score for each freelist and use this lookup table: https://www.stat.tamu.edu/~lzhou/stat302/standardnormaltable.pdf If P 0.10 (maybe use this as a setting) this means the probability of the next allocations going through this freelist is too low and you can decide to tighten the freelist and let the deallocations fall through to the underlying allocator.
Re: Assertion failure without line
Adam D. Ruppe wrote: My first gut idea Turns out: it is the usage of a variable - not newed, and - of a type declared in the file. -manfred
Re: Template type deduction and specialization
On Wednesday, May 20, 2015 19:20:19 Mike Parker via Digitalmars-d-learn wrote: On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote: I'm using a fairly recent version of dmd master, and it prints out the address for px in both cases when I compile your code. So, if it's printing out 100 for you on the second call, it would appear to be a bug that has been fixed at some point since 2.067 (or whatever version you're using) was released. - Jonathan M Davis I'm using 2.067.0, but according to the section of the docs Daniel pointer me to[1], printing 100 is the correct behavior in the second call. [1] http://dlang.org/template.html#function-templates Hmmm. It looks like when : is used directly in the template parameter list, it doesn't mean the same thing as when it's used in an is expression. I _never_ use : directly in the template parameter list, so I misunderstood what it did. And looking over what it says, your printVal(T : T*) should be used when explicitly calling printVal!(int*) but that printVal(px) will print the address, because for whatever reason, IFTI doesn't work with the : syntax directly in the template parameter list (I have no idea why, but that section in the spec is pretty clear about that). So, the fact that it's printing the address for me in both cases is bug. But if you're seeing it print 100 for printVal!(int*)(px) and the address for printVal(px), then that would be correct per the spec. Personally, I wish that template specializations like this just didn't exist in the language, because they're redundant with template constraints and just add more complication to the language, but it's not like we're going to get rid of them at this point, unfortunately. But because I think that they're pointless, I never use them, and clearly am not familiar enough with how they work. - Jonathan M Davis
dmd on centos 6.6
Hi folks, I just cloned the latest dmd from github on a Centos 6.6 machine. It has a dmd 2.065 installed. Cloning and building dmd succeeded, then so did druntime. Then after I cloned Phobos I got: std/math.d(2759): Error: number '0x1p-1024' is not representable std/math.d(2762): Error: number '0x1p-1024' is not representable std/math.d(2765): Error: number '0x1p-1024' is not representable std/math.d(2770): Error: number '0x1p-128f' is not representable std/math.d(2773): Error: number '0x1p-128f' is not representable std/math.d(2776): Error: number '0x1p-128f' is not representable Does anyone know what could be happening? Thanks, Andrei
Re: shared libs for OSX
On Wednesday, 20 May 2015 at 21:35:38 UTC, bitwise wrote: On Wednesday, 20 May 2015 at 18:53:30 UTC, Jacob Carlborg wrote: On 2015-05-20 16:44, bitwise wrote: I tried using a shared library for OSX yesterday. I opened it with dlopen, retrieved my extern(C) function, and called it. All was well, and it seemed to work(wrote to the console with writeln). But, I got a message in the console saying shared libraries were not yet implemented for OSX. What exactly is it that's not working? TLS, module constructors, module/class info, perhaps the GC, similar things. Heh.. That's pretty useless. Any idea on the state of things? Like if there are plans to support this in the near future(few months)? I couldn't find many conversations on this. This kinda-totally ruins my plans(on OSX at least). Actually, TLS works on OS X: dmd emulates it, while ldc has native TLS using undocumented OS X APIs. I'm unsure of how full-fledged the support is on those other issues, but I believe the big issue is that loading multiple shared libraries is not supported, as that will take more work: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L198 If you want to talk to someone about getting more of shared libraries working, I believe Martin is your man.
[Issue 14609] Github HEAD: DMD assertion failure for valid code
https://issues.dlang.org/show_bug.cgi?id=14609 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4672 --
[Issue 14609] [REG2.068a] Github HEAD: DMD assertion failure for valid code
https://issues.dlang.org/show_bug.cgi?id=14609 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Summary|Github HEAD: DMD assertion |[REG2.068a] Github HEAD: |failure for valid code |DMD assertion failure for ||valid code --
Re: GC Destruction Order
On Wednesday, 20 May 2015 at 13:54:29 UTC, bitwise wrote: Yes, but D claims to support manual memory management. It seems to get second class treatment though. It's WIP. There were thoughts to run finalizers on the thread where the object was allocated (I doubt it's a good idea, though). Anyway, if you're doing manual memory management, how GC popped up? If you have your manual memory managed with GC, it means you have a memory leak: manually managed memory shouldn't become garbage without being freed. I suppose it will be a long way before D rediscovers .net practices. I'm pretty sure I can PInvoke malloc in C# too ;) I use Marshal.AllocHGlobal. Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope. If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time. AFAIK D does not provide any built in functionality like Objective-C's 'runOnMainThread', which makes this a painful option. You asked for destructor being called on the thread where it went out of scope, which is not necessarily the main thread.
Re: Request for Features/Ideas: A std.archive package
On Wednesday, 20 May 2015 at 12:19:07 UTC, Liam McSherry wrote: On Wednesday, 20 May 2015 at 08:26:11 UTC, Kagamin wrote: http://www.rarlab.com/rar/unrarsrc-5.2.7.tar.gz why do you need reverse engineering? UnRAR only extracts RAR archives That's what all 3rd party archivers do. Only rarlab software can create rar archives. If UnRAR-derived code was in Phobos, everyone that used Phobos would be required to accept the above licence, or remove the RAR archiving module from their system. I guess, the code was requested to be written. How to distribute it is a different question.
shared libs for OSX
I tried using a shared library for OSX yesterday. I opened it with dlopen, retrieved my extern(C) function, and called it. All was well, and it seemed to work(wrote to the console with writeln). But, I got a message in the console saying shared libraries were not yet implemented for OSX. What exactly is it that's not working? Thanks, Bit
