graalvm/vscode-extensions

Visual Studio Code extension

This suite provides extension to Visual Studio Code that supports development of applications targeting GraalVM. The extension is Technology Preview.

Build VSIX package from sources

To build VSIX package of the GraalVM extension, take the following steps:

• Install vsce (short for "Visual Studio Code Extensions"), a command-line tool for packaging, publishing and managing VS Code extensions

npm install -g vsce

• Compile and package the extension

pushd graalvm; npm install; vsce package; popd;

Alternatively, invoke mx build to create a zip file distribution with the extension contained.

Installation

To install the GraalVM extension into Visual Studio Code, take the following step:

• Install desired package with code --install-extension <extension.vsix>

code --install-extension graalvm/graalvm-*.vsix

License

GraalVM VS Code Extension is licensed under The Universal Permissive License (UPL), Version 1.0

vscode-extensions's Issues

Add support for defining environment variables in launch configuration

It's fairly common when running or debugging an application to want to specify environment variables. Other launchers I've used support the env property, accepting a map of key:value pairs. It would be really nice if this were configurable for the GraalVM launcher as well. My use case is running and debugging code on TruffleRuby.

The Extension pack is not available.

The extension pack GraalVM Extension Pack for Java, is not available in the marketplace and returns 404.

https://marketplace.visualstudio.com/items?itemName=oracle-labs-graalvm.graalvm-pack

Manually searching also don't yield any results: https://marketplace.visualstudio.com/search?term=graalvm&target=VSCode&category=All%20categories&sortBy=Relevance

JS Code Highlighting Inside Java

Copyed From:

• oracle/graaljs#628

Get Correct JS syntax Highlighting in Java15+ TextBlocks would be nice

Value getDimensions = jsContext.eval("js", """
`() => {
    return {
        width: document.documentElement.clientWidth,
        height: document.documentElement.clientHeight,
        deviceScaleFactor: window.devicePixelRatio
    }
}`
""");

VisualVM component not available for GraalVM 21

I have been using GraalVM 17 with Java 17 for a long time without any problems. I have been able to use the visualVM integration for a long time. This seems to not work with GraalVM 21:

Even with the installation active, I do not have the option to even install visualVM as a component.

With GraalVM 17 you can see the difference, as it finds the GraalVM Core and Native Image portions of the JDK. (Ignore the Could not resolve components as I'm using a snap version of vscode that doesn't have the GLIBCXX_3.4.29 installed)

In this case, I am able to attach a VisualVM component to the GraalVM instance.

Looks like the GraalVM 21 is not being recognized as a GraalVM JDK

Publish extensions to open-vsx.org

Could you publish the extensions also to open-vsx.org which is used as the extension registry by compatible alternatives to vscode like VSCodium or Eclipse Theia? Here's a document which explains how to do that: https://github.com/eclipse/openvsx/wiki/Publishing-Extensions

Plugin doesn't see GraalVM installations

Hi, the plugin won't detect any installed GraalVM.
Not even wen I let the plugin download and install the GraalVM.
Got an error "Failed to add selected Graal VM installation"
On Mac Book Pro OSX BigSur.
java -version:
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
Picked up _JAVA_OPTIONS: -Xmx2048m
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment GraalVM CE 21.2.0 (build 11.0.12+6-jvmci-21.2-b08)
OpenJDK 64-Bit Server VM GraalVM CE 21.2.0 (build 11.0.12+6-jvmci-21.2-b08, mixed mode, sharing)

Should restore the services of JDT language server after uninstall NetBeans language server

Currently NetBeans Language Server automatically adds some settings (e.g. "java.completion.enabled", "java.debug.settings.enableRunDebugCodeLens") to my settings.json to disable some clash services of JDT Language Server, but when I uninstall NetBeans Language Server, these settings cannot be restored, which will result in some JDT Language features not being available. This is not a good behavior and I believe most users will not know they need to change the settings manually.

So you'd better change these settings back when users uninstall NetBeans Language Server.

Please refer to the uninstall hook about how to add cleanup steps.
https://code.visualstudio.com/api/references/extension-manifest#extension-uninstall-hook

ECONNREFUSED 127.0.0.1:<PORT> on Windows 10

Below I have included as much information as possible.
This issue does not happen in WSL or in a Devcontainer with Ubuntu.

(Thank you so much to the Graal and Apache Netbeans folks for such an awesome platform + extension by the way)

[Error - 10:37:27 AM] Starting client failed
Error: connect ECONNREFUSED 127.0.0.1:18189
	at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)

Initiating server activation
Request to kill LSP server.
Cannot kill: current process is None
Launching Apache NetBeans Language Server with C:\GraalVM\graalvm-ce-java16-21.1.0-dev
LSP server launching: 14660
-------------------------------------------------------------------------------
>Log Session: Sunday, June 13, 2021 at 10:37:28 AM Eastern Daylight Time
>System Info: 
  Product Version         = vsc 12.4-21726744165c946ba6619bff89e98d5863f26e22
  Operating System        = Windows 10 version 10.0 running on amd64
  Java; VM; Vendor        = 16; OpenJDK 64-Bit Server VM 16+36-jvmci-21.1-b03; GraalVM Community
  Runtime                 = OpenJDK Runtime Environment 16+36-jvmci-21.1-b03
  Java Home               = C:\GraalVM\graalvm-ce-java16-21.1.0-dev

{
	  "java.home": "C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev",
	  "netbeans.jdkhome": "C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev",
	  "graalvm.home": "C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev",
	  "graalvm.installations": ["C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev"],
	  "terminal.integrated.env.windows": {
	    "GRAALVM_HOME": "C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev",
	    "JAVA_HOME": "C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev",
	    "PATH": "C:\\GraalVM\\graalvm-ce-java16-21.1.0-dev\\bin;<TRUNCATED>"
	  }
}

