Graal Native Image is assuming 4k page size here, which is a naughty assumption to make in the modern Linux-on-ARM landscape.
Two very common hardware configurations require 16k minumum page size: the Raspberry Pi 5 and Asahi Linux (running on Apple Silicon hardware).
This change forces 64k pages for Linux/AArch64 native executables to guarantee compatibility with these platforms.
DEVELOPMENT.adoc is also updated to cover the additional dependencies required for building native executables on Linux.
Don't use the system Java on Windows builds, instead download them from Adoptium.
Also:
* Fail job if curl returns a 4xx status code
* Add java version to `GradleJob`
Motivation:
- simplify implementation of lazy type checking
- fix correctness issues of lazy type checking (#785)
Changes:
- implement listing/mapping type cast via amendment (`parent`) instead of delegation (`delegate`)
- handle type checking of *computed* elements/entries in the same way as type checking of computed properties
- ElementOrEntryNode is the equivalent of TypeCheckedPropertyNode
- remove fields VmListingOrMapping.delegate/typeNodeFrame/cachedMembers/checkedMembers
- fix#785 by executing all type casts between a member's owner and receiver
- fix#823 by storing owner and receiver directly
instead of storing the mutable frame containing them (typeNodeFrame)
- remove overrides of VmObject methods that are no longer required
- good for Truffle partial evaluation and JVM inlining
- revert a85a173faa except for added tests
- move `VmUtils.setOwner` and `VmUtils.setReceiver` and make them private
- these methods aren't generally safe to use
Result:
- simpler code with greater optimization potential
- VmListingOrMapping can now have both a type node and new members
- fewer changes to surrounding code
- smaller memory footprint
- better performance in some cases
- fixes https://github.com/apple/pkl/issues/785
- fixes https://github.com/apple/pkl/issues/823
Potential future optimizations:
- avoid lazy type checking overhead for untyped listings/mappings
- improve efficiency of forcing a typed listing/mapping
- currently, lazy type checking will traverse the parent chain once per member,
reducing the performance benefit of shallow-forcing
a listing/mapping over evaluating each member individually
- avoid creating an intermediate untyped listing/mapping in the following cases:
- `new Listing<X> {...}`
- amendment of `property: Listing<X>`
This fixes an issue where certain modules tasks fail due to the plugin
attempting to analyze their imports, but the arguments may not actually be
Pkl modules.
For example, the pkldoc task accepts entire packages in its "sourceMoules" property.
This changes the gather imports logic to only analyze file-based modules.
This is also a performance improvement; non file-based modules are unlikely to import
files due to insufficient trust levels.
Also: fix a bug when generating pkldoc on Windows
Motivation:
The following expression evaluates to 2 instead of 1:
new Listing { "value" } { [0 + 0] = "override" }.length
Changes:
- fix length computation in EntriesLiteralNode
- improve `api/listing` tests
- make snippet test failures diffable in IntelliJ
Result:
- fixes https://github.com/apple/pkl/issues/780
- improved dev experience in IntelliJ
This fixes issues when a mapping/listing delegates to another mapping/listing.
The core issue is that `cachedValues` is not guaranteed to be the complete set
of the object's members; they may be stored on the delegate instead.
Therefore, it's not correct compute hash code and equality based on `cachedValues`.
Instead, it's better to use the `getCachedValue()` method, which has the correct
logic for looking up the existing cached value.
- change line numbers from blue to faint to improve legibility on dark backgrounds
- use EnumSet throughout
- move all ANSI classes into package core.util (no need to split them over util and runtime)
- rename AnsiCodingStringBuilder to AnsiStringBuilder
Any thrown Pkl Errors are colored in the simple test report!
Also:
* Refactor `TextFormatter` to be more generic; rename to `TextFormattingStringBuilder`
* Adjust test report slightly (no emojis, add more spacing).
* Introduce `ColorTheme` class.
* Make stack frame descriptors colored as "faint"
Also: this changes the summary so it summarizes _all_ modules, rather than a summary per module.
---------
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
Co-authored-by: Philip K.F. Hölzenspies <holzensp@gmail.com>
GraalVM for JDK 17.0.12 is the final Critical Patch Update
made available under the GraalVM Free Terms and Conditions license.
Subsequent Critical Patch Updates require a commercial license.
* Encapsulate message transport by removing `ExternalReaderProcess.getTransport` and adding `getModuleResolver` and `getResourceResolver` methods
* Reuse `Random` instances within `ExternalReaderProcessImpl` and module/resource resolvers
* Externalize all `ExternalReaderProcessException` messages
* Add some missing doc comments to `ModuleKeyFactories` and `ResourceReaders` methods for external readers
* Move org.pkl.core.util.Readers to org.pkl.core.Readers
There is currently a bug around resolving variables within the iterable of a for
generator or spread syntax (https://github.com/apple/pkl/issues/741)
Normally, mappings/listings are type-checked lazily. However, this results in the said
bug getting widened, for any object members declared in the iterable.
As a workaround for now, prevent the bug from being any worse by ensuring that these
object members are eagerly typechecked.
- keep implementation classes internal to their packages
- make classes final if possible
- make namespace classes non-instantiable
- throw IllegalStateException instead of ExternalReaderProcessException for use after close
- common convention already used by HttpClient etc.
- programming errors should be signaled with unchecked exceptions
- use private instead of public lock object
- polish Javadoc
- delete commented out code
- don't use star import for a single class
* Add `values` to `Mapping`
* Add `entries` to `Mapping`
* Add `containsValue` to `Mapping`
* Add `every` to `Mapping`
* Add `any` to `Mapping`
* Add `toDynamic` to `Mapping`
* Add `lastIndex` to `Listing`
* Add `getOrNull` to `Listing`
* Add `first` to `Listing`
* Add `firstOrNull` to `Listing`
* Add `last` to `Listing`
* Add `lastOrNull` to `Listing`
* Add `single` to `Listing`
* Add `singleOrNull` to `Listing`
* Add `contains` to `Listing`
* Add `any` to `Listing`
* Add `every` to `Listing`
* Fixup `any` to `Listing`
* Revert "Add `toDynamic` to `Mapping`"
This reverts commit 5551974ecd8110aa2eb8f546e992c32d3181df9b.
* Revert "Add `values` to `Mapping`"
This reverts commit 6fc78796
* Revert "Add `entries` to `Mapping`"
This reverts commit a7e8dfc4
* Annotate new members with `Since` 0.27
* Fix documentation in `base.pkl`
* Add location information to empty/single checks in `Listing` operations
* Remove additional variable for laziness preservation
* Apply spotless
* Apply suggestions from code review
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com>
---------
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com>
* Load `PklProject` using the same security settings and env vars passed provided via ExecutorSPIOptions
* Handle thrown `PklException` from loading `PklProject` and throw `ExecutorSPIException`
* Handle thrown `PklException` of older Pkl distributions, converting them into `ExecutorSpiException`
Changes:
* Move class `TestResults` to package `org.pkl.core`, because it is a public class (it's the result of `Evaluator#evaluateTest`)
* Change examples to treat individual examples as assertions in the same test. Previously, they were considered different tests with an incrementing number. This better aligns with how facts are treated.
* Change `TestResults` to be a record, and introduce builders.
* Remove "module" test result section (it is not really a section).
* Add javadoc to `TestResults`
* Formatting fix: prefix ✍️ emoji just like we do the ❌ and ✅ emojis
* Consider writing examples as failures, not successes. `pkl test` will exit with code 10 if the only failing tests are due to writing examples.
This adds a new feature, which allows Pkl to read resources and modules from external processes.
Follows the design laid out in SPICE-0009.
Also, this moves most of the messaging API into pkl-core
Motivation:
In Spring Boot 3.0, the annotation type `org.springframework.boot.context.properties.ConstructorBinding`
was deprecated in favor of `org.springframework.boot.context.properties.bind.ConstructorBinding`.
In 3.2, the old annotation type was removed.
As of 3.0, a `@ConstructorBinding` annotation is no longer required/recommended for configuration classes with a single public constructor.
Changes:
Remove generation of `@ConstructorBinding` annotations in codegen-java and codegen-kotlin.
Result:
- Generated code is compatible with Spring Boot 3.x.
(Verified with locally updated pkl-spring.)
- Generated code is no longer compatible with Spring Boot 2.x.
To use Pkl 0.27 and later with Spring Boot 2.x, use Pkl 0.26's code generator.
- Fixes#139.
Motivation:
- Java serialization makes as much sense for module classes as it does for regular classes.
- Offer same Java serialization support as codegen-java.
Changes:
- Move generation of `appendProperty` method and serialization code
into new method `generateCompanionRelatedCode`.
- Improve/fix generation of serialization code.
Result:
Java serialization is also supported for module classes.
Write annotations to project metadata, and provide them to pkl-doc\
The following annotations have meaning for pkl-doc:
* `@Unlisted`: hide package from documentation site
* `@Deprecated`: add deprecated information
Fix a bug where overwriting `output` causes a PklBugException.
This now produces a more helpful message pointing to the actual problem.
Co-authored-by: translatenix <119817707+translatenix@users.noreply.github.com>
Motivation:
Currently, the condition for making a generated Java class instantiable is "class is neither abstract nor stateless".
(An instantiable class receives a public constructor and equals/hashCode/toString/with methods.)
This is inconsistent with Pkl and codegen-kotlin, both of which support instantiation of stateless classes.
Changes:
Widen condition for making a class instantiable to "class is neither abstract nor a stateless final module class".
This is consistent with codegen-kotlin, which generates object declarations (only) for stateless final module classes.
Result:
Stateless classes are instantiable in Pkl, codegen-java, and codegen-kotlin.
