Re: deimos libX11 undefined reference
Am 12.07.2012 08:17, schrieb Jacob Carlborg: > On 2012-07-12 01:50, cal wrote: > >> Hmm, looking at the .c header, the function is not even defined. I think >> it is not used, and in this case turning macros into functions in the >> binding generates linker errors. I don't know the best way to fix this >> in the binding (I have simply commented out the functions in my repo, as >> they don't seem to be used). But its worth noting. > > If a macro is turned into a function it needs to have an implementation. > when marcos are turned into functions they introduce new symbols. it's a pity, but in that case you have to link to deimos. so deimos will become a wrapper rather than a binding.
Re: why is string not implicit convertable to const(char*) ?
Your answers are remarkable elaborated. Thanks for your great effort, Jonathan!! ;-)
why is string not implicit convertable to const(char*) ?
does anyone know why string not implicit convertable to const(char*) ?
---
import core.sys.posix.unistd;
void main()
{
// ok
unlink("foo.txt");
// failed
string file = "bar.txt";
unlink(file);
}
test.d(10): Error: function core.sys.posix.unistd.unlink (const(char*))
is not callable using argument types (string)
test.d(10): Error: cannot implicitly convert expression (file) of type
string to const(char*)
Re: foreach_reverse error
>> group returns a lazy forward range. use foreach(i; group(retro(ints))) > > Yet another reason foreach_reverse needs to go. > > > T > No please don't! There are hundred and ten very usefull cases.
Re: getgrgid() for Posix
Am 08.05.2012 18:26, schrieb useo6: > Hi everyone, > > does anyone know how I can the name of a group in Posix? In C/C++ I can use > getgrgid(), but I just found nothing like this function. Is there any > alternative > to get the name of a group of a file? > > Thanks in advance! Yes that true, it's neither in phobos nor in druntime. Why not using the C Method? Just declare it as extern(C) and use it ;-).
Re: ptrace (process trace system call) on Linux from D
Am 08.05.2012 18:12, schrieb Matej Nanut: > On Monday, 7 May 2012 at 22:56:07 UTC, mta`chrono wrote: >> What do you meant by "D alternatives to wait() and fork() that could be >> used with ptrace()". Maybe I don't understand your intention. > > Nevermind with that; I've been confused since there are exec*() > functions in std.process, but no wait() and fork(). I think there's a > new std.process in the works that has more D-ish ways to do these. > > And thanks for the core.* VS std.c.* clarification. I didn't even think > of using core.* all the way for libc bindings. But consider that fork() is a very specific UNIX syscall. There is nothing similar like that on Windows. That's maybe why they didn't wrap it in Phobos. Maybe the same applies to wait() that seems to rely on the UNIX signal stuff. But there should be some kind of derivate on windows, too. But neverthenless you are free to use every C-Funktion. You just need some kind of definition to tell dmd to create the right symbols. If the definition is already present in druntime, it's fine - just use it! otherwise you have to define it yourself. > > If struct method names are mangled, does that mean that that way of > doing it doesn't work? I'll try it anyway, to try and get rid of a few > extra files. It shouldn't work. But you can add another custom ptrace method (_NOT_ extern(C)) with different operators. If you can give more information of your superior intention (what are you going to create?) then I'll might provide a better assistance!
Re: ptrace (process trace system call) on Linux from D
> (2) Is it more D-ish to use something like "enum PTRequest { traceMe =
> 0, ... }" instead of the fully capitalised originals? It doesn't seem
> to affect the working of things.
Yes, that's more D-ish. In new D code I prefer the camelcased ones, but
there are cases where you'd like to use the original ones. it's up to! ;-)
> (3) wait() is declared as returning a pid_t in the manpage, and is
> declared as such in core.sys.posix.sys.wait. In std.c.process however,
> it returns an int. I can't even find a process.h in my Linux install.
> What am I supposed to use? I know it essentially doesn't matter, as
> pid_t is aliased as int.
> Are there D alternatives to wait() and fork() that I could use with
> ptrace() instead of the C posix system functions?
>
> (4) Some things are declared only in core.*, not in std.*. Will they be
> added at some point or is this how it's supposed to be?
I thing core.* (druntime) is the right place for _all_ bindings to libc.
But yeha, there are still some relicts in std.c.* of the good old days.
What do you meant by "D alternatives to wait() and fork() that could be
used with ptrace()". Maybe I don't understand your intention.
Re: ptrace (process trace system call) on Linux from D
Am 25.04.2012 18:36, schrieb Matej Nanut:
> Hello everyone,
>
> I would like to know how to call ptrace (the system call) from D.
>
> I don't know what to import or link. If my understanding is correct, I
> need to create a .di file of some sort with stuff declared in it. How
> would I do this?
>
> Thanks, Matej
Hello Matej,
I guess you're asking for http://linux.die.net/man/2/ptrace.
normally it's somewhere deep in druntime but I couldn't find it. Maybe
someone is able to add it for you. But neverthenless, you can just put
some declaration in your D file and call it.
import core.stdc.stdio;
import core.sys.posix.sys.types;
enum __ptrace_request
{
PTRACE_TRACEME = 0,
PTRACE_PEEKTEXT = 1,
PTRACE_PEEKDATA = 2,
PTRACE_PEEKUSER = 3,
PTRACE_POKETEXT = 4,
PTRACE_POKEDATA = 5,
PTRACE_POKEUSER = 6,
PTRACE_CONT = 7,
PTRACE_KILL = 8,
PTRACE_SINGLESTEP = 9,
PTRACE_GETREGS = 12,
PTRACE_SETREGS = 13,
PTRACE_GETFPREGS = 14,
PTRACE_SETFPREGS = 15,
PTRACE_ATTACH = 16,
PTRACE_DETACH = 17,
PTRACE_GETFPXREGS = 18,
PTRACE_SETFPXREGS = 19,
PTRACE_SYSCALL = 24,
PTRACE_SETOPTIONS = 0x4200,
PTRACE_GETEVENTMSG = 0x4201,
PTRACE_GETSIGINFO = 0x4202,
PTRACE_SETSIGINFO = 0x4203
}
extern(C) long ptrace(__ptrace_request request, pid_t pid, void *addr,
void *data);
void main()
{
// just call ptrace like you would do in C
}
Re: Does D supply basic error codes?
import core.stdc.stdlib;
int main()
{
return EXIT_FAILURE; // EXIT_SUCCESS works here too.
}
Am 30.01.2012 00:21, schrieb NewName:
> Hello all.
> C has EXIT_FAILURE and EXIT_SUCCESS to be returned from main().
> Does D have similar predefined values?
Re: char* to long
Why not just go the "good old" way? you char* should be zero terminated
when coming from c.
private import core.stdc.stdlib,
std.stdio;
void main()
{
const(char)* str = "1234567890".ptr;
long lng = atoll(str);
writeln(lng);
}
Re: newbie question: Can D do this?
In PHP frameworks often use $option arrays which are some kind of key
value pairs. they are merged with the default valuzes inside the function.
pro:
- you can pass an argument by name
- you only need to pass those who needed.
cons:
- hash arrays
it should be possible to create a similar method in d. but I really
don't like this solution in d. it feels bad and looks ugly.
query(array(
'firstname' => 'John',
'country' => 'France',
'order' => 'asc'
));
class Model
{
function query($options = array())
{
// merge with defaults
$options = array_merge(array(
'deep' => true,
'order' => 'desc',
'type' => 'sql',
'backend' => 'mysql'
...
), $options);
}
}
?>
Re: Restrict access to "critical" functions
Maybe you should use a VM to run your restricted applications. Or have a look a chroot, dchroot or schroot, to setup such stuff. The Programming Language will not help you in this case!
Re: Abstract functions in child classes
Even if the current behavior (what Adam mentioned) is not a bug, I think it seems to be a pitfall for std::programmer. The language/compiler should be more restrictive in this case.
Re: dup method const or not?
Okay, what about this hack?
---
import std.bitmanip;
import core.stdc.string;
void main()
{
const(BitArray) foo;
BitArray bar;
bar.len = foo.len;
bar.ptr = foo.ptr[0 .. foo.dim].dup.ptr;
}
---
Re: dup method const or not?
that's a real good question. it fails with the following error:
Error: function std.bitmanip.BitArray.dup () is not callable using
argument types () const
here is a hack:
---
import std.bitmanip;
import core.stdc.string;
void main()
{
const(BitArray) foo;
BitArray bar;
memcpy(&bar, &foo, BitArray.sizeof);
}
---
Re: auto
Did you know that auto is not auto in the way auto behalfs. it's just a
placeholder so the compiler can determine that a variable follows. but
you can use any other keyword for type interfering, too.
void main()
{
const a = FunctionThatReturnsSomething();
static b = 5.0;
scope c = "hey";
}
Re: DFastCGI
IIRC there are two version of fastcgi / fgci ? The one is using stdin, stdout for communication and the application is running as a child of the webserver. And the other is running as a standalone application using unix sockets for communcation. Is DFastCGI able to handle both?
Re: What is shared functions?
> void main() {
> shared s1 = cast(shared)new S();
> s1.onlyShared(); // ok
> //s1.notShared(); // error: not callable using argument types () shared
> auto s2 = new S();
> //s2.onlyShared(); // error: not callable using argument types ()
> s2.notShared(); // ok
> }
I would rather prefer "auto s1 = new shared(S);" because "shared s1 =
new S();" seems to allocate a TLS variable which is then casted to
shared which is actually non-TLS.
