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
5821
Off-topic / Re: Adding Value to the project
« on October 19th, 2011, 03:51 PM »
Hindsight is a wonderful thing. Hindsight tells me that programming viewpoints were needed earlier on, but right now for the bulk of things, we're actually finding that we need probably an even split between programming and non-programming viewpoints.

Take the bulk of the discussion of last night and today in the New Revs - Comments threads. That's talking about ACP options, where they are, how illogical and useless they are where they are (as they're not even searchable) and whether they should be moved. Very little of that is programming related, in all honesty.

Tell you a little secret: having people who aren't technically inclined helps us get it right more than you'd think.
5822
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 03:49 PM »
Yeah, it's pretty headache inducing, but it's been interesting to read up on the finer points of HTTP.
Quote
AFAIK, the only point is to allow for more simultaneous downloads off a single server by reusing earlier connections
Yup. Specifically it saves you the lookup at the TCP level, which if you're doing a lot of work is worth saving but for individual file requests, it's not worth it - even if you do two or three in sequence (e.g. browse list of plugins, browse category within list) it's still not actually going to benefit you too much and in almost every case it would be better to let the host have the TCP connection back instead.
Quote
Oh, and can you look into reusing weget for AeMe as well...?
Sure thing. Once it's tested, anyway ;)
5823
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on October 19th, 2011, 03:28 PM »
Quote
there's no space for anyone to argue about it. They just have to wait till it comes out and [only] if you guys want to make it public..
That's the thing. Too many people seem to assume that things are their 'right' to have.
Quote
About  the "and is exactly the sort of people (like yourself, I hasten to add) that I want to work with", dont count on that. Not really because i dont want to but only because im just a 0 at scripting..
But it's not all about the code. Some of the best suggestions here have been from people who aren't coders. Too much of SMF is built by coders who think like coders, and not enough input from non-coder users.

Take the admin panel. I understand the logic by which it was all built. I understand the implications on a technical level of why things are where they are and how they are. But the average user doesn't, and it makes it harder for average users to use because they don't see it how a programmer sees it. They see it how a regular person would see it - which ends up being confusing and frustrating.
Quote
Well, once again, sorry that I took some of your time for this. Wasnt really my intention..
No need to apologise; the only person who needs to apologise is me for snapping like I did, for which I'm sorry. The above rant wasn't aimed at you, just you happened to be the one who tripped the breaker, so to speak. At least now there's a general thread answering the question and it's probably the most obvious place for it...

Besides, it's nice to have someone else in the camp who understands what's going on :)
5824
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 03:12 PM »
Hmm, further to the above, I do actually need to use HTTP/1.1 for Range support, that's cool because it's only actually an issue in fsock cases since cURL will just deal with it transparently. Interestingly, I think that's actually a bug in fetch_web_data, it issues an HTTP/1.0 block with Host as a supplied header, which didn't exist in HTTP/1.0.

Still, it doesn't change my modus operandi; I'm still rewriting to exclude keep-alive because we're not keeping connections alive between requests in almost every case.
5825
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on October 19th, 2011, 03:05 PM »
Please understand, it wasn't directed specifically at you. It's the fact this comes up surprisingly often, and the answer is within the forum.

The problem is that people don't really get the fact of how much work is really required and when they realise we've been on this for over a year already, they seem to expect it sooner rather than later... and a number of those people don't care about quality, or indeed it being good for anyone else, they just want what they want and don't care about anyone else.

Many people waiting for something isn't necessarily a good thing. First of all, it puts pressure on us to deliver, which for a hobby project isn't necessarily what we want. But it's interesting to note how many people are enthusiastic, and I suspect that reflects how many people are discontented with SMF 2.0 going final.[1]

People who appreciate the effort and time, and are prepared to wait and add their opinion when we put something up for discussion - this is great, and is exactly the sort of people (like yourself, I hasten to add) that I want to work with, that I want to be involved with.

People who just come here expecting free stuff and not putting anything of their own in, I have zero patience for. You strike me as firmly in the first group :)
 1. A fact that I warned them about, over a year ago, even before 2.0 RC4 was out.
5826
The Pub / When can I download Wedge? / Where can I download Wedge?
« on October 19th, 2011, 02:48 PM »
Right now, you can't. It's not done yet. And if we were to release it right now, it would really be inappropriate.

