Page 1 of 41 | Next »
[16:17:11] matthewd: https://github.com/rake-compiler/rake-compiler#cross-compilation---the-future-is-now
[16:17:34] matthewd: (but it's been a long time since I cared, so no idea how easy, or how current, that is)
[13:26:00] matthewd: user3: The order of the comparison is significant; you probably need it the other way around
[13:39:33] matthewd: It's a good way to get a handle on the codebase while doing something I'm already familiar with ¯\_(ツ)_/¯
[10:02:36] matthewd: okraits: Check config.cache_store; action_controller.perform_caching doesn't affect the low level cache
[02:47:27] matthewd: RickHull: You've thrown a bunch of code in there, but haven't managed to use many actual words
[02:48:27] matthewd: RickHull: Are you saying "this has changed behaviour; the thing that used to give a warning now raises"?
[02:49:57] matthewd: RickHull: Because yes, it does. It's the second feature listed on the release announcement.
[07:06:08] matthewd: Personally, I think I would expect the raise when you define it in Kernel or BasicObject -- i.e., that it would raise when traversing Object, not just if it's found exactly inside Object.
[07:19:19] matthewd: ... because the above is just a slightly more verbose way of spelling `X = 1; String::X`
[07:20:44] matthewd: Because ~everything subclasses Object, and everything is defined in Object. The old behaviour was confusing, because a subclass reference would always "work".
[07:21:05] matthewd: That's why it's had an aggressive warning for a while, and that's why it's now going away.
[07:23:01] matthewd: Object is the top level. It is not useful for its contents to be inherited like that. Because it is the top level.
[07:25:20] matthewd: It's not; that's the behaviour you showed that I agreed was surprising. (And which fxn previously commented on.)
[07:27:15] matthewd: [12-02 17:36:08] <matthewd> Personally, I think I would expect the raise when you define it in Kernel or BasicObject -- i.e., that it would raise when traversing Object, not just if it's found exactly inside Object.
[07:29:42] matthewd: Yes, that particular behaviour is odd. But I think it's currently rather lost in your issue, which seems to mostly state things that are obvious to anyone who already knows how constant lookup works in principle.
[07:30:35] matthewd: Sorry, that sounds more condescending than I mean it to... I mean "for the subset of people with reasonable specialist knowledge here, there's eye-glazing before getting to the point they might in fact find surprising", not "any reasonable person should know this"
[07:31:59] matthewd: Well, it goes back to the fact that Object is the root of everything -- that's where "global" methods come from, and that's where "global" constants come from
[07:34:03] matthewd: Well it hasn't needed special rules for 20 years... it's just now being found that the lack of special rules can be confusing, because the generic rules have unfortunate overlapping implications
[07:34:53] matthewd: Or at least, it's just now being addressed by the introduction of special rules. The potential for confusion has been understood for a while.
[07:38:28] matthewd: I only recall people explicitly defining constants into Object where they specifically intended to define a top-level constant
[07:39:10] matthewd: So, I won't claim that no-one is doing so, but still... if people were getting the warning, and then they changed their code in a way that they no longer got the warning, then they're fine
[07:39:44] matthewd: If they got the warning then ignored it because they decided they knew better and that a strict reading meant it didn't actually apply to what they were doing, then that sounds too bad for them
[07:44:09] matthewd: And that's the problem here: the unreasonableness is having to be introduced, because the alternative is also disturbing
[07:45:10] matthewd: He sees no relationship between shugo's example and his, despite the fact the only difference between them is whether the parent is Foo vs Object
[07:50:57] matthewd: `String` looks up that constant in the current scope's parents, and finds it in Object
[07:51:39] matthewd: The only thing special about Object as being top-level is the fact it has the `::Foo` special syntax
[07:52:12] matthewd: But unless you're using that leading-:: style, you're always using inheritance-based lookup
[07:53:35] matthewd: I understand your point, but I'm refuting your "now Object/toplevel is weird and special" point, by noting that a simple implementation of that idea would break all constants
[07:56:52] matthewd: I think modules may get trickier.. if someone explicitly does a top-level include of a module, then having that module's constants appear on every object isn't necessarily wrong
[15:51:33] matthewd: krawchyk: Either underneath some other top-level entry (which depends on it), or under dependencies at the bottom (meaning it's pulled in by your Gemfile explicitly)
[15:52:05] matthewd: krawchyk: So, mail appears at the "top" here: https://github.com/rails/rails/blob/master/Gemfile.lock#L308
[15:52:49] matthewd: krawchyk: That lists *its* dependencies, but there must also be some reason, in the file, for why it's included at all
[15:52:53] matthewd: In this case, we find it here: https://github.com/rails/rails/blob/master/Gemfile.lock#L55
[15:54:56] matthewd: Note that it's *not* a tree -- it's a two level list, showing "gem -> its dependencies"
[15:55:30] matthewd: *Why* that gem is in the list is found elsewhere -- whether it's as another dep (in this case), or an explicit reference
[15:56:34] matthewd: Note your other option is the 'reverse dependencies' link on rubygems.org -- but that obviously tells you about all of them, not just the one(s) you have installed
[11:34:55] matthewd: terens: Is there a competing suggestion/approach for you to compare & contrast? Or just general doubt?
[11:39:41] matthewd: morfin: Slightly more detailed reasoning: https://github.com/rails/rails/pull/31082#issuecomment-342656259
[12:28:03] matthewd: Guest90927: $1 looks like a global, but is actually a specially-scoped local.. tbh I'm actually not sure whether that's relevant in this case
[03:42:30] matthewd: As I said, if you're not checking the result of `create` (which you obviously weren't), then you should call `create!`
[03:42:47] matthewd: ... because it will tell you if it fails to create for some reason, which you're now seeing
[03:43:11] matthewd: So yes, to address the problem, now that you can see it: you have a validation issue
[04:40:39] matthewd: If the object goes away, its file will eventually get closed by the garbage collector anyway.. but it's better practice not to rely on that (partly just because it could be some time later)
[04:51:17] matthewd: Sounds plausible -- though if things are convoluted, you might want more of the call stack
[06:05:19] matthewd: The association tells it to *use* the attribute; whether the attribute *exists* depends on there being a suitably-named column
[06:06:09] matthewd: course_id is the default FK name for `belongs_to :course`, btw, so you don't need to specify that
[06:15:48] matthewd: I can never remember the details of the migration generator magic, but yeah that sounds right
[06:27:27] matthewd: Right, so that's empty. You need to rollback the migrate you ran, then edit that file to tell it to add the new column
[06:31:13] matthewd: So now you can delete one of those, and change the other to actually add the column
[03:28:37] matthewd: clamp! would be impossible because Comparable can't mutate its value, and Comparable can't mutate its value [partly] because many of its most popular values are always frozen
[03:42:34] matthewd: Mutter: If you have more specific questions, I'm sure we can be more helpful. But a full discussion comparing the syntaxes and trade-offs seems better covered by the various long-form articles that turn up in a Google search
[06:38:23] matthewd: RickHull: You get a NoMethdError, because your Foo instance doesn't have an include method
[06:58:43] matthewd: I don't understand what this is doing.. too much code for me. But my gut says you need fewer classes, not more.
[07:10:55] matthewd: Similarly, why are Node and Tree separate? If the methods were on Node, they could naturally operate on a subtree
[07:16:48] matthewd: I don't understand what problem this is solving. Right now, it looks like it's creating a complicated API that I wouldn't want to use, and then the implementation flows from that. How should you refactor the implementation? By changing the API.
[07:31:43] matthewd: hailey27: Does https://github.com/sparklemotion/nokogiri/issues/740#issuecomment-300370426 help?
[07:42:25] matthewd: Seems like you could do https://github.com/sparklemotion/nokogiri/blob/master/lib/nokogiri/xml/document_fragment.rb#L22-L25 for yourself
[07:43:01] matthewd: Create an empty fragment, parse as a full document, then move the children over
[07:43:59] matthewd: Alternatively, I don't know whether the ctx parameter there could be useful as an avenue to get some hints into the parser?
[07:46:04] matthewd: Given it's all the "real" documentfragment constructor seems to do, I don't think I'd even feel that bad about it :)
[07:48:41] matthewd: Yup, checks out: https://github.com/sparklemotion/nokogiri/commit/c23eb88b2707a82bc04f807d2d043755ff503c8e
[09:34:37] matthewd: Andr3as: Use save! (and friends) if you're not checking the result of calling save (etc)
[10:19:58] matthewd: phedkvist: `git fetch origin; git rebase -i origin/master`, then delete all the lines that aren't yours
[10:35:58] matthewd: phedkvist: No worries! Do you happen to know how you got into that situation, btw?
[10:36:41] matthewd: I'm wondering if we have something to fix in our docs, because you're not the first person I've seen with that problem
[10:53:59] matthewd: phedkvist: Weird.. I don't immediately see where that could've gone wrong. (Though I assume it was the rebase, somehow)
[10:54:55] matthewd: megan1993: Forms are generated in views, which don't have any influence over the subsequent incoming request