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 got the feeling that we'll end up with v128.0.1, v129.0.0, v130.0.0 and so on, plus nobody caring about maintaining an LTS branches.

Also, anybody is free to downgrade their compiler to any outdated version anyway, giving those old versions a different version number won't make using them more attractive, imho.

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 to be set up?
> >>
> >> https://forum.dlang.org/thread/acxedxzzesxkyomrsmjo@forum.dlang.org
> >>
> >> It's all well and good to hope for such services, but they're unlikely to happen unless paid for.
> >
> > That's actually something that I could see happening without anyone being paid to do it, but it's much more likely to get done in a timely manner if someone is paid to do it, and it's arguably critical enough for the dub ecosystem that it's something that the Foundation should pay someone to do.
> >
> > - Jonathan M Davis
>
> The software itself is pretty simple (besides it has to deal with some DUB bugs). It would just need someone to run it. If running it every DMD release is sufficient and if it doesn't need to be automated, it won't be such a big deal anymore.
>
> By the way, I'm currently playing around testing DUB packages with my prototype.

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 release, which they may or may not have time to do. IMHO, it really only makes sense to set up something automated.

I would expect that any time code.dlang.org detected that a package had a new version (or a package was added), the new versions would be tested.

What's somewhat more of an open question is how new compiler releases should be handled. Aside from the issue that _every_ package then potentially needs to be tested (which could take a while), there's the issue of which versions to test. Testing every release of a package would be overkill, but simply testing the latest isn't necessarily enough.

Also, there's the question of what it even means to test each package to verify that it's working. Does that mean running the unit tests? Not all projects run them the same way, and it could be pretty expensive to run the tests for all packages on code.dlang.org. And of course, that assumes that the package even has any unit tests to begin with. So, should testing the package just mean that dub build works? That will catch the really basic problems, but it won't usually catch problems in templates and could easily miss other types of problems - though maybe it's enough. Regardless, it's going to need to be made clear what it means that code.dlang.org claims that a package works with a particular version of the compiler.

All in all, while this seems like a great idea, the more I think about it, the more it seems like it could get pretty thorny when sorting out all of the details.

- Jonathan M Davis

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 time to run stuff every dmd release, which they may or may not have time to do. IMHO, it really only makes sense to set up something automated.

Yes, it needs to be automated and run in the background by a machine. Humans are just too unreliable for this.


> I would expect that any time code.dlang.org detected that a package had a new version (or a package was added), the new versions would be tested.

That would make the most sense.


> What's somewhat more of an open question is how new compiler releases should be handled. Aside from the issue that _every_ package then potentially needs to be tested (which could take a while), there's the issue of which versions to test. Testing every release of a package would be overkill, but simply testing the latest isn't necessarily enough.

The initial setup will take a long time because we have so many packages that have never been tested in this way before.  But once the database is up-to-date, I expect that it will take much less work to keep things up-to-date.

For the initial setup, I don't think it's necessary to test *every* historial release of the compiler -- the most important thing is the current official releases of all compilers (gdc, ldc, dmd).[*]  If a package doesn't compile with the latest release, then optionally do a unidirectional search backwards to find the last compiler version that compiles it successfully, and log that.

([*] 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 which of 50 dmd git revisions failed / succeeded to compile a package, just whether the *latest* dmd-nightly works.  So perhaps an update once a week or once a month in between releases will be enough.  But dmd-nightly is an optional extra that can be skipped for now.  The important baseline is the current official releases of gdc / ldc / dmd.)


> Also, there's the question of what it even means to test each package to verify that it's working. Does that mean running the unit tests? Not all projects run them the same way, and it could be pretty expensive to run the tests for all packages on code.dlang.org. And of course, that assumes that the package even has any unit tests to begin with. So, should testing the package just mean that dub build works? That will catch the really basic problems, but it won't usually catch problems in templates and could easily miss other types of problems - though maybe it's enough. Regardless, it's going to need to be made clear what it means that code.dlang.org claims that a package works with a particular version of the compiler.
[...]

