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 - Arantor
6076
Features / Re: New revs
« on October 7th, 2011, 01:17 PM »
Revision: 1068
Author: arantor
Date: 12:17:02, 07 October 2011
Message:
! Oops, more legacy code from the DB dumper that I forgot I didn't need. Mind you, it does give potential for more cleanup later of the Extra class. (Class-DBExtra.php)
----
Modified : /trunk/Sources/Class-DBExtra.php
6077
Features / Re: New revs
« on October 7th, 2011, 01:08 PM »
Revision: 1067
Author: arantor
Date: 12:08:41, 07 October 2011
Message:
! Removed the database backup facility. It was a shade unreliable, especially in UTF-8 circumstances. There are better tools out there for this job, use them. (DumpDatabase.php, Class-DBExtra.php, ManageMaintenance.php, ManageMaintenance.template.php, ManageMaintenance language file)
----
Modified : /trunk/Sources/Class-DBExtra.php
Deleted : /trunk/Sources/DumpDatabase.php
Modified : /trunk/Sources/ManageMaintenance.php
Modified : /trunk/Themes/default/ManageMaintenance.template.php
Modified : /trunk/Themes/default/languages/ManageMaintenance.english.php
Modified : /trunk/Themes/default/languages/ManageMaintenance.french.php
6078
Features / Re: New revs
« on October 7th, 2011, 11:54 AM »
Revision: 1066
Author: arantor
Date: 10:48:31, 07 October 2011
Message:
! Files flagged as not found in pretty URLs mode should indicate that fact when logging the error, rather than them being general errors. (Errors.php, QueryString.php, ManageMaintenance language file)
----
Modified : /trunk/Sources/Errors.php
Modified : /trunk/Sources/QueryString.php
Modified : /trunk/Themes/default/languages/ManageMaintenance.english.php
6079
Features / Re: New revs
« on October 7th, 2011, 11:48 AM »
Revision: 1065
Author: arantor
Date: 10:43:48, 07 October 2011
Message:
! Integrate the fixes from SMF 2.0.1 patch, specifically:
 ! Disable the mod center putting the session into everything. (ModerationCenter.php)
 ! Fix version detection in the package manager, in case I ever reuse that function in the plugin manager. (Subs-Package.php)
 ! Maintenance not dealing with $_POST vars properly (ManageMaintenance.php)
 ! Entity fixes, namely being sure to exclude 0x202D and 0x202E which are LTR/RTL override characters, and making sure certain characters are entitified. (Class-String.php, Subs-Members.php)
----
Modified : /trunk/Sources/Class-String.php
Modified : /trunk/Sources/ManageMaintenance.php
Modified : /trunk/Sources/ModerationCenter.php
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Sources/Subs-Package.php
6080
Features / Re: New revs
« on October 7th, 2011, 11:27 AM »
Revision: 1063
Author: arantor
Date: 10:26:09, 07 October 2011
Message:
! Implemented one of the two changes from BB 2.1.14, to allow Google Web Preview requests. Haven't included the other change, which deprecates testing for # in requested URI since none of the clients that should be using Wedge should be generating that kind of URL as a referrer anyway. (Apparently some broken browsers do - though none of the ones we support, AFAIK, and certain client-side JS will, but again...) (Security.php)
----
Modified : /trunk/Sources/Security.php

@ They set it so you have to go into 'strict' mode to enable that test, but I see no reason why it needs to be deprecated for Wedge. If someone can show me a reproducible case where it's a problem, I'll deal with it.
6081
Features / Re: New revs
« on October 7th, 2011, 11:14 AM »
Revision: 1062
Author: arantor
Date: 10:14:16, 07 October 2011
Message:
! Really rearranged the display template pretty heavily. Each component is now its own subtemplate, and the list is called from Display. There's also a shift of some of the logic (like what buttons are available) being moved to the core rather than in each theme. I don't think I broke anything. (Display.php, Display.template.php)

