On Tuesday, 20 February 2018 at 08:46:02 UTC, meppl wrote:

> @"16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime
>
> So, now someone could "easily" write his own memory managment for allocations who would be usually done by the default GC - e.g. classes?

Easily? unlikely, but it's probably possible.  For example, whenever you use `new` to instantiate a class, it calls `_d_newclass` (https://github.com/dlang/druntime/blob/098a08a9593a8e265a9b02da55bda53393f3d5c1/src/rt/lifetime.d#L66).  You could potentially make that do something different.  You will, unfortunately, need some implement some "infrastructure" to get it to work, namely `ClassInfo` which is an alias for `TypeInfo`.

At the moment the runtime is heavily dependent on `TypeInfo` for type information that's already known at compile-time, which stinks.  To mitigate that some of us are working on modifying the the compiler/runtime interface to use templates instead.  That would allow implementing the runtime hooks without requiring so much of the infrastructure.

Btw, this is all possible now even without the features of 2.079.  2.079 just allows one to do this more incrementally.  It's still a long way from being a pleasant experience, but it's getting better.

Mike

On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
>
>
> On 19/02/2018 21:17, Andre Pany wrote:
>> On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
>>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release.
>>>
>>> [...]
>> 
>> This release is fantastic!
>> 
>> In the change log information about lld linker is missing. Maybe you can add
>> some info how to use it instead of link.exe (the OMF one).
>> 
>> Kind regards
>> André
>
> LLD does not replace the OMF linker, but the MS linker for COFF.
>
> The Windows installer also comes with platform libraries built from the mingw definitions and a wrapper library for the VC distributable C runtime libraries. This allows using dmd with -m64 and -m32mscoff without having to install Visual Studio, the VC build tools or the Windows SDK.
>
> I'll add a PR for the changelog...

How does one keep on using Microsoft's linker? I've tried lld on Linux and while some binaries ran fine, others crashed. I don't trust it all right now.

Atila

On 20/02/2018 9:49 AM, Atila Neves wrote:
> On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
>>
>>
>> On 19/02/2018 21:17, Andre Pany wrote:
>>> On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
>>>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release.
>>>>
>>>> [...]
>>>
>>> This release is fantastic!
>>>
>>> In the change log information about lld linker is missing. Maybe you can add
>>> some info how to use it instead of link.exe (the OMF one).
>>>
>>> Kind regards
>>> André
>>
>> LLD does not replace the OMF linker, but the MS linker for COFF.
>>
>> The Windows installer also comes with platform libraries built from the mingw definitions and a wrapper library for the VC distributable C runtime libraries. This allows using dmd with -m64 and -m32mscoff without having to install Visual Studio, the VC build tools or the Windows SDK.
>>
>> I'll add a PR for the changelog...
> 
> How does one keep on using Microsoft's linker? I've tried lld on Linux and while some binaries ran fine, others crashed. I don't trust it all right now.
> 
> Atila

By the looks, nothing.

https://github.com/dlang/dmd/blob/3030457738872ffe12e145dddb80b8b4cf766e4b/src/dmd/link.d#L1031

Also Windows and Linux support in lld may as well be equated to a completely different set of projects.

"The linkers share the same design but share very little code. Sharing code makes sense if the benefit is worth its cost. In our case, the object formats are different enough that we thought the layer to abstract the differences wouldn’t be worth its complexity and run-time cost. Elimination of the abstract layer has greatly simplified the implementation." - https://lld.llvm.org/NewLLD.html

On Tuesday, 20 February 2018 at 09:49:07 UTC, Atila Neves wrote:
> How does one keep on using Microsoft's linker? I've tried lld on Linux and while some binaries ran fine, others crashed. I don't trust it all right now.
>
> Atila

DMD prefers VC's linker if it is installed and will only fallback to lld-link.exe if no VC installation can be found.
So there is a slight risk of accidentally using lld, when sth. in the VC detection code fails, but I hope that part is solid enough by now.
Of course you can manully pick the linker using an env var, https://github.com/dlang/dmd/blob/38da6c2258c0ff073b0e86e0a1f6ba190f061e5e/src/dmd/link.d#L274, with the possibility to hard-coding the setting in your sc.ini.

What were addressing here is the problem that in order to try D on Windows you need to go through the 30min. hoop of installing multi-GiB VC and Win SDK, or live with an outdated object file format and a hardly maintained linker.
So this should improve the default experience on Windows.
If someone wants to interact with C/C++, chances that VC is already installed are very high.