Let's not overcomplicate things and doom the flight before it takes off. Let's start with the absolute minimum baseline, and then additional perks can be added on top of that once the baseline is working.

I say the baseline is that dub build works.

If we feel like going an extra mile, dub test.

If we feel like doing even more, then add other stuff like compiling provided example programs, testing template instantiations and what-not. (Though one would expect that dub test ought to do that already, otherwise I question the quality of the code / unittests.)

As long as we publish exactly what is being run to verify whether the package "works", I think that should be good enough for starters.  Even if dub build, say, doesn't catch all problems, it's still better than the status quo of no information at all.  Let's not let the perfect become the enemy of the good, as is the common malady around here.


T

-- 
The problem with the world is that everybody else is stupid.

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 release, which they may or may not have time to do. IMHO, it really only makes sense to set up something automated.

How big is the chance that a newly added package isn't compatible with the recent version of DMD?
But yeah, I get your point of the problematic of having this not automated.

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 _every_ package then potentially needs to be tested (which could take a while), there's the issue of which versions to test. Testing every release of a package would be overkill, but simply testing the latest isn't necessarily enough.
>
> The initial setup will take a long time because we have so many packages that have never been tested in this way before.  But once the database is up-to-date, I expect that it will take much less work to keep things up-to-date.
>
> For the initial setup, I don't think it's necessary to test *every* historial release of the compiler -- the most important thing is the current official releases of all compilers (gdc, ldc, dmd).[*]  If a package doesn't compile with the latest release, then optionally do a unidirectional search backwards to find the last compiler version that compiles it successfully, and log that.

I pretty much assumed that we'd just start with the most recent compiler release, and then we'd only have to run anything for a given package when it did a new release or when a new version of the compiler was released. My point about versions was about which versions of a package to test. We don't necessarily want to just test the latest package version, but we also don't want to be testing every version of a package when a new compiler version comes out. I think that at some point here, some thought will have to go into what makes the most sense in that regard.

> ([*] 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 which of 50 dmd git revisions failed / succeeded to compile a package, just whether the *latest* dmd-nightly works.  So perhaps an update once a week or once a month in between releases will be enough.  But dmd-nightly is an optional extra that can be skipped for now.  The important baseline is the current official releases of gdc / ldc / dmd.)

My gut reaction is that we shouldn't include anything but actual dmd releases. As a developer of Phobos, I do often use the development version, but in general, I don't think that that's something that we should be encouraging the average user to do.

> > Also, there's the question of what it even means to test each package to verify that it's working. Does that mean running the unit tests? Not all projects run them the same way, and it could be pretty expensive to run the tests for all packages on code.dlang.org. And of course, that assumes that the package even has any unit tests to begin with. So, should testing the package just mean that dub build works? That will catch the really basic problems, but it won't usually catch problems in templates and could easily miss other types of problems - though maybe it's enough. Regardless, it's going to need to be made clear what it means that code.dlang.org claims that a package works with a particular version of the compiler.
>
> [...]
>
> Let's not overcomplicate things and doom the flight before it takes off. Let's start with the absolute minimum baseline, and then additional perks can be added on top of that once the baseline is working.
>
> I say the baseline is that dub build works.
>
> If we feel like going an extra mile, dub test.
>
> If we feel like doing even more, then add other stuff like compiling provided example programs, testing template instantiations and what-not. (Though one would expect that dub test ought to do that already, otherwise I question the quality of the code / unittests.)
>
> As long as we publish exactly what is being run to verify whether the package "works", I think that should be good enough for starters.  Even if dub build, say, doesn't catch all problems, it's still better than the status quo of no information at all.  Let's not let the perfect become the enemy of the good, as is the common malady around here.

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 approaches things is outright wrong. With dxml, I was forced to abandon dub test completely, because it broke anything that depended on dxml. As far as I can tell, what happens is that dub pulls in the dependencies and builds them all with dub build (so without stuff like -unittest), but then when you use dub test on your project, it stupidly uses all of the configuration options that the dub test configuration uses in the dependencies, meaning that anything that didn't get built with dub build wasn't there, and you got linker errors. I initially tried to fix it by versioning all unittest blocks and all unit test helpers with a version identifier specific to dxml's dub test build, but dub stupidly declared that version identifier when any project depending on dxml ran dub test, so you _still_ got linker errors. My conclusion was that the only sane thing to do was to completely abandon dub test and define a separate build type for running dxml's unit tests so that the version identifier could actually only be declared when building dxml's unit test build. The result is that dub test always passes but does absolutely nothing, which is really annoying, but I don't trust how dub test behaves farther than I can throw it, and it's currently my intention to never use it on any library I release ever. The whole thing really pisses me off.

