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
5971
Off-topic / Re: WIFI Kill
« on October 11th, 2011, 01:14 AM »
I don't see why it wouldn't be. Fairly sure Python has TCP port level bindings available even in Windows.
5972
The Pub / Re: Spell checker
« on October 11th, 2011, 12:20 AM »
Quote
the "new" preferred one or the old one?
It's not exactly a choice. pspell won't be available properly in 5.3 and enchant isn't available conveniently in 5.2 (though it *can* be available). It's not that hard to support both though if you know what you're doing. I say this with the full knowledge of having read up on enchant's API...


That said, I suspect no-one here but me actually knows how tightly bound the spellchecker is into SMF. It's not just in the post page.[1]
 1. It's available in the post/quick reply pages, the profile page for spell checking your signature and it's used in the search pages to identify potentially mis-spelled words. This is distinctly non trivial to cleanly integrate.
5973
Features / Re: Birthday, calendar, plugin, core
« on October 11th, 2011, 12:11 AM »
Bump in the hopes of a few more votes.
5974
The Pub / Re: Spell checker
« on October 10th, 2011, 11:51 PM »
There is a random side benefit that I suspect no-one but me would pick up on.

If the spell checker is removed from core, it means that it becomes easier to write xx-locale language packs, e.g. Pirate :D
5975
Features / Re: Template skeleton!
« on October 10th, 2011, 11:33 PM »
Quote from Nao on October 10th, 2011, 11:32 PM
Hmm. And if we only created dummy topic Ids each time a comment is posted on a profile or album or item?
we could associate these dummy Ids with the real element Id in a new table... Dunno.
Which is juggling ids, which is more work, requires transactions to achieve reliably, and complicates matters.
5976
Off-topic / Re: WIFI Kill
« on October 10th, 2011, 11:29 PM »
My PC is not wifi enabled, therefore I can't test it.

I suppose I could try writing it for my Mac though...
5977
Features / Re: Template skeleton!
« on October 10th, 2011, 11:29 PM »
Quote from Nao on October 10th, 2011, 10:43 PM
But if id_topic is the primary index, then it's unique as well, isn't it..? So we can't hold two different items with id_topic = 1 in the topic table... (Can we?)
No, that's because it's auto increment and thus unique.
Quote
Then we can't have a topic=2.0... Same problem. No?
Or do you mean to store the actual topic IDs in a different place than {db_prefix}topics...?
Same problem. Might as well scratch the idea of floating topics since it cannot be implemented in a way that to be able to have contiguous user visible topics without making it over complicated (by having the user visible id be separate and disconnected from the physical id, because you then have to get into the realms of transactions to ensure that the id you use for insertion is actually the next id and hasn't been stepped on in the time between querying for last-used id and the row insertion...)

If the choice is between having separate tables or juggling ids, I'll take separate tables every time.
5978
Off-topic / Re: WIFI Kill
« on October 10th, 2011, 11:22 PM »
Quote from MultiformeIngegno on October 10th, 2011, 10:54 PM
:O :O Is there something like this for Windows?
Wouldn't be hard to write, if the PC is wifi enabled.
5979
Features / Re: Template skeleton!
« on October 10th, 2011, 10:05 PM »
Quote
...which, again, means we can't have both a topic=1.0 and a media album with ID #1. Creating a first album when topic=1.0 already exists will set the album ID to 2. And that's precisely one of the major blockers for me...
Wait, what?

The boards and albums table will be left alone, because they're foreign keys to the source-type/source-id item.

If you create a board, and an album, they're both id 1 in their respective tables.

The first topic to be created is topic id 1 (source type: board, source id 1, as it's in board 1). Then we upload a media item... it's media item 1 (in album 1), but it consumes topic id 2 (source type: album, source id 1)

You can define multiple types of index on a typical; topic own id has to be the primary key because it's auto-increment and that ensures uniqueness for the topic itself (so you don't end up with multiple topic id 1 cases)
5980
Features / Re: Template skeleton!
« on October 10th, 2011, 09:17 PM »
Quote from Nao on October 10th, 2011, 07:45 PM
I think I should feel offended... :lol:
Nope, wasn't meant as one. There simply haven't been any bad ideas.
Quote
Then that's exactly the original definition of floating topics...
Yup, hehe ;)
Quote
Or we have to ditch the id_topic key in favor of an (id_topic, board_type) key. Which I'm not sure would be as fast...?
You'd make id_topic remain the PK, then have a unique index on source_type, source_id. It'd be comparable to now, and should be faster under some circumstances.
Quote
Definitely. I was still referring simply to the storing of data itself.
*nods*
Quote
A shorter wetem is what I'm looking at for now.
Works for me.
Quote
Don't confuse me... :whistle:
Heh. Well, just seems to me that add (or better, merge) is the right verb to describe the operation being carried out.
Quote
::load(array('layer' => array('block')), 'default', 'replace')