On Tuesday, 20 February 2018 at 12:07:58 UTC, Martin Nowak wrote:
>
> What were addressing here is the problem that in order to try D on Windows you need to go through the 30min. hoop of installing multi-GiB VC and Win SDK, or live with an outdated object file format and a hardly maintained linker.
> So this should improve the default experience on Windows.
> If someone wants to interact with C/C++, chances that VC is already installed are very high.

only 30min?

what world are you living in ;-)

great work btw. looking forward to seeing it in action.

On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
> On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
>> 17. Allow multiple selective imports from different modules in a single import statement
>>
>> I have a bad feeling that that one is going to be a source of a raft of bugs for years to come.
>
> No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking.
> It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end.
> If you prefer java-like 50 lines import manifests, then by all means keep using those.
> How would that feature cause bugs though?

In:

    import myModule : foo, bar;

how do you know if bar is myModule.bar or if it's a separate module bar?

On Tuesday, 20 February 2018 at 08:26:06 UTC, Rainer Schuetze wrote:
>
>
> On 20/02/2018 01:58, Basile B. wrote:
>> On Monday, 19 February 2018 at 21:50:02 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 19/02/2018 21:17, Andre Pany wrote:
>>>> On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote:
>>>>> Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release.
>>>>>
>>>>> [...]
>>>>
>>>> This release is fantastic!
>>>>
>>>> In the change log information about lld linker is missing. Maybe you can add
>>>> some info how to use it instead of link.exe (the OMF one).
>>>>
>>>> Kind regards
>>>> André
>>>
>>> LLD does not replace the OMF linker, but the MS linker for COFF.
>>>
>>> The Windows installer also comes with platform libraries built
>> 
>> Just one step left to get an unified debug experience then: dward2 debug info for windows COFF objects.
>> 
>> Is that right ?
>
> I don't think that is planned in the near future.
>
> AFAICT DWARF debug support in dmd is not better than COFF (GDC might have an edge here), but using gdb instead of the VS debugger (or any other debugger suporting standard debug info) on Windows is pretty uncommon.

I mean that by default we could have, under windows
- the standard C lib interfaced to MinGW stuff (instead of digital mars snn.lib)
- COFF objects, (instead of OMF)
- DWARF2 debug infos, so that GDB can be used.

GDB doesn't recognize OMF (and even if it did then there's the CV problem).

FreePascal compiler follow this pattern: COFF everywhere, and DWARF as format of debug infos. What i meant is that DMD is at one step of being able to do the same, under windows even for COFF objects, debug infos are not DWARF format but the MS format. (unless i miss something, which is possible since i don't use win anymore).

On Tuesday, 20 February 2018 at 19:36:46 UTC, John Gabriele wrote:
>
> In:
>
>     import myModule : foo, bar;
>
> how do you know if bar is myModule.bar or if it's a separate module bar?

It probably could be described a little better in the change log. It uses examples, but doesn't really describe what the file structure is that work with those examples.

Perhaps this:

--- pkg.d
module pkg;

public import pkg.mod1;
public import pkg.mod2;

--- pkg.mod1.d
module pkg.mod1;

enum sym1;

--- pkg.mod2.d
module pkg.mod2;

enum sym2;

If this structure works for both of those examples, then
import pkg.mod1 : sym1, mod2 : sym2;
works because mod2 has a selective import and
import pkg.mod1 : sym1, sym2, pkg.mod2;
works because pkg.mod2 is fully qualified (it may be annoying to find sym2 if this works with the above structure).

So in your example you know that bar is in myModule because bar is neither fully qualified, nor is it fully qualified.

So it seems like something below would also work
import pkg : mod1 : sym1, mod2 : sym2;
but then what about
import pkg.mod1 : sym1, mod2 : sym2, sym3;
Is sym3 part of mod1 or mod2?

On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
> So in your example you know that bar is in myModule because bar is neither fully qualified, nor is it fully qualified.
>

*nor does it have selective imports.

so how does one enforce that it imports `bar` as a module and not a
symbol in myModule when doing `import myModule : foo, bar;` ?
could this be supported:
`import myModule : foo, bar :`;
to break ambiguity?



On Tue, Feb 20, 2018 at 12:10 PM, jmh530 via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
>>
>> So in your example you know that bar is in myModule because bar is neither fully qualified, nor is it fully qualified.
>>
>
> *nor does it have selective imports.