Re: scala native, wouldn't it *not* have the optimizing JIT when not on the
JVM, therefore making it potentially slower if the (compiler-based)
optimizer is inferior?
On Thu, Dec 15, 2022 at 11:44 AM Interrante, John A (GE Research, US) <
john.interra...@ge.com> wrote:
> The words "lots of integr
stevedlawrence merged PR #1:
URL: https://github.com/apache/daffodil-extra/pull/1
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@daffod
stevedlawrence opened a new pull request, #1:
URL: https://github.com/apache/daffodil-extra/pull/1
- Fix license to remove subcomponents that don't exist in the extra repo
- Add .asf.yml to configure description, enable bug/wiki/projects, and only
allow rebase merges
--
This is an auto
The words "lots of integrations" comes from the library's README. As Adam
said, integrations seem to be Enumeratum add-on modules which help other Scala
ecosystem major players (Play framework, etc.) use Enumeratum with their own
software. Enumeratum itself supports Scala versions from 2.12 to
For "integrations", it means the enumerations library has support for use
in other libraries like cats, json libraries, HTTP libraries, testing, ORM,
etc., so the user doesn't have to bridge enum support themselves.
On Thu, Dec 15, 2022 at 11:03 AM Mike Beckerle wrote:
> I guess I don't understa
I created the daffodil-extra repository.
This is specifically for examples, tools/utilities, and things that we're
not "creating releases of".
I would not suggest putting DFDL Schemas projects there. If we want to
create a DFDL schema project that is part of the Apache Daffodil effort I'd
suggest
I guess I don't understand what it means for an enumerations library to
have "lots of integrations".
By this do you mean the versions of scala it supports, and the scala native
and scala js?
I think these things are pretty easy to support for a small library with no
dependencies at all.
re: Scala
Since there are no immediate objections, I've created a PR to add this.
I've also discovered that downloads.apache.org and closer.lua and aware
of archives and so we can actually use the same links for all releases,
including those that are archived. That removes one manual step of
changing li
+1
Using direct download links sounds better to me too. Both curl and wget have
curl -o, --output file and wget -O, --output-document=file options to avoid
needing to rename the file after downloading it. We can mention these options
somewhere in the same places where we already mention that
Hi Steve,
As a developer, I like to script things that I need to do repeatedly, to
the extent possible, and regularly use wget and curl. I'm on board with
whatever can be done to make it simple for developers to script fetching
these artifacts with minimal frustration.
+1 for me.
-Davin
On Thu
For linking to the latest release artifacts on our webpage, we currently
use the closer.lua script described here:
https://infra.apache.org/release-download-pages.html
For example, to download the latest source release, our website links here:
https://www.apache.org/dyn/closer.lua/daffodil/
11 matches
Mail list logo