Comments (4)
Thanks for the great suggestion.
I had already thought about it, and to proceed here, we would first need to resolve JVM dependencies. Some dependencies (namely kravis and krangl) could be moved easily into a jvm-module as they do not contribute to the core of the library. What's harder to resolve are
- PriorityQueue (for which there is no kotlin countpart afaik). This relates to #48 because using some half-baked replacement is likely to impact performance significantly.
- commons-math3:3.6.1 - Distributions support is crucial imho, so this would need to be migrated to something such a kmath or similar. Certainly doable but quite some work I think.
Once JVM dependencies have been removed, I'd be all in and ears to migrate the build system. I have no prior experience with multiplatform yet.
We could explore the refactoring in a separate branch I think, to allow me to evolve the core library independently until such a fix is complete.
from kalasim.
Thanks @holgerbrandl!
Instead of trying to remove JVM dependencies before proceeding, I think the first step could be to migrate the project to a multiplatform project that only targets JVM. Once that's done it becomes easier to try and resolve JVM specific issues, either with...
- alternative libraries (simpler, but adds additional dependencies),
- or by wrapping the JVM specific code with specific expect/actual code (might lead to different behaviour on platforms, so it would require specific testing),
- or porting code to a Kotlin-common implementation (more reliable behaviour, but more code to maintain).
Anyway, say the word and, if you'd like, I can start updating the Gradle config? 👍
from kalasim.
I've done some digging and these are the libraries that are not multiplatform compatible.
- org.apache.commons.math3.distribution (as you already noted)
- com.github.holgerbrandl.jsonbuilder (replace with Kotlinx Serialization?)
- org.jetbrains.kotlinx.dataframe (seems to be JVM/JS only)
- Java utils + associated functions (e.g.
PriorityQueue
,Map.merge()
,Map.putIfAbsent()
,ThreadLocal
,java.awt.geom.Point2D
,java.util.logging.Level
,Thread.sleep()
,UUID
) - There's some reflection based stuff using
javaClass
There are also some JVM specific stuff which can be happily moved to jvmMain
(or a specific subproject?), like the Jupyter notebook integrations.
There's also a notable amount of JUnit code, but that should be quite easily migratable to kotlin.test or Kotest.
from kalasim.
Great analysis. I was not aware of quite some JVM dependencies. To me this also indicates that before revising the build structure, dependencies should be converted one-by-one (starting with the most complex ones) which I guess is non-trivial in some cases (e.g. reflection does not work on multiplatform afaik).
I'd think ordered by amount of work for to port this to KMP the list is
- Reflection (unclear to me if this is possible at all)
- PriorityQueue
- Multithreading support (which is a crucial feature)
- java utils (which is a lot of work)
- json processing
- commons-math
- dataframe could be moved into jvm part, but this severly reduce the usefulness of the library imho
Given the number of JVM dependencies, it is actually imho quite possible that it's not feasible with the few resources available to convert the library into multiplatform, and if so I don't want to end up with a more complex revised build structure that would in such case serve no function, and would need to be rolled back eventually.
JVM bits could be separated in a special package/namespace until everything else is ready to go KMP.
from kalasim.
Related Issues (20)
- State trigger do not trigger
- Wait should allow to provide description
- Optimize MetricTime API
- `display()` should enforce time range in kravis
- Publish call-center as blog article HOT 1
- Add support for DurationUnit in distributions
- Difference of ticktime should be duration and not Double HOT 1
- Remodel distributions API to better support Duration requirements in `hold()` HOT 2
- Override random and shuffled in Component HOT 1
- Enable API quality by using explicitApi HOT 1
- Dark mode documentation HOT 4
- It should fail if both `process` and `repeatedProcess` are implemented by a Component
- It should provide a statistics API for the internal event bus
- All internal events could be opt-in HOT 1
- It fails to resolve the correct component in a branched process HOT 1
- Support all arithmetic ops for scalar timeline operations
- Allow to activate processes more efficiently
- Validate need and impl of keepRequest and keepWait
- Fix test asserts in JoinTests and `join`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kalasim.