Re: Reading and converting binary file 2 bits at a time
On Thursday, 27 August 2015 at 12:40:07 UTC, Mike James wrote: How about... A lot nicer. :)
Re: Reading and converting binary file 2 bits at a time
On Thursday, 27 August 2015 at 09:00:02 UTC, Andrew Brown wrote:
Hi,
I need to read a binary file, and then process it two bits at a
time. But I'm a little stuck on the first step. So far I have:
import std.file;
import std.stdio;
void main(){
auto f = std.file.read(binaryfile);
auto g = cast(bool[]) f;
writeln(g);
}
but all the values of g then are just true, could you tell me
what I'm doing wrong? I've also looked at the bitmanip module,
I couldn't get it to help, but is that the direction I should
be looking?
Thanks very much
Andrew
How about...
module main;
import std.bitmanip;
import std.stdio;
struct Crumbs {
@property ref ubyte whole() {
return m_whole;
}
union {
private ubyte m_whole;
mixin(bitfields!(
ubyte, one, 2,
ubyte, two, 2,
ubyte, three, 2,
ubyte, four, 2
));
}
}
void main(string[] argv)
{
ubyte[] buffer = [123, 12, 126, 244, 35];
Crumbs cmb;
foreach (octet; buffer) {
cmb.whole = octet;
writefln(Crumb: %08b, octet);
writefln(Crumb one: %s, cmb.one);
writefln(Crumb two: %s, cmb.two);
writefln(Crumb three: %s, cmb.three);
writefln(Crumb four: %s, cmb.four);
}
}
Regards, Mike.
Re: This Week in D summarizes those long threads for you!
On 25/08/2015 23:55, Laeeth Isharc wrote: https://www.patreon.com/esr?ty=h Ha, nice one, didn't know about that. I've signed up as Patreon - ESR is ok in my book, he's a FOSS proponent, but not a FSF zealot. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Arrays of structs
On Thursday, 27 August 2015 at 11:45:14 UTC, anonymous wrote: On Thursday 27 August 2015 13:15, BBasile wrote: https://github.com/BBasile/iz/blob/master/import/iz/types.d#L125 https://github.com/BBasile/iz/blob/master/import/iz/types.d#L150 https://github.com/BBasile/iz/blob/master/import/iz/types.d#L191 Your use of @trusted is wrong and dangerous. @trusted functions are supposed to be memory-safe, but you're marking unsafe functions with it. Things like a @trusted `free` [1] are just plain wrong. `free` isn't memory- safe. The problems with @trusted templates can be more subtle. Even if the template body itself doesn't do anything unsafe, the template arguments are being trusted, too. So if the template ever calls any code from the arguments (including constructors, destructors, postblits, ...), then it cannot be marked @trusted. [1] https://github.com/BBasile/iz/blob/master/import/iz/types.d#L112 the pointer is checked before the call. Yes it can be dangling but free goes in pair with the newPtr funct. I plan to do better when Andrei's allocators will be released: https://github.com/BBasile/phobos/blob/showcase-construct/std/experimental/allocator/showcase.d#L105 Anyway. I cheat a bit with attributes but as long as it's only for me...I know this kinds of functions are not phobos-level.
Re: vibe.d - cannot allocate memory in static TLS block
removing the import vibe.d is enough to make it work as a shared library
Re: D-Day for DMD is today!
On 23/08/2015 06:17, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Cool stuff! What's the plan going forward, for those not so much up to date with what's going on? Is the next major release of DMD gonna be D-DMD based then? Which compiler is going to be used to compile D-DMD? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Casting pointers
On 8/26/15 8:14 AM, John Burton wrote:
This would be undefined behavior in c++ due to aliasing rules on
pointers. It appears to work reliably in D when I try it, but that's
obviously no guarantee that it's correct or will continue to do so.
Is this correct code in D? And if not, what should I do instead to
cleanly and efficiently extract structured data from a sequence of bytes?
import std.stdio;
struct data
{
int a;
int b;
}
void main()
{
byte[] x = [1, 2, 3, 4, 5, 6, 7, 8];
data* ptr = cast(data*)(x);
printf(%x %x\n, ptr.a, ptr.b);
}
This should be defined behavior (but there is an issue that will
probably eventually be fixed -- you shouldn't cast an array to a
pointer, use x.ptr instead). I think strict aliasing only comes into
play when something is *changed*. For example:
byte[] x = [1, 2, 3, 4, 5, 6, 7, 8];
data* ptr = cast(data *)(x.ptr);
ptr.a = 4;
writefln(%x %x\n, x[0], x[1]);
However, if we consider the strict aliasing rule from C++ allows casting
to char * and unsigned char *, D's byte[] and ubyte[] should be
equivalent to those. So if anything, that should be defined.
-Steve
Re: Arrays of structs
On Thursday, 27 August 2015 at 12:56:26 UTC, anonymous wrote: On Thursday 27 August 2015 14:35, BBasile wrote: Anyway. I cheat a bit with attributes but as long as it's only for me...I know this kinds of functions are not phobos-level. Sure, as long as you're cautious and regard those functions as unsafe, you may be fine. You still risk accidentally writing unsafe code that's marked @safe, but that's up to you. But when you show such code in the learn group, I think it's important to point out that this usage of @trusted is wrong. If only to warn newbies about it. :handshake:
Re: Digger 2.3 verstr.h problem
On 2015-08-25 13:42:38 +, Vladimir Panteleev said: And, any idea how I can print getcwd() during compile time? I tried but it's not working by using the function directly... this is really strange. getcwd() doesn't work during compile time because it's a system call. I really don't have an idea how to track this problem down... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: order of declaration/definition
On Thursday, 27 August 2015 at 13:14:24 UTC, Daniel Kozák wrote: On Thu, 27 Aug 2015 13:01:02 + vitus via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: works ok for me V tom je ten problém :)
[Issue 14953] std.concurrency: Add function to flush message box
https://issues.dlang.org/show_bug.cgi?id=14953 --- Comment #6 from Chris wend...@tcd.ie --- You assume a scenario where the programmer has no control over the data flow and messages can come from anywhere in at random, which is not necessarily the case. If threads follow a message passing protocol there is naturally some sort of synchronization between the threads. --
Re: dmd codegen improvements
On 18/08/2015 21:28, Walter Bright wrote: On 8/18/2015 12:38 PM, deadalnix wrote: And honestly, there is no way DMD can catch up. I find your lack of faith disturbing. https://www.youtube.com/watch?v=Zzs-OvfG8tEfeature=player_detailpage#t=91 My instinct also tells me it's extremely unlikely that DMD will be able to catch. But regardless of that, let's suppose it does catch up, that you (and/or others) are eventually able to make the DMD backend as good as LLVM/GCC. At what cost (development time wise) will that come? How much big chunks of development effort will be spent on that task, that could be spent on improving other areas of D, just so that DMD could be about as good (not better, just *as good*), as LDC/GDC?... -- Bruno Medeiros https://twitter.com/brunodomedeiros
[Issue 14953] std.concurrency: Add function to flush message box
https://issues.dlang.org/show_bug.cgi?id=14953 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #5 from Dmitry Olshansky dmitry.o...@gmail.com --- Related to this is the possibility to get the size of the message box, e.g. you would only want to flush a message box, if its size is 0. I haven't found a way to get the size of the message box, unless something has escaped me. In an async world with fire and forget message passing all of the above is marred with race conditions. You might check that size == 0 the next instant the message comes in. I think the only legitimate use case would be dropUntil!(SomeMessageTypesHere) as it at least has a point of serialization - marker message in a stream of messages. --
Re: dmd codegen improvements
On 19/08/2015 09:22, Dmitry Olshansky wrote: I'm interested in ways to reduce that gap. [...] Replace the backend with GDC or LLVM? :-P Oh come on - LLVM was an inferiour backend for some time. So what? Let us no work on it 'cause GCC is faster? I can't figure out what you meant: LLVM has an inferiour backend to what? GCC or DMD? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Moving forward with work on the D language and foundation
On Monday, August 24, 2015 18:42:59 Andrei Alexandrescu via Digitalmars-d-announce wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Facebook has impacted my career and life very positively, and I am grateful to have been a part of it for this long. The time has come for me, however, to fully focus on pushing D forward. As sorry I am for leaving a good and secure career behind, I am excited many times over about the great challenges and opportunities going forward. Next step with the D Language Foundation is a formal talk with the foundation's prospective attorney tomorrow. I hope to get the foundation in motion as soon as possible, though I'm told there are numerous steps to complete. I will keep this forum posted about progress. I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Wow. Sounds financially risky on your part, but if you can afford to do this, then it'll be great for the D community at large. The more resources we can have focused on D, the better. - Jonathan M Davis
Re: D-Day for DMD is today!
On 23/08/2015 06:17, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Cool stuff! What's the plan going forward, for those not so much up to date with what's going on? Is the next major release of DMD gonna be D-DMD based then? Which compiler is going to be used to compile D-DMD? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Moving forward with work on the D language and foundation
On 24/08/2015 19:42, Andrei Alexandrescu wrote: I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Cool, I'd be up for contributing in this way. Any thoughts on how that would work though? One off Paypal donations, or a recurring system like Patreon or BountySource's Salt? (https://salt.bountysource.com/) -- Bruno Medeiros https://twitter.com/brunodomedeiros
[Issue 14958] Casting a double to ulong sometimes produces wrong results
https://issues.dlang.org/show_bug.cgi?id=14958
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #7 from ag0ae...@gmail.com ---
(In reply to Steven Schveighoffer from comment #6)
I think that's where I see there is an issue. Only when you actually assign
it to a double does it become concretely double.
With -O that doesn't cut it either.
void main()
{
import std.stdio;
double x = 1.2;
double d = x * 10.0;
writeln(cast(ulong) d);
}
`dmd test.d ./test` - 12
`dmd -O test.d ./test` - 11
--
Re: Arrays of structs
On Thursday 27 August 2015 14:35, BBasile wrote: Anyway. I cheat a bit with attributes but as long as it's only for me...I know this kinds of functions are not phobos-level. Sure, as long as you're cautious and regard those functions as unsafe, you may be fine. You still risk accidentally writing unsafe code that's marked @safe, but that's up to you. But when you show such code in the learn group, I think it's important to point out that this usage of @trusted is wrong. If only to warn newbies about it.
[Issue 14958] Casting a double to ulong sometimes produces wrong results
https://issues.dlang.org/show_bug.cgi?id=14958 --- Comment #6 from Steven Schveighoffer schvei...@yahoo.com --- I understand that fp can vary based on compiler selection of instructions, and this is one of those instances. However, the type system doesn't reflect reality here. Even this prints 11: writeln(cast(ulong)(cast(double)(x * 10.0))); The cast to double is ignored because typeof(x * 10.0) *is* already double. But it's not actually a double in generated code. I think that's where I see there is an issue. Only when you actually assign it to a double does it become concretely double. The workaround (using to!ulong) may cease to work at some point also, because inlining could remove that storage to a double. --
Re: order of declaration/definition
On Monday, 24 August 2015 at 01:01:13 UTC, John Colvin wrote:
enum A = 1;
enum B = C; //Error
static if(A)
enum C = 0;
enum D = C; //OK
Is order supposed to matter here?
Beter:
enum E = 1;
struct Foo{
enum X1 = E;
static if(1) enum E = 2;
enum X2 = E;
}
static assert(Foo.X1 != Foo.X2);
class Bar{
enum X1 = __traits(isAbstractClass, typeof(this));
static if(1) abstract void bar();
enum X2 = __traits(isAbstractClass, typeof(this));
}
static assert(Bar.X1 != Bar.X2);
mixins has same problem.
Re: vibe.d - cannot allocate memory in static TLS block
On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:
P.S. this would be better asked in
http://forum.dlang.org/group/learn or
http://forum.rejectedsoftware.com
made a thread before on the vibe forum too, see here
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/26343/
On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:
Firstly, try with up-to-date vibe.d and zmqd.
What happens if you remove some of those dependencies? If you
remove targetType dynamicLibrary? Is it just vibe.d on it's own
that is causing the problem, or is it a combination?
thx for the input, i've pulled out a smaller testing example from
my codebase using only vibe as a dependency. if i compile this
code as executable everything works as expected. Compiling it as
a dynamicLibrary fails when the library is loaded.
if this is of any help, that is the program the shared library is
loaded into
https://github.com/IceNinjaman/CoD4X17a_testing/
the used compile script:
https://github.com/IceNinjaman/CoD4X17a_testing/blob/master/build_cod4x17a_elf_nopunkbuster.sh
{
name: vibefailtest,
description: A minimal D application.,
copyright: Copyright © 2015, vagrant,
authors: [vagrant],
targetType: dynamicLibrary,
dependencies: {
vibe-d: ~0.7.25-alpha.1,
},
versions: [VibeCustomMain]
}
import std.stdio;
import vibe.d;
struct version_t
{
int major;
int minor;
}
align(1) struct pluginInfo_t{ // To be used in
OnInfoRequest
align(1):
version_t handlerVersion; // Requested plugin handler version
- mandatory field
version_t pluginVersion; // Version of your plugin - optional
char[64] fullName;// Full plugin name, short name is
the filename without extension - optional
char[128] shortDescription; // Describe in a few words what
this plugin does - optional
char[1024] longDescription; // Full description - optional
}
extern (C) void OnInfoRequest(pluginInfo_t *info)
{
info.handlerVersion = version_t(2, 302);
info.pluginVersion = version_t(0, 1);
}
extern (C) int OnInit()
{
printf( init\n);
return 0;
}
void main(){
OnInit();
}
Re: order of declaration/definition
On Thu, 27 Aug 2015 13:01:02 +
vitus via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Monday, 24 August 2015 at 01:01:13 UTC, John Colvin wrote:
enum A = 1;
enum B = C; //Error
static if(A)
enum C = 0;
enum D = C; //OK
Is order supposed to matter here?
Beter:
enum E = 1;
struct Foo{
enum X1 = E;
static if(1) enum E = 2;
enum X2 = E;
}
static assert(Foo.X1 != Foo.X2);
class Bar{
enum X1 = __traits(isAbstractClass, typeof(this));
static if(1) abstract void bar();
enum X2 = __traits(isAbstractClass, typeof(this));
}
static assert(Bar.X1 != Bar.X2);
mixins has same problem.
works ok for me
Re: order of declaration/definition
On Thu, 27 Aug 2015 13:26:11 +
vitus via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Thursday, 27 August 2015 at 13:14:24 UTC, Daniel Kozák wrote:
On Thu, 27 Aug 2015 13:01:02 +
vitus via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
works ok for me
V tom je ten problém :)
Jo mas pravdu :) po prepsani na:
enum E = 1;
struct Foo{
enum X1 = E;
enum E = 2;
enum X2 = E;
}
static assert(Foo.X1 != Foo.X2);
class Bar{
enum X1 = __traits(isAbstractClass, typeof(this));
abstract void bar();
enum X2 = __traits(isAbstractClass, typeof(this));
}
static assert(Bar.X1 != Bar.X2);
void main() {
import std.stdio;
writeln(Foo.X1, Foo.X2);
writeln(Bar.X1, Bar.X2);
}
to uz vidim ;-)
[Issue 14970] New: [D1] Add support for Template Params section in ddoc
https://issues.dlang.org/show_bug.cgi?id=14970 Issue ID: 14970 Summary: [D1] Add support for Template Params section in ddoc Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: ddoc Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com --
[Issue 13516] std.windows.charset documentation missing from dlang.org
https://issues.dlang.org/show_bug.cgi?id=13516 hst...@quickfur.ath.cx changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14972 --
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Facebook has impacted my career and life very positively, and I am grateful to have been a part of it for this long. The time has come for me, however, to fully focus on pushing D forward. As sorry I am for leaving a good and secure career behind, I am excited many times over about the great challenges and opportunities going forward. Next step with the D Language Foundation is a formal talk with the foundation's prospective attorney tomorrow. I hope to get the foundation in motion as soon as possible, though I'm told there are numerous steps to complete. I will keep this forum posted about progress. I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Thanks, Andrei That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome.
Re: What is this function call operator?
On Thursday, 27 August 2015 at 16:03:58 UTC, Gary Willoughby wrote: Sorry, I mean the three dots '...' that seems to be what the documentation is referring to. Also the `isCallable` template uses it. That just means it can take whatever arguments. The documentation is just saying it is callable with anything; the ... is a placeholder. In the template itself, (T...) is a variadic argument list, again meaning it can take anything. (The reason isCallable does it though isn't to actually take multiple arguments, it is so it can take any *kind* of argument; a bit of a hack.)
[Issue 14972] New: Documentation for std.windows.* missing
https://issues.dlang.org/show_bug.cgi?id=14972 Issue ID: 14972 Summary: Documentation for std.windows.* missing Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: major Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: hst...@quickfur.ath.cx None of the modules in std.windows have documentation generated for dlang.org. This is understandable (albeit unacceptable), because the documentation is apparently generated on a Posix machine, so even if we added those modules to the makefile it probably still won't produce any useful docs (the actual code would be version()'d out). Basically, we need a way to tell the compiler that we're generating documentation for Windows, so it should compile in Windows blocks even though it may actually be running on Posix. Related bugs: #13516 (and its duplicates). --
Re: dmd codegen improvements
On Thursday, 27 August 2015 at 14:12:01 UTC, Bruno Medeiros wrote: On 18/08/2015 21:28, Walter Bright wrote: On 8/18/2015 12:38 PM, deadalnix wrote: And honestly, there is no way DMD can catch up. I find your lack of faith disturbing. https://www.youtube.com/watch?v=Zzs-OvfG8tEfeature=player_detailpage#t=91 My instinct also tells me it's extremely unlikely that DMD will be able to catch. But regardless of that, let's suppose it does catch up, that you (and/or others) are eventually able to make the DMD backend as good as LLVM/GCC. At what cost (development time wise) will that come? How much big chunks of development effort will be spent on that task, that could be spent on improving other areas of D, just so that DMD could be about as good (not better, just *as good*), as LDC/GDC?... Honestly, while I don't see why dmd couldn't catch up to gdc and ldc if enough development time were sunk into it, I seriously question that dmd can catch up without way too much development time being sunk into it. And if ldc and gdc are ultimately the compilers that folks should be using if they want the best performance, then so be it. But if dmd can be sped up so that it's closer and there's less need to worry about the speed difference for most folks, then I think that that's a big win. Every little bit of performance improvement that we can get out of dmd is an improvement, especially when those improvements come at minimal cost, and I see no reason to not improve dmd's performance where it's not going to be a huge timesink to do so and where the appropriate precautions are taken to avoid regressions. - Jonathan M Davis
[Issue 14972] Documentation for std.windows.* missing
https://issues.dlang.org/show_bug.cgi?id=14972 hst...@quickfur.ath.cx changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=13516 --
Re: What is this function call operator?
On Thursday, 27 August 2015 at 16:12:35 UTC, Adam D. Ruppe wrote: On Thursday, 27 August 2015 at 16:03:58 UTC, Gary Willoughby wrote: Sorry, I mean the three dots '...' that seems to be what the documentation is referring to. Also the `isCallable` template uses it. That just means it can take whatever arguments. The documentation is just saying it is callable with anything; the ... is a placeholder. In the template itself, (T...) is a variadic argument list, again meaning it can take anything. (The reason isCallable does it though isn't to actually take multiple arguments, it is so it can take any *kind* of argument; a bit of a hack.) Ah right, I get it. Thanks.
Re: Moving forward with work on the D language and foundation
On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: [...] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. Andrei is past 50? Doesn't look it!
[Issue 13516] std.windows.charset documentation missing from dlang.org
https://issues.dlang.org/show_bug.cgi?id=13516 hst...@quickfur.ath.cx changed: What|Removed |Added CC||john.loughran.colvin@gmail. ||com --- Comment #3 from hst...@quickfur.ath.cx --- *** Issue 14664 has been marked as a duplicate of this issue. *** --
[Issue 14664] missing pages / broken links
https://issues.dlang.org/show_bug.cgi?id=14664 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution|--- |DUPLICATE --- Comment #4 from hst...@quickfur.ath.cx --- *** This issue has been marked as a duplicate of issue 13516 *** --
[Issue 14953] std.concurrency: Add function to flush message box
https://issues.dlang.org/show_bug.cgi?id=14953 --- Comment #7 from Sean Kelly s...@invisibleduck.org --- I think there's already a bugzilla for getting the mailbox size. It's definitely come up before, and would be a trivial change. The way the MessageBox code works is it has a thread-local queue and then a shared queue. When a match isn't found in the thread-local queue the shared queue is moved to the local queue and the match continues on the new messages. All of these operations (empty queue, get size, etc) would operate on the local queue only. Touching the shared queue in any way requires acquiring a mutex, which is generally not what you want for these operations. In essence, messages in the shared queue are messages that arrived after your operation was executed. --
[Issue 14958] Casting a double to ulong sometimes produces wrong results
https://issues.dlang.org/show_bug.cgi?id=14958 --- Comment #8 from yebblies yebbl...@gmail.com --- There is an old open bug somewhere about adding a way to force a dump of excess precision. --
Re: What is this function call operator?
On Thursday, 27 August 2015 at 15:18:24 UTC, Gary Willoughby wrote: What is this function call operator? (...) Where can i learn more about it? It is the () at the end of a thing. You can overload it in a struct by writing an opCall member.
Re: What is this function call operator?
On Thursday 27 August 2015 17:18, Gary Willoughby wrote: What is this function call operator? (...) Where can i learn more about it? http://dlang.org/operatoroverloading.html#function-call http://ddili.org/ders/d.en/operator_overloading.html#ix_operator_overloading.opCall
Re: What is this function call operator?
On Thu, 27 Aug 2015 15:18:22 + Gary Willoughby d...@nomad.so wrote: If you visit this link: http://dlang.org/phobos/std_traits.html#isCallable There is this paragraph: Detect whether T is a callable object, which can be called with the function call operator (...). What is this function call operator? (...) Where can i learn more about it? http://dlang.org/operatoroverloading.html#function-call
Re: vibe.d - cannot allocate memory in static TLS block
On Thursday, 27 August 2015 at 15:40:20 UTC, ddos wrote: On Thursday, 27 August 2015 at 15:16:25 UTC, John Colvin wrote: I think your problem is that you need to initialise the D runtime. Perhaps adding a call to http://dlang.org/phobos/core_runtime.html#.Runtime.initialize inside OnInit will solve it for you. Also, remember to terminate the runtime when the plugin is unloaded. i thought about that too, but that wasn't the case ( unless i fucked something up ). nothing from my example gets executed, the crash happens i think when the library is loaded. Ok, yes, that isn't it then. just in case i've also added runtime.initialize also to the vibe main. also if the runtime.initialize would be missing that would mean my executable example should crash, but the executable test works just fine. Unless I misunderstand what you're doing, the executable test would be initialising the runtime anyway, it's put in by the compiler when building an executable. The only other thing I can think of is: have you tried removing the main from your code, while still defining VibeCustomMain?
Re: vibe.d - cannot allocate memory in static TLS block
On Thursday, 27 August 2015 at 13:08:18 UTC, ddos wrote:
On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:
P.S. this would be better asked in
http://forum.dlang.org/group/learn or
http://forum.rejectedsoftware.com
made a thread before on the vibe forum too, see here
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/26343/
On Thursday, 27 August 2015 at 11:34:36 UTC, John Colvin wrote:
Firstly, try with up-to-date vibe.d and zmqd.
What happens if you remove some of those dependencies? If you
remove targetType dynamicLibrary? Is it just vibe.d on it's
own that is causing the problem, or is it a combination?
thx for the input, i've pulled out a smaller testing example
from my codebase using only vibe as a dependency. if i compile
this code as executable everything works as expected. Compiling
it as a dynamicLibrary fails when the library is loaded.
if this is of any help, that is the program the shared library
is loaded into
https://github.com/IceNinjaman/CoD4X17a_testing/
the used compile script:
https://github.com/IceNinjaman/CoD4X17a_testing/blob/master/build_cod4x17a_elf_nopunkbuster.sh
{
name: vibefailtest,
description: A minimal D application.,
copyright: Copyright © 2015, vagrant,
authors: [vagrant],
targetType: dynamicLibrary,
dependencies: {
vibe-d: ~0.7.25-alpha.1,
},
versions: [VibeCustomMain]
}
import std.stdio;
import vibe.d;
struct version_t
{
int major;
int minor;
}
align(1) struct pluginInfo_t{ // To be used in
OnInfoRequest
align(1):
version_t handlerVersion; // Requested plugin handler
version - mandatory field
version_t pluginVersion; // Version of your plugin -
optional
char[64] fullName;// Full plugin name, short name
is the filename without extension - optional
char[128] shortDescription; // Describe in a few words what
this plugin does - optional
char[1024] longDescription; // Full description - optional
}
extern (C) void OnInfoRequest(pluginInfo_t *info)
{
info.handlerVersion = version_t(2, 302);
info.pluginVersion = version_t(0, 1);
}
extern (C) int OnInit()
{
printf( init\n);
return 0;
}
void main(){
OnInit();
}
I think your problem is that you need to initialise the D
runtime. Perhaps adding a call to
http://dlang.org/phobos/core_runtime.html#.Runtime.initialize
inside OnInit will solve it for you. Also, remember to terminate
the runtime when the plugin is unloaded.
What is this function call operator?
If you visit this link: http://dlang.org/phobos/std_traits.html#isCallable There is this paragraph: Detect whether T is a callable object, which can be called with the function call operator (...). What is this function call operator? (...) Where can i learn more about it?
Re: What is this function call operator?
On Thursday, 27 August 2015 at 15:19:15 UTC, Adam D. Ruppe wrote: On Thursday, 27 August 2015 at 15:18:24 UTC, Gary Willoughby wrote: What is this function call operator? (...) Where can i learn more about it? It is the () at the end of a thing. You can overload it in a struct by writing an opCall member. Sorry, I mean the three dots '...' that seems to be what the documentation is referring to. Also the `isCallable` template uses it.
Re: vibe.d - cannot allocate memory in static TLS block
-fpic was missing std.datetime didnt cause crash anymore after i added the fpic option import vibe.inet.url; import vibe.inet.urltransfer; import vibe.mail.smtp; import vibe.stream.counting; import vibe.stream.memory; import vibe.stream.operations; import vibe.stream.ssl; import vibe.stream.tls; import vibe.stream.zlib; //import vibe.templ.diet; //import vibe.templ.utils; import vibe.textfilter.html; import vibe.textfilter.markdown; import vibe.textfilter.urlencode; import vibe.utils.string; //import vibe.web.web; //import vibe.web.rest; from those modules, the commented out 4 cause the following error Error: Sys_LoadLibrary error: /home/vagrant/.callofduty4/plugin.failtest.tmp: cannot allocate memory in static TLS block Error: Failed to load the plugin /home/vagrant/.callofduty4/plugin.failtest.tmp!
Re: vibe.d - cannot allocate memory in static TLS block
On Thursday, 27 August 2015 at 15:16:25 UTC, John Colvin wrote: I think your problem is that you need to initialise the D runtime. Perhaps adding a call to http://dlang.org/phobos/core_runtime.html#.Runtime.initialize inside OnInit will solve it for you. Also, remember to terminate the runtime when the plugin is unloaded. i thought about that too, but that wasn't the case ( unless i fucked something up ). nothing from my example gets executed, the crash happens i think when the library is loaded. just in case i've also added runtime.initialize also to the vibe main. also if the runtime.initialize would be missing that would mean my executable example should crash, but the executable test works just fine.
Re: vibe.d - cannot allocate memory in static TLS block
i think i started to narrow down the error, and i think the actual error is not in vibe.d, or atleast no only there since import vibe.d causes the shared lib to crash my program, i investigated the vibe.d module. it consists of all the vibe submodule + some modules of phobos. so i started commenting out some of the modules to see which one are causing the error. first i removed all vibe modules and only left in the phobos modules ... crash again - wait what? import std.datetime; causes my library to crash -_- k this is a different error now, but still importing std.datetime; in my test creates a segfault 0.o strange to be continued ... This program has crashed with signal: Segmentation fault The current Gameversion is: CoD4 X 1.7a linux-i386-custom_debug type 'e' build 3382 Aug 27 2015 File is ./cod4x17a_dedrun Hash is: 1c941e6f17d4b4bc3243e033707e1625e48ae9cfa232aeabc42f294ce5adaecc -- Crash Backtrace -- 2: .(Sys_DumpCrash+0xe7) [0x206a5c9] 1: .(Sys_SigHandler+0x3c) [0x206a70c] 0: linux-gate.so.1(__kernel_sigreturn+0) [0xf76e8d40] -- Registers --- edi 0xec0d41b8 esi 0x0 ebp 0xff88ce58 esp 0xff88ce30 eax 0xec0d9380 ebx 0xf770b000 ecx 0x8 edx 0x3960292072 eip 0x0 Backtrace Completed Received signal: Segmentation fault, exiting... Server received signal: Segmentation fault Shutting down server... - Server Shutdown - With the reason: Server received signal: Segmentation fault Terminating server... Sending heartbeat to cod4master.activision.com Sending heartbeat to cod4master.iceops.in Sending heartbeat to cod4master.activision.com Sending heartbeat to cod4master.iceops.in ShutdownGame (1) --- ./run.sh: line 1: 6629 Segmentation fault ./cod4x17a_dedrun +exec server.cfg
Re: dmd codegen improvements
On Thursday, 27 August 2015 at 13:49:18 UTC, Bruno Medeiros wrote: On 19/08/2015 09:22, Dmitry Olshansky wrote: I'm interested in ways to reduce that gap. [...] Replace the backend with GDC or LLVM? :-P Oh come on - LLVM was an inferiour backend for some time. So what? Let us no work on it 'cause GCC is faster? I can't figure out what you meant: LLVM has an inferiour backend to what? GCC or DMD? I think he's saying that the argument: Don't work on DMD because it's already far behind could have been applied to working on LLVM when it was far behind GCC. I don't agree, but I think that's what he means.
[Issue 14971] New: array.length -= x; should be checked for underflow when compiling without -release
https://issues.dlang.org/show_bug.cgi?id=14971
Issue ID: 14971
Summary: array.length -= x; should be checked for underflow
when compiling without -release
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: collin.ree...@gmail.com
For exactly the same reason that the index-out-of-bounds runtime checks are
useful for debugging purposes when compiling without the -release flag,
decrements on the array .length attribute should be checked during runtime for
underflow.
As it is now:
int main()
{
int[] a = [];
a.length--;
return 0;
}
Will yield:
core.exception.OutOfMemoryError@(0)
This should instead be an error message along the lines of the
index-out-of-bounds exception that indicates what the problem actually is.
This is related to Issue 3933 from 2010 (there's still no line number on the
error, which goes a long way to making this issue less important).
--
[Issue 14972] Documentation for std.windows.* missing
https://issues.dlang.org/show_bug.cgi?id=14972 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #1 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/dlang.org/pull/1083 https://github.com/D-Programming-Language/phobos/pull/3593 --
Re: Moving forward with work on the D language and foundation
On Thursday, 27 August 2015 at 18:03:37 UTC, Colin wrote: On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: [...] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. Andrei is past 50? Doesn't look it! And Walter who was involved in the 80's in the team who made MS DOS... do you think he's 20 yo ?
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, [...] Andrei What big news! May you prosper and may the odds favor your (and our) dream, going forward.
Re: D jwtd library propagated on jwt.io
On Tuesday, 25 August 2015 at 13:14:31 UTC, tchaloupka wrote: Maybe unnoticed by the community, but thanks to Oleh (olehlong) D is visible as one of implementations of Json web token library on http://jwt.io/. Great, adding D support to a project is very helpful to grow our ecosystem and a good way to increase D's visibility.
Re: dmd codegen improvements
On Thursday, 27 August 2015 at 17:59:48 UTC, Jonathan M Davis wrote: that's a big win. Every little bit of performance improvement that we can get out of dmd is an improvement, especially when those improvements come at minimal cost, and I see no reason to not improve dmd's performance where it's not going to be a huge timesink to do so and where the appropriate precautions are taken to avoid regressions. Actually, if you think about PR, it does not matter. I might even be better to perform 50% worse and call it a development-mode than to perform 25% worse in release mode... How about putting effort into making it easier to hook multiple backends into the same binary instead? People won't complain if they can toss in -O and get LLVM backend output from the same compiler.
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Congratulations. I am very impressed by the young talent in the D community. I asked one such chap how he knew so much, and he attributed it to learning from being around such top notch guys as you, Andrei, and the other contributors. Should someone post to Reddit ?
Re: Moving forward with work on the D language and foundation
On Thursday, 27 August 2015 at 18:42:41 UTC, BBasile wrote: On Thursday, 27 August 2015 at 18:03:37 UTC, Colin wrote: On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: [...] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. Andrei is past 50? Doesn't look it! And Walter who was involved in the 80's in the team who made MS DOS... do you think he's 20 yo ? We were talkin' bout Andrei yo, not Walter!
Re: Moving forward with work on the D language and foundation
On Thursday, 27 August 2015 at 20:52:42 UTC, Steven Schveighoffer wrote: On 8/27/15 2:03 PM, Colin wrote: On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: [...] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. Andrei is past 50? Doesn't look it! He ain't that old :) http://erdani.com/index.php/about/ Born in 1969 -Steve Sorry, for some reason this is not the best of me i'm showing tonigth...Maybe it'll be better when talking about a PR or anything else...See ya later.
DMD git HEAD now self-hosting
I'm surprised nobody has mentioned this on the forum yet, but as of 23 Aug, dmd git HEAD has switched over to ddmd with the landmark commit 88ec9d8. Since that time, the remaining C++ files have been slowly but surely phased out one by one, replaced with their D equivalents. This is awesome news I think a celebration is in order. ;-) As of today, there are still about 28 or so C++ files left (84 source files are now in D). PRs converting C++ sources to D continue to trickle in. Way to go, D! T -- No! I'm not in denial!
Re: DMD git HEAD now self-hosting
On Thursday, 27 August 2015 at 20:43:49 UTC, H. S. Teoh wrote: I'm surprised nobody has mentioned this on the forum yet […] See http://forum.dlang.org/post/mrbl1d$qhs$1...@digitalmars.com As of today, there are still about 28 or so C++ files left (84 source files are now in D). PRs converting C++ sources to D continue to trickle in. The DMC backend is still in C++, although Daniel is planning to convert it to D too. — David
Re: DMD git HEAD now self-hosting
On Thursday, 27 August 2015 at 20:43:49 UTC, H. S. Teoh wrote: I'm surprised nobody has mentioned this on the forum yet, but as of 23 Aug, dmd git HEAD has switched over to ddmd with the landmark commit 88ec9d8. Since that time, the remaining C++ files have been slowly but surely phased out one by one, replaced with their D equivalents. This is awesome news I think a celebration is in order. ;-) As of today, there are still about 28 or so C++ files left (84 source files are now in D). PRs converting C++ sources to D continue to trickle in. Way to go, D! T Haven't been reading Announce? :) http://forum.dlang.org/post/mrbl1d$qhs$1...@digitalmars.com
Re: DMD git HEAD now self-hosting
On Thu, Aug 27, 2015 at 08:46:57PM +, Brad Anderson via Digitalmars-d wrote: On Thursday, 27 August 2015 at 20:43:49 UTC, H. S. Teoh wrote: I'm surprised nobody has mentioned this on the forum yet, but as of 23 Aug, dmd git HEAD has switched over to ddmd with the landmark commit 88ec9d8. Since that time, the remaining C++ files have been slowly but surely phased out one by one, replaced with their D equivalents. This is awesome news I think a celebration is in order. ;-) As of today, there are still about 28 or so C++ files left (84 source files are now in D). PRs converting C++ sources to D continue to trickle in. Way to go, D! T Haven't been reading Announce? :) http://forum.dlang.org/post/mrbl1d$qhs$1...@digitalmars.com Ahh, just realized I'm not subscribed to the announce mailing list. *facepalm* T -- English has the lovely word defenestrate, meaning to execute by throwing someone out a window, or more recently to remove Windows from a computer and replace it with something useful. :-) -- John Cowan
[Issue 14970] [D1] Add support for Template Params section in ddoc
https://issues.dlang.org/show_bug.cgi?id=14970 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- This looks like a good idea. How about introducing it in the n.g. and see what others think of it? --
Re: Moving forward with work on the D language and foundation
On 8/27/15, BBasile via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 27 August 2015 at 18:03:37 UTC, Colin wrote: On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: [...] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. Andrei is past 50? Doesn't look it! And Walter who was involved in the 80's in the team who made MS DOS... do you think he's 20 yo ? Hmm.. ? This is the first time I've heard of this. He's one of the very first people who have developed a C++ compiler, but MS-DOS?
Re: Moving forward with work on the D language and foundation
On 8/27/15 2:03 PM, Colin wrote: On Thursday, 27 August 2015 at 16:01:54 UTC, BBasile wrote: On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: [...] That's courageous, particularly past 50 yo. It's a different culture, past 50 yo in Europe people choose security, but in USA, past 50 yo some people still take the risk to try something new. Awesome. Andrei is past 50? Doesn't look it! He ain't that old :) http://erdani.com/index.php/about/ Born in 1969 -Steve
[Issue 14955] [D1] Add module profiling feature
https://issues.dlang.org/show_bug.cgi?id=14955 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- You can also use separate compilation to achieve the same effect. --
[Issue 7015] Allow vector operations into newly declared array
https://issues.dlang.org/show_bug.cgi?id=7015 Ryuichi OHORI r.97...@gmail.com changed: What|Removed |Added CC||r.97...@gmail.com --- Comment #4 from Ryuichi OHORI r.97...@gmail.com --- (In reply to Stewart Gordon from comment #3) So this is really two things: (a) as you say, a diagnostic bug, as the error message when you try to do it is bogus (b) a language feature request to allow this code Maybe (b) is a duplicate of 2548 --
Error Compiling with -debug swtich
Hello,
Just wondering why compiling the following fails with the -debug
switch, but appears to compile and execute fine without it:
import std.stdio;
import std.algorithm;
import std.container;
int main(string[] args) {
Array!string letters = [b,a,c];
sort(letters[]);
writeln (letters[]); // [a,b,c]
return 0;
}
With the -debug switch, I get:
src\phobos\std\range\package.d(7180): Error:
'std.range.SortedRange!(RangeT!(Array!string), a
b).SortedRange.dbgVerifySorted' is not nothrow
src\phobos\std\algorithm\sorting.d(982): Error: template instance
std.range.assumeSorted!(a b, RangeT!(Array!string)) error
instantiating
Without the switch, everything seems to work fine...(I'm using
DMD 2.068.0)
Thanks,
Jordan
Re: DCD v0.7.0-rc1
On Thursday, 27 August 2015 at 10:13:38 UTC, BBasile wrote: On Tuesday, 25 August 2015 at 08:57:12 UTC, Brian Schott wrote: On Tuesday, 25 August 2015 at 08:46:18 UTC, BBasile wrote: On Friday, 21 August 2015 at 10:15:09 UTC, Brian Schott wrote: [...] Tuesday...what's going on, everything is fine ? I'm still tracking down some problems. http://forum.dlang.org/post/fgzvowtioiudjvvha...@forum.dlang.org I've seen some activity on your allocator fork and on the DCD submodules yesterday, is it ok to release the DCD binaries based on the current state ? Is the problem fixed ? Or would you recommend more to distribute latest stable 0.6 (for example just after A.Neves fixed a regression) ? Never mind...I'll release in a few hours...
Re: DCD v0.7.0-rc1
On Thursday, 27 August 2015 at 10:13:38 UTC, BBasile wrote: I've seen some activity on your allocator fork and on the DCD submodules yesterday, is it ok to release the DCD binaries based on the current state ? Is the problem fixed ? Or would you recommend more to distribute latest stable 0.6 (for example just after A.Neves fixed a regression) ? No. I'll tag 0.7.0 when it's ready. There are still a few bugs. (Just for fun, run a build from master in Valgrind)
Re: DMD git HEAD now self-hosting
On Thursday, 27 August 2015 at 20:46:59 UTC, Brad Anderson wrote:
On Thursday, 27 August 2015 at 20:43:49 UTC, H. S. Teoh wrote:
I'm surprised nobody has mentioned this on the forum yet, but
as of 23 Aug, dmd git HEAD has switched over to ddmd with the
landmark commit 88ec9d8. Since that time, the remaining C++
files have been slowly but surely phased out one by one,
replaced with their D equivalents.
This is awesome news I think a celebration is in order. ;-)
As of today, there are still about 28 or so C++ files left (84
source files are now in D). PRs converting C++ sources to D
continue to trickle in.
Way to go, D!
T
Haven't been reading Announce? :)
http://forum.dlang.org/post/mrbl1d$qhs$1...@digitalmars.com
So.. looking through the source, I see lots of this:
extern (C++) class { ... }
Wasn't extern(C++) only supposed to work on interfaces?
Are the docs outdated?
Thanks,
Bit
Re: vibe.d - cannot allocate memory in static TLS block
same result on windows
Coedit 1 - update 2
I'm glad to announce that a second update, for Coedit 1, is available. https://github.com/BBasile/Coedit/releases/tag/1_update_2 https://github.com/BBasile/Coedit Coedit is an IDE for the DMD compiler. It's 'a DMD GUI for the free electrons'. If it's not enough it may be all too much (https://www.youtube.com/watch?v=S5M2GtNpPE4) Have fun while you can, life is short.
Re: D-Day for DMD is today!
Bruno Medeiros wrote in message news:mrn30f$26ff$2...@digitalmars.com... Cool stuff! Yeah! What's the plan going forward, for those not so much up to date with what's going on? Is the next major release of DMD gonna be D-DMD based then? Which compiler is going to be used to compile D-DMD? The next major release (2.069) will use the D-based frontend. We're planning to use GDC and/or LDC releases based on the 2.067 frontend to compile DMD on most platforms.
[Issue 14952] Redundant REX.W before FSTP confuses Valgrind
https://issues.dlang.org/show_bug.cgi?id=14952 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14973] New: [REG2.068] compiler inference of contexts for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14973
Issue ID: 14973
Summary: [REG2.068] compiler inference of contexts for nested
map seems broken
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
This is separated from issue 14962 because the root issue is not exactly same.
import std.range;
import std.algorithm;
class Foo {
int baz() {return 1;}
void bar() {
auto s = [1].map!(i = baz()); // compiles
auto r = [1].map!(i = [1].map!(j = baz())); // error
}
}
testfoo.d(8): Error: need 'this' for 'baz' of type 'int()'
/Users/steves/git/dmd2/osx/bin/../../src/phobos/std/algorithm/iteration.d(459):
instantiated from here: MapResult!(__lambda2, int[])
testfoo.d(8):instantiated from here: map!(int[])
/Users/steves/git/dmd2/osx/bin/../../src/phobos/std/algorithm/iteration.d(549):
instantiated from here: __lambda2!int
/Users/steves/git/dmd2/osx/bin/../../src/phobos/std/algorithm/iteration.d(459):
instantiated from here: MapResult!(__lambda2, int[])
testfoo.d(8):instantiated from here: map!(int[])
--
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! https://www.reddit.com/r/programming/comments/3ioy2l/d_compiler_dmd_moves_front_end_to_pure_d_from_c/ Ready for London morning.
[Issue 14973] [REG2.068] compiler inference of contexts for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14973 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4971 --
[Issue 14955] [D1] Add module profiling feature
https://issues.dlang.org/show_bug.cgi?id=14955 Dicebot pub...@dicebot.lv changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #2 from Dicebot pub...@dicebot.lv --- Technically you can but separate compilation like that is very effort consuming to add to any non-trivial build system (if it doesn't support separate compilation from the very beginning). In our use case there is in-house makefile framework that handles most of low level details automatically and circumventing that is considerably more effort than just overriding DFLAGS in whole makefile. On the other hand, is there any reason why it is a bad idea (apart from general minimize additions concern)? --
[Issue 14781] [REG2.067] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||rejects-valid Summary|impure delegate to pure |[REG2.067] impure delegate |function context should be |to pure function context |able to modify context |should be able to modify ||context Severity|enhancement |regression --- Comment #7 from Kenji Hara k.hara...@gmail.com --- I change the importance to regression, because the introduced behavior since 2.067 rejects valid code. --
Re: DMD git HEAD now self-hosting
H. S. Teoh via Digitalmars-d wrote in message news:mailman.579.1440708229.13986.digitalmar...@puremagic.com... I'm surprised nobody has mentioned this on the forum yet, but as of 23 Aug, dmd git HEAD has switched over to ddmd with the landmark commit 88ec9d8. Since that time, the remaining C++ files have been slowly but surely phased out one by one, replaced with their D equivalents. This is awesome news I think a celebration is in order. ;-) We've been celebrating without you on the announce list! As of today, there are still about 28 or so C++ files left (84 source files are now in D). PRs converting C++ sources to D continue to trickle in. Way to go, D! Unfortunately it's going to slow down for a little while. The files I've done post-switch were only left in C++ because they used a small part of the backend headers and were easier to do by hand instead of converting automatically. The rest of the glue layer/backend (~90 c++ files) is going to need a conversion project of the same scale as the frontend one, preceded by a refactoring project 10 times the size of the frontend one. Walter's recent backend cleanup PRs are working on this, and I'm working on a backend test suite to make refactoring safer. We could see DMD be 100% D within six months, depending on how much free time I have and how picky Walter is about my refactoring PRs.
[Issue 14952] Redundant REX.W before FSTP confuses Valgrind
https://issues.dlang.org/show_bug.cgi?id=14952 --- 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/20938d46c4ba8aafd9ff40965484555e58ce0e37 fix Issue 14952 - Redundant REX.W before FSTP confuses Valgrind https://github.com/D-Programming-Language/dmd/commit/b570bf975f4e85ad6572720f7d4769ad8bee62a7 Merge pull request #4967 from WalterBright/fix14952 [REG] fix Issue 14952 - Redundant REX.W before FSTP confuses Valgrind --
documentation for C/C++ interop
would someone care to work on updating this? I understand from
Daniel's post in main list that the only thing that doesn't work
is special member functions. that's different from what the
documents say, and it is surely something important for D that
people are aware of this.
I don't really know C++, so I won't be much good at writing it,
otherwise I would have a first stab at it myself.
But I tried with the following toy, which worked fine:
import std.stdio;
extern(C++) struct Test
{
int i;
extern(C++) void mutate()
{
i+=10;
//test=goodbye.dup.ptr;
}
}
extern(C++) void callme(Test* test);
void main(string[] args)
{
Test test;
writefln(%s,test);
test.mutate;
writefln(%s,test);
callme(test);
writefln(%s,test);
}
#include stdio.h
struct Test
{
int i;
public:
void mutate();
};
void callme(struct Test* test)
{
test-i=(test-i)+1;
test-mutate();
}
[Issue 14962] [REG2.068] compiler inference of attributes for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14962 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@gmail.com --- The behavior comes from issue 14781. So I also changed it to a regression. https://github.com/D-Programming-Language/dmd/pull/4970 --
[Issue 14781] [REG2.067] impure delegate to pure function context should be able to modify context
https://issues.dlang.org/show_bug.cgi?id=14781 --- Comment #8 from Kenji Hara k.hara...@gmail.com --- New PR targeting 2.068.1 release: https://github.com/D-Programming-Language/dmd/pull/4970 --
[Issue 14955] [D1] Add module profiling feature
https://issues.dlang.org/show_bug.cgi?id=14955 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com --- (In reply to Walter Bright from comment #1) You can also use separate compilation to achieve the same effect. Ah, I haven't thought of that. Unfortunately it would be time consuming for us to transfer to using separate compilation, whereas the implementation for this is very little code. Would you be against adding support for this only in D1? We can provide the implementation, of course. --
[Issue 14973] [REG2.068] compiler inference of contexts for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14973 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- The regression has been introduced by: https://github.com/D-Programming-Language/dmd/pull/4464 --
[Issue 14962] [REG2.068] compiler inference of attributes for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14962
--- Comment #2 from Kenji Hara k.hara...@gmail.com ---
(In reply to Steven Schveighoffer from comment #0)
Another case:
import std.range;
import std.algorithm;
class Foo {
int baz() {return 1;}
void bar() {
auto s = [1].map!(i = baz()); // compiles
auto r = [1].map!(i = [1].map!(j = baz())); // error
}
}
[snip]
I separated the second case into issue 14973.
--
Re: DCD v0.7.0-rc1
On Thursday, 27 August 2015 at 22:18:25 UTC, Brian Schott wrote: On Thursday, 27 August 2015 at 10:13:38 UTC, BBasile wrote: I've seen some activity on your allocator fork and on the DCD submodules yesterday, is it ok to release the DCD binaries based on the current state ? Is the problem fixed ? Or would you recommend more to distribute latest stable 0.6 (for example just after A.Neves fixed a regression) ? No. I'll tag 0.7.0 when it's ready. There are still a few bugs. (Just for fun, run a build from master in Valgrind) By the way you should also take the upstream version of 'mallocator.d'. I dont know if you' ve get why i've pinged you last week but currently DCD cannot be build in debug mode on Windows 32 bit...look at the notifications and you'll understand why. Believe or not but some low-level C functions were not existing and that's why something like one year ago you get a bug report...it looks like a switch was added to link microsoft C library (-betterC) even on win32 but so far if you compile DCD with -debug -g|-gc then BANG error...
Re: dmd codegen improvements
John Colvin wrote in message news:qlbnpjnizwpslrdpk...@forum.dlang.org... I think he's saying that the argument: Don't work on DMD because it's already far behind could have been applied to working on LLVM when it was far behind GCC. I don't agree, but I think that's what he means. It helps that LLVM has a superior license.
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. [...] I hope you don't mind, but I guess it is public info now, and news has a greater impact when fresh: https://www.reddit.com/r/programming/comments/3ioy9b/andrei_alexandrescu_c_guru_leaves_facebook_to/
Re: DMD git HEAD now self-hosting
bitwise wrote in message news:ydbofgjkddszxedpw...@forum.dlang.org...
So.. looking through the source, I see lots of this:
extern (C++) class { ... }
Wasn't extern(C++) only supposed to work on interfaces?
Are the docs outdated?
Yup. extern(C++) works with almost everything except special member
functions.
[Issue 14952] Redundant REX.W before FSTP confuses Valgrind
https://issues.dlang.org/show_bug.cgi?id=14952 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/098403aa9858201f2e664cf8d6cb33c0f697bff8 Merge pull request #4967 from WalterBright/fix14952 [REG] fix Issue 14952 - Redundant REX.W before FSTP confuses Valgrind --
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. [...] Awesome. I wish I could join you. :) Maybe in time. How do we donate? Is there a mechanism to maybe do reoccurring donations via PayPal?
Re: Reading and converting binary file 2 bits at a time
On Thursday, 27 August 2015 at 09:26:55 UTC, rumbu wrote:
On Thursday, 27 August 2015 at 09:00:02 UTC, Andrew Brown wrote:
Hi,
I need to read a binary file, and then process it two bits at
a time. But I'm a little stuck on the first step. So far I
have:
import std.file;
import std.stdio;
void main(){
auto f = std.file.read(binaryfile);
auto g = cast(bool[]) f;
writeln(g);
}
but all the values of g then are just true, could you tell me
what I'm doing wrong? I've also looked at the bitmanip module,
I couldn't get it to help, but is that the direction I should
be looking?
Thanks very much
Andrew
auto bytes = cast(ubyte[])read(binaryfile);
foreach(b; bytes)
{
writeln((b 0xC0) 6); //bits 7, 6
writeln((b 0x30) 4); //bits 5, 4
writeln((b 0x0C) 2); //bits 3, 2
writeln((b 0x03)); //bits 1, 0
}
That's lovely, thank you. One quick question, the length of the
file is not a multiple of the length of ubyte, but the cast
still seems to work. Do you know how it converts a truncated
final section?
Thanks again
Andrew
Re: vibe.d - cannot allocate memory in static TLS block
On Thursday, 27 August 2015 at 09:10:59 UTC, Rikki Cattermole wrote: Perhaps try 0.7.24 which is the last stable release (0.7.25 is in alpha according to git tags). thx rikki, but sadly the newer version didn't solve my problems
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone [...] Wow.
Arrays of structs
I'm a c++ programmer trying to understand how memory allocation works in D. I created a struct and added a destructor to it. My understanding is that structs have deterministic destructors - they are called when the struct goes out of scope (unless it is allocated with new). Now if I put instances of the struct in a fixed size array data[6] d; d[3] = data(1, 2, 3); then the destructor on all the contents is called when the array goes out of scope. However if I add them to a dynamic array... data[] d; d ~= data(1, 2, 3) Then the destructor appears to be called at some random time later. So it looks like it's the garbage collection that is doing this. That seems to go against the specification of how struct works... I'm not creating the item with new and as far as I can tell the array is storing instances of objects, not pointers to objects? Is my understanding correct? Is it documented anywhere how memory allocation works for this? Is a dynamic array in fact storing an array of GC'd pointers to the structs? Or something else...
Re: DCD v0.7.0-rc1
On Tuesday, 25 August 2015 at 08:57:12 UTC, Brian Schott wrote: On Tuesday, 25 August 2015 at 08:46:18 UTC, BBasile wrote: On Friday, 21 August 2015 at 10:15:09 UTC, Brian Schott wrote: https://github.com/Hackerpilot/DCD/releases/tag/v0.7.0-rc1 If nothing else comes up I'll tag 0.7.0 Monday. DCD is an editor-independent auto-completion program for D code. Read more here: https://github.com/Hackerpilot/DCD Tuesday...what's going on, everything is fine ? I'm still tracking down some problems. http://forum.dlang.org/post/fgzvowtioiudjvvha...@forum.dlang.org I've seen some activity on your allocator fork and on the DCD submodules yesterday, is it ok to release the DCD binaries based on the current state ? Is the problem fixed ? Or would you recommend more to distribute latest stable 0.6 (for example just after A.Neves fixed a regression) ?
[Issue 14605] RefAppender fails isOutputRange
https://issues.dlang.org/show_bug.cgi?id=14605 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/dd2161705a7c6eb2fc9ba913a09b0592dde25469 std.traits.hasMember: just forward to __traits(hasMember, ...) This way opDispatch'ed members are recognized. Fixes issue 14605 - RefAppender fails isOutputRange. --
Re: Arrays of structs
Hi, On Thursday, 27 August 2015 at 10:05:31 UTC, John Burton wrote: understanding is that structs have deterministic destructors - they are called when the struct goes out of scope Yes, when they are declared right at the scope, and not contained in something that might live past the current scope. However if I add them to a dynamic array... Then the destructor appears to be called at some random time later. So it looks like it's the garbage collection that is doing this. Yeah. That seems to go against the specification of how struct works... I'm not creating the item with new and as far as I can tell the array is storing instances of objects, not pointers to objects? The array is storing the full structs, yes. The array is GC-ably allocated and will therefore not go out of scope at end of scope. Because the array doesn't vanish here, the structs inside will not go out of scope either; they treat the array as their scope. (I'm sure others could explain this more formally.) There is no reference left to the array, so the GC may at a random later time deallocate the array, and thereby call ~this() on each struct. Is my understanding correct? Explicit new is not the only way to put objects on the GC'ed heap. Putting them in a GC-ed array like this is another way. Or having them as a component in a class, then instantiating that class. Is it documented anywhere how memory allocation works for this? I'll leave this for others, too. Is a dynamic array in fact storing an array of GC'd pointers to the structs? No, it's the full struct. -- Simon
