On 10/06/2018 01:38 AM, 0xEAB wrote:
The "tests" check doesn't seem to work properly for DMD <= v2.072.0.
If one looks at the reports[0] for those compilers, one will that pretty
everything failed.
For example, `discord-rpc`[1] doesn't even have any unittests.
I'm clearing out those build
On Friday, 21 September 2018 at 22:26:11 UTC, Neia Neutuladh
wrote:
On Friday, 21 September 2018 at 20:49:54 UTC, 0xEAB wrote:
On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh
wrote:
The tester is now submodule-aware and I removed builds for
packages with a `.gitmodules` file.
On Friday, 21 September 2018 at 20:49:54 UTC, 0xEAB wrote:
On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh
wrote:
The tester is now submodule-aware and I removed builds for
packages with a `.gitmodules` file.
I'm not sure whether this is actually a good idea. There are
some
On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh
wrote:
The tester is now submodule-aware and I removed builds for
packages with a `.gitmodules` file.
I'm not sure whether this is actually a good idea. There are some
projects that support both, DUB and submodules+makefile. Those
On Thursday, 20 September 2018 at 06:41:54 UTC, drug wrote:
Autotester should show build logs because for example `nanogui`
package reported as failed although it builds on my machines
successfully.
The tester is now submodule-aware and I removed builds for
packages with a `.gitmodules`
On Monday, 10 September 2018 at 12:16:03 UTC, Adam D. Ruppe wrote:
On Sunday, 9 September 2018 at 14:28:11 UTC, Guillaume Piolat
wrote:
I don't manage to find x-module search again, perhaps disabled.
Yeah, there's a memory leak in it so leaving it up would kill
the box to build actual docs.
On Thursday, 20 September 2018 at 06:41:54 UTC, drug wrote:
Autotester should show build logs because for example `nanogui`
package reported as failed although it builds on my machines
successfully.
This is because the D project tester (i assume this is what you
call autotester) uses
20.09.2018 07:16, Neia Neutuladh пишет:
On Thursday, 20 September 2018 at 02:51:52 UTC, Neia Neutuladh wrote:
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh wrote:
Not on dlang.org anywhere, but I built a crude version of this.
Results are available at http://ikeran.org/report/.
On Thursday, 20 September 2018 at 04:16:41 UTC, Neia Neutuladh
wrote:
And source code is available at
https://git.ikeran.org/dhasenan/dubautotester
Please don't judge me.
Nice work.
On Thursday, 20 September 2018 at 02:51:52 UTC, Neia Neutuladh
wrote:
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh
wrote:
Not on dlang.org anywhere, but I built a crude version of
this. Results are available at http://ikeran.org/report/.
A quick status update:
And source
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh
wrote:
Not on dlang.org anywhere, but I built a crude version of this.
Results are available at http://ikeran.org/report/.
A quick status update:
Per-package reports and build badges are now a thing.
On Tuesday, 11 September 2018 at 13:48:36 UTC, 0xEAB wrote:
By the way, thanks for all your explanations :)
No problem! If it's inscrutable, it's not very useful.
On Monday, 10 September 2018 at 20:36:44 UTC, Neia Neutuladh
wrote:
On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote:
Moreover, a future feature could be build logs, so one could
check why something failed to build.
I'm hesitant to do much in this regard because I don't want
people
On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote:
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh
wrote:
It blindly takes the results of dub build and dub test.
Another question:
How does it deal with targetType set to "sourceLibrary"?
As of five minutes ago, for
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh
wrote:
It blindly takes the results of dub build and dub test.
Another question:
How does it deal with targetType set to "sourceLibrary"?
Moreover, a future feature could be build logs, so one could
check why something failed to
On Monday, 10 September 2018 at 15:46:28 UTC, Neia Neutuladh
wrote:
midi-gamepad has no releases. It has 0.1.1-alpha
So it doesn't test pre-release versions.
Thanks for clarification.
On Monday, 10 September 2018 at 13:58:37 UTC, 0xEAB wrote:
May I ask why some packages are missing (e.g. `midi-gamepad`)?
midi-gamepad has no releases. It has 0.1.1-alpha, which is a
prelease version, and ~master, which is a branch, and I can't
rely on ~master being consistent in successive
On Monday, 10 September 2018 at 10:50:16 UTC, Joakim wrote:
Nice work. I wonder about some of your results, as it says that
dub itself doesn't build with all of the dmd versions, but
somehow the tests pass sometimes (shouldn't be possible if you
can't build dub itself). I just tested with `dub
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh
wrote:
Not on dlang.org anywhere, but I built a crude version of this.
Results are available at http://ikeran.org/report/.
The current backfill is taking the three most recent versions
of each package on the ~40 most recent versions
On Sunday, 9 September 2018 at 14:28:11 UTC, Guillaume Piolat
wrote:
I don't manage to find x-module search again, perhaps disabled.
Yeah, there's a memory leak in it so leaving it up would kill the
box to build actual docs. And the last couple months have been
crazy IRL, but I scheduled
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh
wrote:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh
wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of
On Mon, Sep 10, 2018 at 01:27:20AM +, Neia Neutuladh via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
> > To me, this strongly suggests the following idea:
> > - add *all* dlang.org packages to our current autotester / CI
> > infrastructure.
> > -
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of a) package builds successfully,
log the
compiler version / git hash
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
Really, D wins on very few metrics but the D fanboys will only
focus on those.
If D wants to survive it better get people willing to help it,
making their lives more difficult when there are far better
options out there will
On Saturday, 8 September 2018 at 18:10:50 UTC, Jonathan M Davis
wrote:
A related issue is projects that have dependencies outside of D
itself
- for instance, a project that wraps GTK or Qt or something C
or C++ library
[...]
These problems aren't necessarily insurmountable, but they do
On Saturday, 8 September 2018 at 23:33:42 UTC, Nick Sabalausky
(Abscissa) wrote:
I can't speak for anyone else but it looks to me as a
realistic way to have it.
You can also donate to Adam for http://dpldocs.info/, it has
interesting things like cross-package search (search ALL of
On 09/08/2018 08:43 AM, Guillaume Piolat wrote:
We have something similar with dpldocs which builds docs lazily, and is
now linked from code.dlang.org
It's a matter of extending it with downloading toolchain and building.
I can't speak for anyone else but it looks to me as a realistic way
On Saturday, 8 September 2018 at 18:10:50 UTC, Jonathan M Davis
wrote:
A related issue is projects that have dependencies outside of D
itself
- for instance, a project that wraps GTK or Qt or something C
or C++ library
that is on many systems but which isn't guaranteed to be
present. It would
On Saturday, September 8, 2018 7:28:53 AM MDT Nicholas Wilson via
Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
> > Again, this strongly suggests the idea I've mentioned a few
> > times now: *all* packages on code.dlang.org needs to be run
> > through a
On Saturday, September 8, 2018 7:44:09 AM MDT Nicholas Wilson via
Digitalmars-d wrote:
> On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
>
> wrote:
> > Honestly, I wouldn't rely on anything beyond dub build working
> > in a consistent manner across projects. As far as I can tell,
>
On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
wrote:
Honestly, I wouldn't rely on anything beyond dub build working
in a consistent manner across projects. As far as I can tell,
you can't actually do anything properly custom with dub test,
and I'm inclined to think that how it
On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
Again, this strongly suggests the idea I've mentioned a few
times now: *all* packages on code.dlang.org needs to be run
through a CI tester, and success/failure to compile should be
reported back to dlang.org somehow. Then in
On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky
(Abscissa) wrote:
Personally, I think that's a really good way to go. However,
for awhile now, I've been starting to think: "Wouldn't it be
awesome to have a packager manager that AUTOMATICALLY picks up
compatibility information
On Saturday, 8 September 2018 at 11:24:50 UTC, rjframe wrote:
The beta might be better than dmd-nightly, as they would avoid
the churn and still provide maintainers with time to react to
problems with the upcoming release before the release is out.
Betas are often outdated and contain
On Fri, 07 Sep 2018 09:35:29 -0700, H. S. Teoh wrote:
> ([*] I was going to suggest including dmd-nightly as well, but that
> poses the problem of load: running it every night will cause a lot of CI
> churn, which also generates a lot of mostly-useless information -- no
> one will care about
On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:
On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh
wrote:
[...]
There are ways around this:
[...]
Is there any other language that does any of this? I don't think
any language does all of it, so do you plan to wait
On Saturday, 8 September 2018 at 01:32:19 UTC, Everlast wrote:
There are ways around this:
Take a step back and consider what you're asking for.
You are asking for dub to become github. A very cruddy version of
github. One in which everyone can submit changes to every
repository. With a
On 09/07/2018 10:29 AM, 0xEAB wrote:
On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky (Abscissa)
wrote:
Personally, I think that's a really good way to go. However, for
awhile now, I've been starting to think: "Wouldn't it be awesome to
have a packager manager that AUTOMATICALLY
On Saturday, 8 September 2018 at 00:53:33 UTC, Neia Neutuladh
wrote:
On Saturday, 8 September 2018 at 00:04:08 UTC, Everlast wrote:
Seems there are a few good suggestions.
Here is another:
Have dub have the ability to submit patches when a previously
broken package compiles.
So I identify
On Saturday, 8 September 2018 at 00:04:08 UTC, Everlast wrote:
Seems there are a few good suggestions.
Here is another:
Have dub have the ability to submit patches when a previously
broken package compiles.
So I identify a package that doesn't compile anymore and submit a
patch that adds a
Seems there are a few good suggestions.
Here is another:
Have dub have the ability to submit patches when a previously
broken package compiles.
For example, I fixed a few bugs in the demo pretty quick... dub
should automatically push those changes to the right place so
they can be used by
On Friday, 7 September 2018 at 20:06:47 UTC, 0xEAB wrote:
What's the reason for this questions?
Well, there's the evil `sourceLibrary` build type, that makes
it impossible to build a package itself, no matter what.
Kind regards,
Elias
Okay, sorry, I think my last message will cause some
On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
wrote:
Honestly, I wouldn't rely on anything beyond dub build working
in a consistent manner across projects. As far as I can tell,
you can't actually do anything properly custom with dub test,
and I'm inclined to think that how it
On Friday, September 7, 2018 10:35:29 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> On Fri, Sep 07, 2018 at 09:24:13AM -0600, Jonathan M Davis via
> Digitalmars-d wrote: [...]
> > What's somewhat more of an open question is how new compiler releases
> > should be handled. Aside from the issue that
On Friday, 7 September 2018 at 15:24:13 UTC, Jonathan M Davis
wrote:
I don't see how such a system could work very well if it's not
automated. Simply doing it with every release of dmd means that
newer packages won't be tested, and it would force someone to
take the time to run stuff every dmd
On Fri, Sep 07, 2018 at 09:24:13AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
[...]
> I don't see how such a system could work very well if it's not
> automated. Simply doing it with every release of dmd means that newer
> packages won't be tested, and it would force someone to take the
On Friday, September 7, 2018 8:36:11 AM MDT 0xEAB via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 20:08:08 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via
> >
> > Digitalmars-d wrote:
> >> Ah, but would you actually pay for such a service
On Friday, 7 September 2018 at 08:17:45 UTC, Nick Sabalausky
(Abscissa) wrote:
I think some sort of semver scheme really should be
implemented for the compiler and phobos. But we need more
manpower to handle that.
Fair point on manpower.
Does using semver really solve anything here?
I've
On Thursday, 6 September 2018 at 20:08:08 UTC, Jonathan M Davis
wrote:
On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via
Digitalmars-d wrote:
Ah, but would you actually pay for such a service to be set up?
https://forum.dlang.org/thread/acxedxzzesxkyomrs...@forum.dlang.org
It's all
On Friday, 7 September 2018 at 08:12:05 UTC, Nick Sabalausky
(Abscissa) wrote:
Personally, I think that's a really good way to go. However,
for awhile now, I've been starting to think: "Wouldn't it be
awesome to have a packager manager that AUTOMATICALLY picks up
compatibility information
On 09/06/2018 09:12 AM, Steven Schveighoffer wrote:
The compiler doesn't change all that often, and when it does, it's
usually a long deprecation cycle.
Even with perfect backwards compatibility in the compiler, minimum
compiler version will still tend to matter. Also, cherry-picking
On 09/05/2018 05:49 PM, H. S. Teoh wrote:
On Wed, Sep 05, 2018 at 04:40:19PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
[...]
What we need is for DUB to quit pretending the compiler (and DUB
itself, for that matter) isn't a dependency just like any other. I
pointed this out
On Thursday, September 6, 2018 12:35:06 PM MDT Joakim via Digitalmars-d
wrote:
> Ah, but would you actually pay for such a service to be set up?
>
> https://forum.dlang.org/thread/acxedxzzesxkyomrs...@forum.dlang.org
>
> It's all well and good to hope for such services, but they're
> unlikely to
On Thursday, 6 September 2018 at 18:20:05 UTC, Bastiaan Veelo
wrote:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh
wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of a) package builds successfully,
log the
compiler version / git hash
On Thursday, 6 September 2018 at 16:27:38 UTC, Everlast wrote:
You totally missed the point.
The point with 1 package only was to demonstrate how easy it is
to maintain and that it theoretically would have the long
longevity. When one has an infinite number of packages then
every package(or
On Thu, Sep 06, 2018 at 04:32:09PM +, Everlast via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter wrote:
[...]
> > What annoys people is not that there are broken packages in the
> > list, but that there is no way to know beforehand if one is choosing
>
On Thursday, 6 September 2018 at 15:28:56 UTC, Patrick Schluter
wrote:
On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany
wrote:
On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast
wrote:
[...]
You showed as a
On Thursday, 6 September 2018 at 13:08:00 UTC, Laurent Tréguier
wrote:
On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
The problem is that all projects should be maintained. The
issue, besides the tooling which can only reduce the problem
to manageable levels, is that projects
On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany
wrote:
On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
[...]
You showed as a painful issue in our eco system which we can
work on, thank you.
You do
On Thursday, 6 September 2018 at 13:03:09 UTC, 0xEAB wrote:
On Thursday, 6 September 2018 at 10:55:04 UTC, Laurent Tréguier
wrote:
Then would it be possible to use code coverage to hint users
about packages possibly not building anymore even if they are
shown to be buildable ?
I see yet
On 9/5/18 4:40 PM, Nick Sabalausky (Abscissa) wrote:
On 09/04/2018 09:58 PM, Jonathan M Davis wrote:
On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via
Digitalmars-d
wrote:
Are you talking about this?
https://github.com/clinei/3ddemo
which hasn't been updated since February
On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
The problem is that all projects should be maintained. The
issue, besides the tooling which can only reduce the problem to
manageable levels, is that projects go stale over time.
This is obvious! You say though "But we can't
On Thursday, 6 September 2018 at 10:55:04 UTC, Laurent Tréguier
wrote:
Then would it be possible to use code coverage to hint users
about packages possibly not building anymore even if they are
shown to be buildable ?
I see yet another problem here. Having to maintain a high
coverage just to
On Wednesday, 5 September 2018 at 12:32:33 UTC, Andre Pany wrote:
On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus
wrote:
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast
wrote:
[...]
If you don't want to use
On Thursday, 6 September 2018 at 10:35:44 UTC, Guillaume Piolat
wrote:
+1 talk here assume that we can know what we build compile or
not,
but with template it doesn't make sense unless the unittest
instantiate.
And since we can't add unittest magically where there is none,
it's not a
On Wednesday, 5 September 2018 at 07:07:50 UTC, JN wrote:
On Wednesday, 5 September 2018 at 06:16:57 UTC, Neia Neutuladh
wrote:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh
wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current
On Thursday, 6 September 2018 at 01:13:37 UTC, 0xEAB wrote:
On Wednesday, 5 September 2018 at 14:39:39 UTC, RhyS wrote:
This is the same reason why D with Code-D on Windows was a
total disaster. You install VSC+CodeD. It breaks because some
dependency library somewhere was not updated for DMD
On Wednesday, 5 September 2018 at 16:26:14 UTC, rikki cattermole
wrote:
On 06/09/2018 4:19 AM, H. S. Teoh wrote:
On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via
Digitalmars-d wrote:
On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via
Digitalmars-d
wrote:
[...]
Also,
On Wednesday, 5 September 2018 at 14:39:39 UTC, RhyS wrote:
This is the same reason why D with Code-D on Windows was a
total disaster. You install VSC+CodeD. It breaks because some
dependency library somewhere was not updated for DMD xx.0,
because D broke/changed something again. Contact the
On Wed, Sep 05, 2018 at 04:40:19PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
[...]
> What we need is for DUB to quit pretending the compiler (and DUB
> itself, for that matter) isn't a dependency just like any other. I
> pointed this out years ago over at DUB's GitHub project,
On Wednesday, 5 September 2018 at 15:28:38 UTC, H. S. Teoh wrote:
On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
[...]
[...]
And that is why I think we should implement my idea of putting
*all* dub packages on code.dlang.org into our CI
On 09/04/2018 09:58 PM, Jonathan M Davis wrote:
On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via Digitalmars-d
wrote:
Are you talking about this?
https://github.com/clinei/3ddemo
which hasn't been updated since February 2016?
This is part of why it's sometimes been discussed
On 9/5/18 11:46 AM, Dennis wrote:
On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven Schveighoffer wrote:
3ddemo has one commit. In February 2016. I think it would be an
amazing feat indeed if a project with one version builds for more than
2 years in any language.
This problem is not
On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus
wrote:
[...]
I'm not going to sit here and spend have my time fixing shit
that should have never broke in the first place.
Thanks, you've made a great decision for
On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis
wrote:
On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via
Digitalmars-d wrote:
On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
> 3rd party libraries are usually the real
On Wednesday, 5 September 2018 at 15:28:38 UTC, H. S. Teoh wrote:
And that is why I think we should implement my idea of putting
*all* dub packages on code.dlang.org into our CI
infrastructure, and log all successes / failures to a database
that can then be used to display the range of
On 06/09/2018 4:19 AM, H. S. Teoh wrote:
On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d
wrote:
[...]
And that is why I think we should implement my idea of putting *all*
dub
On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d
> wrote:
[...]
> > And that is why I think we should implement my idea of putting *all*
> > dub packages on code.dlang.org into our CI
On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis
wrote:
but it doesn't fix the fundamental problem that whoever wrote
the library needs to continue to maintain it or pass it on to
someone else to maintain it when they don't want to maintain it
anymore, or anyone using it is
On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven
Schveighoffer wrote:
3ddemo has one commit. In February 2016. I think it would be an
amazing feat indeed if a project with one version builds for
more than 2 years in any language.
This problem is not about 3ddemo. I can totally relate to
On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via
> Digitalmars-d wrote: [...]
>
> > 3rd party libraries are usually the real problem if there is one. They
> > need to be maintained, and if something
On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
[...]
> 3rd party libraries are usually the real problem if there is one. They
> need to be maintained, and if something happens that breaks them from
> one release to another, that can prevent you from upgrading
On Wednesday, September 5, 2018 9:05:29 AM MDT SashaGreat via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 14:45:25 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via
> > Digitalmars-d wrote:
> > ...
>
> Thanks for replying and I think
On Wednesday, 5 September 2018 at 14:45:25 UTC, Jonathan M Davis
wrote:
On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via
Digitalmars-d wrote:
...
Thanks for replying and I think I'm ok with this line of thought.
And another thing it's not just my own code, but the
third-parties
On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven
>
> Schveighoffer wrote:
> > 3ddemo has one commit. In February 2016. I think it would be an
> > amazing feat indeed if a project with one version builds for
On Wednesday, 5 September 2018 at 05:53:46 UTC, Neia Neutuladh
wrote:
Compare with DMD over the past year. (Just one year!) opDot was
deprecated, C-style array declarations were removed, opDispatch
works differently with `with` statements, arithmetic with
pointers of different types was
On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven
Schveighoffer wrote:
3ddemo has one commit. In February 2016. I think it would be an
amazing feat indeed if a project with one version builds for
more than 2 years in any language.
I built it successfully with DMD 2.076 (I just picked a
On 9/4/18 8:49 PM, Everlast wrote:
I downloaded 3ddemo, extracted, built and I get these errors:
logger 2.66.0: building configuration "library"...
\dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16): Error:
cannot implicitly convert expression logger of type
On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote:
On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus
wrote:
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
[...]
If you don't want to use D, then don't use D. No one is
holding a gun to your head.
It
On Wednesday, September 5, 2018 3:54:17 AM MDT Everlast via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 08:21:48 UTC, Kagamin wrote:
> > On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> >> This attitude of "It's your problem" is going to kill D.
> >
> > Well, if you
On Wednesday, 5 September 2018 at 08:21:48 UTC, Kagamin wrote:
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
This attitude of "It's your problem" is going to kill D.
Well, if you hate problems, programming will hurt you a lot in
any language.
No one said I hate problems,
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
On Wed, Sep 05, 2018 at 01:18:17AM +, James Blachly via
Digitalmars-d wrote:
[...]
[...]
[...]
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
This attitude of "It's your problem" is going to kill D.
Well, if you hate problems, programming will hurt you a lot in
any language.
On Tue., 4 Sep. 2018, 10:45 pm H. S. Teoh via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Wed, Sep 05, 2018 at 01:18:17AM +, James Blachly via Digitalmars-d
> wrote:
> > On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> > > I downloaded 3ddemo, extracted, built
On Wednesday, 5 September 2018 at 06:16:57 UTC, Neia Neutuladh
wrote:
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh
wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of
On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus wrote:
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
There is really no incentive for me to use D except for it's
language features... everything else it does, besides
performance, is shit compared to what most other
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
On Wed, Sep 05, 2018 at 01:18:17AM +, James Blachly via
Digitalmars-d wrote:
On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> I downloaded 3ddemo, extracted, built and I get these errors:
>
...
[...]
Are
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote:
To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
infrastructure.
- if a particular (version of a) package builds successfully,
log the
compiler version / git hash
On Wednesday, 5 September 2018 at 04:32:18 UTC, SrMordred wrote:
Wouldn´t be interesting to specify the compiler version on
dub.json?
(I think ruby uses this idea)
Ruby 1.8 stuck around for four years before Ruby 1.9 came out.
Then it was six years until Ruby 2.0 came out. These days,
1 - 100 of 110 matches
Mail list logo
