by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 14 21:56
    JohanEngelen commented #3375
  • Jul 14 21:55
    JohanEngelen commented #3375
  • Jul 14 20:33
    kubo39 synchronize #3506
  • Jul 14 13:00
    dnadlinger commented #3507
  • Jul 14 12:08
    kinke closed #3507
  • Jul 14 12:08
    kinke commented #3507
  • Jul 14 10:46
    Geod24 commented #3507
  • Jul 14 10:34
    kinke commented #3507
  • Jul 14 10:06
    PetarKirov commented #3507
  • Jul 14 08:32
    kinke commented #3507
  • Jul 14 08:28
    Geod24 opened #3507
  • Jul 14 08:25
    Geod24 commented #3493
  • Jul 14 07:57
    kinke closed #3496
  • Jul 14 07:57
    kinke commented #3496
  • Jul 14 07:13
    kinke commented #3505
  • Jul 14 03:39
    kubo39 opened #3506
  • Jul 13 22:36
    kubo39 synchronize #3485
  • Jul 13 21:49
    kinke commented #3505
  • Jul 13 21:49
    kinke commented #3505
  • Jul 13 21:46
    kinke commented #3505
Roberto Rosmaninho
@Robertorosmaninho
Hi Kinkelin, thanks for responding. In the case of a static matrix, how can I get its size? When I identified an example as SArray, I tried to get the size using the "dim" attribute, but it didn't return what I expected, the attribute that has the closest information I need is "deco", but I don't know how to extract that information (without treating the String) and if this is the correct way to do it.
Roberto Rosmaninho
@Robertorosmaninho
static array*
Martin Kinkelin
@kinke
You can get the size, in bytes, of any type via Type::size(). dim is the static array length. If you are talking about static 2D arrays (T[2][3]), that's a static array of static arrays.
Mathias LANG
@Geod24
Hi,
I was looking at bit at LDC recently, since we dropped support for DMD. I would like to enable stdcpp tests for LDC, as it can't be done for DMD because of ABI issues (e.g. mismatch in constructors call). I see there is no CI in druntime, so I suppose everything is done through the ldc repository ?
Nicholas Wilson
@thewilsonator
Yes, see cat *.yml | grep druntime
Petar Kirov
@PetarKirov
@Geod24 @kinke @thewilsonator I think we should add an LDC build step to the upstream druntime CI
Petar Kirov
@PetarKirov
On the gamedev channel on https://dlang.slack.com/ (btw, @kinke you really should join Slack) we discussed with Manu, @Pursche, and Ethan that they want to make a druntime from scratch specialized for game development. I advised against that as there's a lot of good work put into druntime that they will miss out, in addition to potential breaking changes between the compiler and the runtime. I think we finally reached a compromise solution, which is to not start from scratch, but at fork the current upstream master branch
I still think that the best would be developing this alternative nogc runtime in the upstream repo
One of the pain points Manu mentioned is that he can't build upstream druntime with LDC, because upstream doesn't include many LDC-specific changes
Mathias LANG
@Geod24
@PetarKirov : Would love to. And to split the frontend into its own repo. But that's nowhere near happening.
Petar Kirov
@PetarKirov
I think that the best way to go would be to integrate all version (LDC) code in upstream (perhaps just without the ldc.* package
Mathias LANG
@Geod24
Yup
I welcome contributions @PetarKirov :D
Martin Kinkelin
@kinke

Compiling upstream druntime with LDC makes absolutely no sense, you couldn't use it with DMD anyway (not ABI compatible). As the README.md says, different compilers ship with different druntimes; not doing so would lead to a pretty ugly upstream druntime, with a bunch of LDC and GDC specifics, which makes the source just harder to read. From time to time, I revise the LDC-specifics diffs and try to upstream what seems to make sense, e.g., stuff that both LDC and GDC need (e.g., support for other targets). But I surely don't want to add and modify LDC-specific stuff upstream, which cannot be tested for LDC directly and would complicate + slow down LDC development.

So the only advantage of upstreaming would be to make it somewhat easier for forks; but that's obviously not my main concern. (And I would have preferred incremental improvements to druntime to make it more modularized with less dependencies on other parts, not a whole fork).

Mathias LANG
@Geod24
I was hoping that upstreaming things would make it easier for people to see what is happening on other compilers, instead of focusing on the DMD side of things and you having to fix things later. And that would prevent compilers capabilities from diverging too much.
Martin Kinkelin
@kinke

having to fix things later

That's what we (LDC devs) do whenever merging stuff and usually not a big deal.

Mathias LANG
@Geod24

But I surely don't want to add and modify LDC-specific stuff upstream, which cannot be tested for LDC directly and would complicate + slow down LDC development.

Would it be an issue to reduce the current diff, though ? That surely would not slow down development, since whatever you feel like having in your fork can go in your fork. And if we eventually get to the point where we can test (upstream) druntime additions with LDC, that'd be great, but until we get there, I don't see much problem with @thewilsonator 's PRs.

Martin Kinkelin
@kinke
Also, some druntime changes need according changes in the compiler (and vice-versa), so doing everything upstream would mean keeping both compilers in sync (assuming LDC would be used for druntime CI too), and that'd be a considerable pain (LDC follows stable, not master...).
Nick's tiny PRs seem fine for now (that's what I meant by upstreaming things that make sense), but they are nowhere enough to build a usable upstream druntime with LDC.
Mathias LANG
@Geod24
I don't think we're anywhere close to doing everything upstream, nor do I think that's what should happen.
But if we can get to a point where you have no diff with upstream after a tag (e.g. syncing on a new LDC release), that'd be great already, if only to give more visibility to upstream contributors. And that shouldn't have any impact on LDC speed of development, should it ?
Martin Kinkelin
@kinke

