On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
Package.d is a real problem existing on our currently modules
design. First is that it means to take the directory name to
use as a module.
This is a problem for 3 reasons:
1. You won't be able to find your module by the file name.
Happened to stumble across this today, which I thought is a relevant, if
sadly humorous, take on build systems:
https://pozorvlak.dreamwidth.org/174323.html
T
--
ASCII stupid question, getty stupid ANSI.
On Friday, 4 November 2022 at 19:53:01 UTC, Adam D Ruppe wrote:
This isn't that hard; in the old days you'd have `pkg.foo` then
`import pkg.all` instead of `import pkg;`.
It was worse, you would do
import mylib.all;
and now it's just:
import mylib;
Also the "all" concept is bad, it
On 11/4/22 7:19 PM, Anonymouse wrote:
[#20699](https://issues.dlang.org/show_bug.cgi?id=20699) must be
non-trivial to fix, so I'm exploring makefiles. If possible I'd like to
keep dub for dependency management though, just not for actual compilation.
Is it at all possible (or even desireable)
On Fri, Nov 04, 2022 at 11:19:17PM +, Anonymouse via Digitalmars-d-learn
wrote:
> [#20699](https://issues.dlang.org/show_bug.cgi?id=20699) must be
> non-trivial to fix, so I'm exploring makefiles. If possible I'd like
> to keep dub for dependency management though, just not for actual
>
[#20699](https://issues.dlang.org/show_bug.cgi?id=20699) must be
non-trivial to fix, so I'm exploring makefiles. If possible I'd
like to keep dub for dependency management though, just not for
actual compilation.
Is it at all possible (or even desireable) to construct a
makefile that builds
On 11/4/22 3:49 PM, Adam D Ruppe wrote:
On Friday, 4 November 2022 at 19:34:58 UTC, jmh530 wrote:
Oh really, then what's the point of package.d?
It was originally added because Phobos had `std.algorithm` and
`std.datetime` and some people wanted to break them up into pieces, but
not break
On Friday, 4 November 2022 at 19:40:09 UTC, H. S. Teoh wrote:
So that you can import abc.def separately from abc.def.ghi and
abc.def.jkl.
This isn't that hard; in the old days you'd have `pkg.foo` then
`import pkg.all` instead of `import pkg;`. The specific thing
that led to the package.d
On Friday, 4 November 2022 at 19:34:58 UTC, jmh530 wrote:
Oh really, then what's the point of package.d?
It was originally added because Phobos had `std.algorithm` and
`std.datetime` and some people wanted to break them up into
pieces, but not break user code that still said `import
On Fri, Nov 04, 2022 at 07:34:58PM +, jmh530 via Digitalmars-d-learn wrote:
> On Friday, 4 November 2022 at 19:17:04 UTC, Adam D Ruppe wrote:
> > On Friday, 4 November 2022 at 19:10:33 UTC, jmh530 wrote:
> > > If you don't plan to use private(package_name), then I don't know
> > > what the
On Friday, 4 November 2022 at 19:17:04 UTC, Adam D Ruppe wrote:
On Friday, 4 November 2022 at 19:10:33 UTC, jmh530 wrote:
If you don't plan to use private(package_name), then I don't
know what the point of it is.
This works fine without the package.d anyway.
Oh really, then what's the point
On Friday, 4 November 2022 at 19:10:33 UTC, jmh530 wrote:
If you don't plan to use private(package_name), then I don't
know what the point of it is.
This works fine without the package.d anyway.
On Friday, 4 November 2022 at 16:56:59 UTC, Hipreme wrote:
[snip]
You can use any name instead. The only difference between an
ordinary source file and a package.d is the module name. For
instance, if you're inside the filesystem directory, you can
change the name to literally anything and
On Friday, 4 November 2022 at 16:21:17 UTC, z wrote:
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
What do we use instead?
I won't lie about the fact package.d forced me to workaround
elusive "bugs" in my usage(1) but what is the alternative if we
don't want to work around
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
What do we use instead?
I won't lie about the fact package.d forced me to workaround
elusive "bugs" in my usage(1) but what is the alternative if we
don't want to work around it?
(1)(ime : had cases of package.d requiring
On Friday, 4 November 2022 at 14:11:55 UTC, bauss wrote:
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
I disagree completely with being against package.d.
Having used D for like a decade at this point, I've never
experienced any issues with it.
Most issues seems to be for
On Friday, 4 November 2022 at 14:11:55 UTC, bauss wrote:
Having used D for like a decade at this point, I've never
experienced any issues with it.
Lucky you, lots of other people have. Broken phobos updates,
impossible to transition to it without code breakages (which is
the only reason it
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:
...
I disagree completely with being against package.d.
Having used D for like a decade at this point, I've never
experienced any issues with it.
Most issues seems to be for newcomers and people who aren't
entirely familiar with
Package.d is a real problem existing on our currently modules
design. First is that it means to take the directory name to use
as a module.
This is a problem for 3 reasons:
1. You won't be able to find your module by the file name. This
is incredibly common, for instance, in Visual Studio
On Friday, 4 November 2022 at 08:48:36 UTC, Salih Dincer wrote:
On Thursday, 3 November 2022 at 11:58:20 UTC, Paul Backus wrote:
On Thursday, 3 November 2022 at 06:26:22 UTC, Salih Dincer
Looking at the source, it seems that only the numeric
overloads of `iota` implement `save`. I think this
On Thursday, 3 November 2022 at 11:58:20 UTC, Paul Backus wrote:
On Thursday, 3 November 2022 at 06:26:22 UTC, Salih Dincer
Looking at the source, it seems that only the numeric overloads
of `iota` implement `save`. I think this is probably just an
oversight, though, since I can't see any
21 matches
Mail list logo