So, anyway, I think that it's pretty clear that you can't rely on anything other than dub build working for a project, because that has to work for it function as a dub package, whereas none of the rest does.

Regardless, aside from pointing out that dub test is not a command that you can rely on working for dub packages in general, my point was really that we need to be sure of what we're trying to test here, and when we present it on code.dlang.org, it needs to be clear what it's indicating. If we were to decide that we wanted it to indicate some level of actual functionality, then we'd pretty much have to figure out how to run unit tests or to indicate the lack of unit testing, which creates a whole host of problems. On the other hand, if we just want to do dub build, we need to be clear that when code.dlang.org indicates that a project "passes," all that means is that dub build succeeds and that it doesn't actually say anything about how well the package works. Ideally, we want to present useful information that isn't misleading.

- Jonathan M Davis

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 approaches things is outright wrong.


Talking about `dub build`, is there a way to make it build dependencies but not link?


  "targetType": "staticLibrary"    <-- doesn't build any dependencies


  "dflags": ["-c"],
  "targetType": "executable"       <-- -c will get stripped off by DUB


On the other hand:
How big is the chance that building with the `syntaxOnly` option succeeds on a package that wouldn't actually build?


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

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 confusion.

(1) Problem no.1 is that one cannot build a package with targetType `sourceLibrary`.
(2) No.2 in order to circumvent that, one could just use this package as dependency in some dummy pacakge.
(3) Only targetType `executable` will make DUB build the dependencies of a package
(4) At the same time, DUB will always try to link the objects then, not passing through `-c` when specified as d-flag. Means, the "build" (the build itself works fine, of course) of all packages depending on non-available libs will fail (because DUB will exit with some linker error).


Kind regards,
Elias

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 everyone else(with rollback of course).

Dub simply determines if a package is broken by trying to compile it. When the package then compiles from being fixed by the user, dub can recognize that and push the changes automatically(by keeping track of the broken parts of the code and the changes).

This then allows fixes to accumulate by single users rather than everyone having to fix things themselves and requiring them to put in the effort to push the changes themselves.

99% of all these problems can be eliminated with a PROPERLY designed system. I would think that it would be the first thing on the table to do since without a properly designed system things just head towards chaos like they have. The sooner the PROPERLY designed system is created the sooner we all can benefit from such a PROPERLY designed system.

Look how much wasted time and energy this single thread has created just because of the improperly designed system. The problem is people need to get out of the dark ages and stop thinking like programmers from the 70's.  There are better away to do things, it just takes people wanting to do them and willing to spend the time to figure out the proper way. By making a design that reduces the burden on the user, the user will be more willing to contribute and will be able to contribute more and everyone will benefit.

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 bitcoin miner and sets fire to your cat?

If dub packages were scoped to a user, then you could fork a dub package more easily. Then the dub registry page for that package could contain both the information "this package doesn't compile with DMD > 2.65.0" and "this package has a more up-to-date fork that compiles with DMD > 2.068.0".

