But maybe I'm wrong.
@david-bouyssie It seams to me that the ambition to elevate technology by sharing in the open is part of the consideration of "fair use" when as a layman trying to interpret the verdict. So as SN is open source and not aimed at competing but rather being an open source complement to things like JVM and GraalVM using a liberal license helps to be categorized as "fair use". In that regard the ruling of the US supreme court is positive as "fair use" is connected to a kind of healthy technological progress, and I guess that would be in line with the intention of EU law as well (but we would need a layer here, who probably would say that it has to be tested in court to be sure).
If this link works. There were 4 criteria including the amount copied which was small. To me this is the key part of the dissent. https://twitter.com/ekrich/status/1379129626312634371?s=21
@bjornregnell I'm working this days a lot of with lawyers in IP fields in EU. Let me be blunt: each country very unique. Technically some decision can be made on EU level, but all directive of EU should be ratified by local parlament or something like this. Usually it is ratified as is but sometime some part of (!) of directive at some countries excluded. The best example which is related to IT is e-invoice. Almost each country has its own format, vendor and so on. :(
@WojciechMazur I am finding porting from 0.4.0-M2 very troublesome because of the C types like CSize/ULong etc. There are no basic arithmetic operator that allow
Int * CSize for example to pass to malloc. We are pretty used to being able to add an int to a long and having the result promoted to a long at least in Scala. Promotion is pretty safe. Of course using unsigned arithmetic is safe if you want to avoid a negative number but the current ergonomics are quite cumbersome. This was the ngram processing which is easy to port but with the new changes I can't get it to work yet - not for this reason but another one.
Anyway, I do have another memory corruption issue: https://gist.github.com/catap/6214e29b23191188432b778d76207842
@WojciechMazur A question, if you please, about handling & respecting Intellectual Property for PRs where the original author is unavailable. PR #1921 adds network datagram (UDP) support to posixlib. The conceptual content certainly Looks Good to Me. The exact textual content needs a rebase because of a later, merged PR which made the case of constants consistent.
It would be nice to do the rebase so that the person doing the merge did not have to do so. Would it be in line with
Scala Native's Intellectual Property guidelines for me to create a new PR, based on and acknowledging PR #1921, and do the rebase? Is there a better way to proceed? I am trying to help a community generated PR get merged rather than create stress. Thank you for your providing direction.
btw in general that's one of the things Mergify can you, you can write
@Mergifyio rebase in a PR comment and it will rebase it
Would it be in line with
Scala Native's Intellectual Property guidelines for me to create a new PR, based on and acknowledging PR #1921, and do the rebase?
If the original author has signed the CLA, then yes.
About scala-native/scala-native#2247
I have no idea how to minimise this test to something that I can share. So, if anyone have any ideas I'd love to hear it.
@WojciechMazur I think this is fine based on my research outlined in the PR, and it works now so I don't think we need to make changes. scala-native/scala-native#2240
If you pass a GC value to some C data structure and it stops being visible from those locations, it's marked as garbage.
To change that you need to make those objects reachable, and that's why your workaround is working: it's making them live through transitive link from top-level object -> hashmap -> element.
Are some of these failures based on my changes? https://github.com/scala-native/scala-native/runs/2298199381?check_suite_focus=true
It could have a C-friendly alloc/free-style interface as well. Here freeing would be equivalent to dropping the value from the hashmap.
More inspiration: https://docs.hpyproject.org/en/latest/api.html#handles
Handles could be reference-counted (with manual inc/dec ref) to allow multiple locations to refer to a single handle.
Did everyone see the blog? https://medium.com/virtuslab/revisiting-scala-native-performance-67029089f241
@WojciechMazur cool blog post on SN performance Thanks for your efforts!! I just added a link to it from here https://github.com/lunduniversity/scalades
And these nested returns (https://github.com/scala-native/scala-native-benchmarks/blob/master/src/main/scala/queens/QueensBenchmark.scala#L50) are compiled as exceptions.
Given that adding exception awareness is likely to increase complexity of the interflow algorithm significantly I'd argue that this benchmark (and the underlying use case of non-local returns) is not interesting enough to pay the cost.
Otherwise very interesting comparisons! The biggest surprise to me is that we use waaaaay less memory than the alternatives.
@densh One other thing. We are very close to a Scala Native build for
scalafmt.
This was always one of my goals to have a real world benchmark.
and my "hack" is something like
Handle[T] to be honest, just some based trial that manage everything.
anyway, it doesn't explains this: scala-native/scala-native#2243
:)
Technically it is very similar to my internal hack.
Can anybody help with adding SN support for scala-java-times and scala-java-locales projects (cquiroz/scala-java-time#45 and https://github.com/cquiroz/scala-java-locales/issues/38) ?