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
1066
Off-topic / Neil Gaiman's 8 Rules of Writing
« on April 3rd, 2013, 12:28 AM »
Some of these seem to apply to software writing too.
http://www.brainpickings.org/index.php/2012/09/28/neil-gaiman-8-rules-of-writing/
http://www.brainpickings.org/index.php/2012/09/28/neil-gaiman-8-rules-of-writing/
1067
Off-topic / Re: Doctor Who
« on April 2nd, 2013, 11:34 PM »
There is only so much you can do with 1970s monsters.
As far as the other... this is neither surprising nor entirely desirable.
(click to show/hide)
As far as the other... this is neither surprising nor entirely desirable.
More gurning, more running, more "I'm sorry, I'm so sorry"
1068
Off-topic / Re: Doctor Who
« on April 2nd, 2013, 06:55 PM »
Eh, Moffat has said about bringing back old monsters for the newer series in different forms - like we've seen the Silurians. The notion of bringing back the Great Intelligence and now potentially another old monster should not really be a surprise. Provided it's handled properly.
1069
Features / Re: Crazy idea: fonts as a preference
« on April 2nd, 2013, 12:54 AM »
Now do it when you start crossing tabs and windows too.
1070
Features / Re: Crazy idea: fonts as a preference
« on April 2nd, 2013, 12:48 AM »
Not always it doesn't.
1071
Features / Re: Miscellaneous/WIP screenshots
« on April 1st, 2013, 04:47 AM »
Wait until you see the third screen ;)
1072
Features / Re: Miscellaneous/WIP screenshots
« on April 1st, 2013, 04:33 AM »1073
Bug reports / Re: Rewriting pretty URLs with respect to the moved topic notice
« on April 1st, 2013, 03:00 AM »
Because what you're doing here is not what I'm doing on localhost.
Also, no, it's not just iurl tags. And yes it is the rewriter process.
I turned off all pretty URLs, did a redirect, worked as expected. Change the post to have:
Code: [Select]
Still worked as expected.
Then I turned pretty URLs on again, but *only* for profiles, and got the same behaviour.
Enabling it for topics is even more fucked up, however. Since for some reason, my given board has a 'url' of 'dummy678704' (no forwardslash) so everything breaks entirely. But even if I have the slash, it's all fecked because I'm not running it on a given domain, but in a folder, i.e. localhost/wedge/
Which says to me that rewrite URLs are currently broken if they only work at a top level folder. I seem to recall mentioning this before too. More than once, if I'm not mistaken. This is why I don't use PURLs, because it's *never* worked for me.
Also, no, it's not just iurl tags. And yes it is the rewriter process.
I turned off all pretty URLs, did a redirect, worked as expected. Change the post to have:
[url]http://localhost/wedge/index.php?topic=37.0[/url]Still worked as expected.
Then I turned pretty URLs on again, but *only* for profiles, and got the same behaviour.
Enabling it for topics is even more fucked up, however. Since for some reason, my given board has a 'url' of 'dummy678704' (no forwardslash) so everything breaks entirely. But even if I have the slash, it's all fecked because I'm not running it on a given domain, but in a folder, i.e. localhost/wedge/
Which says to me that rewrite URLs are currently broken if they only work at a top level folder. I seem to recall mentioning this before too. More than once, if I'm not mistaken. This is why I don't use PURLs, because it's *never* worked for me.
1074
Features / Re: New revs - Public comments
« on March 31st, 2013, 08:59 PM »
I'm using GIMP 2.6.12 if that's any help.Quote That should be it. As I said, I was wrong. It's the old code that wasn't removed properly, but at first glance looked thoroughly broken because I didn't see the extra line above the removed code that solved the problem, I just saw 'chunk of removed code that sets up variables used later on'.
I've spent a lot of time getting very frustrated lately with a lot of people and a lot of things because I feel like I'm shouting up from inside a well and no-one but me is listening to what I'm saying.
Which is why I'm now working on a new feature and until the feature is done, I'm just going to avoid forums in general, because it's hard to concentrate when I'm in this much of a bad mood.
So far, so good...
I've spent a lot of time getting very frustrated lately with a lot of people and a lot of things because I feel like I'm shouting up from inside a well and no-one but me is listening to what I'm saying.
Which is why I'm now working on a new feature and until the feature is done, I'm just going to avoid forums in general, because it's hard to concentrate when I'm in this much of a bad mood.
1075
Features / Re: Miscellaneous/WIP screenshots
« on March 31st, 2013, 08:39 PM »
This afternoon's work, so far. That and the long text file documenting how all this stuff needs to work.
1076
Off-topic / Re: GetSimple CMS
« on March 31st, 2013, 08:31 PM »
XML isn't inherently a bad thing if you do it right. Hell, any SMF page is an XML document in its own right. You can also take XML documents and style them with XSLT files should you want to do so.
But storing everything as files in what would *have* to be world-writable on shared servers >_<
But storing everything as files in what would *have* to be world-writable on shared servers >_<
1077
The Pub / Re: The Cookie Law (in the UK at least)
« on March 31st, 2013, 08:28 PM »Is disabling session handling for guests a major change?
1078
The Pub / Re: The Cookie Law (in the UK at least)
« on March 31st, 2013, 06:53 PM »
No... You're only seeing part of the picture and assuming that's how it works the rest of the time :/
PHPSESSID - for logged in members is set up by PHP. We have no control of that at the Wedge level, not for the want of trying, though.
PHPSESSID - for guests is set up all the time, again by PHP... but it is only injected into links if cookies were not found, which should only be the first page load. PHP itself doesn't do the injection part (because we tell it not to) but we manually handle the process at this time, so instead of it being every page without fail, it is only when cookies are not present. Links will be without PHPSESSID if you view more than one page as a guest and cookies are enabled.
There are two parts to my suggestion:
1, disable the injection. This would give us a minor performance boost, a minor bandwidth saving but makes stats less accurate.
2. disable session handling *entirely* for guests. This would give us a major performance boot, no additional bandwidth saving over the first one, and the number of guests becomes unavailable. But no number is probably more meaningful than a very-inaccurate number.
PHPSESSID - for logged in members is set up by PHP. We have no control of that at the Wedge level, not for the want of trying, though.
PHPSESSID - for guests is set up all the time, again by PHP... but it is only injected into links if cookies were not found, which should only be the first page load. PHP itself doesn't do the injection part (because we tell it not to) but we manually handle the process at this time, so instead of it being every page without fail, it is only when cookies are not present. Links will be without PHPSESSID if you view more than one page as a guest and cookies are enabled.
There are two parts to my suggestion:
1, disable the injection. This would give us a minor performance boost, a minor bandwidth saving but makes stats less accurate.
2. disable session handling *entirely* for guests. This would give us a major performance boot, no additional bandwidth saving over the first one, and the number of guests becomes unavailable. But no number is probably more meaningful than a very-inaccurate number.
1079
The Pub / Re: The Cookie Law (in the UK at least)
« on March 31st, 2013, 06:43 PM »
"is PHPSESSID now only used for guests"
When the point of the suggestion was to NOT use it at all for guests.
When the point of the suggestion was to NOT use it at all for guests.
1080
The Pub / Re: The Cookie Law (in the UK at least)
« on March 31st, 2013, 06:39 PM »
We made no changes whatsoever.
PHPSESSID gets created by PHP. We have no control over that.
But the point of what I was suggesting was the complete opposite of what you're asking anyway.
PHPSESSID gets created by PHP. We have no control over that.
But the point of what I was suggesting was the complete opposite of what you're asking anyway.