That means I can't hijack your project, which is good, but updating broken dependencies takes manual intervention, which is bad.

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 a package that doesn't compile anymore and submit a patch that adds a bitcoin miner and sets fire to your cat?

There are ways around this:

1. If the code is just a few lines and does not escape then it is marked safe and is safe.

This probably gets at least 50% of all patches because it is from a bug that is a few lines of code.

2. Require users to log in to be able to submit changes. Users must wait a week after registering to sub changes and can only submit so many changes per day.
They can submit more but they are flagged.

3. Commits to the end user side can be reviewed.

4. A forum thread is generated for each project with sub threads for each commit. These can be "rated" for how well they fix the problem by others and people can discuss them, sort of like bugzilla but better(more forum like).


5. large changes are automatically committed but are not automatically used. They must be marked as valid by the maintainer of the project or the community.


Basically your argument is that we should throw the baby out with the bath water because MAYBE the baby will grow up to be Hitler. Your logic is the same as cops who say "I should kill this guy now because MAYBE he has a gun" or any other insane thing that is a "MAYBE" but actually very unlikely.


Instead of assuming the most unlikely case, which is insane, it is better to assume the most likely case and then add in the necessary checks to deal with the unlikely cases.


Because, you know, I could download a dub package right now that does exactly what you just said, so it is really irrelevant. The only thing having dub automatically handle it all for you would do is give someone a little more incentive to try and make it happen that way. But seriously, do you think this would be a common attack vector for psychopaths?

When you make it 99.9999% likely they will be ineffective then who cares what they do. If it does happen, the chances are it will fail for various reasons. It it is probably 1 in a billion shot that they will create a patch that will be effective for what they want(to get your bank account, or whatever).

It's much more likely that other routes would be more effective and since psychopaths are only worried about being successful they are not going to waste their time with an attack vector that is almost surely not going to succeed.

Basically those that are in such a secure environment are also not going to make it easy(e.g., they will use a VM alternate OS, sandbox, etc).

Those that don't really care don't have much to lose so it wouldn't matter if the attacker was successful.

6. Users can define levels for automatically including code - 0 for automatic, all cases
1 - When patches do not escape
2 - When patches do not escape and are less than x KB or y lines.
3 - When forum rating > 10 people and 90%
...
X - Review all changes
Y - Ignore all
etc...

This way paranoid users can opt out. If, say, psychopaths do start using D to spread their insanity, then people can just switch to a more secure level and it will squash the problem quickly making it less an incentive for the attackers.


So, you see, there are plenty of solutions that can solve your hypothetical reason for squashing something that would be very practical.

There is absolutely no reason to throw the baby out... none! Don't allow it to turn in to a Hitler, it's not the babies fault, it's yours for what you teach it.

Meaning, there is no reason to not have dub automate everything as much as possible for hypothetical security concerns... Teach dub how to deal with them to a high enough degree that anyone attempting such things will be shut down quickly. It's not 100% but nothing is. After all, we are not even talking about something that hackers have ever used as an attack vector before... it's not even in the realm of what they are after(it's not just system control because most systems are useless).


> If dub packages were scoped to a user, then you could fork a dub package more easily. Then the dub registry page for that package could contain both the information "this package doesn't compile with DMD > 2.65.0" and "this package has a more up-to-date fork that compiles with DMD > 2.068.0".
>
> That means I can't hijack your project, which is good, but updating broken dependencies takes manual intervention, which is bad.

Yes, but if one just makes it a bit more intelligent one can solve the problem PROPERLY!

I'm not saying my solutions are what should be done because I'm just throwing out rough ideas. What I'm saying is that THERE IS A PROPER SOLUTION!

It would take people communicating in an organized and structured way to come up with that proper solution.

This means a group of people deciding that it should be done and that they will work together to solve the problem by coming up with the correct solution then coding that solution. It would take months, not days and it would involve a lot of people working together which requires organization to be effective. It can't be done on a forum like this.