Re: D client for ROS
On 07/29/2017 03:21 AM, Johan Engelen wrote: Hi all, Are there any robot folks out here that are working with ROS and would be able to work on creating a D client library for it? ROS is used a lot at our university and in robot research in general, and most people use the C++ client (the main one, next to Python). In arguing for teaching D at our university, it would help a lot if students could use D with ROS. Cheers, Johan (fyi: I'm an assistent prof Robotics and Mechatronics and LDC developer) Looks like you will have to make a robot to have it write the D client for ROS. :o) Ali
Re: newCTFE Status July 2017
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: [ ... ] Hello Guys, The bug preventing newCTFE from executing bf_ctfe[1] correctly (a peculiarity in which for for and if statement-conditions other then 32bit integers where ignored) is now fixed. newCTFE is about 5.7 times faster compiling bf_ctfe. (compiling bf_ctfe includes a test where a brainfuck interpreter written in brainfuck executes the brainfuck hello-world programm) Here are the numbers: uplink@uplink-desktop:~/d/dmd$ time src/dmd ../bf-ctfe/source/*.d -c -o- > x Hello World! Hello World! real0m0.113s user0m0.104s sys 0m0.008s uplink@uplink-desktop:~/d/dmd$ time dmd ../bf-ctfe/source/*.d -c > x Hello World! Hello World! real0m0.633s user0m0.600s sys 0m0.028s [1] https://github.com/UplinkCoder/bf_ctfe
Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.
What do you think about adding an optional config value `defaultArch` to dub? It would be used when no arch is specified. I could specify default arch as x86_64 and everything would be fine.
Re: M:N thread multiplexing
On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote: Reading this article: http://www.evanmiller.org/why-im-learning-perl-6.html makes me curious about the state of Dlang's M:N thread multiplexing. Quoting the article: "if you want M:N thread multiplexing your options today are precisely Erlang, Go, .NET, and Perl 6." Is it possible to add D to this list of languages mentioned in that article? Whenever I asked about CSP in D I got the answer to consider vibe.d. D has fibers. In addition to have something like green threads, it would need a mechanism that a fiber that is going to be blocked when taking from an empty channel is detached from that channel and assigned to one that is not empty. Not sure I agree that .NET has m:n threads in sense of CSP/green threads. About Perl 6 I don't know. Java has it as well through Quasar (http://docs.paralleluniverse.co/quasar/) and the JVM in general through Coroutines in Kotlin (https://kotlinlang.org/docs/reference/coroutines.html)
Re: undefined reference to `rt_loadLibrary'
On Sunday, 30 July 2017 at 16:44:52 UTC, Jean-Louis Leroy wrote: Hello, I am trying to dynamically load a shared object using core.runtime.Runtime.loadLibrary. The link fails with a undefined reference to `rt_loadLibrary' error. Indeed when I `nm /usr/lib/x86_64-linux-gnu/libphobos2.a` I don't see it there. Is an extra lib needed? [...] OK after more googling I found that adding `dflags "-defaultlib=phobos2` to my dub.sdl file solves this problem.
undefined reference to `rt_loadLibrary'
Hello, I am trying to dynamically load a shared object using core.runtime.Runtime.loadLibrary. The link fails with a undefined reference to `rt_loadLibrary' error. Indeed when I `nm /usr/lib/x86_64-linux-gnu/libphobos2.a` I don't see it there. Is an extra lib needed? dub -v output: openmethods:dynaload 0.0.9+commit.3.g6bc05eb: building configuration "application"... dmd -c -ofexamples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload.o -debug -g -w -version=Have_openmethods_dynaload -version=Have_openmethods -version=Have_openmethods_dynalib -Iexamples/dynaload/source/ -Isource/ -Iexamples/dynalib/source/ examples/dynaload/source/app.d -vcolumns Linking... dmd -ofexamples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload examples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload.o examples/dynalib/.dub/build/library-debug-linux.posix-x86_64-dmd_2075-A1AE604B4B5F4B4357215CE03CBCA526/libopenmethods_dynalib.a .dub/build/library-debug-linux.posix-x86_64-dmd_2075-906C07C721DFE17599071D69E200CEC8/libopenmethods.a -L--no-as-needed -g examples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:222: undefined reference to `rt_loadLibrary' collect2: error: ld returned 1 exit status
Re: newCTFE Status July 2017
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: [ ... ] Hi Guys, After getting the brainfuck to D transcompiler to work. I now made it's output compatible with newCTFE. See it here: https://gist.github.com/UplinkCoder/002b31572073798897552af4e8de2024 Unfortunately the above code does seem to get mis-compiled, As it does not output Hello World, but rather:
Re: M:N thread multiplexing
On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote: Reading this article: http://www.evanmiller.org/why-im-learning-perl-6.html makes me curious about the state of Dlang's M:N thread multiplexing. Quoting the article: "if you want M:N thread multiplexing your options today are precisely Erlang, Go, .NET, and Perl 6." Is it possible to add D to this list of languages mentioned in that article? There is std.parallelism, which maps M tasks to N threads [1]. Not sure how it deals with blocking I/O, though. [1] https://dlang.org/phobos/std_parallelism.html
M:N thread multiplexing
Reading this article: http://www.evanmiller.org/why-im-learning-perl-6.html makes me curious about the state of Dlang's M:N thread multiplexing. Quoting the article: "if you want M:N thread multiplexing your options today are precisely Erlang, Go, .NET, and Perl 6." Is it possible to add D to this list of languages mentioned in that article?
Re: newCTFE Status July 2017
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
[ ... ]
Hey Guys!
working on the ctfe brainfuck compiler I finally figured out what
was going wrong.
consider this:
uint fn ()
{
uint[1] pointlessArray = [0];
foreach(0 .. 42)
pointlessArray[0]++;
return pointlessArray[0];
}
static assert(fn() == 42);
until a few minutes ago this would have failed and the output
would have been 0;
can you guess why ?
Well, while the ++array[0] would lower to BinAssignExp (array[0]
+= 1) which does correctly deal with references
++ is actually not lowerd but it's own special expression.
which is handled with the following code:
auto expr = genExpr(e.e1); // in x++ expr is the x
if (!canWorkWithType(expr.type) ||
!canWorkWithType(retval.type))
{
bailout("++ only i32 is supported not " ~
to!string(expr.type.type) ~ " -- " ~ e.toString);
return;
}
assert(expr.vType != BCValueType.Immediate,
"++ does not make sense as on an Immediate
Value");
Set(retval, expr); // return a copy of the old
value
// the following code adds one the the original
value
if (expr.type.type == BCTypeEnum.f23)
{
Add3(expr, expr, BCValue(Imm23f(1.0f)));
}
else if (expr.type.type == BCTypeEnum.f52)
{
Add3(expr, expr, BCValue(Imm52f(1.0)));
}
else
{
Add3(expr, expr, imm32(1));
}
of course arr[x]++ will load the value into a temporary and add
one to that temporary
never modifying the array.
Luckily I introduced a a way for rmw (read-modify-write)
operations to be done on structs on arrays a while back.
if the expr is not normal local i.e. a stack-variable it will
have heapRef which tells you to which pointer you have to write
to modify the actual value rather then just modifying the
temporary in which it was loaded.
so this was fixed by adding the following 3 lines.
if (expr.heapRef)
{
StoreToHeapRef(expr);
}
Which will work for array's slices and structs alike :)
Re: Accessing memory after destroy
On Sunday, 30 July 2017 at 07:45:27 UTC, Johan Engelen wrote: On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis wrote: [1] https://dlang.org/spec/class.html#deallocators If destroy has been called on a class object, then it is a bug to access it at any point after that (IIRC, the expectation is that it will blow up in your face, because the vtable is gone - TDPL talks about this, I believe, but I don't know where my copy is at the moment, so I can't check). That being said, the memory is still valid. And as Moritz pointed out, if the memory is accessible, the GC won't free it. So, it's a bug to access the object, but it should be memory safe to do so. If this is the case, then we really need to improve and pin-down the spec on this point. So `destroy` only calls the destructor and puts the object in `T.initializer` (non-constructed) state, and is otherwise not related to memory deallocation. May the destructor be called again when the GC collects the memory? Why is the object put in `T.initializer` state? rt_finalize2 zeroes the vptr out after assigning typeid(T).initializer, so calling the destructor more than once is not possible, unless someone manually saves the vptr and assigns it back to the object after the call to destroy / rt_finalize. To make sure: My question is from a spec point of view. Not about what currently happens and what is "OK" with the current implementation. I guess the spec needs to be updated to state explicitly that a class destructor is called only once, if that's not already the case.
Re: Accessing memory after destroy
On Sunday, 30 July 2017 at 07:58:19 UTC, ketmar wrote: Johan Engelen wrote: [...] afair, somewhere in the spec there is a mention that dtor will be called at most once for each initialized object. and object state doesn't have any sense after calling dtor, but D still has to put something there, so `.init` looks like a reasonable choice. althru i'm not sure that anything in specs says that runtime *must* clear destroyed objects (they aren't really usable after calling dtor anyway, it is at least a logical bug to use object after destroying it). Seems that zeroing it out is better choice, maybe.
Re: Accessing memory after destroy
Johan Engelen wrote: If this is the case, then we really need to improve and pin-down the spec on this point. So `destroy` only calls the destructor and puts the object in `T.initializer` (non-constructed) state, and is otherwise not related to memory deallocation. May the destructor be called again when the GC collects the memory? Why is the object put in `T.initializer` state? To make sure: My question is from a spec point of view. Not about what currently happens and what is "OK" with the current implementation. afair, somewhere in the spec there is a mention that dtor will be called at most once for each initialized object. and object state doesn't have any sense after calling dtor, but D still has to put something there, so `.init` looks like a reasonable choice. althru i'm not sure that anything in specs says that runtime *must* clear destroyed objects (they aren't really usable after calling dtor anyway, it is at least a logical bug to use object after destroying it).
Re: Accessing memory after destroy
On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis wrote: [1] https://dlang.org/spec/class.html#deallocators If destroy has been called on a class object, then it is a bug to access it at any point after that (IIRC, the expectation is that it will blow up in your face, because the vtable is gone - TDPL talks about this, I believe, but I don't know where my copy is at the moment, so I can't check). That being said, the memory is still valid. And as Moritz pointed out, if the memory is accessible, the GC won't free it. So, it's a bug to access the object, but it should be memory safe to do so. If this is the case, then we really need to improve and pin-down the spec on this point. So `destroy` only calls the destructor and puts the object in `T.initializer` (non-constructed) state, and is otherwise not related to memory deallocation. May the destructor be called again when the GC collects the memory? Why is the object put in `T.initializer` state? To make sure: My question is from a spec point of view. Not about what currently happens and what is "OK" with the current implementation.
