From e0b4b77acd444b1c8dd09264abef9be794a7f50b Mon Sep 17 00:00:00 2001 From: i10416 Date: Thu, 29 Feb 2024 15:11:08 +0900 Subject: [PATCH] tidy: minor cleanup - remove unnecessary trailing spaces - fix typos --- .github/workflows/ci.yml | 38 ++++++++--------- .github/workflows/publish-docs.yml | 28 ++++++------- .github/workflows/release.yml | 8 ++-- docs/_docs/contributing/contributing.md | 42 +++++++++---------- docs/_docs/reference/library-modules.md | 28 ++++++------- docs/_docs/reference/usage.md | 8 ++-- docs/_docs/reference/va-list.md | 6 +-- src/main/scala/fr/hammons/slinc/Slinc.scala | 2 +- .../scala/fr/hammons/slinc/BindingSpec.scala | 2 +- 9 files changed, 81 insertions(+), 81 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 7b7e5223..b8575c37 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -1,16 +1,16 @@ name: SLinC CI on: pull_request: - push: + push: branches: - "master" -jobs: +jobs: format-check: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 + - uses: actions/checkout@v3 - uses: coursier/cache-action@v6 - uses: coursier/setup-action@v1.3.0 with: @@ -25,7 +25,7 @@ jobs: - run: mkdir reports - name: Core tests run: sbt coverage test - + - run: | sbt coverageReport mkdir -p reports @@ -33,53 +33,53 @@ jobs: # - run: | # ./mill core.scoverage.xmlReport # cp out/core/scoverage/xmlReport.dest/scoverage.xml reports/core-coverage.xml - # env: + # env: # JAVA_HOME: ${{ env.JAVA_HOME_17_X64}} - + # - name: Java 17 Implementation test # run: | # ./mill j17.compile # ./mill j17.test - # env: + # env: # JAVA_HOME: ${{ env.JAVA_HOME_17_X64}} # - run: | # ./mill j17.scoverage.xmlReport # cp out/j17/scoverage/xmlReport.dest/scoverage.xml reports/java17-coverage.xml - # env: + # env: # JAVA_HOME: ${{ env.JAVA_HOME_17_X64}} # - name: Java 19 Implementation test # run: | # ./mill j19.compile - # ./mill j19.test + # ./mill j19.test # - run: | - # ./mill j19.scoverage.xmlReport + # ./mill j19.scoverage.xmlReport # cp out/j19/scoverage/xmlReport.dest/scoverage.xml reports/java19-coverage.xml - # - name: Runtime 17 implementation tests - # run: ./mill runtime.test - # env: + # - name: Runtime 17 implementation tests + # run: ./mill runtime.test + # env: # JAVA_HOME: ${{ env.JAVA_HOME_17_X64 }} # - run: | - # ./mill runtime.scoverage.xmlReport + # ./mill runtime.scoverage.xmlReport # cp out/runtime/scoverage/xmlReport.dest/scoverage.xml reports/java-17-runtime-coverage.xml - # env: + # env: # JAVA_HOME: ${{ env.JAVA_HOME_17_X64 }} - - # - name: Runtime 19 implementation tests + + # - name: Runtime 19 implementation tests # run: ./mill runtime.test # - run: | # ./mill runtime.scoverage.xmlReport # cp out/runtime/scoverage/xmlReport.dest/scoverage.xml reports/java-19-runtime-coverage.xml - name: Upload coverage to Codecov - uses: codecov/codecov-action@v3 + uses: codecov/codecov-action@v3 with: - directory: reports \ No newline at end of file + directory: reports diff --git a/.github/workflows/publish-docs.yml b/.github/workflows/publish-docs.yml index 84d07b6c..b5b27554 100644 --- a/.github/workflows/publish-docs.yml +++ b/.github/workflows/publish-docs.yml @@ -1,15 +1,15 @@ name: Publish Docs -on: +on: workflow_dispatch - + jobs: - build: + build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - with: + with: lfs: true - - uses: coursier/cache-action@v6 + - uses: coursier/cache-action@v6 - uses: actions/setup-java@v3 with: distribution: 'temurin' @@ -18,20 +18,20 @@ jobs: run: sbt doc - name: Upload GitHub Pages artifact uses: actions/upload-pages-artifact@v3 - with: + with: path: target/scala-3.3.1/api - deploy: - needs: build + deploy: + needs: build permissions: - pages: write - id-token: write - environment: + pages: write + id-token: write + environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} - runs-on: ubuntu-latest + runs-on: ubuntu-latest steps: - - name: Deploy to GitHub Pages - id: deployment + - name: Deploy to GitHub Pages + id: deployment uses: actions/deploy-pages@v4 diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 9dc46d08..735f5c49 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -6,7 +6,7 @@ on: jobs: publish: runs-on: ubuntu-latest - steps: + steps: - uses: actions/checkout@v3 - uses: coursier/cache-action@v6 - name: Get Secrets @@ -18,10 +18,10 @@ jobs: e5a2f416-de5c-4f2d-bc09-b060011d760b > SONATYPE_PASSWORD 44adbbc1-df7f-432f-8034-b060011d5d94 > SONATYPE_USERNAME 88fba8d9-e11a-4d8c-bfbd-b06001410130 > PGP_PASSPHRASE - - name: Get JVMs + - name: Get JVMs uses: actions/setup-java@v4 - with: + with: distribution: 'temurin' java-version: 17 cache: sbt - - run: sbt ci-release \ No newline at end of file + - run: sbt ci-release diff --git a/docs/_docs/contributing/contributing.md b/docs/_docs/contributing/contributing.md index bf39fbc9..5ac20283 100644 --- a/docs/_docs/contributing/contributing.md +++ b/docs/_docs/contributing/contributing.md @@ -5,9 +5,9 @@ The code in this repository is primarily divided into four top-level directories * `j17/`: Java 17 specific parts of the Slinc implementation * `j19/`: Java 19 specific parts of the Slinc implementation * `runtime/`: The complete Slinc project, with Java 17 and 19 implementations combined and the correct implementation chosen at runtime by your system. - + ## Developing Slinc -Slinc is a somewhat involved project to program for. With implementations targeting Java 17 and Java 19, one needs access to both JDKs to develop and run the j17 and j19 projects. +Slinc is a somewhat involved project to program for. With implementations targeting Java 17 and Java 19, one needs access to both JDKs to develop and run the j17 and j19 projects. ### Sdkman @@ -19,7 +19,7 @@ Once you have sdkman installed, you can use the following commands to install an * Install: `sdk i java 19-tem` * Use: `sdk u java 19-tem` * Default: `sdk d java 19-tem` - + #### Java 17 * Install: `sdk i java 17.0.4.1-tem` * Use: `sdk u java 17.0.4.1-tem` @@ -29,25 +29,25 @@ Once you have sdkman installed, you can use the following commands to install an `Use` will set the JDK visible for a certain terminal instance. This is useful if you want to build the entire project. Use will only effect the JDK choice for the terminal it's invoked in, and will not affect the user default JVM. -`Default` will set the JDK that's visible for all programs launched after the command has been invoked. This is useful for reloading your code editor to work on a different java implementation for Slinc. +`Default` will set the JDK that's visible for all programs launched after the command has been invoked. This is useful for reloading your code editor to work on a different java implementation for Slinc. ### Editor -When developing Slinc, it's suggested to use [VSCode](https://code.visualstudio.com/) along with the [Metals](https://marketplace.visualstudio.com/items?itemName=scalameta.metals) extension. Slinc is heavily dependent on compile-time programming, and VSCode+Metals works very well with this development model. One can use other editors, but it's probably mandatory to use Metals. +When developing Slinc, it's suggested to use [VSCode](https://code.visualstudio.com/) along with the [Metals](https://marketplace.visualstudio.com/items?itemName=scalameta.metals) extension. Slinc is heavily dependent on compile-time programming, and VSCode+Metals works very well with this development model. One can use other editors, but it's probably mandatory to use Metals. -Using metals, one can import the build definition from mill. If one encounters an issue with the import failing for no discernable reason, try deleting the `out` directory and trying again. There is a problem with this project and mill failing to generate bloop configurations. If one encounters errors when viewing a code base that do not resolve themselves, it's suggested to try closing VSCode, killing all Java processes, and deleting .metals, .bloop, and out. Generally, this will fix all issues. +Using metals, one can import the build definition from mill. If one encounters an issue with the import failing for no discernable reason, try deleting the `out` directory and trying again. There is a problem with this project and mill failing to generate bloop configurations. If one encounters errors when viewing a code base that do not resolve themselves, it's suggested to try closing VSCode, killing all Java processes, and deleting .metals, .bloop, and out. Generally, this will fix all issues. -When developing for Slinc, choose an implementation to focus on, and choose the appropriate JDK for it. Switch with the appropriate `default` command on sdkman, kill all java processes, and afterwards open the project with VSCode. The corresponding `j` project should be having no missing definition errors after this process. Switching between JDK versions follows the same process. +When developing for Slinc, choose an implementation to focus on, and choose the appropriate JDK for it. Switch with the appropriate `default` command on sdkman, kill all java processes, and afterwards open the project with VSCode. The corresponding `j` project should be having no missing definition errors after this process. Switching between JDK versions follows the same process. -## Compiling +## Compiling -The following commands compile the Slinc projecs: +The following commands compile the Slinc projects: * core: `./mill core.compile` * j17: `./mill j17.compile` * j19: `./mill j19.compile` * runtime: `./mill runtime.compile` -Compiling the entire project would normally be done by running `./mill _.compile`, but considering the different project have different JDK requirements, the full compilation takes the form of +Compiling the entire project would normally be done by running `./mill _.compile`, but considering the different project have different JDK requirements, the full compilation takes the form of ```bash sdk u java 17.0.4.1-tem && \ @@ -78,7 +78,7 @@ Testing code is generally stored in the `core` project under `core/test/src`. Ja Tests in Slinc use munit and scalacheck. One can read how to use munit with scalacheck [here](https://scalameta.org/munit/docs/integrations/scalacheck.html) and how to use scalacheck [here](https://github.com/typelevel/scalacheck/blob/main/doc/UserGuide.md). -In order to develop a new test suite for Slinc, add the implementation to `core/test/src`. If the test suite is testing an implementation in `core` then one can define it in the normal way specified by the munit documentation. However, if it's meant to be a test of Slinc implementations, it should be defined in a generic fashion like so: +In order to develop a new test suite for Slinc, add the implementation to `core/test/src`. If the test suite is testing an implementation in `core` then one can define it in the normal way specified by the munit documentation. However, if it's meant to be a test of Slinc implementations, it should be defined in a generic fashion like so: ```scala package fr.hammons.slinc @@ -87,7 +87,7 @@ import munit.ScalaCheckSuite trait MyTestSuite(slinc: Slinc) extends ScalaCheckSuite: import slinc.{*,given} - test("myTest") { + test("myTest") { assertEquals(4,4) } ``` @@ -104,9 +104,9 @@ If one's test suite concerns JIT compilation, one can use `noJit` and `immediate ### Troubleshooting tests -Sometimes when running a freshly written test, or testing freshly written code, one might encounter a situation where the test suite will stop testing early, or never stop running. +Sometimes when running a freshly written test, or testing freshly written code, one might encounter a situation where the test suite will stop testing early, or never stop running. -Generally, the test suite will stop running early when some part of the Slinc runtime fails to initialize properly. One can easily detect if this is the case by moving some test code out of the test section into the root of the suite. +Generally, the test suite will stop running early when some part of the Slinc runtime fails to initialize properly. One can easily detect if this is the case by moving some test code out of the test section into the root of the suite. Observe the following example: @@ -125,7 +125,7 @@ trait MySuite(s: Slinc) extends ScalacheckSuite: import s.{*,given} sizeOf[Int] 4.as[SizeT] - + test("myTest") { assertEquals(sizeOf[Int], 4.as[SizeT]) } @@ -141,18 +141,18 @@ trait MySuite(s: Slinc) extends ScalacheckSuite: property("myProperty") { forAll{ - (i: Int) => + (i: Int) => Scope.confined{ val ptr = Ptr.blank[CInt] - !ptr = i + !ptr = i assertEquals(!ptr, i) } } } ``` -should be changed to +should be changed to ```scala trait MySuite(s: Slinc) extends ScalacheckSuite: @@ -164,13 +164,13 @@ trait MySuite(s: Slinc) extends ScalacheckSuite: property("myProperty") { forAll{ - (i: Int) => + (i: Int) => Scope.confined{ val ptr = Ptr.blank[CInt] - !ptr = i + !ptr = i assertEquals(!ptr, i) } } } -``` \ No newline at end of file +``` diff --git a/docs/_docs/reference/library-modules.md b/docs/_docs/reference/library-modules.md index 689c729c..e1b10243 100644 --- a/docs/_docs/reference/library-modules.md +++ b/docs/_docs/reference/library-modules.md @@ -4,7 +4,7 @@ title: "Function Sets" Function sets are groupings of functions in Slinc. Each can be configured in a number of ways. -A function set is a Scala `trait` that derives the `FSet` type class. Method declarations within it are used as a template for the bindings to C that the Slinc runtime will generate. +A function set is a Scala `trait` that derives the `FSet` type class. Method declarations within it are used as a template for the bindings to C that the Slinc runtime will generate. ## FSet declarations @@ -12,7 +12,7 @@ FSet declarations are declarations of C library bindings without any entanglemen ### FSet naming -The type name of the module does not matter to Slinc. +The type name of the module does not matter to Slinc. ### Method naming @@ -76,23 +76,23 @@ import fr.hammons.slinc.* @NeedsResource("my_lib") trait L derives FSet: - def my_fun(i: CInt): Unit + def my_fun(i: CInt): Unit ``` The slinc runtime will look for `/native/my_lib_x64.so` on x86_64 linux, and `/native/my_lib_x64.dll` on x86_64 Windows. ### Libraries on the system path -If the library is on the system path that the JVM is aware of, you can declare an FSet's dependence on it with the `Needs` annotation. +If the library is on the system path that the JVM is aware of, you can declare an FSet's dependence on it with the `Needs` annotation. ```scala import fr.hammons.slinc.annotations.* import fr.hammons.slinc.types.* -import fr.hammons.slinc.* +import fr.hammons.slinc.* @Needs("z") trait L derives FSet: - def zlibVersion(): Ptr[CChar] + def zlibVersion(): Ptr[CChar] ``` This declaration is for a binding to zlib. @@ -101,7 +101,7 @@ This declaration is for a binding to zlib. If the library dependency is located on the filesystem, you can use an absolute or relative path with the `@NeedsFile` annotation. -```scala +```scala import fr.hammons.slinc.annotations.* import fr.hammons.slinc.types.* import fr.hammons.slinc.* @@ -109,15 +109,15 @@ import fr.hammons.slinc.* //relative path @NeedsFile("my_lib.so") trait A derives FSet: - def my_fn(): Unit + def my_fn(): Unit -//absolute path +//absolute path @NeedsFile("/tmp/my_lib.so") trait B derives FSet: def my_fn(): Unit ``` -#### Platform dependent filesystem dependencies +#### Platform dependent filesystem dependencies If you do not provide an absolute file name (file ending with .so or .dll), Slinc will use the base file name provided along with the appropriate library suffix for the OS and a tag based on the architecture. @@ -129,14 +129,14 @@ The architecture tags for the architectures follows: |-----|-----| |x86_64| x64, amd64, x86_64| -### C file jar resources +### C file jar resources If a C file is placed in a jar, under the `/native` you can use the `@NeedsResource` annotation to have Slinc compile and load the file at runtime. In order for this to work, one must have clang installed on the target system. ```scala import fr.hammons.slinc.annotations.* -import fr.hammons.slinc.types.* -import fr.hammons.slinc.* +import fr.hammons.slinc.types.* +import fr.hammons.slinc.* @NeedsResource("my_lib.c") trait L derives FSet: @@ -145,7 +145,7 @@ trait L derives FSet: ## Summoning FSet Implementations -FSet declarations have been shown above, but they are not useable without being summoned. Doing so requires the Slinc runtime on your classpath, and makes the JAR and class files generated dependent on a specific JVM. +FSet declarations have been shown above, but they are not useable without being summoned. Doing so requires the Slinc runtime on your classpath, and makes the JAR and class files generated dependent on a specific JVM. To summon an fset implementation, you use the `FSet.instance[?]` method as shown in the following example: diff --git a/docs/_docs/reference/usage.md b/docs/_docs/reference/usage.md index e92715ba..cbe51f4f 100644 --- a/docs/_docs/reference/usage.md +++ b/docs/_docs/reference/usage.md @@ -61,7 +61,7 @@ The list of operations available on a `Ptr[A]`: * `!ptr = 5` - copy data into a pointer (requires `Send[A]` be defined) * `Ptr.blank[A](n: Int)` - create a blank space in native memory that can store `n` consecutive instances of `A` (requires `LayoutOf[A]` be defined) * `Ptr.copy[A](a: A)` - create a copy of `a` in native memory (requires `Send[A]`) -* `Ptr.asArray(size: Int)` - attempts to copy the data at the pointer into an Array of size `size` (requires `Receive[A]`). This is a very dangerous operation that can crash your program if you don't have all the data you need. +* `Ptr.asArray(size: Int)` - attempts to copy the data at the pointer into an Array of size `size` (requires `Receive[A]`). This is a very dangerous operation that can crash your program if you don't have all the data you need. ## Structs @@ -75,9 +75,9 @@ These struct analogs can be composed with any type that has a `DescriptorOf` def ## va_list -The `va_list` type for C is supported via the `VarArgs` and `VarArgsBuilder` types. +The `va_list` type for C is supported via the `VarArgs` and `VarArgsBuilder` types. -A C function that takes a va_list parameter like below +A C function that takes a va_list parameter like below ```c int pass_va_list(int count, va_list args); @@ -105,4 +105,4 @@ Scope.confined{ } ``` -More documentation on usage of `VarArgs` can be found [here](./va_list.md). \ No newline at end of file +More documentation on usage of `VarArgs` can be found [here](./va_list.md). diff --git a/docs/_docs/reference/va-list.md b/docs/_docs/reference/va-list.md index 3756ec68..6c7e2288 100644 --- a/docs/_docs/reference/va-list.md +++ b/docs/_docs/reference/va-list.md @@ -2,7 +2,7 @@ title: "VarArgs" --- -In C, the `va_list` type can be used to allow callbacks to be variadic. This type is supported in Slinc via the `VarArgs` and `VarArgsBuilder` types. +In C, the `va_list` type can be used to allow callbacks to be variadic. This type is supported in Slinc via the `VarArgs` and `VarArgsBuilder` types. `VarArgs` is the Scala analog of `va_list`, so bindings to C functions and types that contain `va_list` should use `VarArgs` in Slinc. @@ -37,6 +37,6 @@ The `.copy` method allows you to copy a `VarArgs`, making sure that functions yo Be very careful with `VarArgs`. They are usually on the stack, especially if they've come from C. That means that their scope can be much more limited than most things in Slinc. The data backing a `VarArgs` can cease to exist after a function finishes, rather than when a Scope ends. -## Java 17 support +## Java 17 support -`VarArgs` on java 17 is not well supported. If you need to use `VarArgs` for a project, please choose [one of the other JVMs Slinc supports](./jdk-support.md). \ No newline at end of file +`VarArgs` on java 17 is not well supported. If you need to use `VarArgs` for a project, please choose [one of the other JVMs Slinc supports](./jdk-support.md). diff --git a/src/main/scala/fr/hammons/slinc/Slinc.scala b/src/main/scala/fr/hammons/slinc/Slinc.scala index 4d0a142b..073de329 100644 --- a/src/main/scala/fr/hammons/slinc/Slinc.scala +++ b/src/main/scala/fr/hammons/slinc/Slinc.scala @@ -36,7 +36,7 @@ object Slinc: .pipe(vString => vString.toIntOption.getOrElse( throw Error( - s"Major error occured. Couldn't parse the version number $vString" + s"Major error occurred. Couldn't parse the version number $vString" ) ) ) diff --git a/src/test/scala/fr/hammons/slinc/BindingSpec.scala b/src/test/scala/fr/hammons/slinc/BindingSpec.scala index 1ae15594..0f9f68e0 100644 --- a/src/test/scala/fr/hammons/slinc/BindingSpec.scala +++ b/src/test/scala/fr/hammons/slinc/BindingSpec.scala @@ -162,7 +162,7 @@ trait BindingSpec(val slinc: Slinc) extends ScalaCheckSuite: val test = FSet.instance[TestLib] assertEquals(Null[Unit], test.i157_null_eq()) - property("issue 176 - can use and recieve union types from C functions"): + property("issue 176 - can use and receive union types from C functions"): val test = FSet.instance[TestLib] forAll: (float: CFloat, int: CInt, left: Boolean) => val union = CUnion[(Float, Int)]