View mode: basic / threaded / horizontal-split · Log in · Help
October 15, 2012
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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
Re: D seems interesting, but...
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/
3 4 5 6 7 8
Top | Discussion index | About this forum | D home