Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
4741
Features / Re: New revs
« on July 20th, 2012, 10:32 PM »
rev 1641 -- the Post commit. More to come... (Scary stuff.)
(2 files, 2kb)
! Post page didn't present current attachments in the right order. (Post.php)
! Post page ignored zero-byte attachments in some situations. (Post.php)
* Used the opportunity to simplify the current_attachments array and remove the deprecated 'approved' flag. At this point it's only an array because of the 'unchecked' boolean. (Post.php, Post.template.php)
(2 files, 2kb)
! Post page didn't present current attachments in the right order. (Post.php)
! Post page ignored zero-byte attachments in some situations. (Post.php)
* Used the opportunity to simplify the current_attachments array and remove the deprecated 'approved' flag. At this point it's only an array because of the 'unchecked' boolean. (Post.php, Post.template.php)
4742
Features / Re: Github & stuff
« on July 19th, 2012, 01:17 AM »
@CJ> You're saying it's easier to use. I'm saying it's harder to install. I'm just asking, what tells me it's going to be 'easy' to use once I install it? SmartGit isn't that hard to use, heck even TortoiseGit is okay after the initial learning curve...Quote from PantsManUK on July 18th, 2012, 05:13 PM Apparently, the command-line is the best possible git tool ahah... Says Linus himself. Of course.
Hey I laughed at this quote of his:
"Btw, (...), you're a quality example of why I detest the github
interface. For some reason, github has attracted people who have zero
taste, don't care about commit logs, and can't be bothered."
Source:
https://github.com/torvalds/linux/pull/17#issuecomment-5659970
The thread is a funny read... Although I stopped early on.Quote from PantsManUK on July 18th, 2012, 05:13 PM I cloned a GH repo earlier today (ah, the SHA-1 really doesn't help to keep track...), directly from github with the command line. It was alright. And I don't have to go through this annoying process of forking in my account, and thus encouraging people to look at my awful code... :P
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
Git's workflow is quite different to that of SVN, but Git and Hg have very similar workflows (as someone that uses/has used all three). TBH, once you get your head into the two-step commit/pull way of working, it's not a hassle. Personally, I much prefer Git, but that's cause I've mostly migrated all my development work over to my Mac and that has Tower - The most powerful Git client for Mac (best damn Git client it's been my pleasure to use; I just wish someone would do something this good for PC).
Hey I laughed at this quote of his:
"Btw, (...), you're a quality example of why I detest the github
interface. For some reason, github has attracted people who have zero
taste, don't care about commit logs, and can't be bothered."
Source:
https://github.com/torvalds/linux/pull/17#issuecomment-5659970
The thread is a funny read... Although I stopped early on.
Between GH and BB, I prefer the BB website, but I'm not using the wiki or ticketing systems on either of those two sites. Tower has inbuilt GH integration (you can create a GH repo from within Tower, and some other stuff too, but as I say, I don't really use it so the integration is overkill for me and my workflows)
Anyway, I'm still not entirely convinced. I think that for now, repohosting or bitbucket will be fine...
4743
Features / Re: New revs
« on July 19th, 2012, 12:53 AM »
rev 1640
(6 files, 3kb)
+ Added a we_board variable to board pages. Although it's less often used than we_topic, it's still worth adding it, if only for future plugins. (Display.template.php, index.template.php, Post.template.php, post.js, topic.js)
* Moved delete and submit strings to the generic JS code (instead of just the thought code), so that guests can always see them without having to load them twice. (index.template.php, script.js)
(6 files, 3kb)
+ Added a we_board variable to board pages. Although it's less often used than we_topic, it's still worth adding it, if only for future plugins. (Display.template.php, index.template.php, Post.template.php, post.js, topic.js)
* Moved delete and submit strings to the generic JS code (instead of just the thought code), so that guests can always see them without having to load them twice. (index.template.php, script.js)
4744
Features / Re: New revs
« on July 18th, 2012, 08:36 PM »
rev 1639 (the bugfix commit)
(5 files, 2kb)
! Non-file cache systems (at least APC) were broken in Wedge because failed cached retrievals wouldn't be properly detected. (Subs-Cache.php)
! Navigating user posts would lead you to the wrong profile when visiting older pages. (Profile-View.php)
! Undefined index in voter visibility code (poll_votes_visible was used instead of poll_voters_visible.) (Poll.php)
! A couple of bugs with zlib.output_compression. (index.php, SSI.php)
(5 files, 2kb)
! Non-file cache systems (at least APC) were broken in Wedge because failed cached retrievals wouldn't be properly detected. (Subs-Cache.php)
! Navigating user posts would lead you to the wrong profile when visiting older pages. (Profile-View.php)
! Undefined index in voter visibility code (poll_votes_visible was used instead of poll_voters_visible.) (Poll.php)
! A couple of bugs with zlib.output_compression. (index.php, SSI.php)
4745
Features / Re: Github & stuff
« on July 17th, 2012, 06:11 PM »I use git-cola interface, very easy to work with and is cross platform.
I'm not sure it's that 'easy' to work with if it requires installing msysgit, *then* Python, then PyQt... Meh! :^^;:
Posted: July 17th, 2012, 06:04 PM
The problem with giving direct access to commit is that you cannot review their work before including, it,
in some ways, can be worse than a pull request.
Posted: July 17th, 2012, 06:08 PM
I'm wary of dragging us into that particular quagmire. I'm hoping that there will be a higher quality of submission of plugins.
Wow, they actually made the repo public, as opposed to the playpen repo. But yes, it is as I suspected.
RH's bug tracker is pretty good, IMO, you should be able to try it out?
Yup it's now the main public repo, didn't realise it had actually been moved (see, I told you I don't check their repo!)
Oh, and BTW, I'm now 'officially' post-unbanned from simplemachines.org. It took some time because the person who originally unbanned me didn't remove the custom additional group I was in that prevented me from modifying my profile (ahem) and posting on most boards as well.
4746
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on July 16th, 2012, 06:47 PM »
In Moldova, Wedge releases you.
(Well, for some reason it doesn't work as well as those Soviet Russia jokes.)
Quote from Inter on July 16th, 2012, 04:35 PM Would work better if you told me how to reproduce that...
There's only one $(this).data('that'), and it has single quotes, not double quotes, and it's in the toggler code, and it works fine for me... -_-
(Well, for some reason it doesn't work as well as those Soviet Russia jokes.)
Posted: July 16th, 2012, 06:44 PM
Code: [Select] Time: 16.07.2012 17:34:11
Error: $(this).data("that") is undefined
Source: http://wedge.org/cache/script-1342367230.js.gz
Line: 7
There's only one $(this).data('that'), and it has single quotes, not double quotes, and it's in the toggler code, and it works fine for me... -_-
4747
Yep, but I just can't bother to download Nas's repo and install it just to watch that... :P
I'm sure it looks good, too. Hey, if it's SMF 2.1 then we can happily steal from it :lol: I'm sure he'd be glad, too.
Although for now I'd rather use a <progress> bar, I'm sure in the future I'll want to harmonize its looks.
I'm sure it looks good, too. Hey, if it's SMF 2.1 then we can happily steal from it :lol: I'm sure he'd be glad, too.
Although for now I'd rather use a <progress> bar, I'm sure in the future I'll want to harmonize its looks.
4748
Features / Re: Github & stuff
« on July 16th, 2012, 06:21 PM »Yes and no. Being open means you open the doors to a potential flood of submissions. You then have the joy of wading through the submissions in the hopes of finding good things. If you get a collection of great coder submissions, great, but the odds are not in favour of that being the case, given what has been approved as mods in the past.
Seriously, being open is not the magical panacea it's supposed to be. Being open means you get more input. It doesn't mean it's any *better* input. If anything I'd almost say that it will eventually dilute things because there will be pressure to accept patches that aren't up to snuff.
If it's not up to my standard, I'll just comment on the source code and tell people what's wrong with it. (It's one of the advantages of github -- you can comment on a specific line.)
Then I'll wait for them to adapt their code because later they'll remember to do it without my input.
Well, it's pretty much what John did after I commented his commits to Wedge back in the day ;)
Consider the past of SMF. It was hard enough getting to be a beta tester, let alone a dev badge.
Consider the people who earned that badge. Consider also the people who've submitted patches in the past to SMF, and how few of those were historically accepted. It's not merely a lack of time that caused all those things to be the case, it was the overall low quality of submissions.
In the SMF 2.1 repo, though, there's quite some activity (on par with Wedge I'd say.)
In the end, though, it's mostly about two developers, emanuele and spuds, doing most of the commits.
https://github.com/SimpleMachines/SMF2.1/graphs/contributors
Aside from them, *only* team members (or ex-members) can be found: norv, Thantos, Nas, John, nend (beta tester IIRC -- I suspect he's sicommnend at github), Trekkie, DrDeejay, IchBin.
So, even though the development process is now public, it's pretty much as if SMF had given commit access to all of their teamies. No need to go public indeed. I guess that going public and hoping for developers is either good for limited projects (which are more likely to receive external improvements, maybe the JS and PHP snippets I wrote could be part of that), or for huge projects that a lot of people are into, such as a programming language or OS or whatever.
I could suggest that we open a private git or mercurial or svn repo somewhere with a bug tracker (with a good one I mean... I don't know if RH's is any good?), and then we give commit access to anyone who requests it (basically people in our Friends and Consultants groups).
I know that a couple of years ago I was more protective of the codebase and will probably keep annoying the hell out of people like I did with John (and I'm still sorry about that), but I think it's better to have as many people as possible on the project, than basically just me these last few months. I'm sure there are areas that others would like to modify.
We could use a DCO like SMF 2.1 currently does, if no one wants to write a contributor agreement. The copyright would still be shared between Pete and I. No secrets about that, obviously.
To be brutally honest, I want to be wrong about this. But I want to see SMF take their main repo public and see what happens, I see no reason to think our experience will be substantially different. Everything I'm predicting is almost certain to come true sometime after SMF makes the 2.1 repo public, and I do not want us to fall into the same trap.
Don't see why it would be an active repo if it's not the official one..?
4749
Okay, found it... I think.
https://github.com/SimpleMachines/SMF2.1/pull/59
I can't see it in action, so I have no idea what it looks like. But it reminds me of Dragooon's bars because they're skewed by 45°.
As for keyframes, I did a bit of testing and here's what I came up with:
Code: [Select]
This works just fine...
What's your problematic code then?
https://github.com/SimpleMachines/SMF2.1/pull/59
I can't see it in action, so I have no idea what it looks like. But it reminds me of Dragooon's bars because they're skewed by 45°.
As for keyframes, I did a bit of testing and here's what I came up with:
.cat
-prefix-animation-duration: 3s
-prefix-animation-name: slidein
@-prefix-keyframes slidein
from
margin-left: 100%
width: 300%
to
margin-left: 0%
width: 100%This works just fine...
What's your problematic code then?
4750
What is it?
http://wedge.org/do/media/?sa=stats
@Pete> What style by Nas? The thing I'm talking about was cooked up by Dragooon for AeMe...
Posted: July 16th, 2012, 10:53 AM
Oh, er, yes, it is.
That's how I found that keyframes won't work in WeCSS.
Did you try putting keyframes into a separate CSS file using the regular CSS syntax? Just to know if it's a parsing issue or something else...
4751
Features / Re: Github & stuff
« on July 15th, 2012, 11:27 PM »
Then SMF 2.1 has an edge over us..?
4752
Features / Re: Github & stuff
« on July 15th, 2012, 08:44 PM »
Well, why wouldn't we be soliciting their help...?
4753
Features / Re: Media boards: fishing for opinions
« on July 15th, 2012, 07:25 PM »No, but you get a lot of data to work with to be able to understand how running a larger forum is likely to handle the extra load.
That's a very good question. What it means to me is that MessageIndex.php needs an overhaul, possibly loadBoard() needs to identify the type of board involved and when we would otherwise divert to MessageIndex, we figure out which file needs to be loaded for that type of board.
MessageIndex.php would load the main stuff, then would determine the board type and call MessageIndex-Blog.php or whatever. (Or just the corresponding template.)
Same for Display -- Display-Blog.template.php, etc.
This would probably help performance if implementing tons of board types. Also helps with plugins enabling their own board type...?
Now, as for your comment, I'd just like to say that nothing prevents MessageIndex from redirecting to the current code in the /media/ folder. Well, what I really mean is, solution (A) would change the album URLs to use something in the style of board URLs, while solution (B) would keep using ?action=media;sa=album;in=123 where the albums table stores id_album = 123 and id_topic = 345, and id_topic is a custom topic created in a custom (unique) board. The main point is that the code changes are limited, the main drawback is that you can't set up board permissions on the album, rather you have to use the current album permission system -- of course the album permission system is currently better because it offers to ban/allow users on a case by case basis, while boards, and will force you to create a custom group just to allow or deny someone.
I'm not sure what the best would be... Hence my poll.
Heck, the C and D solutions are also complex in that they effectively remove 'albums' from possible 'floating boards', instead having a single hidden board hold all of the albums as topics.
(Of course, I could also have added another suggestion where we have a single hidden board to represent the gallery, and then one topic per item -- with the item/album/category relationship being maintained in the media tables. That would make sense, too...
So, to keep it short, solution A makes the most sense if we want to go fully 'floating boards'. Other solutions might be better for performance. I don't know.
Anyway, yes, the point is correct: if you do a query where you're sorting by any column and there's a TEXT or larger field in there, it will generate a disk-based temporary table (this is what a filesort is). Getting around it using a subselect is an interesting way of doing it, but essentially yes it's correct, it fools the query parser as to how the table is generated and it means it isn't implicitly a filesort. At that point you just have to hope MySQL can get enough memory to do it in memory otherwise you end up with a filesort anyway.
Well, thankfully, MySQL queries can be optimized later on, they don't have to be static :)
4754
Features / Re: Media boards: fishing for opinions
« on July 15th, 2012, 07:41 AM »
And benchmarking is something I'm not sure about doing for now... (Well, maybe we can use John's latest plugin for that :P)
I like the idea of a subselect, though, ideally, because it's cleaner and at least it gives MySQL an opportunity to optimize by itself. Only problem is, MySQL is usually not too good at that task... :^^;:
Only one vote in the poll? :sob:
Pete, that reminds me of this post I saw this week...
http://developwithstyle.com/articles/2012/06/22/speeding-up-sql-queries-containing-text-fields/
Do you think that's true? Because if it is, doing MySQL is like fucking voodoo to me :P
I like the idea of a subselect, though, ideally, because it's cleaner and at least it gives MySQL an opportunity to optimize by itself. Only problem is, MySQL is usually not too good at that task... :^^;:
Only one vote in the poll? :sob:
Posted: July 15th, 2012, 07:30 AM
Pete, that reminds me of this post I saw this week...
http://developwithstyle.com/articles/2012/06/22/speeding-up-sql-queries-containing-text-fields/
Do you think that's true? Because if it is, doing MySQL is like fucking voodoo to me :P