At one point that was intentional (and we even specifically had the experimental warning in there and everything)... but it's true, nowadays, it's primarily annoying :-).
1 reply
hmm I mean.. that would be a super easy solution: Just make it a comment :D
Haha, well that would work. but then it would look as a part of the file (it's not).
I mean, similarly to the error thing: the CLI is generally not primarily meant to be what produces machine-readable output anyways... look at what
--bin and --bin-runtime (especially taken together) do...
1 reply
Machine-consumption is expected to use standard-json.
Of course a bit annoying for classic piping :-).
cameel: my initial reaction to those python assert PRs would have been the same as yours, but https://github.com/ethereum/solidity/pull/13383#issue-1335799140 I actually wasn't aware of and it does in fact seem a bit weird :-D.
(that's why I assigned you, since based on that I wasn't sure about it :-))
Not that python optimization stuff is something that is relevant for those CI scripts.
Ah, ok, now you closed both, then it's fine :-).
In Python you can technically disable asserts, just like in C++. It's just that in Python there's no binary so you have to select that optimized mode when you run the script.
And it's not the default.
And it's not the default.
So in practice they're always there.
Yeah, sure, what I meant is that I actually found it surprising that those assertions can vanish :-). But yeah, https://github.com/ethereum/solidity/pull/13383#issuecomment-1212160463 is a good point and even if it wasn't there's no call to ever "compile" those scripts anyways.
Well, you could compile them to bytecode and run that without having the source.
I think that this would then persist.
But no one does that. At least not with open source stuff.
I know that Arch includes compiled bytecode in packages along with sources.
But that's only because source dirs are not writable so Python would not be able to generate it on the fly.
So you'd get bytecode compilation on every run.
I'm done for today and because of all the small stuff didn't manage to get to the labels yet. I'm going to work on that tomorrow morning so that we can have a call in the afternoon.
Actually, I do have a very crude initial idea. Maybe I'll just paste that into a note so that you can have a look now. It's still incomplete and will change.
I still don't know how to make these notes owned by the org public though :)
Can you read it?
I actually have a dedicated browser to keep logged into the org account solely for reading these things :-D. So yeah, I can read it :-).
And at a first glance, it does look nice - but I'll have a closer look and we can chat tomorrow :-).
Just one note: it gets hairy when you try to go into details but my overall impression after thinking about it was that maybe even just having the effort+impact combo would improve filtering a lot :) Maybe with a help of some
controversial label to filter out proposals we have mixed feeling about and are unlikely to implement.
Yeah, may be... Unfortunately,
Effort is often the hardest thing to judge in advance :-).
We may need "Effort: unknown" :-D.
That's why it can't be very precise but it's still useful to know if this is a multi-stage feature or a one-line change.
We could have
We could have
unknown but I suspect that a lot of the time it will be just a code for high :)
I'll try to think of some ways to describe it other than
low and high. Maybe that will make it easier to assign.
Yeah, the problem is often that once you actually know how much effort it is, you're also basically done :-D. But yeah, let's talk tomorrow, don't want to keep you here, if you wanted to finish up for today ;-).
"need" is such a strong word
I mean, one may think about that what one wants, but there are people with spaces in their paths :-).
Not sure if such theoretical people should run a release script, though :-D.
abc=test this
zsh: command not found: this
zsh: command not found: this
Yeah... or
$ source "a b/test"
$ source a b/test
bash: a: No such file or directory
$ export TEST="a b/test"
$ source "$TEST"
$ source $TEST
bash: a: No such file or directory