logs archiveBotHelp.net / Freenode / #ada / 2015 / August / 17 / 1
Shark8
!Last
jk4
Lucretia: ada.cx doesn't exist
I see sparre informed you.
Lucretia
jk4: wake up
jk4: catch up
sparre
Shark8: 3M USD (https://en.wikipedia.org/wiki/GNAT)
Shark8: Roughly 15 man-years of experienced compiler builders is my guess.
Shark8
sparre: Ah, I see.
Heh, I wish I could have 3M USD to back my project ideas.
sparre
I agree that the GCC IR may have made the job harder, but I still think the 3M USD is a good approximation.
You may of course be able to skip the "Heart of Darkness" by putting that on the code-generation side of AIR, but you still have to implement all the compile-time checks and overload resolution.
Visaoni
shark8: and honestly, I'm not sure storing the IR actually helps that much with your goals. you'd need some way to force all equivalent subprograms to have the same IR
Shark8
Er, I did mention a canonical form, didn't I?
Visaoni
yes. I mean, that's even more work, and probably a good "hard" problem all by itself
sparre
Yes. Worse than optimising. ;-)
A simple "canonical form" can be done by a pretty printer, but anything beyond that is extremely difficult.
Some of it may be done for a few million USD. :-)
jk4
Lucretia: was busy finishing my math class!
i wonder if i can set my irc status with my calendar
Visaoni
Shark8: if you want to deal with dependency version automatically, or at least partially so, you could look at tokenizing the source and /trying/ to determine if it's changed
it'll probably have to be fairly primitive, but at least in some cases you should be able to see through things like name changes
and certainly formatting changes
Shark8
Visaoni: I don't think that would be useful... you should be able to add subprograms, tasks, and sub-packages w/o triggering a false positive.
Visaoni
I think you're going to have to accept lots of false positives
if you want to actually produce anything
false negatives are probably the best you can afford to not accept
otherwise you're honestly looking at proving source A acts exactly the same as source B
but the depedency can add things that don't matter.
Shark8
Why would you have to prove that they act the same? All you really need to do for that is ensure public-facing interface in only "added to". (Actually you could do some interesting things on overloading/defaults/signatures.)
Visaoni
keep track of what the package uses from the dependency, and if those things are the same (probably in a fairly trivial sense, but you could work on makingi t more sophisticated over time) in the new version of the dependency then you can accept the new version as compatible
because otherwise you can /very/ easily have a situation where the implementation changes and breaks programs using it, but you automatically mark them as fine
it's not just a matter of ensuring the new version allows the program to be built, but ensuring it still runs properly
sparre
(Action) would just build and test the packages/libraries/programs and see which compilers they work with. (But you've heard that before.)
Visaoni
it's probably the most realistic way of doing things
Shark8
No, it *IS* about ensuring that the program may be built; the "running properly" is outside the scope of the project... besides, "runs-properly" isn't something that can be done via VCS-style systems -- e.g. Function Random return Integer ....... Function Random Return integer is (4); is a perfectly valid body for the function.
Visaoni
there's no point in embarking on such a huge project just to save people the task of running make
Shark8
Something that ensures that the "runs properly" held would probably entail a massive test-suite and/or a SPARK-style prover.
Visaoni
if you wanted to prove it, but you could try to see if it would "run the same" and stick with that. again, wouldn't be perfect but you could at least deal with simple changes
Shark8
(And while I *do* like proven software, I think that requiring that as a qualifier for submitting a lib/project would kill it outright.)
Visaoni
I honestly see no point in this whole thing just to try to prove if a program can be built with a new version of a dependency. you still need testing before you can do anything with that knowledge
if your package manager automatically upgrades dependencies just because it's buildable, you're going to haev unhappy people
and if it doesn't automatically /do/ anything, then what's the point of it?
jk4
about 1% of people writing software have a clue about what proving anything means
Shark8
Visaoni: Question: Should the system ONLY keep the most recent version? (Of course not.) -- What ensuring that the public interface is compatible does is allows us to start with some version and [by default] use the latest version that's compatible w/ it. (Overridable, so you could say "DL v 1.1.3, exact.")
Visaoni
Shark8: Buildable != compatible
Shark8
Visaoni: Howso?
Visaoni
I can easily change the way a subprogram is implemented that will cause any program using it to behave improperly
just like your previous example - change a proper implementation for Function Random return Integer ... into Function Random return Integer is (4);
Shark8
That would be buildable and compilable.
Visaoni
yes, that doesn't mean it is compatible
Shark8
Behavior properties are something else altogether.
Visaoni
yes
I'm saying, without those behaviors being acceptable you can't do anything
if I'm maintaining some software, I'm not going to set it up to possibly break any time somebody upgrades a dependency it uses
in your system, I'd pin everything to a version I knew worked
Shark8
And that would be doable.
Visaoni
why would I want to deal with the headache of suddenly having it be broken, even though I hadn't touched anything in months? then I have to go look at what happened, and why
yes
I'm saying, there's not value - at all - in a system that automatically upgrades dependencies just because the result would compile
in fact, I think it has negative value
it's actively harmful
Shark8
Are you assuming that your compiler/environment would pull libs down automatically? `Cause I wasn't thinking that.
Natacha
except for when the behavior change is the fix a security flaw
Visaoni
even then Natacha. what if that breaks the program? much better to have some kind of alert system for that kind of problem
Natacha
AFAIK that's the main argument for automated environment upgrades
most admin' I know prefer spending time with a broken system than with a vulnerable one
Visaoni
I'd rather have a proper system to alert people to security issues
specing
Natacha: then how do you explain so many windows boxen out there?
then how do you explain people using >core2duo processors?
Visaoni
at least then I'd know there's a security problem, rather than things suddenly being broken and having to go figure out why etc
Natacha
the time between the alert firing and the human intervention is very valuable
Visaoni
Shark8: I was assuming the package manager would automatically pull down libs as needed. Not in the sense it would automatically update an environment, but that new users would find things broken
Natacha: perhaps, with an alert and the automatic upgrade being restricted to security issues that might be fine
Natacha
usually there is the automatic security upgrade, and only alerts when the thing is broken
but of course, that assumes proper monitoring in the first place
Shark8
Visaoni: Why? That would make your compiler/environment necessitate an internet connection.
Natacha
but no amount of software method can lower the need of proper monitoring anyway
Visaoni
SHhark8: Hm? Not the compiler/environment, but the package manager. What use is a package manager that knows about a dependency but can't fetch it for you, even though it has the code filed away somewhere?
Natacha: that's fair enough
Shark8
The dependency tracking stuff is all done on the server-side, the client (what I think you're thinking of) is just that, a client. It's behavior is, well, mostly undefined.
Visaoni
Shark8: I think we've gotten a bit sidetracked. My point is, being buildable is not a sufficient condition to declare a new version of a lib compatible with a given program.
Shark8
So?
Again, behavior modeling (proving and or testing) is beyond the scope of the project.
Natacha
So contracts \o/
Visaoni
So even if you know a program builds with the new version of the lib, you can't automatically mark the new version of the lib as compatible
So, what in the heck are you doing with this knowledge that the program builds with the new version? What's actually happening? What's the point?
Shark8
The point is that very often there are non-breaking changes to the library (e.g. additions to the interface) -- those should not automatically invalidate your ablity to use it.
Visaoni
Okay, but in order to do that you need to worry about the behavior of the library
Shark8
Again, ensuring behaviors is beyond the scope of the project.
Visaoni
in which case you need to accept that adding to the public interface does automatically invalidiate your ability to use it
you can't have it both ways
unless you wish to have a package manager that occasionally breaks things itself
Shark8
Ok, let's flip the question -- how would you ensure that behaviors remain unchanged?
Visaoni
well, the easiest and most brain-dead method is a simple source/source comparison
if the source hasn't changed for the parts of the library used by the program, then it's fine
Shark8
And what if this is a simple "better variable names" update?
Visaoni
then it'll detect changes when there are none
you could try tracking returned (and out parameters) values and see if you could do things like get past changes to variable names
Shark8
And how eould that be useful? It would be like these version-control systems that flag meaningless whitespace alterations.
Visaoni
you could strip whitespace and things first, and have enough language awareness to identify blocks that represent a subprogram
« prev 1 2 next »