But if we can get to a point where you have no diff with upstream after a tag

No idea how that should work out without upstreaming everything, incl. ldc.* etc.

Mathias LANG
@Geod24
If W&A decided to accept it, would it be an issue ?
Martin Kinkelin
@kinke
Wrt. working on a fork, I don't think there would be much issues wrt. merging that stuff into the according LDC branch. There aren't that many diffs, and those are mostly contained in a few, sometimes quite heavily modified files (rt.sections_elf_shared for example).
Martin Kinkelin
@kinke
No idea why W&A would be involved in this. - Again, I don't see any advantage and need for this, just disadvantages, except to slightly simplify work an a druntime fork which is supposed to work with multiple compilers. And as said, I don't think a fork is the way to go.
Mathias LANG
@Geod24
Re: W&A, I mentioned them because they are ultimately the decision-taker. Not sure who else to ask when it comes to decision making on druntime. Personally I'm all for it, as I've often had to take a look at what LDC does (for DMD more often than druntime tho).
Or we could just merge your PR, and say "anything goes if it's surrounded by a version (LDC)", and see if anyone complain :)
But if you don't think it's worth it, well, let's keep it as is :shrug:
Martin Kinkelin
@kinke
Another, probably simpler option for the fork would be to fork LDC's druntime, not upstream's. Our version consists mostly of version (LDC) extensions, though there are some additions which aren't versioned (like additional pragma(inline, true) decorations as workarounds for missing/incomplete cross-module inlining etc.). We don't touch the upstream Makefiles (because we use CMake, and that script is in the LDC repo), so additional LDC files wouldn't be compiled with the Makefiles.
Mathias LANG
@Geod24

Another, probably simpler option for the fork would be to fork LDC's druntime, not upstream's

For dlang/druntime to become a fork of ldc-developers/druntime ?

Martin Kinkelin
@kinke
Heh no, the planned gamedev/nogc/whatever fork forking off our druntime, as it's mostly a superset of upstream's druntime.
Mathias LANG
@Geod24
Gotcha
Martin Kinkelin
@kinke
[I.e., getting LDC's druntime to compile and work correctly with DMD should be way easier than the other way.]
Petar Kirov
@PetarKirov
The potential gamedev druntime fork is the least of my motivations actually. What I actually want is the opposite! There should be no forks of druntime and phobos
I'd like all development to happen in one place so there is a single source of truth. It's really backwards that when someone wants to add support for a new platform they have test their changes with LDC or GDC's fork of druntime, only to later have to port their changes to the upstream druntime and phobos repos.
Additionally, when developing on the upstream repos, we have zero visibility how are changes affect targets not supported by dmd
Petar Kirov
@PetarKirov
For example, I think the right place for the work of adding WebAassembly/WASI support in druntime is upstream, even though it can only be tested with LDC atm
Additionally there's some long overdue restructuring between phobos and druntime
Some of it has already started by moving code from std.conv to core.lifetime
Petar Kirov
@PetarKirov
Additionally, many of us want to ditch the current makefiles and replace them with dmd's build.d. Rainer has already committed a big step in that direction ( dlang/druntime#3026)
And so on... so this why I think having all development upstream is the way to go
Ernesto Castellotti
@ErnyTech
I should define all the functions with addrspace(1) because with the AVR target it represents PROGMEM and all the code should go here. LLVM if not specified uses addrspace(0), which in AVR would be RAM or "data space". Could anyone more experienced with LDC than I advise where to edit to get this?
Martin Kinkelin
@kinke
You could probably quickly hack up something in gen/functions.cpp, DtoDefineFunction(). - That might be trouble with function pointers/delegates though, but you'll see. [To me it looks like this should be handled by the LLVM target, at least as an option. But yeah, it's still experimental.]
Ernesto Castellotti
@ErnyTech
It seems that llvm automatically adds addrspace(1) to functions, but it doesn't always work. If I use LDC_global_crt_ctor it fails with the "wrong type for intrinsic global variable" error because llvm expects [1 x {i32, void () addrspace (1) *, i8 *}] while LDC seems to provide [1 x { i32, void () *, i8 *}]
Johan Engelen
@JohanEngelen
I think the solution may be in setting the datalayout correctly. @thewilsonator may be able to tell you more about that, as I remember something was needed for similar issues for the dcompute targets.
Ernesto Castellotti
@ErnyTech
I'm currently trying to implement @ldc.attributes.addrspace, which I think is more relevant since defining variables as PROGMEM is widely used on AVR
Martin Kinkelin
@kinke
I've completely reworked https://wiki.dlang.org/LDC#Project_status. Feedback/cross-checking is very welcome.
Martin Kinkelin
@kinke
Also completely reworked: https://wiki.dlang.org/Using_LDC
Johan Engelen
@JohanEngelen
Nice, I made some more additions to those two pages
Martin Kinkelin
@kinke
Excellent.
Martin Kinkelin
@kinke
CirrusCI now features CPU & memory usage charts, pretty cool: https://cirrus-ci.com/task/4597926959775744