View mode: basic / threaded / horizontal-split · Log in · Help
October 15, 2012
Re: D seems interesting, but...
On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote:
> On 10/15/2012 06:22 AM, Iain Buclaw wrote:
> > On 15 October 2012 08:23, Gerry Weaver<gerryw@compvia.com>
> wrote:
>
> >> Disassembly of section .text:
> >>
> >> 00000000<.text>:
> >>     0:   b8 10 00 00 00          mov    $0x10,%eax
> >>     5:   b9 00 00 00 00          mov    $0x0,%ecx
> >>     a:   8b 11                   mov    (%ecx),%edx
> >>     c:   89 10                   mov    %edx,(%eax)
> >>     e:   89 01                   mov    %eax,(%ecx)
> >>    10:   c3                      ret
> >>
> >>
> >> Thanks,
> >> -G
> >>
> >
> >
> > That looks to me as if hello.d is an empty file.
>
> That is the most plausible reason so far: The OP has an empty 
> file in the current directory but the hello.d that is being 
> edited in Emacs is elsewhere. :)
>
> Ali

Hi,

I have been looking into this. I'm afraid it isn't that simple. I 
just created the file with vi in the same directory I was trying 
to compile it in. I can cat it etc., so I know the text is there. 
I have even reproduced the issue on a different partition etc.. 
I'm starting to think that some other package that is installed 
on this particular system may be the source of the problem. I 
can't reproduce the issue on another install of the same OS, 
version, etc.. I went ahead and installed the .deb package on the 
new system and it still works.

Thanks,
-G
October 15, 2012
Re: D seems interesting, but...
On 10/15/12 1:37 PM, foobar wrote:
> On Monday, 15 October 2012 at 15:22:38 UTC, Andrei Alexandrescu wrote:
> <snip>
>>>
>>> Yes, this is a nice thing Java, .NET and Python have.
>>
>> Wonder if a simple convention would suffice, e.g. every module that
>> wanna defines a moduleMain(string[] args) and then you have one module
>> main.d that has:
>>
>> void main(string[] args) { import wuddever; moduleMain(args); }
>>
>>
>> Andrei
>
> Great idea! But why add another (redundant) level of indirection?
> It should go in the C main in druntime together with a mechanism to call
> the correct D main, by e.g. reading the module name from the command line.

Well there's a tension here: good language design generally aims at 
providing few general features applicable to many use cases. Encoding 
particular use cases in the language is warranted by either 
disproportionate frequency in use or disproportionate difficulty in 
implementing them within the language. I don't think this particular 
feature scores very highly in either category.


Andrei
October 15, 2012
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote:
> On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote:
[...]
> >That is the most plausible reason so far: The OP has an empty file in
> >the current directory but the hello.d that is being edited in Emacs
> >is elsewhere. :)
> >
> >Ali
> 
> Hi,
> 
> I have been looking into this. I'm afraid it isn't that simple. I
> just created the file with vi in the same directory I was trying to
> compile it in. I can cat it etc., so I know the text is there. I
> have even reproduced the issue on a different partition etc.. I'm
> starting to think that some other package that is installed on this
> particular system may be the source of the problem. I can't
> reproduce the issue on another install of the same OS, version,
> etc.. I went ahead and installed the .deb package on the new system
> and it still works.
[...]

Yeah, it seems to be a very system-specific problem. I'd like to get to
bottom of it if I could, as it piques my curiosity (plus it would be
nice to prevent somebody else from running into the same problem in the
future), but then I don't really want to waste your time hunting down an
obscure problem if you already have a working dmd by some other means.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
October 15, 2012
Re: D seems interesting, but...
On Monday, 15 October 2012 at 17:53:15 UTC, Andrei Alexandrescu 
wrote:
> On 10/15/12 1:37 PM, foobar wrote:
>> On Monday, 15 October 2012 at 15:22:38 UTC, Andrei 
>> Alexandrescu wrote:
>> <snip>
>>>>
>>>> Yes, this is a nice thing Java, .NET and Python have.
>>>
>>> Wonder if a simple convention would suffice, e.g. every 
>>> module that
>>> wanna defines a moduleMain(string[] args) and then you have 
>>> one module
>>> main.d that has:
>>>
>>> void main(string[] args) { import wuddever; moduleMain(args); 
>>> }
>>>
>>>
>>> Andrei
>>
>> Great idea! But why add another (redundant) level of 
>> indirection?
>> It should go in the C main in druntime together with a 
>> mechanism to call
>> the correct D main, by e.g. reading the module name from the 
>> command line.
>
> Well there's a tension here: good language design generally 
> aims at providing few general features applicable to many use 
> cases. Encoding particular use cases in the language is 
> warranted by either disproportionate frequency in use or 
> disproportionate difficulty in implementing them within the 
> language. I don't think this particular feature scores very 
> highly in either category.
>
>
> Andrei