There's a lot of things that we want, and need, to do that haven't yet been done. Some things are fundamentally broken or missing critical functionality.

Even if you're a hardcore user, it's still not ready for you, because even the installation doesn't work off the bat without some work (the installer is not stored in the main folder, and has to be moved from another folder prior to installation to make it work properly)

We know you're eager, because we've told you all the goodies that are coming in Wedge, some that are done, some that are coming. But you really need to understand that firstly, it's just two of us writing it, and that we do have lives outside of Wedge - even though we're putting a vast amount of time into it.

This post will be updated in the future, though, as it becomes available.


Why did I even write this? It's because I'm frustrated. I've lost count of the number of people who've come here asking for downloads. Some post publicly, some privately message me, and I'm fed up of it. We don't owe anyone anything, and while I love working on it, I don't love feeling like it's a noose around my neck - and each time I see such a message, I feel like that's where it'll head, as people don't seem to realise that we do this for fun, and not because we're paid to make them something for nothing.

Wedge has a bright and amazing future but you have to let us make it happen in a way we're comfortable with - and that means not rushing releases. That means we take as long as we feel is necessary to make it work. You can see the progress in the New Revs thread. That should give you some idea of the scale of changes that are underway - commits happen every day or at worst every couple of days, far higher and far more thoroughly than a good number of open source projects manage, in fact.

I'm also annoyed a lot in the fact that people don't seem to look around before asking. Is it really that hard to grasp that it isn't ready yet? Is it really that hard to spend a little time looking around and seeing what we're about? I guess it actually is, given how many people I'm aware of have just come along, posted without reading just because they want cool free stuff, without taking the time to understand what we're about.

Anyway, here endeth the rant. Keep calm and carry on!
5827
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 12:55 PM »
After getting more and more involved in it, I think it's really not worth the effort. We're not doing it on the browser where it would really make a difference. In our case, even if several requests are being sent to package servers, the time apart is still going to be several seconds, so that keep-alive is bordering on the pedantic in terms of saving (the overhead is that we save a TCP connection, at the cost of tying up the destination host's resources longer, and for the number of requests we'll be making, it would be better not to do so at all)


