Re: Internal Compiler Error Help
https://github.com/CyberShadow/DustMite/wiki On Thursday, 21 May 2015 at 08:28:30 UTC, Saurabh Das wrote: Hello, We have been working on a genetic programming project, and occasionally the compiler fails and gives an internal error. I've captured and reduced one of these down to a single expression. See http://dpaste.dzfl.pl/e7a66aa067ab (reduced_expr.d) When I compile this file using: dmd -c -O reduced_expr.d It says: DMD 2.066.1] Internal error: backend/cod1.c 1562 DMD 2.067.1] Internal error: backend/cod1.c 1567 The compile succeeds without the '-O' flag. Am I correct in assuming that an internal error in the compiler should be filed as a bug report? As you can see, the expression is a massive ugly thing, as is often the case with genetic programming. I'd like to reduce this expression further before filing said bug report. I recall seeing a project on this forum which automatically figures out the simplest program which causes a compile failure. Can someone kindly point me to it? Thanks, Saurabh
Internal Compiler Error Help
Hello, We have been working on a genetic programming project, and occasionally the compiler fails and gives an internal error. I've captured and reduced one of these down to a single expression. See http://dpaste.dzfl.pl/e7a66aa067ab (reduced_expr.d) When I compile this file using: dmd -c -O reduced_expr.d It says: DMD 2.066.1] Internal error: backend/cod1.c 1562 DMD 2.067.1] Internal error: backend/cod1.c 1567 The compile succeeds without the '-O' flag. Am I correct in assuming that an internal error in the compiler should be filed as a bug report? As you can see, the expression is a massive ugly thing, as is often the case with genetic programming. I'd like to reduce this expression further before filing said bug report. I recall seeing a project on this forum which automatically figures out the simplest program which causes a compile failure. Can someone kindly point me to it? Thanks, Saurabh
Re: Template type deduction and specialization
On Wed, 20 May 2015 17:23:05 -0700 Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: 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 1.) we could fix just doc - easiest, but inconsistent 2.) remove implicit deduction even for fun(T:char)(T c) and all other specialization - code breakage so imho not good 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
deserialization: creating a class instance without calling constructor
Can I create an instance of A without calling a constructor? (see below)
Use case: for generic deserialiaztion, when the deserialization library
encounters a class without default constructor for example (it knows what
the fields should be set to, but doesn't know how to construct the object).
class A{
int x=2;
this(int x){
this.x=x;
}
}
This came up here:
https://github.com/msgpack/msgpack-d/issues/54#issuecomment-104136148
I provide some hacky solution for that in that thread but I suspect it's
not safe and something is missing.
Re: Internal Compiler Error Help
Thanks!
Wow, dustmite is really useful. It reduces the expression down to:
double someFunction(double AvgPriceChangeNormalized, double
TicksTenMinutesNormalized)
{
return
(TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0;
}
Which gives a compiler error: Internal error: backend/cod1.c 1562
Re: deserialization: creating a class instance without calling constructor
On Thursday, 21 May 2015 at 09:06:59 UTC, Timothee Cour wrote:
Can I create an instance of A without calling a constructor?
(see below)
Use case: for generic deserialiaztion, when the deserialization
library
encounters a class without default constructor for example (it
knows what
the fields should be set to, but doesn't know how to construct
the object).
class A{
int x=2;
this(int x){
this.x=x;
}
}
This came up here:
https://github.com/msgpack/msgpack-d/issues/54#issuecomment-104136148
I provide some hacky solution for that in that thread but I
suspect it's
not safe and something is missing.
For a start I'm pretty sure you want to be calling
core.memory.GC.malloc not core.stdc.stdlib.malloc, otherwise you
leak the memory.
Re: Internal Compiler Error Help
On Thursday, May 21, 2015 08:28:29 Saurabh Das via Digitalmars-d-learn wrote: Am I correct in assuming that an internal error in the compiler should be filed as a bug report? Yes. You should never see an ICE, and the compiler should never segfault. So, whenever you see either of those happen, please report it. - Jonathan M Davis
Re: Dual conditions in D and Python
On Thursday, May 21, 2015 16:57:14 Dennis Ritchie via Digitalmars-d-learn wrote:
Hi,
In Python I can write this:
if (4 = 5 = 6):
print (OK)
-
http://rextester.com/NNAM70713
In D, I can only write this:
import std.stdio;
void main() {
if (4 = 5 5 = 6)
puts(OK);
}
-
http://rextester.com/FICP83173
I wanted to ask what is the reason? Maybe the program on Python's
slower because of this? Or legacy C/C++ affected D?
No C-based language allows what python does, and based on operators work in
C-based languages, what python is doing simply doesn't fit or make sense.
What happens in C/C++/D/Java/C#/etc. land is that 4 = 5 results in a bool,
at which point you'd end up with a comparison between that bool and 6, which
is _not_ something that you want. But with other operators _is_ very much
what you'd want. Operator chaining works in the same way across all
operators in C-based languages, and trying to make 4 = 5 = 6 be equivalent
to 4 = 5 5 = 6 would make it so that they weren't consistent. And it
wouldn't make the language any more powerful, because you can quite easily
just do 4 = 5 5 = 6 instead of 4 = 5 = 6. It only costs you a few
characters and results in the language being far more consistent. I'm
honestly quite surprised that python would allow such a thing, but they seem
to do a lot of stuff that most programmers from C-based languages
(especially C++) would think is crazy.
- Jonathan M Davis
Re: Dual conditions in D and Python
Dennis Ritchie wrote: if (4 = 5 = 6): print (OK) - I would rather write: if( isSorted![4,5,6]) -manfred
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 18:26:28 UTC, Dennis Ritchie wrote: elif instead of else if: http://rextester.com/WOSH30608 The parallel exchange values: http://rextester.com/TPUD51604 wow!
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 18:26:28 UTC, Dennis Ritchie wrote:
On Thursday, 21 May 2015 at 17:43:25 UTC, Jonathan M Davis
wrote:
No C-based language allows what python does, and based on
operators work in
C-based languages, what python is doing simply doesn't fit or
make sense.
What happens in C/C++/D/Java/C#/etc. land is that 4 = 5
results in a bool,
at which point you'd end up with a comparison between that
bool and 6, which
is _not_ something that you want. But with other operators
_is_ very much
what you'd want. Operator chaining works in the same way
across all
operators in C-based languages, and trying to make 4 = 5 = 6
be equivalent
to 4 = 5 5 = 6 would make it so that they weren't
consistent. And it
wouldn't make the language any more powerful, because you can
quite easily
just do 4 = 5 5 = 6 instead of 4 = 5 = 6. It only costs
you a few
characters and results in the language being far more
consistent. I'm
honestly quite surprised that python would allow such a thing,
but they seem
to do a lot of stuff that most programmers from C-based
languages
(especially C++) would think is crazy.
- Jonathan M Davis
Yes, of course, some of Python's design for C ++ - programmers
will look crazy, but they are worth it :)
elif instead of else if:
http://rextester.com/WOSH30608
The parallel exchange values:
http://rextester.com/TPUD51604
Something I sometimes do for strictly personal projects:
import std.typecons : ω = tuple;
import std.typetuple : Ω = TypeTuple;
void main()
{
auto a = 1, b = 2;
Ω!(a, b) = ω(b, a);
assert(a==2 b==1);
}
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 17:43:25 UTC, Jonathan M Davis wrote: No C-based language allows what python does, and based on operators work in C-based languages, what python is doing simply doesn't fit or make sense. What happens in C/C++/D/Java/C#/etc. land is that 4 = 5 results in a bool, at which point you'd end up with a comparison between that bool and 6, which is _not_ something that you want. But with other operators _is_ very much what you'd want. Operator chaining works in the same way across all operators in C-based languages, and trying to make 4 = 5 = 6 be equivalent to 4 = 5 5 = 6 would make it so that they weren't consistent. And it wouldn't make the language any more powerful, because you can quite easily just do 4 = 5 5 = 6 instead of 4 = 5 = 6. It only costs you a few characters and results in the language being far more consistent. I'm honestly quite surprised that python would allow such a thing, but they seem to do a lot of stuff that most programmers from C-based languages (especially C++) would think is crazy. - Jonathan M Davis Yes, of course, some of Python's design for C ++ - programmers will look crazy, but they are worth it :) elif instead of else if: http://rextester.com/WOSH30608 The parallel exchange values: http://rextester.com/TPUD51604
Re: Template type deduction and specialization
On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote: On Wed, 20 May 2015 17:23:05 -0700 Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: 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 1.) we could fix just doc - easiest, but inconsistent Before doing this, we have to understand what works and what doesn't. It's not clear to me. 2.) remove implicit deduction even for fun(T:char)(T c) and all other specialization - code breakage so imho not good I don't think this is possible, this would break lots of existing code. 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2 I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides because the docs say so? A possible explanation is that the specialization doesn't resolve to a *specific type* but instead resolves to a *flavor of type*. For example, does this work? foo(T : int*)(T t) That would make some sense at least, but I don't understand why this rule is in place. -Steve
Re: Template type deduction and specialization
On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote: On Thu, 21 May 2015 08:54:54 -0400 Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote: On Wed, 20 May 2015 17:23:05 -0700 Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: 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 1.) we could fix just doc - easiest, but inconsistent Before doing this, we have to understand what works and what doesn't. It's not clear to me. 2.) remove implicit deduction even for fun(T:char)(T c) and all other specialization - code breakage so imho not good I don't think this is possible, this would break lots of existing code. 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2 I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides because the docs say so? But this will break more code than 2. So it is impossible to fix it. Not more, but it will be worst, because it could change behaviour of program without error message
Re: Internal Compiler Error Help
double foo(double b)
{
return b / (b == 0) == 0;
}
Looks like this fails too.
Re: Internal Compiler Error Help
PS: The original expression:
http://dpaste.dzfl.pl/raw/e7a66aa067ab
double someFunction(double AvgPriceChangeNormalized, double
DayFactor, double TicksTenMinutesNormalized)
{
return
AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*(TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))*(TicksTenMinutesNormalized;
}
Re: GC Destruction Order
On 5/20/15 11:09 AM, Kagamin wrote: 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). It's essential for lockless thread-local programming. At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File. The absolute best part about the shared qualifier is the lack of shared qualifier -- you can be certain something isn't shared if it doesn't have shared attached to it. Right now, even in that case, you still have to worry about RAII objects being destroyed in other threads. We shouldn't have to worry about that. -Steve
Re: GC Destruction Order
On 5/21/15 8:40 AM, Kagamin wrote: On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote: At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File. You mean the reference counting part? Yes, if you put a File as a class member, the destructor of the class would call the File's destructor, which could be run in any thread. Since File is a reference counted wrapper, the destructor decrements the reference count and possibly closes the file. The whole operation must be atomic if we are spread across threads. But if you only ever access that containing class in a local thread, you are paying the cost of locking (or at least atomic decrement) for all reference counts on that file, for very little reason. Especially if the File doesn't live in a heap object (dtor doesn't know where it's being called from). -Steve
Re: Internal Compiler Error Help
and please submit to https://issues.dlang.org Submitted: https://issues.dlang.org/show_bug.cgi?id=14613 That expression is, not to put too fine a point on it, mad. The operator precedence itself is giving me a headache, let alone the division of a double by a boolean... I'm pretty sure it doesn't do what you want it to, unless what you want is seriously weird. As a matter of fact, i'm pretty sure that expression evaluates to 1, irrelevant of the values of the two variables. s/irrelevant/irrespective/ The original expression was a candidate in a genetic programming population - a result of trial and error / natural selection over a few generations. The dustmite-reduced expression is really weird I agree - I don't know what to make of it. I've reported it as I found it. The otiginal expression is not so wierd, it just haphazardly long. It doesn't do any strange divides or compares. In either case, it shouldn't compile normally without the '-O' and fail to compile with it. We managed a 1000x speed up over Java on our genetic programming system by using D, but this compile failure is preventing us from using the release / optimised builds :(( Thanks, Saurabh
Re: DMD Symbol Reference Analysis Pass
On Wednesday, 20 May 2015 at 09:41:09 UTC, Per Nordlöw wrote: On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote: Ping!?
Re: GC Destruction Order
On 5/19/15 7:03 PM, bitwise wrote: On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On 5/19/15 5:07 PM, bitwise wrote: On Tue, 19 May 2015 15:36:21 -0400, rsw0x anonym...@anonymous.com wrote: On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote: On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe destructiona...@gmail.com wrote: On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote: Is this also true for D? Yes. The GC considers all the unreferenced memory dead at the same time and may clean up the class and its members in any order. Ugh... I was really hoping D had something better up it's sleeve. It actually does, check out RefCounted!T and Unique!T in std.typecons. They're sort of limited right now but undergoing a major revamp in 2.068. Any idea what the plans are?. Does RefCounted become thread safe? Correct me if I'm wrong though, but even if RefCounted itself was thread-safe, RefCounted objects could still be placed in classes, at which point you might as well use a GC'ed class instead, because you'd be back to square-one with your destructor racing around on some random thread. With the current GC, yes. RefCounted needs to be thread safe in order to use it. But if we change the GC, we could ensure destructors are only called in the thread they were created in (simply defer destructors until the next GC call in that thread). This seems like it could result in some destructors being delayed indefinitely. That's already the case. I'm finding it hard to be optimistic about the memory model of D. The idea of marking absolutely everything in your program with @nogc just to make it safe is ludicrous. That makes no sense, the GC is not unsafe. Maybe I worded that incorrectly, but my point is that when you're running with the GC disabled, you should only use methods marked with @nogc if you want to make sure your code doesn't leak right? that's a lot of attributes O_O OK, I see your point. Yes, you need @nogc to not leak. The point of @nogc was to ensure machine-checkable prevention of GC calls. The idea is to put @nogc on main(), and then all your calls will have to be @nogc. Where it absolutely comes in handy is compiler generated GC calls that can be unexpected (e.g. closures). But I'd still recommend not disabling the GC, as that is redundant, and having a stray GC call will not leak if something somehow (roguely) uses the GC (there are ways to do this). Alternatively, you can run a collection at opportune times just in case. It means you have to live with a subset of the language, and phobos cannot support you 100%. We are working to ensure that it's @nogc as much as possible. -Steve
Re: Template type deduction and specialization
On Thu, 21 May 2015 08:54:54 -0400 Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote: On Wed, 20 May 2015 17:23:05 -0700 Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: 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 1.) we could fix just doc - easiest, but inconsistent Before doing this, we have to understand what works and what doesn't. It's not clear to me. 2.) remove implicit deduction even for fun(T:char)(T c) and all other specialization - code breakage so imho not good I don't think this is possible, this would break lots of existing code. 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2 I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides because the docs say so? But this will break more code than 2. So it is impossible to fix it.
Re: GC Destruction Order
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote: At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File. You mean the reference counting part?
Re: GC Destruction Order
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote: At this moment, a thread-local-only heap pointer must deal with multi-threading issues simply because destructors can run on another thread, even though the reference is thread-local. The biggest example right now is reference-counted structures such as std.stdio.File. Just for the record: .net doesn't use reference counting for system resources like files, it works fine, such resources usually have well-defined ownership.
Re: DMD Symbol Reference Analysis Pass
On Thursday, 21 May 2015 at 11:52:34 UTC, Per Nordlöw wrote: On Wednesday, 20 May 2015 at 09:41:09 UTC, Per Nordlöw wrote: On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote: Ping!? I think you'd be more likely to get responses to this sort of question in the main group, not D.learn, it's a bit beyond Learning D.
Re: Writing to two files at once
On Thursday, 21 May 2015 at 21:02:42 UTC, Ali Çehreli wrote:
On 05/21/2015 01:56 PM, wobbles wrote:
What I ended up doing was creating an OutputRange that
contains the
files I want to write to.
On OutputRange.put I simply print to print to all the files.
Just like MultiFile example here: :)
http://ddili.org/ders/d.en/ranges.html#ix_ranges.OutputRange
Ali
Yeah!
This is my implementation:
public struct OutputSink{
File[] files;
@property void addFile(File f){ files ~= f; }
@property File[] file(){ return files; }
void put(Args...)(string fmt, Args args){
foreach(file; files)
file.writefln(fmt, args);
}
}
I'll remember to look in your book next time I need something
simple :)
Re: Writing to two files at once
On Thursday, 21 May 2015 at 21:16:59 UTC, wobbles wrote: On Thursday, 21 May 2015 at 21:00:15 UTC, Cassio Butrico wrote: If I understand right you want to redirect the output to a file by a flag , another file type , video printer is it? I think by video printer you mean the console? If so, yes. I believe I've solved it anyway, see Ali and my answer above. Thanks! You're right, Ali 's book is of great help for all
Re: Writing to two files at once
On Thursday, 21 May 2015 at 20:15:29 UTC, wobbles wrote: On Thursday, 21 May 2015 at 20:06:08 UTC, wobbles wrote: I would like to write to two files at once. If user specifies verbose flag, output should write to both stdout and the programs standard output file. Any ideas? I should add, I'm using a library that already writes it's output to a std.stdout.File that I can provide it, so my thinking is I need a std.stdout.File that points at both stdout and some arbitrary file location. Tricky I think... If it is hardcoded to take a File (I.e. it's not a template parameter), then your options are: modify the library, modify phobos or use the OS to do the duplication. On *nix you should be able to do it quite easily, don't know about windows.
Re: Writing to two files at once
On Thursday, 21 May 2015 at 20:15:29 UTC, wobbles wrote: On Thursday, 21 May 2015 at 20:06:08 UTC, wobbles wrote: I would like to write to two files at once. If user specifies verbose flag, output should write to both stdout and the programs standard output file. Any ideas? I should add, I'm using a library that already writes it's output to a std.stdout.File that I can provide it, so my thinking is I need a std.stdout.File that points at both stdout and some arbitrary file location. Tricky I think... What I ended up doing was creating an OutputRange that contains the files I want to write to. On OutputRange.put I simply print to print to all the files. Means I had to edit the underlying library, but that's OK as I own it, and this seems more robust anyway :)
Re: Writing to two files at once
If I understand right you want to redirect the output to a file by a flag , another file type , video printer is it?
Re: Writing to two files at once
On 05/21/2015 01:56 PM, wobbles wrote: What I ended up doing was creating an OutputRange that contains the files I want to write to. On OutputRange.put I simply print to print to all the files. Just like MultiFile example here: :) http://ddili.org/ders/d.en/ranges.html#ix_ranges.OutputRange Ali
ImplicitConversionTargets opposite
std.traits has ImplicitConversionTargets. Is there any template that returns the types that can implicty convert to T?
Re: Writing to two files at once
On Thursday, 21 May 2015 at 21:00:15 UTC, Cassio Butrico wrote: If I understand right you want to redirect the output to a file by a flag , another file type , video printer is it? I think by video printer you mean the console? If so, yes. I believe I've solved it anyway, see Ali and my answer above. Thanks!
Re: Dual conditions in D and Python
On 05/21/2015 12:44 PM, Meta wrote:
All we need is user-defined opIs and then we're really cooking with gas.
if (5 is between(4, 6))
{
//...
}
We're almost there. :)
bool is_between(T0, T1, T2)(T0 what, T1 min, T2 max)
{
return (what = min) (what = max);
}
void main()
{
if (5.is_between(4, 6)) {
// ...
}
}
Ali
Writing to two files at once
I would like to write to two files at once. If user specifies verbose flag, output should write to both stdout and the programs standard output file. Any ideas?
Re: Writing to two files at once
On Thursday, 21 May 2015 at 20:06:08 UTC, wobbles wrote: I would like to write to two files at once. If user specifies verbose flag, output should write to both stdout and the programs standard output file. Any ideas? I should add, I'm using a library that already writes it's output to a std.stdout.File that I can provide it, so my thinking is I need a std.stdout.File that points at both stdout and some arbitrary file location. Tricky I think...
Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 08:55:45 UTC, Saurabh Das wrote:
Thanks!
Wow, dustmite is really useful. It reduces the expression down
to:
double someFunction(double AvgPriceChangeNormalized, double
TicksTenMinutesNormalized)
{
return
(TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0;
}
Which gives a compiler error: Internal error: backend/cod1.c
1562
make that
double foo(double a, double b)
{
return (b ? 1 : a) ? 1 : b / (b == 0) == 0;
}
and please submit to https://issues.dlang.org
That expression is, not to put too fine a point on it, mad. The
operator precedence itself is giving me a headache, let alone the
division of a double by a boolean... I'm pretty sure it doesn't
do what you want it to, unless what you want is seriously weird.
As a matter of fact, i'm pretty sure that expression evaluates to
1, irrelevant of the values of the two variables.
Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 10:24:59 UTC, John Colvin wrote:
On Thursday, 21 May 2015 at 08:55:45 UTC, Saurabh Das wrote:
Thanks!
Wow, dustmite is really useful. It reduces the expression down
to:
double someFunction(double AvgPriceChangeNormalized, double
TicksTenMinutesNormalized)
{
return
(TicksTenMinutesNormalized?1:AvgPriceChangeNormalized)?1:TicksTenMinutesNormalized/(TicksTenMinutesNormalized==0)==0;
}
Which gives a compiler error: Internal error: backend/cod1.c
1562
make that
double foo(double a, double b)
{
return (b ? 1 : a) ? 1 : b / (b == 0) == 0;
}
and please submit to https://issues.dlang.org
That expression is, not to put too fine a point on it, mad. The
operator precedence itself is giving me a headache, let alone
the division of a double by a boolean... I'm pretty sure it
doesn't do what you want it to, unless what you want is
seriously weird.
As a matter of fact, i'm pretty sure that expression evaluates
to 1, irrelevant of the values of the two variables.
s/irrelevant/irrespective/
Re: deserialization: creating a class instance without calling constructor
On Thursday, 21 May 2015 at 09:06:59 UTC, Timothee Cour wrote:
Can I create an instance of A without calling a constructor?
(see below)
Use case: for generic deserialiaztion, when the deserialization
library
encounters a class without default constructor for example (it
knows what
the fields should be set to, but doesn't know how to construct
the object).
class A{
int x=2;
this(int x){
this.x=x;
}
}
This came up here:
https://github.com/msgpack/msgpack-d/issues/54#issuecomment-104136148
I provide some hacky solution for that in that thread but I
suspect it's
not safe and something is missing.
based on this:
https://github.com/D-Programming-Language/druntime/blob/6698ee21d4eb00ec2e8c621993359d235618df75/src/rt/lifetime.d#L71
you can create an instance without calling the constructor like
this:
---
CT construct(CT, A...)(A a)
if (is(CT == class))
{
auto memory = malloc(typeid(CT).init.length);
memory[0 .. typeid(CT).init.length] = typeid(CT).init[];
return cast(CT) memory;
}
---
actually it only copies the fields with their initial values.
Re: Template type deduction and specialization
On 5/21/15 10:15 AM, Daniel Kozák via Digitalmars-d-learn wrote:
import std.stdio;
void f(T:T*)(T* t)
{
writeln(before change this is not called);
}
void f(T)(T t)
{
writeln(before change this is called);
}
void main() {
int val;
f(val);
f!(int*)(val);
}
now it prints:
before change this is called
before change this is not called
but if we make change as you suggest this will be print:
before change this is not called
before change this is not called
Ugh, that was not what my reading of the docs seemed to suggest:
Function template type parameters that are to be implicitly deduced may
not have specializations
I misread that to mean *templates* that have specializations cannot be
used for IFTI. Now I see that the rule is talking not about templates
but *template type parameters*.
But the more I look at this, the more I think this is a bad code smell.
I can't see any logical reason to do something different with an
implicit deduction vs. an explicit call. Especially in the face of other
code that Can anyone come up a valid use case for this? Even one that is
a hack?
I'll note that if you replace the specialization with:
f(T : int *)(T t)
it calls the specialized version twice. Clearly, the rule is not
properly described or not properly implemented.
I would like to hear from Walter on this, what are the thoughts behind
this rule?
-Steve
Re: Template type deduction and specialization
On 5/21/15 9:14 AM, Daniel Kozak wrote: On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote: On Thu, 21 May 2015 08:54:54 -0400 Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote: On Wed, 20 May 2015 17:23:05 -0700 Ali Çehreli via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: 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 1.) we could fix just doc - easiest, but inconsistent Before doing this, we have to understand what works and what doesn't. It's not clear to me. 2.) remove implicit deduction even for fun(T:char)(T c) and all other specialization - code breakage so imho not good I don't think this is possible, this would break lots of existing code. 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2 I agree with this fix. I don't understand why specialization should disqualify IFTI. Can someone explain this rationale besides because the docs say so? But this will break more code than 2. So it is impossible to fix it. Not more, but it will be worst, because it could change behaviour of program without error message How so? My understanding is that it's illegal to call a function with specializations when IFTI is involved. This means code that currently doesn't compile, will compile. But what working code base has non-compiling code? I guess some __traits(compiles) calls would change, but I don't see the harm in this? You can call the function with an explicit instantiation, calling it with an implicit one isn't going to change the semantic meaning of the call. In other words, code that does this: foo(x); that doesn't compile, will start to compile as if you did: foo!(typeof(x))(x). How does this break code? And how does it break more code than 2? -Steve
Re: Internal Compiler Error Help
On Thu, 21 May 2015 11:36:14 +, Saurabh Das wrote:
PS: The original expression:
http://dpaste.dzfl.pl/raw/e7a66aa067ab
double someFunction(double AvgPriceChangeNormalized, double DayFactor,
double TicksTenMinutesNormalized)
{
return
AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*
(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*
(TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/
(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)
+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/
TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/
(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)
+(DayFactor)==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/
((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/
(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)
+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/
TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/
(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)
+(DayFactor)))*(TicksTenMinutesNormalized;
}
now i have to find a way to unsee it...
signature.asc
Description: PGP signature
Re: Internal Compiler Error Help
fair enough. I thought normally you'd want to have some sort of expression simplification in genetic programming, to avoid adding too many superfluous degrees of freedom? Aside from the obvious problems, those extra degrees of freedom can put you at risk of overfitting. Yes - our evaluation criteria gives bonus points for simpler expressions. We also strongly constrain the degrees of freedom. Both these aim to reduce overfitting. The expression seems rather complex because every division is protected by a equal to 0 check. Since our data sets are vast and number of features is kept low, overfitting is less of a concern. We do watch out for it though. In release builds, the compiler does the job of simplifying the expression, so we don't input a simplified expression a-priori. We are currently building this framework because earlier Java frameworks were deficient in speed. Already we have achieved a ~ 1000x speedup, so right now we are looking to consolidate and stabilise. In the next iteration, we could think of adding a simplify expression feature. Thanks, Saurabh
Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 11:36:15 UTC, Saurabh Das wrote:
PS: The original expression:
http://dpaste.dzfl.pl/raw/e7a66aa067ab
double someFunction(double AvgPriceChangeNormalized, double
DayFactor, double TicksTenMinutesNormalized)
{
return
AvgPriceChangeNormalized)*(0.0868))*((DayFactor)*(TicksTenMinutesNormalized)))*(((AvgPriceChangeNormalized)*(0.0868))*(TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)==0)?(1):(((TicksTenMinutesNormalized)+(-0.865))/((TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))==0)?(1):((TicksTenMinutesNormalized)/TicksTenMinutesNormalized)==0)?(1):((AvgPriceChangeNormalized)/(TicksTenMinutesNormalized)))-((TicksTenMinutesNormalized)+(DayFactor)))*(TicksTenMinutesNormalized;
}
fair enough. I thought normally you'd want to have some sort of
expression simplification in genetic programming, to avoid adding
too many superfluous degrees of freedom? Aside from the obvious
problems, those extra degrees of freedom can put you at risk of
overfitting.
Re: Internal Compiler Error Help
If you're looking for speed, how about ldc?
Re: Template type deduction and specialization
On Thu, 21 May 2015 09:58:16 -0400
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On 5/21/15 9:14 AM, Daniel Kozak wrote:
On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote:
On Thu, 21 May 2015 08:54:54 -0400
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
On Wed, 20 May 2015 17:23:05 -0700
Ali Çehreli via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
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
1.) we could fix just doc - easiest, but inconsistent
Before doing this, we have to understand what works and what
doesn't. It's not clear to me.
2.) remove implicit deduction even for fun(T:char)(T c) and
all other specialization - code breakage so imho not good
I don't think this is possible, this would break lots of existing
code.
3.) fix doc and allow even fun(T:T*)(T* p) - same as 2
I agree with this fix. I don't understand why specialization
should disqualify IFTI. Can someone explain this rationale
besides because the docs say so?
But this will break more code than 2. So it is impossible to fix
it.
Not more, but it will be worst, because it could change behaviour of
program without error message
How so? My understanding is that it's illegal to call a function with
specializations when IFTI is involved. This means code that currently
doesn't compile, will compile. But what working code base has
non-compiling code? I guess some __traits(compiles) calls would
change, but I don't see the harm in this? You can call the function
with an explicit instantiation, calling it with an implicit one isn't
going to change the semantic meaning of the call.
In other words, code that does this:
foo(x);
that doesn't compile, will start to compile as if you did:
foo!(typeof(x))(x).
How does this break code?
And how does it break more code than 2?
-Steve
import std.stdio;
void f(T:T*)(T* t)
{
writeln(before change this is not called);
}
void f(T)(T t)
{
writeln(before change this is called);
}
void main() {
int val;
f(val);
f!(int*)(val);
}
now it prints:
before change this is called
before change this is not called
but if we make change as you suggest this will be print:
before change this is not called
before change this is not called
Re: fwiw - quora on stroustrup/static if/D
On Thursday, 21 May 2015 at 23:28:32 UTC, weaselcat wrote: On Thursday, 21 May 2015 at 17:36:00 UTC, Laeeth Isharc wrote: https://www.quora.com/What-does-Bjarne-Stroustrup-think-about-different-programming-languages The C++ standard committee already reviewed static_if IIRC Andrei and Walter said they were being incredibly unfair. http://forum.dlang.org/thread/cdgzdesltjefjvnjb...@forum.dlang.org#post-cdgzdesltjefjvnjbspk:40forum.dlang.org pretty long thread on it if you want to dig through it. And I'll end my post with an excerpt from the ISOCPP paper, and IMO the reason C++ is the way it is: Being a new and realtively simple-to-use new feature, static_if would un- doubtedly be used by many who have no need for the relatively small increme- natal improvement in performance offered. I don't claim to be a language guru, but I couldn't make any sense of that 'considered' paper (static if) even when I squinted and looked at it funny. Fair maiden lives an exciting life in the big city, and only now decides to be more discerning? As a student of affect and its manifestation in language it seemed to make perfect sense though. http://www.sciencedirect.com/science/article/pii/B9780124160088000115 Still, I tried not to be too harsh, because it (C++) was in many ways an admirable achievement, and who am I to have the expertise to be sure. On the other hand, one cannot escape the need to form judgements, and I figured if I got it completely wrong then somebody would certainly put me right. Thanks for the link - will take a look. Laeeth.
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 23:14:47 UTC, Dennis Ritchie wrote:
On Thursday, 21 May 2015 at 21:35:22 UTC, Ali Çehreli wrote:
We're almost there. :)
bool is_between(T0, T1, T2)(T0 what, T1 min, T2 max)
{
return (what = min) (what = max);
}
void main()
{
if (5.is_between(4, 6)) {
// ...
}
}
Ali
A condition is that if, for example, that? :)
if (5 2 -9 -13 10 == 10 21 != 45):
print(OK)
this looks like gibberish upon first sight and is not something
I'd want to see in code I inherit.
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 21:35:22 UTC, Ali Çehreli wrote:
We're almost there. :)
bool is_between(T0, T1, T2)(T0 what, T1 min, T2 max)
{
return (what = min) (what = max);
}
void main()
{
if (5.is_between(4, 6)) {
// ...
}
}
Ali
A condition is that if, for example, that? :)
if (5 2 -9 -13 10 == 10 21 != 45):
print(OK)
-
http://rextester.com/JSC75231
import std.stdio;
void main()
{
if (5 2
2 -9
-9 -13
-13 10
10 == 10
10 21
21 != 45)
writeln(OK);
}
-
http://rextester.com/AZFL70044
Re: fwiw - quora on stroustrup/static if/D
On Thursday, 21 May 2015 at 17:36:00 UTC, Laeeth Isharc wrote: https://www.quora.com/What-does-Bjarne-Stroustrup-think-about-different-programming-languages The C++ standard committee already reviewed static_if IIRC Andrei and Walter said they were being incredibly unfair. http://forum.dlang.org/thread/cdgzdesltjefjvnjb...@forum.dlang.org#post-cdgzdesltjefjvnjbspk:40forum.dlang.org pretty long thread on it if you want to dig through it. And I'll end my post with an excerpt from the ISOCPP paper, and IMO the reason C++ is the way it is: Being a new and realtively simple-to-use new feature, static_if would un- doubtedly be used by many who have no need for the relatively small increme- natal improvement in performance offered.
Re: Python's features, which requires D
On Friday, 22 May 2015 at 00:23:30 UTC, Dennis Ritchie wrote: Hi, I've collected some of Python's features. It seems to me that they are not in the D! Surely all this is in the D? :) http://rextester.com/CNQQR D doesn't have list comprehensions, so it's difficult to directly port these. off the top of my head, the last one can easily be done with std.range.stride P.S. I think that all of this is written in D is much more lines of code! and they can be done in less with APL and J.
Re: Python's features, which requires D
On Friday, 22 May 2015 at 01:17:17 UTC, weaselcat wrote:
D doesn't have list comprehensions, so it's difficult to
directly port these.
I can not imagine how difficult it is to implement it in D, but
I'm pretty sure that nested for loops to fill arrays (in D, you
can call them differently, for example, force :)) will be very
useful thing, because Python is a veryIt is often used.
Besides, I do not understand what could be the problem with
nested loops in arrays, because std.algorithm.map works on the
principle of nested loops. I think that the biggest problem in
the implementation of this should not be. Excuse me if I'm wrong.
off the top of my head, the last one can easily be done with
std.range.stride
import std.stdio, std.range;
void main()
{
int[] a = [ 1, 2, 3, 4, 5, 6 ];
writeln(stride(a, 2)); // [1, 3, 5] #odd #print(x[::2]) #OK
// [2, 4, 6] #even #print(x[1::2]) #no equivalent in D
auto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ];
// [2, 6, 10] #print(x[1::4]) #no equivalent in D
}
Re: Python's features, which requires D
On Friday, 22 May 2015 at 01:52:30 UTC, Dennis Ritchie wrote:
On Friday, 22 May 2015 at 01:17:17 UTC, weaselcat wrote:
D doesn't have list comprehensions, so it's difficult to
directly port these.
I can not imagine how difficult it is to implement it in D, but
I'm pretty sure that nested for loops to fill arrays (in D, you
can call them differently, for example, force :)) will be very
useful thing, because Python is a veryIt is often used.
Besides, I do not understand what could be the problem with
nested loops in arrays, because std.algorithm.map works on the
principle of nested loops. I think that the biggest problem in
the implementation of this should not be. Excuse me if I'm
wrong.
off the top of my head, the last one can easily be done with
std.range.stride
import std.stdio, std.range;
void main()
{
int[] a = [ 1, 2, 3, 4, 5, 6 ];
writeln(stride(a, 2)); // [1, 3, 5] #odd #print(x[::2]) #OK
// [2, 4, 6] #even #print(x[1::2]) #no equivalent in D
writeln(stride(a[1..$], 2));
auto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ];
// [2, 6, 10] #print(x[1::4]) #no equivalent in D
writeln(stride(a[1..$], 4));
}
Re: Python's features, which requires D
On Friday, 22 May 2015 at 02:18:23 UTC, weaselcat wrote:
On Friday, 22 May 2015 at 01:52:30 UTC, Dennis Ritchie wrote:
off the top of my head, the last one can easily be done with
std.range.stride
import std.stdio, std.range;
void main()
{
int[] a = [ 1, 2, 3, 4, 5, 6 ];
writeln(stride(a, 2)); // [1, 3, 5] #odd #print(x[::2]) #OK
// [2, 4, 6] #even #print(x[1::2]) #no equivalent in D
writeln(stride(a[1..$], 2));
auto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ];
// [2, 6, 10] #print(x[1::4]) #no equivalent in D
writeln(stride(a[1..$], 4));
}
Yes, this is what you need (I often forget that the functions can
take ranges in D).
Maybe somewhere and nested loops for to fill the arrays lying
around :)
Python's features, which requires D
Hi, I've collected some of Python's features. It seems to me that they are not in the D! Surely all this is in the D? :) http://rextester.com/CNQQR
Re: Python's features, which requires D
On 05/21/2015 05:23 PM, Dennis Ritchie wrote:
Hi,
I've collected some of Python's features. It seems to me that they are
not in the D!
Surely all this is in the D? :)
http://rextester.com/CNQQR
Here is my attempt:
import std.stdio;
import std.algorithm;
import std.conv;
import std.range;
void main()
{
// Replace 'none' with 'all' to activate.
version (none) {
const n = 5;
auto a = stdin
.byLine
.map!(l = l.splitter.map!(to!int).array)
.take(n);
writeln(a);
writeln(-);
}
{
const n = 6;
auto a = iota(n)
.map!(i = chain([2].replicate(i),
[1],
[0].replicate(n - i - 1)));
writefln(%(%(%s %)\n%), a);
writeln(-);
}
{
const x = [ 1, 2, 3, 4, 5, 6 ];
writeln(x.stride(2));
writeln(x.dropOne.stride(2));
writeln(-);
}
{
// The internet does not need another fizz buzz. :p
}
}
Ali
Re: opIndex vs. opSlice for empty slices
On Friday, 22 May 2015 at 05:47:28 UTC, Mike Parker wrote: I've always used opSlice to produce empty slices, but having recently read the documentation at [1], I see this: To overload a[], simply define opIndex with no parameters: And no mention that opSlice can fill the same role. Am I right to infer that we should prefer opIndex over opSlice for this? If so, what's the rationale? [1] http://dlang.org/operatoroverloading.html#slice http://forum.dlang.org/thread/luadir$t0g$1...@digitalmars.com#post-luadir:24t0g:241:40digitalmars.com
opIndex vs. opSlice for empty slices
I've always used opSlice to produce empty slices, but having recently read the documentation at [1], I see this: To overload a[], simply define opIndex with no parameters: And no mention that opSlice can fill the same role. Am I right to infer that we should prefer opIndex over opSlice for this? If so, what's the rationale? [1] http://dlang.org/operatoroverloading.html#slice
Re: Dual conditions in D and Python
On 5/21/15 12:57 PM, Dennis Ritchie wrote:
Hi,
In Python I can write this:
if (4 = 5 = 6):
print (OK)
-
http://rextester.com/NNAM70713
In D, I can only write this:
import std.stdio;
void main() {
if (4 = 5 5 = 6)
puts(OK);
}
-
http://rextester.com/FICP83173
I wanted to ask what is the reason? Maybe the program on Python's slower
because of this? Or legacy C/C++ affected D?
There is this possibility:
switch(5){
case 4: .. case 6:
}
You could also make some nifty abuse-of-syntax types:
struct Between(T)
{
T low;
T high;
bool opBinaryRight!(op : in)(T val) { return val = low val =
high;}
}
auto between(T)(T low, T high) { return Between!T(low, high); }
if(5 in between(4, 6))
:)
-Steve
Re: deserialization: creating a class instance without calling constructor
On 2015-05-21 11:06, Timothee Cour via Digitalmars-d-learn wrote:
Can I create an instance of A without calling a constructor? (see below)
Use case: for generic deserialiaztion, when the deserialization library
encounters a class without default constructor for example (it knows
what the fields should be set to, but doesn't know how to construct the
object).
class A{
int x=2;
this(int x){
this.x=x;
}
}
This came up here:
https://github.com/msgpack/msgpack-d/issues/54#issuecomment-104136148
I provide some hacky solution for that in that thread but I suspect it's
not safe and something is missing.
Here's how I do it in my serialization library Orange [1]
[1]
https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L166
--
/Jacob Carlborg
Re: Dual conditions in D and Python
Something I sometimes do for strictly personal projects:
import std.typecons : ω = tuple;
import std.typetuple : Ω = TypeTuple;
void main()
{
auto a = 1, b = 2;
Ω!(a, b) = ω(b, a);
assert(a==2 b==1);
}
On Thursday, 21 May 2015 at 19:05:16 UTC, Steven Schveighoffer
wrote:
On 5/21/15 12:57 PM, Dennis Ritchie wrote:
Hi,
In Python I can write this:
if (4 = 5 = 6):
print (OK)
-
http://rextester.com/NNAM70713
In D, I can only write this:
import std.stdio;
void main() {
if (4 = 5 5 = 6)
puts(OK);
}
-
http://rextester.com/FICP83173
I wanted to ask what is the reason? Maybe the program on
Python's slower
because of this? Or legacy C/C++ affected D?
There is this possibility:
switch(5){
case 4: .. case 6:
}
You could also make some nifty abuse-of-syntax types:
struct Between(T)
{
T low;
T high;
bool opBinaryRight!(op : in)(T val) { return val = low
val = high;}
}
auto between(T)(T low, T high) { return Between!T(low, high); }
if(5 in between(4, 6))
:)
-Steve
All this, of course, looks good, but what about the principle of
the ideal programming language :)
In the end I want to focus on one philosophical principle, which
lies at the basis of my ideas about the ideal programming
language. Typically, during the discussion in the forums, when
you start to talk in a language that is not X features Y, be sure
there is someone who will say: Why, that's if you take the
features A, B and C, and screw them crutches D, E, F, then we
will get almost Y. Yes, it is. But I do not like this approach.
One can imagine that such programmers want some complicated way
through the maze. You can go through the maze, but the way the
curve and non-obvious. I also want to be instead of the labyrinth
has a large area, on which from any point to any other one would
go in a straight line. Just a straight line.
-
The quotation is taken from the article:
http://habrahabr.ru/post/257875/
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 19:05:16 UTC, Steven Schveighoffer
wrote:
On 5/21/15 12:57 PM, Dennis Ritchie wrote:
Hi,
In Python I can write this:
if (4 = 5 = 6):
print (OK)
-
http://rextester.com/NNAM70713
In D, I can only write this:
import std.stdio;
void main() {
if (4 = 5 5 = 6)
puts(OK);
}
-
http://rextester.com/FICP83173
I wanted to ask what is the reason? Maybe the program on
Python's slower
because of this? Or legacy C/C++ affected D?
There is this possibility:
switch(5){
case 4: .. case 6:
}
You could also make some nifty abuse-of-syntax types:
struct Between(T)
{
T low;
T high;
bool opBinaryRight!(op : in)(T val) { return val = low
val = high;}
}
auto between(T)(T low, T high) { return Between!T(low, high); }
if(5 in between(4, 6))
:)
-Steve
All we need is user-defined opIs and then we're really cooking
with gas.
if (5 is between(4, 6))
{
//...
}
Dual conditions in D and Python
Hi,
In Python I can write this:
if (4 = 5 = 6):
print (OK)
-
http://rextester.com/NNAM70713
In D, I can only write this:
import std.stdio;
void main() {
if (4 = 5 5 = 6)
puts(OK);
}
-
http://rextester.com/FICP83173
I wanted to ask what is the reason? Maybe the program on Python's
slower because of this? Or legacy C/C++ affected D?
Re: Using arrays of function pointers in D
Start with a function type declaration: void function() func_ptr; Then make an array out of it: void function()[] func_ptr_array; It works like other arrays, just the [] might be a little harder to see since it is a much longer type signature. But it is still in there, right after it, similarly to int[]. Then the array is indexed and set like normal. You can change length on it (auto initializes all members to null), ~= my_func to append, etc. You can also do associative arrays of function pointers btw.
Re: Internal Compiler Error Help
On Thursday, 21 May 2015 at 14:12:25 UTC, Kagamin wrote: If you're looking for speed, how about ldc? Absolutely - we are working on getting it to compile on ldc and/or gdc.
Using arrays of function pointers in D
I've been rewriting one of my emulators in D and am fairly new to the language. I'm having trouble finding documentation on creating/initializing/use of arrays of function pointers in D. If anyone has a code example I'd appreciate it!
Re: Using arrays of function pointers in D
On Thursday, 21 May 2015 at 16:25:24 UTC, Adam D. Ruppe wrote: Start with a function type declaration: void function() func_ptr; Then make an array out of it: void function()[] func_ptr_array; It works like other arrays, just the [] might be a little harder to see since it is a much longer type signature. But it is still in there, right after it, similarly to int[]. Then the array is indexed and set like normal. You can change length on it (auto initializes all members to null), ~= my_func to append, etc. You can also do associative arrays of function pointers btw. Thanks! Holy moly you guys are quick in here.
Re: Using arrays of function pointers in D
On Thursday, 21 May 2015 at 16:23:15 UTC, John wrote:
I've been rewriting one of my emulators in D and am fairly new
to the language. I'm having trouble finding documentation on
creating/initializing/use of arrays of function pointers in D.
If anyone has a code example I'd appreciate it!
float foo(int a, float b)
{
import std.stdio;
writeln(a, b);
return a+b;
}
void main()
{
float function(int, float)[] arrayOfFPs;
arrayOfFPs = new float function(int, float)[42];
arrayOfFPs[0] = foo;
auto r = arrayOfFPs[0](3, 7.6);
assert(r == 3+7.6f);
alias DT = int delegate(int);
int a = 4;
auto arrayOfDelegates = new DT[3];
arrayOfDelegates[1] = (int x) = a + x;
assert(arrayOfDelegates[1](3) == 7);
}
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 16:57:16 UTC, Dennis Ritchie wrote:
Hi,
In Python I can write this:
if (4 = 5 = 6):
print (OK)
-
http://rextester.com/NNAM70713
In D, I can only write this:
import std.stdio;
void main() {
if (4 = 5 5 = 6)
puts(OK);
}
-
http://rextester.com/FICP83173
I wanted to ask what is the reason? Maybe the program on
Python's slower because of this? Or legacy C/C++ affected D?
http://wiki.dlang.org/Language_Designs_Explained#Why_does_D_not_support_chaining_comparison_operators.3F
fwiw - quora on stroustrup/static if/D
https://www.quora.com/What-does-Bjarne-Stroustrup-think-about-different-programming-languages
Re: Dual conditions in D and Python
On Thursday, 21 May 2015 at 17:17:29 UTC, Alex Parrill wrote: http://wiki.dlang.org/Language_Designs_Explained#Why_does_D_not_support_chaining_comparison_operators.3F Backward compatibility with C is nice but on the other hand it is a road to nowhere! Because of this compatibility, I'm compelled to write return instead of ret and else if instead of elif :) I think to create a truly correct C++, it was necessary to completely abandon the backward compatibility with C.
