The JavaFX workaround consist of creating a javafx.embed.swing.JFXPanel
statically in a namespace that is loaded before any other namespace that
import problematic JavaFX classes as in [1,2].
This initializes the JavaFX platform.
[1]
https://github.com/halgari/fn-fx/blob/master/src/fn_fx/render
Potentially relevant? I posted a patch two years ago for some static
initialisers still running in 1.8, not yet merged. It was actually the type
hints causing the initialisers to be run at compile time
http://dev.clojure.org/jira/browse/CLJ-1714
On Tue, Mar 28, 2017 at 10:21 AM 'Gunnar Völkel' vi
I do a lot of work with data structures, so this, I think, would be useful
to me.
For the immutable data structures, it seems like they could be done as a
drop-in replacement for the Clojure built-ins. There are a couple new
functions for splitting and concatenating. I'd recommend following
prec
Hi Gunnar,
Yes, I use this trick to get tests to run without starting up an
application. That is a run-time issue.
The problem I'm having is a compile-time issue. That is, errors are thrown
when the compiler hits a gen-class or proxy used to try to extend (some)
JavaFX classes.
--
You receiv
I was wondering if protocols do or will be extended to support specs?
I'm thinking in the two following ways:
1) I can spec a protocol's functions so that whoever implements it has a better
and more complete specification of how it should do so.
2) Protocols can dispatch based on the tagged ent
In my experience, there's definitly still issues with static initializers, even
in 1.8.
I'd recommend you go mixed Java for those use case.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
give clojurians a try on slack. monitoring that and this list i get the
impression that helpful people do not necessarily work both fora.
On Mar 27, 2017 11:00 AM, "lonign via Clojure"
wrote:
> Hi Gregg,
>
> I've have tried them, but have not been able to get anything that will
> compile, let a
>
> Right, except each thread gets its own binding. So it's not necessarily
> that you'll get the value of the last binding up the call stack. This will
> only be true if you are in the same thread also.
The last binding up in the call stack implies that you are in the same
thread, but I thin
Ah yes, I remember this now. It seems like this is a fix that would
definitely help, too, since many (most?) people using serious interop will
be type hinting.
On 28 March 2017 at 23:15, Adam Clements wrote:
> Potentially relevant? I posted a patch two years ago for some static
> initialisers st
>
> which brings up the limitation of implementing dynamically scoped vars
> with ThreadLocal: It would be reasonable to expect that the bindings of
> dynamic vars propagate to all code inside the same function, even if
> executed by a different thread
>
This is not a limitation, this was done
10 matches
Mail list logo
