[Issue 13724] std.datetime.timeIt

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13724

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #9 from Jonathan M Davis  ---
I'm not at all convinced that this is worth adding, but if I were to add
something like this, I would probably make it use a callback that gave the
Duration so that it would be simple to do something like turn

auto foo = doSomething(args);

into

auto foo = timeIt!(a => writefln("doSomething: %s, a))(doSomething(args));

or

void printIt(Duration d, string file = __FILE__, size_t line = __LINE__)
{
writefln("%s(%s): %s", file, line, d);
}

auto foo = timeIt!printIt(doSomething(args));

But then again, the only reason I see to have a function like this would be to
do something like print or log the results of a particular run. It certainly
isn't appropriate for benchmarking.

--

[Issue 15710] Replacement for std.utf.validate which does not throw

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15710

--- Comment #2 from Jonathan M Davis  ---
Well having isValidUTF rather than validate would just make it so that you can
use an if-else block instead of a try-catch. It wouldn't really clean that code
up much.

If you really want to clean up what you're doing in that example, you need to
use byCodeUnit or byUTF, which use the replacement character. In that case, you
wouldn't need to check for valid Unicode. If you want a string out the other 
side instead of a range of code units or code points, you then just call
to!string or toUTF8 on it. e.g.

auto codeUnits = str.byCodeUnit();

or

auto dchars = str.byDchar(); // byUTF!dchar

or

str = str.byCodeUnit().to!string();

Now, if you want a string and don't want to allocate a new string if the string
is valid, then you'd need to check whether the string is valid Unicode, but in
that case you still don't need anything as complicated as what you wrote for
toValidUTF. You'd just need something like

try
str.validate();
catch(UnicodeException)
str = str.byCodeUnit().to!string();

and if we had isValidUTF, then you'd have

if(!str.isValidUTF())
str = str.byCodeUnit().to!string();

So, while isValidUTF would help, it's mostly just getting rid of an unnecessary
exception, which does clean up the code in this case, but not drastically. It's
byCodeUnit or byUTF that really clean things up here.

Now, as for adding isValidUTF, I have a PR for it in the PR queue, and Andrei
approved the symbol, but he rejected the implementation. He basically wanted me
to completely redesign how decode works internally and that the superficial
changes I had made to make it work with isValidUTF were too ugly to live. So,
at some point here, I need to go back and figure out how to rework all that
again, which is not going to be pretty.

--

[Issue 14562] Support BigInt function std.range.repeat and other functions of Phobos

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14562

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #3 from Simen Kjaeraas  ---
There are extremely few cases where using a value above 2^63 for the repeat
count is sensible. For the remaining 100% of cases, there's
https://dlang.org/phobos/std_bigint#.BigInt.toLong.

--

[Issue 17183] Improve std.algorithm.mutate.remove documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17183

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
>  Moving some of the details to a static if internally can yield improvements 
> in all three doc locations.

We have done this now too:
https://dlang.org/phobos/std_algorithm_mutation.html#.remove

There's also:

https://github.com/dlang/phobos/pull/6154

which tries to address the actual API problems of remove

--

[Issue 17137] std.stdio.readln should provide an OutputRange overload

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17137

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 17127] bad example code for std.concurrency.Generator

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17127

--- Comment #5 from Seb  ---
https://github.com/dlang/phobos/pull/5873 is the only bit left, but that's
currently failing on 32-bit testers.

--

[Issue 17047] std.algorithm.iteration.splitter should propagate bidirectionality

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17047

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #1 from Seb  ---
https://github.com/dlang/phobos/pull/6150

> Making splitter a bidirectional range fundamentally broken - at least if the 
> delimiter has more than one element. Think about something like

---
auto result = "***".splitter("**"); // odd number in the string being
split, even number in the delimeter
---

> The range is not going to have the same elements if it's iterated from the 
> back. It will end up being split differently.

--

[Issue 17046] std.algorithm.iteration.splitter should work with mere ForwardRanges

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17046

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 18701] New: std.conv.emplaceRef should be made publicly available

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18701

  Issue ID: 18701
   Summary: std.conv.emplaceRef should be made publicly available
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: bootcamp, safe
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

std.conv.emplaceRef is Phobos's internal @safe version of emplace.
Like `formattedRead`, emplace should be made @safe if no pointers are used.

Motivation:

No need for these hacks anymore - just `emplace!SafeClass(buf, 5)`

---
auto support = (() @trusted => cast(SafeClass)(buf.ptr))();
auto safeClass = emplace!SafeClass(support, 5);
---

--

[Issue 17030] Specialize range functions for isSortedRange

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17030

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17026] std.conv.emplace could be @safe if the constructor is so

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17026

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
It's now fixed with (but only with -dip1000)

--

