Status of Tickets for Release.next
30 views
Skip to first unread message
Christopher Redinger
Apr 26, 2011, 8:30:24 PM4/26/11
to cloju...@googlegroups.com
Hello!
We've been having some discussions around what tickets are going to be included in the next release of Clojure.
We would like to get your feedback on the following tickets.
* dynamic defrecord definitions trumped by AOT versions in classpath
** I have created a design discussion page here: http://dev.clojure.org/display/design/Dynamic+defrecord+definitions+trumped+by+AOT+versions+in+classpath
** If you have opinions about this ticket, please post them there.
* "Numerics tickets"
** bit ops to have primitive semantics by default, no conditionals, direct mapping to JVM primitive ops
** Add support for Big* numeric types to Reflector
** n-ary bit functions, also inlining of n-ary bit and math operations
** Alexander Taggart has created a design page here: http://dev.clojure.org/display/doc/Bit+Operations
* The following tickets have been removed from Release.next and will be handled in a future release:
* If an intrepid developer really wanted to get these into the release, let us know and we can discuss how these could fit into the release plans.
** Data Conveying Exception
** Compiler loses 'loop's return type in some cases
** lazy recursive definition giving incorrect results
** Method/Constructor resolution does not factor in widening conversion of primitive args
The rest of the tickets are being worked on by Core team members as we move closer to a beta release. Stay tuned!
If you'd like to see the status of the remaining open tickets in Release.Next, you can view them here: http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10051
Steve Miner
Apr 27, 2011, 11:39:50 AM4/27/11
to cloju...@googlegroups.com
On Apr 26, 2011, at 8:30 PM, Christopher Redinger wrote:
** Method/Constructor resolution does not factor in widening conversion of primitive args
Correction on link: http://dev.clojure.org/jira/browse/CLJ-445
ataggart
Apr 27, 2011, 2:48:42 PM4/27/11
to Clojure Dev
Note that CLJ-666 is not being worked on (AFAIK). It would have been
fixed via the now-postponed CLJ-445.
For bit-ops and n-ary support, I've made a fork/branch rather than
deal with the back-and-forth of patches. I can make patches once the
changes are agreed upon.
http://github.com/ataggart/clojure/tree/bit-ops
http://github.com/ataggart/clojure/tree/n-ary
As for CLJ-445, I'm breaking up the changes the one mega-patch
introduced. It was simply too large of a change to reason about.
I've made a fork/branch which contains only a step-by-step
reorganization of the code between Compiler and Reflector. The result
is that Reflector has a nicely self-contained, black box API. It would
be swell if this preparatory change was considered.
https://github.com/ataggart/clojure/tree/reorg-reflector
I will be completing the remaining, incrementally documented changes
for CLJ-445 sometime today.
https://github.com/ataggart/clojure/commits/prim-conversion
On Apr 26, 5:30 pm, Christopher Redinger <redin...@gmail.com> wrote:
> Hello!
>
> We've been having some discussions around what tickets are going to be
> included in the next release of Clojure.
>
> We would like to get your feedback on the following tickets.
>
> * dynamic defrecord definitions trumped by AOT versions in classpath
> **http://dev.clojure.org/jira/browse/CLJ-371
fixed via the now-postponed CLJ-445.
For bit-ops and n-ary support, I've made a fork/branch rather than
deal with the back-and-forth of patches. I can make patches once the
changes are agreed upon.
http://github.com/ataggart/clojure/tree/bit-ops
http://github.com/ataggart/clojure/tree/n-ary
As for CLJ-445, I'm breaking up the changes the one mega-patch
introduced. It was simply too large of a change to reason about.
I've made a fork/branch which contains only a step-by-step
reorganization of the code between Compiler and Reflector. The result
is that Reflector has a nicely self-contained, black box API. It would
be swell if this preparatory change was considered.
https://github.com/ataggart/clojure/tree/reorg-reflector
I will be completing the remaining, incrementally documented changes
for CLJ-445 sometime today.
https://github.com/ataggart/clojure/commits/prim-conversion
On Apr 26, 5:30 pm, Christopher Redinger <redin...@gmail.com> wrote:
> Hello!
>
> We've been having some discussions around what tickets are going to be
> included in the next release of Clojure.
>
> We would like to get your feedback on the following tickets.
>
> * dynamic defrecord definitions trumped by AOT versions in classpath
> ** I have created a design discussion page
> here:http://dev.clojure.org/display/design/Dynamic+defrecord+definitions+t...
> ** If you have opinions about this ticket, please post them there.
>
> * "Numerics tickets"
> ** bit ops to have primitive semantics by default, no conditionals, direct
> mapping to JVM primitive ops
> ***http://dev.clojure.org/jira/browse/CLJ-772
>
> * "Numerics tickets"
> ** bit ops to have primitive semantics by default, no conditionals, direct
> mapping to JVM primitive ops
> ** Add support for Big* numeric types to Reflector
> ***http://dev.clojure.org/jira/browse/CLJ-666
> ** n-ary bit functions, also inlining of n-ary bit and math operations
> ***http://dev.clojure.org/jira/browse/CLJ-184
> ** Alexander Taggart has created a design page
> here:http://dev.clojure.org/display/doc/Bit+Operations
>
> * The following tickets have been removed from Release.next and will be
> handled in a future release:
> * If an intrepid developer really wanted to get these into the release, let
> us know and we can discuss how these could fit into the release plans.
> ** Data Conveying Exception
> ***http://dev.clojure.org/jira/browse/CLJ-733
> here:http://dev.clojure.org/display/doc/Bit+Operations
>
> * The following tickets have been removed from Release.next and will be
> handled in a future release:
> * If an intrepid developer really wanted to get these into the release, let
> us know and we can discuss how these could fit into the release plans.
> ** Data Conveying Exception
> ** Compiler loses 'loop's return type in some cases
> ***http://dev.clojure.org/jira/browse/CLJ-701
> ** lazy recursive definition giving incorrect results
> ***http://dev.clojure.org/jira/browse/CLJ-457
> ** Method/Constructor resolution does not factor in widening conversion of
> primitive args
> ***http://dev.clojure.org/jira/browse/CLJ-455
> primitive args
>
> The rest of the tickets are being worked on by Core team members as we move
> closer to a beta release. Stay tuned!
>
> If you'd like to see the status of the remaining open tickets in
> Release.Next, you can view them
> here:http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requ...> The rest of the tickets are being worked on by Core team members as we move
> closer to a beta release. Stay tuned!
>
> If you'd like to see the status of the remaining open tickets in
> Release.Next, you can view them
ataggart
Apr 27, 2011, 2:53:21 PM4/27/11
to Clojure Dev
I've also made a fork/branch correcting a number of casting
deficiencies, and moving unchecked casts into its own ns:
http://github.com/ataggart/clojure/commits/casting
deficiencies, and moving unchecked casts into its own ns:
http://github.com/ataggart/clojure/commits/casting
> Hello!
>
> We've been having some discussions around what tickets are going to be
> included in the next release of Clojure.
>
> We would like to get your feedback on the following tickets.
>
> * dynamic defrecord definitions trumped by AOT versions in classpath
> **http://dev.clojure.org/jira/browse/CLJ-371
>
> We've been having some discussions around what tickets are going to be
> included in the next release of Clojure.
>
> We would like to get your feedback on the following tickets.
>
> * dynamic defrecord definitions trumped by AOT versions in classpath
> ** I have created a design discussion page
> here:http://dev.clojure.org/display/design/Dynamic+defrecord+definitions+t...
> ** If you have opinions about this ticket, please post them there.
>
> * "Numerics tickets"
> ** bit ops to have primitive semantics by default, no conditionals, direct
> mapping to JVM primitive ops
> ***http://dev.clojure.org/jira/browse/CLJ-772
>
> * "Numerics tickets"
> ** bit ops to have primitive semantics by default, no conditionals, direct
> mapping to JVM primitive ops
> ** Add support for Big* numeric types to Reflector
> ***http://dev.clojure.org/jira/browse/CLJ-666
> ** n-ary bit functions, also inlining of n-ary bit and math operations
> ***http://dev.clojure.org/jira/browse/CLJ-184
> ** Alexander Taggart has created a design page
> here:http://dev.clojure.org/display/doc/Bit+Operations
>
> * The following tickets have been removed from Release.next and will be
> handled in a future release:
> * If an intrepid developer really wanted to get these into the release, let
> us know and we can discuss how these could fit into the release plans.
> ** Data Conveying Exception
> ***http://dev.clojure.org/jira/browse/CLJ-733
> here:http://dev.clojure.org/display/doc/Bit+Operations
>
> * The following tickets have been removed from Release.next and will be
> handled in a future release:
> * If an intrepid developer really wanted to get these into the release, let
> us know and we can discuss how these could fit into the release plans.
> ** Data Conveying Exception
> ** Compiler loses 'loop's return type in some cases
> ***http://dev.clojure.org/jira/browse/CLJ-701
> ** lazy recursive definition giving incorrect results
> ***http://dev.clojure.org/jira/browse/CLJ-457
> ** Method/Constructor resolution does not factor in widening conversion of
> primitive args
> ***http://dev.clojure.org/jira/browse/CLJ-455
> primitive args
>
> The rest of the tickets are being worked on by Core team members as we move
> closer to a beta release. Stay tuned!
>
> If you'd like to see the status of the remaining open tickets in
> Release.Next, you can view them
> here:http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requ...> The rest of the tickets are being worked on by Core team members as we move
> closer to a beta release. Stay tuned!
>
> If you'd like to see the status of the remaining open tickets in
> Release.Next, you can view them
Colin Jones
Apr 27, 2011, 3:22:21 PM4/27/11
to cloju...@googlegroups.com
I have a patch for CLJ-666, but it breaks a test currently in master
around the result of `(bit-shift-left 1N 10000)`, so I haven't
submitted it yet. See
http://groups.google.com/group/clojure-dev/browse_thread/thread/2191cbf0048d8ca6
for details.
I'd be happy to do so as-is and modify later (once CLJ-772 is done?),
or to remove or modify the test in question to reflect the desired
behavior if that's more appropriate.
around the result of `(bit-shift-left 1N 10000)`, so I haven't
submitted it yet. See
http://groups.google.com/group/clojure-dev/browse_thread/thread/2191cbf0048d8ca6
for details.
I'd be happy to do so as-is and modify later (once CLJ-772 is done?),
or to remove or modify the test in question to reflect the desired
behavior if that's more appropriate.
Let me know how I should handle it, and I'd be happy to submit this patch.
Thanks!
Colin
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
>
--
Colin Jones
ataggart
Apr 27, 2011, 4:26:53 PM4/27/11
to Clojure Dev
If the test breaks it likely means Numbers.shiftLeft(long,int) was
selected over Numbers.shiftLeft(Object,Object). Given that 1N is an
Object (one that can exceed the size of a long), the method selection
is incorrect, thus the patch is broken.
Can you make the patch available someplace, so I can take a look?
On Apr 27, 12:22 pm, Colin Jones <trptco...@gmail.com> wrote:
> I have a patch for CLJ-666, but it breaks a test currently in master
> around the result of `(bit-shift-left 1N 10000)`, so I haven't
> submitted it yet. Seehttp://groups.google.com/group/clojure-dev/browse_thread/thread/2191c...
selected over Numbers.shiftLeft(Object,Object). Given that 1N is an
Object (one that can exceed the size of a long), the method selection
is incorrect, thus the patch is broken.
Can you make the patch available someplace, so I can take a look?
On Apr 27, 12:22 pm, Colin Jones <trptco...@gmail.com> wrote:
> I have a patch for CLJ-666, but it breaks a test currently in master
> around the result of `(bit-shift-left 1N 10000)`, so I haven't
Colin Jones
Apr 27, 2011, 5:47:23 PM4/27/11
to cloju...@googlegroups.com
On Wed, Apr 27, 2011 at 3:26 PM, ataggart <alexcloj...@gmail.com> wrote:
> If the test breaks it likely means Numbers.shiftLeft(long,int) was
> selected over Numbers.shiftLeft(Object,Object). Given that 1N is an
> If the test breaks it likely means Numbers.shiftLeft(long,int) was
> selected over Numbers.shiftLeft(Object,Object). Given that 1N is an
That's certainly the case.
> Object (one that can exceed the size of a long), the method selection
> is incorrect, thus the patch is broken.
>
Right, the question, then, is how the Reflector should make the
choice. The original request suggested c.l.Reflector.paramArgTypeMatch
was the place for it, so that's what I did.
> Can you make the patch available someplace, so I can take a look?
>
Done. It's attached to the issue.
-Colin
ataggart
Apr 27, 2011, 6:30:51 PM4/27/11
to Clojure Dev
Thanks. As I noted on the ticket, you were thrown a red herring. The
interplay between Reflector and Compiler is ... interesting.
I'd recommend deferring CLJ-666 until the Reflector/Compiler situation
is improved (e.g., CLJ-445).
On Apr 27, 2:47 pm, Colin Jones <trptco...@gmail.com> wrote:
interplay between Reflector and Compiler is ... interesting.
I'd recommend deferring CLJ-666 until the Reflector/Compiler situation
is improved (e.g., CLJ-445).
On Apr 27, 2:47 pm, Colin Jones <trptco...@gmail.com> wrote:
ataggart
Apr 28, 2011, 3:24:51 AM4/28/11
to Clojure Dev
I've opened the following rather severe bugs that should be included:
http://dev.clojure.org/jira/browse/CLJ-781
http://dev.clojure.org/jira/browse/CLJ-782
Both have patches ready for test.
I also have a patch ready for CLJ-771, but it won't apply until the
above changes to numbers.clj get included.
http://dev.clojure.org/jira/browse/CLJ-781
http://dev.clojure.org/jira/browse/CLJ-782
Both have patches ready for test.
I also have a patch ready for CLJ-771, but it won't apply until the
above changes to numbers.clj get included.
ataggart
Apr 28, 2011, 5:28:40 PM4/28/11
to Clojure Dev
Is there going to be any dialog with the Core team on this stuff?
Perhaps it doesn't affect Relevance, but some of us need to work with
bytes.
Perhaps it doesn't affect Relevance, but some of us need to work with
bytes.
> Hello!
>
> We've been having some discussions around what tickets are going to be
> included in the next release of Clojure.
>
> We would like to get your feedback on the following tickets.
>
> * dynamic defrecord definitions trumped by AOT versions in classpath
> **http://dev.clojure.org/jira/browse/CLJ-371
>
> We've been having some discussions around what tickets are going to be
> included in the next release of Clojure.
>
> We would like to get your feedback on the following tickets.
>
> * dynamic defrecord definitions trumped by AOT versions in classpath
> ** I have created a design discussion page
> here:http://dev.clojure.org/display/design/Dynamic+defrecord+definitions+t...
> ** If you have opinions about this ticket, please post them there.
>
> * "Numerics tickets"
> ** bit ops to have primitive semantics by default, no conditionals, direct
> mapping to JVM primitive ops
> ***http://dev.clojure.org/jira/browse/CLJ-772
>
> * "Numerics tickets"
> ** bit ops to have primitive semantics by default, no conditionals, direct
> mapping to JVM primitive ops
> ** Add support for Big* numeric types to Reflector
> ***http://dev.clojure.org/jira/browse/CLJ-666
> ** n-ary bit functions, also inlining of n-ary bit and math operations
> ***http://dev.clojure.org/jira/browse/CLJ-184
> ** Alexander Taggart has created a design page
> here:http://dev.clojure.org/display/doc/Bit+Operations
>
> * The following tickets have been removed from Release.next and will be
> handled in a future release:
> * If an intrepid developer really wanted to get these into the release, let
> us know and we can discuss how these could fit into the release plans.
> ** Data Conveying Exception
> ***http://dev.clojure.org/jira/browse/CLJ-733
> here:http://dev.clojure.org/display/doc/Bit+Operations
>
> * The following tickets have been removed from Release.next and will be
> handled in a future release:
> * If an intrepid developer really wanted to get these into the release, let
> us know and we can discuss how these could fit into the release plans.
> ** Data Conveying Exception
> ** Compiler loses 'loop's return type in some cases
> ***http://dev.clojure.org/jira/browse/CLJ-701
> ** lazy recursive definition giving incorrect results
> ***http://dev.clojure.org/jira/browse/CLJ-457
> ** Method/Constructor resolution does not factor in widening conversion of
> primitive args
> ***http://dev.clojure.org/jira/browse/CLJ-455
> primitive args
>
> The rest of the tickets are being worked on by Core team members as we move
> closer to a beta release. Stay tuned!
>
> If you'd like to see the status of the remaining open tickets in
> Release.Next, you can view them
> here:http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide&requ...> The rest of the tickets are being worked on by Core team members as we move
> closer to a beta release. Stay tuned!
>
> If you'd like to see the status of the remaining open tickets in
> Release.Next, you can view them
Stuart Halloway
Apr 29, 2011, 11:00:46 AM4/29/11
to cloju...@googlegroups.com
Is there going to be any dialog with the Core team on this stuff?
Perhaps it doesn't affect Relevance, but some of us need to work with
bytes.
Hi Alex,
I have added answers inline to all the questions at http://dev.clojure.org/display/doc/Bit+Operations, and the core team is hanging out in IRC. We are still working through the stack of tickets to adjust priorities and to organize the changes in reviewable chunks.
There are some bite-sized pieces (e.g. eliminating negative shifts), if anybody wants to work on them let's coordinate in IRC.
Stu
Reply all
Reply to author
Forward
0 new messages