10000 Makes it possible to use env(1) to run scala scripts, by dcsobral · Pull Request #9 · scala/scala · GitHub
[go: up one dir, main page]
Skip to content

Makes it possible to use env(1) to run scala scripts, #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Dec 1, 2011
Merged

Makes it possible to use env(1) to run scala scripts, #9

merged 1 commit into from
Dec 1, 2011

Conversation

dcsobral
Copy link
Contributor
@dcsobral dcsobral commented Dec 1, 2011

by dropping the requirement of a !# line when using env. This is how some other
languages, such as ruby, are run.

Typical usage:

#!/usr/bin/env scala
println("Hello, "+args(0)+"!")

Contributed by: Daniel C. Sobral

@dcsobral
Makes it possible to use env(1) to run scala scripts, by dropping
8b8ed99 
the requirement of a !# line when using it. This is how some other
languages, such as ruby, are run.

Typical usage:

    #!/usr/bin/env scala
    println("Hello, "+args(0)+"!")

Contributed by: Daniel C. Sobral
@paulp paulp merged commit 8b8ed99 into scala:master Dec 1, 2011
odersky added a commit to odersky/scala that referenced this pull request Jul 14, 2012
@odersky
Attempt scala#9 to opimize findMember.
3993376 
Also avoid recomputation of memberType in findMembers
adriaanm referenced this pull request in adriaanm/scala Jul 14, 2012
@odersky
Attempt #9 to opimize findMember.
fcb0c01 
Also avoid recomputation of memberType in findMembers
retronym referenced this pull request in retronym/scala Jun 26, 2013
@retronym
SI-7475 Pay the duplication tax for findMember/findMembers
cc6a3c9 
Swathes of important logic are duplicated between `findMember`
and `findMembers` after this run of optimization.

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in reflection. Also fixed test case that failed when moving to findMember
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This commit updates `findMembers` with the bug fixes that `findMember`
has received, and adds flashing warning signs for future maintainers.

A followup commit will address the duplication at the root.
@adriaanm adriaanm mentioned this pull request Aug 14, 2013
Closed
retronym referenced this pull request in retronym/scala Jan 29, 2014
@retronym
SI-7475 Private members are not inheritable
c5ed740 
Exclude them from superclasses in `findMember` and in
`OverridingPairs`.

The odd logic in `findMember` that considered whether the
selector class was owned by the owner of the candidate private
symbol dates back to 2007 (bff4268), but does not appear to
have any relationship to the spec.

Refinement types are still able to inherit private members from
all direct parents, as was needed in pos/t2399.scala. More tests
are included for this scenario.

In short, the logic now:

 - includes direct parents of refinements,
 - otherwise, excludes privates after the first class in the
   base class sequence

TODO: Swathes of important logic are duplicated between `findMember`
and `findMembers` after this run of optimization.

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in reflection. Als
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember
retronym referenced this pull request in retronym/scala Jan 31, 2014
@retronym
SI-7475 findMember and findMembers: estranged no more
0813dd3 
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This didn't actually bear fruit, and the intervening years have
seen the implementations drift.

Now is the time to reunite them under the banner of `FindMemberBase`.

Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.

While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.

Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.

Coming up next: we can actually fix SI-7475!
retronym referenced this pull request in retronym/scala Jan 31, 2014
@retronym
SI-7475 findMember and findMembers: estranged no more
dd5a685 
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This didn't actually bear fruit, and the intervening years have
seen the implementations drift.

Now is the time to reunite them under the banner of `FindMemberBase`.

Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.

While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.

Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.

Coming up next: we can actually fix SI-7475!
retronym referenced this pull request in retronym/scala Jan 31, 2014
@retronym
SI-7475 findMember and findMembers: estranged no more
239e318 
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This didn't actually bear fruit, and the intervening years have
seen the implementations drift.

Now is the time to reunite them under the banner of `FindMemberBase`.

Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.

While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.

Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.

Coming up next: we can actually fix SI-7475!
retronym referenced this pull request in retronym/scala Feb 6, 2014
@retronym
SI-7475 findMember and findMembers: estranged no more
8b29ecc 
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This didn't actually bear fruit, and the intervening years have
seen the implementations drift.

Now is the time to reunite them under the banner of `FindMemberBase`.

Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.

While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.

Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.

Coming up next: we can actually fix SI-7475!
retronym added a commit that referenced this pull request Feb 12, 2014
@retronym @adriaanm
SI-7475 findMember and findMembers: estranged no more
aebe379 
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This didn't actually bear fruit, and the intervening years have
seen the implementations drift.

Now is the time to reunite them under the banner of `FindMemberBase`.

Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.

While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.

Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.

Coming up next: we can actually fix SI-7475!
adriaanm added a commit that referenced this pull request Mar 28, 2014
@adriaanm
#9 try to avoid double slashes in url
5997e32
retronym referenced this pull request in retronym/scala May 7, 2014
@adriaanm
Merge pull request #9 from adriaanm/snapshot
ae10b8e 
Validate against 2.11.0-SNAPSHOT
retronym added a commit that referenced this pull request Feb 5, 2015
@retronym
Merge pull request #9 from som-snytt/review/6502
c6c9565 
SI-6502 Convert test to asserts
retronym added a commit that referenced this pull request Aug 6, 2015
@retronym
SI-9425 Leave Companion.apply if constructor is less accessible
f5dc96b 
Calls to synthetic case class apply methods are inlined to the
underlying constructor invocation in refchecks.

However, this can lead to accessibility errors if the constructor
is private.

This commit ensures that the constructor is at least as accessible
as the apply method before performing this tranform.

I've manually checked that other the optimization still works in other
cases:

scala> class CaseApply { Some(42)  }
defined class CaseApply

    scala> :javap -c CaseApply
    Compiled from "<console>"
    public class CaseApply {
      public CaseApply();
        Code:
           0: aload_0
           1: invokespecial #9                  // Method java/lang/Object."<init>":()V
           4: new           #11                 // class scala/Some
           7: dup
           8: bipush        42
          10: invokestatic  #17                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
          13: invokespecial #20                 // Method scala/Some."<init>":(Ljava/lang/Object;)V
          16: pop
          17: return
    }
@scabug scabug mentioned this pull request Apr 7, 2017
Closed
smarter pushed a commit to smarter/scala that referenced this pull request Apr 11, 2017
@DarkDimius
Merge pull request scala#9 from smarter/proc-syntax
6ce804d 
Rewrite usages of procedure syntax
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dcsobral @paulp
0