<lopex[m]> the question is is it just prompted gpt thingy ?
sagax has quit [Excess Flood]
PavanNambi[m] has joined #jruby
<headius> Hello!
<headius> Pavan Nambi: hi there! Do you have a project that you are interested in?
<PavanNambi[m]> if i can be honest no i dont have as of now
<PavanNambi[m]> thinking of this Ruby 3.2 features and spec tests
<headius> In general You should only need a knowledge of Java and Ruby at some level, and obviously some experience running the JVM and building Java based stuff
<PavanNambi[m]> i am well aware of java and ruby atleast some what
<PavanNambi[m]> so like what should be my approach here...
<PavanNambi[m]> cloning repo and going through sourcecode..? or read documentation first...?
<headius> You can certainly look at the code but there is a lot of it. I can give you a couple key classes to look at to get a feel for things
<PavanNambi[m]> that would be great!
<headius> Ok, most of the main Ruby classes are implemented in here: https://github.com/jruby/jruby/tree/master/core/src/main/java/org/jruby
<headius> RubyString is the String class, RubyArray is the Array class, and so on
<headius> you can look through some of these to see how we implement their logic, and then mark them as being Ruby methods with @JRubyMethod
<headius> like Hash#[], the accessor method for something like my_hash[:foo], starts here: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyHash.java#L1307-L1311
<headius> if you are interested in parser or compiler side of things we can show you some of that too
<headius> I did a little cleanup of the ideas page here: https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List-(2023)#jruby
<PavanNambi[m]> <headius> "I did a little cleanup of the..." <- this looks really nice.. thanks
<PavanNambi[m]> <headius> "Ok, most of the main Ruby..." <- thankyou! i will check them out and ask if i have any doubts!
<enebo[m]> Pavan Nambi: Are you familiar with dtoa and floating point representation?
<PavanNambi[m]> <headius> "like Hash#[], the accessor..." <- hey yeahhh i am actually going through crafting interpreters book ,so this is nice
<PavanNambi[m]> enebo[m]: yes!
<PavanNambi[m]> * interpreters book https://craftinginterpreters.com/ ,so this
<enebo[m]> we need a license-friendly backend for floats/doubles for our printf implementation
<PavanNambi[m]> * hey yeahhh i am actually going through crafting interpreters book https://craftinginterpreters.com/ ,so this is nice
<PavanNambi[m]> edit: ig i quoted wrong msg here
<enebo[m]> so writing one is a guaranteed way of doing that
<enebo[m]> I have been looking at grisu2 as part of that
<PavanNambi[m]> EDIT: ig i quoted wrong msg here
<PavanNambi[m]> * hey yeahhh i am actually going through crafting interpreters book https://craftinginterpreters.com/ ,so this is nice
<enebo[m]> One historical issue is our printing of floats sometimes goes off the rails compared to C ruby and we get weird values 4.0000000000000235 vs 4.0
<PavanNambi[m]> https://github.com/romange/Grisu this..?
<enebo[m]> This is the paper but this paper outlines grisu and grisu2
<PavanNambi[m]> oh thanks!
<enebo[m]> The thing is some algorithms give an optimal answer quickly and if it can't you then I guess fall over to another method
<enebo[m]> " As a consequence Grisu2 sometimes
<enebo[m]> outside the conservative approximation"
<enebo[m]> fails to return the shortest optimal representation which could lie
<enebo[m]> but I am not sure I care that much as a first swipe
<enebo[m]> I guess the unknown is how much this happens and whether C Ruby will mismatch as much
<enebo[m]> So there is a little bit of an unknown
<PavanNambi[m]> we can use multiple algorithms..?
<PavanNambi[m]> like grisu2 as default
<enebo[m]> C Ruby will use native dtoa but I think they ship an old BSD one for platforms without
<enebo[m]> I think that is a question to be answered
<enebo[m]> The other obvious approach we could do is use jnr-posix (or FFI) to call dtoa natively to compare
<headius> native call would be nice to have as an exactly compatible option
<headius> in any case
<headius> it won't be as fast as a Java/JVM-based option of course but we'd have to evaluate that
<enebo[m]> Pavan Nambi: The other side of the dtoa is that it is part of the larger project of reimplementing printf
<enebo[m]> I have a partial branch of that already but getting the properly formatted float then needs to be broken up and formatted correctly
<enebo[m]> new_printf is a branch and it has most integral types working but needs dtoa to continue work on all the other formats like %efgp
<PavanNambi[m]> ohh i believe this is what you are referring to right?
<PavanNambi[m]> ig i will start by looking at classes provided by charles(headius) and get idea of things
<PavanNambi[m]> thankyou for all the responses!
<PavanNambi[m]> * ig i will start by looking at classes provided by charles(headius) and get idea of things , i mean i believe i should know what i am dealing with before doing anything else
<PavanNambi[m]> thankyou for all the responses!
<headius> sounds good!