October 15, 2012
On 10/15/12 4:12 PM, bearophile wrote:
> 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.

I don't think that compares apples to apples, as the entire feature combination present into either language must be taken into account.

> 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.

I think for someone coming from Python, something akin to

if __name__ == "__main__":
    main()

makes good sense. In my opinion that's not a design we should copy.


Andrei
October 15, 2012
On Monday, 15 October 2012 at 20:45:39 UTC, Gerry Weaver wrote:
> 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

Hi,

Sorry, I neglected to mention something. I did a test with a zero length file and compared the output to the problem case. The output was, in fact, identical. Would it be difficult to do a simple test for zero length files and output a message like "error: zero length/empty file <filename>"? The output in this case is fairly misleading.

Thanks,
-G

October 15, 2012
On 15 October 2012 23:21, Gerry Weaver <gerryw@compvia.com> wrote:
> On Monday, 15 October 2012 at 20:45:39 UTC, Gerry Weaver wrote:
>>
>> 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
>
>
> Hi,
>
> Sorry, I neglected to mention something. I did a test with a zero length file and compared the output to the problem case. The output was, in fact, identical. Would it be difficult to do a simple test for zero length files and output a message like "error: zero length/empty file <filename>"? The output in this case is fairly misleading.
>
> Thanks,
> -G
>

It would be less misleading if we got rid of _tlsstart and _tlsend. This would slim the error message down to...

---
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function `_D2rt6dmain24mainUiPPaZi7runMainMFZv': src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10): undefined reference to `_Dmain'
---

Which is less cryptic, and everyone can spot a "undefined reference to `_Dmain'" more easily.

However _tls is engraved in the current design of TLS.  On the move to shared libraries, I would hope that these be removed and replaced.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
October 15, 2012
Andrei Alexandrescu:

> I don't think that compares apples to apples, as the entire feature combination present into either language must be taken into account.

I agree that features must take in account the specific ecology of the other features of a language. And I agree the problem I am discussing about refers to the idea of "main module" that is currently ill defined in D (but I think it should be defined).

But the point is, I am desiring to solve this problem since years in D, so far I have written tons of lines of D1/D2 code, and I have not found a good solution.


> I think for someone coming from Python, something akin to
>
> if __name__ == "__main__":
>     main()
>
> makes good sense. In my opinion that's not a design we should copy.

I have suggested that solution just because I know it, and because it's probably easy to implement (once the idea of main module is defined). But I agree there are surely better designs to solve this problem. But some solution is desired, that Python-style solution is better than the current D situation :-) Currently I usually solve that problem wrapping the main in "static if (modulename_main)" and I compile with that version.

Bye,
bearophile
October 15, 2012
On Mon, 15 Oct 2012 06:24:57 -0500, Paulo Pinto <pjmlp@progtools.org> wrote:

> On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
>> Jacob Carlborg:
>>
>>> How should DMD detect if you're building a (dynamic) library? Sure it can see that you're not using -lib or -shared but what about separate complication?
>>
>> What about the need to use a compiler switch if you are performing a separate compilation?
>>
>> A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compile&run modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests.
>>
>> Bye,
>> bearophile
>
> Yes, this is a nice thing Java, .NET and Python have.
>
>
debug mixin(`void main() { /*do something*/ }`);
works but is kinda hacky, and line numbering on error messages might be one or two off.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
October 15, 2012
On Sun, 14 Oct 2012 23:39:42 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Mon, Oct 15, 2012 at 06:20:03AM +0200, Alex Rønne Petersen wrote:
>> On 15-10-2012 05:10, Gerry Weaver wrote:
> [...]
>> >dmd hello.d
>> >
>> >Here is the output:
>> >
>> >/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
>> >`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
>> >src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
>> >undefined reference to `_Dmain'
>> >/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
>> >`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
>> >src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
>> >undefined reference to `_tlsend'
>> >src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
>> >undefined reference to `_tlsstart'
>> >/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
>> >`thread_attachThis':
>> >src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference  
>> to
>> >`_tlsstart'
>> >src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference  
>> to
>> >`_tlsend'
>> >/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
>> >`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
>> >src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
>> >undefined reference to `_tlsend'
>> >src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
>> >undefined reference to `_tlsstart'
>> >/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
>> >`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
>> >src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
>> >undefined reference to `_tlsend'
>> >src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
>> >undefined reference to `_tlsstart'
>> >/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
>> >`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
>> >src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
>> >undefined reference to `_deh_beg'
>> >src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
>> >undefined reference to `_deh_beg'
>> >src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
>> >undefined reference to `_deh_end'
>> >src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
>> >undefined reference to `_deh_end'
>> >/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
>> >`thread_entryPoint':
>> >src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference  
>> to
>> >`_tlsend'
>> >src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference  
>> to
>> >`_tlsstart'
>> >collect2: ld returned 1 exit status
>> >--- errorlevel 1
>
> This looks like what happens if you try to use the latest dmd release
> with an old version of Phobos, perhaps installed along with gdc.
>
> Whoever's doing the .deb packaging really should add a versioned
> Depends: field to debian/control so that it will require installation of
> the correct version of Phobos, or, at the very least, refuse to install
> if such is not available.
>
>

From what I've seen, LDC and GDC both rename their versions of phobos so that they won't interfere.

I've had all three installed side-by-side at one point in time...

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
October 15, 2012
On Mon, 15 Oct 2012 04:58:14 -0500, Don Clugston <dac@nospam.com> wrote:

> On 15/10/12 11:14, Jacob Carlborg wrote:
>> Just use DVM, it's also cross-platform:
>>
>> https://bitbucket.org/doob/dvm
>
> I tried that on both Windows and Ubuntu, and couldn't get it to work on either of them. I posted a couple of bug reports eight months ago, and they still haven't been fixed. Not recommended for anyone who is having problems with their installation.

Doesn't work on Arch 64bit either.  I tried to fix it at one point and gave it up...
-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
October 16, 2012
On 2012-10-16 00:39, Iain Buclaw wrote:

> It would be less misleading if we got rid of _tlsstart and _tlsend.
> This would slim the error message down to...
>
> ---
> /usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
> `_D2rt6dmain24mainUiPPaZi7runMainMFZv':
> src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
> undefined reference to `_Dmain'
> ---
>
> Which is less cryptic, and everyone can spot a "undefined reference to
> `_Dmain'" more easily.
>
> However _tls is engraved in the current design of TLS.  On the move to
> shared libraries, I would hope that these be removed and replaced.

The corresponding variables have already been removed from the Mac OS X specific code and replaced with proper API calls.

-- 
/Jacob Carlborg
October 16, 2012
On 2012-10-16 01:54, 1100110 wrote:

> Doesn't work on Arch 64bit either.  I tried to fix it at one point and
> gave it up...

Please report the issue so it's not forgotten. You don't need to have fix or a pull request, just information how I should reproduce it.

https://bitbucket.org/doob/dvm

-- 
/Jacob Carlborg
October 16, 2012
On Tue, 16 Oct 2012 01:47:16 -0500, Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-16 01:54, 1100110 wrote:
>
>> Doesn't work on Arch 64bit either.  I tried to fix it at one point and
>> gave it up...
>
> Please report the issue so it's not forgotten. You don't need to have fix or a pull request, just information how I should reproduce it.
>
> https://bitbucket.org/doob/dvm
>
OK. Install dvm using directions on bitbucket.

dvm install -l
(no output)
dvm list
No installed D compilers

Thats it.  No errors, I'll make a issue in a bit.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/