nirvdrum has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 244 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 240 seconds]
ruurd has quit [Quit: bye folks]
Freeky has joined #jruby
lopex[m] has quit [Ping timeout: 272 seconds]
Freaky has quit [Ping timeout: 272 seconds]
Freeky is now known as Freaky
lopex[m] has joined #jruby
<rdubya[m]>
Hey all, I've run into something that I was wondering if it is a known issue or if maybe I am doing something wrong. I'm using `defineConstant` to add a constant to a module and sometimes the name is all lowercase. It throws an exception in that case, but it appears that ruby 2.5 only throws a warning in that case instead of an error.
<rdubya[m]>
I get: `NameError: bad constant name qux` in JRuby and `warning: rb_define_const: invalid name `qux' for constant` with mri
<rdubya[m]>
* I get: `NameError: bad constant name qux` in JRuby and `warning: rb_define_const: invalid name 'qux' for constant` with mri
<enebo[m]>
rdubya: so does it work in MRI for sure?
<enebo[m]>
rdubya: Regardless it is a bug on our side
<rdubya[m]>
the library i am working on passes all the tests in mri and won't even start because of this issue
<rdubya[m]>
i'm working around it right now by skipping defining anything that is invalid
<enebo[m]>
but you can const_get :qux?
<rdubya[m]>
hmm didn't try that
<enebo[m]>
defineConstant is define_constant too I assume
<rdubya[m]>
no i'm calling it directly in java
<rdubya[m]>
trying to get jruby support for protobuffers
<enebo[m]>
lol...ok well I am seeing a problem with this description
<rdubya[m]>
so its been fun converting the c code to java lol
<enebo[m]>
so you are using ruby c api and java api then and not doing this from Ruby?
<rdubya[m]>
most of the current gem is c native
<rdubya[m]>
so i'm building the java counterpart
<enebo[m]>
rb_define_const is what you are calling on MRI though
<rdubya[m]>
yeah that's what they call
<rdubya[m]>
it's kind of funny because they check for it and throw a warning and then ruby throws basically the same warning
<enebo[m]>
ok so this is a level of compat we normally do not have to worry about but I suppose in this case we should just see if there is a method which will allow it to work with only a warning
<enebo[m]>
ok we need to know a) is this a Ruby incompat and b) is this something we do not provide a proper analog for in our APIs
<enebo[m]>
I could see both but largely because most people do not try and make consts with a lower case letter
<rdubya[m]>
so then i get: ``` protobuf/conformance/google/protobuf/test_messages_proto3_pb.rb:203: warning: Enum value 'qux' does not start with an uppercase letter as is required for Ruby constants.
<rdubya[m]>
protobuf/conformance/google/protobuf/test_messages_proto3_pb.rb:203: warning: rb_define_const: invalid name `qux' for constant
<rdubya[m]>
* so then i get: ``` protobuf/conformance/google/protobuf/test_messages_proto3_pb.rb:203: warning: Enum value 'qux' does not start with an uppercase letter as is required for Ruby constants.
<rdubya[m]>
protobuf/conformance/google/protobuf/test_messages_proto3_pb.rb:203: warning: rb_define_const: invalid name `qux' for constant ```
<rdubya[m]>
ugg that didn't format well lol
<enebo[m]>
so you get warning spam but it probably did it anyways (in C)
<enebo[m]>
In Ruby I think this is not a problem for us so a) above is ok I am sure
<enebo[m]>
rdubya: just try setConstant(name, value)
<enebo[m]>
It may not give you a warning but defineConstant is used by "things" and I am not sure we want to change the behavior
<enebo[m]>
If you ask me their behavior seems very questionable. If you cannot set a constant in Ruby but it is allowed with warnings in C you have to think there is an inconsistency
<rdubya[m]>
yeah lol
ruurd has joined #jruby
<enebo[m]>
but this also makes me wonder if protobuf library itself has a bug
<enebo[m]>
or perhaps it is just a requirement to work that the C code happens to allow lower cased constants
<rdubya[m]>
yeah, not sure on that one, i've been learning all about protobuffers over the past couple of weeks trying to figure out what they are actually doing lol
<rdubya[m]>
amazingly, i got almost all the tests to pass without modification to the tests themselves, just had a couple odd things
<enebo[m]>
we have some interest in using protobufs for reading pre-lexed source or persisted IR to avoid allocating but it requires lots of changes because it realyl wants stuff to be laid out similarly
<rdubya[m]>
but there also isn't 100% test coverage because there are some methods defined in the c code that I don't have on the java side and the tests are still passing
<enebo[m]>
(but that is all just from Java itself)
<rdubya[m]>
lol it appears that even if it creates it, you can't get it
<enebo[m]>
yeah from Ruby I don't think you can so their tests are also broken
<enebo[m]>
I was half wondering if they also retrieved via C api and it just happened to work both ways
<rdubya[m]>
i think these are convenience things for the ruby side, so I'm guessing they don't actually verify anywhere that its available
<enebo[m]>
So two bugs maybe 1) MRI should not just warn in C api [there could very well be reasons why they allow it though] 2) the protobuf test itself is broken if there is no way to read the lc const
<rdubya[m]>
i'm just going to skip creating it if it isn't valid
<enebo[m]>
rdubya: question: Should they just fail there?
<enebo[m]>
I mean what is the test actually doing
<rdubya[m]>
they aren't testing this piece specifically, i think its difficult to say that it should hard fail since somebody may be defining these for a different language where the case doesn't matter
<rdubya[m]>
in most cases these are accessed using symbols
<rdubya[m]>
or the numeric value they represent
<enebo[m]>
rdubya: ah. I guess so? Feels strange to me but that is a possible reason to ignore
<enebo[m]>
in the old XML days schematron ended up being popular with some because it merely identified constraints which must be true. Other data which was not subject to any rules was fine. Compare that to DTDs where it is a whole view of what it is parsing.
<rdubya[m]>
interesting
<enebo[m]>
It maybe is like that
<rdubya[m]>
do you know offhand how to throw a warning?
<rdubya[m]>
i can dig through the code if not
<enebo[m]>
rdubya: I can understand wanting to be fully compatible but do you think there is value? Or does the test try and observe the warning?
<rdubya[m]>
I just figured I'd throw a warning so that if somebody is using a definition that they don't control, they'll have some idea of why they can't access it
<enebo[m]>
sure that makes sense
<rdubya[m]>
and thanks for the code sample, I meant to ask, is there javadocs anywhere for the jruby source?
<enebo[m]>
we do not seem to have a proper enum for this but this enum has not aged well for us
<enebo[m]>
well we ship javadocs when we publish our artifacts
<enebo[m]>
but a better question might be how useful is our javadocs :)
<rdubya[m]>
lol
<enebo[m]>
we should be much better about our comments in this regards and some sections of code are much better than others so i am not saying there is not value in looking
<rdubya[m]>
for me its mostly about knowing what methods are publicly available without having to scroll through all the code, so even just a list of methods would be helpful
<enebo[m]>
ah yeah well there are required by sonatype to push so we should have them in the artifacts themselves
<enebo[m]>
I tend to just list members in intellij for a list but then I also tend to know the codebase so I have an inkling that something exists already
nirvdrum has joined #jruby
zacts has quit [Quit: leaving]
zacts has joined #jruby
zacts has quit [Quit: leaving]
subbu is now known as subbu|lunch
zacts has joined #jruby
nirvdrum has quit [Ping timeout: 265 seconds]
<zacts>
can I develop android apps with jruby?
<headius[m]>
rdubya: I suspect this is an attempt to use the constant table to hold a value but wanting it to not be visible to normal Ruby code
<headius[m]>
this is the new jruby-base artifact with jruby-core continuing to be the published shaded jar
<headius[m]>
it is almost green except for the jar size checks, which I'm looking into
<enebo[m]>
yeah I was already ok with this but was just waiting until it was green
<headius[m]>
ok
<enebo[m]>
or at least we had discussed the shade vs no and naming part of it
<headius[m]>
we need to land it sooner than later so I'll do that today
<enebo[m]>
ok
zacts has quit [Ping timeout: 246 seconds]
zacts has joined #jruby
<headius[m]>
enebo: so I figured out the problem and we may have had some confusion around what's actually shaded in jruby-core
<headius[m]>
it appears that jruby-core only shades ASM and two other libraries that depend on it (jitescript and jnr-ffi) but I may have mislead Kristian to shade everything
<headius[m]>
see latest comment there
<rdubya[m]>
headius: cool,thanks for the heads up
<headius[m]>
I am making the fix but I wanted to mention this, since jruby-core will *not* be "base + all dependencies" since it wasn't before
<headius[m]>
base will be bare, core will be base + shaded ASM (hidden), jitescript, and jnr-ffi, complete will be core + remaining dependencies and stdlib
<headius[m]>
I had gotten the idea somewhere that core was shading everything
<enebo[m]>
hmm I guess I did not realize only asm was shaded either
<headius[m]>
I think because when we build core it shades everything for lib/jruby.jar
<headius[m]>
but the actual dist build does not
<enebo[m]>
I do recall one of the jars would not work shaded as it put a Class.forName with the type in it somewhere
<headius[m]>
in any case I want to make sure we are in agreement that core should shade no more than it did before
<enebo[m]>
but I only remember this because you are telling me now :)
<headius[m]>
even though that doesn't mesh with what we originally planned for base/core
<enebo[m]>
no I mean we want the same to be the same but the new to fit into modular world
<enebo[m]>
Some day I dream we will no long have joda too :P
<headius[m]>
yeah it really ends up that jruby-core shades just slightly too much because it has to rewrite jnr-ffi's uses of ASM
<headius[m]>
so then it has to pull in jnr-ffi and that's where the original issue came from
<headius[m]>
it relocates ASM and jitescript packages but not jnr-ffi, because it doesn't pull in the other jnr libs
<headius[m]>
core is a weird beast and I think maybe we should consider deprecating it
<headius[m]>
it doesn't shade everything it needs, but it shades enough to lead to conflicts in jnr-ffi
<enebo[m]>
In a Java 15+ world we need to be well-behaved so I think that deprecation will happen regardless of how we feel about jruby-core
<headius[m]>
true
<headius[m]>
base will be the important artifact going forward
zacts has quit [Quit: leaving]
<enebo[m]>
It does end up meaning things like windows installer could be more complcated perhaps...so perhaps if base works in older Javas we can move to it earlier
zacts has joined #jruby
<enebo[m]>
lol "\xg1" boom bad escape 'g' and it points at it but "\x1g" is no probs as \x1 is valid and g is just another char after it
<headius[m]>
same in MRI?
<enebo[m]>
that is Ruby behavior I am complaining about
<headius[m]>
oh I see
<headius[m]>
it wants hex
<enebo[m]>
we will error or work just like MRI in this case
<enebo[m]>
but our caret points a beginnign of string and not at the 'g'
<headius[m]>
so basically it only requires one hex char after \x
<headius[m]>
but at least one
<enebo[m]>
So I am fixing that but remarking at how sloppy allowed hex input looks weird here
<enebo[m]>
and the only possible invalid hex warning can only happen at first char after the 'x'
<headius[m]>
the power of Ruby
<headius[m]>
I pushed updates for base PR, hopefully it doesn't cause something else to break
<headius[m]>
enebo: do you know who is using this "glimmer" SWT wrapper? they release on a surprisingly regular basis
<enebo[m]>
I do not but I know the name so I feel like I did know it at some point
<enebo[m]>
did redcar also use it?
<headius[m]>
last I looked Redcar just had its own SWT wrapper, but that was a long time ago
<enebo[m]>
maybe pragtob? with the processing stuff?