Well, it isn't so much in the language per se as it's (mostly?) 
in druntime.
We _already_ have code in druntime that calls the user supplied 
main function. All I'm suggesting is a very minor enhancement to 
that mechanism which does add useful convenience.
Seems to me the usefulness of this greatly outweighs the 
implementation cost.
October 15, 2012
Re: D seems interesting, but...
On Monday, 15 October 2012 at 18:03:10 UTC, H. S. Teoh wrote:
> On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote:
>> On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote:
> [...]
>> >That is the most plausible reason so far: The OP has an empty 
>> >file in
>> >the current directory but the hello.d that is being edited in 
>> >Emacs
>> >is elsewhere. :)
>> >
>> >Ali
>> 
>> Hi,
>> 
>> I have been looking into this. I'm afraid it isn't that 
>> simple. I
>> just created the file with vi in the same directory I was 
>> trying to
>> compile it in. I can cat it etc., so I know the text is there. 
>> I
>> have even reproduced the issue on a different partition etc.. 
>> I'm
>> starting to think that some other package that is installed on 
>> this
>> particular system may be the source of the problem. I can't
>> reproduce the issue on another install of the same OS, version,
>> etc.. I went ahead and installed the .deb package on the new 
>> system
>> and it still works.
> [...]
>
> Yeah, it seems to be a very system-specific problem. I'd like 
> to get to
> bottom of it if I could, as it piques my curiosity (plus it 
> would be
> nice to prevent somebody else from running into the same 
> problem in the
> future), but then I don't really want to waste your time 
> hunting down an
> obscure problem if you already have a working dmd by some other 
> means.
>
>
> T

Hi,


It just occurred to me that I've seen this type of file issue 
before. If memory serves, it was related to the attempt to load a 
64bit lib on a 32bit system. It was an odd problem, because it 
didn't fail in the way one would expect. The process in that case 
was reading garbage from memory. I don't get how it could be 
reading nothing though. Anyway, I'm going to look into this 
possibility. I found some notes that I made during that time and 
it does have a similar feel to it. I'll let y'all know what I 
find.

Thanks,
-G
October 15, 2012
Re: D seems interesting, but...
On Monday, 15 October 2012 at 18:46:22 UTC, Gerry Weaver wrote:
> On Monday, 15 October 2012 at 18:03:10 UTC, H. S. Teoh wrote:
>> On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote:
>>> On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli 
>>> wrote:
>> [...]
>>> >That is the most plausible reason so far: The OP has an 
>>> >empty file in
>>> >the current directory but the hello.d that is being edited 
>>> >in Emacs
>>> >is elsewhere. :)
>>> >
>>> >Ali
>>> 
>>> Hi,
>>> 
>>> I have been looking into this. I'm afraid it isn't that 
>>> simple. I
>>> just created the file with vi in the same directory I was 
>>> trying to
>>> compile it in. I can cat it etc., so I know the text is 
>>> there. I
>>> have even reproduced the issue on a different partition etc.. 
>>> I'm
>>> starting to think that some other package that is installed 
>>> on this
>>> particular system may be the source of the problem. I can't
>>> reproduce the issue on another install of the same OS, 
>>> version,
>>> etc.. I went ahead and installed the .deb package on the new 
>>> system
>>> and it still works.
>> [...]
>>
>> Yeah, it seems to be a very system-specific problem. I'd like 
>> to get to
>> bottom of it if I could, as it piques my curiosity (plus it 
>> would be
>> nice to prevent somebody else from running into the same 
>> problem in the
>> future), but then I don't really want to waste your time 
>> hunting down an
>> obscure problem if you already have a working dmd by some 
>> other means.
>>
>>
>> T
>
> Hi,
>
>
> It just occurred to me that I've seen this type of file issue 
> before. If memory serves, it was related to the attempt to load 
> a 64bit lib on a 32bit system. It was an odd problem, because 
> it didn't fail in the way one would expect. The process in that 
> case was reading garbage from memory. I don't get how it could 
> be reading nothing though. Anyway, I'm going to look into this 
> possibility. I found some notes that I made during that time 
> and it does have a similar feel to it. I'll let y'all know what 
> I find.
>
> Thanks,
> -G

Hmm.. It doesn't seem likely that these problems are related. The 
issue I remembered involved a series of program errors that 
started with the improper handling of a dlopen. It is almost 
impossible that dmd could be reproducing this situation.

Thanks,
-G
October 15, 2012
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 08:46:21PM +0200, Gerry Weaver wrote:
[...]
> It just occurred to me that I've seen this type of file issue
> before. If memory serves, it was related to the attempt to load a
> 64bit lib on a 32bit system. It was an odd problem, because it
> didn't fail in the way one would expect. The process in that case
> was reading garbage from memory. I don't get how it could be reading
> nothing though. Anyway, I'm going to look into this possibility. I
> found some notes that I made during that time and it does have a
> similar feel to it. I'll let y'all know what I find.
[...]

