Re: extern(C++) in win32.mak
On 07/02/2018 6:05 AM, Paul D Anderson wrote:
I don't understand the following line in dmd/src/win32.mak:
extern (C++) __gshared const(char)* ddoc_default = import
("default_ddoc_theme.ddoc");
That is a string import (-J).
What does the word "import" mean in this context? I can't find any
documentation on the use of import in this way, and the line fails to
compile during the make.
https://dlang.org/spec/expression.html#import_expressions
extern(C++) in win32.mak
I don't understand the following line in dmd/src/win32.mak:
extern (C++) __gshared const(char)* ddoc_default = import
("default_ddoc_theme.ddoc");
What does the word "import" mean in this context? I can't find
any documentation on the use of import in this way, and the line
fails to compile during the make.
The error message is:
file "default_ddoc_theme.ddoc" cannot be found or not in a path
specified with -J
The file is in the directory dmd2/src/res, which is specified
with -J../res in the build.
Is there anyone who knows the ins and outs of the makefile that
can shed some light?
Thanks,
Paul
Re: more OO way to do hex string to bytes conversion
On 07/02/2018 4:06 AM, Craig Dillabaugh wrote: On Wednesday, 7 February 2018 at 03:25:05 UTC, rikki cattermole wrote: On 06/02/2018 8:46 PM, Craig Dillabaugh wrote: On Tuesday, 6 February 2018 at 18:46:54 UTC, H. S. Teoh wrote: [...] clip [...] clip [...] Wouldn't it be more accurate to say OO is not the correct tool for every job rather than it is "outdated". How would one write a GUI library with chains and CTFE? But you could with signatures and structs instead ;) I am not sure how this would work ... would this actually be a good idea, or are you just saying that technically it would be possible? A very good idea :) WIP: https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md https://github.com/rikkimax/stdc-signatures/tree/master/stdc
Re: more OO way to do hex string to bytes conversion
On Wednesday, 7 February 2018 at 03:25:05 UTC, rikki cattermole wrote: On 06/02/2018 8:46 PM, Craig Dillabaugh wrote: On Tuesday, 6 February 2018 at 18:46:54 UTC, H. S. Teoh wrote: [...] clip [...] clip [...] Wouldn't it be more accurate to say OO is not the correct tool for every job rather than it is "outdated". How would one write a GUI library with chains and CTFE? But you could with signatures and structs instead ;) I am not sure how this would work ... would this actually be a good idea, or are you just saying that technically it would be possible?
Re: more OO way to do hex string to bytes conversion
On 06/02/2018 8:46 PM, Craig Dillabaugh wrote:
On Tuesday, 6 February 2018 at 18:46:54 UTC, H. S. Teoh wrote:
On Tue, Feb 06, 2018 at 06:33:02PM +, Ralph Doncaster via
Digitalmars-d-learn wrote:
clip
OO is outdated. D uses the range-based idiom with UFCS for chaining
operations in a way that doesn't require you to write loops yourself.
For example:
import std.array;
import std.algorithm;
import std.conv;
import std.range;
// No need to use .toStringz unless you're interfacing with C
auto hex = "deadbeef"; // let compiler infer the type for you
auto bytes = hex.chunks(2) // lazily iterate over `hex` by
digit pairs
.map!(s => s.to!ubyte(16)) // convert each pair to a ubyte
.array; // make an array out of it
// Do whatever you wish with the ubyte[] array.
writefln("%(%02X %)", bytes);
clip
T
Wouldn't it be more accurate to say OO is not the correct tool for every
job rather than it is "outdated". How would one write a GUI library
with chains and CTFE?
But you could with signatures and structs instead ;)
Re: enumerated iteration to struct
On Wednesday, 7 February 2018 at 01:45:27 UTC, Jonathan M Davis
wrote:
Perhaps, but foreach does not support that.
foreach(e; range)
{
...
}
is lowered to something like
for(auto __range = range; !__range.empty; __range.popFront())
{
auto e = __range.front;
...
}
Fun fact: an actual lowering from the compiler:
Result __r39 = iota(2).opSlice();
for (; !__r39.empty(); __r39.popFront())
{
int a = __r39.front();
}
https://run.dlang.io/is/QihjQi
(sorry for being slightly off-topic, but it's always interesting
for me to check whether our assumptions for of the inner-workings
of the compiler are true ...)
Re: enumerated iteration to struct
On Wednesday, February 07, 2018 01:21:16 Fra Mecca via Digitalmars-d-learn
wrote:
> On Wednesday, 7 February 2018 at 01:10:34 UTC, Fra Mecca wrote:
> > I don't know if this post belongs to the learn section, but
> > I'll try anyway.
> >
> > I am using the std.path.pathSplitter function that returns a
> > PathSplitter function exposing ranges primitive.
> >
> > I have some question that could be generalized to other structs
> > that expose range primitives.
> >
> > 1. Why can't I write foreach(i, el;
> > pathSplitter("foor/bar").enumerate) ?
> > 2. Supposing I want to fix this problem, what do I add to the
> > struct? opApply?
>
> There was a stupid stupid error on my part because I wasn't
> import the range module.
>
> > 3. Why doesn't ranges infer the iteration method at compile
> > time so that I don't need to write enumerate?
>
> This question is still valid.
> I think it would be saner to write
> foreach(idx, el; paths)
> instead of
> foreach(idx, el; paths.enumerate)
Perhaps, but foreach does not support that.
foreach(e; range)
{
...
}
is lowered to something like
for(auto __range = range; !__range.empty; __range.popFront())
{
auto e = __range.front;
...
}
In order to support indices, it would need to also add a size_t that it
incremented as it iterated the range, and the language doesn't support that.
It would be useful in many cases, and it would make sense for many ranges,
but it arguably doesn't make sense for others. In particular, it would pose
a problem for infinite ranges, and it's been argued before that for stuff
like AAs where you're not really dealing with a linear list, it doesn't make
sense (though that's debatable, since the range itself is linear even if it
doesn't relate to indices into anything).
Ultimately, it's one of those things where it was trivial to solve with a
library solution, so it wasn't added to the language. I don't know what the
odds would be of a DIP which adds it to the language being accepted, but I
suspect that it would be rejected on the grounds that it's already solved
with a library solution. Over time, Walter and Andrei have increasingly
favored library solutions over language solutions when a library solution
will do the job, though certainly sometimes it's debatable as to whether a
language solution would be better.
- Jonathan M Davis
macOS preview D files
Using finder, I want to see D files shown in the preview column, I some times have with TextMate. Also on my iPhone (in iCloud app, open as a text file) would be a bonus too.
Re: enumerated iteration to struct
On Wednesday, 7 February 2018 at 01:10:34 UTC, Fra Mecca wrote:
I don't know if this post belongs to the learn section, but
I'll try anyway.
I am using the std.path.pathSplitter function that returns a
PathSplitter function exposing ranges primitive.
I have some question that could be generalized to other structs
that expose range primitives.
1. Why can't I write foreach(i, el;
pathSplitter("foor/bar").enumerate) ?
2. Supposing I want to fix this problem, what do I add to the
struct? opApply?
There was a stupid stupid error on my part because I wasn't
import the range module.
3. Why doesn't ranges infer the iteration method at compile
time so that I don't need to write enumerate?
This question is still valid.
I think it would be saner to write
foreach(idx, el; paths)
instead of
foreach(idx, el; paths.enumerate)
enumerated iteration to struct
I don't know if this post belongs to the learn section, but I'll
try anyway.
I am using the std.path.pathSplitter function that returns a
PathSplitter function exposing ranges primitive.
I have some question that could be generalized to other structs
that expose range primitives.
1. Why can't I write foreach(i, el;
pathSplitter("foor/bar").enumerate) ?
2. Supposing I want to fix this problem, what do I add to the
struct? opApply?
3. Why doesn't ranges infer the iteration method at compile time
so that I don't need to write enumerate?
Re: Run-time initialised static variables
On Tuesday, February 06, 2018 23:50:52 dekevin via Digitalmars-d-learn
wrote:
> Thanks a lot! I will change all my initialisations to static
> constructors now.
I should point out that the downside to static constructors is that if you
have modules that recursively depend on each other, the program throws an
Error at startup, because the runtime can't determine the correct order of
initialization. So, while static constructors can be very useful, you do
have to be careful with them.
> The only additional problem I have, is that ℚInf has a disabled
> default constructor.
D does not have default constructors. What you're really disabling is
default initialization. This is an important distinction in understanding
how objects are initialized in D. The init value is known at compile time
and can't involve runtime stuff, whereas a default constructor would be able
to run arbitrary code at runtime.
> Is there a way to allow shared static constructors, but not the
> default constructor?
> struct ℚInf {
> ℚ qval;
> immutable static ℚInf zero;
> @disable this();
> shared static this() {
>zero.qval = ℚ(0);
> }
> this(long num, long den) {
>qval = ℚ(num,den); //this initialisation requires
> dynamically linked code
>}
> }
If you're initializing an immutable variable, you have to initialize it in
one go. What you're doing is letting it be default initialized (which
results in a compilation error, because default initialiaztion is disabled
for that type) and then assigning to one of its members. If the default
initialization weren't disabled, you'd get an error about not being able to
mutate an immutable variable, whereas the fact that you disabled default
initialization but did not explicitly initialize the variable results in a
compilation error about not initializing the variable.
If you want zero to be immutable, you must initialize the entire object at
once. e.g.
zero = QInf(0, 0);
or whatever makes sense. If you need zero to be initialized differently from
other QInfs, then you could make a private constructor that just takes the
value for qval. But it either has to be default initialized with whatever
the init type is (which you clearly don't want, since you disabled that), or
it needs to be explicitly given a value.
- Jonathan M Davis
Re: Run-time initialised static variables
On Tuesday, 6 February 2018 at 23:50:52 UTC, dekevin wrote:
On Tuesday, 6 February 2018 at 23:21:36 UTC, Jonathan M Davis
wrote:
[...]
Thanks a lot! I will change all my initialisations to static
constructors now.
The only additional problem I have, is that ℚInf has a disabled
default constructor.
Is there a way to allow shared static constructors, but not the
default constructor?
struct ℚInf {
ℚ qval;
immutable static ℚInf zero;
@disable this();
shared static this() {
zero.qval = ℚ(0);
}
this(long num, long den) {
qval = ℚ(num,den); //this initialisation requires
dynamically linked code
}
}
Best,
Kevin
I should perhaps add, that I get the following DMD error message:
source/intervalarithmeticrationals.d(15): Error: variable
intervalarithmeticrationals.ℚInf.posinf default construction is
disabled for type immutable(ℚInf)
Re: Run-time initialised static variables
On Tuesday, 6 February 2018 at 23:21:36 UTC, Jonathan M Davis
wrote:
On Tuesday, February 06, 2018 23:03:07 dekevin via
Digitalmars-d-learn wrote:
Hello everyone,
I just ran into the problem, that I need a static variable,
where
the initialisation code for that variable is only accessible
during run-time (since part of the initialisation code will be
dynamically linked).
Is there a way to do this in D?
To be a bit more concrete, this is where I have the problem
(where ℚ uses GMP, which is dynamically linked):
struct ℚInf {
ℚ qval;
immutable static ℚInf zero = ℚInf(0,1);
this(long num, long den) {
qval = ℚ(num,den); //this initialisation requires
dynamically linked code
}
}
So, you want qval to be static and initialized at runtime? Then
use a static constructor. e.g.
struct QInf
{
...
static this()
{
qval = ...;
}
...
}
That doesn't work if you're dealing with a static local
variable, but it works for static members of structs and
classes, and it works for module-level variables.
And if you want to make qval immutable, then use a shared
static constructor. e.g.
struct QInf
{
...
shared static this()
{
qval = ...;
}
...
}
You can currently initialize immutable static variables with
non-shared static constructors, but that's a bug and will
result in the immutable variable being reinitialized whenever a
new thread is created.
- Jonathan M Davis
Thanks a lot! I will change all my initialisations to static
constructors now.
The only additional problem I have, is that ℚInf has a disabled
default constructor.
Is there a way to allow shared static constructors, but not the
default constructor?
struct ℚInf {
ℚ qval;
immutable static ℚInf zero;
@disable this();
shared static this() {
zero.qval = ℚ(0);
}
this(long num, long den) {
qval = ℚ(num,den); //this initialisation requires
dynamically linked code
}
}
Best,
Kevin
Re: Implicit Casting
On 02/06/2018 01:35 PM, Jonathan wrote: > But what I really want it to do is to implicitly cast an `int[2]` to a > `Pos`. > > Is this possible in D? Simply, no. :) Ali
Re: Run-time initialised static variables
On Tuesday, February 06, 2018 23:03:07 dekevin via Digitalmars-d-learn
wrote:
> Hello everyone,
> I just ran into the problem, that I need a static variable, where
> the initialisation code for that variable is only accessible
> during run-time (since part of the initialisation code will be
> dynamically linked).
>
> Is there a way to do this in D?
>
> To be a bit more concrete, this is where I have the problem
> (where ℚ uses GMP, which is dynamically linked):
>
> struct ℚInf {
> ℚ qval;
> immutable static ℚInf zero = ℚInf(0,1);
> this(long num, long den) {
> qval = ℚ(num,den); //this initialisation requires
> dynamically linked code
> }
> }
So, you want qval to be static and initialized at runtime? Then use a static
constructor. e.g.
struct QInf
{
...
static this()
{
qval = ...;
}
...
}
That doesn't work if you're dealing with a static local variable, but it
works for static members of structs and classes, and it works for
module-level variables.
And if you want to make qval immutable, then use a shared static
constructor. e.g.
struct QInf
{
...
shared static this()
{
qval = ...;
}
...
}
You can currently initialize immutable static variables with non-shared
static constructors, but that's a bug and will result in the immutable
variable being reinitialized whenever a new thread is created.
- Jonathan M Davis
Run-time initialised static variables
Hello everyone,
I just ran into the problem, that I need a static variable, where
the initialisation code for that variable is only accessible
during run-time (since part of the initialisation code will be
dynamically linked).
Is there a way to do this in D?
To be a bit more concrete, this is where I have the problem
(where ℚ uses GMP, which is dynamically linked):
struct ℚInf {
ℚ qval;
immutable static ℚInf zero = ℚInf(0,1);
this(long num, long den) {
qval = ℚ(num,den); //this initialisation requires
dynamically linked code
}
}
Shouldn't D be added to this list?
Sorry if this is the wrong place to post, but I just came across this just now: https://www.khronos.org/opengl/wiki/Language_bindings I was thinking that with derelictGL, D should be on this list? If so, I'm not sure how one would go about this?
Re: more OO way to do hex string to bytes conversion
On 02/06/2018 11:55 AM, Ralph Doncaster wrote:
> I'll have to do some more reading about
> maps. My initial though is they don't seem as readable as loops.
Surprisingly, they may be very easy to read in some situations.
> The chunks() is useful, so for now what I'm going with is:
> ubyte[] arr;
> foreach (b; "deadbeef".chunks(2))
> {
> arr ~= b.to!ubyte(16);
> }
That is great but it has two issues that may be important in some programs:
1) It makes multiple allocations as the array grows
2) You need another loop to to do the actual work later on
If you needed to go through the elements just once, the memory
allocations would be wasted. Instead, you can solve both issues with a
chained expression like the ones that has been shown by others.
The cool thing is, you can always hide the ugly bits in a function.
Starting with ag0aep6g's code, I went overboard to pick a better
destination type (other than ubyte) to support different chunk sizes:
void main()
{
import std.stdio;
foreach (b; "deadbeef".hexValues)
{
writefln("%2X", b);
}
// Works for different sized chunks as well:
writeln("12345678".hexValues!4);
}
auto hexValues(size_t digits = 2, ToType =
DefaultTypeForSize!digits)(string s) {
import std.algorithm: map;
import std.conv: to;
import std.range: chunks;
return s.chunks(digits).map!(chars => chars.to!ToType(16));
}
template DefaultTypeForSize(size_t s) {
static if (s == 1) {
alias DefaultTypeForSize = ubyte;
} else static if (s == 2) {
alias DefaultTypeForSize = ushort;
} else static if (s == 4) {
alias DefaultTypeForSize = uint;
} else static if (s == 8) {
alias DefaultTypeForSize = ulong;
} else {
import std.string : format;
static assert(false, format("There is no default %s-byte type",
s));
}
}
Ali
Re: DLangUI Drag and Drop support?
On 2018-02-06 09:32, Andres Clari wrote: But DWT doesn't support macOS right? That would be my main target... Aha, no it doesn't. -- /Jacob Carlborg
Re: dirEntries returns relative, not absolute paths
https://github.com/dlang/phobos/pull/6133 On Tue, Feb 6, 2018 at 1:40 PM, Jonathan M Davis via Digitalmars-d-learn wrote: > On Tuesday, February 06, 2018 18:58:43 number via Digitalmars-d-learn wrote: >> https://dlang.org/phobos/std_file.html#dirEntries >> >> >> The name of each iterated directory entry contains the >> >> absolute path. >> >> it seems to be absolute only if the specified path is absolute, >> or always relative to the parent dir of the specified path. > > Then the docs need to be fixed. > > - Jonathan M Davis >
Re: dirEntries returns relative, not absolute paths
On Tuesday, February 06, 2018 18:58:43 number via Digitalmars-d-learn wrote: > https://dlang.org/phobos/std_file.html#dirEntries > > >> The name of each iterated directory entry contains the > >> absolute path. > > it seems to be absolute only if the specified path is absolute, > or always relative to the parent dir of the specified path. Then the docs need to be fixed. - Jonathan M Davis
Implicit Casting
I am trying to make a `Pos` type. But I need it to implicitly
cast from an `int[2]`.
I am using the `alias this` to get most of what I want but it
still doesn't do all an implicit cast can do.
What I have now is this:
struct Pos {
int[2] pos;
alias pos this;
this (int[2] pos) {
this.pos = pos;
}
}
This allows me to implicitly cast from type `Pos` to type
`int[2]` but not the other way. I can do a sort of cast when I
define a `Pos` (`Pos pos = [2,3]` works).
But what I really want it to do is to implicitly cast an `int[2]`
to a `Pos`.
Is this possible in D?
Re: workspace-d dsymbol Visual Code macOS
[snip] On Tuesday, 6 February 2018 at 20:59:54 UTC, WebFreak001 wrote: can you try git clone https://github.com/Pure-D/workspace-d.git cd workspace-d dub upgrade dub build and then put the resulting path of the executables in your user settings as "d.workspacedPath" I got the same compile time errors.
Re: workspace-d dsymbol Visual Code macOS
On Tuesday, 6 February 2018 at 20:43:55 UTC, Joel wrote: On Tuesday, 6 February 2018 at 19:36:54 UTC, WebFreak001 wrote: On Tuesday, 6 February 2018 at 05:41:19 UTC, Joel wrote: I'm using a macOS (10.12.6) computer. workspace-d used to work, but now it says it's not installed, (I think since I quit out of Visual Code before shutting down the computer). I tried compiling with with the option, but got this: [...] after a reload it should either fix itself or break horribly by not compiling because of a deadlock in dub. Either way try removing ~/.dub/packages/workspace-d* and delete the bin folder in the extension path and reload (also try serve-d if that didn't help) If that still doesn't work report an issue to https://github.com/Pure-D/workspace-d workspace-d and serve-d don't exist in my dub packages. can you try git clone https://github.com/Pure-D/workspace-d.git cd workspace-d dub upgrade dub build and then put the resulting path of the executables in your user settings as "d.workspacedPath"
Re: more OO way to do hex string to bytes conversion
On Tuesday, 6 February 2018 at 18:46:54 UTC, H. S. Teoh wrote:
On Tue, Feb 06, 2018 at 06:33:02PM +, Ralph Doncaster via
Digitalmars-d-learn wrote:
clip
OO is outdated. D uses the range-based idiom with UFCS for
chaining operations in a way that doesn't require you to write
loops yourself. For example:
import std.array;
import std.algorithm;
import std.conv;
import std.range;
// No need to use .toStringz unless you're interfacing with C
auto hex = "deadbeef";// let compiler infer the type for you
auto bytes = hex.chunks(2) // lazily iterate over `hex` by
digit pairs
.map!(s => s.to!ubyte(16))// convert each pair to a ubyte
.array; // make an array out of it
// Do whatever you wish with the ubyte[] array.
writefln("%(%02X %)", bytes);
clip
T
Wouldn't it be more accurate to say OO is not the correct tool
for every job rather than it is "outdated". How would one write
a GUI library with chains and CTFE?
Second, while 'auto' is nice, for learning examples I think
putting the type there is actually more helpful to someone trying
to understand what is happening. If you know the type why not
just write it ... its not like using auto saves you any work in
most cases. I understand that its nice in templates and for
ranges and the like, but for basic types I don't see any
advantage to using it.
Re: workspace-d dsymbol Visual Code macOS
On Tuesday, 6 February 2018 at 19:36:54 UTC, WebFreak001 wrote: On Tuesday, 6 February 2018 at 05:41:19 UTC, Joel wrote: I'm using a macOS (10.12.6) computer. workspace-d used to work, but now it says it's not installed, (I think since I quit out of Visual Code before shutting down the computer). I tried compiling with with the option, but got this: [...] after a reload it should either fix itself or break horribly by not compiling because of a deadlock in dub. Either way try removing ~/.dub/packages/workspace-d* and delete the bin folder in the extension path and reload (also try serve-d if that didn't help) If that still doesn't work report an issue to https://github.com/Pure-D/workspace-d workspace-d and serve-d don't exist in my dub packages.
Re: more OO way to do hex string to bytes conversion
On 2/6/18 1:46 PM, H. S. Teoh wrote:
Of course, this eagerly constructs an array to store the result, which
allocates, and also requires the hex string to be fully constructed
first. You can make this code lazy by turning it into a range
algorithm, then you can actually generate the hex digits lazily from
somewhere else, and process the output bytes as they are generated, no
allocation necessary:
/* Run this example by putting this in a file called 'test.d'
* and invoking `dmd -unittest -main -run test.d`
*/
import std.array;
import std.algorithm;
import std.conv;
import std.format;
import std.range;
import std.stdio;
auto hexToBytes(R)(R hex)
if (isInputRange!R && is(ElementType!R : dchar))
{
return hex.chunks(2)
.map!(s => s.to!ubyte(16));
}
unittest
{
// Infinite stream of hex digits
auto digits = "0123456789abcdef".cycle;
digits.take(100)// take the first 100 digits
.hexToBytes // turn them into bytes
.map!(b => format("%02X", b)) // print in uppercase
.joiner(" ")// nicely delimit bytes with spaces
.chain("\n")// end with a nice newline
.copy(stdout.lockingTextWriter);
// write output directly to stdout
Hm... format in a loop? That returns strings, and allocates. Yuck! ;)
writefln("%(%02X %)", digits.take(100).hexToBytes);
-Steve
Re: DLangUI Drag and Drop support?
On Tuesday, 6 February 2018 at 08:48:47 UTC, aberba wrote: On Saturday, 3 February 2018 at 18:06:30 UTC, Andres Clari wrote: Hi, is there support for drag and drop in dlangui?? I haven't found anything on the docs, issues or forums. I'm building a project that requires support for dropping URLs from the browser into a ListWidget. Is this possible with dlangui at all? Can you please file an issue in the github repo. Its very active so it's possible support will be implemented sooner. I created an issue for it with a basic outline of a possible implementation: https://github.com/buggins/dlangui/issues/553
Re: more OO way to do hex string to bytes conversion
On Tuesday, 6 February 2018 at 18:33:02 UTC, Ralph Doncaster
wrote:
I've been reading std.conv and std.range, trying to figure out
a high-level way of converting a hex string to bytes. The only
way I've been able to do it is through pointer access:
import std.stdio;
import std.string;
import std.conv;
void main()
{
immutable char* hex = "deadbeef".toStringz;
for (auto i=0; hex[i]; i += 2)
writeln(to!byte(hex[i]));
}
Thanks for all the feedback. I'll have to do some more reading
about maps. My initial though is they don't seem as readable as
loops.
The chunks() is useful, so for now what I'm going with is:
ubyte[] arr;
foreach (b; "deadbeef".chunks(2))
{
arr ~= b.to!ubyte(16);
}
Re: workspace-d dsymbol Visual Code macOS
On Tuesday, 6 February 2018 at 05:41:19 UTC, Joel wrote: I'm using a macOS (10.12.6) computer. workspace-d used to work, but now it says it's not installed, (I think since I quit out of Visual Code before shutting down the computer). I tried compiling with with the option, but got this: [...] after a reload it should either fix itself or break horribly by not compiling because of a deadlock in dub. Either way try removing ~/.dub/packages/workspace-d* and delete the bin folder in the extension path and reload (also try serve-d if that didn't help) If that still doesn't work report an issue to https://github.com/Pure-D/workspace-d
Re: Getting compiler Segfault
On Mon, Feb 05, 2018 at 07:30:09PM +, Ur@nuz via Digitalmars-d-learn wrote:
> On Monday, 5 February 2018 at 12:20:05 UTC, Jacob Carlborg wrote:
> > On 2018-02-04 13:52, Ur@nuz wrote:
> > > Getting compiler stack overflow when building my project, but
> > > still do not know how to localize piece of code that triggers this
> > > bug. Maybe this bug is already registered in bugzilla or someone
> > > could give some advice where to dig into?
> > >
> > > Just runed building under gdb and got the following stack trace:
> >
> > Sharing your code (if possible) would help. Building the compiler
> > with debug symbols ("make -f posix.mak DEBUG=1") would help to give
> > file and line info in the stack trace.
>
> I have failed to figure out the source of bug. Seems that my code is
> incorrect somewhere, but compiler crash instead of writing some
> error...
[...]
The compiler should never crash, no matter how bad the input code. An
internal compiler error is always a compiler bug, and a bug report
should be filed. (Though it's probably better to have actual code that
can reproduce the problem, otherwise it will be hard to do anything
about the bug.)
T
--
IBM = I Blame Microsoft
Re: Can't cast from void*
On Tuesday, 6 February 2018 at 08:29:05 UTC, Kagamin wrote: On Monday, 5 February 2018 at 15:33:02 UTC, Steven Schveighoffer wrote: Is there a more pragmatic use case why this should be possible? Maybe for least surprise. The error message almost convinced me that such cast is impossible, only because of my memory that this cast used to be possible kept me trying. Is 5 not good because it's not big enough? Fill a bugreport.
Re: more OO way to do hex string to bytes conversion
On Tuesday, 6 February 2018 at 18:33:02 UTC, Ralph Doncaster
wrote:
I've been reading std.conv and std.range, trying to figure out
a high-level way of converting a hex string to bytes. The only
way I've been able to do it is through pointer access:
import std.stdio;
import std.string;
import std.conv;
void main()
{
immutable char* hex = "deadbeef".toStringz;
for (auto i=0; hex[i]; i += 2)
writeln(to!byte(hex[i]));
}
While it works, I'm wondering if there is a more
object-oriented way of doing it in D.
converting data has nothing to do with OOP.
In D we write like that:
```
import std.range : chunks; // consumes lazily two by
two
import std.algorithm.iteration : map; // apply a func to the
chuncks
import std.conv : to; // the func: convert with
a custom base
import std.array : array; // render the whole stuff
ubyte[] a = "deadbeef".chunks(2).map!(a => a.to!ubyte(16)).array;
```
Re: more OO way to do hex string to bytes conversion
On 02/06/2018 07:33 PM, Ralph Doncaster wrote:
I've been reading std.conv and std.range, trying to figure out a
high-level way of converting a hex string to bytes. The only way I've
been able to do it is through pointer access:
import std.stdio;
import std.string;
import std.conv;
void main()
{
immutable char* hex = "deadbeef".toStringz;
for (auto i=0; hex[i]; i += 2)
writeln(to!byte(hex[i]));
}
While it works, I'm wondering if there is a more object-oriented way of
doing it in D.
I don't think that works as you intend. Your code is taking the numeric
value of every other character.
But you want 0xDE, 0xAD, 0xBE, 0xEF, no? Here's one way to do that, but
I don't think it qualifies as object oriented (but I'm also not sure how
an object oriented solution is supposed to look):
void main()
{
import std.algorithm: map;
import std.conv: to;
import std.range: chunks;
import std.stdio;
foreach (b; "deadbeef".chunks(2).map!(chars => chars.to!ubyte(16)))
{
writefln("%2X", b);
}
}
dirEntries returns relative, not absolute paths
https://dlang.org/phobos/std_file.html#dirEntries
The name of each iterated directory entry contains the
absolute path.
it seems to be absolute only if the specified path is absolute,
or always relative to the parent dir of the specified path.
import std.stdio;import std.stdio;
void main()
{
import std.file;
import std.path;
assert(!"dir".exists);
scope(exit) if ("dir".exists) rmdirRecurse("dir");
mkdirRecurse("dir/dir1/dir2/dir3");
writeln("-");
foreach (DirEntry e; dirEntries("dir", SpanMode.breadth))
{
writeln("e: " ~ e);
}
writeln("-");
foreach (DirEntry e; dirEntries("../" ~ getcwd.baseName ~
"/dir", SpanMode.breadth))
{
writeln("e: " ~ e);
}
writeln("-");
foreach (DirEntry e; dirEntries(getcwd ~ "/dir",
SpanMode.breadth))
{
writeln("e: " ~ e);
}
// -
// e: dir/dir1
// e: dir/dir1/dir2
// e: dir/dir1/dir2/dir3
// -
// e: ../dTests/dir/dir1
// e: ../dTests/dir/dir1/dir2
// e: ../dTests/dir/dir1/dir2/dir3
// -
// e: /home/user/dTests/dir/dir1
// e: /home/user/dTests/dir/dir1/dir2
// e: /home/user/dTests/dir/dir1/dir2/dir3
}
Re: more OO way to do hex string to bytes conversion
On Tue, Feb 06, 2018 at 06:33:02PM +, Ralph Doncaster via
Digitalmars-d-learn wrote:
> I've been reading std.conv and std.range, trying to figure out a
> high-level way of converting a hex string to bytes. The only way I've
> been able to do it is through pointer access:
>
> import std.stdio;
> import std.string;
> import std.conv;
>
> void main()
> {
> immutable char* hex = "deadbeef".toStringz;
> for (auto i=0; hex[i]; i += 2)
> writeln(to!byte(hex[i]));
> }
>
>
> While it works, I'm wondering if there is a more object-oriented way
> of doing it in D.
OO is outdated. D uses the range-based idiom with UFCS for chaining
operations in a way that doesn't require you to write loops yourself.
For example:
import std.array;
import std.algorithm;
import std.conv;
import std.range;
// No need to use .toStringz unless you're interfacing with C
auto hex = "deadbeef"; // let compiler infer the type for you
auto bytes = hex.chunks(2) // lazily iterate over `hex` by digit
pairs
.map!(s => s.to!ubyte(16)) // convert each pair to a ubyte
.array; // make an array out of it
// Do whatever you wish with the ubyte[] array.
writefln("%(%02X %)", bytes);
If you want a reusable way to convert a hex string to bytes, you could
do something like this:
import std.array;
import std.algorithm;
import std.conv;
import std.range;
ubyte[] hexToBytes(string hex)
{
return hex.chunks(2)
.map!(s => s.to!ubyte(16))
.array;
}
Of course, this eagerly constructs an array to store the result, which
allocates, and also requires the hex string to be fully constructed
first. You can make this code lazy by turning it into a range
algorithm, then you can actually generate the hex digits lazily from
somewhere else, and process the output bytes as they are generated, no
allocation necessary:
/* Run this example by putting this in a file called 'test.d'
* and invoking `dmd -unittest -main -run test.d`
*/
import std.array;
import std.algorithm;
import std.conv;
import std.format;
import std.range;
import std.stdio;
auto hexToBytes(R)(R hex)
if (isInputRange!R && is(ElementType!R : dchar))
{
return hex.chunks(2)
.map!(s => s.to!ubyte(16));
}
unittest
{
// Infinite stream of hex digits
auto digits = "0123456789abcdef".cycle;
digits.take(100)// take the first 100 digits
.hexToBytes // turn them into bytes
.map!(b => format("%02X", b)) // print in uppercase
.joiner(" ") // nicely delimit bytes with spaces
.chain("\n") // end with a nice newline
.copy(stdout.lockingTextWriter);
// write output directly to stdout
}
T
--
Designer clothes: how to cover less by paying more.
more OO way to do hex string to bytes conversion
I've been reading std.conv and std.range, trying to figure out a
high-level way of converting a hex string to bytes. The only way
I've been able to do it is through pointer access:
import std.stdio;
import std.string;
import std.conv;
void main()
{
immutable char* hex = "deadbeef".toStringz;
for (auto i=0; hex[i]; i += 2)
writeln(to!byte(hex[i]));
}
While it works, I'm wondering if there is a more object-oriented
way of doing it in D.
Re: Error: template std.conv.parse cannot deduce function from argument types
On Tuesday, 6 February 2018 at 17:47:30 UTC, Adam D. Ruppe wrote: On Tuesday, 6 February 2018 at 17:33:43 UTC, Ralph Doncaster wrote: I get this error when I try the following code: parse specifically works with a reference input it can advance. From the docs: "It takes the input by reference. (This means that rvalues - such as string literals - are not accepted: use to instead.) It advances the input to the position following the conversion." I think the template overloading for parse is getting confused because it sees the lvalue r.l as being of type union rather than ulong. The left hand side of an assignment never plays a role in overloading, so you can disregard that. It is just a string literal cannot be advanced and thus does not work with parse. Thanks! Got it.
Re: Error: template std.conv.parse cannot deduce function from argument types
On Tuesday, 6 February 2018 at 17:33:43 UTC, Ralph Doncaster wrote: I get this error when I try the following code: parse specifically works with a reference input it can advance. From the docs: "It takes the input by reference. (This means that rvalues - such as string literals - are not accepted: use to instead.) It advances the input to the position following the conversion." I think the template overloading for parse is getting confused because it sees the lvalue r.l as being of type union rather than ulong. The left hand side of an assignment never plays a role in overloading, so you can disregard that. It is just a string literal cannot be advanced and thus does not work with parse.
Error: template std.conv.parse cannot deduce function from argument types
I get this error when I try the following code:
struct Record {
union { ubyte[8] bytes; ulong l;}
uint key;
}
Record r;
r.l = parse!ulong("deadbeef", 16);
However the following works:
string s = "deadbeef";
r.l = parse!ulong(s, 16);
And another way that works:
r.l = "deadbeef".to!ulong(16);
I've been doing C/C++ for over 20 years and recently started
playing with D. I think the template overloading for parse is
getting confused because it sees the lvalue r.l as being of type
union rather than ulong. Is this a bug or the way things are
supposed to work?
Re: Can't cast from void*
On 2/6/18 3:29 AM, Kagamin wrote:
On Monday, 5 February 2018 at 15:33:02 UTC, Steven Schveighoffer wrote:
Is there a more pragmatic use case why this should be possible?
Maybe for least surprise. The error message almost convinced me that
such cast is impossible, only because of my memory that this cast used
to be possible kept me trying. Is 5 not good because it's not big enough?
Honestly, I don't know why it's not working. But maybe there is a reason
(i.e. it's not a bug and was done on purpose).
All I meant is that, if you have a more practical correct reason for
casting an integer literal to an interface, then we can show that it's
worth worrying about.
By illustration of what I'm talking about, D complains about this:
int * foo()
{
int x;
return &x;
}
But not this:
int * bar()
{
int x;
int *p = &x;
return p;
}
Complaining about not being able to cast 5 directly to an interface,
when you can do it in 2 statements, may be like complaining that bar
compiles, why not foo?
-Steve
Understanding the AST...
Hello everybody! Last week end I found this post ( https://dlang.org/blog/2017/08/01/a-dub-case-study-compiling-dmd-as-a-library/ ) on the Blog and thought to myself awesome. So I built the library and everything went smooth. Thanks for the effort of all the involved people who made that possible! I've had a look at the 2 examples, too, the avg. function lines ( https://github.com/dlang/dmd/blob/master/src/examples/avg.d ) and the import ( https://github.com/dlang/dmd/blob/master/src/examples/impvisitor.d ) ones and for a start I decided to make a program that prints the outline of a module. Turns out I don't really understand how to access the data in the AST. For everything there's a visitor method and overriding a few of them to print return statements and some such works as advertised. However, I have no idea where I am in the tree when any of those methods are called. Like for example in FunctionLengthVisitor(AST).visitFuncBody(AST.FuncDeclaration fd). I have a function declaration object which tells me everything about what's inside the function, but how do I know what or where this function belongs to, where can I get that information ? I don't see anything about UDAs either, nor the doc comment. I understand when visitor.getAvgLen is called with the parsed module, the accept function calls a visitor overload for each member. But this sounds to me like I'd have to do a lot of book keeping in my visitor to keep track of things which are already present in the AST. Any insight to this would be much appreciated :)
Re: Using file as input to stdin when compiling
On Tuesday, 6 February 2018 at 06:10:30 UTC, Jamie wrote:
Hi, I'm following through TDPL and am trying to import a txt
file during compiling for the stdin.byLine() function to read.
Currently I have
#!/usr/bin/rdmd and would like it to analyse the supplied text file. Is this
possible in the way that I'm thinking, or is there another way?
Thanks
#!/usr/bin/rdmd
That's limitation of the shebang line. Most implementation's only
accept one argument.
https://en.wikipedia.org/wiki/Shebang_(Unix)
However, you can simply do:
./foo.d < foo.text
or:
void main() {
auto f = File(args[1]);
}
or rdmd --loop for tiny scripts:
echo "abc" | rdmd --loop='line.splitter("").writeln
Re: Interactive Interpreter
On Tuesday, 6 February 2018 at 01:23:57 UTC, Stefan Koch wrote: On Monday, 5 February 2018 at 19:54:09 UTC, Jiyan wrote: Is there any work for an interactive interpreter for D -maybe just for ctfe-able expressions? It shouldnt be too hard to implement it regarding the fact, that ctfe is kinda doing what an interpreter should do i guess. There is https://github.com/dlang-community/drepl which should give you what you want. As the person who builds newCTFE I can tell you that it is rather tricky :) Thank you very much :)
Re: DLangUI Drag and Drop support?
On Saturday, 3 February 2018 at 18:06:30 UTC, Andres Clari wrote: Hi, is there support for drag and drop in dlangui?? I haven't found anything on the docs, issues or forums. I'm building a project that requires support for dropping URLs from the browser into a ListWidget. Is this possible with dlangui at all? Can you please file an issue in the github repo. Its very active so it's possible support will be implemented sooner.
Re: DLangUI Drag and Drop support?
On Monday, 5 February 2018 at 12:17:22 UTC, Jacob Carlborg wrote: On 2018-02-03 19:06, Andres Clari wrote: Hi, is there support for drag and drop in dlangui?? I haven't found anything on the docs, issues or forums. I'm building a project that requires support for dropping URLs from the browser into a ListWidget. Is this possible with dlangui at all? DWT [1] supports drag-and-drop. [1] https://github.com/d-widget-toolkit/dwt But DWT doesn't support macOS right? That would be my main target...
Re: Can't cast from void*
On Monday, 5 February 2018 at 15:33:02 UTC, Steven Schveighoffer wrote: Is there a more pragmatic use case why this should be possible? Maybe for least surprise. The error message almost convinced me that such cast is impossible, only because of my memory that this cast used to be possible kept me trying. Is 5 not good because it's not big enough?
