00:07
elia has quit [Quit: Computer has gone to sleep.]
00:18
pawnbox has joined #jruby
00:23
pawnbox has quit [Ping timeout: 255 seconds]
00:49
pawnbox has joined #jruby
00:53
pawnbox has quit [Ping timeout: 276 seconds]
00:56
shellac has quit [Quit: Computer has gone to sleep.]
01:48
pawnbox has joined #jruby
01:49
n00bdev has joined #jruby
01:52
pawnbox has quit [Ping timeout: 246 seconds]
01:58
camlow325 has quit []
02:02
yfeldblum has quit [Remote host closed the connection]
02:05
n00bdev has quit []
02:18
pawnbox has joined #jruby
02:23
pawnbox has quit [Ping timeout: 246 seconds]
02:39
bb010g has joined #jruby
02:48
pawnbox has joined #jruby
02:52
pawnbox has quit [Ping timeout: 255 seconds]
03:03
yfeldblum has joined #jruby
03:10
yfeldblum has quit [Ping timeout: 250 seconds]
03:18
pawnbox has joined #jruby
03:23
pawnbox has quit [Ping timeout: 265 seconds]
03:26
nirvdrum has joined #jruby
03:47
tomjoro has quit [Remote host closed the connection]
03:59
n00bdev has joined #jruby
04:06
yfeldblum has joined #jruby
04:10
nirvdrum has quit [Ping timeout: 276 seconds]
04:11
yfeldblum has quit [Ping timeout: 260 seconds]
04:18
pawnbox has joined #jruby
04:22
pawnbox has quit [Ping timeout: 240 seconds]
04:38
mkristian_ has joined #jruby
04:42
mkristian__ has quit [Ping timeout: 260 seconds]
04:48
tomjoro has joined #jruby
04:52
tomjoro has quit [Ping timeout: 264 seconds]
04:56
yfeldblum has joined #jruby
05:02
mkristian_ has quit [Read error: Connection reset by peer]
05:02
pawnbox has joined #jruby
05:02
mkristian has joined #jruby
05:06
pawnbox_ has joined #jruby
05:10
pawnbox has quit [Ping timeout: 245 seconds]
05:17
pawnbox_ has quit [Remote host closed the connection]
05:20
pawnbox has joined #jruby
05:30
yfeldblum has quit [Remote host closed the connection]
05:30
kares has joined #jruby
05:43
kares has quit [Quit: hali-hoo!]
05:43
kares has joined #jruby
05:48
tomjoro has joined #jruby
05:52
lopex has quit [Quit: Connection closed for inactivity]
05:52
tomjoro has quit [Ping timeout: 240 seconds]
05:55
n00bdev has quit []
06:03
pawnbox has quit [Remote host closed the connection]
06:15
donV has quit [Quit: donV]
06:17
yfeldblum has joined #jruby
06:19
pawnbox has joined #jruby
06:22
yfeldblum has quit [Ping timeout: 265 seconds]
06:37
yfeldblum has joined #jruby
06:42
yfeldblum has quit [Remote host closed the connection]
06:44
tjohnson has quit [Quit: Connection closed for inactivity]
06:49
tomjoro has joined #jruby
06:50
thedarkone2 has quit [Quit: thedarkone2]
06:53
tomjoro has quit [Ping timeout: 245 seconds]
06:59
donV has joined #jruby
07:17
donV has quit [Quit: donV]
07:20
pawnbox has quit [Remote host closed the connection]
07:47
pawnbox has joined #jruby
08:07
skade has joined #jruby
08:09
tomjoro has joined #jruby
08:13
yfeldblum has joined #jruby
08:16
<
GitHub129 >
jruby/ruby-2.3 e68337c kares: Merge branch 'master' into ruby-2.3...
08:20
pawnbox has quit [Remote host closed the connection]
08:20
pawnbox has joined #jruby
08:24
pawnbox has quit [Read error: Connection reset by peer]
08:25
pawnbox has joined #jruby
08:25
shellac has joined #jruby
08:55
shellac has quit [Quit: Computer has gone to sleep.]
09:02
vtunka has joined #jruby
09:02
mgk has joined #jruby
09:03
<
mgk >
The mssql adapter of AR-JDBC currently prints the following to stderr: "NOTE: ActiveRecord 4.2 with adapter: mssql is not (yet) fully supported by AR-JDBC, please consider helping us out."
09:05
<
mgk >
I've looked at the Github issues but I haven't seen any major bugs that would warrant such a warning. Is this still in there because no one took it out and its basically obsolete?
09:05
<
mgk >
or are there any issues not documented in GitHub. If so, I might be able to help out.
09:06
<
mgk >
(I haven't really discovered any issues in my app, yet)
09:08
elia has joined #jruby
09:14
skade has quit [Quit: Computer has gone to sleep.]
09:26
<
GitHub58 >
jruby/master a5402c7 Benoit Daloze: [Truffle] Hanlde -J-G options in the Eclipse launcher.
09:30
yfeldblum has quit [Ping timeout: 240 seconds]
09:48
skade has joined #jruby
09:53
<
kares >
mgk: than you're good - 4.2 support is fairly recent and only limited testing went in for proprietary adapters
09:53
<
kares >
there are several issues open for mssql if you want to help out
09:55
drbobbeaty has joined #jruby
10:04
yfeldblum has joined #jruby
10:20
<
GitHub164 >
jruby/master 8b9814f kares: [find-bugs] concatenating strings + unnecessary string-buffer use
10:20
<
GitHub164 >
jruby/master 0145e53 kares: [ji] missing hashCode to go with equals in JavaArray proxy
10:20
<
GitHub164 >
jruby/master 4530ba0 kares: re-use empty String array in RubyDir + avoid down-casting array local var
10:22
vtunka has quit [Quit: Leaving]
10:28
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
10:28
bb010g has quit [Quit: Connection closed for inactivity]
10:38
shellac has joined #jruby
11:08
pawnbox has quit [Remote host closed the connection]
11:15
skade has quit [Quit: Computer has gone to sleep.]
11:16
pawnbox has joined #jruby
11:20
pawnbox has quit [Ping timeout: 260 seconds]
11:59
pawnbox has joined #jruby
12:03
djellemah_ has joined #jruby
12:04
lopex has joined #jruby
12:05
skade has joined #jruby
12:05
yfeldblum has quit [Ping timeout: 250 seconds]
12:06
pawnbox has quit [Remote host closed the connection]
12:06
pawnbox has joined #jruby
12:07
djellemah_ has quit [Client Quit]
12:16
rsim1 has joined #jruby
12:20
rsim has quit [Ping timeout: 240 seconds]
12:25
rsim has joined #jruby
12:27
yfeldblum has joined #jruby
12:29
rsim1 has quit [Ping timeout: 240 seconds]
12:51
skade has quit [Quit: Computer has gone to sleep.]
12:57
drbobbeaty has joined #jruby
13:00
drbobbeaty has quit [Client Quit]
13:07
vtunka has joined #jruby
13:09
tcrawley-away is now known as tcrawley
13:12
mgk has quit [Ping timeout: 252 seconds]
13:12
<
GitHub100 >
jruby/master 502a4a8 Benoit Daloze: [Truffle] Only put what is necessary behind @TruffleBoundary in SizedQueueNodes.
13:13
drbobbeaty has joined #jruby
13:13
<
GitHub49 >
jruby/truffle-head ba7bac1 Benoit Daloze: Merge remote-tracking branch 'origin/master' into truffle-head
13:16
drbobbeaty has quit [Client Quit]
13:23
bbrowning_away is now known as bbrowning
13:24
<
GitHub194 >
jruby/master f4259c3 Benoit Daloze: [Truffle] Only put what is necessary behind @TruffleBoundary in QueueNodes.
13:24
<
GitHub79 >
jruby/truffle-head edc01e6 Benoit Daloze: Merge remote-tracking branch 'origin/master' into truffle-head
13:27
Madmanden has joined #jruby
13:38
yfeldblum has quit [Ping timeout: 260 seconds]
13:47
<
GitHub123 >
jruby/master 8ebd8f4 Benoit Daloze: Merge remote-tracking branch 'origin/truffle-head'
13:49
drbobbeaty has joined #jruby
13:50
lance|afk is now known as lanceball
13:51
drbobbeaty has quit [Client Quit]
13:52
nirvdrum has joined #jruby
13:53
drbobbeaty has joined #jruby
13:55
drbobbeaty has quit [Client Quit]
13:55
drbobbeaty has joined #jruby
13:56
tomjoro has quit [Remote host closed the connection]
13:57
skade has joined #jruby
13:57
drbobbeaty has quit [Client Quit]
13:57
nirvdrum has quit [Remote host closed the connection]
13:59
skade has quit [Read error: Connection reset by peer]
13:59
nirvdrum has joined #jruby
14:32
<
GitHub53 >
jruby/master 6fe20cc Benoit Daloze: [Truffle] Add a few missing boundaries in MutexNodes.
14:34
drbobbeaty has joined #jruby
14:34
<
GitHub10 >
jruby/master 76fd1b7 Chris Seaton: [Truffle] Handle nil in SplatCastNode.
14:34
<
GitHub10 >
jruby/master ca3e90d Chris Seaton: [Truffle] Restructure uses a splat rather than an array cast.
14:34
<
GitHub10 >
jruby/master ac50306 Chris Seaton: [Truffle] More lambda specs passing.
14:35
<
GitHub86 >
jruby/truffle-head 7046852 Benoit Daloze: Merge remote-tracking branch 'origin/master' into truffle-head
14:35
drbobbeaty has quit [Client Quit]
14:42
enebo has joined #jruby
14:55
drbobbeaty has joined #jruby
14:57
drbobbeaty has quit [Client Quit]
15:10
<
eregon >
Could somebody re-upload the jcodings snapshot? seems it went away :/
15:11
<
eregon >
oh, it seems I'm looking at stale stuff, we are on a release now :)
15:15
nirvdrum has quit [Remote host closed the connection]
15:16
pawnbox has quit [Remote host closed the connection]
15:18
pawnbox has joined #jruby
15:18
xardion has joined #jruby
15:20
xardion_ has quit [Ping timeout: 276 seconds]
15:22
skade has joined #jruby
15:24
pawnbox_ has joined #jruby
15:24
pawnbox has quit [Ping timeout: 240 seconds]
15:26
pawnbox_ has quit [Remote host closed the connection]
15:26
pawnbox has joined #jruby
15:29
skade has quit [Quit: Computer has gone to sleep.]
15:33
nirvdrum has joined #jruby
15:34
pawnbox has quit [Remote host closed the connection]
15:34
qmx has quit [Ping timeout: 240 seconds]
15:36
Scient has quit [Ping timeout: 250 seconds]
15:37
Scient has joined #jruby
15:38
<
chrisseaton >
is headius or enebo around?
15:39
qmx has joined #jruby
15:39
qmx has quit [Changing host]
15:39
qmx has joined #jruby
15:39
<
chrisseaton >
we use FindBugs on Travis, and download the FindBugs JAR from SourceForge - eregon noticed it looks like we can't do that anymore as it 503's
15:39
<
chrisseaton >
I was thinking maybe have a jruby/travis-files repo on GH and serve from there?
15:40
drbobbeaty has joined #jruby
15:40
drbobbeaty has quit [Client Quit]
15:41
drbobbeaty has joined #jruby
15:41
Madmanden has quit []
15:42
<
headius >
chrisseaton: why don't we pull it from maven central?
15:42
<
headius >
is it not there?
15:43
drbobbeaty has quit [Client Quit]
15:43
<
chrisseaton >
I don't think so - there's a Google fork of it, maybe we can use that
15:43
<
headius >
jars not released to maven don't exist in my worldview
15:44
<
chrisseaton >
well they're on SourceForge so that should tell you all you need to know
15:44
<
chrisseaton >
I'll experiment with the Google fork and ask you again if that's not an option
15:44
<
headius >
if necessary we could throw it on JRuby S3 but I'd rather source something canonical
15:45
<
enebo >
who makes Java jars and do not push them to Maven
15:45
<
enebo >
They sound like they dislike maven more than I do?!?!?
15:45
<
chrisseaton >
Maven Central isn't exactly easy to push to though
15:45
<
chrisseaton >
A lot of bureaucracy around it
15:48
<
chrisseaton >
I think there's been some kind of unofficial fork in this project... nothing is clear
15:49
<
enebo >
chrisseaton: findbugs has existed for like a decade…if they are still not pushing to maven it is a concerted effort to not put something there
15:49
<
enebo >
chrisseaton: although I agree nothing is easy with Maven :)
15:50
<
headius >
maven central is pretty easy to push to via sonatype oss
15:50
<
headius >
you ask for an account, they give it to you, you push
15:50
<
enebo >
private key and the surrounding artifact expectations too
15:50
<
enebo >
and proper signature generation
15:50
<
chrisseaton >
headius: don't you have to fill in a form and wait for a response from Sonatype etc? It's not exactly RubyGems
15:50
<
headius >
sure, but they have step-by-step walkthroughs for that too
15:50
<
enebo >
but it can easily be copied by looking at a similar project
15:51
<
headius >
chrisseaton: yes, but it has never taken more than a day for me
15:51
<
enebo >
but it is only a one time thing and it is generally <24 hours
15:51
pawnbox has joined #jruby
15:52
<
headius >
rubygems and sf.net and other "anyone can throw a binary up" also raise plenty of trust concerns
15:53
<
chrisseaton >
argh so I can get the actual jar for FindBugs from a fork on central, but it doesn't include their launcher, and they have separate main classes for each functionality - e.g. edu.umd.cs.findbugs.ShowHelp
15:53
pawnbox has quit [Remote host closed the connection]
15:53
<
enebo >
anyways I agree there are hoops to jump through and some non-obvious stuff like, what is sonatype (for a new user) but if you want wide deployment in Java world maven repo is it
15:53
pawnbox has joined #jruby
15:54
<
enebo >
chrisseaton: ouch
15:54
<
headius >
chrisseaton: who's running that project anyway? Sounds like a mess
15:54
<
enebo >
chrisseaton: time to fork!
15:54
tjohnson has joined #jruby
15:54
<
chrisseaton >
University of Maryland
15:54
<
headius >
somehow that doesn't surprise me
15:55
<
headius >
org.jruby.findbugs :-D
15:55
<
enebo >
chrisseaton: 12 years of archives on the project…someone has probably asked about maven on it
15:55
pawnbox has quit [Remote host closed the connection]
15:55
<
enebo >
grocery shopping bbiab
15:56
<
chrisseaton >
looks like the reason it's complicated as the core functionality, command line tool and two GUIs are all rolled into one
15:56
<
chrisseaton >
the manual talks about setting the visual style and things like that
15:56
<
headius >
I'm always amazed when there's a widely-used Java project that isn't in central
15:57
<
headius >
releases as recent as 3.0.5
15:57
<
headius >
er I mean Nov 2015
15:57
<
headius >
looks like it uses the google version
15:58
<
headius >
chrisseaton: if we can figure this out it would be nice to start running reports on jruby proper too
15:58
<
headius >
we used to do it periodically but have not in quite a while
15:59
<
chrisseaton >
it's a bit of a pain TBH - almost always false negatives, takes ages so you can't run locally before push and it just embarasses you with a broken build
15:59
<
chrisseaton >
i think you'd also get 10,000 warnings immediately and would have to either fix or ignore them before you could use it on Travis
16:00
<
chrisseaton >
in fact I'm going to remove it from Truffle for now anyway until I get some more time to understand FindBugs
16:00
<
headius >
I remember all the false positives
16:00
<
headius >
we just hande-audited the report periodically
16:01
<
headius >
rather than letting it look like a build error
16:01
<
nirvdrum >
While not automated, IntelliJ's code inspections are very good and do much of the same thing.
16:02
<
GitHub165 >
jruby/truffle-head 5d61a09 Chris Seaton: Merge branch 'master' into truffle-head
16:04
<
headius >
enebo: I think I have load wrapping working
16:05
<
headius >
we weren't using the anonymous module as pushRubyClass...always using Object for it
16:05
<
headius >
we only set the module into the scope, which isn't enough for defs in 1.7
16:06
vtunka has quit [Quit: Leaving]
16:06
pawnbox has joined #jruby
16:07
camlow325 has joined #jruby
16:15
drbobbeaty has joined #jruby
16:16
drbobbeaty has quit [Client Quit]
16:21
bb010g has joined #jruby
16:53
<
GitHub71 >
jruby/jruby-1_7 73daf0a Charles Oliver Nutter: Also use the anonymous wrap class for pushRubyClass, for defs....
17:01
<
GitHub148 >
jruby/jruby-1_7 2e2647e Charles Oliver Nutter: Same fix for AOT as for interp for #3180.
17:08
e_dub has quit [Ping timeout: 250 seconds]
17:10
shellac has quit [Quit: Ex-Chat]
17:12
elia has quit [Quit: Computer has gone to sleep.]
17:13
elia has joined #jruby
17:13
tomjoro has joined #jruby
17:15
elia has quit [Client Quit]
17:21
<
headius >
fixity fixity fixity
17:33
pitr-ch has joined #jruby
17:35
<
eregon >
findbugs magically became available again
17:38
<
headius >
of course it did
18:02
lopex has quit [Quit: Connection closed for inactivity]
18:03
elia has joined #jruby
18:03
thedarkone2 has joined #jruby
18:05
<
bascule >
_____ ____ ___ ____ _ __ ___ _ _
18:05
<
bascule >
| ___| _ \|_ _| _ \ / \\ \ / / | | |
18:05
e_dub has joined #jruby
18:05
<
bascule >
| |_ | |_) || || | | |/ _ \\ V /| | | |
18:05
<
bascule >
| _| | _ < | || |_| / ___ \| | |_|_|_|
18:05
<
bascule >
|_| |_| \_\___|____/_/ \_\_| (_|_|_)
18:05
<
headius >
bascule: yay
18:07
<
enebo >
headius: so how risky is anon wrapping module with require
18:09
<
headius >
enebo: risky as in 1.7.24, eh?
18:10
<
headius >
I'd say it's very low risk because practically nobody ever does load(..., true)
18:10
<
headius >
and if they did, it was broken
18:10
<
headius >
I am going to confirm this is still how MRI does it, but for load without wrap this shouldn't change anything
18:10
<
enebo >
headius: well it was reported by someone who noticed it was not working
18:10
<
headius >
the fix for 9k is also a one-liner
18:10
<
headius >
right...one of those outliers
18:11
<
headius >
so I think it's a good thing to fix
18:11
<
enebo >
headius: but I guess the risk would be some project using it differently on jruby with some jruby-specific fixes and it suddenly breaking because they assumed shared scope
18:11
<
headius >
that is the risk, I agree
18:11
<
enebo >
headius: with that said, they would be depending on wrong behavior
18:11
<
enebo >
headius: so I only bring this up as an issue of timing
18:12
<
enebo >
headius: doing it 4 weeks before release allows us to say they had time to notice
18:12
<
headius >
well it's up to you...I can move those fixes to 1.7.25 if you like
18:12
<
enebo >
headius: one day before?>
18:12
<
enebo >
headius: yeah I don’t know. I am just bringing it up for conversation
18:12
<
enebo >
headius: I like to have these sorts of conversations on ones which make my nose tingle
18:12
<
headius >
I feel pretty safe about it myself, since it's a feature of load most people don't even know about
18:13
<
headius >
and those that do would want it to do the right things
18:13
<
enebo >
headius: I guess it is so unlikely to be used at all
18:13
elia has quit [Quit: Computer has gone to sleep.]
18:13
<
enebo >
headius: some framework which depends on this no doubt worked around this by module_eval’ing the load
18:13
<
enebo >
headius: or something to try and make it happen in a different namespace
18:13
<
enebo >
headius: in which case fixing it would not brea them
18:14
<
enebo >
headius: but load is meant mostly for reloading the same thing
18:14
<
enebo >
hmm yeah this is probably worth going for it
18:14
<
headius >
I think it is...I'll do more verification of it as well
18:15
<
headius >
fixing it on master untags a handful of specs too
18:19
<
headius >
we haven't done this right for years
18:19
<
GitHub89 >
jruby/master 940c5aa Charles Oliver Nutter: Remove this hack in prep for investigating #3180.
18:19
<
GitHub89 >
jruby/master eb69173 Charles Oliver Nutter: Also get self's class for method defs in script body....
18:19
<
GitHub89 >
jruby/master 358a4af Charles Oliver Nutter: Untag passing Kernel#load specs.
18:22
elia has joined #jruby
18:23
nirvdrum has quit [Ping timeout: 246 seconds]
18:24
nirvdrum has joined #jruby
18:42
nirvdrum has quit [Read error: No route to host]
18:45
nirvdrum has joined #jruby
18:46
<
headius >
seems like my previous fix might have caused some trouble, not the most recent one
18:51
kith has joined #jruby
18:54
<
headius >
hmmm, I'm not getting those failures locally
18:55
<
GitHub174 >
jruby/master 6d171ab Chris Seaton: [Truffle] More lambda specs passing.
18:57
pietr0 has joined #jruby
18:58
bb010g has quit [Quit: Connection closed for inactivity]
18:59
<
headius >
I see a bug
18:59
<
chrisseaton >
headius: CompiledIRMethod doesn't mean jitted does it?
18:59
<
GitHub6 >
jruby/jruby-1_7 b93fbb6 Charles Oliver Nutter: Check for empty identifiers and treat them as false.
19:00
<
headius >
chrisseaton: it does
19:00
<
headius >
it is used when the body that defined a method was already compiled to bytecode
19:00
<
headius >
for the lazy jit it would be MixedModeIRMethod
19:01
<
chrisseaton >
Are native (Java defined in RubyKernel etc) CompiledIRMethods?
19:01
<
headius >
no, those are generated descendants of JavaMethod
19:02
<
headius >
I've wanted to unify all these paths but it would require using indy or a lot more code generation to adapt the different argument layouts
19:02
<
projectodd-ci >
Yippee, build fixed!
19:02
<
headius >
if you run the script directly it attemps to compile the whole thing right away
19:03
<
headius >
only for the target script
19:03
<
headius >
in which case it would be using CompiledIRMethod for any defs
19:03
<
chrisseaton >
oh right yeah the top level is compiled
19:13
elia has quit [Quit: Computer has gone to sleep.]
19:17
<
GitHub37 >
jruby/jruby-1_7 2398cec Charles Oliver Nutter: Add case for breakage fixed in jruby/jruby@b93fbb6e431.
19:19
<
GitHub43 >
jruby/master c3e0baf Charles Oliver Nutter: More robust, less breaky fix to omit bad class/package elements....
19:19
<
GitHub43 >
jruby/master eaffabf Charles Oliver Nutter: Check for empty identifiers and treat them as false.
19:19
<
GitHub43 >
jruby/master fba6319 Charles Oliver Nutter: Add case for breakage fixed in jruby/jruby@b93fbb6e431.
19:21
bb010g has joined #jruby
19:25
elia has joined #jruby
19:25
<
GitHub189 >
jruby/master 3cc7262 Chris Seaton: [Truffle] check respond_to? and call to_hash when getting keyword arguments.
19:25
<
GitHub189 >
jruby/master 7b070cd Chris Seaton: [Truffle] Lambda specs passing.
19:25
<
GitHub189 >
jruby/master 367b9ba Chris Seaton: [Truffle] Got a bunch of method specs passing for free.
19:34
<
headius >
enebo: that one seems to have been fixed between 1.7.21 and now
19:34
<
headius >
I know kares and mkristian have fiddled around with load service during that time
19:36
<
headius >
I find the MRI behavior surprising, tbh
19:37
<
headius >
oh wait a sec
19:37
<
headius >
oh this might be easy
19:37
<
chrisseaton >
I have parens in arguments lists... I've been working for like a week on those in Truffle
19:38
<
chrisseaton >
I hate I mean, not I have
19:38
<
headius >
yeah they're kinda crazy
19:38
<
headius >
I think this problem is simple though...we're just not locally-scoping arguments if they're in params
19:38
<
chrisseaton >
combined with kwargs it's mind bending
19:38
<
headius >
only if they're directly in the ||
19:38
<
headius >
so there's just a check missing somewhere
19:38
<
headius >
params=parens
19:38
<
chrisseaton >
you're probably re-using the multiple assignment parser rules
19:38
<
headius >
yeah perhaps
19:39
<
chrisseaton >
which don't have actions to set in the current scpe
19:39
<
headius >
I don't know where the code is that says "force these to be local to the block" but it's not running for nested vars
19:47
<
headius >
jesus, the Jay source is really old C
19:48
<
headius >
enebo: how do you even build this?
19:48
<
headius >
chrisseaton: you got this to build, right?
19:48
<
enebo >
./bin/generate_parser
19:49
<
chrisseaton >
it's really badly bitrotted! i have a PR open with some suggestions
19:49
<
chrisseaton >
if you're on a mac I can just send you a binary
19:49
<
chrisseaton >
and things like the name of the parent directory the jay repo are in matter!
19:50
<
headius >
enebo: I have to build Jay first
19:50
<
headius >
and it's like pre-C89 code that clang refuses to accept
19:50
<
headius >
I didn't even know this was ever valid C
19:51
<
chrisseaton >
it's K&R isn't it
19:51
<
headius >
I think K&R at least had void
19:51
<
enebo >
you know this is basically original yacc code I think
19:51
<
headius >
this doesn't even have void
19:51
<
enebo >
it has PDP-11 comments in it
19:51
<
headius >
it is K&R var decl style though
19:51
<
enebo >
I could just commit my binary too :)
19:51
<
enebo >
K&R had void
19:51
<
headius >
chrisseaton: unknown repository
19:51
<
headius >
can you make that public maybe?
19:52
<
headius >
it would be easier for me to just pull your fork
19:52
<
headius >
I've never seen that before
19:52
<
enebo >
HAHAHAHA chrisseaton I would have merged this long ago had I gotten notified by github
19:53
<
enebo >
some of this looks like it should be void and not int
19:53
<
chrisseaton >
I figured int was implicit when no type was specified in the era of this C
19:53
<
enebo >
err all of it perhaps
19:53
<
chrisseaton >
I think I deleted the repo this PR came from, but if you merged it you could use it
19:54
<
enebo >
Give me a minute and I can probably fix this for clang quickly
19:54
<
headius >
I think it's probably all supposed to be void since non-void return type was still required
19:54
<
headius >
at least I believe so...this predates my learning C
19:54
<
enebo >
I think mostly we just need more explicit signatures
19:54
<
enebo >
older gcc must ssume void
19:55
<
enebo >
clang is probably requiring ansi
19:55
<
headius >
clang is locked to C99+ I believe
19:55
<
headius >
which requires return type
19:55
<
enebo >
although perhaps there is a k&r flag but we can easily just fix it
19:55
<
enebo >
I will do it and we will see if I still “got it"
19:56
<
headius >
show us your stuff
19:56
<
headius >
or just fix that parser bug for me
19:56
<
enebo >
part of me is not so interested in improvement of a tool which has not changed in 40 years other than Java generation part :)
19:56
<
headius >
I think it's just a matter of forcing all vars in the ArgsNode to be declared as locala
19:56
<
headius >
local to the block
19:56
<
headius >
enebo: we could probably port this to Java
19:56
<
enebo >
headius: well I think it would be nice if people can compile this tool so I don’t have the “quest for fire” binary
19:57
<
enebo >
headius: I have thought about it before
19:57
<
enebo >
headius: not as much jumping like racc
19:57
<
chrisseaton >
I think this was my first PR after starting work on Truffle
19:57
<
headius >
racc took some doing
20:00
<
headius >
now I want to watch Quest for Fire
20:01
<
enebo >
HAHAHA yeah this is super K&R
20:01
<
enebo >
I am amazed this is allowed in clang at all if it is strict C99
20:02
<
headius >
the arg decl definitely is
20:02
<
enebo >
I will just fix the signatures to all be ansi c
20:02
<
headius >
I can't find concrete info on whether return type void is K&R or prior
20:02
<
enebo >
well the lineage of this code is do….old
20:03
<
enebo >
the last csscid is from 1990
20:03
<
enebo >
so this is BSD yacc code
20:03
<
headius >
ok, sounds like K&R did not have a way to indicate no return value
20:03
<
headius >
void didn't come along until C89
20:04
<
headius >
I learned from K&R book but I'm sure it was a post-89 edition
20:04
<
headius >
I probably still have it here somewhere
20:06
<
headius >
sweet, quest for fire is on netflix
20:06
<
enebo >
headius: my first version of that book was an ansii edition too and I think is was around that time frame
20:06
<
headius >
I gues I know what my background noise will be for the rest of the afternoon
20:09
<
headius >
hmm, I forgot this movie is mostly a lot of grunting
20:11
pietr0 has quit [Quit: pietr0]
20:13
<
headius >
enebo: any objection to moving these parser scripts to tool?
20:13
<
headius >
they're not really JRuby bin stuff
20:14
<
enebo >
headius: as long as they still work no
20:14
<
enebo >
tools did not exist when that script was put in there
20:14
<
headius >
yeah I figured
20:15
<
enebo >
we probably have rules to exclude/include possibly
20:15
<
headius >
yeah, we could just drop those if it works fine this way
20:16
<
headius >
let me know when you have jay compiling and I'll make the appropriate changes (and see if I can patch the parser for this issue
20:16
<
enebo >
hehe error.c has been ansified
20:16
<
enebo >
many many functions in that one I guess
20:17
<
enebo >
onintr(signo)
20:17
<
enebo >
someone added void to 1 function in this file at some point
20:18
<
enebo >
unsigned n;
20:18
<
enebo >
seems like something is missing there :)
20:18
<
enebo >
if this fortran? It starts with n…so int? :)
20:19
cremes has quit [Remote host closed the connection]
20:20
<
headius >
yeah must be?
20:21
<
enebo >
heh I doubt they use the I-N rule for variable names pre K&R but it is weird
20:21
<
enebo >
or post K&R
20:22
<
enebo >
so output.c is half ansi half K&R but all voids have no return
20:22
cremes has joined #jruby
20:22
<
enebo >
err no return type
20:22
shellac has joined #jruby
20:23
<
enebo >
and every function has about 15 register variables
20:23
tcrawley is now known as tcrawley-away
20:26
yfeldblum has joined #jruby
20:28
camlow32_ has joined #jruby
20:28
camlow325 has quit [Read error: Connection reset by peer]
20:28
<
enebo >
register int i, j, k, l;
20:28
<
enebo >
register int t;
20:29
<
headius >
those were never guaranteed to go in registers, right?
20:29
<
headius >
just a hint
20:30
<
chrisseaton >
I think they did in early versions
20:30
<
enebo >
headius: back when this hint mattered there were not many registers and once machines got to a point they all started ignoring it
20:30
<
headius >
yeah, but if you ask for more registers than there are registers...
20:31
<
enebo >
headius: so if you name 15 regiser vars but there are only 3 left then you have no idea
20:31
<
enebo >
I was always told to not bother unless that var was insanely important
20:31
<
enebo >
but by the time I learned any lesson it was ignored :)
20:32
<
chrisseaton >
i think they were always in registers when you used them, but may be spilled and reloaded between those points
20:32
shellac has quit [Quit: Computer has gone to sleep.]
20:32
<
enebo >
chrisseaton: yeah but the goal is to make important ones to try and not spill
20:33
<
headius >
yeah I'd think spilling would apply to all vars
20:33
<
enebo >
heh bad typing day
20:33
<
headius >
if they're not in register all the time then it is just a hint
20:33
<
headius >
please prioritize these vars when spilling or not
20:34
<
enebo >
the newer signatures do not use register … in old signatures every single local is a register … and some which maybe got their signature changed to ansi seem to have only register locals
20:34
<
enebo >
I can see multiple coding styles in this code
20:35
<
enebo >
I am guessing BSD -> some other backend generation effort -> added java backend as the three groups
20:36
<
enebo >
I feel somewhat bad my knowledge of C and C++ are slowly disappearing but I sure don’t miss working on a codebase in either language
20:37
<
headius >
C has become read-mostly for me at this point
20:37
kith has quit [Quit: kith]
20:38
<
enebo >
GAH…now that I fixed the signatures I need to add prototype decls
20:40
<
enebo >
HAHAHA…I noticed almost all of those were used in output() method so I moved it to the bottom of the file…FIXED
20:41
kith has joined #jruby
20:42
<
headius >
enebo: nice
20:43
<
headius >
that rule of C still drives me nuts
20:43
<
headius >
you have to read every C file backward unless people declare prototypes
20:44
<
enebo >
ok moved 7 functions around so no more extern signture defs needed
20:47
<
enebo >
char* get_tag(int emptyOk) {
20:47
<
enebo >
I see the java infecting this C
20:47
<
headius >
hahah yeah
20:47
<
enebo >
all the other vars are snake-cased
20:51
<
nirvdrum >
Do we delete SNAPSHOTS that aggressively, or does sonatype?
20:51
<
headius >
they delete when a release is pushed I believe
20:52
<
nirvdrum >
That's . . . something.
20:52
<
headius >
yeah I'm sure there's a reason but it can be a little annoying
20:52
<
nirvdrum >
A local branch I have just stopped working because jcodings was released.
20:52
<
nirvdrum >
But also everything between 9.0.4.0 and 9.0.5.0 can't be bisected.
20:53
<
headius >
huh, I released options and invokebinder but did not see failures on master
20:54
<
nirvdrum >
We use a maven cache in Travis, right?
20:54
<
headius >
maybe they just age out
20:54
<
headius >
we don't, no...there was a bug in it that hasn't been fixed
20:54
<
nirvdrum >
maven doesn't always check for new versions.
20:54
<
headius >
so they should be failing I believe
20:55
<
headius >
yeah it's disabled still
20:55
<
headius >
so I'm surprised
20:55
<
headius >
nirvdrum: what version snapshot of jcodings?
20:56
<
nirvdrum >
1.0.16-SNAPSHOT
20:56
<
nirvdrum >
I just modified the POM locally for now.
20:56
<
nirvdrum >
I don't want to be dealing with a merge or rebase quite yet.
20:56
<
headius >
hmm yep, that's the one I released
20:57
<
nirvdrum >
It was building fine yesterday (and this morning). Maybe they take a day or two to propagate out.
20:58
<
headius >
that's possible
20:58
<
headius >
hmm yep, master builds fine with -U and snapshot versions of options and invokebinder
20:59
<
headius >
those were just released yesterday though I Think
20:59
<
headius >
or wednesday
21:04
<
GitHub70 >
jruby/master a0f1387 Charles Oliver Nutter: Update to release versions of options and invokebinder.
21:13
drbobbeaty has joined #jruby
21:19
<
enebo >
jay: Mach-O 64-bit executable x86_64
21:19
<
enebo >
jay.old: Mach-O executable i386
21:20
<
enebo >
headius: okie dokie
21:20
<
enebo >
headius: looksl ike it generated a binary which generated the same .java output for our parser
21:21
<
enebo >
headius: note these is a mistake in our master grammar atm so you will get one trivial warning
21:21
<
enebo >
headius: it was from last change chrisseaton and I will fix it sooner or later (just need to define that production as having a return type)
21:22
<
headius >
I'll give this patch a shot then
21:22
<
enebo >
I will spend like 10-15 more minutes on jay since it gives zillions of warnings on malloc/alloc etc..
21:22
<
headius >
oh, it needs yydebug checked out too
21:22
<
enebo >
oh wait…I had to re-add that submodule
21:23
<
enebo >
I did not realize anyone had ever changed this repo befor
21:23
<
headius >
where do I get yydebug
21:24
<
enebo >
you did this work
21:24
<
enebo >
it was to get it into maven
21:24
<
headius >
the git submodule
21:24
<
enebo >
it is a submodule
21:24
<
headius >
jay-yydebug ok
21:25
<
headius >
yup got it
21:25
<
headius >
looks good
21:26
yfeldblum has quit [Ping timeout: 240 seconds]
21:39
<
headius >
enebo: PATH=../../jay/src/:$PATH tool/generate_parser Ruby19Parser Ruby19
21:39
<
headius >
but I get error
21:39
<
headius >
../../../../../../../tool/patch_parser.rb:21:in `gets': No such file or directory - Ruby19 (Errno::ENOENT)
21:39
<
enebo >
headius: on 1.7 branch?
21:40
<
headius >
I think it needed full path to jay
21:40
<
headius >
absolute didn't work because it chdirs
21:40
<
enebo >
Generating Parser 'Ruby19Parser' w/ YYTable prefix of 'Ruby19'
21:40
<
enebo >
~/work/jruby-1_7/core/src/main/java/org/jruby/parser ~/work/jruby-1_7
21:40
<
enebo >
~/work/jruby-1_7
21:40
<
headius >
I mean relative didn't work
21:41
<
enebo >
it I think uses pushd
21:41
<
headius >
well, which is the same as cd
21:41
<
enebo >
or is it a ruby script
21:41
<
enebo >
yeah I don’t know…I always have used it the same way
21:41
<
headius >
it does pushd before running the ruby scripts to rewrite it
21:41
<
headius >
and before jay it seems
21:42
<
enebo >
it could be made more robust for this case but I have never seen the issue
21:42
<
headius >
you must use full path to jay
21:42
<
enebo >
:/Users/enebo/Applications/jay/bin:
21:42
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
21:43
<
enebo >
I don’t ever change this
21:44
<
enebo >
but I just have jay in my path like any other tool
21:44
<
headius >
well the patch I thought would help us is only used by truffle
21:44
<
enebo >
which patch?
21:44
<
chrisseaton >
the block local vars one?
21:44
<
chrisseaton >
yeah that's unrealted
21:46
<
headius >
trying to figure out where it goes off into paren-wrapped args land
21:46
<
chrisseaton >
look for uses of constructors of the multasgn nodes?
21:47
<
headius >
enebo: I'm looking at this one...the only problem (I think) is that when you go into nested vars it's no longer forcing them to declare local to the block
21:47
<
headius >
but 9k does it right
21:49
<
headius >
I don't see multi assign referenced from block args
21:49
<
headius >
in the parser
21:49
<
chrisseaton >
so that makes sense - it's reusing the mult asgn rules
21:50
<
chrisseaton >
you could set a breakpoint in the constructor of MultAsgn and look at the stacktrace
21:51
<
headius >
I said I DON'T see it
21:51
<
headius >
I'm working my way through rules though
21:51
<
headius >
ok this might be it though
21:52
<
headius >
it doesn't use the parser rule for masgn but it does construct it
21:52
<
headius >
MultiAsgn19Node
21:53
<
enebo >
hmmm some of the nesting counters I think might still be broken in this parser too
21:53
<
enebo >
like condition and ocmmand stack
21:54
<
enebo >
I got them working on master for some of those no parer functions with blocks on the end bugs but it was not something I could just merge back
21:54
<
enebo >
I am not sure if that is related to this though
21:54
<
headius >
so block args are f_arg, which is a bunch of f_arg_item, which calls into tLPAREN f_marg rparen
21:54
<
enebo >
headius: how does AST look between master and 1.9 in this case
21:55
<
headius >
f_marg just throws those into a MultipleAsgn19Node and does not declare them as new vars in this block
21:56
<
headius >
enebo: appears to be the same
21:56
<
headius >
I need to figure out what parser is doing different for f_marg
21:56
<
enebo >
you look at f_arg_item?
21:57
<
enebo >
the bug is that that commented out code was not implemented
21:58
<
headius >
simplest case is x = 1; [[2]].each {|(x)|}; p x
21:58
bb010g has quit [Quit: Connection closed for inactivity]
21:58
<
headius >
ahh, sure
21:59
<
enebo >
headius: so MRI at 1.9.3 had this extra logic would would realloc these as new vars
21:59
<
headius >
master has ParserSupport.arg_var
21:59
<
enebo >
headius: at the time I did not get what this was for
21:59
<
headius >
in that section
21:59
<
enebo >
headius: so later on I must have realized I guess and it did not get backported
21:59
<
enebo >
headius: I update our parser pretty coarsely so it probably just looked like new brehavior at the time
22:00
<
enebo >
headius: There is very few commented out chunks in the parser
22:00
<
headius >
hmm 1.7 has arg_var too and they seem identical
22:00
<
enebo >
headius: I think there is one other substantial commented out thing but it is yarv reducing a rich construct into another construct
22:01
<
enebo >
headius: something involving loops
22:01
<
enebo >
headius: so I left it in to remember they did that in that case and I probably commented on it
22:01
<
enebo >
I probably should have pointed out I did not get this snippet
22:01
<
headius >
I don't think it's the commented section
22:02
<
headius >
because this is an f_margs
22:02
<
headius >
you meant that commented section
22:02
<
headius >
the DVAR, LVAR stuff
22:03
<
headius >
but that isn't implemented on master either :-\
22:03
<
enebo >
headius: no but we know what it is in IRBuilder
22:03
<
headius >
so you think we're doing it at build time on master?
22:03
<
enebo >
and isn’t there a helper?
22:03
<
enebo >
well we should still alloc a var in scope
22:05
<
enebo >
hmmm you sure this works
22:05
<
enebo >
Let me look on master
22:06
<
headius >
I see differences in f_margs
22:07
<
headius >
when creating the masgn on master it uses support.assignableLabelOrIdentifier
22:07
<
headius >
1.7 just uses assignable
22:09
<
enebo >
yeah it will check existing slot and make it use existing
22:09
<
enebo >
could it just happen to work out
22:10
<
headius >
well I'm trying to add the method that 9k has for this
22:10
<
headius >
since it just unconditionally assigns the variable in current scope
22:12
<
enebo >
well it makes an assign but it seems like it would assign to where it found it
22:12
<
headius >
yeah that doesn't fix it
22:13
<
headius >
ah yeah...because it still does existance check
22:15
bbrowning has quit [Quit: Leaving]
22:15
<
enebo >
merging those two scope types and using this isBlockOrEval I find a bit harder to read too
22:16
<
enebo >
but yeah assign will make an assign on current depth if it is found on current depth otherwise ask parent scope to look for possible assign
22:17
lopex has joined #jruby
22:18
<
enebo >
headius: I half wonder if subbu fixed this issue by restoring the value on exiting the scope or something
22:18
<
headius >
yeah I'm just not seeing a parser diff that would account for this
22:18
<
headius >
this has to be the right place
22:18
<
subbu >
i fixed what?
22:19
<
headius >
jruby -e 'x = 1; [[2]].each {|(x)|}; p x'
22:19
<
enebo >
the commented code is pretty clear now too that this would fixthis problem
22:19
<
headius >
on master, the block x and the outer x are different variables
22:19
<
headius >
on 1.7 they're the same
22:20
<
enebo >
subbu: in MRI this allocates a local variable in the block but I think we use the outter x but in 9k the x is fine after the block exits
22:20
<
enebo >
subbu: I do not see anything in processing of masgn logic which would allocate a new scoped variable
22:20
<
enebo >
subbu: so I am thinking after the block is done we have a copy() setting the value back
22:21
<
enebo >
subbu: athgouh I could just turn on IR output and look I guess but I magically pinged you by mistake :)
22:21
<
headius >
it seems like both scopes declare their own x
22:21
<
headius >
I just can't figure out how
22:21
<
enebo >
yeah I am foncused by that
22:22
<
subbu >
ok, so, 9k matches MRI but 1.7 doesn't?
22:22
<
subbu >
if yes, i don't remember doing anything special.
22:22
<
headius >
I think this is done in the builder
22:22
<
headius >
ahh here it is maybe
22:22
<
headius >
if (values == null) {
22:22
<
headius >
buildArgsMasgn(restNode, argsArray, false, i, postArgsCount, 0, true); // rest of the argument array!
22:23
<
subbu >
enebo, i know IRClosure allocates vars based on shadowing.
22:23
<
subbu >
i vaguely remember adding code to it to fix broken output from parser ..
22:24
<
subbu >
headius, enebo there are probably comments in IRclosure as well ...
22:24
<
headius >
that would explain this
22:24
<
enebo >
subbu: ah well I guess I should just look for StaticScope.declare in here :)
22:24
<
headius >
it appears to follow one path for masgn with RHS and one path for masgn with no RHS
22:24
<
headius >
the latter is treated as args and allocated differently
22:24
<
headius >
that's not a terrible hack but it means I don't have a trivial fix for this in 1.7 parser
22:25
<
enebo >
hehe IRClosure.getLocalVariable
22:25
<
headius >
look at IRBuilder.buildMultipleAsgn19Assignment
22:25
<
headius >
for each variable chunklet it branches based don values == null or not
22:26
<
enebo >
yeah + getNewLocalVariable called from that
22:26
<
enebo >
yeah it is the method I referenced in IRClosure
22:26
<
subbu >
I will let you enjoy the spelunking in the code ... I am distracted a bit here .. it also happens to be the 15th birthday of wikipedia.
22:26
<
headius >
subbu: enjoy, I think we're on the right track
22:26
<
subbu >
so i want to cram in some work before festivities begin in a couple hours.
22:27
<
enebo >
if it asks for an LocalVariable from a closure it does some extra counting for for loops but then also corrects the AST and has StaticScope allocate a new variable
22:27
<
enebo >
So this fixes it in master but really does just work around that commented out code in the parser
22:27
<
headius >
parser still kicks out the wrong variable declarations
22:27
<
enebo >
so if we kill this then I suspect we can clean up IR a tiny bit
22:27
<
enebo >
and also get a fix out of 1.9 in the process
22:28
<
headius >
yeah, I was just hoping it was a quick one for 1.7.24, pull a line or two out of 9k parser
22:28
<
headius >
but it's more involved
22:28
<
enebo >
well it is not so bad
22:29
<
headius >
so which commented part are you talking about
22:29
<
lopex >
what's the ratio of jruby IR ruby specific features and general optimization techniques ?
22:29
<
headius >
the internal_id etc stuff in f_arg_item?
22:29
<
enebo >
RubyParser.y f_arg_item
22:29
<
headius >
there's a second commented part on 1.7 so I was confused
22:29
<
headius >
$$ = new ArgAuxiliaryNode($1.getPosition(), (String) $1.getValue(), 1);
22:30
<
headius >
so basically we need this "dyna_in_block" flag
22:30
bb010g has joined #jruby
22:30
<
headius >
to force it to be a dvar
22:30
<
enebo >
ok so the weird bit here and this might just be the two impls not being quite the same is we pass an masgnnode as $2
22:30
<
enebo >
nd_value if anything would be an ArrayNode
22:31
<
enebo >
but also it could have n vars inside it right?
22:31
<
enebo >
how could one if statement change these?
22:32
<
enebo >
it is possible they make a bogus var as an AUX var and then when they process this they make all the nested vars local to the same scope
22:32
<
headius >
enebo: which would be analogous to IRBuilder fixing it up
22:33
<
enebo >
yeah perhaps so…i was pretty confused about this AUX thing
22:33
<
enebo >
to the point I commented it out :)
22:33
<
enebo >
this is a pretty wonky solution
22:33
<
enebo >
is this really how they solved this?
22:34
<
enebo >
I think it would be pretty simple for us to just do a ‘$$ = reallocateMargs($2);'
22:35
<
enebo >
where that method is on parser and just gets eahc marg out reallocs on current scope and then returns that new list
22:35
<
enebo >
our staticscope is superior in that we don’t need to check whether we are in a block or not since it is part of staticscope itself
22:37
<
headius >
I'm trying to figure out how they deal with this AUX arg
22:37
<
enebo >
hahahaha yeah me too
22:37
<
enebo >
there is only 5 references to it in the entire source
22:37
pawnbox has quit [Remote host closed the connection]
22:37
<
headius >
they do have the if section that allocates a dvar or lvar but then they wrap that in AUX
22:37
<
headius >
but what the heck
22:37
yfeldblum has joined #jruby
22:37
<
headius >
there's gotta be some fixup code here somewhere
22:38
<
enebo >
they also use this in for
22:41
<
enebo >
headius: one thing is for sure though it wraps a list in this node with an random id
22:42
<
enebo >
well sort of
22:42
<
enebo >
if make [aux(some_id, new_{d,l}var), margs_list]
22:42
erick__ has joined #jruby
22:43
<
enebo >
so it actually allocates a var too
22:43
<
lopex >
headius, enebo what's the best sources to learn aboout jruby IR ?
22:44
<
enebo >
I know why too
22:44
<
headius >
lopex: reading through how we build stuff in IRBuilder works for me
22:44
<
enebo >
it is making a hidden variable because it is an indirect lvar
22:44
<
enebo >
the result of the masgn is itself an argument to the block
22:44
<
enebo >
not one you can directly reference but still
22:44
<
headius >
enebo: ick
22:45
<
headius >
that's what aux is?
22:45
<
enebo >
so |a, (b,c), d| is three lvars
22:45
<
headius >
and they ignore it which is why we don't see it getting used
22:45
<
headius >
or they use it as (b, c) = hidden var yanking out of incoming arg list
22:45
<
enebo >
they do not support zsuper in deinf_method luckily :)
22:46
<
enebo >
headius: that would make most sense
22:46
<
enebo >
headius: somewhat clever in being a simpler impl
22:46
<
enebo >
destructuring does not need to be in instr set
22:46
<
enebo >
or not as much logic anyways
22:46
<
headius >
well then I'm back to wondering how they force the b, c to be local to the block
22:46
<
headius >
so this commented part is not related
22:47
<
enebo >
no I think it is related
22:47
<
enebo >
I just don’t think we figured out how aux fits into it yet
22:47
<
enebo >
This seems to be an implicit local AND a marker
22:50
<
headius >
I think the truth lies in f_margs
22:53
<
enebo >
NEW_DASGN_CURR
22:53
<
enebo >
in assignable_gen
22:53
<
headius >
I'm trying to trace that on our side too
22:53
edub has joined #jruby
22:53
e_dub has quit [Quit: ZZZzzz…]
22:53
<
headius >
dvar_curr is a check for the variable in current dscope, right?
22:54
<
enebo >
I don’t think we have it
22:54
<
headius >
yeah seems like that
22:55
<
headius >
we have the exists check which just checks for variable names but they seem to check a separate list of argument names too
22:56
erick___ has joined #jruby
22:56
erick__ has quit [Read error: Connection reset by peer]
22:58
<
enebo >
headius: yeah true but I am not sure if it matters or not
22:58
<
enebo >
headius: I think it might help for detecting duplicated arg lists
22:58
<
enebo >
headius: although I guess I don’t know why they keep these separate
22:58
<
enebo >
headius: I do not actually see then using this _CURR differently in compile.c htough
22:58
<
headius >
they seem to use it to shortcut the lexical search
22:59
<
enebo >
headius: it seems to generate the same code for block vars
22:59
pawnbox has joined #jruby
23:00
<
enebo >
semantically I am getting a little baffled by this
23:01
<
enebo >
why is |(k)| not shadowing the outer k?
23:01
<
enebo >
why would this explicitly be a new variable
23:01
<
headius >
because all block args are local to the block
23:01
<
headius >
even those in destructuring
23:02
<
headius >
that was a change in 1.9
23:02
<
enebo >
oh for any assignment
23:03
<
enebo >
this can be an indefinitely nested structure of assignments
23:03
<
enebo >
so a simple list processing cannot be done
23:04
<
enebo >
but we could make a margsAssignable method which just allocated a new variable for these assignments
23:04
<
headius >
and the parser reuses masgn logic for the destructuring, but then doesn't know they need to be forced to be block local
23:04
<
headius >
they go back to being normal variables
23:05
<
enebo >
so I think we just change margs to call it’s own support method and we can jhust alloc these on current scope
23:05
<
enebo >
IRBuilder itself can then remove any special fixup logic since all the variables will exist in the proper scope then
23:06
pawnbox has quit [Ping timeout: 240 seconds]
23:06
<
enebo >
unless there is a case I don’t understand which I am increasingly thinking could be true :)
23:07
<
headius >
well the bit I don't get is that we need normal masgn to still shadow
23:07
<
headius >
I haven't been able to figure out what changes between the two cases
23:08
<
enebo >
headius: shadow for lhs?
23:09
<
enebo >
if not in a block I guess they will so we need to know our scope
23:09
<
enebo >
oh but if not in a block it cannot shadow :)
23:09
<
enebo >
so any assignment to var in block scope cannot shadow
23:10
<
headius >
$ ruby23 -e 'x = 1; [[2]].each {|y| (x, _) = y}; p x'
23:10
<
enebo >
but rhs itself can be from outside but that is not a problem it just looks for a var in that case
23:10
<
headius >
$ ruby23 -e 'x = 1; [[2]].each {|(x)| }; p x'
23:11
<
headius >
MRI doesn't appear to like (x) = y so I had to add the dummy var for it to parse
23:11
<
headius >
but you get the idea
23:11
<
enebo >
well I see the difference but I just got confused from this
23:11
<
enebo >
so….masgn can assign as a shadow
23:12
<
headius >
a paren destructuring in the body of the block will see containing scope vars
23:12
pawnbox has joined #jruby
23:12
<
enebo >
but non-masgn assignments cannot shadow
23:12
<
headius >
paren destructuring in the arg list should not
23:12
<
enebo >
paren desrtucturing wll not shadow
23:12
<
enebo >
that is pretty fucking weird
23:12
<
headius >
so we can't just change masgn to never shadow
23:12
<
enebo >
and I am not talking about the destructuring
23:13
<
headius >
this is why IRBuilder checks to see if there's a RHS I think
23:13
<
headius >
if there's no RHS it treats it as all new variables for this scope
23:13
<
enebo >
I mean ‘a = 1; -> { a = 2}; p a’ is 1 but ‘a = 1; -> { (a, b) = [2,3] }; p a’ is 2
23:14
<
enebo >
that is really really surprising semantics
23:14
<
enebo >
semantics I do not thin I realized existed
23:14
<
enebo >
well that is still 1
23:15
<
headius >
well that's not really it
23:15
<
headius >
you need the destructuring in the first one as part of arg list
23:15
<
headius >
as in [[2]].each {|(a)| }
23:16
<
enebo >
heh I did not exectute :)
23:16
<
headius >
that a will always be local to the block
23:16
<
enebo >
HAHA yeah it is 2 now
23:16
<
enebo >
so it leaked in my latter example
23:16
<
headius >
but [[2]].each { |z| (a, _) = z } will use the outer a
23:16
<
headius >
because the destructuring occurs in the body and not the arg list
23:16
<
enebo >
no I am ignoring destructuring
23:17
<
enebo >
I am just coping with the goofiness of masgn shadowing
23:17
<
enebo >
err using outer scope
23:17
<
enebo >
that is really fucking weird
23:17
<
headius >
I don't think it's weird...what is weird?
23:17
<
headius >
they both shadow `a` in your example
23:17
<
headius >
normal variable and a variable in an masgn
23:18
<
headius >
they both will assign 2 to `a`
23:18
<
enebo >
oh haha whew
23:18
<
enebo >
ok thank got
23:18
<
enebo >
it is as I thought
23:18
pawnbox has quit [Ping timeout: 260 seconds]
23:18
<
enebo >
ok so I was confused by the example
23:19
<
headius >
I keep coming back to this NEW_DASGN_CURR bit in assignable_gen
23:20
<
enebo >
headius: ok I am on the same page and your fears need not be
23:21
<
enebo >
masgn is not definted in margs
23:21
<
enebo >
it is by mlhs and friends
23:21
<
enebo >
margs is only for destructuring in arg lists
23:21
<
enebo >
so we can make special method and it wont affect masgn in general
23:21
<
headius >
so we just need to make this always var in current scope
23:21
<
enebo >
yeah I think so
23:22
<
headius >
well that's not too bad then
23:22
<
enebo >
but with that said I do not really see why they designate this as special
23:22
<
enebo >
I guess so they can see it in output peryaps
23:22
<
headius >
I might see where to do it then
23:22
<
headius >
f_marg : f_norm_arg
23:22
<
headius >
where it actually does an assignable
23:23
<
enebo >
yeah I think you just make slightly different version of assignLabelOrIdentiffier
23:23
<
headius >
and probably for the assignables in f_marg_list
23:23
<
enebo >
but you do not care about the label bit
23:23
<
enebo >
that method is for both (foo: and foo,
23:24
<
enebo >
WE DID IT…(being optimistic)
23:24
<
enebo >
headius: I would fix on 1.7 first and then master since you will have extra work to edal with logic in IRClosure
23:24
pawnbox has joined #jruby
23:25
<
headius >
yeah I'll try that
23:30
pawnbox has quit [Ping timeout: 250 seconds]
23:33
tomjoro has quit [Remote host closed the connection]
23:36
enebo has quit [Quit: enebo]
23:36
pawnbox has joined #jruby
23:43
pawnbox has quit [Ping timeout: 250 seconds]
23:43
drbobbeaty has joined #jruby
23:44
<
headius >
I think I have it
23:49
pawnbox has joined #jruby
23:55
pawnbox has quit [Ping timeout: 250 seconds]
23:57
<
GitHub83 >
jruby/jruby-1_7 d3f90ac Charles Oliver Nutter: Move parser scripts to tool.
23:57
<
GitHub83 >
jruby/jruby-1_7 e179f01 Charles Oliver Nutter: Always assign masgn destructured args in block as block-local....