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
5791
Off-topic / Re: Post count fever
« on October 21st, 2011, 12:26 AM »
Sleep well :)
Yeah, the plugins stuff was enormous, and I guess Class-WebGet wasn't a few lines. But I keep finding myself doing a bunch of little commits like tonight's - though I probably should bench the difference in bbc parsing with that change, it cuts down string slicing once per tag evaluated (or more accurately, once per bbc opening character)
Yeah, the plugins stuff was enormous, and I guess Class-WebGet wasn't a few lines. But I keep finding myself doing a bunch of little commits like tonight's - though I probably should bench the difference in bbc parsing with that change, it cuts down string slicing once per tag evaluated (or more accurately, once per bbc opening character)
5792
Features / Re: Storing the modified-post user id
« on October 21st, 2011, 12:24 AM »Oh yes, I forgot than an empty varchar takes no space (or so) in the DB, so it'd only be used when deleting the account...
The bigger problem I have is the amount of rewriting that will occur on deleting an account, because it will force every row where that user has impacted to be rewritten - which could cause a lot of data change.
What I'd probably do in that case is make it so all account deletions have to be approved by the admin, rather than making it optional, because of the performance impact that's attached (the account's frozen out to the user anyhow at that point unless they want to undelete it), and for spammers it's mostly irrelevant because in a lot of cases the post will be removed as well...
id_modified_by or something should have a default of 0 or maybe null, I don't know which is likely to take the least space...
5793
Off-topic / Re: Post count fever
« on October 21st, 2011, 12:16 AM »
Maybe - but a lot of my commits have been small tweaks this month rather than big hulking commits... :whistle:
5794
Features / Re: Storing the modified-post user id
« on October 21st, 2011, 12:12 AM »
The poster's name is still stored too, remember. We could store just the ids, and if the relevant account gets deleted, backfill those rows with the relevant names.
I guess, though I'm not sure, that the reason it's done that way is to allow guests to edit their post after the event (based on session and/or IP address, but not sure off the top of my head)
I guess, though I'm not sure, that the reason it's done that way is to allow guests to edit their post after the event (based on session and/or IP address, but not sure off the top of my head)
5795
Features / Re: New revs
« on October 21st, 2011, 12:10 AM »
(1 modified, again missed the size, sorry, but it's half a dozen lines again)
Revision: 1128
Author: arantor
Date: 22:42:02, 20 October 2011
Message:
! Under some circumstances two calls could be put into the embedder code which had the interesting side effect of mulching certain operations. Not calling it twice seems to rectify all issues observed while testing previous revision, without introducing any other issues into link parsing. (Post2.php)
----
Modified : /trunk/Sources/Post2.php
@ After more playing about I can still get it to break, though it is less broken than before. Specifically now, if a link is posted it will be handled correctly normally in both full and quick edit, but if the post is subsequently modified, it will be wrapped in url tags which are not handled correctly. It's really *really* irritating, seeing how there is a url tag with = parameter (i.e. [url=http://wedge.org]wedge[/url]) which has worked the entire time, and not been mulched with the above one bit. Also Aeva embedding works just fine even with this patch, both quick and full edit.
IOW: quick edit is always correct, full edit is not, yet they seem to use the same code path! The bbc parser itself seems to be handling what's given to it correctly, but that full edit is breaking the link handling.
Sure, we can go through every change in either Subs-BBC or Class-Editor back to r1 (including when they weren't originally in those files!) but I'd rather concentrate on finding where it does it and not making it do it again.
More specifically I want to know what the difference in code paths is between quick and full edit because quick edit seems to be consistently correct, and I don't know why. I thought the difference was the chunk I removed in r1128 (given its comment, it seemed likely) but it's more than that.
Revision: 1128
Author: arantor
Date: 22:42:02, 20 October 2011
Message:
! Under some circumstances two calls could be put into the embedder code which had the interesting side effect of mulching certain operations. Not calling it twice seems to rectify all issues observed while testing previous revision, without introducing any other issues into link parsing. (Post2.php)
----
Modified : /trunk/Sources/Post2.php
@ After more playing about I can still get it to break, though it is less broken than before. Specifically now, if a link is posted it will be handled correctly normally in both full and quick edit, but if the post is subsequently modified, it will be wrapped in url tags which are not handled correctly. It's really *really* irritating, seeing how there is a url tag with = parameter (i.e. [url=http://wedge.org]wedge[/url]) which has worked the entire time, and not been mulched with the above one bit. Also Aeva embedding works just fine even with this patch, both quick and full edit.
IOW: quick edit is always correct, full edit is not, yet they seem to use the same code path! The bbc parser itself seems to be handling what's given to it correctly, but that full edit is breaking the link handling.
Sure, we can go through every change in either Subs-BBC or Class-Editor back to r1 (including when they weren't originally in those files!) but I'd rather concentrate on finding where it does it and not making it do it again.
More specifically I want to know what the difference in code paths is between quick and full edit because quick edit seems to be consistently correct, and I don't know why. I thought the difference was the chunk I removed in r1128 (given its comment, it seemed likely) but it's more than that.
5796
Features / Storing the modified-post user id
« on October 20th, 2011, 11:58 PM »
For a reason I've never understood, SMF never stored the user id of a modified post. It stores the name and the time - the bare minimum, I guess - but not the user id.
I figure we should store the user id and actually add that to the list of ids we query during Display startup, so that we can actually display not only the current name (as opposed to whatever name they used at the time) but we can link to it.
It also allows for some other interesting consequences, like if the last person who edited your post was a moderator, it could relatively easily prevent non-moderators then editing that post.
There is a storage cost (~3 bytes per message) and a slight performance hit though I'd argue that fairly often the editor on a post is someone who has already posted in the topic (recently) anyway, e.g. the author, or a moderator...
Thoughts?
I figure we should store the user id and actually add that to the list of ids we query during Display startup, so that we can actually display not only the current name (as opposed to whatever name they used at the time) but we can link to it.
It also allows for some other interesting consequences, like if the last person who edited your post was a moderator, it could relatively easily prevent non-moderators then editing that post.
There is a storage cost (~3 bytes per message) and a slight performance hit though I'd argue that fairly often the editor on a post is someone who has already posted in the topic (recently) anyway, e.g. the author, or a moderator...
Thoughts?
5797
Features / Re: New revs
« on October 20th, 2011, 11:31 PM »
(1 file, missed the size but it's about 6 lines in total affected!)
Revision: 1126
Author: arantor
Date: 22:25:40, 20 October 2011
Message:
! Replaced browser specific styling hacks for splitting words with soft-hyphen entity. It really needed to be done! (Subs-BBC.php)
! Slight performance tweak in the BBC parser, avoiding extra string slicing once per tag. (Subs-BBC.php)
----
Modified : /trunk/Sources/Subs-BBC.php
Also note there is currently a fairly large bug in the preparser/parser where autolinked URLs are thoroughly mashed up.
Typing this in a post in a post, expecting it to be autolinked:
Code: [Select]
Results in:
Code: [Select] being generated in the physical post which is rendered as:
Code: [Select]
It is definitely a preparsing problem because it's stored like that. That said, something's distinctly odd about how it works because if I have the link written out twice on two separate lines (link / blank line / link), and it's done through the quick modify, neither are linked, but if I manually put URL bbcode around the second link, both are linked.
I think we've thoroughly broken the preparser and parser somewhere (but the above happens even with the r1125 version of Subs-BBC.php)
:edit: So, I'm waiting for r1127 to be posted here, committed what I thought was a fix in r1128 but it seems that the parser is still broken, more details when I post r1128.
Revision: 1126
Author: arantor
Date: 22:25:40, 20 October 2011
Message:
! Replaced browser specific styling hacks for splitting words with soft-hyphen entity. It really needed to be done! (Subs-BBC.php)
! Slight performance tweak in the BBC parser, avoiding extra string slicing once per tag. (Subs-BBC.php)
----
Modified : /trunk/Sources/Subs-BBC.php
Also note there is currently a fairly large bug in the preparser/parser where autolinked URLs are thoroughly mashed up.
Typing this in a post in a post, expecting it to be autolinked:
http://wedge.org/Results in:
[url]http://[url]http://wedge.org/[/url][/url]http://[url]http://wedge.org/[/url]It is definitely a preparsing problem because it's stored like that. That said, something's distinctly odd about how it works because if I have the link written out twice on two separate lines (link / blank line / link), and it's done through the quick modify, neither are linked, but if I manually put URL bbcode around the second link, both are linked.
I think we've thoroughly broken the preparser and parser somewhere (but the above happens even with the r1125 version of Subs-BBC.php)
:edit: So, I'm waiting for r1127 to be posted here, committed what I thought was a fix in r1128 but it seems that the parser is still broken, more details when I post r1128.
5798
Off-topic / Re: Adding Value to the project
« on October 20th, 2011, 11:06 PM »5799
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 20th, 2011, 11:06 PM »
call_hook('actions') ? It's called normally.
5800
Plugins / Re: Plugin servers / getting plugins to a system
« on October 20th, 2011, 11:01 PM »
Hmm, yeah, which is impractical and a PITA (and what was there only works if allow_url_fopen is set)
In which case, the only solution is ugly and rather costly in memory terms (but I can put a test to try and prevent it dying due to being out of memory), which is to call imagecreatefromstring - since we have the string handy - and build an image out of it for imagesx and imagesy. That seems familiar, SMF may even have done it but with all the code and staring at hex dumps of files in the middle I may well have forgotten about it :/
I didn't even realise until yesterday that fetch_web_data not only supports FTP but also arbitrary HTTP POST content. (Of course Class-WebGet *also* supports those things, which I suspect is not so well realised in the first case)
Getting back to the original topic, I realised a problem that I don't know how to deal with: authentication. I originally figured I'd send the username and password to the server as part of the request, but I realised that if the destination wasn't open to guests, it'd never reach its destination at all. So either I have to put in the requirement that a destination forum/plugin server be open to guests (since I'm looking at making it a plugin itself), or have it do an authentication and login as the first request, send back the cookie (and have that stored somewhere temporarily), then resend the actual request for updates complete with cookie.
Hmmm. It seems so much easier to make the plugin server be a separate file that can authenticate on its own without having to create a user session etc. Maybe I should do that (though that has its own interesting side effects, and I'd rather make it an action)
In which case, the only solution is ugly and rather costly in memory terms (but I can put a test to try and prevent it dying due to being out of memory), which is to call imagecreatefromstring - since we have the string handy - and build an image out of it for imagesx and imagesy. That seems familiar, SMF may even have done it but with all the code and staring at hex dumps of files in the middle I may well have forgotten about it :/
I didn't even realise until yesterday that fetch_web_data not only supports FTP but also arbitrary HTTP POST content. (Of course Class-WebGet *also* supports those things, which I suspect is not so well realised in the first case)
Getting back to the original topic, I realised a problem that I don't know how to deal with: authentication. I originally figured I'd send the username and password to the server as part of the request, but I realised that if the destination wasn't open to guests, it'd never reach its destination at all. So either I have to put in the requirement that a destination forum/plugin server be open to guests (since I'm looking at making it a plugin itself), or have it do an authentication and login as the first request, send back the cookie (and have that stored somewhere temporarily), then resend the actual request for updates complete with cookie.
Hmmm. It seems so much easier to make the plugin server be a separate file that can authenticate on its own without having to create a user session etc. Maybe I should do that (though that has its own interesting side effects, and I'd rather make it an action)
5801
Plugins / Re: Plugin servers / getting plugins to a system
« on October 20th, 2011, 10:08 PM »
I know there have been out of memory errors from its use, so I can only presume it doesn't.
5802
Off-topic / Re: I'm not quite sure how I'm supposed to deal with this
« on October 20th, 2011, 05:02 PM »
B-b-b-but it's an album that looks like it's hilarious when you're either drunk or stoned, or it's late and you're barely conscious anyway! :lol:
5803
Off-topic / Hmm, worth spending a few minutes thinking about
« on October 20th, 2011, 04:47 PM »
http://www.theregister.co.uk/2011/10/20/are_ip_addresses_personal_data/
That's a very, very good question. You can probably figure out what my answer to that question is, from this blog post.[1]
Also rather interesting is to read the comments, in particular at the countries that do consider it to be personal data.
That's a very, very good question. You can probably figure out what my answer to that question is, from this blog post.[1]
Also rather interesting is to read the comments, in particular at the countries that do consider it to be personal data.
| 1. | If not, the answer is complicated. Yes, it can help identify an individual, but it's not that rock solid, and that there are quite a few ways to compromise it, so that it should be considered a reasonable piece of information, not a concrete 'this definitely identifies a unique user', because it doesn't. The result is that I'm downplaying the use of IP addresses for account-level items. |
5804
Off-topic / Re: I'm not quite sure how I'm supposed to deal with this
« on October 20th, 2011, 04:42 PM »
Yeah, I think that might be the answer. Is it wrong that I'm half-seriously considering buying the whole album just for the full effect?
5805