October 15, 2012
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
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
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
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
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
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
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
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
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
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