Re: [ANN] Deeto - A Java dynamic proxy factory for interface-typed data transfer objects

[gvim]

Sounds like everything I escaped from when I discovered Clojure.

gvim

On 03/07/2019 22:38, henrik42 wrote:

Hi everyone,

I'm pleased to announce the release of Deeto 0.1.0 [1]

Deeto is a Clojure library for Java developers. With Deeto you can
define your data transfer object types via interfaces in Java. You do
not need to implement these interfaces. Instead you can ask Deeto to
analyze (via reflection) the interface class and then give you a
factory for it.

Deeto returns Java dynamic proxys which implements `Cloneable` and
`Serializable`. The proxy has sane `equals`, `hashCode` and `clone`
implemetations.

It's available now on Clojars.

Henrik

[1] https://github.com/henrik42/deeto/tree/0.1.0

--
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
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/51f21a20-ae63-449d-a126-5d5545ab876a%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/5D1D43E5.2090903%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Deeto - A Java dynamic proxy factory for interface-typed data transfer objects

[henrik42]

Hi everyone,

I'm pleased to announce the release of Deeto 0.1.0 [1]

Deeto is a Clojure library for Java developers. With Deeto you can
define your data transfer object types via interfaces in Java. You do
not need to implement these interfaces. Instead you can ask Deeto to
analyze (via reflection) the interface class and then give you a
factory for it.

Deeto returns Java dynamic proxys which implements `Cloneable` and
`Serializable`. The proxy has sane `equals`, `hashCode` and `clone`
implemetations.

It's available now on Clojars.

Henrik

[1] https://github.com/henrik42/deeto/tree/0.1.0

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/51f21a20-ae63-449d-a126-5d5545ab876a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: core.async: Unbound channels

[Ghadi Shayban]

(chan) is not a channel with an unbounded buffer. It is a channel with *no* 
buffer and needs to rendezvous putters and takers 1-to-1.  (Additionally it 
will throw an exception if more than 1024 takers or putters are enqueued 
waiting)

On Wednesday, July 3, 2019 at 7:14:46 AM UTC-4, Ernesto Garcia wrote:
>
> You can create a unbound channel with (chan), but not if you use a 
> transducer; (chan nil (filter odd?)) will raise an error that no buffer 
> is provided. Why is this the case?
>
> Why the enforcement of all channels to be bound? In a program, there will 
> be channels that propagate to other channels, so only channels at the 
> boundaries would require to be bound?
>
> Channel limits are also much dependent on the particular process and 
> environment. How would we write generic code that creates channels, if 
> those need to be bound to limits unknown?
>
> Thanks,
> Ernesto
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/12cf0bf8-dafd-429b-a2d2-3875f579f1c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[Chris Nuernberger]

OK that makes more sense, BeamFn is not an interface. I imagine they argued
about that decision at some point.

In your example, MyFn looks to be a general class as it can work with any
clojure var. Do you have a package with many of these type of stub classes
defined? I mean, you could name it BeamFnIntegerString thus encoding the
specializations of the baseclass into the type. One of my questions was
about the range of types that end up specializing the BeamFn<>.

Great link about the proxy attack, that is very interesting.  I want to
dive into that one a bit more.

On Tue, Jul 2, 2019 at 8:14 PM atdixon  wrote:

