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 - Nao
2086
Features / Re: New revs
« on December 29th, 2013, 03:41 PM »
[php-5.3 8e8967e]
253 files changed, 33939 deletions(-), 409 bytes
- Moving other/ folder into a different repo altogether, and deleting it from here. At one point, when I get to rewrite/clean up the Wedge history, I'll remove other/ from it entirely, and this commit will be gone, too, so, it's the ultimate opportunity to just say it, loud and clear: (REDACTED-BY-GIT)
253 files changed, 33939 deletions(-), 409 bytes
- Moving other/ folder into a different repo altogether, and deleting it from here. At one point, when I get to rewrite/clean up the Wedge history, I'll remove other/ from it entirely, and this commit will be gone, too, so, it's the ultimate opportunity to just say it, loud and clear: (REDACTED-BY-GIT)
2087
The Pub / Re: git problems for non-gits.
« on December 29th, 2013, 01:19 PM »
I think I've found the reason for the merge conflicts in master...
Apparently, here's how it happened:
- 14 December: committed my theme changes to 'master'.
- 15 December: fixed many bugs. Decided that theme removal was worth a branch by itself. Clicked 'Amend' on the commit window, so that it would re-use the last commit. Click 'new branch', entered 'byebye-themes'.
- As a result, the 'master' branch was NOT reset to its previous state. Instead, it still holds the FIRST version of the commit, dated from December 14, while byebye-themes has the second version of it, also dated December 14, but if you click 'Commit Date', you'll see it's actually from December 15.
- 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..?
Apparently, here's how it happened:
- 14 December: committed my theme changes to 'master'.
- 15 December: fixed many bugs. Decided that theme removal was worth a branch by itself. Clicked 'Amend' on the commit window, so that it would re-use the last commit. Click 'new branch', entered 'byebye-themes'.
- As a result, the 'master' branch was NOT reset to its previous state. Instead, it still holds the FIRST version of the commit, dated from December 14, while byebye-themes has the second version of it, also dated December 14, but if you click 'Commit Date', you'll see it's actually from December 15.
- 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..?
2088
The Pub / Re: git problems for non-gits.
« on December 29th, 2013, 12:02 PM »If you are doing things "right" you should *never* use rebase (unless of merge conflicts, but that's another topic).Quote from Nao on December 15th, 2013, 10:58 PM - I didn't have to play with rebase at any point. Does that mean I'm free from it, or not? Is rebasing needed only when committing from another branch...?
I've got so many problems with merging, eh... For instance, if merging on bitbucket or github, you get an extra commit with the merge process. The infamous ones, the ones that take up all of the space in the history log, and make it look like there's more activity than usual. If merging locally, nothing happens. It's just a fast-forward, so it simply moves the ref for that branch to the other branch's ref. AFAICT, at least.
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.
I mean, if it's all that complicated, I'm NEVER going to use branches again. And you know what that means..? It means I'm just doing SVN stuff, and then I'll start requesting that people send me patches, instead of pull requests. I know that many popular projects 'do it' this way, so it's not a big deal in the end, but wasn't the whole branching business the main selling point of git..? Wasn't its 3-way merge lauded as a genius thing? Why then, would I get a merge conflict on something that just needs a fast-forward?
You can work with a sort of "centralized" repo, yes (that is basically what the "upstream" in your case is), the only problem I can see is this:
* repo upstream => commit 1 (let's say)
* I do a commit in my local and push => repo emanuele commit 2
* in the meantime you do a commit on your local repo => origin commit 3
* I send a PR and you merge it from github => repo upstream commit => 4
Now, you'd have to synch your local repo and the remote one (upstream) but: if you push you get a fast-forward (or whatever it is) error because you have new commits locally and new commits in the remote, so you have first to "pull"[1] the remote repo and then push it again.
1. pull is equivalent to fetch + merge, so "grab the remote history and merge it into your local branch"
It's not so different in fact (and probably for your work-flow it could make more sense), the only difference is what is considered the "master" repository: doing the pull request way is the one that belongs to he organization (like for Elk and SMF, in this case you never commit to the org repo, but always to your local one and then synch), in the other you consider your local repo the original one and you could even ignore PR at github and instead fetch the other repos and do the merges directly on your local copy (sorry, I'm one of the few that apparently loves git workflow and can't stop thinking about all the alternatives to do the same thing LOL).
Good question... you should suggest it to them.
Probably because sign-off is not *so* popular...I think, but dunno.
Or maybe pull requests are considered, by practice, to be a de facto sign-off..?
2089
Plugins / Re: Lang. files?
« on December 27th, 2013, 11:58 PM »
This is the desired format for French language files (for instance):
FORUM_ROOT/languages/index.french.php
This is the desired format in a tentative repo:
REPO_ROOT/French/index.french.php
I can easily have plugins in a separate repo because I'm using the repo as my Plugins folder in my local Wedge install, and I don't have to copy files. But I can't maintain a language repo the same way, because a 'professional' repo would need to separate all languages clearly, when the Wedge repo will require languages to be all in the same folder -- mostly because it's then easier to update by FTP.
Any solutions, maybe..?
FORUM_ROOT/languages/index.french.php
This is the desired format in a tentative repo:
REPO_ROOT/French/index.french.php
I can easily have plugins in a separate repo because I'm using the repo as my Plugins folder in my local Wedge install, and I don't have to copy files. But I can't maintain a language repo the same way, because a 'professional' repo would need to separate all languages clearly, when the Wedge repo will require languages to be all in the same folder -- mostly because it's then easier to update by FTP.
Any solutions, maybe..?
2090
Features / Re: New revs
« on December 27th, 2013, 11:12 PM »
[php-5.3 5129f7b]
21 files changed, 515 insertions(+), 511 deletions(-), 20.03 KiB
* More create_function calls were utterly destroyed for the good of everyone. Nearly all of them are done, the rest are in WIP files. (Dlattach.php, ManageAttachments.php, ManageBans.php, ManageMaintenance.php, ManageMembergroups.php, ManageMemberOptions.php, ManageMembers.php, ManagePaid.php, ManageScheduledTasks.php, ManageSearchEngines.php, ManageSmileys.php, ModerationCenter.php, Modlog.php, RepairBoards.php, Subs-Members.php, install.php)
! Fixed incorrect handling of invalid database prefixes. Replaced a leftover language entry with this new error string. (install.php, Install.language.php)
! Fixed TTL on a settings cache call. (ManageServer.php)
* Saving a cache refresh. (ScheduledTasks.php)
21 files changed, 515 insertions(+), 511 deletions(-), 20.03 KiB
* More create_function calls were utterly destroyed for the good of everyone. Nearly all of them are done, the rest are in WIP files. (Dlattach.php, ManageAttachments.php, ManageBans.php, ManageMaintenance.php, ManageMembergroups.php, ManageMemberOptions.php, ManageMembers.php, ManagePaid.php, ManageScheduledTasks.php, ManageSearchEngines.php, ManageSmileys.php, ModerationCenter.php, Modlog.php, RepairBoards.php, Subs-Members.php, install.php)
! Fixed incorrect handling of invalid database prefixes. Replaced a leftover language entry with this new error string. (install.php, Install.language.php)
! Fixed TTL on a settings cache call. (ManageServer.php)
* Saving a cache refresh. (ScheduledTasks.php)
2091
Off-topic / Re: Contact vs Followers?
« on December 25th, 2013, 01:25 AM »
There is currently no ui for contact lists. The reason is that it's not something I can't write later, after I go public.
Right now you can only add or remove the current member whose profile you're viewing. The number of people in a specific list is indicated in brackets. I don't think writing the ui would take more than a day, I'm just focusing on things I really need to finish, ie Theme removal, php 5.3 update (most of this I'll postpone though), php cache (I may postpone it as well), and folder structure changes (these rely mostly on theme removal.)
Oh gosh. I'm in a motel and I miss coding. I'm in withdrawal. Why don't they have computers? I can't code on my S3... :(
Right now you can only add or remove the current member whose profile you're viewing. The number of people in a specific list is indicated in brackets. I don't think writing the ui would take more than a day, I'm just focusing on things I really need to finish, ie Theme removal, php 5.3 update (most of this I'll postpone though), php cache (I may postpone it as well), and folder structure changes (these rely mostly on theme removal.)
Oh gosh. I'm in a motel and I miss coding. I'm in withdrawal. Why don't they have computers? I can't code on my S3... :(
2092
Off-topic / Re: Contact vs Followers?
« on December 24th, 2013, 02:57 PM »
Who's gonna be my biatch today?
:niark:
:niark:
2093
Off-topic / Re: Happy Holidays !
« on December 24th, 2013, 12:21 PM »Merry Christmas to all..and I know what you mean by the code calling, Nao. :D
The commit I just sent is just a demo of what's coming up. Good news is, I don't HAVE to finish everything before I go public; I can do it little by little, even much later.
2094
Off-topic / Re: Contact vs Followers?
« on December 24th, 2013, 12:18 PM »
Guys, if you insist on fighting, I'll rename it to Bitch List :P
2095
Features / Re: New revs
« on December 24th, 2013, 12:14 PM »
[php-5.3 8729bad]
16 files changed, 129 insertions(+), 111 deletions(-), 3.99 KiB
+ Added wesql::fetch_all() and wesql::fetch_rows() functions, which are helper functions implementing PHP 5.3's mysqli_fetch_all. Still need to actually use it everywhere it makes sense, of course... (i.e. anywhere row retrieval is done all at once.) (Class-DB.php, Pin.php)
+ Wedge now supports a permanent cache status. Just use 'forever' as the TTL parameter. (Subs-Cache.php)
* Wedge now uses permanent caching for settings. Redoing that query every 90 seconds made no sense, as once settings are updated, the cache is always emptied anyway. I found a few areas where it wasn't true, so I fixed them as well. (Load.php, ManagePlugins.php, ManageSearch.php, ScheduledTasks.php, Subs-Post.php, Subs.php)
* Also switched smiley database cache to permanent status. I'd already partially accounted for that in my smiley rewrite years ago, and I'm not exactly sure why I didn't go all the way at the time. (Class-Editor.php, ManageSmileys.php, Subs-BBC.php)
* Wedge cache filenames cache (what an interesting name) is now permanent, too. (Subs-Cache.php)
@ No idea why $settings['settings_updated'] isn't updated in updateSettings() (what an interesting sentence); I have a feeling it's a dirty hack and it should be removed from Wedge ASAP.
- Unused array. (Subs-Cache.php)
- Unused setting. (install.sql)
- Removed an eval feature that was available for lists, but never used. In case plugins need that, I'll add a callback version, but don't ask me to use eval when not needed. (Subs-List.php)
* Renamed post_retri_eval to after_run in cache_quick_get(), and using lambda functions instead of eval(). $params are passed as your function params, as it just makes sense. AFAIK, this is only used in the calendar code, which is not even core in Wedge. (Subs-Cache.php)
* Turned a couple of string helper functions to closures. (Class-String.php)
! Missing global in list_getGroups(). Also got rid of the create_function calls, yay. (Groups.php)
16 files changed, 129 insertions(+), 111 deletions(-), 3.99 KiB
+ Added wesql::fetch_all() and wesql::fetch_rows() functions, which are helper functions implementing PHP 5.3's mysqli_fetch_all. Still need to actually use it everywhere it makes sense, of course... (i.e. anywhere row retrieval is done all at once.) (Class-DB.php, Pin.php)
+ Wedge now supports a permanent cache status. Just use 'forever' as the TTL parameter. (Subs-Cache.php)
* Wedge now uses permanent caching for settings. Redoing that query every 90 seconds made no sense, as once settings are updated, the cache is always emptied anyway. I found a few areas where it wasn't true, so I fixed them as well. (Load.php, ManagePlugins.php, ManageSearch.php, ScheduledTasks.php, Subs-Post.php, Subs.php)
* Also switched smiley database cache to permanent status. I'd already partially accounted for that in my smiley rewrite years ago, and I'm not exactly sure why I didn't go all the way at the time. (Class-Editor.php, ManageSmileys.php, Subs-BBC.php)
* Wedge cache filenames cache (what an interesting name) is now permanent, too. (Subs-Cache.php)
@ No idea why $settings['settings_updated'] isn't updated in updateSettings() (what an interesting sentence); I have a feeling it's a dirty hack and it should be removed from Wedge ASAP.
- Unused array. (Subs-Cache.php)
- Unused setting. (install.sql)
- Removed an eval feature that was available for lists, but never used. In case plugins need that, I'll add a callback version, but don't ask me to use eval when not needed. (Subs-List.php)
* Renamed post_retri_eval to after_run in cache_quick_get(), and using lambda functions instead of eval(). $params are passed as your function params, as it just makes sense. AFAIK, this is only used in the calendar code, which is not even core in Wedge. (Subs-Cache.php)
* Turned a couple of string helper functions to closures. (Class-String.php)
! Missing global in list_getGroups(). Also got rid of the create_function calls, yay. (Groups.php)
2096
Features / Re: Ajax Quick Reply?
« on December 23rd, 2013, 07:21 PM »
I'm not exactly sure what the fuss is about being able to Ajaxively quick reply. I mean, it's bound to bring more problems than it solves.
e.g., I'm posting a new reply, but someone's answered in the meantime. Should I show the post before, and draw your attention to it? Maybe I'll work on that in the future, but unless I'm paid for the job...
Also, if you post a reply on a page that has 15 replies already, you'll end up with your post on that page. Say you now want to share your post withfollowers friends. Instead of copying the permalink, you copy the page's URL. And voilà, your friends will NOT see the post you meant to show them, because it's on the following page, not that one.
e.g., I'm posting a new reply, but someone's answered in the meantime. Should I show the post before, and draw your attention to it? Maybe I'll work on that in the future, but unless I'm paid for the job...
Also, if you post a reply on a page that has 15 replies already, you'll end up with your post on that page. Say you now want to share your post with
2097
Off-topic / Re: Contact vs Followers?
« on December 23rd, 2013, 07:18 PM »
Lol.
Well, you can always edit your language files to change the name...
But I'll stick with contacts. It's possibly the most generic name for the feature. It doesn't imply friendship, admiration or anything. It's just a *member bookmark* for you to easily find people you know and follow their latest posts and thoughts.
Well, you can always edit your language files to change the name...
But I'll stick with contacts. It's possibly the most generic name for the feature. It doesn't imply friendship, admiration or anything. It's just a *member bookmark* for you to easily find people you know and follow their latest posts and thoughts.
2098
Features / Re: New revs
« on December 23rd, 2013, 07:16 PM »
[php-5.3 2fe90ec] -- how many branches can I live with before I start merging them...? :P
12 files changed, 291 insertions(+), 339 deletions(-), 6.11 KiB
* Wedge now requires PHP 5.3+, which allows me to use closures instead of create_function or other ugly callbacks. I'm not going to use these everywhere (it's a manual conversion), but I'm definitely excited to use it everywhere I can from now on. Also, using const keywords where possible -- it should be faster over define() calls. (index.php, Class-CSS.php, Class-String.php, Class-System.php, Profile-Modify.php, QueryString.php, Profile.template.php)
* Overhauled the installer's readme file. I don't know if anyone's ever read it, but it needed more work. Eventually, I'll copy that file somwhere on wedge.org, don't fret. (readme_install.html)
- PCRE is always compiled from PHP 5.3 on, and its version is recent enough, so I can finally remove the PCRE test. Which means no one ever got to see it... Hmm. (install.php, Install.language.php)
12 files changed, 291 insertions(+), 339 deletions(-), 6.11 KiB
* Wedge now requires PHP 5.3+, which allows me to use closures instead of create_function or other ugly callbacks. I'm not going to use these everywhere (it's a manual conversion), but I'm definitely excited to use it everywhere I can from now on. Also, using const keywords where possible -- it should be faster over define() calls. (index.php, Class-CSS.php, Class-String.php, Class-System.php, Profile-Modify.php, QueryString.php, Profile.template.php)
* Overhauled the installer's readme file. I don't know if anyone's ever read it, but it needed more work. Eventually, I'll copy that file somwhere on wedge.org, don't fret. (readme_install.html)
- PCRE is always compiled from PHP 5.3 on, and its version is recent enough, so I can finally remove the PCRE test. Which means no one ever got to see it... Hmm. (install.php, Install.language.php)
2099
The Pub / Re: Minimum PHP version?
« on December 23rd, 2013, 05:19 PM »
@Auk is there a problem with WampServer..?
2100
Features / Re: Ajax Quick Reply?
« on December 23rd, 2013, 04:15 PM »
Live627 already wrote a plugin for that, IIRC, so I don't know if I'll ever make it core.