Danny Arends Wrote:
> OK
> Thanks very much, made myself an account there and
> re-posted the issue.
Not OK. You forgot testcase.
OK
Thanks very much, made myself an account there and
re-posted the issue.
Though it still feels like I'm doing something wrong
On 10.08.2011 11:53, Danny Arends wrote:
(Also posted this in bugs, but I think it needs to be here)
The bugs newsgroup should be read-only.
Post bugs here: http://d.puremagic.com/issues/
Events in bugzilla gets posted to the bugs newsgroup
On Tue, 04 May 2010 15:22:52 -0500, Ellery Newcomer wrote:
> On 05/04/2010 11:32 AM, Lars T. Kyllingstad wrote:
>>
>> Shouldn't 'term' and 'signaled' switch names? It looks to me like
>> 'term' will be nonzero if the process receives any signal, while
>> 'signaled' will be only be true if it is a
On 05/04/2010 11:32 AM, Lars T. Kyllingstad wrote:
Shouldn't 'term' and 'signaled' switch names? It looks to me like 'term'
will be nonzero if the process receives any signal, while 'signaled' will
be only be true if it is a terminating signal, and not if it is a stop
signal.
signaled corres
On Tue, 04 May 2010 08:55:36 -0500, Ellery Newcomer wrote:
> On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
>> std.process is currently undergoing a complete redesign, so the current
>> situation should improve in the near future. :)
>>
>> -Lars
>
> That's good to hear. And since you're an exp
On 05/04/2010 09:51 AM, Graham Fawcett wrote:
Thanks for posting this. Just curious -- why did you choose to model PID
as a tuple instead of a struct? I'm not clear on what the tradeoffs are.
Best,
Graham
according to core.sys.posix.sys.wait, this is only valid for linux, grrr.
I don't think
On Tue, 04 May 2010 08:55:36 -0500, Ellery Newcomer wrote:
> On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
>
>
>> In your case the segfault would cause SIGSEGV (signal 11) to be sent to
>> the process, and the the above test would print "Process terminated by
>> signal 11".
>>
>> See "man w
On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
In your case the segfault would cause SIGSEGV (signal 11) to be sent to
the process, and the the above test would print "Process terminated by
signal 11".
See "man wait" for more info.
That's where I got my info (or rather /usr/include/bits/
On Mon, 03 May 2010 20:32:03 -0500, Ellery Newcomer wrote:
> On 05/03/2010 06:08 PM, Graham Fawcett wrote:
>>
>> [...]
>>
>> And "(139& 0xff00)>>> 8" evaluates to 0. I am not sure why it's
>> not simply returning the raw status-code, though, and only on Posix
>> systems -- it must be a Posi
On Tue, 04 May 2010 09:25:30 +1200, Bernard Helyer wrote:
> On 04/05/10 08:57, Lars T. Kyllingstad wrote:
>> On Mon, 03 May 2010 15:54:28 -0500, Ellery Newcomer wrote:
>>
>>> Hello.
>>>
>>> I'm trying to invoke a command inside d, and it returns a success code
>>> when the command in question segf
On 05/03/2010 06:08 PM, Graham Fawcett wrote:
What OS are you running on? In D2, this the definition of system():
int system(string command)
{
if (!command) return std.c.process.system (null);
const commandz = toStringz (command);
invariant status = std.c.process.
On Mon, 03 May 2010 17:34:51 -0500, Ellery Newcomer wrote:
> On 05/03/2010 04:49 PM, Steven Schveighoffer wrote:
>>
>> Could it be perhaps that it can't possibly get at that status?
>> Remember, system runs /bin/sh -c, so all you can get as status is the
>> return code of /bin/sh (which didn't seg
On 05/03/2010 04:49 PM, Steven Schveighoffer wrote:
Could it be perhaps that it can't possibly get at that status? Remember,
system runs /bin/sh -c, so all you can get as status is the return code
of /bin/sh (which didn't segfault).
-Steve
All I know is the analogous code in python returns th
On 04/05/10 09:49, Steven Schveighoffer wrote:
On Mon, 03 May 2010 17:25:30 -0400, Bernard Helyer
wrote:
I believe his problem is that the return code of the caller indicates
success.
Could it be perhaps that it can't possibly get at that status? Remember,
system runs /bin/sh -c, so all you
On Mon, 03 May 2010 17:25:30 -0400, Bernard Helyer
wrote:
On 04/05/10 08:57, Lars T. Kyllingstad wrote:
On Mon, 03 May 2010 15:54:28 -0500, Ellery Newcomer wrote:
Hello.
I'm trying to invoke a command inside d, and it returns a success code
when the command in question segfaults.
any ide
On 04/05/10 08:57, Lars T. Kyllingstad wrote:
On Mon, 03 May 2010 15:54:28 -0500, Ellery Newcomer wrote:
Hello.
I'm trying to invoke a command inside d, and it returns a success code
when the command in question segfaults.
any ideas?
// the caller
import std.process;
int main(){
auto
On Mon, 03 May 2010 15:54:28 -0500, Ellery Newcomer wrote:
> Hello.
>
> I'm trying to invoke a command inside d, and it returns a success code
> when the command in question segfaults.
>
> any ideas?
>
> // the caller
> import std.process;
>
> int main(){
> auto r = system("./test");
>
On 24/02/10 12:53, Ellery Newcomer wrote:
Hey! You're right!
import tango.io.Stdout;
void main(){
Object obj = null;
int[] a;
a ~= 1;
Stdout(obj.toString()).newline;
}
gives me
Die: DW_TAG_type_unit (abbrev 7, offset 0x6f)
parent at offset: 0xb
has children: FALSE
attributes:
DW_AT_byte_size (
On 02/23/2010 03:22 PM, Bernard Helyer wrote:
On 24/02/10 03:45, Ellery Newcomer wrote:
I'm thinking it's an issue with DMD. I can get backtraces with simple
programs.
If you use a dynamic array in there somewhere, the chances of it not
working go up, I'm afraid. This doesn't leave many progr
On 24/02/10 03:45, Ellery Newcomer wrote:
I'm thinking it's an issue with DMD. I can get backtraces with simple
programs.
If you use a dynamic array in there somewhere, the chances of it not
working go up, I'm afraid. This doesn't leave many programs that *work*.
On 23/02/10 17:33, Ellery Newcomer wrote:
Oh. good idea.
mua ha ha. ldc dies on compile:
ldc:
/home/kamm/eigenes/projekte/ldc/llvm-26/lib/VMCore/Instructions.cpp:921:
void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() ==
cast(getOperand(1)->getType())->getElementType() && "Pt
On 02/23/2010 10:34 AM, Robert Clipsham wrote:
I'm no expert, but that looks like a dmd bug, can you reproduce with
ldc? The actual segfault is probably to do with your code, but if gdb
gives that then there's a problem with the debug info that dmd is
writing. The only easy way to debug this if
On 23/02/10 02:14, Ellery Newcomer wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
parent at offset: 0xb
has children: F
On 02/23/2010 06:28 AM, Steven Schveighoffer wrote:
On Mon, 22 Feb 2010 21:14:08 -0500, Ellery Newcomer
wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG
On Mon, 22 Feb 2010 21:14:08 -0500, Ellery Newcomer
wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
parent at off
Ellery Newcomer:
> Is there any decent way to figure out where segfaults are coming from?
> e.g. 200k lines of bad code converted from java
To perform that translation you have to do first adapt the original Java code
to D as much as possible keeping it woeking, then add unit tests to each method
On 23/02/10 15:14, Ellery Newcomer wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
parent at offset: 0xb
has children: F
On 02/22/2010 08:41 PM, Jesse Phillips wrote:
Ellery Newcomer wrote:
Is there any decent way to figure out where segfaults are coming from?
e.g. 200k lines of bad code converted from java
I tried gdb, and it didn't seem to work too well.
Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
pare
Ellery Newcomer wrote:
> Is there any decent way to figure out where segfaults are coming from?
>
> e.g. 200k lines of bad code converted from java
>
> I tried gdb, and it didn't seem to work too well.
>
> Die: DW_TAG_type_unit (abbrev 3, offset 0x6d)
>parent at offset: 0xb
>has children:
30 matches
Mail list logo
