2.9.2 vs. 2.10.0: the commandlinening

Re: [scala-language] Can composing N (say 20) polymorphic functions take time exponential in N (say 80s) to compile?

[moved to -internals]

On Mon, Jul 2, 2012 at 6:21 AM, Josh Suereth
<joshua.suereth@...> wrote:
> Not quite.  We don't have a plan for when a 2.9.3 would occur yet.  I'll
> take a look at what it's acquired and bring up the idea at our next meeting.

I'd still like to take advantage of tree attachments to get rid of the
subclasses of Apply [1]. They aren't correctly handled during tree
duplication, and using attachments would be much cleaner.

To keep source compatibility for the IDE, we could try to provide
provide extractors in 2.10 to mimic the removed case classes. But if
that didn't work out, we might need to backport a few new methods
(e.g. Apply#isConstructor) to 2.9.3. I believe a similar release of
2.8 was made shortly after 2.9 came out.

-jason

https://github.com/retronym/scala/commit/17d8618

Closing issues

I'm trying to compile a list of tickets closed on HEAD, but the
irregularity of the messages is making that very hard.

Right now, many are closing issues like this:

SI-NNNN Description

Etc...

The problem with that is that sometimes the messages are like this:

      Pending test for SI-5008.
      Pending test for SI-4649.

And, of course, not everyone is following the above style anyway. For example:

    Closes t5399. Review by adriaanm

That's a very recent one, so it's relevant.

Besides tNNNN, there's also #NNNN and issue/NNNN, and full URLs!
Speaking of URLs, here are two different bodies from recent commits:

    adds `narrow` to the reflection API

    as per https://issues.scala-lang.org/browse/SI-5951

and

    TypeTag => AbsTypeTag, ConcreteTypeTag => TypeTag

    This protects everyone from the confusion caused by stuff like this:
    https://issues.scala-lang.org/browse/SI-5884

The first seems to be fixing the issue, the second seems not to be
fixing the issue. If I have to guess as a human, no script in the
world is ever going to tell them apart.

Here are some other formats that are _almost_ easy to retrieve by script:

    Fix SI-5846 and SI-4027.

    Closes SI-4482, SI-4651, SI-3702.

    fix for SI-4935

   Also fixes SI-5967, which shows up during pattern matching.

The first two have multiple issues following the close/fix word. Not
much of a problem, unless people come up with more ways to do the same
thing. The second is more difficult, because the word "fix" happens in
many places, and a "SI-NNNN" later in the same line does not always
mean it is being fixed. I have seen such a case. The last one is not
particularly difficult either, except that all that context around
"fix SI-5967" can be problematic. For instance, it could be "does not
fix SI-5967".

So, if you'd like to be able to extract fixes from git logs, I suggest
"(Fix(es)?|Closes?) SI-NNNN, SI-NNNN..." to be added to a line all by
itself on your commit logs.

If anyone (like Josh) is interested, here's what I'm doing for now:

git log v2.9.2..HEAD  --no-merges -i -E --grep "(^
*SI-[0-9]{2,5})|(close|fix)[a-z]*  *(for  *)?(si-|#|t|issue|http[^
]*\/)[^ 0-9]*[0-9]{2,5}\b" | tr 'A-Z' 'a-z' | sed -nEf filter.sed |
sort -u -n > fixed.txt
git log v2.9.2  --no-merges -i -E --grep "(^
*SI-[0-9]{2,5})|(close|fix)[a-z]*  *(for  *)?(si-|#|t|issue|http[^
]*\/)[^ 0-9]*[0-9]{2,5}\b" | tr 'A-Z' 'a-z' | sed -nEf filter.sed |
sort -u -n > backported.txt
grep -x -f backported.txt -v fixed.txt > newlyfixed.txt

Content of filter.sed:

/^ *si-[0-9]{2,5}/ s/^ *si-([0-9]{2,5}\b).*/\1/p
/close|fix/ {
	s/.*(close|fix)[a-z]* +(for +)?(((si-|#|t|issue|http[^ ]*\/)[^
0-9]*[0-9]{2,5}\b( *, *| *and *)?)+).*/\3/
	Tnomatch
	s/,/ /g
	s/[^ 0-9]//g
	s/^\s+|\s+$//g
	s/\s+/\n/g
	p
	:nomatch
}

Yeah, I know. :-/ And 404 on the result is incorrect (the sole URL
caught incorrectly by this).

--

-- 
Daniel C. Sobral

I travel to the future all the time.

Re: Closing issues

Re: Closing issues

Re: Closing issues

Re: Closing issues

The style you recommend is not that easy to filter automatically.
Git's --grep goes over the whole body. Granted, we can then limit
output to the title, which will automatically skip anything else.
Still, any standard is better than no standard.

Now, I'm not asking for any enforcement to be applied. I'm just
calling attention to people that, if they'd like the tickets they
closed to be found by script for any purpose (automatic closing,
statistics, release notes, repo-archeology, etc), they should pay some
attention to how they write their commit messages.

