std.experimental.allocator and @nogc
I was trying to use allocators in a @nogc function. I tried FreeList!Mallocator and it works fine. But AllocatorList!Mallocator doesn't work. dmd complains that AllocatorList.allocate is not @nogc, even when BookkeepingAllocator is NullAllocator. But if I add '@nogc' to AllocatorList.allocate by hand, it works. Is this probably a bug in how dmd deduce function properties?
full path to source file __FILE__
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to be
ran with rdmd. However, the script needs to know it's own path.
The original batch script uses the %~dp0 variable for this, but
I'm at a loss on how to do this in D. Since rdmd compiles the
executable to the %TEMP% directory, thisExePath won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
Re: multithreaded hell, help!
On Thursday, July 21, 2016 21:47:09 rikki cattermole via Digitalmars-d-learn wrote: > On 21/07/2016 9:44 PM, Brons wrote: > > Im trying to access data in a global between threads. > > So ive set my global to shared, however the object trying to access it > > needs to also then be shared, but it cant be because its part of a > > library... > > > > Is there any simple way to transfer data from one thread to another? > > > > 1. My situation is im reading from a serial port in a thread. Which > > writes to my global. > > 2. In a draw thread i need to get that data and draw my output. > > > > Cheers > > __gshared or cast away shared. Be _very_ careful of __gshared. It's intended for C-style global variables only - really, with the idea of using them when linking against C code. The type system still treats them as thread-local, not shared, so it can do optimizations based on thread-local which are incompatible with the object being on multiple threads. You may not have much choice in this case, but I'd strongly argue that you avoid using __gshared if possible. An alternative would be marking the object as shared and then casting away shared while the variable is protected by a mutex (or synchronized block) so that you can then call non-shared, member functions on the shared object. If you can do that instead of __gshared, I'd strongly recommend it. However, the preferred way to share information across threads if possible is to use std.concurrency to send messages across threads. It's somewhat limited if you're trying to pass user-defined types across threads if they're not value types (since they have to be immutable or shared), but if you need to, you can cast an object to immutable on one side and back to mutable on the other - so long as you _know_ that there are no other instances of that object on the original thread. Value types are easy though, since they can be copied when passed across. __gshared _might_ be the best choice in your case. However, usually, it's just the quick and easy way out that gets things working but which risks subtle bugs down the line. Personally, I would only ever use it when integrating with a C or C++ library. - Jonathan M Davis
Re: full path to source file __FILE__
On Thursday, July 21, 2016 19:54:34 Jonathan Marler via Digitalmars-d-learn
wrote:
> Is there a way to get the full path of the current source file?
> Something like:
>
> __FILE_FULL_PATH__
>
> I'm asking because I'm rewriting a batch script in D, meant to be
> ran with rdmd. However, the script needs to know it's own path.
> The original batch script uses the %~dp0 variable for this, but
> I'm at a loss on how to do this in D. Since rdmd compiles the
> executable to the %TEMP% directory, thisExePath won't work.
>
> BATCH
> -
> echo "Directory of this script is " %~dp0
>
>
> DLANG
> -
> import std.stdio;
> int main(string[] args) {
> writeln("Directory of this script is ", ???);
> }
Well, while it might not be what you want, the obvious solution is to just
compile it as an executable and put that where you want rather than making
it a script.
- Jonathan M Davis
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote: won't? what this means? That gives the path to the .exe but he wants the path to the .d. But why? I would think the current working directory is probably adequate and that's easy to get...
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 22:33:39 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote: won't? what this means? That gives the path to the .exe but he wants the path to the .d. But why? I would think the current working directory is probably adequate and that's easy to get... I explain in the original post. Any ideas Adam? Thanks in advance.
Re: full path to source file __FILE__
On 7/21/16 3:54 PM, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to be ran
with rdmd. However, the script needs to know it's own path. The
original batch script uses the %~dp0 variable for this, but I'm at a
loss on how to do this in D. Since rdmd compiles the executable to the
%TEMP% directory, thisExePath won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
Sure seems like an unwanted limitation.
rdmd does forward all dmd options, but there isn't really an option to
say "put the exe in the source path".
You should file an enhancement.
-Steve
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 22:39:45 UTC, Steven Schveighoffer
wrote:
On 7/21/16 3:54 PM, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran
with rdmd. However, the script needs to know it's own path.
The
original batch script uses the %~dp0 variable for this, but
I'm at a
loss on how to do this in D. Since rdmd compiles the
executable to the
%TEMP% directory, thisExePath won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
Sure seems like an unwanted limitation.
rdmd does forward all dmd options, but there isn't really an
option to say "put the exe in the source path".
You should file an enhancement.
-Steve
An option for rdmd would be good, but then requires the user to
call rdmd in a particular way. It doesnt allow the script itself
know where it lives, which is needed in my case.
Re: union initalization
On Friday, 22 July 2016 at 02:08:06 UTC, Ali Çehreli wrote:
On 07/21/2016 06:48 PM, Rufus Smith wrote:
> I would like to combine two types
>
>
> template Foo(A, B = 4)
> {
> union
> {
> byte b = B;
> int a = A << 8;
> }
> }
>
> This packs a and b together in to an int bytes, saving an
int(rather
> than storing a and b in an int each) and makes it easier to
access.
Bitfields may actually be useful in this case:
https://dlang.org/phobos/std_bitmanip.html#.bitfields
They don't allow default assignment though?
> I get an error about overlapping default initialization. They
don't
> actually overlap in this case because of the shift.
The following at least compiles:
struct Foo(int A, byte B = 4)
{
union
{
byte b = void;
int a = void;
uint __both = (A << 8) | B;
}
}
void main() {
auto f = Foo!(42)();
}
Ali
Maybe... I don't like extra member. Bitfields seem like it would
be the best way but I require default initialization. I want to
hide as details of the work on unpacking as possible.
union initalization
I would like to combine two types
template Foo(A, B = 4)
{
union
{
byte b = B;
int a = A << 8;
}
}
This packs a and b together in to an int bytes, saving an
int(rather than storing a and b in an int each) and makes it
easier to access.
I get an error about overlapping default initialization. They
don't actually overlap in this case because of the shift.
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 22:57:06 UTC, Jonathan M Davis wrote: On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via Digitalmars-d- learn wrote: [...] It would be pretty terrible actually to put the executable in the source path, and in many cases, the user wouldn't even have the permissions for it. For instance, what if the script were in /usr/local/bin? They won't have the permissions for the executable to end up there, and it would just cause a bunch of clutter in /usr/local/bin, since you'd get a new executable every time it decided that it needed to rebuild it (and you wouldn't want it to delete the executable every time, otherwise it would have to rebuild it every time, making it so that it would _always_ have to compile your script when it runs instead of just sometimes). Right now, the executable ends up in a temp directory, which makes a lot of sense. Maybe it would make sense to have such a flag for very rare cases, but in general, it seems like a terrible idea. - Jonathan M Davis I agree this isn't a very good solution for the problem at hand. Putting the executable in a temporary directory makes sense in any cases I can think of. I posted an idea for another potential solution (http://forum.dlang.org/thread/cmydxneeghtjqjrox...@forum.dlang.org), please let me know your thoughts. Thanks.
Re: union initalization
On 07/21/2016 06:48 PM, Rufus Smith wrote:
> I would like to combine two types
>
>
> template Foo(A, B = 4)
> {
> union
> {
> byte b = B;
> int a = A << 8;
> }
> }
>
> This packs a and b together in to an int bytes, saving an int(rather
> than storing a and b in an int each) and makes it easier to access.
Bitfields may actually be useful in this case:
https://dlang.org/phobos/std_bitmanip.html#.bitfields
> I get an error about overlapping default initialization. They don't
> actually overlap in this case because of the shift.
The following at least compiles:
struct Foo(int A, byte B = 4)
{
union
{
byte b = void;
int a = void;
uint __both = (A << 8) | B;
}
}
void main() {
auto f = Foo!(42)();
}
Ali
Re: full path to source file __FILE__
On Friday, 22 July 2016 at 01:52:57 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler wrote: I explain in the original post. Any ideas Adam? Thanks in advance. But why does the batch script use it? Since you are rewriting anyway, maybe you can find an easier/better way to achieve the goal. The script depends on other files relative to where it exists on the file system. I couldn't think of a better design to find these files then knowing where the script exists, can you?
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler wrote: I explain in the original post. Any ideas Adam? Thanks in advance. But why does the batch script use it? Since you are rewriting anyway, maybe you can find an easier/better way to achieve the goal.
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
thisExePath won't work.
won't? what this means?
this work on my windows
import std.file: thisExePath;
import std.stdio: writeln;
void main()
{
writeln(thisExePath());
}
Re: full path to source file __FILE__
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran with rdmd. However, the script needs to know it's own
path. The original batch script uses the %~dp0 variable for
this, but I'm at a loss on how to do this in D. Since rdmd
compiles the executable to the %TEMP% directory, thisExePath
won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
What's wrong with __FILE__.dirName ?
Re: LDC with ARM backend
On Thursday, 21 July 2016 at 10:30:55 UTC, Andrea Fontana wrote: On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote: I can build a "Hello world" program on ARM GNU/Linux, with druntime and phobos. I'll write a doc page about that. It's a good idea :) Done: https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux I based it totally on Kai's previous page for LDC on Android. It lacks the build for druntime/phobos unit-tests.
Re: Default implementations in inherited interfaces
On Thursday, 21 July 2016 at 12:42:14 UTC, Adam D. Ruppe wrote: On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote: I have an interface A which declares a certain function. A second interface B inherits from A and wishes to provide a default implementation for that function. You can't, interfaces cannot have implementations of virtual functions. Your code is trying to define two separate functions with the same name (the compiler should probably prohibit that, since it doesn't do want you want it to do). Your best bet is to make B an abstract class instead of an interface. Then it can override interface functions. Of course, it will also tie you down as you can only inherit from one class, but it will actually work. I see. Java 8 has a 'default' keyword that allows interfaces to provide a default implementation and sub-classes can optionally override it if needed. The rationale behind it was extending interfaces without causing old code to faill. (called "virtual extension methods" or "defender methods"). The use case is similar to above. Is there a way to achieve an equivalent functionality in D? Thanks, Saurabh
Re: Default implementations in inherited interfaces
On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote:
I have an interface A which declares a certain function. A
second interface B inherits from A and wishes to provide a
default implementation for that function. How can I achieve
this? I'm facing an error when I try this:
interface A
{
int func(int);
}
interface B : A
{
final int func(int)
{
return 0;
}
}
class C : B
{
}
rdmd it.d:
it.d(14): Error: class it.C interface function 'int func(int)'
is not implemented
Thanks,
Saurabh
Interesting.
This is worth a bugzilla issue, IMHO. In fact, if you try the
other way (i.e.: you provide an implementation of func in class
C), you get the opposite error, that you are overriding a final
function (B.func).
Re: multithreaded hell, help!
On 21/07/2016 9:44 PM, Brons wrote: Im trying to access data in a global between threads. So ive set my global to shared, however the object trying to access it needs to also then be shared, but it cant be because its part of a library... Is there any simple way to transfer data from one thread to another? 1. My situation is im reading from a serial port in a thread. Which writes to my global. 2. In a draw thread i need to get that data and draw my output. Cheers __gshared or cast away shared.
Re: LDC with ARM backend
On Wednesday, 20 July 2016 at 16:10:48 UTC, Claude wrote: R_ARM_TLS_IE32 used with non-TLS symbol ?? Oh, that was actually quite obvious... If I revert the first android patch on LLVM sources, and build it back it works! I can build a "Hello world" program on ARM GNU/Linux, with druntime and phobos. I'll write a doc page about that.
Re: shuffle a character array
On Wednesday, 20 July 2016 at 18:32:15 UTC, Jesse Phillips wrote: I think you mean that your range library treats them as arrays of code units, meaning your library will break (some) unicode strings. Right - I disagree with the assessment that all (or even most) char[] types are intended to represent unicode strings, rather than arrays containing chars. If you want your array to be interpreted as a unicode string, then you should use std.utc's byGrapheme or similar functions.
multithreaded hell, help!
Im trying to access data in a global between threads. So ive set my global to shared, however the object trying to access it needs to also then be shared, but it cant be because its part of a library... Is there any simple way to transfer data from one thread to another? 1. My situation is im reading from a serial port in a thread. Which writes to my global. 2. In a draw thread i need to get that data and draw my output. Cheers
Default implementations in inherited interfaces
I have an interface A which declares a certain function. A second
interface B inherits from A and wishes to provide a default
implementation for that function. How can I achieve this? I'm
facing an error when I try this:
interface A
{
int func(int);
}
interface B : A
{
final int func(int)
{
return 0;
}
}
class C : B
{
}
rdmd it.d:
it.d(14): Error: class it.C interface function 'int func(int)' is
not implemented
Thanks,
Saurabh
Re: multithreaded hell, help!
On Thursday, 21 July 2016 at 09:47:09 UTC, rikki cattermole wrote: On 21/07/2016 9:44 PM, Brons wrote: Im trying to access data in a global between threads. So ive set my global to shared, however the object trying to access it needs to also then be shared, but it cant be because its part of a library... Is there any simple way to transfer data from one thread to another? 1. My situation is im reading from a serial port in a thread. Which writes to my global. 2. In a draw thread i need to get that data and draw my output. Cheers __gshared or cast away shared. __gshared has done the trick! Thanks :)
Re: LDC with ARM backend
On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote: I can build a "Hello world" program on ARM GNU/Linux, with druntime and phobos. I'll write a doc page about that. It's a good idea :)
Re: Default implementations in inherited interfaces
On Thursday, 21 July 2016 at 09:46:10 UTC, Lodovico Giaretta wrote: Interesting. This is worth a bugzilla issue, IMHO. In fact, if you try the other way (i.e.: you provide an implementation of func in class C), you get the opposite error, that you are overriding a final function (B.func). Submitted as issue 16306 https://issues.dlang.org/show_bug.cgi?id=16306
Re: Default implementations in inherited interfaces
On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote: I have an interface A which declares a certain function. A second interface B inherits from A and wishes to provide a default implementation for that function. You can't, interfaces cannot have implementations of virtual functions. Your code is trying to define two separate functions with the same name (the compiler should probably prohibit that, since it doesn't do want you want it to do). Your best bet is to make B an abstract class instead of an interface. Then it can override interface functions. Of course, it will also tie you down as you can only inherit from one class, but it will actually work.
Re: full path to source file __FILE__
On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 7/21/16 3:54 PM, Jonathan Marler wrote:
> > Is there a way to get the full path of the current source file?
> > Something like:
> >
> > __FILE_FULL_PATH__
> >
> > I'm asking because I'm rewriting a batch script in D, meant to be ran
> > with rdmd. However, the script needs to know it's own path. The
> > original batch script uses the %~dp0 variable for this, but I'm at a
> > loss on how to do this in D. Since rdmd compiles the executable to the
> > %TEMP% directory, thisExePath won't work.
> >
> > BATCH
> > -
> > echo "Directory of this script is " %~dp0
> >
> >
> > DLANG
> > -
> > import std.stdio;
> > int main(string[] args) {
> >
> > writeln("Directory of this script is ", ???);
> >
> > }
>
> Sure seems like an unwanted limitation.
>
> rdmd does forward all dmd options, but there isn't really an option to
> say "put the exe in the source path".
>
> You should file an enhancement.
It would be pretty terrible actually to put the executable in the source
path, and in many cases, the user wouldn't even have the permissions for it.
For instance, what if the script were in /usr/local/bin? They won't have the
permissions for the executable to end up there, and it would just cause a
bunch of clutter in /usr/local/bin, since you'd get a new executable every
time it decided that it needed to rebuild it (and you wouldn't want it to
delete the executable every time, otherwise it would have to rebuild it
every time, making it so that it would _always_ have to compile your script
when it runs instead of just sometimes). Right now, the executable ends up
in a temp directory, which makes a lot of sense.
Maybe it would make sense to have such a flag for very rare cases, but in
general, it seems like a terrible idea.
- Jonathan M Davis