[Issue 17024] check Phobos for convenience wrapper for templated struct

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17024

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17020] std.parallelism.taskpool amap should accept lambdas

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17020

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17019] std.algorithm.iteration.each should be usable with parallel

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17019

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 17018] Push std.experimental.xml

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17018

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
experimental.xml is now at:

https://github.com/dlang-community/experimental.xml

Though dxml has been recently started and might become a replacement:

https://github.com/jmdavis/dxml

--

[Issue 16614] [META] Each artifact in the standard library should have a meaningful example

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16614

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
This is now being tracked by https://github.com/dlang/phobos/projects/1 - we
are almost half-way through the remaining module blacklist :)

--

[Issue 15972] range of chars doesn't work with joiner with literal delimiters

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15972

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---

> What I have in mind:
> 1. Move autodecoding algorithms to undead.
> 2. Remove autodecoding from algorithms.
> 3. Have dfix rewrite std.algorithm to undead.algorithm

How would that work in practice?

std.algorithm is highly templated and the big issue are the auto-decoding
primitives in std.range.
We can't remove them easily nor even version them out (see e.g.
https://github.com/dlang/phobos/pull/5513) and no one seems to have found a
good transition path so far.

For now .byCodeUnit is the only available workaround and maybe eventually
RCString gets a thing.

--

[Issue 15969] makeNrray - allocate + dispose multi-dimensional array

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15969

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---


https://dlang.org/phobos/std_experimental_allocator.html#makeMultidimensionalArray
https://dlang.org/phobos/std_experimental_allocator.html#disposeMultidimensionalArray

--

[Issue 15971] BigInt ctor should accept forward ranges

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15971

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15750] net/isemail uses lots of redundant helper methods

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15750

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15732] std.function partial does not work with function / delegate references

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15732

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15710] Replacement for std.utf.validate which does not throw

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15710

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Yeah, I would be really cool if I don't have to do such ugly hacks when I just
want to handle invalid UTF.

---
private string toValidUTF(string s)
{
import std.algorithm.iteration : map;
import std.range : iota;
import std.utf;
return s.representation.length
.iota
.map!(i => s.decode!(UseReplacementDchar.yes)(i))
.toUTF8;
}

try {
outStream.validate;
} catch (UTFException) {
outStream = outStream.toValidUTF;
}
---

--

[Issue 15645] Tuple.slice() causes memory corruption.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15645

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #6 from Seb  ---
This was fixed by https://github.com/dlang/phobos/pull/5342 (or well at least
this PR prevents the unsafe usage).

--

[Issue 15294] receiveTimeout with negative value asserts

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15294

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
This has been fixed in 2.072:

https://run.dlang.io/is/FlTlZj

--

[Issue 15285] Range-ified functions for std.string

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15285

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15227] std.format undocumented grammar

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15227

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 15147] std.random.uniform return value depends on integer size

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15147

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
I just ran into this when trying to add more/better public examples for
std.random (https://github.com/dlang/phobos/pull/6393).

Normally, examples can be done by seeding the RNG and thus _knowing_ the
sequence of the PRNG.
The current behavior is really nasty.

--

[Issue 14647] std.random line 3015 heisenbug with FreeBSD_32

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14647

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Seb  ---
I haven't seen this one in the last two years, so I'm assuming that it has been
fixed. Closing.

--

[Issue 14562] Support BigInt function std.range.repeat and other functions of Phobos

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14562

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 14553] The return types of std.array.array for narrow strings conflicts with its documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14553

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 14543] std.algorithm.searching.until does not handle range sentinels nicely

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14543

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp

--

[Issue 14312] std.random unittest has intermittent failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14312

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
I haven't seen this in the last two years, so I assume its fixed.

--

[Issue 13965] More handy schwartzSort

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13965

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
   Hardware|x86 |All
 OS|Windows |All

--

[Issue 13893] "rawRead must take a non-empty buffer"

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13893

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 13924] Deprecate std.random.uniformDistribution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13924

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 13916] Nested std.concurrency.receive doesn't work correctly

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13916

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
So I experimented with removing the message from the list before the handler is
called, but I always get a LinkTerminated Exception which comes from the child
being terminated.
The child is in a while(true) loop, so it shouldn't get terminated, but for
some reason now its module deconstructor is now immediately called :/


diff --git a/std/concurrency.d b/std/concurrency.d
index 0e1b505bc..1c426bcc0 100644
--- a/std/concurrency.d
+++ b/std/concurrency.d
@@ -1974,8 +1980,9 @@ private
 enum timedWait = false;
 }