C:\Users\rayga>gu list
Illegal format in tzmappings file: illegal null character found at line 1, offset 47.
ComponentId              Version             Component name                Stability                     Origin
-------------------------------------------------------------------------------------------------------------------
graalvm                  21.1.0-dev          GraalVM Core                  -
js                       21.1.0-dev          Graal.js                      Early adopter (suppo
nfi                      21.1.0-dev          SVM Truffle NFI Support       Early adopter (suppo

---

Example VS Code Devcontainer configuration which works fine:

FROM ubuntu:21.10
ENV DEBIAN_FRONTEND=noninteractive
​
# Gradle
ENV GRADLE_VERSION 7.1
ENV GRADLE_HOME /opt/gradle
VOLUME /home/gradle/.gradle
​
# GraalVM
ENV JAVA_HOME=/graalvm
ENV PATH=$JAVA_HOME/bin:$PATH
​
ARG JAVA_VERSION=16
ARG TARGET_ARCH=linux-amd64
​
# Grabbing a nightly release, 21.2.0-dev-20210615_0052
ARG GRAALVM_VERSION=21.2.0-dev
ARG GRAALVM_GITHUB_RELEASE_TAG=20210615_0052
​
# /graalvm-ce-java16-21.2.0-dev
ARG GRAALVM_HOME=/graalvm-ce-java${JAVA_VERSION}-${GRAALVM_VERSION}
# graalvm-ce-java16-linux-amd64-dev.tar.gz
ARG GRAALVM_DOWNLOAD_TARGET=graalvm-ce-java${JAVA_VERSION}-${TARGET_ARCH}-dev.tar.gz
ARG GRAALVM_DEV_DOWNLOADS_URL=https://github.com/graalvm/graalvm-ce-dev-builds/releases/download
​
RUN  set -o errexit -o nounset -o xtrace \
  && apt-get update \
  && apt-get install --no-install-recommends --yes   \
  unzip ca-certificates wget \
  # GraalVM
  # Example: https://github.com/graalvm/graalvm-ce-dev-builds/releases/download/21.2.0-dev-20210615_0052/graalvm-ce-java16-linux-amd64-dev.tar.gz
  && wget "${GRAALVM_DEV_DOWNLOADS_URL}/${GRAALVM_VERSION}-${GRAALVM_GITHUB_RELEASE_TAG}/${GRAALVM_DOWNLOAD_TARGET}" \
  && tar --extract --gzip --file=${GRAALVM_DOWNLOAD_TARGET} \
  && ln --symbolic $GRAALVM_HOME /graalvm \
  \
  # Gradle
  && echo "Downloading Gradle" \
  && wget --no-verbose --output-document=gradle.zip "https://services.gradle.org/distributions/gradle-${GRADLE_VERSION}-bin.zip" \
  \
  && echo "Installing Gradle" \
  && unzip gradle.zip \
  && rm gradle.zip \
  && mv "gradle-${GRADLE_VERSION}" "${GRADLE_HOME}/" \
  && ln --symbolic "${GRADLE_HOME}/bin/gradle" /usr/bin/gradle \
  \
  && echo "Testing Gradle installation" \
  && gradle --version \
  \
  # Cleanup
  && apt-get -qq clean \
  && rm --recursive --force /var/lib/apt/lists/* /tmp/* /var/tmp/* \
  && rm --force ${GRAALVM_DOWNLOAD_TARGET}
​
RUN gu install llvm-toolchain \
  && gu install python \
  && gu install ruby \
  && gu install wasm

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.183.0/containers/ubuntu
{
  "name": "GraalVM Ubuntu",
  "build": {
    "dockerfile": "Dockerfile",
    "args": {}
  },
​
  // Set *default* container specific settings.json values on container create.
  "settings": {
    "netbeans.jdkhome": "/graalvm",
    "java.import.gradle.java.home": "/graalvm",
    "java.home": "/graalvm",
    "terminal.integrated.env.linux": null,
    "terminal.integrated.inheritEnv": false
  },
​
  "containerEnv": {
    "GRADLE_HOME": "/opt/gradle/gradle-7.1",
    "JAVA_HOME": "/graalvm"
  },
​
  // Set remoteEnv so that tasks (Gradle extension) pick up proper JAVA_HOME env
  "remoteEnv": {
    "PATH": "${containerEnv:PATH}",
    "JAVA_HOME": "/graalvm"
  },
​
  "extensions": [
    "oracle-labs-graalvm.graalvm",
    "asf.apache-netbeans-java",
    "ms-azuretools.vscode-docker",
    "usernamehw.errorlens",
    "richardwillis.vscode-gradle"
  ]
}

Publish `GraalVM Extensions for VS Code` to Open VSX

Dear extension author,
Please publish this extension to the Open VSX marketplace.

Context

Unfortunately, as Microsoft prohibits usages of the Microsoft marketplace by any other products or redistribution of .vsix files from it, in order to use VS Code extensions in non-Microsoft products, we kindly ask that you take ownership of the VS Code extension namespace in Open VSX and publish this extension on Open VSX.

What is Open VSX? Why does it exist?

Open VSX is a vendor neutral alternative to the MS marketplace used by most other derivatives of VS Code like VSCodium, Gitpod, OpenVSCode, Theia-based IDEs, and so on.

You can read on about Open VSX at the Eclipse Foundation's Open VSX FAQ.

How can you publish to Open VSX?

The docs to publish an extension can be found here. This process is straightforward and shouldn't take too long. Essentially, you need an authentication token and to execute the ovsx publish command to publish your extension. There's also a doc explaining the whole process with an example GitHub Action workflow.

Handle workspace files correctly

In my global configuration I have nothing relevant.
Now I have a file graalvm.code-workspace like:

{
	"settings": {
		"graalvm.home": "...\\graalvm-ce-java11-21.2.0",
		"graalvm.installations": [
			"...\\graalvm-ce-java11-21.2.0"
		],
		"netbeans.jdkhome": "...\\graalvm-ce-java11-21.2.0",
		"terminal.explorerKind": "integrated",
		"terminal.integrated.env.windows": {
			"GRAALVM_HOME": "...\\graalvm-ce-java11-21.2.0",
			"JAVA_HOME": "...\\graalvm-ce-java11-21.2.0"
		}
	}
}

When I open the file, 2 issues occur:

(1) I get the following error in the Output window:

[Error - 16:20:04] Server initialization failed.
Error: command 'dry_run' already exists
	at _.registerCommand (c:\Users\me\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:94:109536)
	at Object.registerCommand (c:\Users\me\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:103:20898)
	at W.register (c:\Users\me\.vscode\extensions\oracle-labs-graalvm.graalvm-0.5.11\dist\extension.js:2:320903)
	at W.initialize (c:\Users\me\.vscode\extensions\oracle-labs-graalvm.graalvm-0.5.11\dist\extension.js:2:320665)
	at S.initializeFeatures (c:\Users\me\.vscode\extensions\oracle-labs-graalvm.graalvm-0.5.11\dist\extension.js:2:337737)
	at c:\Users\me\.vscode\extensions\oracle-labs-graalvm.graalvm-0.5.11\dist\extension.js:2:330288

(2) the extension duplicates the configuration that I have in my workspace file in the global settings, appending:

    "graalvm.home": "...\\graalvm-ce-java11-21.2.0",
    "netbeans.jdkhome": "...\\graalvm-ce-java11-21.2.0",
    "terminal.integrated.env.windows": {
        "GRAALVM_HOME": "...\\graalvm-ce-java11-21.2.0",
        "JAVA_HOME": "...\\graalvm-ce-java11-21.2.0"
    }

This is problematic: the GraalVM extension isn't enabled globally, so it shouldn't change any global configuration either. If it's only enabled for the current workspace, it should only touch the workspace configuration. And since all required configuration is already provided in the workspace file, I expect it to do nothing at all in this case.

Cannot debug Ruby on GraalVM using chromeInspector protocol and default output

Reported by external user there is an issue with GraalVM extension when generating default launch.json config for debugging Ruby. It does not start.
I had a simple ruby script and had to create following launch.json to make debugger running VSCode GraalVM ext 0.5.6 and GraalVM EE 21.0.0.2 Java 11 and GraalVM CE 21.1.0 JDK11.

"configurations": [
        {
            "type": "graalvm",
            "request": "launch",
            "name": "Launch Ruby Script",
            "runtimeExecutable": "ruby",
            "program": "${file}",
            "protocol": "debugAdapter",
            "outputCapture": "std"
        }

    ] 

Other combinations don't work.
When having simple hello.rb file with content like

 puts 'Hello World'

then when launching debugger it also says undefined breakpoint for breakpoint on line 1.

No "GraalVM" debugger launch environment available

The docs for the GraalVM VS Code extension have several sections on debugging various Truffle languages. In each of them, there's some variation of the following:

To debug a Ruby application running on GraalVM, creating a launch configuration for the application is necessary. To do so, open the application project folder in VS Code (File > Open Folder), then switch to the Debug view by clicking on the "bug" icon in the left-hand side panel. The newly opened window will suggest you create a launch.json file. If debugging is not yet configured (no launch.json has been created), select GraalVM from the list of available debug environmnets [sic].

However, there is no "GraalVM" option available in the list of debug environments. It appears that either the option is missing or the documentation is out of date.

cant attach debug remote jvm

i launch a jvm with remote debug port 7878

/home/w/lib/jvm/graalvm-ee-java8-21.3.0/bin/java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7878 -Dfile.encoding=UTF-8 -cp /home/w/Documents/localgitserver/zaporxyAndExtenions/zaproxy/zap/bin/main:/home/w/.m2/repository/com/fifesoft/rsyntaxtextarea/3.1.3.jar org.zaproxy.zap.ZAP

then i try connection to 7878 with vscode , But can't connect the remote jvm .

this is my launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "graalvm",
            "request": "attach",
            "name": "Attach",
            "port": 7878
        } 
    ]
}

my extensions

remote jvm terminal output error

Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/list< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json HTTP< - expected >JDWP-Handshake<
Debugger failed to attach: handshake failed - received >GET /json/vers< - expected >JD

my vscode is 1.60

Can not install x86 target GraalVM_EE on M1x Mac

As there is no EE version of GraalVM for M1x (ARM64) Macs yet, I would like to select the x86 version (to be used via Rosetta 2). This forces me to install via download/command line which is cumbersome. Please allow selection of non "native" GraalVM Versions.

Graalvm17 Native Image debug hang on vscode

Graalvm debug hang with following config:
maven config:

<build>
        <plugins>
          <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
            <version>${native.maven.plugin.version}</version>
            <extensions>true</extensions>
            <executions>
              <execution>
                <id>build-native</id>
                <goals>
                  <goal>build</goal>
                </goals>
                <phase>package</phase>
              </execution>
              <execution>
                <id>test-native</id>
                <goals>
                  <goal>test</goal>
                </goals>
                <phase>test</phase>
              </execution>
            </executions>
            <configuration>
              <fallback>false</fallback>
              <agent>
                <enabled>true</enabled>
              </agent>
                <buildArgs>
                  <buildArg>-g</buildArg>
                  <buildArg>-O0</buildArg>
                </buildArgs>             
               <debug>true</debug>
            </configuration>
          </plugin>

lauch config:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "graalvm",
      "request": "attach",
      "name": "Attach",
      "protocol": "debugAdapter",
      "port": 4711
    }
  ]
}

graalvm version: 17:

Test issue

Testing issues in this projects.

Plugin wrongly adds JavaSE-8 entry java.configuration.runtimes in settings.json

This entry is added by the plugin. It can't be found. Even if the right entry is already added, which is JavaSE-1.8, the problem persists.

{
  "name": "JavaSE-8",
  "path": "C:\\Program Files\\GraalVM\\graalvm-ee-java8-21.3.4"
}

Thank you.

Unable to set the ECMAScript language compatibility

When the extension is enabled, it very proactively tries to parse all the projects in the VSCode workspace. If the projects use a newer ECMAScript for JavaScript with for example import-commands, they are all marked as having syntax errors. After digging a bit I found that there is a configuration parameter that could be set as the server starts up (for example --js.ecmascript-version=2019) but I didn't find any way to set it. Did I miss something or is there another way to enable the compatibility?

Cannot debug Micronaut Gradle projects

I have created a simple gradle micronaut project and I've added a trivial controller:

@Controller("/health")
public class HealthCheck {
    
    @Get()
    public HttpResponse<String> index() {        
        return HttpResponse.ok("success");
    }  
}

From VS Code I start debugging the project (F5 shortcut, using default launch.json file). VS Code started the debug mode but if I try to hit this controller from curl I get

{"message":"Page Not Found","_links":{"self":{"href":"/health","templated":false}}}

This does not happen if i start the project with gradle run. The curl command returns success

Is it something that can be addressed into the Micronaut VS Code extension? Or is it something that Micronaut team has to address...

Field "can be final" quickfix puts "final" in wrong place.

Apache NetBeans Language Server: 12.2.2
GraalVM Extension: 0.5.4

When seeing this warning: "Field brandId can be final" with full details below, and selecting the "Make final" quick fix the "final" keyword is not inserted into the correct position. It inserts at the cursor position sometimes, and sometimes in between the type and field name. E.g., "private String final foo".

{
"resource": "/Users/shaun/git/github/shaunsmith/comics/src/main/java/org/comics/model/Issue.java",
"owner": "generated_diagnostic_collection_name#2",
"code": "hints:0-text/x-java:org.netbeans.modules.java.hints.threading.Tiny.canBeFinal",
"severity": 4,
"message": "Field brandId can be final",
"startLineNumber": 103,
"startColumn": 22,
"endLineNumber": 103,
"endColumn": 29
}

How to start Visual VM when gradle project starts?

Hi! I have a Gradle project. I want to open Visual VM and start monitoring e.g. memory profiling when project start or when specific Gradle codding run e.g. gradle run

How to achieve this?

When I run project from Gradle plugin, Visual VM not starts.

cwd default overridden by executable

I'm running into an issue with the GraalVM debugger not running in the correct directory. Without having the cwd set correctly, none of the project files (e.g., Rakefile or Gemfile) can be found by the executing process.

I haven't debugged the extension yet, so I'm not entirely sure what's going on, but if I do not specify the cwd property in my debug configuration, then the working directory is set to the directory that contains the ruby process. If I add an entry like "cwd": "${workspaceFolder}", then everything works as I expect. But, that's the documented default value so I assume something in the extension is overriding the value somewhere.