Okay, what do you do with this...?
This says to me to replace the current contents of default with a new layer (with that new block in it)

The rename is a good idea.
Quote
I guess I'll just keep the ::layer method for easy addition of container layers, like used to be done in SMF.
And I'll consider calls to ::load to be, well... Just a series of blocks.
Works for me.
5981
The Pub / [Archive] Re: Logo Madness
« on October 10th, 2011, 06:15 PM »
*nods* I gave up after a fashion and when I have 5 minutes I plan to learn how to use Blender. But that relies on me having 5 minutes.
5982
The Pub / [Archive] Re: Logo Madness
« on October 10th, 2011, 06:02 PM »
I was doing that not too long ago trying to model some 3D objects on my iPad... not so successful.
5983
Features / Re: Template skeleton!
« on October 10th, 2011, 05:55 PM »
Quote
Which brings me back to, ah, these annoying floating topics... I think I should just rename this to 'floating messages' and give up on the idea of storing the type in the topic table, and rather have it in the message table, with a proper index.
It's not the worst idea you had this week. I'm not sure what is, but this wasn't it.

No, essentially what is needed is adding something to the topic - not the message - to define where it is. That takes care of content management internally.

All you do, much like I talked about for media items, is convert the board id into half of two columns: you have 'topic type' and 'topic context'; the type refers to board, or media item or whatever, and context is the board id or album id.

Displaying that content is another matter entirely, because then it comes down purely to presentation how you want to display it - since you'd realistically never use the same layout everywhere. The layout for posts (be they forum or blog posts) wouldn't be the same as in the PM area, wouldn't be the same as comments in media items, and whatever else (I certainly wouldn't reuse the same layout for WD, I'd keep closer to WD's original layout)

To sum up, it is exactly what you're talking about, but tied to the topic, not the individual message. A given message lives in a given topic. It's the topic which forms a collection of messages that you need to deal with putting an origin into.
Quote
Nope, it doesn't... Which is why I didn't push it into the object to begin with. It already has the block's name at this point, so it simply needs to call template_blockname().
Then it doesn't really need to belong to the class, though there's no reason why it *can't*. It is sort of between the two, go with whatever makes more sense.
Quote
Nope... load('block', 'default') will replace the 'main' block. load('block', 'sidebar') will add to the current blocks.
I think we already went through that...
So you're merging then? :P Consider array_merge. It replaces elements in the first source with those from the second, and is quite content to add things on the end as well under the right circumstances...
5984
Features / Re: Template skeleton!
« on October 10th, 2011, 05:32 PM »
Quote
So... Who adds it to their to-do?
Well, refitting the API is on my todo list for the murky future... but for now, neither of us. There are bigger fish to fry - though it's certainly relevant in the integration of Aeva for attachments.
Quote
I tried moving it to a private method, but then I remembered that Load.php and other files will use it to run specific functions from template files, such as template_init(), so I made it public, but then it doesn't have much of a point being in the object... Except for being called through self::exec in the render method.
Except for the small detail that if it's not part of the object, it won't have access to the object's variables. Does it need access to the block list for any reason, for example?
Quote
I try having as little data as possible in the object that is not directly related to outputting non-template data. I've been wondering about while_we_re_here(), for example...
That's the general idea; stuff that the object doesn't *need*, it shouldn't *have*.
Quote
But in the case of default, the list is never empty, is it..? It has the 'main' block by default in it...
But you're still adding to it, right?

Perhaps a better verb would be 'merge', which covers both adding and replacing...
5985
Features / Re: The calendar
« on October 10th, 2011, 05:11 PM »
Please vote: http://wedge.org/pub/feats/6944/birthday-calendar-plugin-core/