Now, that does sound like it could be the source of the problem. If dmd
was reading garbage from the file, if there just happens to be, say, a
binary 0 at the beginning (or whatever it is that causes dmd to think it
has reached EOF), then it would just stop and produce an empty object
file. So the linker will fail to find the symbols that dmd emits when it
encounters main().


T

-- 
Не дорог подарок, дорога любовь.
October 15, 2012
Re: D seems interesting, but...
Andrei Alexandrescu:

> Well there's a tension here: good language design generally 
> aims at providing few general features applicable to many use 
> cases. Encoding particular use cases in the language is 
> warranted by either disproportionate frequency in use or 
> disproportionate difficulty in implementing them within the 
> language. I don't think this particular feature scores very 
> highly in either category.

It's a feature that I use about in every Python module/package 
I've written, and it's about as equally used in code you see in 
Python repositories. So it's a common need in Python. I'm asking 
for it for more than three years or so.

And regarding the implementation my "hack" means having a single 
compile-time constant (plus a switch to be used when you want 
partial compilation?). Better designs are possible, but it's a 
matter of how much you want to work for it.

Bye,
bearophile
October 15, 2012
Re: D seems interesting, but...
On Monday, 15 October 2012 at 19:38:24 UTC, H. S. Teoh wrote:
> On Mon, Oct 15, 2012 at 08:46:21PM +0200, Gerry Weaver wrote:
> [...]
>> It just occurred to me that I've seen this type of file issue
>> before. If memory serves, it was related to the attempt to 
>> load a
>> 64bit lib on a 32bit system. It was an odd problem, because it
>> didn't fail in the way one would expect. The process in that 
>> case
>> was reading garbage from memory. I don't get how it could be 
>> reading
>> nothing though. Anyway, I'm going to look into this 
>> possibility. I
>> found some notes that I made during that time and it does have 
>> a
>> similar feel to it. I'll let y'all know what I find.
> [...]
>
> Now, that does sound like it could be the source of the 
> problem. If dmd
> was reading garbage from the file, if there just happens to be, 
> say, a
> binary 0 at the beginning (or whatever it is that causes dmd to 
> think it
> has reached EOF), then it would just stop and produce an empty 
> object
> file. So the linker will fail to find the symbols that dmd 
> emits when it
> encounters main().
>
>
> T

Hi,

When running dmd, none of the read (and friends) syscalls happen 
as far as the kernel is concerned. This would lend some 
credibility to the lib theory. However, it's quite odd that 
results are the same for each time dmd is executed. I would 
expect a random result or even a segfault/abort on different runs.

Thanks,
-G
October 15, 2012
Re: D seems interesting, but...
On Monday, 15 October 2012 at 20:19:22 UTC, Gerry Weaver wrote:
> On Monday, 15 October 2012 at 19:38:24 UTC, H. S. Teoh wrote:
>> On Mon, Oct 15, 2012 at 08:46:21PM +0200, Gerry Weaver wrote:
>> [...]
>>> It just occurred to me that I've seen this type of file issue
>>> before. If memory serves, it was related to the attempt to 
>>> load a
>>> 64bit lib on a 32bit system. It was an odd problem, because it
>>> didn't fail in the way one would expect. The process in that 
>>> case
>>> was reading garbage from memory. I don't get how it could be 
>>> reading
>>> nothing though. Anyway, I'm going to look into this 
>>> possibility. I
>>> found some notes that I made during that time and it does 
>>> have a
>>> similar feel to it. I'll let y'all know what I find.
>> [...]
>>
>> Now, that does sound like it could be the source of the 
>> problem. If dmd
>> was reading garbage from the file, if there just happens to 
>> be, say, a
>> binary 0 at the beginning (or whatever it is that causes dmd 
>> to think it
>> has reached EOF), then it would just stop and produce an empty 
>> object
>> file. So the linker will fail to find the symbols that dmd 
>> emits when it
>> encounters main().
>>
>>
>> T
>
> Hi,
>
> When running dmd, none of the read (and friends) syscalls 
> happen as far as the kernel is concerned. This would lend some 
> credibility to the lib theory. However, it's quite odd that 
> results are the same for each time dmd is executed. I would 
> expect a random result or even a segfault/abort on different 
> runs.
>
> Thanks,
> -G

Hi,

I think I have satisfied myself that this is probably a fluke. We 
have captured enough in this thread that there will be a good 
starting point should the issue ever come up again. It may sound 
odd, but I'm actually glad it happened. It helped me realize an 
issue with a system that would probably have manifested itself in 
some other frustrating and embarrassing way later on ;-)

Thanks everyone,
-G
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home