On Mon, Jul 2, 2012 at 1:35 PM, Adriaan Moors <adriaan.moors@...> wrote:
> Hi Daniel,
>
> Excellent, thanks for this!
>
> The PRP recommends a uniform title format, and I think we should start
> enforcing it.
>
> https://github.com/scala/scala/wiki/Pull-Request-Policy
>
> I'd suggest dropping the fixes/closes/... prefix because it's redundant and
> commit titles must be short.
>
> If a commit merely references a ticket, and not closes it, the commit title
> should not reference it.
>
>
> cheers
> adriaan
>
> On Mon, Jul 2, 2012 at 6:19 PM, Daniel Sobral <dcsobral@...> wrote:
>>
>> I'm trying to compile a list of tickets closed on HEAD, but the
>> irregularity of the messages is making that very hard.
>>
>> Right now, many are closing issues like this:
>>
>> SI-NNNN Description
>>
>> Etc...
>>
>> The problem with that is that sometimes the messages are like this:
>>
>>       Pending test for SI-5008.
>>       Pending test for SI-4649.
>>
>> And, of course, not everyone is following the above style anyway. For
>> example:
>>
>>     Closes t5399. Review by adriaanm
>>
>> That's a very recent one, so it's relevant.
>>
>> Besides tNNNN, there's also #NNNN and issue/NNNN, and full URLs!
>> Speaking of URLs, here are two different bodies from recent commits:
>>
>>     adds `narrow` to the reflection API
>>
>>     as per https://issues.scala-lang.org/browse/SI-5951
>>
>> and
>>
>>     TypeTag => AbsTypeTag, ConcreteTypeTag => TypeTag
>>
>>     This protects everyone from the confusion caused by stuff like this:
>>     https://issues.scala-lang.org/browse/SI-5884
>>
>> The first seems to be fixing the issue, the second seems not to be
>> fixing the issue. If I have to guess as a human, no script in the
>> world is ever going to tell them apart.
>>
>> Here are some other formats that are _almost_ easy to retrieve by script:
>>
>>     Fix SI-5846 and SI-4027.
>>
>>     Closes SI-4482, SI-4651, SI-3702.
>>
>>     fix for SI-4935
>>
>>    Also fixes SI-5967, which shows up during pattern matching.
>>
>> The first two have multiple issues following the close/fix word. Not
>> much of a problem, unless people come up with more ways to do the same
>> thing. The second is more difficult, because the word "fix" happens in
>> many places, and a "SI-NNNN" later in the same line does not always
>> mean it is being fixed. I have seen such a case. The last one is not
>> particularly difficult either, except that all that context around
>> "fix SI-5967" can be problematic. For instance, it could be "does not
>> fix SI-5967".
>>
>> So, if you'd like to be able to extract fixes from git logs, I suggest
>> "(Fix(es)?|Closes?) SI-NNNN, SI-NNNN..." to be added to a line all by
>> itself on your commit logs.
>>
>> If anyone (like Josh) is interested, here's what I'm doing for now:
>>
>> git log v2.9.2..HEAD  --no-merges -i -E --grep "(^
>> *SI-[0-9]{2,5})|(close|fix)[a-z]*  *(for  *)?(si-|#|t|issue|http[^
>> ]*\/)[^ 0-9]*[0-9]{2,5}\b" | tr 'A-Z' 'a-z' | sed -nEf filter.sed |
>> sort -u -n > fixed.txt
>> git log v2.9.2  --no-merges -i -E --grep "(^
>> *SI-[0-9]{2,5})|(close|fix)[a-z]*  *(for  *)?(si-|#|t|issue|http[^
>> ]*\/)[^ 0-9]*[0-9]{2,5}\b" | tr 'A-Z' 'a-z' | sed -nEf filter.sed |
>> sort -u -n > backported.txt
>> grep -x -f backported.txt -v fixed.txt > newlyfixed.txt
>>
>> Content of filter.sed:
>>
>> /^ *si-[0-9]{2,5}/ s/^ *si-([0-9]{2,5}\b).*/\1/p
>> /close|fix/ {
>>         s/.*(close|fix)[a-z]* +(for +)?(((si-|#|t|issue|http[^ ]*\/)[^
>> 0-9]*[0-9]{2,5}\b( *, *| *and *)?)+).*/\3/
>>         Tnomatch
>>         s/,/ /g
>>         s/[^ 0-9]//g
>>         s/^\s+|\s+$//g
>>         s/\s+/\n/g
>>         p
>>         :nomatch
>> }
>>
>> Yeah, I know. :-/ And 404 on the result is incorrect (the sole URL
>> caught incorrectly by this).
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>

--

-- 
Daniel C. Sobral

I travel to the future all the time.

Re: Closing issues

Re: Closing issues

Re: Closing issues