Re: [dub] specify dependency configuration
I forgot to mention dub should automatically choose the first configuration available if you do not specify it. In this case that's the library one. Or atleast it should do that.
Re: import conflicts
On 1/19/2015 4:37 AM, AndyC wrote:
On Sunday, 18 January 2015 at 19:20:34 UTC, Vlad Levenfeld wrote:
I get this all the time with std.array.array (I use my own array
implementations, but phobos' array seems to secretly creep in
everywhere). I think its got to do with that private import visibility
bug (https://issues.dlang.org/show_bug.cgi?id=314 or
https://issues.dlang.org/show_bug.cgi?id=13096 I think)
which, by the looks of it, should be getting a fix... soon? ish?
Ah, if its just a compiler bug I'm ok with that. I was worried there
was something about the language I didnt understand.
I got it to compile ok using:
import std.file: remove, exists, rename;
Thanks,
-Andy
The problem is, that's the bug Vlad was talking about. Selective imports
wind up becoming public, polluting the namespace. The thing to do when
you get conflicts is to use the fully-qualified function name, like so:
std.file.remove( lastUpdate.7z );
Keep those selective imports out of module scope until the bug is fixed.
They work in local scope just fine:
void foo() {
import std.file : remove, exists;
if( exists( foo )) remove( foo );
}
Re: simple assignment statement compiles but becomes a run time error
On Monday, 19 January 2015 at 02:04:23 UTC, Mike Parker wrote: On 1/19/2015 10:44 AM, WhatMeWorry wrote: On Sunday, 18 January 2015 at 20:07:25 UTC, weaselcat wrote: On Sunday, 18 January 2015 at 19:51:02 UTC, WhatMeWorry wrote: On Sunday, 18 January 2015 at 19:42:33 UTC, WhatMeWorry wrote: I've got a OpenGL function returning a pointer // const GLubyte *version = glGetString(GL_VERSION); // C++ and openLG code // the following compiles with no errors or warnings char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); // ABENDS HERE! // documentation from std.string shows // pure @system inout(char)[] fromStringz(inout(char)* cString); // Seems pretty innocuous to me. Debugger returns: Unhandled exception at 0x76AC2F71 (KernelBase.dll) in WhatVersionOfOpenGL.exe Hi, try replacing the fromStringz with to!string from std.conv No cigar. char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); causes the same exception. Thanks for suggestion. Could (Can?) OpenGL be marking the string as read only? So we can print out value put not copy it? You're trying to shove a dynamic array into a static array. That isn't going to fly. Your openglVersion variable needs to be dynamic. Declare it as string or auto: auto openglVersion = fromStringz( glGetString( GL_Version )); Note that fromStringz returns a slice of the C string, which means that if the C string doesn't survive after the return call, or if you plan to keep your D string around outside of the call site, you can get a crash. The OpenGL specification requires strings returned by glGetString to be static, i.e. the pointer will always be valid, so you can do whatever you want. Generally, though, to!string is what you want. It allocates memory for the string and copies it. the array type helpers _.idup_ and _.dup_ can also be used to have a safe copy: `` auto openglVersion = glGetString(GL_Version).fromStringz.idup; ``
Re: Bug on Posix IPC_STAT. Wrong number of attachments
On Monday, 19 January 2015 at 04:18:47 UTC, tcak wrote: On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote: On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote: After these, it works perfectly. I hope this can be fixed in next version. Please file a bug at https://issues.dlang.org/. And since you seem to know how to fix it, maybe you can make a pull request via GitHub, too? https://issues.dlang.org/show_bug.cgi?id=14007 I am not familiar with Github's pull system etc. So, I will prepare the fixed code and attach it on issue. Fixed shm.d file is put on issue page. If someone could put a pull request on Github with it. shmid_ds is on version(linux) part is fixed up on it, and works properly. But tested on 64-bit system only.
Re: druntime build failing because of masm386 problems
On Sunday, January 18, 2015 23:21:43 jollie via Digitalmars-d-learn wrote: Jonathan M Davis via Digitalmars-d-learn digita lmars-d-le...@puremagic.com Wrote in message: It's been a while since I did anything in Windows with D, and unfortunately, I need to again, and now I can't get druntime to build. I'm getting this lovely error: dmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH Error: 'dmc' not found I know that I've seen this before, but I can't remember how to fix the problem. dmc is definitely on my PATH (I successfully built dmd prior to trying to build druntime), so the error seems to be wrong, for whatever good that does me. I don't see a masm386 with dmc, so I don't know where that comes from. Maybe that's part of the problem. Has anyone seen this problem and figured out how to get around it or fix it? - Jonathan M Davis It's been some months since I had this problem pop up, but I just ran touch on the minit.obj file so make thought it was up to date and used it. That did the trick. Thanks. It looks like that has to be done after every time I run clean. That definitely sucks. - Jonathan M Davis
Re: simple assignment statement compiles but becomes a run time error
On 1/19/2015 10:44 AM, WhatMeWorry wrote: On Sunday, 18 January 2015 at 20:07:25 UTC, weaselcat wrote: On Sunday, 18 January 2015 at 19:51:02 UTC, WhatMeWorry wrote: On Sunday, 18 January 2015 at 19:42:33 UTC, WhatMeWorry wrote: I've got a OpenGL function returning a pointer // const GLubyte *version = glGetString(GL_VERSION); // C++ and openLG code // the following compiles with no errors or warnings char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); // ABENDS HERE! // documentation from std.string shows // pure @system inout(char)[] fromStringz(inout(char)* cString); // Seems pretty innocuous to me. Debugger returns: Unhandled exception at 0x76AC2F71 (KernelBase.dll) in WhatVersionOfOpenGL.exe Hi, try replacing the fromStringz with to!string from std.conv No cigar. char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); causes the same exception. Thanks for suggestion. Could (Can?) OpenGL be marking the string as read only? So we can print out value put not copy it? You're trying to shove a dynamic array into a static array. That isn't going to fly. Your openglVersion variable needs to be dynamic. Declare it as string or auto: auto openglVersion = fromStringz( glGetString( GL_Version )); Note that fromStringz returns a slice of the C string, which means that if the C string doesn't survive after the return call, or if you plan to keep your D string around outside of the call site, you can get a crash. The OpenGL specification requires strings returned by glGetString to be static, i.e. the pointer will always be valid, so you can do whatever you want. Generally, though, to!string is what you want. It allocates memory for the string and copies it.
Re: Bug on Posix IPC_STAT. Wrong number of attachments
On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote: On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote: After these, it works perfectly. I hope this can be fixed in next version. Please file a bug at https://issues.dlang.org/. And since you seem to know how to fix it, maybe you can make a pull request via GitHub, too? https://issues.dlang.org/show_bug.cgi?id=14007 I am not familiar with Github's pull system etc. So, I will prepare the fixed code and attach it on issue.
Re:druntime build failing because of masm386 problems
Jonathan M Davis via Digitalmars-d-learn digita lmars-d-le...@puremagic.com Wrote in message: It's been a while since I did anything in Windows with D, and unfortunately, I need to again, and now I can't get druntime to build. I'm getting this lovely error: dmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH Error: 'dmc' not found I know that I've seen this before, but I can't remember how to fix the problem. dmc is definitely on my PATH (I successfully built dmd prior to trying to build druntime), so the error seems to be wrong, for whatever good that does me. I don't see a masm386 with dmc, so I don't know where that comes from. Maybe that's part of the problem. Has anyone seen this problem and figured out how to get around it or fix it? - Jonathan M Davis It's been some months since I had this problem pop up, but I just ran touch on the minit.obj file so make thought it was up to date and used it. --
Re: druntime build failing because of masm386 problems
On 19/01/2015 4:53 p.m., Jonathan M Davis via Digitalmars-d-learn wrote: It's been a while since I did anything in Windows with D, and unfortunately, I need to again, and now I can't get druntime to build. I'm getting this lovely error: dmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH Error: 'dmc' not found I know that I've seen this before, but I can't remember how to fix the problem. dmc is definitely on my PATH (I successfully built dmd prior to trying to build druntime), so the error seems to be wrong, for whatever good that does me. I don't see a masm386 with dmc, so I don't know where that comes from. Maybe that's part of the problem. Has anyone seen this problem and figured out how to get around it or fix it? - Jonathan M Davis I've actually had a go at rebuilding druntime recently for dub. This is one of the things I HATE the state of. masm386 based upon what I read from the NG is a compiler written for 16bit and hence not runnable on 32bit Windows. You will find however minit.obj in the repo along with minit.asm. You shouldn't need to recompile minit.asm.
Re: [dub] specify dependency configuration
On 19/01/2015 1:59 p.m., cal wrote:
Given myapp and a dependency, specified by dub.json's:
myapp: dub.json
{
...
dependencies: {
dependency_a: =0.6.0
}
...
}
dependency_a: dub.json
{
...
configurations: [
{
name: config_a,
targetType: library,
...
},
{
name: config_b,
targetType: executable,
...
},
...
}
How do I specify (in myapp: dub.json) that I want the config_a
configuration of dependency_a?
I just want to verify, you are using configurations only to determine if
its being built a certain way?
And not lets say as a subpackage?
Ignoring that, there is something called subConfigurations section.
Example from: http://code.dlang.org/package-format
{
...
name: somepackage
configurations: [
{
name: metro-app,
targetType: executable,
platforms: [windows],
versions: [MetroApp],
libs: [d3d11]
},
{
name: desktop-app,
targetType: executable,
platforms: [windows],
versions: [DesktopApp],
libs: [d3d9]
},
{
name: glut-app,
targetType: executable,
versions: [GlutApp]
}
]
}
{
...
dependencies: {
somepackage: =1.0.0
},
subConfigurations: {
somepackage: glut-app
}
}
Re: [dub] specify dependency configuration
On Monday, 19 January 2015 at 02:10:41 UTC, Rikki Cattermole wrote: I just want to verify, you are using configurations only to determine if its being built a certain way? And not lets say as a subpackage? Some dependency (that I don't control) might define for example two configurations, a sourceLibrary type and a library type (my own app does not define it's own configurations). I'm just wondering if there is a way to tell dub i'm only interested in using that dependency as a sourceLibrary for example.
Re: [dub] specify dependency configuration
On Monday, 19 January 2015 at 02:10:41 UTC, Rikki Cattermole
wrote:
subConfigurations: {
somepackage: glut-app
}
}
Ahh I guess this is it, thanks for that!
Re: simple assignment statement compiles but becomes a run time error
On Sunday, 18 January 2015 at 20:07:25 UTC, weaselcat wrote: On Sunday, 18 January 2015 at 19:51:02 UTC, WhatMeWorry wrote: On Sunday, 18 January 2015 at 19:42:33 UTC, WhatMeWorry wrote: I've got a OpenGL function returning a pointer // const GLubyte *version = glGetString(GL_VERSION); // C++ and openLG code // the following compiles with no errors or warnings char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); // ABENDS HERE! // documentation from std.string shows // pure @system inout(char)[] fromStringz(inout(char)* cString); // Seems pretty innocuous to me. Debugger returns: Unhandled exception at 0x76AC2F71 (KernelBase.dll) in WhatVersionOfOpenGL.exe Hi, try replacing the fromStringz with to!string from std.conv No cigar. char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); causes the same exception. Thanks for suggestion. Could (Can?) OpenGL be marking the string as read only? So we can print out value put not copy it?
druntime build failing because of masm386 problems
It's been a while since I did anything in Windows with D, and unfortunately, I need to again, and now I can't get druntime to build. I'm getting this lovely error: dmc -c src\rt\minit.asm masm386 -DM_I386=1 -D_WIN32 -Mx src\rt\minit.asm; Can't run 'masm386', check PATH Error: 'dmc' not found I know that I've seen this before, but I can't remember how to fix the problem. dmc is definitely on my PATH (I successfully built dmd prior to trying to build druntime), so the error seems to be wrong, for whatever good that does me. I don't see a masm386 with dmc, so I don't know where that comes from. Maybe that's part of the problem. Has anyone seen this problem and figured out how to get around it or fix it? - Jonathan M Davis
Re: druntime build failing because of masm386 problems
On Sunday, January 18, 2015 22:19:29 Jonathan M Davis via Digitalmars-d-learn wrote: On Sunday, January 18, 2015 23:21:43 jollie via Digitalmars-d-learn wrote: It's been some months since I had this problem pop up, but I just ran touch on the minit.obj file so make thought it was up to date and used it. That did the trick. Thanks. It looks like that has to be done after every time I run clean. That definitely sucks. Oh. It looks like this page has an even better suggestion: http://wiki.dlang.org/Building_DMD It suggests creating an empty masm386.bat file in a directory which is in your path (e.g. C:\dm\bin), and then it'll just work, since masm386 will do nothing. Still, I'm inclined to think that the makefile should be fixed so that it just uses the provided object file if can't be rebuilt on the system anyway. - Jonathan M Davis
[dub] specify dependency configuration
Given myapp and a dependency, specified by dub.json's:
myapp: dub.json
{
...
dependencies: {
dependency_a: =0.6.0
}
...
}
dependency_a: dub.json
{
...
configurations: [
{
name: config_a,
targetType: library,
...
},
{
name: config_b,
targetType: executable,
...
},
...
}
How do I specify (in myapp: dub.json) that I want the config_a
configuration of dependency_a?
Re: Getting a safe path for a temporary file
On Sunday, 18 January 2015 at 11:21:52 UTC, Marc Schütz wrote: It's not different, and if you're still doing the O_EXCL open afterwards, it's safe. I just assumed you were going to use the generated filename without a further check. This is then unsafe, no matter how the UUID is generated, and depending on the RNG that's been used, they can be quite predictable. Granted, the risk is low, but still... tmpfile is more predictable: it generates sequential file names.
Bug on Posix IPC_STAT. Wrong number of attachments
I create a shared memory by using shmget. And attach to it by
using shmat.
Finally, I use shmctl to get statistics to learn number of
attachments to
that shared memory. According to documentation
(linux.die.net/man/2/shmat), number of attachments should be 1.
Same codes, C returns 1, D returns 0. It took me 2 days until
realising this.
I put C and D codes, and makefile for quick testing.
Ubuntu 64-bit. Kernel: 3.13.0-44-generic
I checked the shmid_ds at both core.sys.posix.sys.shm and
/usr/include/bits/shm.h. They look similar. Although C
definition makes a difference based on 32 and 64 bits, D's
definition doesn't care about. Because I am on 64-bit kernel,
they should be same.
main.c
==
#include stdio.h
#include sys/types.h
#include sys/ipc.h
#include sys/shm.h
#include fcntl.h
void main(){
// allocate
int id = shmget( IPC_PRIVATE, 4096, IPC_CREAT | S_IRUSR |
S_IWUSR );
// if failed, leave
if( id == -1 ){
printf(shmget failed\n);
return;
}
// attach
void* ptr = shmat( id, 0, 0 );
// if failed, leave
if( ptr == (void*)-1 ){
printf(shmat failed\n);
shmctl( id, IPC_RMID, 0 );
return;
}
// stat
struct shmid_ds stat;
// get statistics
int res = shmctl( id, IPC_STAT, stat );
printf(STAT: %d\n, res);
// get number of attachments
printf(NATTCH: %d\n, (unsigned short)stat.shm_nattch);
// detach
shmdt( ptr );
// remove
shmctl( id, IPC_RMID, 0 );
}
main.d
===
import std.stdio;
private import core.sys.posix.sys.mman;
private import core.sys.posix.sys.shm;
private import core.sys.posix.unistd;
private import core.sys.posix.sys.stat;
private static import core.stdc.errno;
private static import core.stdc.time;
void main(){
// allocate
int id = shmget( IPC_PRIVATE, 4096, IPC_CREAT | S_IRUSR |
S_IWUSR );
// if failed, leave
if( id == -1 ){
writeln(shmget failed);
return;
}
// attach
void* ptr = shmat( id, null, 0 );
// if failed, leave
if( ptr == cast(void*)-1 ){
writeln(shmat failed);
shmctl( id, IPC_RMID, null );
return;
}
// stat
shmid_ds stat;
// get statistics
int res = shmctl( id, IPC_STAT, stat );
writeln(STAT: , res);
// get number of attachments
writeln(NATTCH: , stat.shm_nattch);
// detach
shmdt( ptr );
// remove
shmctl( id, IPC_RMID, null );
}
makefile
==
all:
dmd main.d -ofdprog
gcc main.c -o cprog
clear:
rm cprog
rm dprog
Re: Shared and GC
http://forum.dlang.org/thread/dnxgbumzenupviqym...@forum.dlang.org :-/
Re: Getting a safe path for a temporary file
On Saturday, 17 January 2015 at 17:16:41 UTC, Tobias Pankrath wrote: On Saturday, 17 January 2015 at 16:55:42 UTC, Marc Schütz wrote: On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc wrote: On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz wrote: Is it currently possible to get the path to a safe temporary file, i.e. one that is guaranteed to be freshly created and will not override another existing file? There's `std.file.tempDir`, which doesn't create a unique file. Then there's `std.stdio.tmpfile()`, which does, but it returns a `File` object, and its `name` property is `null`. Did I miss something? IMO this is very import functionality. One use case is passing these names as command line arguments to an external program that doesn't support stdin/stdout. I agree that it would be useful. This is what I used, although there may be a better option: http://dlang.org/phobos/std_uuid.html Nice idea, but it still allows for intentional collision attacks :-( The only really safe solution is one that generates (probably) unique names, then opens the file with O_EXCL|O_CREAT (or whatever other means the OS provides), and if it fails, retries with a different name. `std.stdio.tmpfile()` already does that (it uses `tmpfile(3)` under the hood), but doesn't allow access to the name. You're looking for core.sys.posix.stdlib : mkstemp. I think that should be used by std.stdio.File as well, care to create an enhancement request in bugzilla? But it's POSIX only :-(
Re: Getting a safe path for a temporary file
On Sunday, 18 January 2015 at 00:51:37 UTC, Laeeth Isharc wrote: I don't follow why a collision attack is applicable in this case. Your stage 1 of generating unique names: how is this different from using a random uuid? It's not different, and if you're still doing the O_EXCL open afterwards, it's safe. I just assumed you were going to use the generated filename without a further check. This is then unsafe, no matter how the UUID is generated, and depending on the RNG that's been used, they can be quite predictable. Granted, the risk is low, but still...
Re: Getting a safe path for a temporary file
On Saturday, 17 January 2015 at 21:32:18 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: But I think that what we need is a function in std.stdio (e.g tempFile insteaf of tmpfile) which returns an open File with a randomly generated name and gives you access to its name rather than using C's tmpfile, which does not give you access to the name and deletes the file on you when it's closed. Right - I overlooked this fact. The bad thing is that you might even be forced to close the file before another program can open it, if either of the programs wants to open it exclusively (probably most likely to happen on Windows).
import conflicts
Hi all, I'm trying to write my first actual app that'll go into
production. My file starts with this set of imports:
import std.stdio, std.string, std.json, std.process, std.conv,
std.file,
core.sys.posix.syslog, tinyredis.redis;
import core.sys.posix.unistd: chdir;
import core.sys.posix.sys.stat: mkdir, umask;
import core.thread: Thread, dur;
import core.stdc.stdlib: exit;
At some point in code I have added:
if (exists(lastUpdate.7z)) {
remove(lastUpdate.7z);
}
Now I get compile errors:
autoupdate.d(183): Error: std.file.remove at
/usr/include/dmd/phobos/std/file.d(429) conflicts with
core.stdc.stdio.remove at
/usr/include/dmd/druntime/import/core/stdc/stdio.d(548)
I'm not importing core.stdc.stdio, so why is it conflicting?
Thanks for your time,
-Andy
Re: import conflicts
On Sunday, 18 January 2015 at 19:20:34 UTC, Vlad Levenfeld wrote: I get this all the time with std.array.array (I use my own array implementations, but phobos' array seems to secretly creep in everywhere). I think its got to do with that private import visibility bug (https://issues.dlang.org/show_bug.cgi?id=314 or https://issues.dlang.org/show_bug.cgi?id=13096 I think) which, by the looks of it, should be getting a fix... soon? ish? Ah, if its just a compiler bug I'm ok with that. I was worried there was something about the language I didnt understand. I got it to compile ok using: import std.file: remove, exists, rename; Thanks, -Andy
Re: import conflicts
I get this all the time with std.array.array (I use my own array implementations, but phobos' array seems to secretly creep in everywhere). I think its got to do with that private import visibility bug (https://issues.dlang.org/show_bug.cgi?id=314 or https://issues.dlang.org/show_bug.cgi?id=13096 I think) which, by the looks of it, should be getting a fix... soon? ish?
simple assignment statement compiles but becomes a run time error
I've got a OpenGL function returning a pointer // const GLubyte *version = glGetString(GL_VERSION); // C++ and openLG code // the following compiles with no errors or warnings char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); // ABENDS HERE! // documentation from std.string shows // pure @system inout(char)[] fromStringz(inout(char)* cString); // Seems pretty innocuous to me. Debugger returns: Unhandled exception at 0x76AC2F71 (KernelBase.dll) in WhatVersionOfOpenGL.exe
Re: simple assignment statement compiles but becomes a run time error
On Sunday, 18 January 2015 at 19:42:33 UTC, WhatMeWorry wrote: I've got a OpenGL function returning a pointer // const GLubyte *version = glGetString(GL_VERSION); // C++ and openLG code // the following compiles with no errors or warnings char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); // ABENDS HERE! // documentation from std.string shows // pure @system inout(char)[] fromStringz(inout(char)* cString); // Seems pretty innocuous to me. Debugger returns: Unhandled exception at 0x76AC2F71 (KernelBase.dll) in WhatVersionOfOpenGL.exe // Got it to work with writeln(fromStringz(glGetString(GL_VERSION))); But shouldn't I have been able to grabbed a copy of the string and put it in the openglVersion fixed size char array? Maybe string, or dynamic array?
Re: Bug on Posix IPC_STAT. Wrong number of attachments
On Sunday, 18 January 2015 at 16:06:39 UTC, tcak wrote:
I create a shared memory by using shmget. And attach to it by
using shmat.
Finally, I use shmctl to get statistics to learn number of
attachments to
that shared memory. According to documentation
(linux.die.net/man/2/shmat), number of attachments should be 1.
Same codes, C returns 1, D returns 0. It took me 2 days until
realising this.
I put C and D codes, and makefile for quick testing.
Ubuntu 64-bit. Kernel: 3.13.0-44-generic
I checked the shmid_ds at both core.sys.posix.sys.shm and
/usr/include/bits/shm.h. They look similar. Although C
definition makes a difference based on 32 and 64 bits, D's
definition doesn't care about. Because I am on 64-bit kernel,
they should be same.
main.c
==
#include stdio.h
#include sys/types.h
#include sys/ipc.h
#include sys/shm.h
#include fcntl.h
void main(){
// allocate
int id = shmget( IPC_PRIVATE, 4096, IPC_CREAT | S_IRUSR |
S_IWUSR );
// if failed, leave
if( id == -1 ){
printf(shmget failed\n);
return;
}
// attach
void* ptr = shmat( id, 0, 0 );
// if failed, leave
if( ptr == (void*)-1 ){
printf(shmat failed\n);
shmctl( id, IPC_RMID, 0 );
return;
}
// stat
struct shmid_ds stat;
// get statistics
int res = shmctl( id, IPC_STAT, stat );
printf(STAT: %d\n, res);
// get number of attachments
printf(NATTCH: %d\n, (unsigned short)stat.shm_nattch);
// detach
shmdt( ptr );
// remove
shmctl( id, IPC_RMID, 0 );
}
main.d
===
import std.stdio;
private import core.sys.posix.sys.mman;
private import core.sys.posix.sys.shm;
private import core.sys.posix.unistd;
private import core.sys.posix.sys.stat;
private static import core.stdc.errno;
private static import core.stdc.time;
void main(){
// allocate
int id = shmget( IPC_PRIVATE, 4096, IPC_CREAT | S_IRUSR |
S_IWUSR );
// if failed, leave
if( id == -1 ){
writeln(shmget failed);
return;
}
// attach
void* ptr = shmat( id, null, 0 );
// if failed, leave
if( ptr == cast(void*)-1 ){
writeln(shmat failed);
shmctl( id, IPC_RMID, null );
return;
}
// stat
shmid_ds stat;
// get statistics
int res = shmctl( id, IPC_STAT, stat );
writeln(STAT: , res);
// get number of attachments
writeln(NATTCH: , stat.shm_nattch);
// detach
shmdt( ptr );
// remove
shmctl( id, IPC_RMID, null );
}
makefile
==
all:
dmd main.d -ofdprog
gcc main.c -o cprog
clear:
rm cprog
rm dprog
Here is what I did to solve the problem. In D code, I defined my
own shmid_ds struct (Structure is taken from
/usr/include/bits/shm.h)
// from /usr/include/bits/shm.h
/* Type to count number of attaches. */
alias shmatt_t = c_ulong;
/* Data structure describing a shared memory segment. */
version( X86_64 ){
struct my_shmid_ds{
ipc_perm shm_perm; /* operation permission struct */
size_t shm_segsz; /* size of segment in bytes */
time_t shm_atime; /* time of last shmat() */
time_t shm_dtime; /* time of last shmdt() */
time_t shm_ctime; /* time of last change by
shmctl() */
pid_t shm_cpid; /* pid of creator */
pid_t shm_lpid; /* pid of last shmop */
shmatt_t shm_nattch;/* number of current attaches */
c_ulong __glibc_reserved4;
c_ulong __glibc_reserved5;
};
}
else{
struct my_shmid_ds{
ipc_perm shm_perm; /* operation permission struct */
size_t shm_segsz; /* size of segment in bytes */
time_t shm_atime; /* time of last shmat() */
c_ulong __glibc_reserved1;
time_t shm_dtime; /* time of last shmdt() */
c_ulong __glibc_reserved2;
time_t shm_ctime; /* time of last change by
shmctl() */
c_ulong __glibc_reserved3;
pid_t shm_cpid; /* pid of creator */
pid_t shm_lpid; /* pid of last shmop */
shmatt_t shm_nattch;/* number of current attaches */
c_ulong __glibc_reserved4;
c_ulong __glibc_reserved5;
};
}
Then, I changed the type of stat variable:
my_shmid_ds stat;
Finally, need to do a casting (Doing this came to me so stupid
Re: How to avoid invalid memory operation errors (and more) in DLLs?
On Wednesday, 14 January 2015 at 13:51:08 UTC, John Colvin wrote: Would it be possible for you to file this as a bug at issues.dlang.org ? While trying to file this issue, I was simplifing my test case and in the process I was able to make it not crash, but now core.thread.Thread.getThis().name() is always empty, even if i __gshared everything so i guess this is one of those non trackable, non fixable issues that default TLS introduced. This is so confusing and frustrating right now, I can't report this as a bug because I was able to fix the crash, but I wasn't able to obtain the desired results in my program, maybe a programming or implementation error? I'm taking a break right now with D, I've been stuck for too long with these threading/tls issues. I need vacations.
Re: Bug on Posix IPC_STAT. Wrong number of attachments
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote: After these, it works perfectly. I hope this can be fixed in next version. Please file a bug at https://issues.dlang.org/. And since you seem to know how to fix it, maybe you can make a pull request via GitHub, too?
Re: simple assignment statement compiles but becomes a run time error
On Sunday, 18 January 2015 at 19:51:02 UTC, WhatMeWorry wrote: On Sunday, 18 January 2015 at 19:42:33 UTC, WhatMeWorry wrote: I've got a OpenGL function returning a pointer // const GLubyte *version = glGetString(GL_VERSION); // C++ and openLG code // the following compiles with no errors or warnings char openglVersion[100] = fromStringz(glGetString(GL_VERSION)); // ABENDS HERE! // documentation from std.string shows // pure @system inout(char)[] fromStringz(inout(char)* cString); // Seems pretty innocuous to me. Debugger returns: Unhandled exception at 0x76AC2F71 (KernelBase.dll) in WhatVersionOfOpenGL.exe Hi, try replacing the fromStringz with to!string from std.conv
Colour operations using CyberShadow's graphics library
Hi, I'm new to D and having a go at writing some image processing stuff using Vladimir's ae.graphics library. To filter (i.e. perform correlations/convolutions) on a view with colour type C, I'd like to perform intermediate calculations using a colour with the same number of channels as C, but all of type double, and then to convert back to something of type C at the end. e.g. for a horizontal blur I'd like to keep a running total per channel, packaged in an all-doubles colour type, and then write (total / kernel width) for each channel back into a value of type C. How do I perform the necessary type magic here? Thanks
