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 - emanuele
31
Off-topic / Re: Post count fever
« on January 30th, 2014, 02:13 PM »
I have no idea how you guys are able to write so many posts! LOL
32
Development blog / Re: That'll do.
« on January 23rd, 2014, 01:20 AM »* emanuele is happier when good beer is available, though that doesn't really cope very well with doing more "real" work... well, at least doing it properly. lol
Yep, now seems to work better with firefox.
33
Development blog / Re: That'll do.
« on January 22nd, 2014, 02:30 PM »
Congratulations!
First step accomplished, now you have to finish it! ;)
On the bug, I can confirm: firefox 26 at "low" resolutions (i.e. when the video doesn't fit into the width of the message area, so for example 1024x768), bigger than 1280 works. HTH!
First step accomplished, now you have to finish it! ;)
On the bug, I can confirm: firefox 26 at "low" resolutions (i.e. when the video doesn't fit into the width of the message area, so for example 1024x768), bigger than 1280 works. HTH!
34
Other software / Re: SMF reaction to 'unused, useless globals'
« on January 17th, 2014, 10:39 AM »But *finding* them manually? No way... Nobody's a psychic. So, the only tools at his disposals were: (1) any IDE that has that feature (e.g. Eclipse or NetBeans, one of these two, can't remember, provides small icons next to lines with unneeded globals), (2) fix-globals.php...
For example, I'm currently scanning the whole code looking for input or selects without a label:
https://github.com/emanuele45/Dialogo/tree/labels
and I'm doing it manually... 1572 input tags.
There are two drawbacks with that method:
1) it takes a shitload of time,
2) every time you start something like that on an SMF-like codebase you end up rewriting small or large parts of the code you encounter (in that branch I already did it twice and I almost just started LOL).
That said, automation FTW!! :D
35
The Pub / Re: git rebase is a joke...
« on January 15th, 2014, 11:06 PM »36
The Pub / Re: git rebase is a joke...
« on January 15th, 2014, 12:49 AM »
Provided the repository is clean of course.
* emanuele remembers the joy of finding CRLF commits...
37
The Pub / Re: git rebase is a joke...
« on January 14th, 2014, 04:56 PM »
Ehhh... I understand.
Remove the CRLF from the history is a PAIN and I have to fight with them every time... No idea how to fix them "easily". The only way is prevent them to begin with, I think there are a couple of options you can enable to ignore CRLF and force the repo to LF only.
Remove the CRLF from the history is a PAIN and I have to fight with them every time... No idea how to fix them "easily". The only way is prevent them to begin with, I think there are a couple of options you can enable to ignore CRLF and force the repo to LF only.
38
Archived fixes / Re: Stats are broken
« on January 10th, 2014, 12:53 AM »
Yep, it was a funny loop, Chrome filled up 16 GB of ram, I had to log from ssh and kill it! LOL
39
Other software / Re: SMF reaction to 'unused, useless globals'
« on January 8th, 2014, 10:39 PM »
https://github.com/SimpleMachines/SMF2.1/pull/1151
https://github.com/SimpleMachines/SMF2.1/pull/1157
It took a bit of time. :P
https://github.com/SimpleMachines/SMF2.1/pull/1157
It took a bit of time. :P
40
The Pub / Re: git problems for non-gits.
« on December 29th, 2013, 02:16 PM »AFAIK, rebase is pretty much the same as merge, it's just the way it shows up in the history log that changes..? I mean, in terms of merging the actual files together, etc.
Merge (or pull) does a single thing: brings the code from a branch into another branch. Rebase allows you to rewrite the repo history.
Of course rewrite history is "dangerous" (especially if you do it on master because it changes everything for everybody), but in certain cases it is necessary. I have the terrible habit to do git commit -asm "message", well that works when you know what you have done, but when you already have some previous non-committed stuff floating around it may create not-so-nice commits, with rebase (interactive rebase actually) you can go back to a certain commit, rework the commit, split it, squash two into one, remove unnecessary ones, etc. I do that things "frequently", for example every time I start playing with Travis-ci and new tests and I end up testing a lot of random commits just to see what is wrong, but bring that stuff into master would be stupid, so when I'm done, I come back and rework the branch to have a good-looking series of commits with a rebase.
Now, here's the process I used recently for my workflow...
- master
- Committed theme removal code. Decided to use 'new branch' in the commit window, typed 'byebye-themes'.
- Worked on that branch, then I wanted to switch to PHP 5.3-only. Instead of stashing, switching to master, unstashing, then committing to a new branch (WTF?!), I simply did another 'new branch' in the commit window, and typed 'php-5.3', and committed my changes.
- Wanted to come back to byebye-themes to commit my theme-related changes, but it didn't want to switch, because of the uncommitted stuff. First problem: why the hell can I commit to a 'new branch', but NOT to an existing, prior branch...?! Why would I need to stash, then checkout, then unstash, then uncommit?! I think I could use cherry-picking to move an existing commit to a prior branch, but I'm not very familiar with that, and I don't know if it's the 'recommended way'.
- Okay, now, it gets more complicated... If I try to delete the byebye-themes branch, it tells me that HEAD doesn't have all of the commits in it (!), even though I'd created the new branch from that one. What I want to do at this point, is merge everything back into master.
- I thought, okay, I'll just merge branches manually, one by one. So I went to the master branch, then requested a merge from byebye-themes. (I also tried rebase, with the same effect.) It told me there were conflicts. Which is HORRIBLY WRONG, because byebye-themes was committed FROM master, and master was 100% clean after that commit, so a simple fast-forward should have been enough, but it still found 40+ completely silly merge conflicts, which I'm not willing to fix manually.
You are trying to use it thinking (maybe in your subconscious) they are the same thing and they work the same, but it's not the case. ;)
In SVN branches are different directories, in git no. They are different versions of the same directory.
When you think about it it's obvious that to switch from a branch to another you cannot have uncommitted stuff. Uncommitted stuff are things that git doesn't yet know where they should be, so you have to tell it that you want them into a certain branch, otherwise it will switch to any branch you are switching to (that is not a bad thing per se, just a bit unreliable, but I use it from time to time).
(Why is everybody so frigging happy to use git when it's just systematically the same mess, and with SVN around the corner, they could just choose to forego all of that crap?)
I actually tried to do that with Pandos's repo, so that I wouldn't have to bother with duplicate merges. However, now every time I try to commit, it asks me WHERE I should commit. It doesn't accept a 'default' remote, it wants to know which remote every time, so I'm going to have to remove all of my extra remotes. Pff...
You push to a remote, but commit locally.
I doubt everyone's using a DCO..? :-/
Or maybe pull requests are considered, by practice, to be a de facto sign-off..?
The DCO was introduced in SMF just as a way to calm SM's fear of losing some kind of "property" of the code when it was clear that ask for a CLA was a no-go for github contributions, but in fact it doesn't really give anything to anyone[1], it's just a "confirmation" that you know what you are doing and you can do it, nothing else.
- So, attempting to merge byebye-themes into master WOULD result in conflicts.
What I'd need to do first is reset --hard the master branch to origin/master, or basically, merge my local byebye-themes into origin/master. Or, remove the master branch, and then rename the php-5.3 branch to master. What is best..?
| 1. | and on that there was a fight too with people (from SM) accusing others (developers mainly) to have masked (purposefully) the real meaning of the DCO, etc, but that's completely OT. |
41
Off-topic / Re: Happy Holidays !
« on December 25th, 2013, 03:07 PM »* emanuele always used god-mode when playing videogames because it's faster and easier. :P
42
Off-topic / Re: Happy Holidays !
« on December 25th, 2013, 12:50 AM »I'm positive that it won't work anyway, emanuele ... :D
43
Off-topic / Re: Happy Holidays !
« on December 24th, 2013, 11:02 PM »Hashtags in a forum. Where have we gone?
Oh, merry Christmas! :D
44
The Pub / Re: Is the admin area in urgent need of an overhaul?
« on December 21st, 2013, 01:50 AM »
I think.
If you already know the variable is a check and it is "cast" accordingly (or if you verify is one of the allowed types) then there should be no need for a second variable with a repetition of the type, yes, I agree. :)
If you already know the variable is a check and it is "cast" accordingly (or if you verify is one of the allowed types) then there should be no need for a second variable with a repetition of the type, yes, I agree. :)
45
The Pub / Re: Is the admin area in urgent need of an overhaul?
« on December 20th, 2013, 10:21 AM »Finally, what I expect to be some 'security' code... Wedge/SMF check all variables that should be written to the file, and ensure they're of the correct format. But there's absolutely no reason they could be modified otherwise. It seems like a waste of time, to me... Maybe it was security code for an older version of PHP, I don't know.
A couple of similar things were reported a while ago as security issues in SMF and were in the 2.0.2 and 2.0.3 patches (IIRC).