<< Back to previous view

[DPRIMAP-8] Add clojurescript support Created: 05/May/15  Updated: 29/Nov/15

Status: Open
Project: data.priority-map
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Daniel Compton Assignee: Mark Engelberg
Resolution: Unresolved Votes: 0
Labels: None


 Description   

With the upcoming release of Clojure 1.7 and reader conditionals, is there interest in adding ClojureScript support? There is already a port at https://github.com/tailrecursion/cljs-priority-map. Alan Dipert may be interested in donating that to Clojure Core, otherwise I would be interested in working on a port.



 Comments   
Comment by Mark Engelberg [ 07/May/15 4:14 AM ]

I agree this is worthwhile, and working off of the existing port might help considerably. Do you want to take the lead in asking Alan Dipert and figuring out how to use the reader conditionals effectively to merge the two?

Comment by Tim Visher [ 16/Nov/15 4:00 PM ]

Are we still interested in doing this?

Comment by Mark Engelberg [ 16/Nov/15 11:17 PM ]

I am still supportive of the idea, but don't have time to do it myself right now.

Comment by Tim Visher [ 17/Nov/15 4:00 PM ]

Awesome. I'm digging in to this now. I just opened a different issue to try to get line endings together. http://dev.clojure.org/jira/browse/DPRIMAP-9

Comment by Tim Visher [ 17/Nov/15 5:24 PM ]

What would we like to do as far as clojure version support? If we were ok with dropping support for version prior to 1.7 then I could use `cljc` to target both platforms. If we want to maintain support for prior versions then I'll have to use a different approach.

Thoughts?

Comment by Mark Engelberg [ 17/Nov/15 11:52 PM ]

I said in my earlier comment that, "I think it is worthwhile," and that comment was driven entirely by the sense that "cljc is what modern Clojure libs are expected to do". But the more I think about it the more I realize that it's not entirely clear what we gain by merging the clojure and clojurescript versions, especially since this code is almost exclusively about implementing protocols and interfaces that are completely different between Clojure and Clojurescript, so there is very little code in common. It's also unclear, since the code has so little in common, that it will be any easier to maintain or extend the code in one combined file versus two separate files. On top of that, priority map has changed very little in the past several years since its creation, and will likely have very few changes in the future.

Therefore, I'm starting to feel skeptical that it is worth the effort and the risk of introducing bugs, but to the extent that you're interested in exploring this issue, I think cljc is the way to go.

So before you dive into it, let me ask you your opinion: what are the gains of mashing the two files together into one cljc file?

Comment by Tim Visher [ 26/Nov/15 6:58 AM ]

I think it's worthwhile if only because that would give 'official' contrib support to clojurescript. I'm mostly interested in this because I need a priority queue in a project I'm on and I'd also like to experiment with cljc. So this is partly a learning exercise and partly a practical effort.

That said I am quite surprised at how different the type declarations are. I was assuming I'd be able to just swap out some types using #? but the implementations are quite different. I can't decide yet how much of it I'll be able to unify, but I'm hoping it's quite a bit.

So I guess whether you accept it or not I'd like to go through the exercise.

I assume implicit in what you've said above is the acceptance of a minimum supported version of 1.7?

Comment by Mark Engelberg [ 28/Nov/15 4:07 PM ]

Yes, I'm fine with a minimum supported version of 1.7.

Comment by Alex Miller [ 29/Nov/15 9:57 PM ]

FYI, currently our Hudson CI system that is used to do builds of contrib projects cannot build cljc projects. To build, a new version of clojure-maven-plugin is required, which requires Maven 3 for some of the required plugins, which is not supported in the old version of Hudson we're using.

This is fairly high in my priority list as we are already fighting this issue for test.check (and it's only a matter of time before it's needed for others as well). But you might want to hold off till we've addressed this issue.

It is possible to manually build and release projects without the CI server (and I've done this for test.cehck), but it's no picnic.





[DPRIMAP-3] Add more developer info and Markdown markup to README Created: 02/Apr/13  Updated: 02/Apr/13

Status: Open
Project: data.priority-map
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Mark Engelberg
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File dprimap-readme-touchups-patch-v1.txt    
Patch: Code

 Description   

Just a bit more tweaking of the README.



 Comments   
Comment by Andy Fingerhut [ 02/Apr/13 1:19 PM ]

Patch dprimap-readme-touchups-patch-v1.txt

To see how these changes look on Github, see my forked version here:

https://github.com/jafingerhut/data.priority-map/tree/cleanup-readme





[DPRIMAP-5] Add support for subseq, rsubseq Created: 28/Apr/13  Updated: 28/Apr/13

Status: Open
Project: data.priority-map
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Mark Engelberg
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File dprimap-5-add-support-for-subseq-rsubseq-patch-v1.txt    
Patch: Code and Test

 Description   

This depends upon some kind of change to clojure.core, either to the Sorted interface or the implementation of subseq and rsubseq, as discussed in this thread: http://groups.google.com/group/clojure-dev/browse_thread/thread/fdb000cae4f66a95

There is a ticket CLJ-428 for these proposed clojure.core changes.



 Comments   
Comment by Andy Fingerhut [ 28/Apr/13 2:25 AM ]

Patch dprimap-5-add-support-for-subseq-rsubseq-patch-v1.txt dated Apr 28 2013 depends upon Mark Engelberg's "inclusive" patch for CLJ-428, or something similar, being accepted into clojure.core.

It mostly just uncomments some code that Mark wrote, but also slightly modifies the implementation of seqFrom to take advantage of that new parameter.





Generated at Thu Sep 29 22:20:21 CDT 2016 using JIRA 4.4#649-r158309.