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
601
Archived fixes / Re: Multiple Same-Name Selection Box When Notifying
« on May 26th, 2013, 04:31 PM »
Nope. This is why the entire licensing situation - generally - is a WTF.
SMF is BSD. Under that logic, any changes we make would also be BSD... but that's not how it works. We are required to keep the copyright intact, and otherwise follow the terms of the BSD... but the changes we make to it are ours and not BSD.
They are our copyright, and copyright law prevails in absence of a licence declaring otherwise - which is why a licence is *so* important, it's the only thing that gives you any rights to anything.
Technically, when Wedge releases, it will be 'SMF is BSD, and it's still BSD, but all the other stuff on top is under <this other licence> and the total package is released under <this other licence>'. It's a horrible murky mess to contend with.
SMF is BSD. Under that logic, any changes we make would also be BSD... but that's not how it works. We are required to keep the copyright intact, and otherwise follow the terms of the BSD... but the changes we make to it are ours and not BSD.
They are our copyright, and copyright law prevails in absence of a licence declaring otherwise - which is why a licence is *so* important, it's the only thing that gives you any rights to anything.
Technically, when Wedge releases, it will be 'SMF is BSD, and it's still BSD, but all the other stuff on top is under <this other licence> and the total package is released under <this other licence>'. It's a horrible murky mess to contend with.
602
Archived fixes / Re: Multiple Same-Name Selection Box When Notifying
« on May 26th, 2013, 04:02 PM »
It's a valid one :) MPL fits all of that as I understand it.
That reminds me, I need to talk to the one guy about that...
That reminds me, I need to talk to the one guy about that...
603
Features / Re: Silly menu experiment...
« on May 26th, 2013, 03:49 PM »
Oh, I like the idea a lot. I do note, though, that I'm still thinking about a menu editor which seems to me like it would make this more important if users do insane things like put lots of items at top level.
604
Features / Re: Silly menu experiment...
« on May 26th, 2013, 03:39 PM »
Or for that matter, login/register under other circumstances ;)
605
Archived fixes / Re: Multiple Same-Name Selection Box When Notifying
« on May 26th, 2013, 03:36 PM »
Just to add, there are a number of licensing issues at present to be dealt, including GPL code currently in the repository that we need to obtain suitable licenses for, or that we replace entirely.
There is one thing I want to say though, and this is where the open source issue kicks in.
It's all very well and good having great ideas and executing them well. But the spirit of open source is sharing so that everyone benefits. SMF, under protest, shared their code in a way that allows us to do what we did. Us going MPL (or some other licence) would explicitly allow the code to be shared with other people in a way that lets them build upon it and even share details of implementation with others. I'm cool with that because in the end everyone still benefits, but it does raise the question of how protective we should/must be over it.
One final thing: BSD is not toxic. It is the opposite of toxic in many respects. GPL's problem is not in what it does, but what it forces others to do, in that if a library is GPL and bound in the conventional sense (scripted or otherwise), the entire thing must be GPL. The only way around it is if there is total separation between the parent and child routines where the child is GPL and there is separation, e.g. process fork, or query across a standard interface. BSD on the other hand is not toxic because it doesn't force any of these things, but it doesn't leave much protection for the author either.
I must say I do find it slightly weird that BSD is what allowed us to do what we did and yet we're criticising it for not doing what we want.
There is one thing I want to say though, and this is where the open source issue kicks in.
It's all very well and good having great ideas and executing them well. But the spirit of open source is sharing so that everyone benefits. SMF, under protest, shared their code in a way that allows us to do what we did. Us going MPL (or some other licence) would explicitly allow the code to be shared with other people in a way that lets them build upon it and even share details of implementation with others. I'm cool with that because in the end everyone still benefits, but it does raise the question of how protective we should/must be over it.
One final thing: BSD is not toxic. It is the opposite of toxic in many respects. GPL's problem is not in what it does, but what it forces others to do, in that if a library is GPL and bound in the conventional sense (scripted or otherwise), the entire thing must be GPL. The only way around it is if there is total separation between the parent and child routines where the child is GPL and there is separation, e.g. process fork, or query across a standard interface. BSD on the other hand is not toxic because it doesn't force any of these things, but it doesn't leave much protection for the author either.
I must say I do find it slightly weird that BSD is what allowed us to do what we did and yet we're criticising it for not doing what we want.
606
Off-topic / Re: json_decode and arrays
« on May 25th, 2013, 03:03 PM »
Um... you do foreach track_data as data, then foreach (data->track as track)...
607
Off-topic / Re: json_decode and arrays
« on May 24th, 2013, 05:11 PM »
First glance says that you need to check !empty($data) then foreach ($data->track as $track) then you can iterate over $track to get artist and whatnot.
Possibly you might find it easier to wade through if you pulled it back from json_decode as an associative array rather than an object.
Possibly you might find it easier to wade through if you pulled it back from json_decode as an associative array rather than an object.
608
Off-topic / Re: Automagically De-Nesting Quotes
« on May 23rd, 2013, 11:25 PM »
Breaking a quote up... press quote, place cursor where you want to break the quote, press shift+Enter, it's just magic. ;)
609
Features / Re: File cache backend
« on May 23rd, 2013, 08:33 PM »
Really? Even native functions?
And, really, I'm not particularly interested in json_encode vs serialize, because unless it's vastly out of whack, it's irrelevant - it's write once read many. The debate is json_decode vs unserialize where it really matters.
And, really, I'm not particularly interested in json_encode vs serialize, because unless it's vastly out of whack, it's irrelevant - it's write once read many. The debate is json_decode vs unserialize where it really matters.
* Arantor might try and benchmark that later.
610
Off-topic / Re: Automagically De-Nesting Quotes
« on May 23rd, 2013, 08:23 PM »
While I certainly won't knock anyone for having opinions that conflict, opinions that can be backed up with a justification/support argument are much more valuable. Knowing *why* someone holds the opinion they do can be important.
So, de-nesting does have less readability for some people, and the reason is some scope and context - which can be important in complex debates - can be lost.
For others, I can see there might be an argument that having the extra content does make it hard to focus on what's important and what points need to be refuted. But it seems to me that it swings both ways and is probably down to the user's preference.
So... with that in mind, if a user doesn't want nested quotes, they won't see nested quotes from others and if they quote a post, it should strip the nesting when the quote is generated.
Seems to me that it will solve both sets of concerns.
Regarding multi-quote, I agree that it might be useful to have so I might consider trying to get that working as a plugin.
So, de-nesting does have less readability for some people, and the reason is some scope and context - which can be important in complex debates - can be lost.
For others, I can see there might be an argument that having the extra content does make it hard to focus on what's important and what points need to be refuted. But it seems to me that it swings both ways and is probably down to the user's preference.
So... with that in mind, if a user doesn't want nested quotes, they won't see nested quotes from others and if they quote a post, it should strip the nesting when the quote is generated.
Seems to me that it will solve both sets of concerns.
Regarding multi-quote, I agree that it might be useful to have so I might consider trying to get that working as a plugin.
611
Off-topic / Re: Automagically De-Nesting Quotes
« on May 23rd, 2013, 08:00 PM »
If the strip-nested-quotes option is on, it should be stripped at quote time anyway.
Part of the problem is that while I can see where you're coming from, the average user is too lazy to do that.
Part of the problem is that while I can see where you're coming from, the average user is too lazy to do that.
612
Features / Re: Miscellaneous/WIP screenshots
« on May 23rd, 2013, 05:23 PM »
Well, this would allow you to announce it, discuss it then implement it.
The PM part isn't exactly advertised. It just says:Quote orQuote It doesn't tell the user that PMs are an option, but it is left open in case people do want to discuss changes.
The PM part isn't exactly advertised. It just says:
The terms of the agreement have changed since you last agreed to it. In order to continue using this site, you will need to agree to the new terms.
The terms of the agreement have changed since you last agreed to it. You may continue to browse this site but in order to post messages you will need to agree to the new terms.
613
Features / Re: Miscellaneous/WIP screenshots
« on May 23rd, 2013, 05:02 PM »
Not without a much larger change that I don't really want to get into.
The PM aspect is purely so people can ask questions about the new agreement without actually agreeing to it. I doubt it will even be an issue most of the time in reality.
The PM aspect is purely so people can ask questions about the new agreement without actually agreeing to it. I doubt it will even be an issue most of the time in reality.
614
Features / File cache backend
« on May 23rd, 2013, 04:27 PM »
Just a slightly crazy thought. The file cache serializes content and unserializes it later on.
I wonder if it is safe and better performing to json_encode it instead. Only if native json_encode is available, of course. I did a test a while ago and for the data set I had (large arrays, of arrays of numbers), unserialize was significantly slower than json_decode for my data.
We don't serialize resources or object instances in the base software (there is no reason for us to do so), so from my perspective I see no real reason why we can't do that. If native functions are not available, then we use serialize as normal.
Thoughts?
I wonder if it is safe and better performing to json_encode it instead. Only if native json_encode is available, of course. I did a test a while ago and for the data set I had (large arrays, of arrays of numbers), unserialize was significantly slower than json_decode for my data.
We don't serialize resources or object instances in the base software (there is no reason for us to do so), so from my perspective I see no real reason why we can't do that. If native functions are not available, then we use serialize as normal.
Thoughts?
615
Features / Re: New revs
« on May 23rd, 2013, 04:13 PM »
(11 modified, 13KB)
Revision: 2131
Author: arantor
Date: 23 May 2013 15:11:28
Message:
! Indefinitely long infractions lasted very long indeed... right up until the next page load. (ManageInfractions.php)
! The user shouldn't be told they are post/PM banned if only one of those things is true. (Security.php, Subs-Template.php, index.english.php)
! Admins can now get people to re-agree to the reg agreement. There's also a few related changes that are needed to make this stuff work, since we don't want to quietly remove certain types of warning status when we shouldn't. At least, it seems to work for me... (CoppaForm.php, ManageRegistration.php, Profile-Actions.php, Reminder.php, Subs-Login.php, Register.template.php, Admin language file)
----
Modified : /trunk/Sources/CoppaForm.php
Modified : /trunk/Sources/ManageInfractions.php
Modified : /trunk/Sources/ManageRegistration.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/Reminder.php
Modified : /trunk/Sources/Security.php
Modified : /trunk/Sources/Subs-Login.php
Modified : /trunk/Sources/Subs-Template.php
Modified : /trunk/Themes/default/Register.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/index.english.php
Revision: 2131
Author: arantor
Date: 23 May 2013 15:11:28
Message:
! Indefinitely long infractions lasted very long indeed... right up until the next page load. (ManageInfractions.php)
! The user shouldn't be told they are post/PM banned if only one of those things is true. (Security.php, Subs-Template.php, index.english.php)
! Admins can now get people to re-agree to the reg agreement. There's also a few related changes that are needed to make this stuff work, since we don't want to quietly remove certain types of warning status when we shouldn't. At least, it seems to work for me... (CoppaForm.php, ManageRegistration.php, Profile-Actions.php, Reminder.php, Subs-Login.php, Register.template.php, Admin language file)
----
Modified : /trunk/Sources/CoppaForm.php
Modified : /trunk/Sources/ManageInfractions.php
Modified : /trunk/Sources/ManageRegistration.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/Reminder.php
Modified : /trunk/Sources/Security.php
Modified : /trunk/Sources/Subs-Login.php
Modified : /trunk/Sources/Subs-Template.php
Modified : /trunk/Themes/default/Register.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/index.english.php