Re: writeln and write at CTFE
On 13.01.21 21:47, tsbockman via Digitalmars-d-learn wrote:
Is CTFE I/O a standard feature in other languages? How many other languages even have a CTFE
feature comparable to D's?
Just two langs I use from time to time:
1) nim via forced ctfe; way faster than d by running through a vm:
const foo = fib(42)
static:
echo "foobar"
2) crystal via macros:
{{ puts "foobar" }}
Another one would be zig via comptime, but never tried that.
Re: Parameter with indetermined tuple elements type?
On 11.01.21 16:27, Marcone via Digitalmars-d-learn wrote:
function [...] without template.
And why don't you want to use templates for that? It's as easy as that:
import std;
auto foo(T)(T tup) if (isTuple!T) {
// statically introspect tuple here ...
return tup;
}
void main()
{
writeln(foo(tuple(1, "2", '3')));
writeln(foo(tuple()));
//writeln(foo("not a tuple")); // fails to compile
}
[1] https://run.dlang.io/is/VYk9Y9
Re: How can I directly reffer literal element itself inside [] slice?
On 11.01.21 16:45, Marcone via Digitalmars-d-learn wrote:
"Hello World"[0..?.indexOf("o")]
Does until [1] do the trick?
"Hello World".until("o") // => "Hell"
[1] https://dlang.org/library/std/algorithm/searching/until.html
Re: dirEntries: How get "." and ".."?
On 10.01.21 23:15, kdevel via Digitalmars-d-learn wrote: Don't you already know "." as the path you passed to dirEntries? I don't know the change date, the uid/gid etc. Not as sexy, but can't you manually construct DirEntries [1] by supplying the paths via std.path [2]? DirName [3] should give you the current/parent directory, for example. [1] https://dlang.org/library/std/file/dir_entry.html [2] https://dlang.org/phobos/std_path.html [3] https://dlang.org/phobos/std_path.html#.dirName
Re: DConf talk : Exceptions will disappear in the future?
On 04.01.21 16:39, ludo456 via Digitalmars-d-learn wrote: Can someone point me to an article or more explanations about that? already came up, see: https://forum.dlang.org/thread/jnrvugxqjzenykztt...@forum.dlang.org https://forum.dlang.org/thread/lhyagawrjzzmrtbok...@forum.dlang.org
Re: Reading files using delimiters/terminators
On 28.12.20 00:12, Rekel via Digitalmars-d-learn wrote: is there a reason to use either 'splitter' or 'split'? split gives you a newly allocated array with the results, splitter is lazy equivalent and doesn't allocate. Feel free using either, doesn't matter much with these small puzzle inputs. Sidetangent, don't mean to bash the learning tour, as it's been really useful for getting started, but I'm surprised stuff like tuples and files arent mentioned there. Especially since the documentation tends to trip me up, with stuff like 'isSomeString' mentioning 'built in string types', while I haven't been able to find that concept elsewhere, let alone functionality one can expect in this case (like .length and the like), and stuff like 'countUntil' not being called 'indexOf', although it also exists and does basically the same thing. Also assumeUnique seems to be a thing? Might be worth discussing that in a new topic. The stdlib is vast and has tons of useful utilities, not all of which can be explained in detail in a series of overview posts. Ali's "Programming in D" [1], which has a free online version, functions as an excellent in-depth introduction to the language, going over all the important topics. Regarding function names and docs: Yes, some might seem slightly off coming from other languages (e.g. find vs. dropWhile, until vs. takeWhile, cumulativeFold vs scan/accumulate, etc.), but it's all in there somewhere, implemented with the most care to not waste precious cycles. Might makes it harder to grok going over the implementation or docs for very the first time, but it gets easier after a while. Furthermore, alternative names are often times mentioned in the docs so a quick google search should bring you to the right place. [1] http://ddili.org/ders/d.en/index.html
Re: Reading files using delimiters/terminators
On 27.12.20 01:13, Rekel via Digitalmars-d-learn wrote:
For context, I'm trying this with the puzzle input of day 6 of this year's advent of code.
(https://adventofcode.com/)
For that specific puzzle I simply did:
foreach (group; readText("input").splitter("\n\n")) { ... }
Since the input is never that big, I prefer reading in the whole thing and then
do the processing.
Also, on other days, when the input is more uniform, there's always
https://dlang.org/library/std/file/slurp.html which makes reading it in even easier, e.g. day02:
alias Record = Tuple!(int, "low", int, "high", char, "needle", string, "hay");
auto input = slurp!Record("input", "%d-%d %s: %s");
P.S.: would've loved to have had multiwayIntersection in the stdlib for day06 part2, especially when
there's already multiwayUnion in setops. fold!setIntersection felt a bit clunky.
Re: low-latency GC
On 06.12.20 06:16, Bruce Carneal via Digitalmars-d-learn wrote: How difficult would it be to add a, selectable, low-latency GC to dlang? Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"? I've heard Walter mention performance issues (write barriers IIRC). I'm also interested in the GC-flavor performance trade offs but here I'm just asking about feasibility. What our closest competition, Nim, is up to with their mark-and-sweep replacement ORC [1]: ORC is the existing ARC algorithm (first shipped in version 1.2) plus a cycle collector [...] ARC is Nim’s pure reference-counting GC, however, many reference count operations are optimized away: Thanks to move semantics, the construction of a data structure does not involve RC operations. And thanks to “cursor inference”, another innovation of Nim’s ARC implementation, common data structure traversals do not involve RC operations either! [...] Benchmark: Metric/algorithm ORCMark Latency (Avg) 320.49 us 65.31 ms Latency (Max)6.24 ms 204.79 ms Requests/sec30963.96282.69 Transfer/sec 1.48 MB 13.80 KB Max memory 137 MiB 153 MiB That’s right, ORC is over 100 times faster than the M GC. The reason is that ORC only touches memory that the mutator touches, too. [...] - uses 2x less memory than classical GCs - can be orders of magnitudes faster in throughput - offers sub-millisecond latencies - suited for (hard) realtime systems - no “stop the world” phase - oblivious to the size of the heap or the used stack space. [1] https://nim-lang.org/blog/2020/12/08/introducing-orc.html
Re: low-latency GC
On 06.12.20 06:16, Bruce Carneal via Digitalmars-d-learn wrote: How difficult would it be to add a, selectable, low-latency GC to dlang? Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"? I've heard Walter mention performance issues (write barriers IIRC). I'm also interested in the GC-flavor performance trade offs but here I'm just asking about feasibility. What our closest competition, Nim, is up to with their mark-and-sweep replacement ORC [1]: ORC is the existing ARC algorithm (first shipped in version 1.2) plus a cycle collector [...] ARC is Nim’s pure reference-counting GC, however, many reference count operations are optimized away: Thanks to move semantics, the construction of a data structure does not involve RC operations. And thanks to “cursor inference”, another innovation of Nim’s ARC implementation, common data structure traversals do not involve RC operations either! [...] Benchmark: Metric/algorithm ORCMark Latency (Avg) 320.49 us 65.31 ms Latency (Max)6.24 ms 204.79 ms Requests/sec30963.96282.69 Transfer/sec 1.48 MB 13.80 KB Max memory 137 MiB 153 MiB That’s right, ORC is over 100 times faster than the M GC. The reason is that ORC only touches memory that the mutator touches, too. [...] - uses 2x less memory than classical GCs - can be orders of magnitudes faster in throughput - offers sub-millisecond latencies - suited for (hard) realtime systems - no “stop the world” phase - oblivious to the size of the heap or the used stack space. There's also some discussion on /r/programming [2] and hackernews [3], but it hasn't taken off yet. [1] https://nim-lang.org/blog/2020/12/08/introducing-orc.html [2] https://old.reddit.com/r/programming/comments/k95cc5/introducing_orc_nim_nextgen_memory_management/ [3] https://news.ycombinator.com/item?id=25345770
Re: Error: `std.uni.isUpper` conflicts with `std.ascii.isUpper`
On 2020-07-14 22:37, Marcone via Digitalmars-d-learn wrote:
import std: isUpper, writeln;
void main(){
writeln(isUpper('A'));
}
Why I get this error? How can I use isUpper()?
Two more options:
either fully qualify the name:
import std;
void main(){
writeln(std.uni.isUpper('A'));
}
or import locally:
import std;
void main(){
import std.uni;
writeln(isUpper('A'));
}
Re: Error: `std.uni.isUpper` conflicts with `std.ascii.isUpper`
On 2020-07-14 22:37, Marcone via Digitalmars-d-learn wrote:
import std: isUpper, writeln;
void main(){
writeln(isUpper('A'));
}
Why I get this error? How can I use isUpper()?
Two more options:
either fully qualify the name:
import std;
void main(){
writeln(std.uni.isUpper('A'));
}
or import locally:
import std;
void main(){
import std.uni;
writeln(isUpper('A'));
}