(If a plugin author ever did want to, assuming they cared enough to realise there's a very very slight performance gain to be made for multiple requests to the same server, they'd be using cURL flat out to do it, and using HTTP/1.1 with some of the other gizmos there. But I'd wonder what the hell they were doing to necessitate it anyway...)
5828
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 12:32 PM »
In other news, I can only find one instance where fetch_web_data actually uses the keep-alive facility, and it's one that I think has dubious use in the future - it's used when using the existing package manger, when downloading a package, to grab the file and validate it. But I can't actually see where it's *using* keep-alive. It's not like it's going to attempt to reuse that connection between requests.

Hmm, makes me wonder whether it's needed or not - I guess it probably should be supported, in case a plugin wants it.
5829
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 11:47 AM »
OK, I'll work on this one today then :) And yeah, weget is a better name.
5830
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 11:43 AM »
The whole point of doing it is to avoid ridiculous and complex function calls that have multiple parameters that only apply in certain cases. If I'm keeping it to two lines, I may as well not bother with making it a class.

Consider, which is easier to follow... this is a hypothetical example using arbitrary GET headers.

Code: [Select]
loadSource('Subs-Package');
$code = fetch_web_data($url, '', false, 0, array('Range' => 'bytes=0-1536'));

Code: [Select]
loadSource('Class-WebGet');
$wget = new weweb($url);
$wget->setHeader('Range', 'bytes=0-1536');
$code = $wget->get();

The extra values in fetch_web_data are in order: POST data, whether to use keep-alive and redirection level. I'd assume the same defaults for weweb, though. This is a more extreme example, a typical example would normally only have the function declaration and the get. (If you put everything into the constructor, there's really no benefit to it whatsoever because you're just making it a bastardised function call.)
Posted: October 19th, 2011, 11:35 AM

Hmm, after a quick skim of the docs, I wouldn't be adding range support like that anyway, because cURL has proper support for ranges and expects a proper curl_setopt call for it. Still, I'd just convert that to a setRange() call, so that whether cURL or fsockopen is doing it, it can be done.
5831
Features / Re: Moving options out of Current Theme
« on October 19th, 2011, 11:28 AM »
Quote
I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while.
I see the error log quite heavily, especially at the moment where I'm debugging and have a fairly bad habit of adding debugging logs through trigger_error... but no FOUS issues.
Quote
...info center options...
Yes, recent posts probably should be a general, not a theme, option. If nothing else, a theme which didn't support it before will end up possibly running a modestly expensive query which it didn't have to. The counter-argument is that a theme might have done something very cool and imaginative here but honestly, I'm not seeing what...
Quote
Show statistics on board index:
Given that it's now a single block in the layout I'd have to argue that if they did do something that caused it to break, they're doing it wrong.
Quote
Show latest member on board index
I have yet to fully understand what the point of this actually is. The only reason I don't disable it in my installs is that it doesn't generate any extra load because it's still calculated whether it's shown or not, and it defaults to on. Personally I'd be happy with not only removing the option, but removing this in its entirety.
Quote
Show group key on board index
Hmm, this one is tricky. On the one hand, it feels almost it like it should be a plugin and on the other, do we really want/need another query on the board index by default? That's the reason it is actually off by default, to save a query.

Mind you, it's not like we can't cache that. Thing is, though, if it's left in by default it really needs more options, like being able to control which group(s) are shown and in what order.
Quote
"Show who is viewing"
Well, remember this used to be integrated directly inline in the message index and display templates, and I moved them into the sidebar in the relevant places. Consequently it's far less a theme option than it used to be.
Quote
Show last modification date on modified posts
Yup, I can see it's not really a theme option. On the other hand, if someone makes a theme without it in, there's likely going to be a 'this option doesn't work' bug report come in, though it should be possible to see pretty quickly that it's a theme issue.
Quote
Show view profile button under post: POST settings.
Don't we have a user menu for that sort of thing anyway?
Quote
Show user avatars in message view: POST settings or AVATAR settings.
Avatar settings.
Quote
Show personal text in message view: POST settings.
Hmm. I'd say the post bit is one of the most likely things to be changed in a theme (after the overall style index.template and the board index), and whereas I can't realistically see a theme removing the avatar, I can see them removing the personal text.

I'd actually be inclined to say that it should be on by default and if the admin doesn't want to show it, they'll probably disable it anyway in profile fields.
Quote
Show gender images in message view: POST settings.
Pretty much same as above.
Quote
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Membergroup settings, seeing how it has to be handled in the core logic.
Quote
Enable collapsible additional post options: general, post settings or something...
Post settings.
Quote
My conclusion: theme settings should only *contain settings that related to the theme itself (e.g. something like, "show the info center in the sidebar/main area"), not settings related to features that are built into Wedge* (e.g. personal_text has a field in the members table, so all themes are expected to be able to deal with it.)
My take on it is that if it's something that a theme is *typically likely to modify* then it should be handled in the theme as an option. You'll notice that most of the above fall into the 'not likely to modify' category and thus should be general not theme options, IMNSHO.

And generally, yes, if the core provides it, the theme should either suck it up and deal with it, or if it doesn't want to provide for it, it should be pretty clear that it's the theme making the decision.
Quote
(It's interesting that Opera is telling me 'unobvious' is not a valid word... I always thought it was. A dictionary gives me these antonyms for obvious: ambiguous, indefinite, obscure, unclear, vague. Hmm, that's very close to what we'd use in French -- ambigu, indéfini, obscur, flou/pas clair, vague.)
It isn't a valid word. Neither is inobvious.[1]
Quote
It's inside the info center... Especially now that InfoCenter is its own template, I don't see how/why themes should delete the option. Additionally -- it's up to the theme to decide what to do.
Therein lies the point: if the theme doesn't support it, it should remove the option for it.
Quote
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness...
Sorting by average of RGB values, or converting to HSL and sorting by luminescence? :P Seriously though, I can imagine (and have seen it done many times) where people create groups that aren't alphabetically ordered but have an intrinsic order by precedence. E.g. imagine sm.org. Ordering groups by alphabetic, puts Beta Tester first then Charter Member then Customizer. Presumably you'd want the team first, followed by Charter Member, Friend, Beta Tester in some semblance of order, with the point to prioritise importance.
Quote
What do you think...? As an added bonus, we get to have the options made searchable... This is all because yesterday I wasted 5 minutes trying to enable 'show group key' and the admin search refused to point me to it...
There are so many areas in admin that are not properly covered, it's unreal.
Quote
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...
"Current theme's settings"
Quote
I hope you used a walkthrough for that  It's easier to get below 3 hours that way.
Nope. I didn't exactly hurry, even stopping to listen to the dev commentary in places I didn't remember listening to it before, and still clocked in with half an hour to spare.[2][3]
Quote
Yeah, pretty much... Over 60 times. And the cache would be updated even if 'id_group/additional_groups' isn't updated, which isn't too great IMNSHO.
Eh, didn't realise it was that heavy.
Quote
Sure. Do you want me to get started on it maybe...? Or would you rather do it? It's not exciting work
Nah, I'll do it. I'll probably have to fix stuff. As far as minification goes, I can but it seems like extra work that isn't necessary - getting it down to 280KB was enough of a result for me personally.
Quote
Sure, but I'd rather know why SMF/Wedge is using \n when it could be using br in most places
The main place *I* use it when I do that is for things that will ultimately become emails, since I don't really want to have to think about stripping the br's from it...
Quote
I'd rather not have ';xml' on any URL that is likely to be reused by someone, reposted on a forum, etc. We can just add a special || action == 'feed' anyway
No..... just inside the feed code, add $_GET['xml'] = true :P
 1. However, despite the fact I'm well aware that it isn't a 'real' word in the dictionary sense, does it matter if it conveys the meaning that I'm trying to communciate? It doesn't matter that the word isn't in a dictionary if you and I both understand the same thing from it. Un- is a typical prefix to indication absence or in some cases negation, so un-obvious is a fairly clear, IMHO, meaning of something that has an absence/lack of obviousness, or is simply 'not obvious'. Best thing I learned from David & Leigh Eddings' "The Redemption of Althalus", where one of the characters came out with 'funner', and was appropriately rebuked for using a made-up word, until he pointed out that if you knew what he meant, it didn't matter that it was made up.
 2. I got a couple of things 'wrong' as in slower than I could have done, and the ending always takes much longer than it needs to due to being zapped here, there and everywhere. But even on my first run-through in years, when I first got it on Steam, I still did that in about 3h 15. If I played more carefully, could probably even do it in around 2 hours.
 3. Also note that I've played the LucasArts games pretty heavily over the years and have walkthroughs for most of them in my brain.
5832
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 10:59 AM »
Well, if I add cURL support (by default) to fetch_web_data, I'll be sure to add in the facility to add arbitrary headers which means range support is a step away if anything wants it. The plugin manager will need that if I use GET, and then for the places outside media which use it, it's pretty much a one-liner to deal with.

Debating whether or not to convert fetch_web_data into a class so that setting things like URL, headers etc don't make for a very long function call, though they would make for 2-3 lines of calling instead of the current 1-2 (allowing for inclusion of Subs-Package as it stands right now)
5833
Features / Re: New revs - Public comments
« on October 19th, 2011, 03:17 AM »
Quote
I'm looking at Settings.template.php and only one question comes to mind... Why this? I can understand some themes might wanna add options, but... This makes it very hard to actually find them (they're neither accessible from Profile > Look & Layout, not from the regular admin area... You have to go to Admin > Current Theme, which I don't find very intuitive.)
It's to make it easier for themes to add options, that are under admin control. There's no way for themes to add user options AFAIK without replacing some/all of the profile template.

Admin > Current Theme makes some modicum of sense, but not a lot - though it's a world better than how unobvious theme settings are to find normally.
Quote
Even things like show_group_key... Why would we need to offer to ability to disable it...? To save space?! Why is it a theme option only? It should be in Admin > Membergroups > Settings...

I've been changing show_group_key btw. Now it will also show postgroups, if they have a custom color. Is this okay with everyone? I couldn't think of any strong reason not to do that.
It's a theme option because not all themes provide it. Seriously tempted to move that back out into being a plugin anyway because partly not all themes provide it and partly because so many people want it 'ordered how they want, not just alphabetic', and I think it would be a stretch too far to make core with that in mind. It's not like it's tough to expand any more or anything.
Quote
Which is why I added a default color for the highest post group in Wedge...
Nice. I spent the rest of my evening trying to score the one remaining achievement I had for Monkey Island II on Steam (complete the game in under 3 hours, just finished with 30 mins to spare), so I haven't looked at the commit yet.
Quote
Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
Is there really a lot of places that call updateMemberData?
Quote
It only matters if you're not going to update the file in the future.
I'll update it if it becomes necessary but given how there haven't been updates for a while and it's one of those things that generally 'just works', it should be OK to fix up now.
Quote
Well, we still have a lot of " in the language files, which we used naturally this year AFAIK. So it's pretty much a mixup...
Hmm, we should probably test that. It's likely I'm worrying about nothing but I'd rather that and be proven wrong than to be bitten by it later.
Quote
Oh, there's a bug in the current version btw. It's related to createList() and the creation of the menu... Anyway... Just go to the info center, click one of the membergroups in the group key, and see the errors in the menu. Worked on it for 15 minutes and didn't find anything strange (except for a wetem::load() that can safely go in Groups.php...)
I'll do that in the morning to see what's going on.
Quote
In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
Testing for $_GET['xml'] is good but it doesn't automagically do that for the feeds IIRC. But if we had the feeds set that too (if they don't already), then it's a no-brainer.
5834
Features / Re: New revs - Public comments
« on October 18th, 2011, 09:18 PM »
Quote from Nao on October 18th, 2011, 06:43 PM
Oh, I forgot about post count groups... I never enable colors for these.
We might not but I know sites that do.
Quote
I also managed to catch the place where postgroups are updated so I can clear the cache, but I wouldn't mind some help spotting other areas where regular groups are updated.
Profile area is the main one, but it's not the only one. Group management (Groups.php) is the other main one for assigned groups. Theory says updateMemberData() should be called.
Quote
Also, looked into rev 1118, just a note: there are plenty of multiple spaces (not tabs) in the file, most notably several distinct lines often find themselves on the same line separated by many spaces... Odd!
Class-SFTP's formatting is... special. I thought I'd fixed the worst offenders.
Quote
And the ManagePlugins template -- you committed an empty function, is this as intended?
Yes, that was intended; I am going to populate that function but after fighting with the Class-FileWritable and Subs-Plugins code I was a bit fed up, so committed it as was, raw and unfinished.
Quote
Oh, and before I forget... There are dozens (hundreds?) of " in the language files. Shouldn't we remove them...? I don't think they serve a point these days?
Be very careful with those. There are cases where mismatching goes on - when I created the Birthdays plugin out of the email templates, I made use of a little known quirk of SMF's language editor.

Specifically, you can actually do this in the language files and expect it to work properly in the language editor for both loading and saving:
Code: [Select]
$txt['string'] = 'line 1' . "\n\n" . 'line 2';

I don't know how ManageLanguages does that, so without testing to understand whether there are interesting side effects or not.
Quote
I think it's better (for now) to harmonize the queries, so I started removing online_color when not required by something else...
Well, I'm a bit lost in the amount of changes I made today so I'll just commit what I have now and you can look into it.
Harmonisation is good :) And yeah, I understand exactly what you mean where lots of changes happen, I had points during the early plugin manager dev where it was doing that to me.
Quote
I haven't been moving a lot of code honestly, only recently to straighten it up but I don't see myself adding to that function on a daily basis anyway..... :^^;:
I'm just thinking of the case of having to come back to it in 6 months time.
Quote
I just took out what I didn't care about, and added the stuff I wanted to have (avatars and last login)...
I like it.
Quote
Isn't there a 'super memberlist' mod around? The one where members are listed in boxes -avatar, then some info below... I'm not a big fan of the way it's shown, but it's probably a way to do it that's logical to most people.
Yes, that's the one.
Quote
Hmm... I see. Well, now that the code is committed (I wanted to post this before, but I had a browser crash -- thank you for drafts! -- and committed while waiting for my tab list to reload), you can look into it and test the XML maybe...?
Well, I'll take a look but we might as well not run that particular process if we're outputting XML, I can't see any case in XML (valid or otherwise) where we'd want the colour to be added.
Quote
And please generally tell me what you think about the overall building of the feature ;)
I like the idea but will look at the code later on.
Quote
Then all is good... Just promise me that wesqlQuery will be in Wedge before we release an alpha :P
Of course, I'm going to need it before long ;)
5835
Which hooks?