Wedge

Sorry, I let go of this topic... I guess it hurt too much ;)

It's still a problem, and still a mystery to me. It isn't a TCP IP packet size thingy, it probably even isn't a TCP IP problem at all because of one of the things I explained (having my network down doesn't prevent a large file from downloading, meaning packet exchange between the server and my router continues happily.)

On a positive note, today I finally managed to launch a movie file from my S3 (where I downloaded it) to my PopCorn Hour media player through streaming... I think it's the first time I ever managed to do something like that, ie not using my USB drive on it :P

Great minds again. Until last week I thought it was pronounced meme (meh meh). Then I heard someone in a video say the french word for mime. Meem as you say. I think it was in the latest big bang theory.

I typed mémé but android insisted on changing it to meme eh eh...

Okay, now I see it... I didn't open the page for non-images because I thought it'd work. It works in AeMe for SMF... :-/

I've looked into the source code, and can't find the reason for it.
Basically, $item_data['is_new'] is set to 0 when on an item page, so it doesn't attempt to mark it as seen, but set to 1 on the unseen page.
Need more time to find the culprit... -_-

But, on the same night? 8)It may not seem very 'clean', but it's certainly something that plugins might appreciate being able to do. Provided there are even hooks in parse_bbc() to deal with it, of course...What do you mean? (Or, to avoid having people think I can't speak English, "What did you have in mind?" :P)

So, I'm looking at Pete's latest commits and I found something funny... Another of those 'coincidences' I noticed earlier ;)

Last night I was fixing a bug (which I have yet to commit), related to Wedge cutting off the starting and ending linebreaks inside a quote when switching to Wysiwyg mode. (I told you, I never use Wysiwyg, except when I'm told it needs fixing...) I noticed that it didn't break any other linebreaks, so I looked into parse_bbc() and quickly remembered that I'd added a special regex just to get rid of extra whitespace. Disabling it fixed it. Then I figured, oh yeah it's because the Wysiwyg conversion shouldn't go through the same parsing steps as when actually showing the posts...
So I added a parameter to parse_bbc(), called $converting, which was set to true by the converter, and false otherwise, and it would then skip the line.
Then I thought, oh my that's a lot of parameters to deal with... And shouldn't it make more sense to ensure that it isn't called anytime there's non-standard parsing being done...? So I decided to instead go for an empty($parse_tags) test. It probably isn't perfect, but it should catch most of the occurrences, including the Wysiwyg one. So I did it that way.

Then I'm seeing the new commit, which adds an author ID parameter[1] to parse_bbc(), and really that made me smile.

So, thanks Pete for the coincidence and the smile ;)

I'm thinking, however, that we might want to instead provide a single extra parameter in the form of an array, where we could add our extra params like 'id_cache' and 'id_member' or whatever... Thus, no limits to what can be stored in the parser params, and they can in turn be transmitted to hooks so that plugins may intercept something that they target in particular.
What do you think...? Or is it too ugly of a solution?


I've always loved this kind of smart, elegant little trick ;)

1.	Also for the record, I think we both considered adding that parameter at least a couple of times in Wedge's lifetime, for various reasons!

(Sorry about the topic title, I found it irresistible to use it :lol: I'm also not posting this in private boards because I'm not sure who's in our Friends group or not. If you want it to be private, please ask for a Friend badge if you don't already have one, and request for the move to be done.)

So... First time I'm looking at Elkarte's github... There's a lot of activity so I'm not going to do that often... But I find it amusing (also a bit upsetting I'll admit) that in the first page of commits, I found this:

https://github.com/elkarte/Elkarte/commit/babfac398abdb9b49ffb3e1d3d1631585e917ede

This looks a LOT like a fix I made to Wedge in rev 1847, just four days ago...


As you'll notice, the main change in here is that I fixed the || into &&, just like in the Elkarte commit.

This sounds too coincidental to be true to me. Shouldn't I be the one who gets the thanks, not emanuele?
So...
ema, I have no problems with giving you our alpha versions or whatever, I have absolutely no qualms with you or Elkarte and wish you all the best. I'd just rather be told if you already somehow have access to our SVN without telling. It would make things more comfortable for everyone I think. It's not that I don't think it can be a coincidence -- it's that now this has happened, just a few days after my own fix, this is how I'll remember it, and the harm is already done in my mind, whatever the truth might be. And I don't like this. I don't like being in a situation where I feel uncomfortable about sharing things with other like-minded developers.

If anyone at Elkarte wants to reuse an idea or code block that we wrote, please ask us. We're not ogres. We don't cling to every bit of code that we write like it's our virgin child that we won't give away. Our license is for a general code of conduct and how we want to deal with things generally, but we're flexible on the whole.
Just please don't do this kind of thing behind our back.

Oh, the joys of doing several things at the same time...
I just noticed that the Elkarte commit was made on the exact same day. I haven't checked the times but I suspect it means that I mentioned the exact bug somewhere in this forum, which would explain everything, i.e. that it's neither a coincidence nor a problem.

But did I...? I don't remember. Can someone find my post?

rev 69
(2 files, 1kb)

* Turning a couple of substr calls to slice... Yeah, that's my thing today. (mass_upload/attachui.js, theme_selector/ThemeSelector.php)