> I'm glad someone else is thinking on this too!
>
> #2 - For my case at the moment (Apache Beam), I believe we will always
> know the types in advance so using a Java class is workable but of course a
> (proxy++) would be ideal. Beam asks for us to extend abstract generic class
> so we must use (proxy). It also asks for our instances to be Serializable
> (again, proxy explicitly refuses to help here
>  but I believe this, too,
> should be surmountable, without the security implications of that link). In
> any case, what we do looks like this:
>
> // pseudo-ish code
> public class MyFn extends BeamFn implements Serializable
> {
>public MyFn(Var fn) { this.fn = fn; }
>@Override public String invoke(Integer input) { return (String) fn.
> invoke(input); }
> }
>
> On the Clojure side:
>
> ;; pseudo-ish code
>
> (defn my-fn [^Integer val] ...return a string...)
>
> ...
>(register-beam-step (MyFn. #'my-fn))
> ...
>
> Note how we pass the Clojure function as a Var; this is b/c Beam wants to
> send the function over the wire. IFn is not serializable; Var is however
> and can be resolved back to Clojure function on the other end during
> deserialization.
>
> Now of course this whole dance could be eliminated with a specialized
> library that included a proxy++ function that included the ability for
> clients to specify generic type parameter values and serialization support
> (the mechanics of which would need ironing out but I think should be
> possible.)
>
> And to your point about types not known at runtime... this proxy would
> support that use case on-the-fly, which opens a bunch of possible
> interesting options, as well.
>
>
> On Tuesday, July 2, 2019 at 8:24:41 PM UTC-5, Chris Nuernberger wrote:
>>
>> eglue,
>>
>> 1.  I think this is a great idea if it is really necessary.  I would be
>> in favor of a reify++ alone to simplify things.  I find reify amazing at
>> code compression and heavily use it via type specific macros to implement
>> interfaces that for instance support a particular primitive type.
>> 2.  Is a possible workaround to define java interfaces that implement the
>> type specific generic interfaces and then reify those explicitly or is the
>> set of possible interface specialization types unknown a-priori?
>> 3.  The case where something is unbounded or unknown a-priori I would
>> think would often end up with a java class as on of the specializations.
>> In this case, regardless of the cause, one answer might be an upgraded
>> reify pathway.
>> 4.  Are these perhaps cases where you can create just a little bit of
>> java as a generator somehow to generate the interface you need to reify?
>>
>>
>> I would personally find reify a much nicer pathway than calling clojure
>> vars from java.
>>
>> I also think there could be low hanging fruit (or just good unknown
>> libraries) in the pathway for calling clojure vars from java.
>>
>>
>> Interesting problem (at least to me), thanks!
>>
>> On Thu, Jun 20, 2019 at 10:03 PM eglue  wrote:
>>
>>> Don't get me wrong, I'm as much against types as the next R̶i̶c̶h̶
>>> ̶H̶i̶c̶k̶e̶y̶  guy.
>>>
>>> However -- there are many popular Java frameworks that love to reflect
>>> on their annotations and their generic type signatures.
>>>
>>> To name a heavyweight: Spring. But also, of late: big data frameworks,
>>> many written in Java, love reflecting on generic type signatures. My org is
>>> looking at Beam and Flink, for example.
>>>
>>> These frameworks use types not for the static checking really but as
>>> parameters governing their own dynamic behavior. For example, Spring will
>>> use types at runtime to simply match objects to where they should be
>>> dynamically injected. Beam will look at your type signatures and do runtime
>>> validations to ensure it can process things appropriately. Of course this
>>> is unfortunate, using types this way, when it is all really just data.
>>> Clojure does -- or would do -- it better, simpler, directer, and all of
>>> that.
>>>
>>> Yet we would like to leverage these frameworks. Or rather, we must for
>>> various pragmatic and business reasons.
>>>
>>> And any time we need to "communicate" to these frameworks "through"
>>> their desired fashion of generic types and annotations, we can, of course,
>>> create the appropriate .java files to represent 

Re: Clojure is a good choice for Big Data? Which clojure/Hadoop work to use?

[Thad Guidry]

"The best code is never written"

https://zeppelin.apache.org/
https://nifi.apache.org/

Thad
https://www.linkedin.com/in/thadguidry/


On Tue, Jul 2, 2019 at 11:07 AM orazio  wrote:

> Hi All,
>
> I'm newbie on Clojure/Big Data, and i'm starting with hadoop.
> I have installed Hortonworks HDP 3.1
> I have to design a Big Data Layer that ingests large iot datasets and
> social media datasets, process data with MapReduce job and produce
> aggregation to store on HBASE tables.
>
> For now, my focus is addressed on data processing issue. My question is:
> Is Clojure a good choice for distributed data processing on hadoop ?
> I found Cascalog as fully-featured data processing and querying library
> for Clojure or Java. But are there any active maintainers, for this library
> ?
> Do you know other excellent clojure/Hadoop work in the community, abaout
> data processing?
>
> I would appreciate some help.
>
> Orazio
>
> --
> 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
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/fbc26ffb-5f00-46a7-bf33-7a899f1ffead%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAChbWaMv3UM2jkjPFfBgoXSP3ApgHHo3f3i-hZ_FAxa%2BsP-DtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

core.async: Unbound channels

[Ernesto Garcia]

You can create a unbound channel with (chan), but not if you use a 
transducer; (chan nil (filter odd?)) will raise an error that no buffer is 
provided. Why is this the case?

Why the enforcement of all channels to be bound? In a program, there will 
be channels that propagate to other channels, so only channels at the 
boundaries would require to be bound?

Channel limits are also much dependent on the particular process and 
environment. How would we write generic code that creates channels, if 
those need to be bound to limits unknown?

Thanks,
Ernesto

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/0fb4746a-ff0a-457a-99fd-8763ab526efd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.