! As a result of condensing the logic, there was really no need to have two separate hooks for the buttons, so flattened the hooks into a single generic hook at the end of general Display processing, which will have access to everything in app-wide scope. (Display.php, ManagePlugins.php)
----
Modified : /trunk/Sources/Display.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Themes/default/Display.template.php


@ Nao: Something in my brain told me not to make the title_upper and _lower parts (which are used for the page titles/go up+down areas) into a template layer but I'm not sure *why* my brain told me that. If you wanna change it, please go right ahead.
6082
Plugins / Re: Plugin development
« on October 7th, 2011, 09:15 AM »
Thanks for the nudge but I've used JIRA before in my former professional capacity and I'm sure the phrase 'over my dead body' is involved...

Through my RepositoryHosting account, I have access to Trac, and we don't use that. SimpleDesk, though heavily modified, is installed here and we don't use that either...
6083
Features / Re: The calendar
« on October 7th, 2011, 01:00 AM »
Quote
Once you have a stable release people should use that branch
Sadly impractical. It would force never backporting fixes to stable branches, amongst other things, because otherwise you'll have some people using 'the stable branch', and some people using 'the stable branch plus some fixes', and it doesn't solve anything, you actually risk fragmenting things worse.

At least with milestone releases, you can locate issues by version. (It's hard enough to get people to actually say what version they have. Very often people can't even get that right. I shudder to imagine them trying to post by revision; at least SVN has revision numbers - Github doesn't last I saw.)
Quote
it would be better to have them post to branches that you can review and merge back if you accept the fix.
Aside from the small fact that trying to merge the disparate branches would be an absolute nightmare. SMF from whence we came, has a very complex nature of inter-dependence. You can't change one thing without having it spread out throughout. Invariably a bug fix requires changes in more than one place, making it rather difficult to actually do this, especially while new things are being coded around it.

If the code were more modular, perhaps it would be feasible, but certainly not the way it is right now.

Thing is, you haven't convinced me why it would be good to open up the repo, you've just told me how I'd use the result, not why it would be good for me, or for Wedge for that matter. I'm happy to review bug fixes and so on, but I'll be absolutely damned if I accept patches in a manner consistent with Github, where someone creates what amounts to a fork branch, commits their changes and magically expects me to commit it. It promotes the expectation that work will be accepted, even when it really won't.

The number of commits accepted from other people thus far is still in single digits. I do not expect that to change as a trend, because we are very protective of our work thus far, and the culture engendered by Github et al, whereby changes are committed into a repo that makes it 'trivial' to incorporate change is actually in my mind a very bad idea. It makes people complacent about including changes, rather than reviewing and putting in the effort to include it.

You see, in all my experience of development, the actually successful projects survive and thrive because they have a specific culture. They have a culture that is a fusion of a meritocracy and a benevolent dictatorship. In other words, people at the top that make the decisions, and people tend to have their opinion listened to more thoroughly if they've proven that they aren't wasting time/effort. If someone consistently posts poor code, I'm not exactly going to be enthusiastic about accepting their bug fixes, now, am I? Yet, social coding explicitly encourages contribution, but it doesn't encourage *good* contribution.

Putting it in the forum is actually a much better barometer for the quality of something in my experience.

Also, see http://wedge.org/pub/off/6923/plugin-development/ which in hindsight is probably a better place for this discussion because we're now so far off topic from what I hoped to discuss...

I don't think it really matters, there's been enough people that have misunderstood the point of what I'm getting at here judging by some of the responses here, not to mention some of the private responses I've had, that I'm actually inclined to leave it in despite my gut instinct.[1]
 1. I've been wrong before about bundling/unbundling features. It makes me wary to consider it much these days.
6084
Features / Re: These two bytes may not matter to you...
« on October 6th, 2011, 08:17 PM »
Quote from Nao on October 6th, 2011, 06:48 PM
Maybe I just didn't port that bug fix into my copy of Noisen/Wedge.org...? I mean, originally Noisen runs on SMF 2.0 Beta 1 (the September 2007 release), and I applied all subsequent updates manually...
I don't know where the bug was, just that there *was* a bug in code elements with it occasionally eating backslashes, back before RC2 and that I couldn't reproduce it.
Quote
Then, you may easily compress the files.
Anyone can re-download them from the relevant website (getid3 or libsecsomething) and replace their minified files with the originals...
Though I was planning on making it a single file to avoid having to fix the pathing; the paths are all working under the assumption that the include path has been set to include the parent working directory (much as you would in anything using PEAR libraries, as there is a PEAR library included)

If I were to leave it as multiple files, I would at least have to fix the source loading, but that's a very small price to pay.
Quote
Oh, speaking about zipping... I made a few tests with a Sep. 15 revision of Wedge.
I didn't test with WinRK (it's not free), but I think it wouldn't be (much) better than PAQ...
Also, please remember that the Wedge package is currently 50% bigger than SMF's -- add 1.5MB for AeMe, 500KB for /other/stupid-sub-folders/*, and the rest is mainly new features, new code etc...
And some of it is going to get bigger, some smaller, but it's interesting to note.
Quote
So... PAQ does twice better than ZIP, but it's not very realistic to use it (too long to compress, too much Ram needed....), so 7z SFX PPMd (which doesn't require any decompression program per se) would be a good alternative for offering a downloading to non-techies. (Okay, Mac users may be non-techies as well but I'm catering only to Windows users for now...)
Compression isn't really a problem, because it's not like we'll be doing it daily or weekly. The other thing is that we don't need to offer 3 types of package, but offering zip and tar.gz is advantageous, when I deploy a new site, I just wget the .tar.gz to my server, tar -zxf the file and I'm about ready to install.

I'm really not sure that offering self-extracting archives is really that useful.
Quote
I'm not exactly sure, though, why bz2 is less efficient on Wedge than on SMF... Do we have that many extra image files in it, for instance...?
No, but spriting images makes a difference. Both gz and bz2 start by making a single file out of everything before compressing it (while zip doesn't) - and if you have less repeating patterns, like multiple GIF headers condensed into a single PNG file, or the patterns are physically smaller, like shortening file headers, the saving is smaller.
Quote
Oh, and where are you now, regarding the SMF 2.0.1 patch?
Not yet done anything with it.
Quote
Anything we maintain should be readable. Anything else we use, the smaller the better. We don't want a big download size, not because it's "big", but because it costs money to cover for the bandwidth -- although we can probably share the files via Mediafire and so on... Or just extra mirrors... And because I'm not sure people would like to download and reupload a big file 10 times a year just because we release early and often. I know I wouldn't...
(Then maybe we should have some kind of system that automatically sends the updated files to the server.)
In which case it might be worth comparing zipping stuff vs zipping stuff without comments and seeing what difference it makes. But I don't really have an issue with bundling phpseclib as is, just I didn't want to bulk out with 600KB of code if I didn't have to.
Quote
It's inlined because I need to execute it ASAP. Waiting for jQuery to run is out of the question. It would save probably a hundred bytes, but would create a very noticeable delay when loading a page that doesn't match the expected viewport width. Then again, onresize() doesn't execute when using the Back button (at least in Opera), so it's not exactly a 'perfect' solution anyway. Doing my best...
Just wanted to check. A bunch of code, potentially, can be inlined into the page, both actual-inline and delayed-inline, and it wouldn't hurt to be able to minify both - provided that the generation time isn't huge. It wouldn't be Packer, I'd argue the benefit there would be outweighed by the execution cost. But it's certainly worth some experimentation.
Quote
No, I don't think they are (for media files). If you update the file with the same file, it gets the same filename.
Which is a bit of a bummer...
The filename should really include the timestamp.
Quote
Oh, and I'd love us to consider showing preview & full sizes in plain view as well. As long as the filenames can't be 'found out' by analyzing the thumbnail URL...
Hence putting the timestamp in, making one more unknown for an assailant. Though we could get around that by making any folder other than avatars totally off limits (but with the cost of making thumbnails have to go through PHP)
Quote
Yeah, I suppose so... And even YSlow doesn't care about jQuery being there. Only Google PageSpeed does. And it would only save at BEST 2% because I get a maximum score of 98%, even with jQuery loaded normally.
*nods* It has a use, but not here, I suspect.
Quote
But technically it's not used at all because the browser will no longer request the resource (as long as it caches it, of course.)
Hmm, seems like YSlow doesn't recognize my FileETag query. Maybe I should also do 'Header unset ETag'... And any removed header means more space for pure data...
Unless we use ETags, unset them.
Quote
Does Chrome have an extension to help view request headers?
Use the Inspector. Switch to the Network tab, and just wait for the request to be made - you get to see the request and response headers in full.
Quote
Yeah, well, I suppose it's not as scary if the cookie is loaded sent once. The first packet will be shortened a lot, but not the rest.
The cookie isn't actually that big, and it's not like we can readily shorten it either.
Quote
Ah, I forgot about that ticket...
Then I guess we agree on this, eheh.
Do you want to implement the change?
Yes, fully to put avatars in their own folder and have them requested directly rather than through PHP.

Considering that SMF can do this already, I was only originally planning to make use of the existing code, but strip out the other stuff of serving avatar files through dlattach. I hadn't factored in working with Aeva at that point.
6085
Features / Re: New revs - Public comments
« on October 6th, 2011, 07:46 PM »
I'm not so bothered by the physical status part, though that is ultimately the way to do it. What concerns me is how we show the user. How do we display it?

I'd also prefer to separate deleted-by-author from deleted-by-moderator.

As far as empty-skeleton errors, that implies a logic error, and if there isn't a fatal error shown to the user, what would happen? I'd argue that a page with no content is less helpful than a page with an error message.
6086
Features / Re: New revs - Public comments
« on October 6th, 2011, 05:50 PM »
Quote
We should probably get started on removing the bin right now...
That's cool, provided that we come up with a functional replacement.
Quote
Are we talking about the same thing...? The empty skeleton error?
I didn't get into the error in recycling topics, I didn't see a lot of point, but I did look into the other error that was mentioned at the same time in repairboards.
6087
Features / Re: The calendar
« on October 6th, 2011, 05:49 PM »
You're asking me why it would be so bad to have an open repo - tell me then, why would it be so good if people could pull from a repo instead of having to download the source? Having a milestone release means waypoints for support, for version control etc.

People using SVN versions, except under limited cases, invariably makes the problem so much worse from any real practical perspective, at least in my experience.
6088
Features / Re: The calendar
« on October 6th, 2011, 05:17 PM »
Why does it have to be an open repo for other people to contribute? All it needs is *active* maintainers and people contributing - the mechanics of it do not require it to be open. In SMF's case, I was contributing bug fixes 8-9 months before they were taken into the core, for example - and their repo isn't open (nor was it at the time), but it didn't prevent me contributing. The blockage was not a lack of openness, but a lack of active maintainers looking at supplied patches and implementing them or rejecting them.

I also doubt that we'll add too many core developers to the project.
6089
Features / Re: These two bytes may not matter to you...
« on October 6th, 2011, 04:15 PM »
Quote from Nao on October 6th, 2011, 04:08 PM
Is this on Wedge, or Wedge.org...?
Wedge.org is running SMF2 RC4, not Wedge.
It's here. Back when you posted your code sample testing var_export vs serialize a page or so ago, there's a string with <?php in it which should be followed by \n but isn't, it just becomes <?phpn in the layout.

It's originally an SMF bug around how it does the post split to push things to the highlighter but I thought it was long since (pre RC2!) fixed.
6090
The Pub / Re: Is accumulating Editor in wedge like the one in wordpress a big deal
« on October 6th, 2011, 04:14 PM »
Yes, they can provided we haven't removed or otherwise broken that code.