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.
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.
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 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 Sure thing. Once it's tested, anyway ;)
AFAIK, the only point is to allow for more simultaneous downloads off a single server by reusing earlier connections
Oh, and can you look into reusing weget for AeMe as well...?
5823
The Pub / Re: When can I download Wedge? / Where can I download Wedge?
« on October 19th, 2011, 03:28 PM »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..
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..
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.
Well, once again, sorry that I took some of your time for this. Wasnt really my intention..
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.
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 :)
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!
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...)
(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.
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]
Code: [Select]
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.)
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.
Consider, which is easier to follow... this is a hypothetical example using arbitrary GET headers.
loadSource('Subs-Package');
$code = fetch_web_data($url, '', false, 0, array('Range' => 'bytes=0-1536'));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 »I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while.
...info center options...
Show statistics on board index:
Show latest member on board index
Show group key on board index
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.
"Show who is viewing"
Show last modification date on modified posts
Show view profile button under post: POST settings.
Show user avatars in message view: POST settings or AVATAR settings.
Show personal text in message view: POST settings.
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.
Show gender images in message view: POST settings.
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Enable collapsible additional post options: general, post settings or something...
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.)
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.
(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'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.
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness...
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...
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...
I hope you used a walkthrough for that It's easier to get below 3 hours that way.
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.
Sure. Do you want me to get started on it maybe...? Or would you rather do it? It's not exciting work
Sure, but I'd rather know why SMF/Wedge is using \n when it could be using br in most places
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
| 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)
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 »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.)
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.
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.
Which is why I added a default color for the highest post group in Wedge...
Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
It only matters if you're not going to update the file in the future.
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...
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...)
In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
5834
Features / Re: New revs - Public comments
« on October 18th, 2011, 09:18 PM »Oh, I forgot about post count groups... I never enable colors for these.
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.
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!
And the ManagePlugins template -- you committed an empty function, is this as intended?
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?
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:
$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.
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.
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 just took out what I didn't care about, and added the stuff I wanted to have (avatars and last login)...
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.
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...?
And please generally tell me what you think about the overall building of the feature ;)
Then all is good... Just promise me that wesqlQuery will be in Wedge before we release an alpha :P
5835
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 18th, 2011, 05:24 PM »
Which hooks?