Re: The lifetime of reduce's internal seed
On 04/22/2014 11:45 AM, monarch_dodra wrote:
Reduce returns the seed. It's actually doing something more like this:
int[1] foo()
{
int[1] sum
sum = sum[]; //The lambda operates, and the
//result is assigned back to the seed.
return sum; //Returns the seed.
}
My original lambda that returned a slice was correct then. The seed
would eventually be copied out. Had the compiler not allow slicing the
rvalue then I would be in good shape.
BTW, I'm re-implemented reduce recently (not yet pulled), but I was
*very* thorough about documenting what it does:
https://github.com/D-Programming-Language/phobos/pull/2060
Could you take a look at it (the documentation I mean), and tell me if
everything is what you would have expected?
I think it looks great! :)
Two comments/questions which I did not make on github:
1) Some of the documentation comments that are inside a scope are not
formatted as such. For example, this comment does not start with /++ :
https://github.com/monarchdodra/phobos/blob/reduceReimpl/std/algorithm.d#L753
I wonder whether they are still included in the produced documentation.
2) I think even single-line code blocks should have curly brackets but
Phobos code does not follow that guideline. :)
Ali
Another bug in function overloading?
module test;
public interface I
{
void foo();
void foo(int);
}
public abstract class A : I
{
public void bar()
{
foo();
}
public void foo(int i)
{
}
}
public class C : A
{
public void foo()
{
}
public void bar2()
{
foo(1);
}
}
Error: function test.A.foo (int i) is not callable using argument
types ()
Error: function test.C.foo () is not callable using argument
types (int)
Writing to stdin of a process
I want to be able to write to the stdin stream of an external
process using std.process. I have the following small test app.
myecho.d
--
import std.stdio;
void main(string[] args)
{
foreach (line; stdin.byLine()) {
stdout.writeln(line);
}
}
--
If I call this from the command line, it echo's back whatever I
write
to it.
Then I have the following program.
testpipes.d
---
import std.process;
import std.stdio;
void main( string[] args ) {
auto pipes = pipeProcess(./myecho, Redirect.stdin );
scope(exit) wait(pipes.pid);
pipes.stdin().writeln(Hello world);
}
If I compile and run testpipes.d, nothing happens. I was
expecting
it to echo back Hello world to me.
Can anyone tell me what I am dong wrong.
Re: The lifetime of reduce's internal seed
On Saturday, 26 April 2014 at 06:24:26 UTC, Ali Çehreli wrote:
On 04/22/2014 11:45 AM, monarch_dodra wrote:
Reduce returns the seed. It's actually doing something more
like this:
int[1] foo()
{
int[1] sum
sum = sum[]; //The lambda operates, and the
//result is assigned back to the seed.
return sum; //Returns the seed.
}
My original lambda that returned a slice was correct then. The
seed would eventually be copied out. Had the compiler not allow
slicing the rvalue then I would be in good shape.
Well... your lambda *was* returning a slice to its local copy of
sum. So I thin kit is still wrong. (ref sum, _) = sum[] would
have been correct though.
BTW, I'm re-implemented reduce recently (not yet pulled), but
I was
*very* thorough about documenting what it does:
https://github.com/D-Programming-Language/phobos/pull/2060
Could you take a look at it (the documentation I mean), and
tell me if
everything is what you would have expected?
I think it looks great! :)
Two comments/questions which I did not make on github:
1) Some of the documentation comments that are inside a scope
are not formatted as such. For example, this comment does not
start with /++ :
https://github.com/monarchdodra/phobos/blob/reduceReimpl/std/algorithm.d#L753
I wonder whether they are still included in the produced
documentation.
Nope, that was a mistake on my part. Good catch.
2) I think even single-line code blocks should have curly
brackets but Phobos code does not follow that guideline. :)
Ali
It depends I say. I usually do that, but for certain functions,
such as reduce, it would *literally* double the amount of lines
required to write it. I that point, the function becomes long
enough for it to be a readability problem.
Re: AES encryption with openssl bindings
AES_set_decrypt_key is needed before AES_decrypt. AES_set_decrypt_key(chunk.ptr, 128, wctx);
Re: Another bug in function overloading?
On Sat, 26 Apr 2014 06:55:38 +
Domain via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
module test;
public interface I
{
void foo();
void foo(int);
}
public abstract class A : I
{
public void bar()
{
foo();
}
public void foo(int i)
{
}
}
public class C : A
{
public void foo()
{
}
public void bar2()
{
foo(1);
}
}
Error: function test.A.foo (int i) is not callable using argument
types ()
Error: function test.C.foo () is not callable using argument
types (int)
No. That's expected. If you've overloaded a function from a base class,
only the functions in the derived class are in the overload set, so you
have to bring the base class' overload into the overload by either
overriding the base class overload in the derived class or by aliasing
it in the derived class. e.g.
module test;
public interface I
{
void foo();
void foo(int);
}
public abstract class A : I
{
public void bar()
{
foo();
}
alias I.foo foo;
public void foo(int i)
{
}
}
public class C : A
{
alias A.foo foo;
public void foo()
{
}
public void bar2()
{
foo(1);
}
}
- Jonathan M Davis
Re: Writing to stdin of a process
On Saturday, 26 April 2014 at 08:45:59 UTC, Craig Dillabaugh
wrote:
I want to be able to write to the stdin stream of an external
process using std.process. I have the following small test app.
myecho.d
--
import std.stdio;
void main(string[] args)
{
foreach (line; stdin.byLine()) {
stdout.writeln(line);
}
}
--
If I call this from the command line, it echo's back whatever I
write
to it.
Then I have the following program.
testpipes.d
---
import std.process;
import std.stdio;
void main( string[] args ) {
auto pipes = pipeProcess(./myecho, Redirect.stdin );
scope(exit) wait(pipes.pid);
pipes.stdin().writeln(Hello world);
}
If I compile and run testpipes.d, nothing happens. I was
expecting
it to echo back Hello world to me.
Can anyone tell me what I am dong wrong.
What you are missing is a call to flush() after writeln(). This
is necessary for pipes as they are only automatically flushed if
an internal buffer is full, AFAIK.
Re: Writing to stdin of a process
On Saturday, 26 April 2014 at 08:45:59 UTC, Craig Dillabaugh wrote: Can anyone tell me what I am dong wrong. In this case, I'd close the pipe when you're done. pipes.stdin().writeln(Hello world); pipes.stdin.close; myecho loops on stdin until it receives everything; until the pipe is closed. testpipes waits for myecho to complete before termination. The two processes are waiting on each other: testpipes won't close the file until it exits, and myecho won't exit until testpipes closes the file. an explicit call to close breaks the deadlock. In this case, flushing would cause the one line to appear, because of the buffering yazd talked about, but the program still wouldn't terminate since a flushed buffer still potentially has more coming so echo would see that line, then wait for more..
Re: Another bug in function overloading?
On 4/26/14, Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: No. That's expected. I wonder whether a better diagnostic could help. But then again, maybe the hiding would be intentional and the diagnostic would be spurious/invalid. Not sure..
Re: Writing to stdin of a process
On Saturday, 26 April 2014 at 13:30:41 UTC, Adam D. Ruppe wrote: On Saturday, 26 April 2014 at 08:45:59 UTC, Craig Dillabaugh wrote: Can anyone tell me what I am dong wrong. In this case, I'd close the pipe when you're done. pipes.stdin().writeln(Hello world); pipes.stdin.close; myecho loops on stdin until it receives everything; until the pipe is closed. testpipes waits for myecho to complete before termination. The two processes are waiting on each other: testpipes won't close the file until it exits, and myecho won't exit until testpipes closes the file. an explicit call to close breaks the deadlock. In this case, flushing would cause the one line to appear, because of the buffering yazd talked about, but the program still wouldn't terminate since a flushed buffer still potentially has more coming so echo would see that line, then wait for more.. Thank you Adam, and yazd for your responses, now it works. Thanks also for the explanations, I was wondering how myecho.d would know when the input was finished so it could terminate.
Re: AES encryption with openssl bindings
On Friday, 25 April 2014 at 19:06:33 UTC, brad clawsie wrote: My code compiles and fails silently. How do you want it to fail? C code doesn't throw exceptions.
Creating Libraries Callable from C
Is it possible to write a library that is callable from C without the enduser even knowing it was written in D? That is, can a C programmer use the library as though it were written in C straightforwardly? Or for that matter, by an enduser programming in Python or Lua where the library is being exposed through those languages' C API? I'm sure this is a widely discussed and well understood topic, but I am a newbie (and have no formal training in CS) and don't know where to look for documentation. A little baby tutorial would be super helpful and well received by this newbie. Thanks so much! TJB
DMD Deimos || GDC Deimos?
I'd like to use GLFW from Deimos, but I couldn't get it to work (DMD said it cannot use libglfw.a) and I've read somewhere that only GDC can use these DLLs directly (with a D header, but that's still better than hooking the methods). So do I need GDC for that or not? And would you actually recommend it? On a side note, getting GDC to work is a bitch. I had to copy around several DLLs (like libiconv-2.dll) and it's now working only with the libgcc_s_sjlj-1.dll copied right next to my application's exe. What am I doing wrong? This is really frustrating :/
Re: Creating Libraries Callable from C
It is possible to write a D library useable from C. However, we may not
be able to hide the fact that the library has been written in D.
You must first export some D function you want to use from C, using
extern (C) declaration.
Then declare them in your C program or headers.
You will also have to declare 2 function for initializing and
terminating D's runtime:
char rt_init(long long);
char rt_term(long long);
call rt_init(0) before using your D functions (this will initialize D
runtime - the D GC amongst other things), then use rt_term(0) at the end
of the program - you may want to register an exit function with atexit().
With older versions of DMD we had also to create a D module with an
empty main() function that had to be linked with the C program to force
the D compiler to generate some symbols that were not generated within
the object files. As of dmd 2.064, this is no longer necessary.
Below is an example I once retrieve from this newsgroup:
dlibrary.d
==
import std.stdio, std.array, std.range;
extern(C) void printf(in char*,...);
extern(C) void funcD(){
printf(C's printf in D\n);
writeln(D's writeln);
writeln(D's array alloc: , new double[3]);
writeln(D's iota: , iota(0, 30, 4));
}
cmain.c
===
int printf(char*, ...);
void funcC() {
printf(C's printf in C\n);
}
char rt_init(long long);
char rt_term(long long);
void main(){
// code without D
funcC();
rt_init(0); // initialize D's runtime
//code with D
funcD();
rt_term(0); // terminate D's runtime
//code without D
}
Compilation
===
Compiling the D library
---
dmd -c dlibrary.d
Compiling the C executable
--
You can do it with either dmd or gcc
gcc -o cmain cmain.c dlibrary.o \
-m32 -lrt -lphobos2 -lpthread -lm \
-Xlinker -L$DMD/linux/lib32 \
-Xlinker --no-warn-search-mismatch \
-Xlinker --export-dynamic
To get the proper gcc flags, use dmd in verbose mode:
- first compile cmain: gcc -c cmain.c
- then: dmd -v cmain.o dlibrary.o
Executing
-
./cmain
C's printf in C
C's printf in D
D's writeln
D's array alloc: [nan, nan, nan]
D's iota: [0, 4, 8, 12, 16, 20, 24, 28]
D from other programming languages
==
There is a project to write python extensions in D PYD:
https://bitbucket.org/ariovistus/pyd
I also wrote about my experiment of using Swig for a proof of concept
PHP extension in D:
http://forum.dlang.org/post/gwqstgaiivknieyqf...@forum.dlang.org
What works for PHP can work for the other Swig supported languages
(Java, C#, Go, Perl, Ruby...).
On 04/26/2014 07:13 PM, TJB wrote:
Is it possible to write a library that is callable from C without the
enduser even knowing it was written in D? That is, can a C programmer
use the library as though it were written in C straightforwardly? Or for
that matter, by an enduser programming in Python or Lua where the
library is being exposed through those languages' C API?
I'm sure this is a widely discussed and well understood topic, but I am
a newbie (and have no formal training in CS) and don't know where to
look for documentation.
A little baby tutorial would be super helpful and well received by this
newbie.
Thanks so much!
TJB
Static constructors inconsistency
Hello, i'am experiencing some non consistent behavior with static
constructors. I wonder if this is some bug or i just don't know
enough of D (most probably!).. Code example bellow:
//--
module main;
import std.stdio;
class B
{
static this()
{
A a = new A;
int val = a.getValue(A);
}
}
class A {
private static int[string] aa;
static this()
{
aa = [A:1, B:2];
writeln(@ A static ctor!);
}
int getValue(string str)
{
return aa[str];
}
}
void main(string[] args)
{
B B = new B;
}
//--
The text @ A static ctor! never gets printed. The inconsistency
(IMHO) is that if i do any of this:
- Declare class A before B;
- Change the var declared in A from an AA to some other p.e int;
- Comment the line int val = a.getValue(A);
Maybe there are some other points, but at this point i got
confused and decided trying to understand it. Anyway with any of
those changes the text gets printed.
Anyone able to shed some light into this?
Cheers,
Re: Static constructors inconsistency
Btw, i only tested this using v2.065.0 of DMD. Cheers,
Re: DMD Deimos || GDC Deimos?
On 04/26/2014 08:18 PM, Entry wrote: I'd like to use GLFW from Deimos, but I couldn't get it to work (DMD said it cannot use libglfw.a) and I've read somewhere that only GDC can use these DLLs directly (with a D header, but that's still better than hooking the methods). So do I need GDC for that or not? And would you actually recommend it? On a side note, getting GDC to work is a bitch. I had to copy around several DLLs (like libiconv-2.dll) and it's now working only with the libgcc_s_sjlj-1.dll copied right next to my application's exe. What am I doing wrong? This is really frustrating :/ With MinGW you would use the: -static-libgcc flag when linking the application. I'm not sure if gdc also supports this, but you can give it a try. -- Mike Wey
Re: Problem with code coverage. No .lst files?
On Friday, 25 April 2014 at 08:20:37 UTC, Jeremy DeHaan wrote:
On Friday, 25 April 2014 at 04:23:45 UTC, Ali Çehreli wrote:
On 04/24/2014 08:32 PM, Jeremy DeHaan wrote:
added the -cov switch to my unit test build
Then you must execute the program. :)
Ali
I did, but still nothing. I even tried using the switch in a
debug build and the same thing happened(or didn't happen I
guess). I'm using Mono-D to build if that makes any difference,
and I've tried running it both through Mono-D and via the
application itself. I'm not sure what to do. :(
Well, I think I found out what was happening. If you compile with
-cov AND use -of where the output file is in a different
directory than where the build is taking place(eg, buld happens
in C:/DProject/, and the command line has
-ofC:/DProject/Unittest/Unittest.exe), no .lst files are
produced. I guess the compiler isn't sure where to put them? In
any case, I removed the -of switch and when I ran that
application .lst files were now created in the same directory as
the application. Is this a bug that needs to be reported?
Here's a simple test that reproduces the issues.
test.d
===
module test;
class Test
{
int thing;
this(int newThing)
{
thing = newThing;
}
void showThing()
{
import std.stdio;
writeln(thing);
}
}
unittest
{
auto tester = new Test(100);
tester.showThing();
}
command line that will produce .lst file: dmd test.d -cov
-unittest -main -ofWill.exe
command line that won't produce .lst file: dmd test.d -cov
-unittest -main -oftest\Wont.exe
storing pointers in Variants
I am trying to create a class that can do the following: --- int sample = 42; // myObj is an instance of the class I'm writing myObj.attach (othername, sample); myObj.set (othername, 69); writeln (myObj.get (othername), \t, sample); // should produce '69 69' --- Currently, my class appends to an array of Variants, and can store data internally in this array. Ref parameters don't work with variants, and pointers cause exceptions to be thrown. What would be the best way to go about this? I had momentarily considered using a struct that stores a void pointer to the data, along with type info, and using this to replace the Variant, but I like the ability to change the type at runtime. Any advice would be much appreciated.
Re: Problem with code coverage. No .lst files?
On 04/26/2014 01:11 PM, Jeremy DeHaan wrote: If you compile with -cov AND use -of where the output file is in a different directory than where the build is taking place(eg, buld happens in C:/DProject/, and the command line has -ofC:/DProject/Unittest/Unittest.exe), no .lst files are produced. I can reproduce it under Linux if I change to the program directory and run the program in there. However, if I run the program with its full path when I am inside the original directory where I built the program from, then the .lst file gets generated. Is this a bug that needs to be reported? Yes. command line that will produce .lst file: dmd test.d -cov -unittest -main -ofWill.exe command line that won't produce .lst file: dmd test.d -cov -unittest -main -oftest\Wont.exe So, under Linux, if I start the program as test/wont then the .lst gets generated in the current directory. Ali
Re: storing pointers in Variants
On 04/26/2014 04:08 PM, Matt wrote:
I am trying to create a class that can do the following:
---
int sample = 42;
// myObj is an instance of the class I'm writing
myObj.attach (othername, sample);
myObj.set (othername, 69);
writeln (myObj.get (othername), \t, sample); // should produce '69 69'
---
Currently, my class appends to an array of Variants, and can store data
internally in this array. Ref parameters don't work with variants, and
pointers cause exceptions to be thrown. What would be the best way to go
about this?
I had momentarily considered using a struct that stores a void pointer
to the data, along with type info, and using this to replace the
Variant, but I like the ability to change the type at runtime.
Any advice would be much appreciated.
I think the following is a start:
import std.variant;
class MyClass
{
Variant[string] store;
void attach(T)(string key, ref T var)
{
store[key] = var;
}
void set(T)(string key, T value)
{
*store[key].get!(T*) = value;
}
T get(T)(string key)
{
return *store[key].get!(T*)();
}
}
void main()
{
int sample = 42;
auto myObj = new MyClass;
myObj.attach(othername, sample);
myObj.set(othername, 69);
assert(myObj.get!int(othername) == 69);
assert(sample == 69);
}
Ali
Can I circumvent nothrow?
So I have this procedure: extern (C) void signal_proc(int sn) @system nothrow Which can call this: shutdown_system() @system nothrow Problem I have is inside shutdown_system() I have code that can't possibly be @nothrow because their are a lot of subsystems to shutdown. What I've done for now is just strip the @nothrow attribute of the C function in core.stdc.signal. It feels very hackish but it works..
Re: DMD Deimos || GDC Deimos?
On 4/27/2014 3:18 AM, Entry wrote: I'd like to use GLFW from Deimos, but I couldn't get it to work (DMD said it cannot use libglfw.a) and I've read somewhere that only GDC can use these DLLs directly (with a D header, but that's still better than hooking the methods). So do I need GDC for that or not? And would you actually recommend it? On a side note, getting GDC to work is a bitch. I had to copy around several DLLs (like libiconv-2.dll) and it's now working only with the libgcc_s_sjlj-1.dll copied right next to my application's exe. What am I doing wrong? This is really frustrating :/ 32-bit DMD on Windows expects object files in the OMF format. MinGW, IIRC, outputs objects in the COFF format. 64-bit DMD uses the COFF format through the Microsoft toolchain, but I don't know if that toolchain can link with MinGW libraries (it works the other way). I suggest one of three things: * Use the glfw DLL rather than the static library. You can use it with 32-bit DMD by running implib on the DLL and then linking with the resulting import library (which will be in OMF format). * Compile GLFW in 64-bit with Visual C++ then compile your project with DMD in 64-bit using the MS toolchain. You should be able to link statically or dynamically without trouble here. * Use DerelictGLFW and don't worry about linking with anything. It loads glfw.dll at runtime so that there are no compile-time dependencies other than Derelict itself.
Re: Can I circumvent nothrow?
On 04/26/2014 06:39 PM, Damian Day wrote: Problem I have is inside shutdown_system() I have code that can't possibly be @nothrow because their are a lot of subsystems to shutdown. You can wrap the contents of shutdown_system() with a try-catch block and swallow all exceptions that way. Ali
Re: Can I circumvent nothrow?
On Sunday, 27 April 2014 at 01:53:15 UTC, Ali Çehreli wrote: On 04/26/2014 06:39 PM, Damian Day wrote: Problem I have is inside shutdown_system() I have code that can't possibly be @nothrow because their are a lot of subsystems to shutdown. You can wrap the contents of shutdown_system() with a try-catch block and swallow all exceptions that way. Ali Oh right, didn't realize it would be that simple. Thank you!!
Re: Static constructors inconsistency
On 04/26/2014 12:10 PM, spec wrote:
Hello, i'am experiencing some non consistent behavior with static
constructors. I wonder if this is some bug or i just don't know enough
of D (most probably!).. Code example bellow:
//--
module main;
import std.stdio;
class B
{
static this()
{
A a = new A;
int val = a.getValue(A);
}
}
class A {
private static int[string] aa;
static this()
{
aa = [A:1, B:2];
writeln(@ A static ctor!);
}
int getValue(string str)
{
return aa[str];
}
}
void main(string[] args)
{
B B = new B;
}
//--
The text @ A static ctor! never gets printed. The inconsistency (IMHO)
is that if i do any of this:
- Declare class A before B;
- Change the var declared in A from an AA to some other p.e int;
- Comment the line int val = a.getValue(A);
Maybe there are some other points, but at this point i got confused and
decided trying to understand it. Anyway with any of those changes the
text gets printed.
Anyone able to shed some light into this?
Cheers,
I don't know whether the inconsistency is a bug but according to
documentation, static this inside a module are executed in lexical
order: Static constructors within a module are executed in the lexical
order in which they appear.
http://dlang.org/class.html#StaticConstructor
So, if B depends on A then A's static this must appear before B's.
Ali
Re: Creating Libraries Callable from C
On 04/26/2014 11:27 AM, Rémy Mouëza wrote:
You will also have to declare 2 function for initializing and
terminating D's runtime:
char rt_init(long long);
char rt_term(long long);
call rt_init(0) before using your D functions (this will initialize D
runtime - the D GC amongst other things), then use rt_term(0) at the end
of the program - you may want to register an exit function with atexit().
And if those functions are called from the library's own initialization
and deinitialization functions, the C program need not know anything
about the D runtime dependence:
void mylib_init() {
rt_init(0);
// ... other initialization
}
Ali
Re: Problem with code coverage. No .lst files?
On Sunday, 27 April 2014 at 00:37:39 UTC, Ali Çehreli wrote: So, under Linux, if I start the program as test/wont then the .lst gets generated in the current directory. Ali Just tried that in Windows, and the same thing happened. Weird! I'll be sure to file a bug report. Thanks for the confirmation, Ali!
Re: Creating Libraries Callable from C
On Sunday, 27 April 2014 at 02:15:59 UTC, Ali Çehreli wrote:
And if those functions are called from the library's own
initialization and deinitialization functions, the C program
need not know anything about the D runtime dependence:
void mylib_init() {
rt_init(0);
// ... other initialization
}
and what if user links two such libraries? ;-)
