Thread: [Kotlin] Random Permutation

Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 52
  1. #31  
    Registered Member
    Velocity's Avatar
    Join Date
    Jan 2009
    Age
    28
    Posts
    2,028
    Thanks given
    1,013
    Thanks received
    2,376
    Rep Power
    4112
    Quote Originally Posted by JayArrowz View Post
    You could most likely parametrize the tests so you dont have 10 different test cases instead a single test case with multiple params. Other than that seems cool

    https://gist.github.com/catalinsgh/5...lidatortest-kt

    Edit:

    Why are you testing constants lol? Unit tests are meant to test a single unit of your OWN functionality not if kotlin adheres to keeping a constant a constant :\:

    Code:
       @Test
    	fun testConstants() {
    		assertEquals(1_0_1_3_9_0_4_2_2_3, RandomPermutation.c)
    		assertEquals(1_6_6_4_5_2_5, RandomPermutation.a)
    	}
    legit wouldn't be fucking surprised anymore since nothing in Kotlin is as reliable as once was
    xxxxxxx
    Reply With Quote  
     

  2. Thankful user:


  3. #32  
    Community Veteran


    Join Date
    Dec 2008
    Posts
    4,263
    Thanks given
    405
    Thanks received
    436
    Rep Power
    1674
    Quote Originally Posted by Tyluur View Post
    This is the same energy that started project insanity.
    What's that? Not wanting to change mathematical constants that if changed break the entire backing algorithm?
    Reply With Quote  
     

  4. #33  
    Registered Member
    Tyluur's Avatar
    Join Date
    Jun 2010
    Age
    26
    Posts
    5,103
    Thanks given
    1,818
    Thanks received
    1,767
    Rep Power
    2438
    Quote Originally Posted by Velocity View Post
    legit wouldn't be fucking surprised anymore since nothing in Kotlin is as reliable as once was
    What are you drinking mate imma need me some of that. Kotlin is mad juicy.

    Quote Originally Posted by Gluon View Post
    What's that? Not wanting to change mathematical constants that if changed break the entire backing algorithm?
    Yeah that’s the energy i’m talking about.
    Quote Originally Posted by blakeman8192 View Post
    Keep trying. Quitting is the only true failure.
    Spoiler for skrrrrr:

    Attached image
    Reply With Quote  
     

  5. #34  
    Extreme Donator

    JayArrowz's Avatar
    Join Date
    Sep 2008
    Posts
    104
    Thanks given
    99
    Thanks received
    107
    Rep Power
    810
    Quote Originally Posted by Velocity View Post
    legit wouldn't be fucking surprised anymore since nothing in Kotlin is as reliable as once was
    Yeh i see regular updates happening for Kotlin and loads of bugs with those updates....
    Reply With Quote  
     

  6. #35  
    Community Veteran


    Join Date
    Dec 2008
    Posts
    4,263
    Thanks given
    405
    Thanks received
    436
    Rep Power
    1674
    Quote Originally Posted by JayArrowz View Post
    Yeh i see regular updates happening for Kotlin and loads of bugs with those updates....
    It's not so much the bugs but the code kotlin compiles into. Take a look at basic kotlin byte code and prepare to be amazed. It's a shame because kotlin is one of the most visually beautiful languages I've used.
    Reply With Quote  
     

  7. #36  
    Renown Programmer
    Bartvh's Avatar
    Join Date
    May 2017
    Posts
    370
    Thanks given
    89
    Thanks received
    208
    Rep Power
    497
    Quote Originally Posted by Gluon View Post
    It's not so much the bugs but the code kotlin compiles into. Take a look at basic kotlin byte code and prepare to be amazed. It's a shame because kotlin is one of the most visually beautiful languages I've used.

    What is so bad about Kotlin generated bytecode?
    Attached image
    Guthix Open Source Emulation Framework
    Reply With Quote  
     

  8. #37  
    Registered Member
    Velocity's Avatar
    Join Date
    Jan 2009
    Age
    28
    Posts
    2,028
    Thanks given
    1,013
    Thanks received
    2,376
    Rep Power
    4112
    Quote Originally Posted by Bartvh View Post
    What is so bad about Kotlin generated bytecode?
    due to their null-safety (which on its own is redundant: the jvm spits nullpointer exception upon access of a nullpointer already), they generate null checks in about every statement (first accesses primarily), but to take it a step further, their optimization in most range and for-operations is non-existent (you can check some cases by compiling and then using `javap -c ClassName` to inspect the generated code).

    things like "inline classes" rarely get inlined (in your codebase you have inline classes for ZoneUnit if I'm not mistaken which do not get inlined and will in the runtime be real allocs) and operator overloads with simple bytecode ops become real method calls with all associated overhead instead of "IADD", or similar
    xxxxxxx
    Reply With Quote  
     

  9. Thankful user:


  10. #38  
    Renown Programmer
    Bartvh's Avatar
    Join Date
    May 2017
    Posts
    370
    Thanks given
    89
    Thanks received
    208
    Rep Power
    497
    Quote Originally Posted by Velocity View Post
    due to their null-safety (which on its own is redundant: the jvm spits nullpointer exception upon access of a nullpointer already), they generate null checks in about every statement (first accesses primarily), but to take it a step further, their optimization in most range and for-operations is non-existent (you can check some cases by compiling and then using `javap -c ClassName` to inspect the generated code).
    I think the null-safety in Kotlin is probably one of its strengths. The fact that it is redundant doesn't matter. Every language has concepts that are redundant, but just make it easier for the developers.
    This is the first time I heard about the for-operations/ranges issue. I tried some simple cases and couldn't find any evidence of this.
    things like "inline classes" rarely get inlined (in your codebase you have inline classes for ZoneUnit if I'm not mistaken which do not get inlined and will in the runtime be real allocs)
    That's not true. Also, inline classes are experimental and will improve in 1.5.
    Attached image
    Guthix Open Source Emulation Framework
    Reply With Quote  
     

  11. Thankful users:


  12. #39  
    Registered Member
    Tyluur's Avatar
    Join Date
    Jun 2010
    Age
    26
    Posts
    5,103
    Thanks given
    1,818
    Thanks received
    1,767
    Rep Power
    2438
    Quote Originally Posted by Velocity View Post
    due to their null-safety (which on its own is redundant: the jvm spits nullpointer exception upon access of a nullpointer already), they generate null checks in about every statement (first accesses primarily), but to take it a step further, their optimization in most range and for-operations is non-existent (you can check some cases by compiling and then using `javap -c ClassName` to inspect the generated code).

    things like "inline classes" rarely get inlined (in your codebase you have inline classes for ZoneUnit if I'm not mistaken which do not get inlined and will in the runtime be real allocs) and operator overloads with simple bytecode ops become real method calls with all associated overhead instead of "IADD", or similar
    The alternative in most cases is Java... :/
    Quote Originally Posted by blakeman8192 View Post
    Keep trying. Quitting is the only true failure.
    Spoiler for skrrrrr:

    Attached image
    Reply With Quote  
     

  13. #40  
    [Kotlin] Random Permutation



    Scu11's Avatar
    Join Date
    Aug 2007
    Age
    30
    Posts
    16,307
    Thanks given
    7,215
    Thanks received
    12,308
    Rep Power
    5000
    Quote Originally Posted by Velocity View Post
    due to their null-safety (which on its own is redundant: the jvm spits nullpointer exception upon access of a nullpointer already)
    how is it redundant to turn a problem that was traditionally found at runtime into a compile time problem..?

    Quote Originally Posted by Velocity View Post
    things like "inline classes" rarely get inlined
    this is only true if you don't understand the limitations of inline classes. i've inlined plenty, e.g. the Position/Coord class can be inlined and backed by a simple Int, and confirmed that all usages of it have definitely been inlined by decompiling the resultant bytecode.
    Last edited by Scu11; 01-16-2021 at 03:36 PM.

    Attached image
    Reply With Quote  
     

  14. Thankful users:


Page 4 of 6 FirstFirst ... 23456 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Some Random Events
    By Eleclion in forum Tutorials
    Replies: 4
    Last Post: 05-15-2007, 11:38 PM
  2. Guardian Random Events
    By Eleclion in forum Tutorials
    Replies: 3
    Last Post: 05-12-2007, 08:21 PM
  3. Some Random S**t
    By Darklordants Evil Bro in forum Showcase
    Replies: 2
    Last Post: 04-13-2007, 09:42 PM
  4. A few Random Renders...
    By oblak10 in forum General
    Replies: 2
    Last Post: 04-02-2007, 04:31 AM
  5. my latest sigs :D and random GFX
    By Oblak Lol in forum Showcase
    Replies: 10
    Last Post: 03-31-2007, 10:41 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •