Oh, just found out, it seems that currently the extern C
declarations don't work. This comes from the original Chocolat
range.d
extern (C) {
nothrow:
NSRange NSUnionRange(NSRange range1, NSRange range2) ;
NSRange NSIntersectionRange(NSRange range1, NSRange
On 2014-11-06 17:06, Christian Schneider wrote:
Oh, just found out, it seems that currently the extern C declarations
don't work. This comes from the original Chocolat range.d
extern (C) {
nothrow:
NSRange NSUnionRange(NSRange range1, NSRange range2) ;
NSRange
I have been working on a media library, it still has a long way
to go, but I figured its about time I shared what I am doing.
https://github.com/luminousone/dmedia
If I could possibly convince a few people out their to give'er a
once over.
I use XCB/XLIB/GLX directly, so I am not just
On 7/11/2014 6:56 p.m., luminousone wrote:
I have been working on a media library, it still has a long way to go,
but I figured its about time I shared what I am doing.
https://github.com/luminousone/dmedia
If I could possibly convince a few people out their to give'er a once over.
I use
On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole
wrote:
On 7/11/2014 6:56 p.m., luminousone wrote:
I have been working on a media library, it still has a long
way to go,
but I figured its about time I shared what I am doing.
https://github.com/luminousone/dmedia
If I could
On 7/11/2014 7:38 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote:
On 7/11/2014 6:56 p.m., luminousone wrote:
I have been working on a media library, it still has a long way to go,
but I figured its about time I shared what I am doing.
On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole
wrote:
On 7/11/2014 7:38 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole
wrote:
On 7/11/2014 6:56 p.m., luminousone wrote:
I have been working on a media library, it still has a long
way to go,
On 7/11/2014 7:58 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote:
On 7/11/2014 7:38 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole wrote:
On 7/11/2014 6:56 p.m., luminousone wrote:
I have been working on a
On Friday, 7 November 2014 at 07:08:02 UTC, Rikki Cattermole
wrote:
On 7/11/2014 7:58 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole
wrote:
On 7/11/2014 7:38 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:29:14 UTC, Rikki Cattermole
wrote:
On
On 7/11/2014 8:22 p.m., luminousone wrote:
On Friday, 7 November 2014 at 07:08:02 UTC, Rikki Cattermole wrote:
On 7/11/2014 7:58 p.m., luminousone wrote:
On Friday, 7 November 2014 at 06:42:24 UTC, Rikki Cattermole wrote:
On 7/11/2014 7:38 p.m., luminousone wrote:
On Friday, 7 November 2014
On Thursday, 6 November 2014 at 00:50:23 UTC, bearophile wrote:
I think not giving language support means that D designers
don't want it to be easy to do. And this is good.
Then why are they adding multiple alias this, which appears to be
worse?
Hi,
First, I'd like to point out this question is better asked in
DerelictBgfx issues or digitalmars.D.learn, this NG is for
general D discussion.
On Thursday, 6 November 2014 at 06:44:49 UTC, olivier henley
wrote:
Hi,
May I ask what is the rational to not ship the core libs with
the
On Thursday, 6 November 2014 at 08:30:22 UTC, Ola Fosheim Grøstad
wrote:
1. On amd64 you designate one caller save SIMD register to
error propagation.
I meant callee save. It is saved by the called function if it
does not return an error.
It has been argued that exceptions are too slow in D to propagate
regular errors and should just be used for the truly exceptional
case. Then there should be a faster, but equally convenient
alternative for regular errors.
In Go you solve the problem by returning tuples:
Ola Fosheim Grøstad:
Then why are they adding multiple alias this, which appears to
be worse?
The multiple alias this is being designed right now. If you don't
like the complexities it introduces, then it's a good moment to
express your concerns in that thread (I plan to not use multiple
On Thursday, 6 November 2014 at 08:38:53 UTC, bearophile wrote:
Ola Fosheim Grøstad:
Then why are they adding multiple alias this, which appears to
be worse?
The multiple alias this is being designed right now. If you
don't like the complexities it introduces, then it's a good
moment to
Ola Fosheim Grøstad:
I think D should either try to support programming in the large
or stop claiming that D aims to stop programming in the large
while not being willing to make the feature set suitable.
Think of C++17/D2 as testbed entities that contain most features,
to test what works
On Wednesday, 5 November 2014 at 21:29:20 UTC, Marc Schütz wrote:
Again untested:
private alias makePredicate(alias xtr) =
(a, b) = (extractorFun!xtr(a) extractorFun!xtr(b));
This errors as
sort_ex.d(35,43): Error: basic type expected, not (
sort_ex.d(35,43): Error: function declaration
On Thursday, 6 November 2014 at 08:30:22 UTC, Ola Fosheim Grøstad
wrote:
It has been argued that exceptions are too slow in D to
propagate regular errors and should just be used for the truly
exceptional case. Then there should be a faster, but equally
convenient alternative for regular
On Thursday, 6 November 2014 at 09:03:02 UTC, bearophile wrote:
Think of C++17/D2 as testbed entities that contain most
features, to test what works and what doesn't work, to create
successive languages that contain only the useful features :-)
:-) Yes, I view D2 as an experiment. And I view
If a function named write fails to write, it should throw an
exception. So what about functions that want to return error
codes instead. What I do is prefix the function with try.
You don't have to do that, but it helps me personally keep
track of what functions require explicit error
On Thursday, 6 November 2014 at 09:17:55 UTC, Jonathan Marler
wrote:
First, D has the capability to generate code that uses error
codes via registers or some global variable (note: I wouldn't
specify that a compiler should use a certain register for error
codes, the compiler is smart and will
On Thursday, 6 November 2014 at 09:13:07 UTC, Nordlöw wrote:
On Wednesday, 5 November 2014 at 21:29:20 UTC, Marc Schütz
wrote:
Again untested:
private alias makePredicate(alias xtr) =
(a, b) = (extractorFun!xtr(a) extractorFun!xtr(b));
This errors as
sort_ex.d(35,43): Error: basic type
On Wednesday, 5 November 2014 at 03:31:47 UTC, Joakim wrote:
On Tuesday, 4 November 2014 at 23:45:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Nov 04, 2014 at 11:32:34PM +, tcak via
Digitalmars-d wrote:
Generally, to compile druntime from git HEAD requires that you
use dmd
from
On Wednesday, 5 November 2014 at 03:31:47 UTC, Joakim wrote:
On Tuesday, 4 November 2014 at 23:45:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Nov 04, 2014 at 11:32:34PM +, tcak via
Digitalmars-d wrote:
Generally, to compile druntime from git HEAD requires that you
use dmd
from
On Thursday, 6 November 2014 at 09:36:38 UTC, Nemanja Boric wrote:
Maybe you could consider something like returning `ResultOk,
Err` (like in Rust) which will make you not forget to check
for return code.
Yes, but that is too syntax heavy. I want a language builtin that
is non-intrusive.
On 11/6/2014 3:44 PM, olivier henley wrote:
Hi,
May I ask what is the rational to not ship the core libs with the bgfx D
wrapper? From my point of view it defies the main goal of using a D
wrapper.
First, let's get some terminology straight. There are no wrappers in
Derelict. The Derelict
On 06/11/2014 01:36, Shammah Chancellor wrote:
Is this fixed now?
How about:
alias compiles(alias expr) = __traits(compiles, expr);
I guess supporting that may be problematic (it's too liberal), so I
think we should have __compiles(expr) instead. It looks like a small
saving, but in
On 11/4/14 4:48 PM, Walter Bright wrote:
On 11/4/2014 9:51 AM, Jonathan Marler wrote:
given the
output of Transform, the compiler cannot deduce what the input of
Transform was
EVEN IF THE TEMPLATE IS AS SIMPLE AS THIS ONE.
To answer a question not asked, why doesn't the compiler see the
Shriramana Sharma via Digitalmars-d wrote in message
news:mailman.1515.1415110123.9932.digitalmar...@puremagic.com...
So I'm using latest dmd 2.066.1 on an i386 machine. Does it have the
latest functionality which you refer to? And what is the syntax to
support static and non-virtual member
Steven Schveighoffer wrote in message
news:m3bap5$khl$1...@digitalmars.com...
https://issues.dlang.org/show_bug.cgi?id=1807
Hm.. interesting to note that Martin's suggestion has come to fruition,
might this be revisited?
Not really, templated aliases behave exactly the same as aliases in
On Thursday, 6 November 2014 at 08:04:33 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 November 2014 at 00:50:23 UTC, bearophile wrote:
I think not giving language support means that D designers
don't want it to be easy to do. And this is good.
Then why are they adding multiple alias this,
On Thursday, 6 November 2014 at 15:25:11 UTC, Patrick Jeeves
wrote:
I don't really see how multiple alias this is better or worse
than multiple inheritance.
It is worse because:
1. When you design a class hierarchy with multiple inheritance
you don't reuse something made for another purpose,
On Thursday, 6 November 2014 at 08:17:24 UTC, ponce wrote:
Hi,
First, I'd like to point out this question is better asked in
DerelictBgfx issues or digitalmars.D.learn, this NG is for
general D discussion.
Not agree. DerelictBgfx is one of the most interesting project D
has to show off and
On 04/11/2014 14:18, Johannes Pfau wrote:
And as long as there is no other solution warnings are better than
simply ignoring the problem.
+1
But I think it's likely this check will be implemented in
Dscanner (https://github.com/Hackerpilot/Dscanner/issues/204) and
in the end it doesn't
On 04/11/2014 02:00, Walter Bright wrote:
You are glossing over and dismissing the problems with explicit casts,
and the problems with overloading, etc.
Can't solving any overloading problem be deferred? An incomplete
solution is better than nothing.
As for explicit casts, they are easily
On Thursday, 6 November 2014 at 16:36:41 UTC, olivier henley
wrote:
First, I'd like to point out this question is better asked in
DerelictBgfx issues or digitalmars.D.learn, this NG is for
general D discussion.
Not agree. DerelictBgfx is one of the most interesting project
D has to show off
On Thursday, 6 November 2014 at 12:31:32 UTC, Mike Parker wrote:
First, let's get some terminology straight. There are no
wrappers in Derelict. The Derelict packages are all
bindings, meaning they are one-to-one translations (as much
as possible) of the original library. A wrapper is
On Thu, Nov 6, 2014 at 1:17 AM, Jonathan Marler via Digitalmars-d
digitalmars-d@puremagic.com wrote:
One thing I like about your suggestion is you can specify if a function's
error code should be verified to be handled at compile time. It would be
nice as a library writer if you could
On Thursday, 6 November 2014 at 17:23:21 UTC, ponce wrote:
There were PR since to update to latest API so these binaries
would be outdated already.
This would be easier if bgfx had numbered releases and its API
changed less.
What you _can_ do now is check the date where the API was last
I think there is a misunderstanding: bgfx _examples_ are kind
of cool, but they were only ported for basic testing of the
bindings, and maybe should be removed now to avoid rot.
I just don't see the point to not share the most common target
dependencies libs. Therefore the examples can run out of the
box for most people and some super cool project can be show
cased for D rapidly. This leads to hooking. That's it that's
all and this is the key.
Common libraries
On Thursday, 6 November 2014 at 19:35:27 UTC, olivier henley
wrote:
On Thursday, 6 November 2014 at 17:23:21 UTC, ponce wrote:
There were PR since to update to latest API so these binaries
would be outdated already.
This would be easier if bgfx had numbered releases and its API
changed
I don't think we should have a language construct for that. It is
possible to pack the returned value in a struct that enforce
error checking. Exception is fine for procedure if they can't do
their job. tryDo as explained before in this thread is also a
common convention to indicate that you'll
On 11/6/2014 9:16 AM, Nick Treleaven wrote:
On 04/11/2014 02:00, Walter Bright wrote:
You are glossing over and dismissing the problems with explicit casts,
and the problems with overloading, etc.
Can't solving any overloading problem be deferred? An incomplete solution is
better than
On Thursday, 6 November 2014 at 20:06:55 UTC, deadalnix wrote:
I don't think we should have a language construct for that. It
is
possible to pack the returned value in a struct that enforce
error checking.
How?
Please note that inconvenient is not an option since people then
will end up
On Thursday, 6 November 2014 at 19:18:14 UTC, Jeremy Powers via
Digitalmars-d wrote:
This is why checked exceptions were invented.
Yeah, I agree. Main reasons for classical exception handling:
1. Get error handling directly to a level where it can be handled
to prevent propagating clutter in
On Thursday, 6 November 2014 at 20:58:02 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 November 2014 at 20:06:55 UTC, deadalnix wrote:
I don't think we should have a language construct for that. It
is
possible to pack the returned value in a struct that enforce
error checking.
How?
The
On Thursday, 6 November 2014 at 19:18:14 UTC, Jeremy Powers via
Digitalmars-d wrote:
On Thu, Nov 6, 2014 at 1:17 AM, Jonathan Marler via
suggestion than checked exceptions though...
I think the worst thing about exceptions is the syntax
deformation introduced by all the try/catch blocks.
On Thursday, 6 November 2014 at 21:13:53 UTC, eles wrote:
The most similar thing that I can think about is Boost Optional.
Yes, that is kind of like Rust's std::result or Haskell's Maybe,
but it does not support delaying the handling like you do in
OpenGL.
What is desirable is that you are
On Thursday, 6 November 2014 at 20:08:24 UTC, ponce wrote:
I can see how this is useful for Windows programmers but would
strongly prefer to be completely separated from the bindings,
in some kind of FTP/HTTP server. There would be a link in the
README.md and you would upload builds there
On Thursday, 6 November 2014 at 15:25:11 UTC, Patrick Jeeves
wrote:
On Thursday, 6 November 2014 at 08:04:33 UTC, Ola Fosheim
Grøstad
wrote:
On Thursday, 6 November 2014 at 00:50:23 UTC, bearophile wrote:
I think not giving language support means that D designers
don't want it to be easy to
Something a little better than Boost's Optional:
ExpectedT
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
On Thursday, 6 November 2014 at 21:56:39 UTC, deadalnix wrote:
In the other hand, alias this (or prototypal inheritance model
in
general) do not suffer from these issues. It also have some good
use case like entity framework.
I'm curious as to how prototypical inheritance avoids the diamond
On Thursday, 6 November 2014 at 21:55:42 UTC, ZombineDev wrote:
Something a little better than Boost's Optional:
ExpectedT
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
If you have exceptions maybe, but not good enough.
And none
So today, I was playing around with profiling and optimizing my sliding
block puzzle solver, and found some interesting things:
1) The GC could use some serious improvement: it just so happens that
the solver's algorithm only ever needs to allocate memory, never release
it (it keeps a hash of
On Thu, Nov 06, 2014 at 02:58:16PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
auto ptr = current.ptr;
auto c = current.length;
while (c 0 *ptr != m.id)
ptr++;
cert.headOffset = ptr - current.ptr;
This pushed gdc far
On 11/6/2014 2:58 PM, H. S. Teoh via Digitalmars-d wrote:
2) Auto-decoding is evil: the solver currently uses a naïve char[]
representation for the puzzle board, and uses countUntil() extensively
to locate things on the board. The original code had:
auto offset =
On 11/6/2014 3:13 PM, H. S. Teoh via Digitalmars-d wrote:
mouth.open(); mouth.insert(foot);
Now you've done it. You must pull the Stone of Shame!
https://pbs.twimg.com/media/BrENFq3CMAEqFUL.jpg
On Thursday, 6 November 2014 at 23:00:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
So today, I was playing around with profiling and optimizing my
sliding
block puzzle solver, and found some interesting things:
1) The GC could use some serious improvement: it just so
happens that
the solver's
On Thursday, 6 November 2014 at 21:22:27 UTC, olivier henley
wrote:
I did not know for the Debian policy concerning dynamic libs.
Also, shipping binary builds for Linux without any further
qualification is quite the headache anyway. Typically, you have
to use some really old distro to avoid
It strikes me that the core question here may be one of the
division of labour. The person best suited to signing up for an
ongoing commitment to maintain a whole load of different
libraries across platforms/settings will only by the chancest
fluke be the person who is suited to and enjoys
On Thu, Nov 06, 2014 at 03:15:04PM -0800, Walter Bright via Digitalmars-d wrote:
On 11/6/2014 2:58 PM, H. S. Teoh via Digitalmars-d wrote:
2) Auto-decoding is evil: the solver currently uses a naïve char[]
representation for the puzzle board, and uses countUntil()
extensively to locate things
On Thursday, 6 November 2014 at 23:30:56 UTC, Walter Bright wrote:
On 11/6/2014 3:13 PM, H. S. Teoh via Digitalmars-d wrote:
mouth.open(); mouth.insert(foot);
Now you've done it. You must pull the Stone of Shame!
https://pbs.twimg.com/media/BrENFq3CMAEqFUL.jpg
The Shame Cube is far
On Thu, Nov 06, 2014 at 02:58:16PM -0800, H. S. Teoh via Digitalmars-d wrote:
So today, I was playing around with profiling and optimizing my sliding
block puzzle solver, and found some interesting things:
[...]
Oh, I forgot to mention something else that might be of interest to
people: in the
On Thursday, 6 November 2014 at 22:15:25 UTC, Meta wrote:
On Thursday, 6 November 2014 at 21:56:39 UTC, deadalnix wrote:
In the other hand, alias this (or prototypal inheritance model
in
general) do not suffer from these issues. It also have some
good
use case like entity framework.
I'm
On Thursday, 6 November 2014 at 20:58:02 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 November 2014 at 20:06:55 UTC, deadalnix wrote:
I don't think we should have a language construct for that. It
is
possible to pack the returned value in a struct that enforce
error checking.
How?
On Monday, 27 October 2014 at 02:33:18 UTC, Tofu Ninja wrote:
I don't think this is a new idea but it would be pretty awesome.
So the idea is that the compiler could check dub for libraries
that it can't find and automatically download and integrate
them. It would essentially make all of dub
On Thursday, 6 November 2014 at 19:12:37 UTC, olivier henley
wrote:
1. Windows is a good start.
2. Nobody said you had to provide all of them.
3. We can help. Just myself, I could provide Linux and Windows.
It makes for about 80% of all computers in the world.
If you would like to compile
On Thu, Nov 06, 2014 at 02:58:16PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
1) The GC could use some serious improvement: it just so happens that
the solver's algorithm only ever needs to allocate memory, never
release it (it keeps a hash of visited states that only grows, never
On Friday, 7 November 2014 at 03:28:45 UTC, deadalnix wrote:
Because the base object and delegated object are different
one, not the same being polymorphic.
That does not resolve conflicts with having the same base
prototype or name conflicts in method names. Ignoring the issues
does not
On Friday, 7 November 2014 at 07:12:58 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 7 November 2014 at 03:28:45 UTC, deadalnix wrote:
Because the base object and delegated object are different
one, not the same being polymorphic.
That does not resolve conflicts with having the same base
On Wednesday, 5 November 2014 at 13:34:05 UTC, Marc Schütz wrote:
On Wednesday, 5 November 2014 at 12:54:03 UTC, Ivan Kazmenko
wrote:
Hi!
This gives an error (cannot deduce template function from
argument types):
-
import std.algorithm;
void main () {
char [] c;
sort
On Wednesday, 5 November 2014 at 17:45:00 UTC, luminousone wrote:
abstract class foo {
static DList!foo foo_list;
~this(){ foo_list.remove(this); }
One note: when your program exits the runtime does a final GC
cycle and collects those things calling destructors/finalizers,
however
Misu:
void main(string[] args)
{
class Account
{
public this(int id) { this.id = id; }
int id;
}
...
This is not an answer to your question, but note:
void main() {
class Foo {}
static class Bar {}
pragma(msg,
On 2014-10-26 14:25, Etienne Cimon wrote:
On 2014-10-25 23:31, H. S. Teoh via Digitalmars-d-learn wrote:
Hmm. You can probably use __traits(getAllMembers...) to introspect a
library module at compile-time and build a hash based on that, so that
it's completely automated. If you have this
On Thursday, 6 November 2014 at 10:53:32 UTC, Misu wrote:
Hi,
when I execute this code I have 7 7 7 as result, I think I
understand why.
How can I execute a special task for one element ?
import std.stdio;
import std.parallelism;
void main(string[] args)
{
class Account
{
Hi ppl! I want to scan the local network to find nodes with open
80 port.
code:
import core.thread, core.atomic;
import std.stdio, std.system, std.file, std.conv, std.datetime,
std.socket, std.socketstream, std.stream;
import vibe.core.log;
import vibe.d;
void main()
{
ushort port =
Or the program doesn't find the address after IP 192.168.110.34...
On Thursday, 6 November 2014 at 10:52:32 UTC, Ivan Kazmenko wrote:
On Wednesday, 5 November 2014 at 13:34:05 UTC, Marc Schütz
wrote:
On Wednesday, 5 November 2014 at 12:54:03 UTC, Ivan Kazmenko
wrote:
Hi!
This gives an error (cannot deduce template function from
argument types):
-
On 11/5/14 10:48 PM, Dmitriy wrote:
Hello, I'm in the middle of learning D. I can't find any definitive
information about what is the complexity of operator ~= when used for
adding an element to an array. Is it amortized O(1) or is it
implementation defined? (I hope it at worst O(n) though I
On 11/5/14 2:05 PM, Patrick Jeeves wrote:
On Wednesday, 5 November 2014 at 18:56:08 UTC, luminousone wrote:
unless delete is explicitly called, I don't believe the destructor
would ever be called, it would still have a reference in the static
foo_list object that would stop it from being
On 11/5/14 7:54 AM, Ivan Kazmenko wrote:
Hi!
This gives an error (cannot deduce template function from argument types):
-
import std.algorithm;
void main () {
char [] c;
sort (c);
}
-
Why is char [] so special that it can't be sorted?
Because sort works on ranges, and
On 11/05/2014 11:02 PM, Suliman wrote:
Replace that with something like writeln(caught) and you will see
that it is indeed caught. :) Printing the exception mimicks the
default behavior and you (and I) think that the exception is not
caught. :)
that's work, but I can not understand where I can
I have rectangular forward range of forward ranges (not arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward range:
[
a11 + a21 + ... aM1,
a12 + a22 + ... aM2,
...
a1N + a2N + ... aMN
]
Range of sum elements of every columns;
M, N -
We have to look at the documentation of the function. In this
case the possibilities are FileException and UTFException.
http://dlang.org/phobos/std_file.html#.readText
However, judging by their names, they are both descendants of
Exception, so what you are doing will catch either of them.
On Thursday, 6 November 2014 at 15:53:27 UTC, Jack Applegame
wrote:
I have rectangular forward range of forward ranges (not arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward range:
[
a11 + a21 + ... aM1,
a12 + a22 + ... aM2,
...
a1N +
On Thu, 06 Nov 2014 16:57:48 +, Marc Schütz wrote:
On Thursday, 6 November 2014 at 15:53:27 UTC, Jack Applegame wrote:
I have rectangular forward range of forward ranges (not arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward
On Thu, 06 Nov 2014 17:08:23 +, Justin Whear wrote:
I think the correct solution
will make use of std.range.frontTraversal, but it will be a bit more
complex due to needing to sum every column. std.range.traversal would
make it easy, but it requires random access.
That should be
On Thursday, 6 November 2014 at 16:57:50 UTC, Marc Schütz wrote:
On Thursday, 6 November 2014 at 15:53:27 UTC, Jack Applegame
wrote:
I have rectangular forward range of forward ranges (not
arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward
On Thursday, 6 November 2014 at 17:08:23 UTC, Justin Whear wrote:
This would sum along the wrong dimension. I think the correct
solution
will
make use of std.range.frontTraversal, but it will be a bit more
complex
due to
needing to sum every column. std.range.traversal would make it
easy,
On Nov 5, 2014 12:10 PM, Bauss via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Is there any way to track down access violations, instead of me having to
look through my source code manually.
Whenever you don't get a stack trace on Windows, it's 99% guaranteed you're
calling a
On 11/06/14 18:32, bearophile via Digitalmars-d-learn wrote:
Marc Schütz:
We'd need something taking and returning a RoR that mirrors them
diagonally. Then we could simply apply `map!(r = r.sum)` on the result.
A simple solution is to create a row of values, and then sum them correctly
This is the code for std.range.put:
void put(R, E)(ref R r, E e)
{
//Why?
@property ref E[] EArrayInit(); //@@@9186@@@: Can't use
(E[]).init
//First level: simply straight up put.
static if (is(typeof(doPut(r, e
{
doPut(r, e);
}
//Optional optimization
void popFront() { foreach (ref r; rr) r.popFront(); }
I think it should be
void popFront() { foreach (ref r; rr.save) r.popFront(); }
but I think OP wanted a ready-made phobos solution, w/o all the
range boilerplate...
exactly.
On 11/6/14 4:19 PM, Meta wrote:
This is the code for std.range.put:
void put(R, E)(ref R r, E e)
{
//Why?
@property ref E[] EArrayInit(); //@@@9186@@@: Can't use (E[]).init
//First level: simply straight up put.
static if (is(typeof(doPut(r, e
{
doPut(r,
On Thursday, 6 November 2014 at 15:53:27 UTC, Jack Applegame
wrote:
I have rectangular forward range of forward ranges (not arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward range:
[
a11 + a21 + ... aM1,
a12 + a22 + ... aM2,
...
a1N +
On Thursday, 6 November 2014 at 21:57:36 UTC, Steven
Schveighoffer wrote:
github blame is quite useful:
https://github.com/D-Programming-Language/phobos/blame/master/std/range.d#L668
The commit:
https://github.com/D-Programming-Language/phobos/commit/c717b503e7305a92410c23ca2bc2ea14b40f8aa2
On Thursday, 6 November 2014 at 15:53:27 UTC, Jack Applegame
wrote:
I have rectangular forward range of forward ranges (not arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward range:
[
a11 + a21 + ... aM1,
a12 + a22 + ... aM2,
...
a1N +
On Thursday, 6 November 2014 at 22:02:09 UTC, John Colvin wrote:
On Thursday, 6 November 2014 at 15:53:27 UTC, Jack Applegame
wrote:
I have rectangular forward range of forward ranges (not
arrays):
[
[a11, a12, ... a1N],
[a21, a22, ... a2N],
...
[aM1, aM2, ... aMN]
]
I need lazy forward
1 - 100 of 121 matches
Mail list logo
