On Sun, 09 Jan 2011 23:09:26 -0600, Christopher Nicholson-Sauls wrote:
> On 01/09/11 16:28, Sean Eskapp wrote:
>> This code works fine:
>>
>> int[] arr = [ 1, 2, 3, 4, 5 ];
>> auto myMax = function int(int a, int b) { return (a > b) ? a :
b; };
>> auto biggest = reduce!(myMax)(arr
"Jonathan M Davis" wrote in message
news:mailman.529.1294620116.4748.digitalmar...@puremagic.com...
> On Sunday 09 January 2011 13:52:53 Jim wrote:
>> I'm a firm believer of alternative B: Store the string with its original
>> case, unless it's particularly important to do otherwise.
>>
>> The co
On Sun, 09 Jan 2011 16:51:57 -0600, Andrei Alexandrescu wrote:
> There's a lot of junk in std.string that should be gone. I'm trying to
> motivate myself to port some functions to different string widths and...
> it's not worth it.
>
> What functions do you think we should remove from std.string?
bearophile wrote:
A bug I've introduced once in my D code, are you able to spot it?
void main() { double x = +0; double y = -0; }
The bug: 'y' isn't the desired double -0.0
To avoid this bug DMD may keep the -0 and +0 integer literals represented in
two distinct ways, so they have two differe
On 01/09/11 16:28, Sean Eskapp wrote:
> This code works fine:
>
> int[] arr = [ 1, 2, 3, 4, 5 ];
> auto myMax = function int(int a, int b) { return (a > b) ? a : b; };
> auto biggest = reduce!(myMax)(arr);
>
> But passing the function literal directly to reduce causes an error.
I'm trying to use the array() function in std.array to convert a transformed
array using map (std.algorithm) back to a dynamic array, from a Map. I keep
getting a cryptic error "object.except...@c:\Program Files
(x86)\D\dmd2\windows\bin\..\..\src\phobos\std\
algorithm.d(426): Cannot reduce an empty
On 01/09/2011 04:31 PM, Sean Eskapp wrote:
That's.. ehem.. quite limiting. :) (you probably meant heap)
I meant what I said, and I said what I meant. Stack allocated implicitly would
be
fine, but explicit stack allocation, like declaring variables, doesn't happen in
purely functional languages
On Sun, 09 Jan 2011 20:39:12 -0500, Jonathan M Davis
wrote:
On Sunday 09 January 2011 16:27:11 bearophile wrote:
A bug I've introduced once in my D code, are you able to spot it?
void main() {
double x = +0;
double y = -0;
}
The bug: 'y' isn't the desired double -0.0
To avoid thi
This is not really a bug.
I'd expect -0 to be an integer 0. Negative zero doesn't make sense for
integers, and the behavior is consistent with C/C++.
A warning, like you proposed, could possibly help avoiding a mistake.
bearophile Wrote:
> A bug I've introduced once in my D code, are you abl
On Sunday 09 January 2011 16:27:11 bearophile wrote:
> A bug I've introduced once in my D code, are you able to spot it?
>
> void main() {
> double x = +0;
> double y = -0;
> }
>
>
> The bug: 'y' isn't the desired double -0.0
>
> To avoid this bug DMD may keep the -0 and +0 integer lite
On Sunday 09 January 2011 14:31:11 Sean Eskapp wrote:
> >That's.. ehem.. quite limiting. :) (you probably meant heap)
>
> I meant what I said, and I said what I meant. Stack allocated implicitly
> would be fine, but explicit stack allocation, like declaring variables,
> doesn't happen in purely fu
On Sunday 09 January 2011 13:52:53 Jim wrote:
> I'm a firm believer of alternative B: Store the string with its original
> case, unless it's particularly important to do otherwise.
>
> The cost of case-insensitive comparison is REALLY small. Anytime you are to
> compare two strings ask yourself wh
Andrei Alexandrescu napisał:
> > bool any(alias pred = "a==b", E, Ts...)(E e, Ts args) if(Ts.length> 1 ||
> > !isTuple!Ts) {
> > foreach (a; args)
> > if (binaryFun!pred(a, e))
> > return true;
> > return false;
> > }
> >
> > unittest
> > {
> > assert(!"a
A bug I've introduced once in my D code, are you able to spot it?
void main() {
double x = +0;
double y = -0;
}
The bug: 'y' isn't the desired double -0.0
To avoid this bug DMD may keep the -0 and +0 integer literals represented in
two distinct ways, so they have two different values w
On Sunday 09 January 2011 15:19:31 Jimmy Cao wrote:
> I think the tr, replace, and translate functions are a bit awkward.
Really? I use replace() fairly heavily in string-processing code, and I don't
see anything about it which could be considered awkward.
tr() is definitely cool. I do think tha
On Sunday 09 January 2011 12:28:23 Andrei Alexandrescu wrote:
> On 1/9/11 2:09 PM, Tomek Sowiński wrote:
> > I really don't dig the whole helper structs with overloaded operators
> > thing. It complicates the implementation (more work for compiler to grok
> > and inline) and you're never really sur
On Sunday 09 January 2011 10:44:39 Andrei Alexandrescu wrote:
> On 1/9/11 10:28 AM, Pelle wrote:
> > On 01/09/2011 03:07 AM, Robert Clipsham wrote:
> >> On 08/01/11 23:20, bearophile wrote:
> >>> Andrei has recently closed issue 1323, it's a small but very useful
> >>> feature, so I suggest some pu
IIRC someone on this NG mentioned that several functions are going
away from std.string and into std.algorithm. This would be nice,
considering I frequently get name clashes when importing both modules
(but at least there's no function hijacking. Thanks, D!).
I think the tr, replace, and translate functions are a bit awkward.
There's a lot of junk in std.string that should be gone. I'm trying to
motivate myself to port some functions to different string widths and...
it's not worth it.
What functions do you think we should remove from std.string? Let's make
a string and then send them the way of the dino.
Thanks
>That's.. ehem.. quite limiting. :) (you probably meant heap)
I meant what I said, and I said what I meant. Stack allocated implicitly would
be
fine, but explicit stack allocation, like declaring variables, doesn't happen in
purely functional languages.
Personally, I like being able to impose th
This code works fine:
int[] arr = [ 1, 2, 3, 4, 5 ];
auto myMax = function int(int a, int b) { return (a > b) ? a : b; };
auto biggest = reduce!(myMax)(arr);
But passing the function literal directly to reduce causes an error. Is this
intentional?
Sean Eskapp napisał:
> It's a programmer contract, nothing more. It forces the code to be
> functional, not
> procedural. Just like const and @safe are simply programmer contracts,
Immutably (strongly) pure (pure + all arguments immutable) functions break D
onto functional grounds.
> functiona
It's a programmer contract, nothing more. It forces the code to be functional,
not
procedural. Just like const and @safe are simply programmer contracts,
functional
would mean no explicit stack allocation, except that allocated in called
functions.
I'm a firm believer of alternative B: Store the string with its original case,
unless it's particularly important to do otherwise.
The cost of case-insensitive comparison is REALLY small. Anytime you are to
compare two strings ask yourself whether case-sensitive or case-insensitive is
what you
On 1/9/11 3:13 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
Aha, so this encodes the predicate in the operation. With a general
predicate, that would be:
if (any!"a != b"(expr, 1, 2, 5)) { ... }
The advantage over
if (expr != 1 || expr != 2 || expr != 5)) { ... }
is terseness and
Eskapp wrote:
Functional functions could not modify ANY data, including explicitly
allocating
variables. Although, come to think of it, this wouldn't imply pure, as
they should
still be allowed to read global data and call impure functions.
I don't think I understand this. pure functions
Am 09.01.2011 22:16, schrieb Vladimir Panteleev:
On Sun, 09 Jan 2011 21:02:13 +0200, Daniel Gibson wrote:
What's F$$$F$$?
FireFox/IceWeasel:
http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project
Oh that.
I couldn't care less if my browser is called Fire
Functional functions could not modify ANY data, including explicitly allocating
variables. Although, come to think of it, this wouldn't imply pure, as they
should
still be allowed to read global data and call impure functions.
On Sun, 09 Jan 2011 21:02:13 +0200, Daniel Gibson
wrote:
What's F$$$F$$?
FireFox/IceWeasel:
http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
Imagine things like Windows filenames or tokenized BASIC code (There's
probably plenty of other examples too, for instance, I came across this
issue when dealing with GOLD's pre-defined character set names:
http://www.devincook.com/goldparser/doc/grammars/character-sets.htm ).
These things *do*
Andrei Alexandrescu napisał:
> Aha, so this encodes the predicate in the operation. With a general
> predicate, that would be:
>
> if (any!"a != b"(expr, 1, 2, 5)) { ... }
>
> The advantage over
>
> if (expr != 1 || expr != 2 || expr != 5)) { ... }
>
> is terseness and the guarantee that expr
Sean Eskapp wrote:
I recommend that there be a "functional" keyword, which when applied to
functions, would not allow them to modify existing data, or call impure
functions. This would imply pure.
Thoughts?
What is the difference between this and pure?
--
Simen
I recommend that there be a "functional" keyword, which when applied to
functions, would not allow them to modify existing data, or call impure
functions. This would imply pure.
Thoughts?
On 1/9/11 1:24 PM, Robert Clipsham wrote:
On 09/01/11 18:44, Andrei Alexandrescu wrote:
I'd be glad to change canFind to contains. Vote by replying to this. We
can put canFind on the slow deprecation chute.
Andrei
++vote;
I just remembered why I called it canFind: it clarifies we're talking
On 9/01/11 7:15 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
I'd be glad to change canFind to contains. Vote by replying to this. We
can put canFind on the slow deprecation chute.
Like!
Up vote for me.
On 1/9/11 2:09 PM, Tomek Sowiński wrote:
I really don't dig the whole helper structs with overloaded operators thing. It
complicates the implementation (more work for compiler to grok and inline) and
you're never really sure what it does unless you read the docs (or the
complicated implementat
On 1/9/11 1:30 PM, Andrej Mitrovic wrote:
While you're at it I would really like to have a remove method in
std.algorithm that can take an ElementType of a range as a predicate:
See my older topic:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Removing_an_object_from_a_range_23212.ht
On 1/9/11 1:12 PM, Daniel Gibson wrote:
Am 09.01.2011 19:48, schrieb Robert M. Münch:
On 2011-01-09 19:42:22 +0100, Andrei Alexandrescu said:
I wrote a simple helper, in spirit with some recent discussions:
Hi, EITHER normaly means: This or that, so it's more like an IF/ELSE.
How about ANY?
"Nick Sabalausky" wrote in message
news:igd57p$2k1...@digitalmars.com...
> "Andrei Alexandrescu" wrote in message
> news:igcvll$29k...@digitalmars.com...
>>I wrote a simple helper, in spirit with some recent discussions:
>>
>> // either
>> struct Either(Ts...)
>> {
>> Tuple!Ts data_;
>>
Andrej Mitrovic:
> I think "any" is used in Python IIRC, so I'll have to go +1 with Robert here.
any() and all() in Python have a different purpose, the first is true if one or
more than the given items is true, and the second is true if they all true:
>>> all([1, 2, 4])
True
>>> all(["", None,
"Andrei Alexandrescu" wrote in message
news:igcvll$29k...@digitalmars.com...
>I wrote a simple helper, in spirit with some recent discussions:
>
> // either
> struct Either(Ts...)
> {
> Tuple!Ts data_;
> bool opEquals(E)(E e)
> {
> foreach (i, T; Ts)
> {
>
Daniel Gibson:
> Yeah, "contains" sounds better than "canFind", so
> ++vote
In my dlibs1 I have used isIn(), but contains() is better than canFind().
Bye,
bearophile
Andrei Alexandrescu napisał:
> I wrote a simple helper, in spirit with some recent discussions:
>
> // either
> struct Either(Ts...)
> {
> Tuple!Ts data_;
> bool opEquals(E)(E e)
> {
> foreach (i, T; Ts)
> {
> if (data_[i] == e) return true;
>
s/predicate/needle
While you're at it I would really like to have a remove method in
std.algorithm that can take an ElementType of a range as a predicate:
See my older topic:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Removing_an_object_from_a_range_23212.html
An example would look like:
Object a, b,
On 09/01/11 18:44, Andrei Alexandrescu wrote:
I'd be glad to change canFind to contains. Vote by replying to this. We
can put canFind on the slow deprecation chute.
Andrei
++vote;
--
Robert
http://octarineparrot.com/
On 1/9/11 7:44 PM, Andrei Alexandrescu wrote:
I'd be glad to change canFind to contains. Vote by replying to this. We
can put canFind on the slow deprecation chute.
Changing the name to »contains« has my vote as well – »canFind« always
sounds like a check whether the container can perform »fin
Andrei Alexandrescu napisał:
> I'd be glad to change canFind to contains. Vote by replying to this. We
> can put canFind on the slow deprecation chute.
Like!
Andrei Alexandrescu wrote:
I'd be glad to change canFind to contains. Vote by replying to this. We
can put canFind on the slow deprecation chute.
Absolutely. canFind always sounded to me like "this container supports
find".
--
Simen
Am 09.01.2011 19:44, schrieb Andrei Alexandrescu:
On 1/9/11 10:28 AM, Pelle wrote:
On 01/09/2011 03:07 AM, Robert Clipsham wrote:
On 08/01/11 23:20, bearophile wrote:
Andrei has recently closed issue 1323, it's a small but very useful
feature, so I suggest some public discussion:
http://d.pure
Am 09.01.2011 19:48, schrieb Robert M. Münch:
On 2011-01-09 19:42:22 +0100, Andrei Alexandrescu said:
I wrote a simple helper, in spirit with some recent discussions:
Hi, EITHER normaly means: This or that, so it's more like an IF/ELSE.
How about ANY? IMO
1==any(1, 2, 3)
describes pretty go
I think "any" is used in Python IIRC, so I'll have to go +1 with Robert here.
Here's my results:
Parallel Foreach: 29.6365
Map: 23.1849
Serial: 32.9265
This is with -release -inline -O -noboundscheck
I'm on a quad-core btw.
Am 09.01.2011 19:42, schrieb Andrei Alexandrescu:
I wrote a simple helper, in spirit with some recent discussions:
// either
struct Either(Ts...)
{
Tuple!Ts data_;
bool opEquals(E)(E e)
{
foreach (i, T; Ts)
{
if (data_[i] == e) return true;
}
return false;
}
}
auto either(Ts...)(Ts args)
{
retu
Am 09.01.2011 12:16, schrieb Russel Winder:
Debian Testing is really a rolling release but it tends to be behind
Ubuntu is some versions of things and ahead in others. Also Ubuntu has
non-free stuff that is forbidden on Debian. Not to mention the F$$$F$$
fiasco!
That's why debian has contrib
On 2011-01-09 19:42:22 +0100, Andrei Alexandrescu said:
I wrote a simple helper, in spirit with some recent discussions:
Hi, EITHER normaly means: This or that, so it's more like an IF/ELSE.
How about ANY? IMO
1==any(1, 2, 3)
describes pretty good what is meant.
--
Robert M. Münch
http://
On 2011-01-09 11:44:05 +0100, Jérôme M. Berger said:
Is not it more or less a standard bugzilla [1] install?
Really? Hmm... ok. Nevermind. I normally don't like bugzilla that much.
--
Robert M. Münch
http://www.robertmuench.de
On 1/9/11 10:28 AM, Pelle wrote:
On 01/09/2011 03:07 AM, Robert Clipsham wrote:
On 08/01/11 23:20, bearophile wrote:
Andrei has recently closed issue 1323, it's a small but very useful
feature, so I suggest some public discussion:
http://d.puremagic.com/issues/show_bug.cgi?id=1323
Lines like t
I wrote a simple helper, in spirit with some recent discussions:
// either
struct Either(Ts...)
{
Tuple!Ts data_;
bool opEquals(E)(E e)
{
foreach (i, T; Ts)
{
if (data_[i] == e) return true;
}
return false;
}
}
auto either(Ts...)(Ts arg
On 9/01/11 4:28 PM, Pelle wrote:
On 01/09/2011 03:07 AM, Robert Clipsham wrote:
I'd be all for this, except it's inconsistent.
auto arr = [ "foo" : 1, "bar" : 2 ];
assert("foo" in arr);
in for associative arrays works by key, if it works by value for normal
arrays it's inconsistent, an
On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
* parallel is templated on range, but not on operation. Does this affect
speed for brief operations (such as the one given in the example,
squares[i] = i * i)? I wonder if using an alias wouldn't be more
appropriate. Some performance numbers would b
Just tried to implemnt Perl6-like junctions. Despite template functions
overloading against varadic and non-variadic (ie T[] and T[]...) does
not work, why has a struct opEquals to be S.opEquals(ref const(S))? Why
can't I compare a class against a struct or in my case a struct against
an int?
On 01/09/2011 03:07 AM, Robert Clipsham wrote:
On 08/01/11 23:20, bearophile wrote:
Andrei has recently closed issue 1323, it's a small but very useful
feature, so I suggest some public discussion:
http://d.puremagic.com/issues/show_bug.cgi?id=1323
Lines like this is present thousands of time i
I remember there was a discussion a little while back about how Phobos
would assume that structs are cheap to copy, and would simply pass them
by value.
Is this assumption now "the D way"? Should we all just pass structs by
value, assuming cheap copy construction?
If so, I think this needs t
Tomek Sowiñski:
> If it's about compile-time, it can be done with template wizardry:
>
> x in [1, 5, 7] -> x.in_!(1, 5, 7)
Or better, as a built in feature of arrays :-) But the asymmetry between
literals and normal arrays is silly.
Bye,
bearophile
Am 09.01.2011 14:56, schrieb Tomek Sowiński:
Daniel Gibson napisał:
"restricted to n log(n)"? I think you meant just "log(n)"
As far as I remember the last discussion, it was considered to allow it for
arrays of a constant size or with known (at compiletime) contents or something
like that.
Bu
Tomek Sowiński napisał:
> > What's wrong with std.algorithm.canFind?
> >
> > http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind
>
> That I didn't.. er.. find it :) Sorry for the noise.
One more thing: the overload for range in range search is missing. On the other
hand, it's
Daniel Gibson napisał:
> "restricted to n log(n)"? I think you meant just "log(n)"
>
> As far as I remember the last discussion, it was considered to allow it for
> arrays of a constant size or with known (at compiletime) contents or
> something
> like that.
> But then again, that would feel k
Peter Alexander:
> What's wrong with std.algorithm.canFind?
I will have to use it, then. Thank you for all the answers.
Bye,
bearophile
Peter Alexander napisał:
> What's wrong with std.algorithm.canFind?
>
> http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#canFind
That I didn't.. er.. find it :) Sorry for the noise.
--
Tomek
On 9/01/11 1:28 PM, Tomek Sowiński wrote:
bearophile napisał:
Also, IMO, it has no real advantage, why not use std.algorithm.find instead ?
The syntax is worse, I don't like to call a function for something so common
and basic. It's like calling a library
function to join two strings (and fi
bearophile napisał:
> > Also, IMO, it has no real advantage, why not use std.algorithm.find instead
> > ?
>
> The syntax is worse, I don't like to call a function for something so common
> and basic. It's like calling a library
> function to join two strings (and find("hello", "llox") doesn't
On 1/9/11, Andrej Mitrovic wrote:
> I'm keeping my eye on BeyondCompare. But it's not free. It's $80 for
> the dual platform Linux+Windows and the Pro version which features
> 3-way merge. It's customization options are great though. There's a
> trial version over at http://www.scootersoftware.com
I'm keeping my eye on BeyondCompare. But it's not free. It's $80 for
the dual platform Linux+Windows and the Pro version which features
3-way merge. It's customization options are great though. There's a
trial version over at http://www.scootersoftware.com/ if you want to
give it a spin.
On Sun, 9 Jan 2011 04:15:07 -0800
>> "Jonathan" == wrote:
Jonathan> Personally, I got sick of it and moved on. Currently, I use
Jonathan> Arch, which is _way_ more friendly for building non-repo
Jonathan> packages yourself or otherwise messing repo packages. You
Jonathan> _can_ choose to buil
On Sunday 09 January 2011 04:00:21 Christopher Nicholson-Sauls wrote:
> On 01/08/11 20:18, Walter Bright wrote:
> > Vladimir Panteleev wrote:
> >> On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
> >>
> >> wrote:
> >>> Yeah, I could spend an afternoon doing that.
> >>
> >> sudo apt-get build-de
On 01/08/11 20:18, Walter Bright wrote:
> Vladimir Panteleev wrote:
>> On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright
>> wrote:
>>
>>> Yeah, I could spend an afternoon doing that.
>>
>> sudo apt-get build-dep meld
>> wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2
>> tar
On Sat, 2011-01-08 at 18:22 -0800, Jonathan M Davis wrote:
> On Saturday 08 January 2011 14:34:19 Walter Bright wrote:
> > Michel Fortin wrote:
> > > I know you had your reasons, but perhaps it's time for you upgrade to a
> > > more recent version of Ubuntu? That version is what comes with Hardy
>
Robert M. Münch wrote:
> I just took a look at d.puremagic.com and I really like this systme. Is
> it available as OS? Can it be used for other projects as well?
>
Is not it more or less a standard bugzilla [1] install?
Jerome
[1] http://www.bugzilla.org/
--
mailto:jeber
I just took a look at d.puremagic.com and I really like this systme. Is
it available as OS? Can it be used for other projects as well?
--
Robert M. Münch
http://www.robertmuench.de
Jim wrote:
> I have to agree.
>
> assert(1 + 1 < 3);
>
> will always be easier to read than any:
>
> assertPred!"a < b"(1 + 1, 3);
>
> Why not just keep it simple and straight forward? Anything expressed in the
> latter form can be expressed in the former.
True, but on the other hand:
David Nadlinger wrote:
> On 1/7/11 8:53 AM, Don wrote:
>>> What are the advantages of Mercurial over git? (git does allow
>>> multiple branches.)
>>>
>>> Andrei
>>
>> Essentially political and practical rather than technical. […]
>
> By the way, I just stumbled upon this page presenting arguments
Walter Bright wrote:
> Vladimir Panteleev wrote:
>> From taking a quick look, I don't see meld's advantage over WinMerge
>> (other than being cross-platform).
>
> Thanks for pointing me at winmerge. I've been looking for one to work on
> Windows.
I personally use kdiff3 [1] both on Linux
84 matches
Mail list logo
