summaryrefslogtreecommitdiff
path: root/src/repl
Commit message (Collapse)AuthorAgeFilesLines
...
* SI-8415 Exception handling in REPL initSom Snytt2014-03-153-4/+15
| | | | | | | | Incremental robustness, and probe for typer phase. The probe would be unnecessary if repl contributed a terminal phase that "requires" whatever it needs; that is checked when the Run is built.
* SI-8370 fixes an infinite loop in repl initEugene Burmako2014-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under a weird coincidence of circumstances provided by `sbt console-quick`, new XML parsing logic in compiler plugin initialization could lead to stack overflow errors. Here's the abridged sequence events that led to this unfortunate problem (full description can be found on the JIRA issue page): 1) Initialization of the compiler underlying the REPL would kick off plugin initialization. 2) PluginDescription.fromXML would call into DocumentBuilderFactory, i.e. DocumentBuilderFactory.newInstance.newDocumentBuilder.parse(xml). 3) That thing would call into javax.xml.parsers.SecuritySupport.getResourceAsStream, requesting META-INF/services/javax.xml.parsers.DocumentBuilderFactory. 4) That request would get serviced by TranslatingClassLoader provided by the REPL to expose dynamically compiled code. 5) TranslatingClassLoader would call translatePath that would call into IMain.symbolOfIdent trying to map the requested resource onto one of the classes defined by the REPL (which don't exist yet, because REPL hasn't yet finished initializing). 6) IMain.symbolOfIdent would request IMain.global, which is exactly the instance of the compiler that underlies the REPL, and that's currently being initialized. 7..inf) Repeat until a StackOverflowError.
* some renamingsEugene Burmako2014-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It’s almost 1am, so I’m only scratching the surface, mechanistically applying the renames that I’ve written down in my notebook: * typeSignature => info * declarations => decls * nme/tpnme => termNames/typeNames * paramss => paramLists * allOverriddenSymbols => overrides Some explanation is in order so that I don’t get crucified :) 1) No information loss happens when abbreviating `typeSignature` and `declarations`. We already have contractions in a number of our public APIs (e.g. `typeParams`), and I think it’s fine to shorten words as long as people can understand the shortened versions without a background in scalac. 2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would be thoughtful of us to provide newcomers with better names. To offset the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor` to `Symbol.isConstructor`, which covers the most popular use case for nme’s. 3) I also agree that putting `paramss` is a lot to ask of our users. The double-“s” convention is very neat, but let’s admit that it’s just weird for the newcomers. I think `paramLists` is a good compromise here. 4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful and a shorter name would be a much better fit for the public API.
* establishes scala.reflect.api#internalEugene Burmako2014-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Reflection API exhibits a tension inherent to experimental things: on the one hand we want it to grow into a beautiful and robust API, but on the other hand we have to deal with immaturity of underlying mechanisms by providing not very pretty solutions to enable important use cases. In Scala 2.10, which was our first stab at reflection API, we didn't have a systematic approach to dealing with this tension, sometimes exposing too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing too little (e.g. there's still no facility to change owners, to do typing transformations, etc). This resulted in certain confusion with some internal APIs living among public ones, scaring the newcomers, and some internal APIs only available via casting, which requires intimate knowledge of the compiler and breaks compatibility guarantees. This led to creation of the `internal` API module for the reflection API, which provides advanced APIs necessary for macros that push boundaries of the state of the art, clearly demarcating them from the more or less straightforward rest and providing compatibility guarantees on par with the rest of the reflection API. This commit does break source compatibility with reflection API in 2.10, but the next commit is going to introduce a strategy of dealing with that.
* SI-6732 deprecates internal#Symbol.isPackageEugene Burmako2014-02-141-1/+1
| | | | | | | | This is the first step in disentangling api#Symbol.isPackage, which is supposed to return false for package classes, and internal#Symbol.isPackage, which has traditionally being used as a synonym for hasPackageFlag and hence returned true for package classes (unlike isModule which is false for module classes).
* SI-7933 REPL javax.script eval is cached resultRaphael Jolly2014-01-311-17/+10
| | | | | | | The problem is that the repl underneath the script engine evaluates input to val res0..resN, so it is a one shot operation. To allow repetition, compile(script) now returns a CompiledScript object whose eval method can be called any number of times.
* SI-8107: Use Regex.quoteChristoffer Sawicki2013-12-292-7/+6
|
* SI-8027 REPL double tab regressionSom Snytt2013-12-031-3/+2
| | | | | | | | | | | | | | | | | | Where did double tab go? "The shadow knows." The regression was introduced by the last flurry before we were left to wallow in whatever white space remained. Some xs put other xs under erasure. It's clear that somebody's daughter walked into the room and asked for a story, because, shockingly, the case arrows don't line up. We need a plug-in for Jenkins, or I guess Travis, to fail the build if arrows and equals don't align, because it clearly indicates a lapse of some kind.
* Merge pull request #3147 from som-snytt/issue/repl-columnsAdriaan Moors2013-11-254-14/+126
|\ | | | | SI-7969 REPL -C columnar output
| * SI-7969 REPL variable columnar outputSom Snytt2013-11-182-10/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend column formatting to make columns only as wide as their widest element. This is similar to what `ls` does. Given the longest and shortest string, which bound the min and max column count, compute the layout for those possible column counts, and choose the minimal row count and minimal column count. The junit test is under pending because it uses expecty. (Edit: updated without expectytations.) Example that really benefits, witness the skinny columns: ``` scala> math. BigDecimal PartiallyOrdered cosh rint BigInt Pi exp round E ScalaNumber expm1 signum Equiv ScalaNumericAnyConversions floor sin Fractional ScalaNumericConversions hypot sinh IEEEremainder abs log sqrt Integral acos log10 tan LowPriorityEquiv asin log1p tanh LowPriorityOrderingImplicits atan max toDegrees Numeric atan2 min toRadians Ordered cbrt package ulp Ordering ceil pow PartialOrdering cos random ``` more
| * SI-7969 Refactor to trait with testSom Snytt2013-11-152-20/+31
| | | | | | | | Make REPL classes testable in junit. Test the Tabulator.
| * SI-7969 REPL -C columnar outputSom Snytt2013-11-144-11/+58
| | | | | | | | | | | | | | | | | | | | | | | | Let `ConsoleReaderHelper.printColumns` print in a vertical orientation (similar to `ls -C`) instead of horizontally (`ls -x`). To support the old behavior, add a property `-Dscala.repl.format=across` where "across" is the presumptive mnemonic for `-x`. The format property also takes value `paged` to turn on pagination, which currently forces single-column output (as does `ls | more`) for simplicity.
* | Merge pull request #3152 from paulp/pr/deprecationsJason Zaugg2013-11-221-1/+2
|\ \ | | | | | | Removing deprecated code.
| * | Removing deprecated code.Paul Phillips2013-11-181-1/+2
| |/ | | | | | | | | Code which has been deprecated since 2.10.0 and which allowed for straightforward removal.
* / deprecate Pair and TripleDen Shabalin2013-11-201-1/+1
|/
* SI-7747 Support class based wrappers clean upSom Snytt2013-11-104-74/+55
| | | | | | | | | | | | | | | | | | | | | | | | | Simplified the code paths to just use one of two `Wrapper` types for textual templating. Simplified the class-based template to use the same `$iw` name for the both the class and the wrapper value. In addition, the $read value is an object extending $read, instead of containing an extra instance field, which keeps paths to values the same for both templates. Both styles trigger loading the value object by referencing the value that immediately wraps the user code, although for the class style, inner vals are eager and it would suffice to load the enclosing `$read` object. The proposed template included extra vals for values imported from history, but this is not necessary since such an import is always a stable path. (Or, counter-example to test is welcome.) The test for t5148 is updated as a side effect. Probably internal APIs don't make good test subjects. Modify -Y option message.
* SI-7747 Support class based wrappers as alternative through switch ↵Prashant Sharma2013-11-104-14/+75
| | | | | | | | -Yrepl-class-based Refactoring to reduce the number of if-else Fix test.
* Collections library tidying and deprecation. Separate parts are listed below.Rex Kerr2013-11-071-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Collections library tidying, part one: scripting. Everything in scala.collection.scripting is deprecated now, along with the << method that is implemented in a few other classes. Scripting does not seem used at all, and anyone who did can easily write a wrapper that does the same thing. Deprecated *Proxy collections. The only place proxies were used in the library was in swing.ListView, and that was easy to change to a lazy val. Proxy itself is used in ScalaNumberProxy and such, so it was left undeprecated. Deprecated Synchronized* traits from collections. Synchronizability does not compose well, and it requires careful examination of every method (which has not actually been done). Places where the Scala codebase needs to be fixed (eventually) include: scala.reflect.internal.util.Statistics$QuantMap scala.tools.nsc.interactive.Global (several places) Deprecated LinkedList (including Double- and -Like variants). Interface is idiosyncratic and dangerously low-level. Although some low-level functionality of this sort would be useful, this doesn't seem to be the ideal implementation. Also deprecated the extractFirst method in Queue as it exposes LinkedList. Cannot shift internal representations away from LinkedList at this time because of that method. Deprecated non-finality of several toX collection methods. Improved documentation of most toX collection methods to describe what the expectation is for their behavior. Additionally deprecated overriding of - toIterator in IterableLike (should always forward to iterator) - toTraversable in TraversableLike (should always return self) - toIndexedSeq in immutable.IndexedSeq (should always return self) - toMap in immutable.Map (should always return self) - toSet in immutable.Set (should always return self) Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since for some odd reason immutable.Range overrides those. Deprecated Forwarders from collections. Forwarding, without an automatic mechanism to keep up to date with changes in the forwarded class, is inherently unreliable. Absent a mechanism to keep current, they're deprecated. ListBuffer is the only class in the collections library that uses forwarders, and that functionality can be rolled into ListBuffer itself. Deprecating immutable set/map adaptors. They're a bad idea (barring compiler support) for the same reason that all the other adaptors are a bad idea: they get out of date and probably have a variety of performance bugs. Deprecated inheritance from leaf classes in immutable collections. Inheriting from leaf-classes in immutable collections is rarely a good idea since whenever you use any interesting collections method you'll revert to the original class. Also, the methods are often designed to work with only particular behavior, and an override would be difficult (at best) to make work. Fortunately, people seem to have realized this and there are few to no cases of people extending PagedSeq and TreeSet and the like. Note that in many cases the classes will become sealed not final. Deprecated overriding of methods and inheritance from various mutable collections. Some mutable collections seem unsuited for overriding since to override anything interesting you would need vast knowledge of internal data structures and/or access to private methods. These include - ArrayBuilder.ofX classes. - ArrayOps - Some methods of BitSet (moved others from private to protected final) - Some methods of HashTable and FlatHashTable - Some methods of HashMap and HashSet (esp += and -= which just forward) - Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet) - PriorityQueue - UnrolledBuffer This is a somewhat aggressive deprecation, the theory being better to try it out now and back off if it's too much than not attempt the change and be stuck with collections that can neither be safely inherited nor have implementation details changed. Note that I have made no changes--in this commit--which would cause deprecation warnings in any of the Scala projects available on Maven (at least as gathered by Adriaan). There are deprecation warnings induced within the library (esp. for classes/traits that should become static) and the compiler. I have not attempted to fix all the deprecations in the compiler as some of them touch the IDE API (but these mostly involved Synchronized which is inherently unsafe, so this should be fixed eventually in coordination with the IDE code base(s)). Updated test checks to include new deprecations. Used a higher level implementation for messages in JavapClass.
* Merge pull request #3042 from gourlaysama/t7634-repl-sh-is-brokenAdriaan Moors2013-11-071-1/+1
|\ | | | | SI-7634 resurrect the REPL's :sh command
| * SI-7634 resurrect the REPL's :sh commandAntoine Gourlay2013-11-061-1/+1
| | | | | | | | | | | | ProcessResult had a companion object in 2.10 that somehow disappeared in 2.11. It only called "new ProcessResult(...)", so the REPL might just as well do that.
* | Add a skeletal Delambdafy phase.James Iry2013-11-011-1/+2
|/ | | | | | This commit adds a do-nothing phase called "Delambdafy" that will eventually be responsible for doing the final translation of lambdas into classes.
* macro bundles are now usable in replEugene Burmako2013-10-021-4/+6
| | | | | | | | | | | | | | | | | | | | | | One of the previous commits relaxed the top-level restriction for bundles, turning it into a requirement of staticness (i.e. bundles nested in static objects are also okay now). This means that we can now define bundles in repl. Almost. There's still a little problem remaining that arises from the fact that when compiling a line of input, repl doesn't automatically import all previously defined symbols, but rather uses an heuristic to scan the input and guess what symbols need to be imported. Unfortunately for bundles, this heuristic fails, because when scanning a macro definition that looks like `def foo = macro Macros.foo`, it thinks that it's only necessary to import a term symbol called Macros (a vanilla way of defining macro impls), but not a type symbol called Macros (a new way of writing macro impls in bundles). This commit fixes the problem by making the repl look for both term and type symbols corresponding to the identifiers used in macro definitions.
* Removing unused code.Paul Phillips2013-10-027-47/+2
| | | | | | | Most of this was revealed via -Xlint with a flag which assumes closed world. I can't see how to check the assumes-closed-world code in without it being an ordeal. I'll leave it in a branch in case anyone wants to finish the long slog to the merge.
* Updating Position call sites.Paul Phillips2013-09-271-1/+1
| | | | | | Calling position factories rather than instantiating these particular classes. Not calling deprecated methods. Added a few position combinator methods.
* Cull extraneous whitespace.Paul Phillips2013-09-182-10/+3
| | | | | | | | | | | | | | | | | | | | | One last flurry with the broom before I leave you slobs to code in your own filth. Eliminated all the trailing whitespace I could manage, with special prejudice reserved for the test cases which depended on the preservation of trailing whitespace. Was reminded I cannot figure out how to eliminate the trailing space on the "scala> " prompt in repl transcripts. At least reduced the number of such empty prompts by trimming transcript code on the way in. Routed ConsoleReporter's "printMessage" through a trailing whitespace stripping method which might help futureproof against the future of whitespace diseases. Deleted the up-to-40 lines of trailing whitespace found in various library files. It seems like only yesterday we performed whitespace surgery on the whole repo. Clearly it doesn't stick very well. I suggest it would work better to enforce a few requirements on the way in.
* Corrects behavior of finalResultType.Paul Phillips2013-09-131-1/+1
| | | | | | | | | | | | The implementation had come to depend on finalResultType accidentally doing things beyond its charter - in particular, widening types. After hunting down and fixing the call sites depending on the bugs, I was able to rewrite the method to do only what it's supposed to do. I threw in a different way of writing it entirely to suggest how some correctness might be obtained in the future. It's a lot harder for a method written like this to break.
* SI-7805 REPL -i startupSom Snytt2013-09-061-1/+1
| | | | | | | | | Tested with a ReplTest that loads an include script. ReplTests can choose to be `Welcoming` and keep a normalized welcome message in their check transcript. One recent SessionTest is updated to use the normalizing API.
* SI-7781 REPL stack trunc shows causeSom Snytt2013-09-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The handy stack trace truncation in REPL doesn't show cause like a regular trace. This commit fixes that and also adds the usual indicator for truncation, viz, "... 33 more". The example from the ticket produces: ``` scala> rewrapperer java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: Point of failure at .rewrapper(<console>:9) at .rewrapperer(<console>:10) ... 32 elided Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Point of failure at .wrapper(<console>:8) ... 34 more Caused by: java.lang.RuntimeException: Point of failure at .sample(<console>:7) ... 35 more ``` Suppressed exceptions on Java 7 are handled reflectively. ``` java.lang.RuntimeException: My problem at scala.tools.nsc.util.StackTraceTest.repressed(StackTraceTest.scala:56) ... 27 elided Suppressed: java.lang.RuntimeException: Point of failure at scala.tools.nsc.util.StackTraceTest.sample(StackTraceTest.scala:29) at scala.tools.nsc.util.StackTraceTest.repressed(StackTraceTest.scala:54) ... 27 more ```
* Merge pull request #2850 from gourlaysama/wip/t6507-2Adriaan Moors2013-08-252-6/+5
|\ | | | | SI-6507 completely sidestep handlers in REPL when :silent in on
| * SI-6507 completely sidestep handlers in REPL when :silent in onAntoine Gourlay2013-08-182-6/+5
| | | | | | | | | | | | | | | | | | This is a cleanup of 6db8a52, the original fix for SI-6507. When the REPL is :silent, all handlers are ignored when it comes to generating the printed result. The result extraction code (`lazy val resN = ...`) is still generated, but now it isn't called until the user calls it.
* | Merge pull request #2824 from qerub/ticket/7740Adriaan Moors2013-08-202-4/+14
|\ \ | | | | | | SI-7740 Trim stack trace before printing in REPL
| * | SI-7740 Trim stack trace before printing in REPLChristoffer Sawicki2013-08-192-4/+14
| | |
* | | No longer crash on NoSymbol.owner.Paul Phillips2013-08-192-13/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically calling NoSymbol.owner has crashed the compiler. With this commit, NoSymbol owns itself. This is consistent with the way ownership chains are handled elsewhere in the compiler (e.g. NoContext.owner is NoContext, NoSymbol.enclClass is NoSymbol, and so on) and frees every call site which handles symbols from having to perform precondition tests against NoSymbol. Since calling NoSymbol.owner sometimes (not always) indicates a bug which we'd like to catch sooner than later, I have introduced a couple more methods for selected call sites. def owner: Symbol // NoSymbol.owner is self, log if -Xdev def safeOwner: Symbol // NoSymbol.owner is self, ignore def assertOwner: Symbol // NoSymbol.owner is fatal The idea is that everyone can call sym.owner without undue anxiety or paranoid null-like tests. When compiling under -Xdev calls to `owner` are logged with a stack trace, so any call sites for which that is an expected occurrence should call safeOwner instead to communicate the intention and stay out of the log. Conversely, any call site where crashing on the owner call was a desirable behavior can opt into calling assertOwner. This commit also includes all the safeOwner calls necessary to give us a silent log when compiling scala.
* | Merge pull request #2841 from gourlaysama/wip/t6507Adriaan Moors2013-08-162-3/+5
|\| | | | | SI-6507 do not call .toString on REPL results when :silent is on.
| * SI-6507 do not call .toString on REPL results when :silent is on.Antoine Gourlay2013-08-162-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Member handlers used to always call .toString on REPL results, even when :silent was on, which could force evaluation or cause unwanted side effects. This forwards the current value of `printResults` to the member handlers (through Request) for them to decide what to do when the results must not be printed. 2 handlers now do not return any extraction code when silent: - ValHandler, so that it doesn't call toString on the val - Assign, so that it doesn't call toString on the right-hand side of the assignement.
* | Merge pull request #2777 from soc/SI-7681-dead-code-daemonthreadfactoryAdriaan Moors2013-08-161-42/+35
|\ \ | | | | | | SI-7681 Remove DaemonThreadFactory, clean up IMain
| * | Clean up imports in s.t.n.interpreter.IMainSimon Ochsenreither2013-08-151-38/+33
| | |
| * | SI-7681 Remove scala.tools.nsc.io.DaemonThreadFactorySimon Ochsenreither2013-08-151-5/+3
| |/
* | refactor repl to use new new parser entry pointDen Shabalin2013-08-146-42/+36
| | | | | | | | | | | | This commit refactors repl to use `parseStats` entry point and streamlines hacky error handling that was previously used to encode errors that happen during parsing.
* | refactor parser entry points and extract a few methods outDen Shabalin2013-08-142-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | This commit contains three logical changes: 1. Split `templateStatSeq` into two methods as we need more reliable parsing of template body alone for new `parseStats` entry point. 2. Add new parser entry point called `parseStats` which is aimed towards use in tools that require parsing of Scala code that can be written inside of a template. Such functionality is required for parsing lines in repl, parsing code through toolbox, parsing and running scala scripts and lastly for quasiquotes. All of them are refactored to use this very method in the next commits. A new method called `templateStatsCompat` is also added to make this commit pass the tests but it's a temporary hack that will be removed in next commit in favor of `parseStats`. 3. Extract out a few methods like `isCaseDefStart`, `expectedMsgTemplate` and `parseRule`. These are needed to override parser behaviour in updated quasiquotes parser (see next commits).
* Merge pull request #2776 from gkossakowski/symbolTable-refactoringsGrzegorz Kossakowski2013-08-061-1/+1
|\ | | | | Refactor the cake so SymbolTable does not depend on Global
| * Refactor the cake so SymbolTable does not depend on GlobalGrzegorz Kossakowski2013-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is rather large commit so I'll first explain the motivation behind it and then go through all changes in detail explaining the choices I made. The motivation behind this refactoring was to make SymbolTable unit testable. I wanted a lightweight way of initializing SymbolTable and then writing unit tests for subtyping algorithm, various functionality related to Symbols, etc. All of that should be possible by precisely controlling what we test, e.g., create types and symbols by hand and not have them defined in source code as we normally do in partest (functional) tests. The other motivation was to reduce and clarify dependencies we have in the compiler. Explicit dependencies lead to cleaner design. Also, explicit and reduces dependencies help incremental compilation which is a big problem for us in compiler's code base at the moment. One of the challenges I faced during that refactoring was cyclic dependency between Platform and SymbolLoaders. Platform depended on `SymbolLoaders.SymbolLoader` because it would define a root loader. SymbolLoaders depended on Platform for numerous reasons like deferring decision how to load a given symbol based on some Platform-specific hooks. I decided to break that cycle by removing methods related to symbol loading from Platform interface. One could argue, that better fix would be to make SymbolLoaders to not depend on Platform (backend) concept but that would be much bigger refactoring. Also, we have a new concept for dealing with symbol loading: Mirrors. For those reasons both `newClassLoader` and `rootLoader` were dropped from Platform interface. Note that JavaPlatform still depends on Global so it can access phases defined in Global to implement `platformPhases` method. Both GenICode and BCodeBodyBuilder have some Platform specific logic that requires casting because pattern matcher doesn't narrow types to give them a proper refinement. Check the changes for details. Some logging utilities has been moved from Global to SymbolTable because they are accessed by SymbolTable. Since Global inherits from SymbolTable this should be a source compatible change. The SymbolLoaders has dependency on `compileLate` method defined in Global. The purpose behind `compileLate` is not clear to me but the dependency looks a little bit dubious. At least we made that dependency explicit. ScaladocGlobal and Global defined in interactive has been adapted in a way that makes them compile both with quick.comp and 2.11.0-M4 so my refactorings are not blocking the modularization effort.
* | Merge pull request #2736 from som-snytt/issue/7488-chase-delayed-initAdriaan Moors2013-07-251-18/+64
|\ \ | |/ |/| SI-7488 REPL javap finds new style delayedEndpoint
| * SI-7488 REPL javap finds new style delayedEndpointSom Snytt2013-07-151-18/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The REPL :java -app command is a convenience to locate the body of DelayedInit code. Now it will look for new style delayedEndpoints on the class before it falls back to showing the apply method of the delayedInit$body closure. ``` apm@mara:~/tmp$ skala Welcome to Scala version 2.11.0-20130711-153246-eb1c3137f5 (OpenJDK 64-Bit Server VM, Java 1.7.0_21). Type in expressions to have them evaluated. Type :help for more information. scala> :javap -pv -app delayed.C public final void delayedEndpoint$delayed$C$1(); flags: ACC_PUBLIC, ACC_FINAL Code: stack=2, locals=1, args_size=1 0: getstatic #29 // Field scala/Predef$.MODULE$:Lscala/Predef$; 3: ldc #31 // String this is the initialization code of C 5: invokevirtual #35 // Method scala/Predef$.println:(Ljava/lang/Object;)V 8: return LocalVariableTable: Start Length Slot Name Signature 0 9 0 this Ldelayed/C; LineNumberTable: line 11: 0 scala> :q apm@mara:~/tmp$ rm delayed/*.class apm@mara:~/tmp$ scalac delayed.scala apm@mara:~/tmp$ skala Welcome to Scala version 2.11.0-20130711-153246-eb1c3137f5 (OpenJDK 64-Bit Server VM, Java 1.7.0_21). Type in expressions to have them evaluated. Type :help for more information. scala> :javap -pv -app delayed.C public final java.lang.Object apply(); flags: ACC_PUBLIC, ACC_FINAL Code: stack=2, locals=1, args_size=1 0: getstatic #13 // Field scala/Predef$.MODULE$:Lscala/Predef$; 3: ldc #15 // String this is the initialization code of C 5: invokevirtual #19 // Method scala/Predef$.println:(Ljava/lang/Object;)V 8: getstatic #25 // Field scala/runtime/BoxedUnit.UNIT:Lscala/runtime/BoxedUnit; 11: areturn LocalVariableTable: Start Length Slot Name Signature 0 12 0 this Ldelayed/C$delayedInit$body; LineNumberTable: line 11: 0 line 10: 8 ```
* | SI-7650 No bang expansions in REPL jlineSom Snytt2013-07-151-0/+3
|/ | | | Disable expandEvents at the earliest opportunity.
* SI-4684 Repl supports raw pasteSom Snytt2013-07-111-9/+30
| | | | | | | | By special request, :paste -raw simply compiles the pasted code to the repl output dir. The -raw flag means no wrapping; the pasted code must be ordinary top level Scala code, not script.
* SI-4684 Repl supports whole-file pasteSom Snytt2013-07-111-15/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a file argument to the :paste command which loads the file's contents as though entered in :paste mode. The :paste command is replayable. Samples, including companions defined together: ``` scala> :paste junk.scala File contains no code: junk.scala scala> :paste no-file.scala That file does not exist scala> :paste obj-repl.scala Pasting file obj-repl.scala... <console>:2: error: expected start of definition private foo = 7 ^ scala> :paste hw-repl.scala Pasting file hw-repl.scala... The pasted code is incomplete! <pastie>:5: error: illegal start of simple expression } ^ scala> :replay Replaying: :paste junk.scala File contains no code: junk.scala Replaying: :paste obj-repl.scala Pasting file obj-repl.scala... defined trait Foo defined object Foo Replaying: Foo(new Foo{}) res0: Int = 7 ```
* Merge pull request #2697 from som-snytt/issue/6419-repl-saveAdriaan Moors2013-07-101-0/+7
|\ | | | | SI-6419 Repl save session command
| * SI-6419 Repl save session commandSom Snytt2013-07-011-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A simple save command to write out the current replay stack. ``` scala> val i = 7 i: Int = 7 scala> val j= 8 j: Int = 8 scala> i * j res0: Int = 56 scala> :save multy.script scala> :q apm@mara:~/tmp$ cat multy.script val i = 7 val j= 8 i * j apm@mara:~/tmp$ skala Welcome to Scala version 2.11.0-20130626-204845-a83ca5bdf7 (OpenJDK 64-Bit Server VM, Java 1.7.0_21). Type in expressions to have them evaluated. Type :help for more information. scala> :load multy.script Loading multy.script... i: Int = 7 j: Int = 8 res0: Int = 56 scala> :load multy.script Loading multy.script... i: Int = 7 j: Int = 8 res1: Int = 56 ```
* | Merge pull request #2701 from som-snytt/issue/4594-repl-settingsAdriaan Moors2013-07-101-10/+54
|\ \ | | | | | | SI-4594 Repl settings command
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-22 16:21:40 +0000