-bool onStandardMsg(ref Message msg)
+bool onStandardMsg(ref Message msg, void delegate() beforeSuccess
= (){})
 {
 foreach (i, t; Ops)
 {
 alias Args = Parameters!(t);
@@ -1985,10 +1992,13 @@ private
 {
 static if (is(ReturnType!(t) == bool))
 {
-return msg.map(op);
+beforeSuccess();
+auto b = msg.map(op);
+return b;
 }
 else
 {
+beforeSuccess();
 msg.map(op);
 return true;
 }
@@ -2043,6 +2053,8 @@ private
 {
 for (auto range = list[]; !range.empty;)
 {
+import std.stdio;
+writefln("range: %s", range.front);
 // Only the message handler will throw, so if this occurs
 // we can be certain that the message was handled.
 scope (failure)
@@ -2071,11 +2083,9 @@ private
 }
 else
 {
-if (onStandardMsg(range.front))
-{
-list.removeAt(range);
+if (onStandardMsg(range.front, (){
list.removeAt(range); }))
 return true;
-}
+
 range.popFront();
 continue;
 }
```

--

[Issue 13903] std.array.removeIf for associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13903

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Not sure whether such one/two-liners would be accepted to Phobos.

---
import std.experimental.all;

auto removeIf(alias pred, AA)(AA aa)
{
aa.byPair.filter!(not!pred).each!(e => aa.remove(e.key));
return aa;
}

void main()
{
auto aa = ["a" : 1, "b" : 2];
aa.removeIf!(a => a.key == "a").writeln;
}
---

But efficiency and bug-proneness are two good points.

--

[Issue 13880] nothrow @nogc std.algorithm.reduce on fixed-size arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13880

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
https://github.com/dlang/phobos/pull/6398

--

[Issue 18700] New: iota with floating type + padRigh asserts

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18700

  Issue ID: 18700
   Summary: iota with floating type + padRigh asserts
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: santerkr...@gmail.com

The following triggers an assertion std.range.package.d (source line 5632 for
tag 2.079.0):

iota(6.).padRight(0, 10).slide(4)

The problem occurs when:
 - iota is floating type
 - padRight causes padding to the original size of the iota plus the size of
the slide (e.g. 6 + 4 == 10 in the above)

--

[Issue 13865] std.range.rangeSplit

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13865

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Seb  ---
This has been added a long time ago:

https://github.com/dlang/phobos/pull/1965

--

[Issue 13825] relativePath not handling "." and ".." correctly

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13825

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 5849] std.random.dice is better as a range

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5849

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #11 from Seb  ---
FYI: Here's my implementation of the alias method for mir:

https://github.com/libmir/mir/blob/da76cf406d06957e472b9ba90b4c90b917480cb9/source/mir/random/discrete.d

(it's Boost-licensed)

--

[Issue 11597] Speed up std.random.dice

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11597

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
> See Vose's Alias Method:

Here's my implementation for mir:

https://github.com/libmir/mir/blob/da76cf406d06957e472b9ba90b4c90b917480cb9/source/mir/random/discrete.d

tl;dr:
- std.random's methods should be available as Generators / "Variables"
- Until std.random isn't rewritten it probably doesn't make sense to patch it
partially

There's also:

https://issues.dlang.org/show_bug.cgi?id=5849

--

[Issue 13797] std.array.extend

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13797

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Hmm. Why can't we handle this on a language level?

---
int[] arr;
arr ~= [0, 1, 2];
---

works fine. So I don't see any reason why the compiler couldn't be improved to
accept this too:

---
int[] arr;
arr ~= 3.iota;
---

Custom data types can already do this with operator overloading, but built-in
arrays can't.

I submitted an enhancement request:
https://issues.dlang.org/show_bug.cgi?id=18699

--

[Issue 18699] New: D's builtin arrays could allow a more generic opBinaryAssign with range support

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18699

  Issue ID: 18699
   Summary: D's builtin arrays could allow a more generic
opBinaryAssign with range support
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

(from https://issues.dlang.org/show_bug.cgi?id=13797 where it was proposed to
add a new Phobos function for this)

tl;dr: appending an array to an array works fine today:

---
int[] arr;
arr ~= [0, 1, 2];
---

So I don't see any reason why the compiler couldn't be improved to accept this
too:

---
int[] arr;
arr ~= 3.iota;
---

Custom data types can already do this with operator overloading, but this is
not possible for built-in arrays.
The lowering should be trivial as D already allows ranges for `foreach`:

---
int[] arr;
foreach (e; 3.iota)
arr ~= e;
---

--

[Issue 13724] std.datetime.timeIt

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13724

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 13507] std.range.enumerate with BigInt indexes too

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13507

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 13482] std.algorithm.podSort

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13482

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #2 from Seb  ---
> A pair of overloaded functions like this could be useful to add to Phobos to 
> avoid most of the template bloat caused by std.algorithm.sort in the 
> situations where the maximum sorting performance and flexibility (this just 
> accepts an array) is not strictly necessary:

(OP proposes a solution with if constraint "bloat")

I think if there are any issues with std.algorithm.sort / its templates, we
should try to address these instead of promoting such "workarounds" in the
standard library.
Closing as WONTFIX.

Please feel free to open issues regarding sort or problems with templates.

--

[Issue 13473] std.algorithm.expand

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13473

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #3 from Seb  ---
> Aren't all cases of "expand" reducible to "recurrence"? Do you have an 
> example where this isn't possible / is too ugly?

The closest pedant that D has to unfoldr (apart from recurrence) is its
Generator:

---
import std.experimental.all;
void main()
{
new Generator!int({
foreach (i; 0 .. 10)
yield(i);
}).writeln;
}
---

https://run.dlang.io/is/DQgDN3

So I'm not sure if there's anything actionable to be taken from this issue?

--

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18649

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #7 from Martin Nowak  ---
- The libcurl dependency should be demoted to recommended (installed by
default) or suggested, atm. it's still a dependency.

- It's confusing to see libcurl3 as dependency and libcurl4-openssl-dev as
suggestion.
 
https://github.com/dlang/installer/blob/47830a15d1a576b683c92b4bb4adc4a1d83a2b5d/linux/dmd_deb.sh#L347-L348
  Has anyone ever succeeded to install that with `-o
APT::Install-Suggests="true"` or `--install-suggests`?

- It's a pity that debian doesn't have a meta-package for libcurl, but I'd
research how other packages resolved this issue (libcurl-ocaml depends on
libcurl3-gnutls while libcurl-ocaml-dev depends on libcurl4-gnutls-dev).

- Use an alternative package name `libcurl4 | libcurl3` to support
installations without libcurl4 availability. Assuming that all OSes with
libcurl4 switch to that by default, otherwise you'd be back to the conflict.

So how about:
DEPENDS='libc6, libc6-dev, gcc, libgcc1, libstdc++6'
RECOMMENDS='libcurl4 | libcurl3'
SUGGESTS='libcurl4-openssl-dev, gcc-multilib'

--

[Issue 13104] std.typecons.tupleOp

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13104

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---

Have a look at https://github.com/dlang/phobos/pull/6386

with this the following will work:



(tuple(1, 2) ~ tuple(3, 4)).expand.only.sum = 10
(tuple(1, 2) ~ tuple(3, 4)).expand.only.max = 4


> tupleOp2!q{a + b}(tuple(1, 1.5), tuple(2, 3.2))

So here's what we got today:

zip(tuple(1, 1.5).expand.only, tuple(2, 3.2).expand.only).map!(a => a[0] +
a[1]).writeln;

https://run.dlang.io/is/6rq9MB

What I think could be improved:

- make tuples ranges by default (no .expand.only hacks)
- allow map to take a multi-argument lambda if the size of the front's element
is statically known

--

[Issue 12592] std.algorithm.keep to filter range elements and write back to the source range

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12592

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--

[Issue 12844] Absurd RAM Required for ctRegex

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12844

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #10 from Seb  ---
>From https://github.com/dlang/phobos/pull/6164#issuecomment-365175755:

> Another idea is to deprecate ctRegex and stop testing it. It's 100% obvious 
> that it doesn't work on anything significant in practice due to our compiler 
> limitations. Then we enable it again once CTFE works with std.regex.

--

[Issue 18698] static foreach + __traits(allMembers, moduleName)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18698

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #2 from Ketmar Dark  ---
lol. another `static foreach` great feature: `allMembers` tries to expand
`static foreach`, effectively executing it's body, whith calls `allMembers`,
which tries to expand `static foreach`, effectively...

--

[Issue 18452] std.zip has size limit of 2 GB

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18452

Andrei Vasile  changed:

   What|Removed |Added

 CC||andrei.vasil...@gmail.com
   Assignee|nob...@puremagic.com|andrei.vasil...@gmail.com

--

[Issue 18668] Implement modPow() for std.bigint

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18668

Andrei Vasile  changed:

   What|Removed |Added

 CC||andrei.vasil...@gmail.com

--- Comment #1 from Andrei Vasile  ---
Hey, are you currently working on this? I am interested in solving this bug.
Please let me know. Thanks!
Andrei

--

[Issue 18459] The static array ABI doesn't match the struct ABI

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18459

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18459] The static array ABI doesn't match the struct ABI

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18459

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/820b5c8a612dcb862aad1ca32545a186f2e87b6c
fix Issue 18459 - The static array ABI doesn't match the struct ABI

https://github.com/dlang/dmd/commit/56b717c7a6e97db2b8d184c5a17286c67988c8b1
Merge pull request #7912 from WalterBright/fix18459

fix Issue 18459 - The static array ABI doesn't match the struct ABI
merged-on-behalf-of: Iain Buclaw 

--