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
1906
Off-topic / Re: Post count fever
« on January 21st, 2014, 07:14 AM »
Works if you spam one liners or you have 'game' topics. ;)
As for Pete, he's #1 at sm.org (with 57k i believe), so it's no wonder.
As for Pete, he's #1 at sm.org (with 57k i believe), so it's no wonder.
1907
The Pub / Re: Repository name poll! Yayer!!
« on January 20th, 2014, 11:33 PM »
No, not really...
I do, however, have to say that after getting a bit depressed this morning, I decided that it really doesn't matter when it's out. Nobody will try it out anyway, except for those active in here already, and said users could perfectly ask me for read access to the private Wedge repo-- I've been very, very generous with giving access to it since Pete left. So, really, it doesn't change MUCH...
But, it's also true that I was (secretly) planning to release a proper 'alpha' on the day the repo went public. It probably won't happen on the same day, but you never know. Alphas are made to be broken, after all...
I do, however, have to say that after getting a bit depressed this morning, I decided that it really doesn't matter when it's out. Nobody will try it out anyway, except for those active in here already, and said users could perfectly ask me for read access to the private Wedge repo-- I've been very, very generous with giving access to it since Pete left. So, really, it doesn't change MUCH...
But, it's also true that I was (secretly) planning to release a proper 'alpha' on the day the repo went public. It probably won't happen on the same day, but you never know. Alphas are made to be broken, after all...
1908
Off-topic / Re: Post count fever
« on January 20th, 2014, 11:30 PM »
I can't believe Pete left months ago, and yet he's still ahead of me in terms of post count... We used to be in a tie, but he really posted a lot last year, compared to me!
Well, his reign will soon end, once Wedge goes public... :niark:
In the meantime, I just noticed that I finally overtook him by number of post likes. My honor is safe. 8-)
Well, his reign will soon end, once Wedge goes public... :niark:
In the meantime, I just noticed that I finally overtook him by number of post likes. My honor is safe. 8-)
1909
The Pub / Re: Last minute frights
« on January 20th, 2014, 09:20 PM »
I don't even remember where it is, or if it has a repo for it, or whatever... It's been a long time since I touched it!
1910
The Pub / Re: Repository name poll! Yayer!!
« on January 20th, 2014, 09:18 PM »
I dunno, I clicked 'Explore' on github to see a list of accounts+repos, and the tendency is to:
- have a lowercase name if it's an organization,
- have a NormalName if it's a user account,
- and match the account's case for the repo.
Not 'systematic', but it often happens.
In any case, there are some choices I find dull (github.com/jquery/jquery would work better as github.com/jQuery/jQuery, really), others are too complicated with elaborate case.
- have a lowercase name if it's an organization,
- have a NormalName if it's a user account,
- and match the account's case for the repo.
Not 'systematic', but it often happens.
In any case, there are some choices I find dull (github.com/jquery/jquery would work better as github.com/jQuery/jQuery, really), others are too complicated with elaborate case.
1911
The Pub / Re: Repository name poll! Yayer!!
« on January 20th, 2014, 07:09 PM »
I just realized what's wrong with me...
github.com/Wedge -> looks better in small fonts, or when the github part is ommitted (e.g. the repo's page header, 'Wedge / wedge')
github.com/Wedge -> looks better in large fonts, but looks horrible in the repo's page header ('wedge / wedge').
So, the feeling I have when I see a github URL (or a bitbucket URL, but it's private) is dependent upon the current font size, AND the place where the account name is being shown, AND whether or not it has 'github.com' before it.
Must be the silliest reason ever, but... Well, whatever. Just goes to show that I'm never, never going to be 100% happy about this tiny little detail.
If a team of people can work for a year on a competitor that has a terribly sounding name[1], when they had a perfect name to begin with[2], it's probably that it doesn't matter THAT much... Eh, what can I say!
github.com/Wedge -> looks better in small fonts, or when the github part is ommitted (e.g. the repo's page header, 'Wedge / wedge')
github.com/Wedge -> looks better in large fonts, but looks horrible in the repo's page header ('wedge / wedge').
So, the feeling I have when I see a github URL (or a bitbucket URL, but it's private) is dependent upon the current font size, AND the place where the account name is being shown, AND whether or not it has 'github.com' before it.
Must be the silliest reason ever, but... Well, whatever. Just goes to show that I'm never, never going to be 100% happy about this tiny little detail.
If a team of people can work for a year on a competitor that has a terribly sounding name[1], when they had a perfect name to begin with[2], it's probably that it doesn't matter THAT much... Eh, what can I say!
| 1. | Is it a tree, or an animal? Is it a Basque word, or a mix between English and Italian? |
| 2. | 'Dialogo' sounded so nice, I could have used it for Wedge and be happy with it. |
1912
Features / Re: New revs
« on January 20th, 2014, 06:59 PM »
[master 21922d3]
20 files changed, 123 insertions(+), 25 deletions(-), 14.97 KiB
! Fixed problem where topics were being flagged as unread by MessageIndex, then confirmed as read by get_unread_numbers(), causing a nuclear implosion on the molecular level. (It's always on the molecular level, but it feels smarter to say it.) Well, technically I didn't fix anything, I just took the easy way out by doing an isset(), but at least now I know why it should happen, and why I don't really care. (MessageIndex.template.php)
! Moved privacy constants to the first likely file to use them, i.e. the system class, and used the old syntax for defining them, just in case you're trying to install on an old version of PHP. (index.php, Class-System.php)
! Fixed another installer error. I hate it when a one-time problem turns into a permanent variable test, but you gotta do what you gotta do... (Subs-Cache.php)
* Renamed the /root folder to /install, and moved some of its files to the actual root. I figured that some of these files needed to be in every distribution, regardless of the install status: license files, contributor files, and changelogs.
* Updated the Wedge license to make it clearer that you can fork Wedge on github. This is, of course, according to the git terminology that a 'fork' is just a copy of the Wedge repository that sits in your public account, ready to share your improvements back to Wedge. (Anyone willing to bet it'll be months before I get my first pull request for a feature or plugin from someone not already well involved in Wedge? ;))
+ Added a CRLF-friendly README, GitHub-style, that should serve as a quick introduction to Wedge newbies. (README.md.txt)
20 files changed, 123 insertions(+), 25 deletions(-), 14.97 KiB
! Fixed problem where topics were being flagged as unread by MessageIndex, then confirmed as read by get_unread_numbers(), causing a nuclear implosion on the molecular level. (It's always on the molecular level, but it feels smarter to say it.) Well, technically I didn't fix anything, I just took the easy way out by doing an isset(), but at least now I know why it should happen, and why I don't really care. (MessageIndex.template.php)
! Moved privacy constants to the first likely file to use them, i.e. the system class, and used the old syntax for defining them, just in case you're trying to install on an old version of PHP. (index.php, Class-System.php)
! Fixed another installer error. I hate it when a one-time problem turns into a permanent variable test, but you gotta do what you gotta do... (Subs-Cache.php)
* Renamed the /root folder to /install, and moved some of its files to the actual root. I figured that some of these files needed to be in every distribution, regardless of the install status: license files, contributor files, and changelogs.
* Updated the Wedge license to make it clearer that you can fork Wedge on github. This is, of course, according to the git terminology that a 'fork' is just a copy of the Wedge repository that sits in your public account, ready to share your improvements back to Wedge. (Anyone willing to bet it'll be months before I get my first pull request for a feature or plugin from someone not already well involved in Wedge? ;))
+ Added a CRLF-friendly README, GitHub-style, that should serve as a quick introduction to Wedge newbies. (README.md.txt)
1913
The Pub / Re: Last minute frights
« on January 20th, 2014, 06:53 PM »
I mean, you say you're laughing, then you imply you're serious about it...
As for converting forums, it won't be possible until I get the importer out. It should work, but honestly I wouldn't bet on it, because I haven't tested it in a while, and I've done too many changes these days...
As for converting forums, it won't be possible until I get the importer out. It should work, but honestly I wouldn't bet on it, because I haven't tested it in a while, and I've done too many changes these days...
1914
The Pub / Re: Repository name poll! Yayer!!
« on January 20th, 2014, 03:35 PM »
I've updated the poll for simplicity.
A majority of voters (13 out of 18) chose 'wedge' for the repository name (over 'Wedge' and 'forum'), so this will be its name.
The vote on the account (organization) name was more split (5 versus 8 out of these 13), though, and I'd like to give it another go before it's too late. ;)
Let's give it a few hours, then! I guess I'll settle at the last minute.
A majority of voters (13 out of 18) chose 'wedge' for the repository name (over 'Wedge' and 'forum'), so this will be its name.
The vote on the account (organization) name was more split (5 versus 8 out of these 13), though, and I'd like to give it another go before it's too late. ;)
Let's give it a few hours, then! I guess I'll settle at the last minute.
1915
The Pub / Re: Last minute frights
« on January 20th, 2014, 02:55 PM »
Core it'll be, then!
I figured that with a shorter name such as sys, it'd be even easier to 'spot' the main folder among the folder list, but now that 'css' and 'js' are gone, there's only 'gz' and 'core' to differentiate between, and 'gz' stands out enough of its own to quickly eliminate it.
I'm still hard at work on Wedge. I wanted to release it this morning, but it's hard, really hard.
Wanchope, "no pun intended" implies you're serious. Are you..?
I figured that with a shorter name such as sys, it'd be even easier to 'spot' the main folder among the folder list, but now that 'css' and 'js' are gone, there's only 'gz' and 'core' to differentiate between, and 'gz' stands out enough of its own to quickly eliminate it.
I'm still hard at work on Wedge. I wanted to release it this morning, but it's hard, really hard.
Wanchope, "no pun intended" implies you're serious. Are you..?
1916
The Pub / Re: Last minute frights
« on January 20th, 2014, 08:34 AM »
It's public alpha 3. (Alpha 1 & 2 were private... And released well over a year ago.)
Nothing's feature-frozen until I go RC. Nothing's guaranteed until I go beta. But still, I don't want to have to change the structure again after it's made public.
Seriously, I'm so stressed, I had a horrible night, my throat is aching and I really should take a break.
So, a question.
/core
/root
/src
/sys
/system
Of these 5 folder names currently in consideration for the "main" folder of Wedge (not the Wedge folder itself, but the folder that contains app, html, javascript, languages and skins), which sounds best to you guys..?
@Wanchope> You can talk, you're the one who's laughing right now...
Nothing's feature-frozen until I go RC. Nothing's guaranteed until I go beta. But still, I don't want to have to change the structure again after it's made public.
Seriously, I'm so stressed, I had a horrible night, my throat is aching and I really should take a break.
So, a question.
/core
/root
/src
/sys
/system
Of these 5 folder names currently in consideration for the "main" folder of Wedge (not the Wedge folder itself, but the folder that contains app, html, javascript, languages and skins), which sounds best to you guys..?
@Wanchope> You can talk, you're the one who's laughing right now...
1917
The Pub / Last minute frights
« on January 19th, 2014, 11:37 PM »
So, I'm supposed to release tomorrow...
Today, I changed another set of files (/cache became /gz, and /css and /js were integrated into it), because I didn't like having so many root folders just for caching.
I also screwed up another commit, with a change that was too random and broke other stuff. In the future, these changes will be reverted the usual way, but I much prefer being able to amend a commit. I'll just have to learn, I guess, that I shouldn't push until everything's tested...
My main issue is with the update process. Now I have this /core folder where I log into. Then I have to determine what files I should update. I'm totally lost, because the folder names are no longer distinguished by starting with an uppercase char or something like that.
Voilà. I just don't like the new update process. I find it harder, or longer, than the previous one. But I can't revert either, because this new folder structure has some actual *meaning*. I wanted to remove themes, so I'll have to live with the fact that I can't rely on the Themes folder structure any more.
Believe me... It's hard.
And tomorrow, I'm supposed to set the database structure in stone. I'm supposed to say, "okay, I'll never change it anymore, except for big additions for which I'll write some sort of script."
But the more I look at the SQL file, the more I find things to change.
For instance, MySQL 5.0.3 supports the BIT data format. Ever heard about that..? Me neither. TINYINT(1) is used for booleans in Wedge (and SMF), but it still uses one byte per entry. The BIT(1) format allows the use of 8 times less space. So, yes, it's VERY tempting to start using BIT(1) everywhere, since Wedge will always support it... But... There's a but... WHAT if one of these columns actually has more than two values? Like, for instance, "wedge_screwed_up.IamABoolean = (0, 1, 2)", where "2" was added by a SMF developer to account for a problem that couldn't be solved with binary thinking. It still fits into TINYINT, but not into BIT. Making it prone to bugs in Wedge.
There are dozens of TINYINTs, and I don't know if it's worth double-checking every table to make sure it doesn't use these columns in a weird way.
I can always change everything to BIT(1) later, little by little, but...
It just goes to show that I don't feel ready for a public release. Really, really, I feel like I'm freezing.
Today, I changed another set of files (/cache became /gz, and /css and /js were integrated into it), because I didn't like having so many root folders just for caching.
I also screwed up another commit, with a change that was too random and broke other stuff. In the future, these changes will be reverted the usual way, but I much prefer being able to amend a commit. I'll just have to learn, I guess, that I shouldn't push until everything's tested...
My main issue is with the update process. Now I have this /core folder where I log into. Then I have to determine what files I should update. I'm totally lost, because the folder names are no longer distinguished by starting with an uppercase char or something like that.
Voilà. I just don't like the new update process. I find it harder, or longer, than the previous one. But I can't revert either, because this new folder structure has some actual *meaning*. I wanted to remove themes, so I'll have to live with the fact that I can't rely on the Themes folder structure any more.
Believe me... It's hard.
And tomorrow, I'm supposed to set the database structure in stone. I'm supposed to say, "okay, I'll never change it anymore, except for big additions for which I'll write some sort of script."
But the more I look at the SQL file, the more I find things to change.
For instance, MySQL 5.0.3 supports the BIT data format. Ever heard about that..? Me neither. TINYINT(1) is used for booleans in Wedge (and SMF), but it still uses one byte per entry. The BIT(1) format allows the use of 8 times less space. So, yes, it's VERY tempting to start using BIT(1) everywhere, since Wedge will always support it... But... There's a but... WHAT if one of these columns actually has more than two values? Like, for instance, "wedge_screwed_up.IamABoolean = (0, 1, 2)", where "2" was added by a SMF developer to account for a problem that couldn't be solved with binary thinking. It still fits into TINYINT, but not into BIT. Making it prone to bugs in Wedge.
There are dozens of TINYINTs, and I don't know if it's worth double-checking every table to make sure it doesn't use these columns in a weird way.
I can always change everything to BIT(1) later, little by little, but...
It just goes to show that I don't feel ready for a public release. Really, really, I feel like I'm freezing.
1918
Features / Re: Language revs
« on January 19th, 2014, 11:27 PM »
Pandos, if you pulled the latest revision of the main Wedge repo (the one with all the CSS changes), then you'll have to re-do a clean repo when I push it to github, because I'm amending my revision before it's too late.
If you haven't done it yet, then wait a bit ;)
Or, a bit easier...
Right-click your repo, Git Show Log.
Right-click revision c663d38709eca586f069647e990a43adc25e925f (the second one in the list). Click "Reset to this". Choose "Hard". Confirm.
Now you can safely Pull from the repo. The last update will be overwritten.
If you haven't done it yet, then wait a bit ;)
Posted: January 19th, 2014, 11:05 PM
Or, a bit easier...
Right-click your repo, Git Show Log.
Right-click revision c663d38709eca586f069647e990a43adc25e925f (the second one in the list). Click "Reset to this". Choose "Hard". Confirm.
Now you can safely Pull from the repo. The last update will be overwritten.
1919
Features / Re: New revs
« on January 19th, 2014, 11:19 PM »
ABOVE IS AMENDED.
Because I still can commit, push, amend and re-push. From tomorrow on, I won't be able to do that. I'm sad.
[master 5bc16c9]
5 files changed, 23 insertions(+), 7 deletions(-)
! Why doesn't the board manager allow you to open multiple boards at once anyway..?! I'm fine with not doing it for categories, but boards... You can have many of them. (ManageBans.template.php, mana.css)
! My definition lists don't work so well in medium-sized desktop windows. A shame. Making the trigger stricter, then. (sections.css)
! Forgot to commit the lang cache folder. (gz/lang/*)
Because I still can commit, push, amend and re-push. From tomorrow on, I won't be able to do that. I'm sad.
[master 5bc16c9]
5 files changed, 23 insertions(+), 7 deletions(-)
! Why doesn't the board manager allow you to open multiple boards at once anyway..?! I'm fine with not doing it for categories, but boards... You can have many of them. (ManageBans.template.php, mana.css)
! My definition lists don't work so well in medium-sized desktop windows. A shame. Making the trigger stricter, then. (sections.css)
! Forgot to commit the lang cache folder. (gz/lang/*)
1920
Features / Re: Language revs
« on January 19th, 2014, 10:58 PM »
[master 17db91e]
2 files changed, 9 insertions(+), 6 deletions(-)
Board type modifications. (ManageBoards, index)
Sorry, I only just noticed your pull request. Which happens to override my latest push. Oops. Can you make rebase your commits onto my updated master, sign this off, and then pull request? (You will NEED to do a rebase, and use to opportunity to squash your commits together. I'm really sorry, I didn't expect you to update from the Wedge repo, rather from the languages repo, which didn't have the latest changes.)
2 files changed, 9 insertions(+), 6 deletions(-)
Board type modifications. (ManageBoards, index)
Sorry, I only just noticed your pull request. Which happens to override my latest push. Oops. Can you make rebase your commits onto my updated master, sign this off, and then pull request? (You will NEED to do a rebase, and use to opportunity to squash your commits together. I'm really sorry, I didn't expect you to update from the Wedge repo, rather from the languages repo, which didn't have the latest changes.)