Re: Weird const behavior
On Thursday, 20 December 2018 at 01:37:59 UTC, Simón Oroño wrote: The only difference (code-wise) is the `const` keyword. I've tried with both `ldc` and `dmd` with same result. Why is the output different when the variable is `const`? A const range cannot be iterated by a generic template (without additional work, at least), so writeln just sees it as a blob instead of something it can loop over.
Weird const behavior
I have the following piece of code:
``
#!/bin/env dub
/+ dub.sdl:
name: day2
+/
import std.algorithm.iteration : group;
import std.stdio;
void main() {
const auto a = group("simon");
auto b = group("simon");
writeln(a == b);
writeln();
writeln(a);
writeln();
writeln(b);
}
``
When I run it, it gives me this output:
``
true
const(Group!("a == b", string))("imon", Tuple!(dchar, uint)('s',
1))
[Tuple!(dchar, uint)('s', 1), Tuple!(dchar, uint)('i', 1),
Tuple!(dchar, uint)('m', 1), Tuple!(dchar, uint)('o', 1),
Tuple!(dchar, uint)('n', 1)]
``
The only difference (code-wise) is the `const` keyword. I've
tried with both `ldc` and `dmd` with same result. Why is the
output different when the variable is `const`?
Re: chunkBy array at compile time
On Wed, Dec 19, 2018 at 02:01:28PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 12/19/18 1:30 PM, H. S. Teoh wrote: [...] > > For CTFE, though, we don't really care about calling popFront twice, > > so I surmise that we should be able to just use the original > > non-RefCounted implementation. It's not hard, just take out the bits > > where the subranges communicate with the outer range, and just have > > each subrange carry its own instance of the underlying range. It > > will incur some CTFE performance hit, but that's better than not > > being CTFE-able at all. > > There is a problem here though -- CTFE must compile the same > (essentially) as normal runtime. We can make different code paths for > CTFE, but the problem I see in the meantime is that the TYPE must be > the same. > > In other words, the CTFE version shouldn't use RefCounted, but the > type already has that in there. > > I also see some bad things happening if initialized at compile time > via CTFE, but then used at runtime. But I don't know if that works or > not. [...] Hmph. This is an annoying limitation. :-/ And one of the major downsides of using RefCounted in the implementation. :-( T -- It's bad luck to be superstitious. -- YHL
Re: chunkBy array at compile time
On 12/19/18 1:30 PM, H. S. Teoh wrote: On Wed, Dec 19, 2018 at 01:19:28PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: On 12/19/18 12:20 PM, H. S. Teoh wrote: [...] It was originally a simple wrapper when I first submitted it, but Andrei requested to use RefCounted in order to work around the subrange traversal problem. I.e., in the original implementation, the underlying range traversed twice, once when each subrange is consumed, and once when you call popFront on the outer range. Having RefCounted allows us to retain a reference to the original range so that subranges will also advance the underlying range as seen by the outer range, thereby eliminating calling popFront on the underlying range twice per element. I see, that does pose an issue, especially if you aren't traversing it in order. Communicating back to the "outer" range where the traversal should stop requires having a reference to it in the subrange. However, in terms of a random-access range, or even an array, it should be pretty straightforward to... oh wait, these are narrow strings. nevermind. [...] For CTFE, though, we don't really care about calling popFront twice, so I surmise that we should be able to just use the original non-RefCounted implementation. It's not hard, just take out the bits where the subranges communicate with the outer range, and just have each subrange carry its own instance of the underlying range. It will incur some CTFE performance hit, but that's better than not being CTFE-able at all. There is a problem here though -- CTFE must compile the same (essentially) as normal runtime. We can make different code paths for CTFE, but the problem I see in the meantime is that the TYPE must be the same. In other words, the CTFE version shouldn't use RefCounted, but the type already has that in there. I also see some bad things happening if initialized at compile time via CTFE, but then used at runtime. But I don't know if that works or not. -Steve
Re: chunkBy array at compile time
On Wed, Dec 19, 2018 at 01:19:28PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 12/19/18 12:20 PM, H. S. Teoh wrote: [...] > > It was originally a simple wrapper when I first submitted it, but > > Andrei requested to use RefCounted in order to work around the > > subrange traversal problem. I.e., in the original implementation, > > the underlying range traversed twice, once when each subrange is > > consumed, and once when you call popFront on the outer range. Having > > RefCounted allows us to retain a reference to the original range so > > that subranges will also advance the underlying range as seen by the > > outer range, thereby eliminating calling popFront on the underlying > > range twice per element. > > I see, that does pose an issue, especially if you aren't traversing it > in order. Communicating back to the "outer" range where the traversal > should stop requires having a reference to it in the subrange. > > However, in terms of a random-access range, or even an array, it > should be pretty straightforward to... oh wait, these are narrow > strings. nevermind. [...] For CTFE, though, we don't really care about calling popFront twice, so I surmise that we should be able to just use the original non-RefCounted implementation. It's not hard, just take out the bits where the subranges communicate with the outer range, and just have each subrange carry its own instance of the underlying range. It will incur some CTFE performance hit, but that's better than not being CTFE-able at all. T -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Re: chunkBy array at compile time
On 12/19/18 12:20 PM, H. S. Teoh wrote: On Wed, Dec 19, 2018 at 10:38:06AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: [...] Looking at the code for chunkBy, it seems to me that the implementation is quite complex for what in my head should be a simple wrapper... [...] It was originally a simple wrapper when I first submitted it, but Andrei requested to use RefCounted in order to work around the subrange traversal problem. I.e., in the original implementation, the underlying range traversed twice, once when each subrange is consumed, and once when you call popFront on the outer range. Having RefCounted allows us to retain a reference to the original range so that subranges will also advance the underlying range as seen by the outer range, thereby eliminating calling popFront on the underlying range twice per element. I see, that does pose an issue, especially if you aren't traversing it in order. Communicating back to the "outer" range where the traversal should stop requires having a reference to it in the subrange. However, in terms of a random-access range, or even an array, it should be pretty straightforward to... oh wait, these are narrow strings. nevermind. -Steve
Re: chunkBy array at compile time
On Wed, Dec 19, 2018 at 10:38:06AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: [...] > Looking at the code for chunkBy, it seems to me that the > implementation is quite complex for what in my head should be a simple > wrapper... [...] It was originally a simple wrapper when I first submitted it, but Andrei requested to use RefCounted in order to work around the subrange traversal problem. I.e., in the original implementation, the underlying range traversed twice, once when each subrange is consumed, and once when you call popFront on the outer range. Having RefCounted allows us to retain a reference to the original range so that subranges will also advance the underlying range as seen by the outer range, thereby eliminating calling popFront on the underlying range twice per element. T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
Re: using dub to compile plugins
On Wednesday, 19 December 2018 at 16:31:57 UTC, Andre Pany wrote: On Wednesday, 19 December 2018 at 14:08:10 UTC, Codifies wrote: On Wednesday, 19 December 2018 at 13:14:20 UTC, Andre Pany wrote: On Wednesday, 19 December 2018 at 12:57:14 UTC, Codifies wrote: [...] You can use dub sub packages. Each plugin will be a dub package with its own dub descriptor (sdl) file. For your main dub sdl you set targetType to None. Kind regards Andre how could I have multiple dub files in the same directory for each plugin ??? You have sub folders in which you create the dub.sdl files. In your main dub.sdl you include these folders as sub packages. Regarding the automatic logic you ideally want to have: there is the plan to add dub extension plugins. Unfortunately a hero is needed to implement it. Kind regards Andre I was planning to have all the plugin sources in one directory otherwise I'd have loads of folders all over the place... I think Make is the way forward!
Re: Bug in shifting
On Tuesday, 18 December 2018 at 20:33:43 UTC, Rainer Schuetze
wrote:
On 14/12/2018 02:56, Steven Schveighoffer wrote:
On 12/13/18 7:16 PM, Michelle Long wrote:
byte x = 0xF;
ulong y = x >> 60;
Surely you meant x << 60? As x >> 60 is going to be 0, even
with a ulong.
It doesn't work as intuitive as you'd expect:
void main()
{
int x = 256;
int y = 36;
int z = x >> y;
writeln(z);
}
prints "16" without optimizations and "0" with optimizations.
This happens for x86 architecture because the processor just
uses the lower bits of the shift count. It is probably the
reason why the language disallows shifting by more bits than
the size of the operand.
Yes. On x86 shifting (x >> y) is in reality x >> (y & 0x1F) on 32
bits and x >> (y & 0x3F) on 64 bits.
Re: using dub to compile plugins
On Wednesday, 19 December 2018 at 14:08:10 UTC, Codifies wrote: On Wednesday, 19 December 2018 at 13:14:20 UTC, Andre Pany wrote: On Wednesday, 19 December 2018 at 12:57:14 UTC, Codifies wrote: [...] You can use dub sub packages. Each plugin will be a dub package with its own dub descriptor (sdl) file. For your main dub sdl you set targetType to None. Kind regards Andre how could I have multiple dub files in the same directory for each plugin ??? You have sub folders in which you create the dub.sdl files. In your main dub.sdl you include these folders as sub packages. Regarding the automatic logic you ideally want to have: there is the plan to add dub extension plugins. Unfortunately a hero is needed to implement it. Kind regards Andre
Re: Temporary @trusted scope
On 20/12/2018 5:02 AM, Jonathan M Davis wrote: On Wednesday, December 19, 2018 1:19:42 AM MST rikki cattermole via Digitalmars-d-learn wrote: On 19/12/2018 7:11 PM, Jonathan M Davis wrote: Really? I would have thought that that would be a pretty obvious optimization (especially if inlining is enabled). Assembly doesn't lie. I'm not saying that you're wrong, just expressing surprise. I've never checked to see what code actually got generated. But I do think that it's something that the compiler should be smart enough to do even if it isn't currently that smart, and the fact that it isn't is most defintely not a good thing. - Jonathan M Davis I agree, this would be a very simple AST rewrite. Would be well worth doing since its a common-ish pattern.
Re: Temporary @trusted scope
On Wednesday, December 19, 2018 1:19:42 AM MST rikki cattermole via Digitalmars-d-learn wrote: > On 19/12/2018 7:11 PM, Jonathan M Davis wrote: > > Really? I would have thought that that would be a pretty obvious > > optimization (especially if inlining is enabled). > > Assembly doesn't lie. I'm not saying that you're wrong, just expressing surprise. I've never checked to see what code actually got generated. But I do think that it's something that the compiler should be smart enough to do even if it isn't currently that smart, and the fact that it isn't is most defintely not a good thing. - Jonathan M Davis
Re: Temporary @trusted scope
On Tuesday, 18 December 2018 at 13:52:29 UTC, Steven
Schveighoffer wrote:
On 12/18/18 6:29 AM, Simen Kjærås wrote:
@safe unittest {
unsafe!({
fun(2);
});
unsafe!fun(2);
}
Wow, I really like this. The only real problem is that one
generally searches for @trusted when looking for unsafe code,
but unsafe is pretty obvious too. Also, args should be auto ref.
While @trusted wouldn't work, it could be named 'trusted' instead
of 'unsafe'. That's not gonna help those who search for
'@trusted', but it's closer, at least.
--
Simen
Re: Mixin operator 'if' directly
On Wed, 19 Dec 2018 15:12:14 +, bauss wrote:
> That's assuming that it's compile-time data though.
>
> If not then you can't do what you want to do.
>
> What you can do is wrap it in a function in the mixin template which you
> just call after instantiating it.
Or while instantiating it:
mixin template foo()
{
int _ignoreme()
{
if (readln.strip == "abort") throw new AbortException;
return 1;
}
int _alsoIgnoreMe = _ignoreme();
}
void main()
{
mixin foo;
}
Re: chunkBy array at compile time
On 12/19/18 3:20 AM, Andrey wrote:
Hi,
I have got this code:
import std.array : array;
import std.algorithm.mutation;
import std.algorithm.iteration;
import std.stdio;
void main()
{
string input = "sieviaghp";
enum data = ["emo", "emoze", "emow", "emuo", "evuo", "ete", "ie",
"vuo", "sie", "w"];
enum index = 3;
enum filtered = data.filter!(value => value.length > index).array();
pragma(msg, filtered);
enum GetSeq = filtered.chunkBy!((first, second) => first[index] ==
second[index]);//.array();
pragma(msg, GetSeq);
}
There is an array of strings. I filter it using length of each element.
Result should be:
["emoze", "emow", "emuo", "evuo"]
Then I want to chuck it using symbol at position 'index' to get this:
["emoze"] // group 1, symbol 'z'
["emow"] // group 2, symbol 'w'
["emuo", "evuo"] // group 1, symbol 'o'
Everything I'm doing at COMPILE time!
But when I try to build program I get this strange error:
/dlang/dmd/linux/bin64/../../src/druntime/import/core/memory.d(827):
Error: `fakePureErrno` cannot be interpreted at compile time, because
it has no available source code
onlineapp.d(15): compile time context created here
Probably because it's using RefCounted.
Looking at the code for chunkBy, it seems to me that the implementation
is quite complex for what in my head should be a simple wrapper...
-Steve
Re: Mixin operator 'if' directly
On Wednesday, 19 December 2018 at 15:09:47 UTC, bauss wrote:
On Wednesday, 19 December 2018 at 13:37:17 UTC, Andrey wrote:
Hi,
Here is a template mixin:
mixin template create(alias input, uint index, alias data)
{
if(input.length < index) return;
// ... some code
}
When I try to compile it, I get:
Error: declaration expected, not if
Is it possible to mixin operator 'if' directly inside my
template mixin?
What you want to use is "static if".
The correct way to do the above would be this:
mixin template create(alias input, uint index, alias data)
{
static if(input.length >= index) // Reversed the logic.
{
// ... some code
}
}
That's assuming that it's compile-time data though.
If not then you can't do what you want to do.
What you can do is wrap it in a function in the mixin template
which you just call after instantiating it.
Re: Mixin operator 'if' directly
On Wednesday, 19 December 2018 at 13:37:17 UTC, Andrey wrote:
Hi,
Here is a template mixin:
mixin template create(alias input, uint index, alias data)
{
if(input.length < index) return;
// ... some code
}
When I try to compile it, I get:
Error: declaration expected, not if
Is it possible to mixin operator 'if' directly inside my
template mixin?
What you want to use is "static if".
The correct way to do the above would be this:
mixin template create(alias input, uint index, alias data)
{
static if(input.length >= index) // Reversed the logic.
{
// ... some code
}
}
Re: using dub to compile plugins
On Wed, 19 Dec 2018 12:57:14 +, Codifies wrote: > I could do this with a few simple rules in a Makefile, but I have no > clue how to achieve this using dub. If you need dub, you can create a wrapper script that generates the dub file for the plugins directory. Make is a lot better for this kind of thing.
Re: using dub to compile plugins
On Wednesday, 19 December 2018 at 13:14:20 UTC, Andre Pany wrote: On Wednesday, 19 December 2018 at 12:57:14 UTC, Codifies wrote: [...] You can use dub sub packages. Each plugin will be a dub package with its own dub descriptor (sdl) file. For your main dub sdl you set targetType to None. Kind regards Andre how could I have multiple dub files in the same directory for each plugin ???
Re: Mixin operator 'if' directly
Mixin templates don't work on statements only declarations like structs.
Mixin operator 'if' directly
Hi,
Here is a template mixin:
mixin template create(alias input, uint index, alias data)
{
if(input.length < index) return;
// ... some code
}
When I try to compile it, I get:
Error: declaration expected, not if
Is it possible to mixin operator 'if' directly inside my template
mixin?
Re: using dub to compile plugins
On Wednesday, 19 December 2018 at 12:57:14 UTC, Codifies wrote: I am currently using this dub.sdl name"runz80" targetType "executable" lflags "libz80/libz80.a" however I will be creating a number of plugins, each plugin will consist of a single source file, I'd like the plugin source directory to be separate from main source directory and compile the plugins (.so) to a (binary) plugins directory (the plugins will be dynamically loaded at runtime - I've previously done this in C so I don't anticipate any particular issues - famous last words!) I could do this with a few simple rules in a Makefile, but I have no clue how to achieve this using dub. can someone show me a concrete example of doing this ? Ideally just dropping a new source file into the plugins source folder should produce a new .so the next time dub is run, without having to explicitly add each plugin to the dub file... You can use dub sub packages. Each plugin will be a dub package with its own dub descriptor (sdl) file. For your main dub sdl you set targetType to None. Kind regards Andre
Re: using dub to compile plugins
oh forgot to add just for extra pain while the main application won't need gtk, most of the plugins will...
using dub to compile plugins
I am currently using this dub.sdl name"runz80" targetType "executable" lflags "libz80/libz80.a" however I will be creating a number of plugins, each plugin will consist of a single source file, I'd like the plugin source directory to be separate from main source directory and compile the plugins (.so) to a (binary) plugins directory (the plugins will be dynamically loaded at runtime - I've previously done this in C so I don't anticipate any particular issues - famous last words!) I could do this with a few simple rules in a Makefile, but I have no clue how to achieve this using dub. can someone show me a concrete example of doing this ? Ideally just dropping a new source file into the plugins source folder should produce a new .so the next time dub is run, without having to explicitly add each plugin to the dub file...
Re: Doubt about this book: The D Programming Language
On Sunday, 16 December 2018 at 18:37:15 UTC, Marko wrote: On Amazon The D Programming Language has good reviews but it's 8 years old. So is this book still relevant today? Yes, I would recommend it. It is meant to be comprehensive but introductory, so many language or library changes since are out of the scope anyway. It's then also quite different from a cookbook approach for example -- depends what you're looking for. You may perhaps compare it more closely with Ali's book, but unfortunately I haven't read this one.
chunkBy array at compile time
Hi,
I have got this code:
import std.array : array;
import std.algorithm.mutation;
import std.algorithm.iteration;
import std.stdio;
void main()
{
string input = "sieviaghp";
enum data = ["emo", "emoze", "emow", "emuo", "evuo", "ete",
"ie", "vuo", "sie", "w"];
enum index = 3;
enum filtered = data.filter!(value => value.length >
index).array();
pragma(msg, filtered);
enum GetSeq = filtered.chunkBy!((first, second) =>
first[index] == second[index]);//.array();
pragma(msg, GetSeq);
}
There is an array of strings. I filter it using length of each
element. Result should be:
["emoze", "emow", "emuo", "evuo"]
Then I want to chuck it using symbol at position 'index' to get
this:
["emoze"] // group 1, symbol 'z'
["emow"] // group 2, symbol 'w'
["emuo", "evuo"] // group 1, symbol 'o'
Everything I'm doing at COMPILE time!
But when I try to build program I get this strange error:
/dlang/dmd/linux/bin64/../../src/druntime/import/core/memory.d(827): Error:
`fakePureErrno` cannot be interpreted at compile time, because it has no
available source code
onlineapp.d(15):compile time context created here
So, what is wrong here and how to chunkBy at compile time?
Re: Temporary @trusted scope
On 19/12/2018 7:11 PM, Jonathan M Davis wrote: Really? I would have thought that that would be a pretty obvious optimization (especially if inlining is enabled). Assembly doesn't lie.
Re: Temporary @trusted scope
On Wednesday, 19 December 2018 at 06:11:48 UTC, Jonathan M Davis wrote: Really? I would have thought that that would be a pretty obvious optimization (especially if inlining is enabled). I suppose that it doesn't entirely surprise me if dmd does a poor job of it, but I would have expected ldc to do better than that. I would think that such an improvement would be pretty low-hanging fruit for adding to dmd's optimizer though. AFAIK, it was added.
Re: Temporary @trusted scope
On Tuesday, 18 December 2018 at 12:42:12 UTC, rikki cattermole wrote: Yes except for ldc with -O3. ldc with -O2 generates the same code.
