On 10/11/2010 10:56 PM, bearophile wrote:
Pelle:
string assertReturnsRangeOf(T)() {
return "static assert (is(Unqual!(ForeachType!(typeof(return))) == "
~ T.stringof ~ "));";
}
auto foo() {
return map!q{a*a}([1,2,3,4,5]);
mixin (assertReturnsRangeOf!int);
}
You wer
On 10/12/2010 02:33 AM, Andrei Alexandrescu wrote:
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[]
On Mon, 11 Oct 2010 23:34:41 -0400, Daniel Gibson
wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join
On Tue, 12 Oct 2010 00:47:33 -0400, Daniel Gibson
wrote:
On Tue, Oct 12, 2010 at 6:37 AM, Daniel Gibson
wrote:
Btw: Is "join" not just a (rather trivial) generalization of reduce?
auto inRange = ...; // range of char[]
char[] sep = " ";
auto joined = reduce!( (char[] res, char[] x) {retu
On Tue, Oct 12, 2010 at 6:37 AM, Daniel Gibson wrote:
>
> Btw: Is "join" not just a (rather trivial) generalization of reduce?
>
> auto inRange = ...; // range of char[]
> char[] sep = " ";
> auto joined = reduce!( (char[] res, char[] x) {return res~sep~x;})
> (inRange);
>
Not generalization, I m
Andrei Alexandrescu schrieb:
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[] sep)
if (isSomeChar!
"Denis Koroskin" <2kor...@gmail.com> wrote in message
news:op.vkfv2p13o7c...@korden-pc...
> On Tue, 12 Oct 2010 05:30:27 +0400, Philippe Sigaud
> wrote:
>
> That could be as simple as:
>
> struct Bounded(A min, A max, T = A) { ... }
>
Better yet,
struct Bounded(A min, B max, T = CommonType!(A,
Andrei Alexandrescu schrieb:
On 10/11/2010 10:34 PM, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union()
On 10/11/2010 10:34 PM, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in
Jonathan M Davis schrieb:
On Monday 11 October 2010 20:34:41 Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
On Monday 11 October 2010 20:34:41 Daniel Gibson wrote:
> Andrei Alexandrescu schrieb:
> > On 10/11/2010 08:57 PM, Daniel Gibson wrote:
> >> But right now the point is: join() does something completely different
> >> and should be renamed (or deprecated in std.string and replaced by
> >> union() -
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in std.string anyway, but when join()
is deprecat
On 10/11/2010 08:45 PM, Philippe Sigaud wrote:
2010/10/12 Denis Koroskin<2kor...@gmail.com>:
That could be as simple as:
struct Bounded(A min, A max, T = A) { ... }
Bounded!(0, 1) zeroOrOne; // 4 bytes because of default int
Bounded!(0, 1, ubyte) zeroOrOne; // 1 byte, specified
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in std.string anyway, but when join()
is deprecated in std.string you can imple
On 10/11/2010 10:08 PM, bearophile wrote:
Daniel Gibson:
But right now the point is: join() does something completely different and
should be renamed (or
deprecated in std.string and replaced by union() - a real join isn't needed in
std.string anyway,
but when join() is deprecated in std.stri
bearophile schrieb:
Daniel Gibson:
But right now the point is: join() does something completely different and should be renamed (or
deprecated in std.string and replaced by union() - a real join isn't needed in std.string anyway,
but when join() is deprecated in std.string you can implement a
Philippe Sigaud schrieb:
On Tue, Oct 12, 2010 at 03:28, Simen kjaeraas wrote:
Daniel Gibson wrote:
(*) Something like
Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
BinaryPredicate!(T1, T2) joinPred)
just pseudo-code, I'm not really familiar with D2 and std.algorithm.
The
Daniel Gibson:
> But right now the point is: join() does something completely different and
> should be renamed (or
> deprecated in std.string and replaced by union() - a real join isn't needed
> in std.string anyway,
> but when join() is deprecated in std.string you can implement a real join
On Tue, Oct 12, 2010 at 02:33, Andrei Alexandrescu
wrote:
> ElementType!R1[] join(R1, R2)(R1 items, R2 sep)
> if (isInputRange!R1 && isForwardRange!R2
> && is(ElementType!R2 : ElementType!R1);
> Notice how the separator must be a forward range because it gets spanned
> multiple times, whereas
Philippe Sigaud:
> suggest that for integral types (+ chars) is
> automatically closed at both ends. That what most people want.
> The opening make sense only for floating point or custom types.
The behaviour needs to be the same, for consistency.
Also keep in mind that in D the interval syntaxes
Simen kjaeraas schrieb:
Daniel Gibson wrote:
(*) Something like
Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
BinaryPredicate!(T1, T2) joinPred)
just pseudo-code, I'm not really familiar with D2 and std.algorithm.
The idea is you have a Range r1 with elements of type T1,
On Tue, 12 Oct 2010 05:45:09 +0400, Philippe Sigaud
wrote:
2010/10/12 Denis Koroskin <2kor...@gmail.com>:
That could be as simple as:
struct Bounded(A min, A max, T = A) { ... }
Bounded!(0, 1) zeroOrOne; // 4 bytes because of default
int
Bounded!(0, 1, ubyte) zeroOrOne;
On Tue, Oct 12, 2010 at 03:28, Simen kjaeraas wrote:
> Daniel Gibson wrote:
>
>> (*) Something like
>> Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
>> BinaryPredicate!(T1, T2) joinPred)
>> just pseudo-code, I'm not really familiar with D2 and std.algorithm.
>> The idea is you
2010/10/12 Denis Koroskin <2kor...@gmail.com>:
>
> That could be as simple as:
>
> struct Bounded(A min, A max, T = A) { ... }
>
> Bounded!(0, 1) zeroOrOne; // 4 bytes because of default int
> Bounded!(0, 1, ubyte) zeroOrOne; // 1 byte, specified explicitly
Neat, this is exactly wha
On Tue, Oct 12, 2010 at 03:25, Simen kjaeraas wrote:
Simen, I'm pretty sure you should be asleep right now. I know *I* should.
>> Could you explain what asm { jo overflow;} does?
>
> jo means jump on overflow, and overflow is the targeted label.
OK. So it checks something somewhere to see if an
Daniel Gibson Wrote:
> bearophile schrieb:
> > Andrei:
> >
> >> One thing is still bothering me: the array output type. Why would the
> >> "default" output range be an array?
> >
> > The chain() function that returns a range is already present.
> >
> >
> >> What can be done to make join() at
On Tue, 12 Oct 2010 05:30:27 +0400, Philippe Sigaud
wrote:
2010/10/11 Adam D. Ruppe :
For future direction, I don't think the Type argument is actually
needed to the
Bounded struct. It could determine it from the bounds.
So Bounded!(0, 255) it knows could be a ubyte, but Bounded!('A', 'Z
On Mon, Oct 11, 2010 at 03:55, Yao G. wrote:
> On Sun, 10 Oct 2010 16:16:05 -0500, Philippe Sigaud
> wrote:
>
> I don't have a bounded type, but a wrapping integer, ported from Boost:
>
>>
>> http://bitbucket.org/gomez/yao-library/src/tip/src/yao/datetime/core.d#cl-551
Wow, I never put pure noth
2010/10/11 Adam D. Ruppe :
> For future direction, I don't think the Type argument is actually needed to
> the
> Bounded struct. It could determine it from the bounds.
>
> So Bounded!(0, 255) it knows could be a ubyte, but Bounded!('A', 'Z') is a
> char.
>
> Maybe the type param can be moved to
Daniel Gibson wrote:
(*) Something like
Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
BinaryPredicate!(T1, T2) joinPred)
just pseudo-code, I'm not really familiar with D2 and std.algorithm.
The idea is you have a Range r1 with elements of type T1, a Range r1
with elemen
Philippe Sigaud wrote:
Could you explain what asm { jo overflow;} does?
jo means jump on overflow, and overflow is the targeted label.
It uses a mixin to do the check, so the jo instruction works so it
catches
wrapping overflow too.
Could you explain that part?
See above.
I'm sure
2010/10/11 Denis Koroskin <2kor...@gmail.com>:
> Also, one should be able to define CheckedInt type as follows:
>
> alias Bounded!(int, int.min, int.max) CheckedInt;
>
> CheckedInt would allow easy integer overflow detection.
Does Adam's code do that? I don't know the behaviour of jo overflow;
>
2010/10/11 Tomek Sowiński :
> Philippe Sigaud napisał:
>
>> As you can see, an "open or closed for both ends" policy could be
>> interesting to add. In the previous example, is 1.0 a correct value?
>
> It can be handled as in std.random: Bounded!(T, min, max, string bounds =
> "[)"). But with "[]"
On Sun, Oct 10, 2010 at 23:24, Adam D. Ruppe wrote:
> I saw it on the Phobos list and whipped together a first try.
Cool! Thanks, Adam.
> static string runCheckCode() { return q{
> asm {
> jo overflow;
> }
> if(_payload <
bearophile schrieb:
Andrei:
One thing is still bothering me: the array output type. Why would the
"default" output range be an array?
The chain() function that returns a range is already present.
What can be done to make join() at
the same time a general function and also one that works fo
On 10/11/2010 08:02 PM, bearophile wrote:
You may implement a generic std.algorithm.join, and then implement the
std.string.join that uses just strings (the second argument may be a single
char too) and calls std.algorithm.join for its implementation.
If you don't like that name collision, th
> You may implement a generic std.algorithm.join, and then implement the
> std.string.join that uses just strings (the second argument may be a single
> char too) and calls std.algorithm.join for its implementation.
If you don't like that name collision, the std.algorithm one may be named
joinR
Andrei:
> assert(false) could be in an ideal world replaced by an intrinsic called
> e.g. halt() that looks and feels like a regular function but is
> recognized by the compiler. No new keyword would be needed. But I don't
> think that would mark a significant improvement in the language.
I'd
Andrei Alexandrescu schrieb:
On 10/11/2010 12:38 PM, Daniel Gibson wrote:
But parts of phobos are deprecated or will be deprecated and there still
is no alternative for them.
That may prevent people from writing "real" projects in D2 (or D at all)
- who wants to use classes that will be deprecat
Andrei:
> One thing is still bothering me: the array output type. Why would the
> "default" output range be an array?
The chain() function that returns a range is already present.
> What can be done to make join() at
> the same time a general function and also one that works for strings the
On 10/10/2010 10:52 AM, Christopher Bergqvist wrote:
Hi,
Time for some Sunday nitpicking. While reading TDPL, one thing that
stuck out to me was the special behavior of assert(false). Consider the
following program compiled with "-release".
void main()
{
int a = 0;
assert(a);
}
That
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[] sep)
if (isSomeChar!Char);
I think it's reasonabl
On 10/11/2010 12:38 PM, Daniel Gibson wrote:
But parts of phobos are deprecated or will be deprecated and there still
is no alternative for them.
That may prevent people from writing "real" projects in D2 (or D at all)
- who wants to use classes that will be deprecated soon?
Sure, that old stuff
Pelle:
> string assertReturnsRangeOf(T)() {
> return "static assert (is(Unqual!(ForeachType!(typeof(return))) == "
> ~ T.stringof ~ "));";
> }
>
> auto foo() {
> return map!q{a*a}([1,2,3,4,5]);
> mixin (assertReturnsRangeOf!int);
> }
>
> You were probably looking for a mo
Simen kjaeraas wrote:
> Lutger wrote:
>
>> bearophile wrote:
>>
>> assert(halt)? (thinking of scope)
>>
>> I agree btw, this is very error prone.
>
> Error prone? When should the program haltin debug mode, but not in release?
>
You're right, I wasn't thinking clear.
Lutger wrote:
bearophile wrote:
assert(halt)? (thinking of scope)
I agree btw, this is very error prone.
Error prone? When should the program haltin debug mode, but not in release?
--
Simen
On Sun, 10 Oct 2010 19:52:28 +0400, Christopher Bergqvist
wrote:
Hi,
Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
out to me was the special behavior of assert(false). Consider the
following
program compiled with "-release".
void main()
{
int a = 0;
as
bearophile wrote:
> Christopher Bergqvist:
>> I would prefer it if assert() didn't have this special type of behavior, and
>> that a "halt" keyword or equivalent was introduced. What do you think?
>
> A halt() intrinsic from sounds indeed cleaner. But I don't know if Walter is
> willing to add a
I still don't understand how it's supposed to work. Replace the line
'(OwnerTerminated) { return; }' with '(MsgToClient) { return; }', where
MsgToClient is an enum, still crashes gloriously with an OwnerTerminated
exception. Is there any way I can cleanly stop a thread without crashing?
On Oct
Walter:
> The way varargs works for the C ABI is inefficient, clumsy, and frankly won't
> work for what D needs. So I'm going to have two varargs - one for extern (C)
> which is compatible with the C ABI and one for extern (D) which will push
> things
> on the stack as for 32 bits.
Recently I
Iain Buclaw wrote:
I'm actually rather curious how DMD plans on doing varargs in 64bit. Not least
because I don't think their current method of "calculating" the address of the
_argptr takes 64bit parameter passing into account.
I'm working on it now. It's a bitch.
The way varargs works for th
Andrei Alexandrescu schrieb:
On 10/10/10 20:59 CDT, Jonathan M Davis wrote:
On Sunday 10 October 2010 17:27:55 Daniel Gibson wrote:
bioinfornatics schrieb:
LDC support 64 bit ;)
as well as GDC.
But both currently lack an up-to-date D2 compiler (but the GDC guys are
at least working on it, s
On Monday, October 11, 2010 07:31:54 Sean Kelly wrote:
> Christopher Bergqvist Wrote:
> > Hi,
> >
> > Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
> > out to me was the special behavior of assert(false). Consider the
> > following program compiled with "-release".
>
>
Christopher Bergqvist Wrote:
> Hi,
>
> Time for some Sunday nitpicking. While reading TDPL, one thing that stuck
> out to me was the special behavior of assert(false). Consider the following
> program compiled with "-release".
-release is misnamed. It should be -unsafe or -unchecked or somethin
Thank you, I have checked them out. Both SciD and dstats look useful. We
would have to supplement with our own math libraries and bindings to various
C/Fortran libraries I think. I am just exploring possibilities because of
the endless troubles we have with compiling and linking C++ code on Mac
On Sun, 10 Oct 2010 20:30:52 -0400, Michael Stover wrote:
> Can one call fortran libraries from D? Ie, say one wanted to use LAPACK
> from D?
Since it is possible in C, it should be possible in D. A quick search
turned up this page:
http://www.yolinux.com/TUTORIALS/LinuxTutorialMixingFortran
On Mon, Oct 11, 2010 at 2:30 AM, Michael Stover
wrote:
> I am under the impression that passing a pointer to a static function (ie,
> passing a pointer to a memory address that contains the starting point of a
> function) is not the same as defining a method that can be called by name
> from C cod
Thank you for helping me understand.
Mike
On Mon, Oct 11, 2010 at 8:39 AM, Simen kjaeraas wrote:
> Michael Stover wrote:
>
> I am under the impression that passing a pointer to a static function (ie,
>> passing a pointer to a memory address that contains the starting point of
>> a
>> function)
Michael Stover wrote:
I am under the impression that passing a pointer to a static function
(ie,
passing a pointer to a memory address that contains the starting point
of a
function) is not the same as defining a method that can be called by name
from C code. I am not a C expert though.
On 2010-10-11 06:54, Jonathan M Davis wrote:
On Sunday 10 October 2010 21:26:28 Andrei Alexandrescu wrote:
I think it's a bit hasty to speak on behalf of all of Phobos'
participants. Phobos 2 is indeed different from Phobos 1 but
backward-incompatible changes to Phobos 2 are increasingly rare.
== Quote from Daniel Gibson (metalcae...@gmail.com)'s article
> bioinfornatics schrieb:
> > LDC support 64 bit ;)
> as well as GDC.
> But both currently lack an up-to-date D2 compiler (but the GDC guys are
> at least working on it, seems like they're currently at 2.029 - which is
> great - about 3
On Sat, 09 Oct 2010 18:43:54 -0500, Andrei Alexandrescu wrote:
> On 10/9/10 18:20 CDT, dsimcha wrote:
>> Vote++. When I added bidirectional support for map(), I felt like any
>> solution for doing bidirectional caching was going to suck. I
>> considered just eliminating it, but left it because a
On Sun, 10 Oct 2010 00:46:47 -0700, Jonathan M Davis
wrote:
working on the project without getting too frustrated over it. QtD
is a huge
service to the D community.
It is. Qt bindings were the first thing I looked for when I started
with the language, even with my current project not using
63 matches
Mail list logo
