Re: Enum that can be 0 or null
On Monday, 6 June 2016 at 20:32:23 UTC, Alex Parrill wrote:
They'd be the same type, since you would define the vulkan
functions to take these structures instead of pointer or
integer types.
It relies on a lot of assumptions about the ABI that make a raw
pointer work the same as a structure containing just one
pointer, which is why I did not give it much consideration.
Is there a way to use opCast (just an idea, not working code) ?
private struct VK_HANDLE_HELPER {
const void * handle = null;
alias handle this;
T opCast(T)() if( is( T == uint64_t )) {
return 0uL;
}
}
const VK_NULL_HANDLE = VK_HANDLE_HELPER();
Re: How to enable feedback for AssertError?
On Tuesday, 7 June 2016 at 02:05:00 UTC, Seb wrote: On Tuesday, 7 June 2016 at 01:40:01 UTC, your_name wrote: The way I traced the problem, ironically ;), was to catch Error and print it to screen. It involved dereferencing a null pointer in a thread and an 'assert null this' silently killed the thread leaving me wondering why it didn't produce data. Anyhow, I've had this behavior at least 1 more time but I forgot what exactly it was related to. Maybe I missed something beyond building a normal -debug version. Anyways, thanks for your reply :) Please open an issue - this sounds like a big then. Exceptions thrown from spawned threads do not, by default, terminate the main thread, so they will not be printed to the screen unless it's done explicitly. See this old forum thread at [1]. Note this quote from Sean Kelley (the original maintainer of DRuntime): "Oh, I should mention that if you use core.thread explicitly, any unhandled exception will be re-thrown in the context of whoever joins that thread." [1] http://forum.dlang.org/post/mailman.1153.130030.31962.digitalmars-d-le...@puremagic.com
Re: Parse File at compile time, but not embedded
If I use an enum dmd DOES remove it in release build. But I'm not sure for the general case yet.
Re: Parse File at compile time, but not embedded
On Tuesday, 7 June 2016 at 02:04:41 UTC, Mithun Hunsur wrote:
On Monday, 6 June 2016 at 21:57:20 UTC, Pie? wrote:
On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote:
[...]
This doesn't seem to be the case. In a release build, even
though I never "use" the string, it is embedded. I guess this
is due to not using enum but enum seems to be much harder to
work with if not impossible.
[...]
Not necessarily, You chased that rabbit quite far! The data
your reading could contain sensitive information only used at
compile time and not meant to embed. For example, the file
could contain login and password to an SQL database that you
then connect, at compile time and retrieve that information
the disregard the password(it is not needed at run time).
This is definitely possible, but it can depend on your
compiler. If you use an enum, it'll be treated as a
compile-time constant - so if you never store it anywhere (i.e.
enum File = import('file.txt'); string file = File; is a no-no
at global scope), you should be fine.
If you do find yourself in the precarious situation of storing
the data, then it's up to your compiler to detect that there
are no runtime references to the data and elide it. LDC and GDC
most likely do this, but I doubt DMD would.
For safety, you should try and reformulate your code in terms
of enums and local variables; this *should* work with DMD, but
it's possible it's not smart enough to catch onto the fact that
the function is never used at run-time (and therefore does not
need to be included in the executable).
Ok, I will assume it will be able to be removed for release. It
is an easy check(just search if binary contains file info). I'm
sure an easy fix could be to write 0's over the data in the
binary if necessary.
If I use an enum dmd does *not* remove it in release build. I
will work on parsing the file using CTFE and hopefully dmd will
not try to keep it around, or it can be solved using gdc/ldc or
some other method.
Re: Windows system casting
On Tuesday, 7 June 2016 at 04:06:01 UTC, Mike Parker wrote: Fourth, while casting the string directly to void* will work, it's considered best practice to use the pointer property for clarity. Oops! cast(void*)path.ptr In both cases. Like I said, without .ptr, it works, but this makes it clear at a glance what's going on.
Re: Windows system casting
On Monday, 6 June 2016 at 19:52:36 UTC, Alexander Patapoff wrote:
import std.stdio;
import std.string;
import core.sys.windows.windows;
void main() {
string filepath =
"C:\\Users\\awpat\\Pictures\\patterns_00387591.jpg";
auto p = toStringz(filepath);
int result;
result = SystemParametersInfo(cast(uint)SPI_SETDESKWALLPAPER,
cast(uint)0, cast(void*)p ,cast(uint)SPIF_UPDATEINIFILE);
}
I'm trying to change the background of my computer. to do this
I must convert my string to a const char*, then that can
implicitly to a (PVOID). I believe that I am losing all my data
in the casting process, is there a way for me to keep my data?
or if I am casting this improperly can you demonstrate and
explain the proper way to cast to a void pointer (PVOID)?
First, Win32 API functions that deal with strings generally come
in two flavors, such as SystemParametersInfoA and
SystemParametersInfoW. The A variety deals char strings and the W
variety deals with UTF16 (wchar in D). By default, the bindings
in DRuntime alias the non-suffixed names to the W variety, so
SystemParametersInfo is an alias for SystemParametersInfoW. That
means you need to use wchar, rather than char for your string
parameter unless you call SystemParaetmersInfoA explicitly.
Second, string literals in D are always null terminated, so
there's no need to call toStringz (or std.utf.toUTF16z for wchar
strings) in this case.
Third, you don't need all of those casts in there. I assume you
tried it without the casts, saw an error message where all the
types were different, then applied the casts to all the
parameters. No need. It's only necessary for the string pointer.
Fourth, while casting the string directly to void* will work,
it's considered best practice to use the pointer property for
clarity.
With all of that in mind, either of the following should work for
you:
// Using string -- note the A suffic on the function name
auto path = "C:\\Users\\awpat\\Pictures\\patterns_00387591.jpg";
auto result = SystemParametersInfoA(SPI_SETDESKWALLPAPER, 0,
cast(void*)path ,SPIF_UPDATEINIFILE);
assert(result);
// Using wstring -- note the w suffix on the string literal
auto path = "C:\\Downloads\\LearningD_Cover.jpg"w;
auto result = SystemParametersInfo(SPI_SETDESKWALLPAPER, 0,
cast(void*)path ,SPIF_UPDATEINIFILE);
assert(result);
Error: castSwitch
import std.algorithm.iteration : map;
import std.algorithm : castSwitch;
import std.format : format;
class A { int value; this(int value) { this.value = value; }}
interface I { }
class B : I { }
Object[] arr = [new A(5), new B(), null];
auto results = arr.map!(castSwitch!(
(A a) => "class A with a value of %d".format(a.value),
(I i) => "derived from I",
(B b) => "class B",
() => "null reference",
))();
The codes get nonsense error like:
/home/bthach/dlang/dmd-2.071.0/linux/bin64/../../src/phobos/std/algorithm/comparison.d(277):
Error: no property 'format' for type 'string'
But when I changed the order:
[...]
(B b) => "class B",
(I i) => "derived from I",
Suprisingly, it works.
Re: How to enable feedback for AssertError?
On Tuesday, 7 June 2016 at 01:40:01 UTC, your_name wrote: On Monday, 6 June 2016 at 00:09:15 UTC, Ali Çehreli wrote: [...] Hello Ali, The behavior you described is what I'd expect, however, it's not what I get. The way I traced the problem, ironically ;), was to catch Error and print it to screen. It involved dereferencing a null pointer in a thread and an 'assert null this' silently killed the thread leaving me wondering why it didn't produce data. Anyhow, I've had this behavior at least 1 more time but I forgot what exactly it was related to. Maybe I missed something beyond building a normal -debug version. Anyways, thanks for your reply :) Please open an issue - this sounds like a big then.
Re: Parse File at compile time, but not embedded
On Monday, 6 June 2016 at 21:57:20 UTC, Pie? wrote:
On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote:
On Monday, 6 June 2016 at 17:31:52 UTC, Pie? wrote:
Is it possible to parse a file at compile time without
embedding it into the binary?
I have a sort of "configuration" file that defines how to
create some objects. I'd like to be able to read how to
create them but not have that config file stick around in the
binary.
e.g., (simple contrived example follows)
Config.txt
x, my1
y, my1
z, my2
class my1 { }
class my2 { }
void parseConfig(A)
{
}
void main()
{
parseConfig('Config.txt') // Effectively creates a mixin
that mixes in auto x = new my1; auto y = new my1; auto z =
new my2;
}
If parseConfig uses import('Config.txt') then config.txt will
end up in the binary which I do not want. It would be easier
to be able to use import and strip it out later if possible.
Config.txt may contain secure information, which is why is
doesn't belong in the binary.
Most compilers, I believe, will not embed a string if it is
not used anywhere at runtime. DMD might not though, I'm not
sure.
This doesn't seem to be the case. In a release build, even
though I never "use" the string, it is embedded. I guess this
is due to not using enum but enum seems to be much harder to
work with if not impossible.
But reading sensitive data at compile-time strikes me as
dangerous, depending on your use case. If you are reading
sensitive information at compile time, you are presumably
going to include that information in your binary (otherwise
why would you read it?), and your binary is not secure.
Not necessarily, You chased that rabbit quite far! The data
your reading could contain sensitive information only used at
compile time and not meant to embed. For example, the file
could contain login and password to an SQL database that you
then connect, at compile time and retrieve that information the
disregard the password(it is not needed at run time).
This is definitely possible, but it can depend on your compiler.
If you use an enum, it'll be treated as a compile-time constant -
so if you never store it anywhere (i.e. enum File =
import('file.txt'); string file = File; is a no-no at global
scope), you should be fine.
If you do find yourself in the precarious situation of storing
the data, then it's up to your compiler to detect that there are
no runtime references to the data and elide it. LDC and GDC most
likely do this, but I doubt DMD would.
For safety, you should try and reformulate your code in terms of
enums and local variables; this *should* work with DMD, but it's
possible it's not smart enough to catch onto the fact that the
function is never used at run-time (and therefore does not need
to be included in the executable).
Re: How to enable feedback for AssertError?
On Monday, 6 June 2016 at 00:09:15 UTC, Ali Çehreli wrote:
On 06/05/2016 07:39 AM, your_name wrote:
> The problem I have is whenever an assert in my debug build
fails the
> program or thread is just killed silently.
That's strange. When an assertion fails, the stack trace is
printed and the program is terminated. For example:
void fun(int i) {
assert(i == 7);
}
void main() {
fun(42);
}
That program fails loudly :) with something similar to the
following:
core.exception.AssertError@deneme.d(2): Assertion failure
??:? _d_assert [0x422b9b]
??:? void deneme.__assert(int) [0x422acc]
??:? void deneme.fun(int) [0x422a62]
??:? _Dmain [0x422a75]
??:?
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
[0x423012]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x422f5c]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x422fce]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x422f5c]
??:? _d_run_main [0x422ecd]
??:? main [0x422b05]
??:? __libc_start_main [0x30ea082f]
If you want to prevent termination, it is possible but not
recommended to catch and swallow AssertError (or Error, or
Throwable):
import core.exception;
void fun(int i) {
assert(i == 7);
}
void main() {
try {
fun(42);
} catch (AssertError) {
// Something bad happened. We can't trust the state
// of this program any more.
}
}
As noted, when an Error is thrown, you can't know whether the
program can do anything correctly any more.
Ali
Hello Ali,
The behavior you described is what I'd expect, however, it's not
what I get.
The way I traced the problem, ironically ;), was to catch Error
and print it to screen.
It involved dereferencing a null pointer in a thread and an
'assert null this' silently killed the thread leaving me
wondering why it didn't produce data.
Anyhow, I've had this behavior at least 1 more time but I forgot
what exactly it was related to.
Maybe I missed something beyond building a normal -debug version.
Anyways, thanks for your reply :)
Re: Parse File at compile time, but not embedded
On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote:
On Monday, 6 June 2016 at 17:31:52 UTC, Pie? wrote:
Is it possible to parse a file at compile time without
embedding it into the binary?
I have a sort of "configuration" file that defines how to
create some objects. I'd like to be able to read how to create
them but not have that config file stick around in the binary.
e.g., (simple contrived example follows)
Config.txt
x, my1
y, my1
z, my2
class my1 { }
class my2 { }
void parseConfig(A)
{
}
void main()
{
parseConfig('Config.txt') // Effectively creates a mixin
that mixes in auto x = new my1; auto y = new my1; auto z = new
my2;
}
If parseConfig uses import('Config.txt') then config.txt will
end up in the binary which I do not want. It would be easier
to be able to use import and strip it out later if possible.
Config.txt may contain secure information, which is why is
doesn't belong in the binary.
Most compilers, I believe, will not embed a string if it is not
used anywhere at runtime. DMD might not though, I'm not sure.
This doesn't seem to be the case. In a release build, even though
I never "use" the string, it is embedded. I guess this is due to
not using enum but enum seems to be much harder to work with if
not impossible.
But reading sensitive data at compile-time strikes me as
dangerous, depending on your use case. If you are reading
sensitive information at compile time, you are presumably going
to include that information in your binary (otherwise why would
you read it?), and your binary is not secure.
Not necessarily, You chased that rabbit quite far! The data your
reading could contain sensitive information only used at compile
time and not meant to embed. For example, the file could contain
login and password to an SQL database that you then connect, at
compile time and retrieve that information the disregard the
password(it is not needed at run time).
Re: Error: mutable method isolated.graphics.g3d.model.Model.begin is not callable using a const object
On 06/06/2016 11:25 PM, Alex Parrill wrote: You might be able to get away with casting the const away, if you are sure it won't modify the hash or equality check. Casting away const and then mutating has undefined behavior. The compiler is free to assume that it doesn't happen. Be aware that you're working outside of the specified language if you do it. You rely on the compiler producing code that works in your favor when it has no obligation to do so. I don't think we should ever suggest relying on undefined behavior here in D.learn.
Re: Error: mutable method isolated.graphics.g3d.model.Model.begin is not callable using a const object
On Monday, 6 June 2016 at 21:25:16 UTC, Alex Parrill wrote: On Monday, 6 June 2016 at 21:16:18 UTC, Begah wrote: Does the key of a associative array will be const if the reference is requested? That's probably what it is, actually. Modifying the key with the ref could cause the hash of the key to change without the hashtable knowing about it, causing it to break. You might be able to get away with casting the const away, if you are sure it won't modify the hash or equality check. Thanks for the help, i'll just cast away the const
Re: Parse File at compile time, but not embedded
On Monday, 6 June 2016 at 17:31:52 UTC, Pie? wrote:
Is it possible to parse a file at compile time without
embedding it into the binary?
I have a sort of "configuration" file that defines how to
create some objects. I'd like to be able to read how to create
them but not have that config file stick around in the binary.
e.g., (simple contrived example follows)
Config.txt
x, my1
y, my1
z, my2
class my1 { }
class my2 { }
void parseConfig(A)
{
}
void main()
{
parseConfig('Config.txt') // Effectively creates a mixin
that mixes in auto x = new my1; auto y = new my1; auto z = new
my2;
}
If parseConfig uses import('Config.txt') then config.txt will
end up in the binary which I do not want. It would be easier to
be able to use import and strip it out later if possible.
Config.txt may contain secure information, which is why is
doesn't belong in the binary.
Most compilers, I believe, will not embed a string if it is not
used anywhere at runtime. DMD might not though, I'm not sure.
But reading sensitive data at compile-time strikes me as
dangerous, depending on your use case. If you are reading
sensitive information at compile time, you are presumably going
to include that information in your binary (otherwise why would
you read it?), and your binary is not secure.
Re: Error: mutable method isolated.graphics.g3d.model.Model.begin is not callable using a const object
On Monday, 6 June 2016 at 20:40:12 UTC, Begah wrote: I have a pretty weird error : Error: mutable method isolated.graphics.g3d.model.Model.begin is not callable using a const object [...] It may infer const from the type of `this.instance`, which may be further modified if the method you are running this in is `const`. If you explicitly specify the type of the foreach loop variables, does it work?
Error: mutable method isolated.graphics.g3d.model.Model.begin is not callable using a const object
I have a pretty weird error : Error: mutable method
isolated.graphics.g3d.model.Model.begin is not callable using a
const object
The weird part is that i do not use const or immutable objects in
my code ( for the Model ) :
struct Handle {
Model *asset = null;
string asset_name = null;
alias asset this;
@property bool initialized() {
return asset !is null;
}
this(this) {
(*referenceCount)++;
}
~this() {
(*referenceCount)--;
}
size_t *referenceCount;
}
This structure is where the reference is kept ( allocated with
c's malloc )
Then in my code, i have a loop as such :
ModelInstance[][Handle] instances;
foreach(ref model, ref instances; this.instances) {
model.begin();
foreach(instance; instances) {
instance.render();
}
model.end();
}
But for both model.begin or model.end i get that compilation
error.
As you can see, i am calling model.begin ( which extends to
model.asset.begin ) but no const instances are used.
Side note :
When i remove the ref in the for loop :
foreach(model, ref instances; this.instances)
The codes compile and work, i don't understand why being a
reference or not is a problem.
Re: Enum that can be 0 or null
On Monday, 6 June 2016 at 18:43:33 UTC, ParticlePeter wrote:
On Saturday, 21 May 2016 at 06:36:53 UTC, tsbockman wrote:
...
As an example, if VK_NULL_HANDLE only ever needs to be
assigned to opaque types on the D side (that is, types that
serve only as an ID or address for communicating with the C
side), you could do this:
private struct VkNullHandle { }
enum VK_NULL_HANDLE = VkNullHandle.init;
mixin template VkHandle(bool dispatchable) {
static if (dispatchable || (size_t.sizeof == 8))
void* bits = null;
else
ulong bits = 0;
this(typeof(this) that) {
this.bits = that.bits; }
this(VkNullHandle that) {
this.bits = typeof(this.bits).init; }
ref typeof(this) opAssign(typeof(this) that) {
this.bits = that.bits;
return this;
}
ref typeof(this) opAssign(VkNullHandle that) {
this.bits = typeof(this.bits).init;
return this;
}
}
struct VkDevice { mixin VkHandle!true; }
struct VkInstance { mixin VkHandle!true; }
struct VkFence { mixin VkHandle!false; }
struct VkSemaphore { mixin VkHandle!false; }
void main() {
VkInstance a = VK_NULL_HANDLE;
VkFence b = VK_NULL_HANDLE;
}
(DPaste: https://dpaste.dzfl.pl/8f4ce39a907f )
The above is typesafe, and can easily be made compatible with
a typical C API, since C does no parameter-related name
mangling.
In this case I don't see how it would be possible to use your
VkDevice, etc. as argument to the C functions, as they are of
different type, no?
They'd be the same type, since you would define the vulkan
functions to take these structures instead of pointer or integer
types.
It relies on a lot of assumptions about the ABI that make a raw
pointer work the same as a structure containing just one pointer,
which is why I did not give it much consideration.
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 18:33:36 UTC, ParticlePeter wrote: On Monday, 6 June 2016 at 16:19:02 UTC, Alex Parrill wrote: On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow? I already asked about this: https://forum.dlang.org/post/bnkqevhyxwdjjxsct...@forum.dlang.org Tldr; doesn't seem to be possible without multiple alias this or using ABI hacks. O.k., my web search didn't find that topic. The last reply looks promising, wouldn't that work? That's the ABI hack I mentioned. It abuses the fact that on most hardware and compiled, a pointer and a structure containing a single pointer have the same binary representation. It will likely work, but it isn't guarenteed.
Windows system casting
import std.stdio;
import std.string;
import core.sys.windows.windows;
void main() {
string filepath =
"C:\\Users\\awpat\\Pictures\\patterns_00387591.jpg";
auto p = toStringz(filepath);
int result;
result = SystemParametersInfo(cast(uint)SPI_SETDESKWALLPAPER,
cast(uint)0, cast(void*)p ,cast(uint)SPIF_UPDATEINIFILE);
}
I'm trying to change the background of my computer. to do this I
must convert my string to a const char*, then that can implicitly
to a (PVOID). I believe that I am losing all my data in the
casting process, is there a way for me to keep my data? or if I
am casting this improperly can you demonstrate and explain the
proper way to cast to a void pointer (PVOID)?
thanks!!
Re: Enum that can be 0 or null
On Saturday, 21 May 2016 at 06:36:53 UTC, tsbockman wrote:
...
As an example, if VK_NULL_HANDLE only ever needs to be assigned
to opaque types on the D side (that is, types that serve only
as an ID or address for communicating with the C side), you
could do this:
private struct VkNullHandle { }
enum VK_NULL_HANDLE = VkNullHandle.init;
mixin template VkHandle(bool dispatchable) {
static if (dispatchable || (size_t.sizeof == 8))
void* bits = null;
else
ulong bits = 0;
this(typeof(this) that) {
this.bits = that.bits; }
this(VkNullHandle that) {
this.bits = typeof(this.bits).init; }
ref typeof(this) opAssign(typeof(this) that) {
this.bits = that.bits;
return this;
}
ref typeof(this) opAssign(VkNullHandle that) {
this.bits = typeof(this.bits).init;
return this;
}
}
struct VkDevice { mixin VkHandle!true; }
struct VkInstance { mixin VkHandle!true; }
struct VkFence { mixin VkHandle!false; }
struct VkSemaphore { mixin VkHandle!false; }
void main() {
VkInstance a = VK_NULL_HANDLE;
VkFence b = VK_NULL_HANDLE;
}
(DPaste: https://dpaste.dzfl.pl/8f4ce39a907f )
The above is typesafe, and can easily be made compatible with a
typical C API, since C does no parameter-related name mangling.
In this case I don't see how it would be possible to use your
VkDevice, etc. as argument to the C functions, as they are of
different type, no?
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 18:33:36 UTC, ParticlePeter wrote: On Monday, 6 June 2016 at 16:19:02 UTC, Alex Parrill wrote: On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow? I already asked about this: https://forum.dlang.org/post/bnkqevhyxwdjjxsct...@forum.dlang.org Tldr; doesn't seem to be possible without multiple alias this or using ABI hacks. O.k., my web search didn't find that topic. The last reply looks promising, wouldn't that work? Lets bump it and discuss there.
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 16:19:02 UTC, Alex Parrill wrote: On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow? I already asked about this: https://forum.dlang.org/post/bnkqevhyxwdjjxsct...@forum.dlang.org Tldr; doesn't seem to be possible without multiple alias this or using ABI hacks. O.k., my web search didn't find that topic. The last reply looks promising, wouldn't that work?
Parse File at compile time, but not embedded
Is it possible to parse a file at compile time without embedding
it into the binary?
I have a sort of "configuration" file that defines how to create
some objects. I'd like to be able to read how to create them but
not have that config file stick around in the binary.
e.g., (simple contrived example follows)
Config.txt
x, my1
y, my1
z, my2
class my1 { }
class my2 { }
void parseConfig(A)
{
}
void main()
{
parseConfig('Config.txt') // Effectively creates a mixin that
mixes in auto x = new my1; auto y = new my1; auto z = new my2;
}
If parseConfig uses import('Config.txt') then config.txt will end
up in the binary which I do not want. It would be easier to be
able to use import and strip it out later if possible. Config.txt
may contain secure information, which is why is doesn't belong in
the binary.
Re: core.sys.windows so lean?
On Monday, 6 June 2016 at 16:51:20 UTC, Jonathan Marler wrote: Hmmm...it seems to be missing quite alot though. Especially the winsock api. Over the weekend I was writing some code that uses a windows IOCompletionPort and had to add a fair amount of code that was missing: Pull requests for anything you find missing would be great.
Re: core.sys.windows so lean?
On Monday, 6 June 2016 at 17:11:44 UTC, Vladimir Panteleev wrote: On Monday, 6 June 2016 at 16:51:20 UTC, Jonathan Marler wrote: Hmmm...it seems to be missing quite alot though. You could've mentioned you meant just the winsock modules. They have not been brought over because they were not explicitly under an open-source license. :( (Sorry I didn't realize they were all only in the winsock module) Weird that you could include the standard windows module but not winsock? Also seems odd that a language including bindings to an operating system api would be a licensing issue.
Re: core.sys.windows so lean?
On Monday, 6 June 2016 at 16:51:20 UTC, Jonathan Marler wrote: Hmmm...it seems to be missing quite alot though. You could've mentioned you meant just the winsock modules. They have not been brought over because they were not explicitly under an open-source license.
Re: core.sys.windows so lean?
On Monday, 6 June 2016 at 16:13:48 UTC, Vladimir Panteleev wrote:
On Monday, 6 June 2016 at 16:04:30 UTC, Jonathan Marler wrote:
I'm writing some platform specific D code and I've found that
what the druntime exposes for the windows platform is pretty
lean. I'm guessing that the purpose of the druntime version
of the windows api is to implement the minimum required to
support the windows platform and not meant to be a
full-featured interface to windows. Is this the case?
Erm, not since 2.070:
Hmmm...it seems to be missing quite alot though. Especially the
winsock api. Over the weekend I was writing some code that uses
a windows IOCompletionPort and had to add a fair amount of code
that was missing:
import core.sys.windows.windows;
import core.sys.windows.winsock2;
// NOTE: not sure if this stuff should be included in
core.sys.windows.winsock2
alias u_long = uint; // NOTE: not sure if uint is the best
alias for u_long
// The actual sockaddr_in structure in windows is 24 bytes long,
// but the sockaddr_in defined in core.sys.windows.winsock2 is
only 20.
// This caused an error when calling AcceptEx that indicated
the buffer
// size for sockaddr_in was too small.
union real_sockaddr_in {
sockaddr_in addr;
ubyte[24] padding; // make sure the sockaddr_in takes 24 bytes
}
struct WSABUF {
u_long len;
char* buf;
}
alias LPWSABUF = WSABUF*;
// NOTE: WSAOVERLAPPED is supposed to be castable to and from
OVERLAPPED.
// Maybe this doesn't need to be defined, maybe I could
just always use OVERLAPPED?
struct WSAOVERLAPPED {
ULONG* Internal;
ULONG* InternalHigh;
union {
struct {
DWORD Offset;
DWORD OffsetHigh;
}
PVOID Pointer;
}
HANDLE hEvent;
}
alias LPWSAOVERLAPPED = WSAOVERLAPPED*;
alias LPWSAOVERLAPPED_COMPLETION_ROUTINE = void function(uint,
uint, LPWSAOVERLAPPED, uint);
enum : int {
SIO_GET_EXTENSION_FUNCTION_POINTER = 0xc806,
}
enum GUID WSAID_ACCEPTEX =
{0xb5367df1,0xcbac,0x11cf,[0x95,0xca,0x00,0x80,0x5f,0x48,0xa1,0x92]};
alias LPFN_ACCEPTEX = extern(Windows) bool function(SOCKET
listenSocket,
SOCKET acceptSocket,
PVOID outputBuffer,
DWORD receiveDataLength,
DWORD localAddressLength,
DWORD remoteAddressLength,
DWORD* bytesReceived,
OVERLAPPED* overlapped)
nothrow @nogc;
extern(Windows) int WSAIoctl(SOCKET s, uint dwIoControlCode,
void* lpvInBuffer, uint cbInBuffer,
void* lpvOutBuffer, uint cbOutBuffer,
uint* lpcbBytesReturned,
LPWSAOVERLAPPED lpOverlapped,
LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) nothrow
@nogc;
extern(Windows) int WSARecv(SOCKET s, LPWSABUF lpBuffer, DWORD
bufferCount,
LPDWORD numberOfBytesReceived, LPDWORD flags,
LPWSAOVERLAPPED overlapped,
LPWSAOVERLAPPED_COMPLETION_ROUTINE completionRoutine);
Re: core.sys.windows so lean?
With the newest dmds, if you use -m32mscoff you just use the Microsoft libraries and linkers and the core.sys.windows is pretty full - should be easy to use.
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow? I already asked about this: https://forum.dlang.org/post/bnkqevhyxwdjjxsct...@forum.dlang.org Tldr; doesn't seem to be possible without multiple alias this or using ABI hacks.
Re: core.sys.windows so lean?
On Monday, 6 June 2016 at 16:04:30 UTC, Jonathan Marler wrote: I'm writing some platform specific D code and I've found that what the druntime exposes for the windows platform is pretty lean. I'm guessing that the purpose of the druntime version of the windows api is to implement the minimum required to support the windows platform and not meant to be a full-featured interface to windows. Is this the case? Erm, not since 2.070: http://dlang.org/changelog/2.070.0.html#core-sys-windows If so, is there a good library that someone has implemented to support the full windows API? I think I remember there was one a few years ago, but now I'm unable to find it. I think I remember that the windows .lib files installed with dmd were missing symbols/functions I needed so I had to use the ones in the system32 directory installed with windows. I also had to convert them to OMF (since optlink doesn't support COFF). I'm just wondering if someone can shed some light on this, it's just been a while and google didn't seem to be much help so pointers in the right direction would be much appreciated. Thanks. This is the (former URL of the) library you are thinking of: http://www.dsource.org/projects/bindings Or you might've used my GitHub mirror: https://github.com/CS-svnmirror/dsource-bindings https://github.com/CS-svnmirror/dsource-bindings-win32 It has been intergrated into Druntime as the core.sys.windows package in 2.070.
core.sys.windows so lean?
I'm writing some platform specific D code and I've found that what the druntime exposes for the windows platform is pretty lean. I'm guessing that the purpose of the druntime version of the windows api is to implement the minimum required to support the windows platform and not meant to be a full-featured interface to windows. Is this the case? If so, is there a good library that someone has implemented to support the full windows API? I think I remember there was one a few years ago, but now I'm unable to find it. I think I remember that the windows .lib files installed with dmd were missing symbols/functions I needed so I had to use the ones in the system32 directory installed with windows. I also had to convert them to OMF (since optlink doesn't support COFF). I'm just wondering if someone can shed some light on this, it's just been a while and google didn't seem to be much help so pointers in the right direction would be much appreciated. Thanks.
Re: Implicit conversion of struct to bool for if (s) operation ?
On Monday, 6 June 2016 at 15:28:35 UTC, John wrote: Thank you John and Adam. That was a quick answer !
Re: Implicit conversion of struct to bool for if (s) operation ?
On Monday, 6 June 2016 at 15:23:50 UTC, chmike wrote:
I would like an implicit conversion of Info to bool that return
false if category_ is null so that I can write
add:
bool opCast(T : bool)() {
return whatever;
}
to the struct and it should work.
Re: Implicit conversion of struct to bool for if (s) operation ?
On Monday, 6 June 2016 at 15:23:50 UTC, chmike wrote:
Hello,
I have a structure with two fields ad defined as
struct Info {
this(int value, Category category)
{
category_ = category;
value_ = category ? value : 0;
}
// This converts implicitly to bool.
T opCast(T : bool)() {
return category_ !is null;
}
...
private:
Category category_ = null;
int value_ = 0;
}
I would like an implicit conversion of Info to bool that return
false if category_ is null so that I can write
Info s = foo();
if (s) {
...
}
and where
Info s2;
assert(!s2);
See the inserted code above.
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 12:09:33 UTC, ParticlePeter wrote: I don't see the connection here, you introduced two symbols with two different types. I want one symbol which can pose as two different (constant) types. Ah, my apologies, I misunderstood the question.
Re: Range and poolTask
On Monday, 6 June 2016 at 11:25:00 UTC, Rene Zwanenburg wrote:
Could you elaborate a bit?
Yes.
I have an InputRange and need to pass it throughout a couple of
iteration and manipulation functions such as filter, map and
finishing by grouping with fold. Like:
myrange
.filter!xxx
.map!yyy
.tee!zzz
.fold!www
This process take a lot of time, so I decide to put it in
parallel. I did something like this:
Appender!www output;
foreach(iii; parallel(myrange))
{
only(iii)
.filter!xxx
.map!yyy
.tee!zzz
.copy(output)
}
output.fold!www;
only() will create a Range with one item in it. Also, I can't
group directly. I
need to use a second Range.
It works but it's not elegant as the non-working example above is.
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 11:40:11 UTC, Anonymouse wrote: On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow? If you want it for use in logical expressions then implicit boolean conversion will treat them as the same. https://dpaste.dzfl.pl/d82f60657c37 I don't see the connection here, you introduced two symbols with two different types. I want one symbol which can pose as two different (constant) types.
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow? If you want it for use in logical expressions then implicit boolean conversion will treat them as the same. https://dpaste.dzfl.pl/d82f60657c37
Re: Emulate C's (polymorphic) NULL type
On Monday, 6 June 2016 at 09:43:23 UTC, ParticlePeter wrote: A extern( C ) function should be able to take it as either one. Missed this bit. Not sure about that one.
Re: Range and poolTask
On Monday, 6 June 2016 at 10:26:11 UTC, moechofe wrote: The functions passed to map or amap take the type of the element of the range as argument, but not a range itself. Right. I don't think I understand what the semantics of your example would be though.. Could you elaborate a bit?
Re: Range and poolTask
On Monday, 6 June 2016 at 09:38:32 UTC, Rene Zwanenburg wrote: http://dlang.org/phobos/std_parallelism.html#.TaskPool Or, more specifically, http://dlang.org/phobos/std_parallelism.html#.TaskPool.amap http://dlang.org/phobos/std_parallelism.html#.TaskPool.map The functions passed to map or amap take the type of the element of the range as argument, but not a range itself.
Emulate C's (polymorphic) NULL type
In C NULL can be used as integer as well as null pointer. Is there a way to create such a type in D? The type should have only one value which is obviously (0/null). A extern( C ) function should be able to take it as either one. Overloaded enum pops into my mind as example: enum NULL = 0; enum NULL = null; Is this possible somehow?
Re: Range and poolTask
On Monday, 6 June 2016 at 09:32:30 UTC, moechofe wrote:
I wonder if it is possible to write something like this:
---
// taskPool.distribute -- take a range and distribute entries
to different threads.
dirEntries().distribute(function(R1,R2)(R1 from,R2 to){
from
.filter!xxx
.map!yyy
.tee!zzz(to);
})
.each!www;
---
This would be great.
This might be useful:
http://dlang.org/phobos/std_parallelism.html#.TaskPool
Or, more specifically,
http://dlang.org/phobos/std_parallelism.html#.TaskPool.amap
http://dlang.org/phobos/std_parallelism.html#.TaskPool.map
Range and poolTask
I wonder if it is possible to write something like this:
---
// taskPool.distribute -- take a range and distribute entries to
different threads.
dirEntries().distribute(function(R1,R2)(R1 from,R2 to){
from
.filter!xxx
.map!yyy
.tee!zzz(to);
})
.each!www;
---
This would be great.
Re: Speed up `dub`.
On Sunday, 5 June 2016 at 21:20:20 UTC, Andrej Mitrovic wrote:
On Thursday, 2 June 2016 at 13:04:00 UTC, ciechowoj wrote:
and found that an assert from `std/path.d:3168` (`globMatch`)
contributes a major amount to the running time of dub.
```
assert(balancedParens(pattern, '[', ']', 0));
assert(balancedParens(pattern, '{', '}', 0));
```
Hmm.. that sounds like the dub binary that's distributed is
running its unittests at start. If that's true I don't think
they should be part of the released binary..
Actually, that assertions are invoked from precondition block of
`globMatch`. On the other hand `globMatch` is invoked from
`std.file.dirEntry`. So, I suppose it is fine if it goes about
unit tests.
Re: Embed files into binary.
On 06/06/2016 6:45 PM, Pie? wrote: On Monday, 6 June 2016 at 06:10:35 UTC, rikki cattermole wrote: On 06/06/2016 6:06 PM, Pie? wrote: On Monday, 6 June 2016 at 05:30:12 UTC, rikki cattermole wrote: On 06/06/2016 5:07 PM, Pie? wrote: [...] Then I would say go get a new image library as that one isn't a very good one. ..snip.. Right got rid of all that text. If you want to make the filesystem appear to have files it doesn't, you'll need a virtual file system library. Welcome to the next issue, getting libraries to support it ;) My point exactly! Glad you could finally support my conclusion! ;) Finally was many many months ago[0]. I'm not happy with my implementation. Either way, somebody has to go ahead and write one for Phobos. Although good luck with getting that in. [0] https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental/vfs Would this, say, allow an application to embed a "file system" into it's run time and then virtually dispatch file IO? If so, what about write access(the binary would grow in size when written to)? Its in the name, "virtual" file system. Write access would depend on where the "file" is. What about seemlessly shifting between a real file system and the virtual one by simple flag toggling and rebuilding? If so, then D would definitely benefit from it. This way one can create binaries and back them by a real file system for debugging purposes(easy access, no extracting from binaries or having to store them) then for release, one can turn that in to a virtual file system. Nope, virtual file system is its own representation. Can't switch all the c functions to use it. Its a almost full rewrite to use it. If this is what your vfs does or aims at then hats off! Cheerio! Where do I sign up? If not, would you mind expanding it to do such a thing? Again, I'm not happy with my one.
Re: Embed files into binary.
On Monday, 6 June 2016 at 06:10:35 UTC, rikki cattermole wrote: On 06/06/2016 6:06 PM, Pie? wrote: On Monday, 6 June 2016 at 05:30:12 UTC, rikki cattermole wrote: On 06/06/2016 5:07 PM, Pie? wrote: [...] Then I would say go get a new image library as that one isn't a very good one. ..snip.. Right got rid of all that text. If you want to make the filesystem appear to have files it doesn't, you'll need a virtual file system library. Welcome to the next issue, getting libraries to support it ;) My point exactly! Glad you could finally support my conclusion! ;) Finally was many many months ago[0]. I'm not happy with my implementation. Either way, somebody has to go ahead and write one for Phobos. Although good luck with getting that in. [0] https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental/vfs Would this, say, allow an application to embed a "file system" into it's run time and then virtually dispatch file IO? If so, what about write access(the binary would grow in size when written to)? What about seemlessly shifting between a real file system and the virtual one by simple flag toggling and rebuilding? If so, then D would definitely benefit from it. This way one can create binaries and back them by a real file system for debugging purposes(easy access, no extracting from binaries or having to store them) then for release, one can turn that in to a virtual file system. If this is what your vfs does or aims at then hats off! Cheerio! Where do I sign up? If not, would you mind expanding it to do such a thing? I am essentially coding up something like that as we speak... Using static importing the binary and modulating all my file IO into a routine that chooses to use the physical file system when in debug mode and the imported data in release(it's quite easy, just dispatch to std.file io in debug and simply return the memory of the requested data in release).
Re: Embed files into binary.
On 06/06/2016 6:06 PM, Pie? wrote: On Monday, 6 June 2016 at 05:30:12 UTC, rikki cattermole wrote: On 06/06/2016 5:07 PM, Pie? wrote: [...] Then I would say go get a new image library as that one isn't a very good one. ..snip.. Right got rid of all that text. If you want to make the filesystem appear to have files it doesn't, you'll need a virtual file system library. Welcome to the next issue, getting libraries to support it ;) My point exactly! Glad you could finally support my conclusion! ;) Finally was many many months ago[0]. I'm not happy with my implementation. Either way, somebody has to go ahead and write one for Phobos. Although good luck with getting that in. [0] https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental/vfs
Re: Embed files into binary.
On Monday, 6 June 2016 at 05:30:12 UTC, rikki cattermole wrote: On 06/06/2016 5:07 PM, Pie? wrote: [...] Then I would say go get a new image library as that one isn't a very good one. ..snip.. Right got rid of all that text. If you want to make the filesystem appear to have files it doesn't, you'll need a virtual file system library. Welcome to the next issue, getting libraries to support it ;) My point exactly! Glad you could finally support my conclusion! ;)
