Clojurians
#cljs-dev
<
2017-11-30
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

dnolen13:11:22

@mfikes thanks!

mfikes16:11:07

It might be nice to have a formal way to indicate that the latest patch in JIRA no longer applies, so they can be filtered out from consideration, or specifically searched for. (Maybe a new label or some such.)

mfikes16:11:43

Part of me thinks this shouldn’t be an issue (that an informal comment would suffice). It just seems like there are a sizable number of JIRA tickets in that state.

mfikes16:11:11

It is about 30 of 107 patches that no longer apply. I suppose that is a significant portion.

rauh16:11:50

I feel like it'd be really useful if into worked with arrays. Clojure would probably have it if JVM arrays were dynamic in size.

rauh16:11:33

Or another idea: We already have (to-array coll), add a (to-array xfrom coll).

dnolen16:11:01

I thought into-array too?

bronsa16:11:29

into-array takes ([coll] [type coll]) on clojure jvm

rauh16:11:30

into-array only takes a (into-array type coll) which is ignored in CLJS

bronsa16:11:37

so not amenable for xducer arity

dnolen16:11:31

doesn’t into seq the collection if necessary?

rauh16:11:37

Or another idea: (into-native dest xform coll) that accepts both: js-objects and js arrays.

dnolen16:11:43

it’s been a while I don’t really remember

dnolen16:11:52

not interested in anything around JS objects

rauh16:11:03

So we could do (into-native #js{} (map #(-> [key val]) soem-coll)

dnolen16:11:11

arrays worth considering if it’s cumbersome, but again I don’t remember this being a problem

dnolen16:11:21

remove into-native from your mind :slightly_smiling_face:

dnolen16:11:23

not going to happen

dnolen16:11:01

I thought we covered ES6 Iterable with transducers

dnolen16:11:11

anyways JS should solve this problem, and we just go on that

rauh16:11:59

@dnolen Yeah we can def. already handle js-arrays as the source, but not as the destination of into. (into (array) xf coll) is what I mean.

dnolen16:11:19

but doing that is trivial anyway

dnolen16:11:25

I don’t think it’s important enough

dnolen16:11:44

all you need to do is provide a proper xf

rauh16:11:02

Yeah it's very easy. It could simplify code in core at a few places. Smaller code and probably faster code.

dnolen16:11:17

I don’t see how it could possibly be faster than doing it yourself

dnolen16:11:27

smaller, you saved 2 lines of code

rauh16:11:32

No proper xf wont' work. I can do it easily with (transduce ) and a proper reducer, correct.

dnolen16:11:32

this just isn’t important

dnolen16:11:04

people who care about such perf fiddly things can deal with it

levitanong17:11:30

So I’m looking for issues to work on, so I’m trying to use the issue filter, but neither “open” nor “unassigned” exactly imply an issue that isn’t being worked on. Is there some other indicator I could use to look for things that need work, but aren’t being worked on?

mfikes17:11:28

@levitanong See https://dev.clojure.org/display/community/Contributing, Issue tracking (JIRA) -> Tracking Tickets (for next release) -> ClojureScript -> Needs Patch link

levitanong17:11:41

Oh excellent! Thanks, @mfikes!

mfikes17:11:29

Nearly all of those aren’t being worked on. If you find a ticket of interest, it might be worth checking the Assignee field as an signal that it might be.

levitanong17:11:34

I’ll just add an additional filter to only look for unassigned :smile:

levitanong17:11:00

Oh, except “This query is too complex to display in Simple mode.”

mfikes17:11:11

@levitanong An alternative is to click on the Assignee header twice to sort Unassigned ones to the top.

levitanong17:11:32

Thanks @mfikes!