Closed CodaFi closed 11 years ago
Of course, I don't have the reigns to this, but :shipit:! :D
EDIT: What's with the binary files added? Those shouldn't be here...
Yes, perhaps that would be cleaner.
:+1:
The hidden files (backups?) should be removed.
:mailbox_with_mail:
I don't see any hidden files that shouldn't be there. Perhaps this is a side-effect of Quarantine on OS X ML screwing with my drive. Also, now that I look into it, it seems to be a Git issue. The branch-creation mechanism must have done a little more than it was supposed to.
See the diff on github.com. There are definitely file additions.
Yes, I know, but for all intents and purposes, they don't exist physically. The finder can't find them, searches turn up empty, and even the terminal thinks they don't exist.
Use the GitHub for Mac app, rollback the commit, and when you try to commit the same exact thing, uncheck the _lib
files from the commit, and push those alone. That helps.
Ah! Got it (with a sudo rm -rf
, @jwilling LOL). Will merge in a couple of minutes, any objections?
@CodaFi Don't merge your own pull request. Let others handle it. :+1:
Objection noted.
How are you allowed to merge to TwUI though? I see no such option on any PR. And also, how are you assigned to a PR?
:postbox:
If you can, please use the two suggestions I've given above and apply them to the rest of the file. However, I should note that if the block has a return type there should be a space between it and their arguments.
Is this not optional? Simply using a proper return statement should be fine.
@galaxas0 Any new contributions should adhere to the style guide as much as possible. The conventions specify that there should be a space between the arguments and the return type if the return type exists. Since it is defined in the style guide, we should conform to it.
Ah! Thanks!
I believe the source of the weird backup files was because my Github/TwUI repo was being kept on a USB stick (which I reformatted), but apparently either one of the SanDisk crapware processes or Spotlight has been trying to backup and index those files. Not good
@jspahrsummers Any idea why changing the pointer type inside of a typdef
d block would throw build warnings?
It makes sense, actually. The block expected is one that accepts any kind of TUIView
(although in practice it will only receive a single one), so passing in a block that expects a more specific type should logically result in an error.
So, flip-flopping: because we need a cast, I think we should go back to (id)
, which is less fragile than a specific type.
@jspahrsummers That's odd, why not simply cast the block as a (TUIViewDrawRect)
with whatever TUIView
superclass you'd like?
Casting a block destroys a lot more type information than casting an argument to a more specific type. If the block type changes in the future, the call point won't break, and crazy shit will result.
@jspahrsummers I didn't think of that! You're right, no one wants crazy shit to happen. (suddenly, I remember shitIsBad
in the coding conventions....)
Is there a reason this hasn't been merged yet? :D
Patience, young grasshopper.
@jwilling LOL, alright, then i'll go back to hopping.... :dash:
@CodaFi You could squash the commits to remove the few commits that went back and forth changing the style.
@galaxas0 Yes, I understand that, it was the first thing I tried, but GHfM spawned a weird git cherry-pick process, and threw errors every time I tried to revert the commit.
@CodaFi Ah, that's not good. Alright, doesn't make an exactly earth shattering change, so it's all good.
:shipit:
Cleaned up a couple of places where TUIPopover and TUIProgressBar had declared a
weakSelf
pointer, but didn't actually use it inside the block (:facepunch:), thus leading to retain cycles.