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
4666
Features / Re: Virtual selectors in WeCSS
« on August 11th, 2012, 11:06 PM »
I'm not in the best of moods regarding my current work on Wedge... (And it's not helped by a certain basketball match playing right now on my TV... :P)
Implementing virtuals is proving to be the biggest hurdle ever for WeCSS. And that's really odd, because after my initial failure, I settled for a VERY simple version of it: dealing with them just like with any selector, and removing them from selector lists after inheritance is calculated.
Well, all hell broke loose after that.
- If I move one of the virtuals to a certain position, everything compiles correctly. If I move it just two lines below it (even though those lines have nothing to do with it), that virtual will still work, but some other inherited selectors will suddenly disappear from the list. I've spent hours and hours on this, but I just couldn't understand why. For instance, .top_likes simply goes away from the final file. If you'll look at the CSS for it, .top_likes is inherited from stuff that has nothing to do with my short list of virtuals (inline-block, wehead, wefoot...)
- If I remove the virtual keyword from the entire file, I suddenly find myself with a completely failed compiled file: only rules are printed in it, not selectors! I'm sure this one is easier to fix, but still, I'm baffled...
See, that's exactly what Pete has been going through these days -- the feeling that you simply can't code anything worthwhile these days. It's easy to fall into that trap... It's even more annoying when it's code that you wrote long ago and that has always worked flawlessly, despite its extreme complexity. :(
Implementing virtuals is proving to be the biggest hurdle ever for WeCSS. And that's really odd, because after my initial failure, I settled for a VERY simple version of it: dealing with them just like with any selector, and removing them from selector lists after inheritance is calculated.
Well, all hell broke loose after that.
- If I move one of the virtuals to a certain position, everything compiles correctly. If I move it just two lines below it (even though those lines have nothing to do with it), that virtual will still work, but some other inherited selectors will suddenly disappear from the list. I've spent hours and hours on this, but I just couldn't understand why. For instance, .top_likes simply goes away from the final file. If you'll look at the CSS for it, .top_likes is inherited from stuff that has nothing to do with my short list of virtuals (inline-block, wehead, wefoot...)
- If I remove the virtual keyword from the entire file, I suddenly find myself with a completely failed compiled file: only rules are printed in it, not selectors! I'm sure this one is easier to fix, but still, I'm baffled...
See, that's exactly what Pete has been going through these days -- the feeling that you simply can't code anything worthwhile these days. It's easy to fall into that trap... It's even more annoying when it's code that you wrote long ago and that has always worked flawlessly, despite its extreme complexity. :(
4667
Off-topic / Re: Nexus 7
« on August 10th, 2012, 10:39 PM »
Not available in France...
It's probably the tablet I'll be buying if I ever buy an iPhone 5. If I settle for an Android phone, I'll probably pass on a tablet altogether, or watch out for the iPad Mini.
It's probably the tablet I'll be buying if I ever buy an iPhone 5. If I settle for an Android phone, I'll probably pass on a tablet altogether, or watch out for the iPad Mini.
4668
The Pub / Re: Bloc Madness
« on August 10th, 2012, 12:31 PM »
Well, it might sound odd, but I don't hold grudges against people as long as they're willing to talk again (i.e. we both recognize our mutual interest in each other.)
Except with akyhne and vblamer of course, because they're so lame and don't even deserve a second of my time. :niark:
Except with akyhne and vblamer of course, because they're so lame and don't even deserve a second of my time. :niark:
4669
Off-topic / Re: Doctor Who
« on August 10th, 2012, 09:44 AM »(click to show/hide) If this is true, he would have rewritten time to get Amy back but like Rory, he shouldn't save him in "Cold Blood" but we will see.
AFAIK, the Doctor can't rewrite time if it has already happened to him or something like that... There's a matter of stability at play. He mentioned that in some episode in the past.
Posted: August 10th, 2012, 09:39 AM
start with Doctor #3 (John Pertwee) and watch through doctor #5 (Peter Davidson)
those are the classics.
Doctors 2 and 6-8 were water, IMO...
Doctors 9 (reboot, Christopher Eckelston) 10 (David Tennant) and 11 (Matt Smith) are all awesome!
I probably would never have got into Dr Who if it wasn't for the revival.
Even then -- the first series of the revival is quite ridiculous at times. They did a lot of work in series 3 and later to fix that. At that point it even became a little bit too serious, but OTOH it was simply thrilling... The best episodes are in series 3 to 6.
I'll just give my sincere opinion based on a real life example: the absolute best entry point into Dr Who is the series 3 episode, "Blink". Because (1) it's one of the best in the entire show, and gives you a real feel of what it can achieve, and (2) the episode is told from the POV of a new, unique character we only see in that particular episode, so there are no loose ties, and she discovers the Doctor as an enigmatic entity that she'll never forget.
I actually showed that episode to a friend who didn't know a thing about the Doctor. Two weeks later, he told me he'd watched the entire show (series 1-4 at the time.) And was addicted, of course. Heck, at that point he knew the show better than I did... (Which isn't surprising. I tend to forget storylines are I've watched them.)
4670
Features / Re: New revs
« on August 9th, 2012, 02:34 PM »
rev 1654 -- just a commit to ease my life on wedge.org... :P
(2 files, 3kb)
! Added a temporary fix for Opera 12.50 rev 1538. As you may know, Opera is my default browser and their latest alpha fixes the long-lived bug that I had to write a hack in SMF for, back in 2010. Unfortunately, that hack is no longer valid and all SMF installs are broken in that build, so I devised a slightly better way of handling line breaks. Used the opportunity to better compress that code block. My name is Nao and I like saving bytes. (editor.js)
! IE6 and IE7 don't like confirm() to be redefined without specifying its window namespace. Silly... (script.js)
+ Added reqWin support for alert(), although it's the same fight as confirm(): it can only be used successfully when within an event. I'll probably have to rename all calls to account for that... Thankfully there aren't a lot for alert(). (script.js)
(2 files, 3kb)
! Added a temporary fix for Opera 12.50 rev 1538. As you may know, Opera is my default browser and their latest alpha fixes the long-lived bug that I had to write a hack in SMF for, back in 2010. Unfortunately, that hack is no longer valid and all SMF installs are broken in that build, so I devised a slightly better way of handling line breaks. Used the opportunity to better compress that code block. My name is Nao and I like saving bytes. (editor.js)
! IE6 and IE7 don't like confirm() to be redefined without specifying its window namespace. Silly... (script.js)
+ Added reqWin support for alert(), although it's the same fight as confirm(): it can only be used successfully when within an event. I'll probably have to rename all calls to account for that... Thankfully there aren't a lot for alert(). (script.js)
4671
The Pub / Re: Bloc Madness
« on August 9th, 2012, 11:55 AM »
I posted a long answer over there... Since it's a pre-moderated message (meh), I'm posting it here in case Bloc doesn't approve it...Quote
I'm curious to see how long it will take you to innocently come back to wedge.org and discuss the upcoming release when you didn't exactly have nice words to say about it just last month when you had ViennaBBS to look forward to ;)Quote from Xarcell on August 9th, 2012, 01:19 AM I really hate to hear it Bloc. I was waiting for viennabbs also. I even resigned from Dream Portal. Oh well, it is what it is.
Don't forget about EosAlpha, either...
Bloc, I just wanted to register to make something clear on your forum -- because in the end, it's always about two communities not talking to each other and having preconceived opinions about one another.
So, without further ado:
- Yes, I rejected your last suggestions about Wedge, and no, it doesn't mean I'm a bad guy.
- Yes, Pete and I always have the last word on Wedge. But because we're the decision makers, we also have a huge responsibility to deliver on our word. And I'd much rather be 'powerless' at this point, and not have that responsibility. The stress level would be totally different.
- No, just because I rejected your suggestions, it doesn't mean I rejected you.
- And just because you have ego issues, it doesn't mean we don't respect you either. We do have ego issues, ourselves.
- I'd just like for it to make it clear that I have the utmost respect for your work and your skills, but that I don't think you're being fair -- to us, to your users, and to yourself. If you're going to make ViennaBBS, then do it silently like we did for a year with Wedge. Don't mention it, then say you're giving up, then resuming work, then giving up again. Just say it's something you don't have plans to release before 2015 or something, and people will lose immediate interest, while still trying to follow what you're doing. It'll be less messy.
- If you're going to complain about Wedge, say anything you like because it's a free country (well, France and Norway are free countries anyway), but I can't let you say it's a "developer-centric SMF" that is not thought out for themers. I spent many, MANY months of my life working on the CSS preprocessor for Wedge. It's a work of art in itself. I may not be as good a designer as you are, but I certainly know what designers need to make their life easier. And you even agree yourself to a point -- recently you mentioned how SMF required of themers that they overwrite index.css to replace some stuff in it, and you pushed towards being able to add on top of it. Well, as you know it's a feature that's been in Wedge for over a year and a half now...
So, I'm simply asking of you to be fair to us. We really liked having you onboard. Just because you didn't feel comfortable not having any actual control over Wedge itself doesn't mean we disrespected you in any way. You're in the same position as everyone else but Pete and I... Had you joined the project on day one, it might have been different, but at that point we were already the two-headed entity that became known as Wedgeward and we locked everything for everyone, including our close friends like Dragooon or live627 (who will gradually get more power over Wedge).
We made Wedge because we weren't happy with SMF's direction and lack of commitment of its team, not because we hated the software as it was at the time. Effectively, we left because the SMF team was too narrow-minded per se, what you're accusing us of being. And you were part of the team at the time.
I'm just wondering... What does 'narrow-minded' mean to you? Someone who doesn't think your way?
(Shamelessly inspired from Eugène Labiche's "An egoist is someone who doesn't think about me.")
4672
Off-topic / Re: Doctor Who
« on August 9th, 2012, 11:27 AM »I am kinda pissed that they showed the wallpaper of the Doctor with Amy, kinda ruin the spoiler even in the trailer.
I don't know where I read that (or maybe I just imagined it?), but the Amy story had a different end in my mind...
It said her last foes were the Weeping Angels.
Which says to me, and this is definitely my imagination: it's the ideal way of getting rid of her in an emotional way... She (and probably Rory) will be beaten by them, and transported to an earlier era. The Doctor will then see them as old people. And then she'll say she waited all of her life to see him again. The Girl Who Waited. And then she passes away peacefully in a similar fashion to Blink. The end.
4673
Off-topic / Re: PHP IDE for windows
« on August 7th, 2012, 05:13 PM »
Well I'm probably worse FWIW, I actually didn't check, instead of visiting his profile I checked his IP and then compared it with a whois on his site... It took me 30 seconds or so, but it would have been immediate if I'd cared to click the profile link :lol:
4674
Off-topic / Re: PHP IDE for windows
« on August 7th, 2012, 04:47 PM »
Yeah, sure you like it, since you wrote it...
A hint for your next spam: don't register using an e-mail with the same domain as the one you're linking to! ::)
A hint for your next spam: don't register using an e-mail with the same domain as the one you're linking to! ::)
4675
Development blog / Re: Development, full speed ahead!
« on August 7th, 2012, 04:39 PM »
I'd like for the private alpha to be as short as possible, it's just there to ensure that the deployment process is working OK, so that we don't get too many support requests right now. I'm also considering asking TE not to release his converters to the public until Wedge hits final, so that people aren't too 'tempted' to convert their SMF forums to use Wedge before it's set as 'fully working'.
4676
Development blog / Re: Speeding up development
« on August 7th, 2012, 12:37 PM »
Oh, I never suggested going with what Aeva Media used to do, i.e. downloading its site list automatically and installing it transparently for the admin...
Well, I used to want to do that, but Pete reminded me that it's unlikely it's going to work for the forum code itself, as there are so many ways to screw that up ;)
I'm just saying that we should do away with our 'big' features which, to be honest, I'm too scared to try and implement because they might take so long to do, and instead go with a 'light' Wedge, which is already great enough as it is (even though it has nothing to do with our original vision). A bit of realism is required here... I keep holding off the release date because I want to have these features in and do something 'big', and because I couldn't see myself write some converter for database stuff, but at some point it struck me that whether it's now or later, we WILL have to write a converter for whatever we do like converting attachments to media items... That's just the way it is. So, we could simply include TE's converter inside the Wedge codebase and have it run upgrades transparently to the user whenever a manual update of files is done. And that means, getting rid of upgrade.php (which isn't updated or suitable to Wedge anyway), and instead have: (1) install.sql (which shall be updated every time the database is modified), (2) the internal upgrade script in the admin area, which will either (a) do changes incrementally with one upgrade function per new database change, or (b) let's be crazy (and unrealistic), analyze the install.sql and compare it to the current database, and apply any changes, although it doesn't help when it comes to doing conversion work not related to the database itself (which is why I'm saying it's unrealistic...)
On August 25, 2012, Wedge will already be two years old. I think it would be a good date to go alpha :) Probably private alpha, for now (private read access to the SVN to all our Friends). Using our custom Wedge license, which will remain in place at least until we go for a wide release. Then we'll go public alpha, then public beta, then RC.
After we go wide, we'll determine what our final license for Wedge 1.0 will be. (For those who didn't follow -- our current favorite is the Mozilla Public License v2.0 with Exhibit B, i.e. can't be sub-licensed to GPL, although we have no qualms with seeing redistributions of GPL code alongside our MPL code. Go ask the GPL guys, it's their problem :))
Well, I used to want to do that, but Pete reminded me that it's unlikely it's going to work for the forum code itself, as there are so many ways to screw that up ;)
I'm just saying that we should do away with our 'big' features which, to be honest, I'm too scared to try and implement because they might take so long to do, and instead go with a 'light' Wedge, which is already great enough as it is (even though it has nothing to do with our original vision). A bit of realism is required here... I keep holding off the release date because I want to have these features in and do something 'big', and because I couldn't see myself write some converter for database stuff, but at some point it struck me that whether it's now or later, we WILL have to write a converter for whatever we do like converting attachments to media items... That's just the way it is. So, we could simply include TE's converter inside the Wedge codebase and have it run upgrades transparently to the user whenever a manual update of files is done. And that means, getting rid of upgrade.php (which isn't updated or suitable to Wedge anyway), and instead have: (1) install.sql (which shall be updated every time the database is modified), (2) the internal upgrade script in the admin area, which will either (a) do changes incrementally with one upgrade function per new database change, or (b) let's be crazy (and unrealistic), analyze the install.sql and compare it to the current database, and apply any changes, although it doesn't help when it comes to doing conversion work not related to the database itself (which is why I'm saying it's unrealistic...)
On August 25, 2012, Wedge will already be two years old. I think it would be a good date to go alpha :) Probably private alpha, for now (private read access to the SVN to all our Friends). Using our custom Wedge license, which will remain in place at least until we go for a wide release. Then we'll go public alpha, then public beta, then RC.
After we go wide, we'll determine what our final license for Wedge 1.0 will be. (For those who didn't follow -- our current favorite is the Mozilla Public License v2.0 with Exhibit B, i.e. can't be sub-licensed to GPL, although we have no qualms with seeing redistributions of GPL code alongside our MPL code. Go ask the GPL guys, it's their problem :))
4677
Development blog / Re: Speeding up development
« on August 6th, 2012, 11:15 PM »
We didn't ditch it, I think... It was probably renamed to 'weVersion' or 'we_version' or even 'weVer'... Can't remember.
No, they don't have to figure out anything, they just need to reupload everything...? It's slower, but it's doable by anyone ahah...
My public report...
http://my.opera.com/desktopteam/blog/show.dml/51546052?startidx=250#comment94192592
It's definitely a bug on their side, but it also means that Opera will be buggy in SMF 2.0.x!
No, they don't have to figure out anything, they just need to reupload everything...? It's slower, but it's doable by anyone ahah...
My public report...
http://my.opera.com/desktopteam/blog/show.dml/51546052?startidx=250#comment94192592
It's definitely a bug on their side, but it also means that Opera will be buggy in SMF 2.0.x!
4678
Development blog / Re: Speeding up development
« on August 6th, 2012, 09:58 PM »PS: crap, another bug I just discovered... The selection is off by a few bytes when I click the Bold button in the bbc box, perhaps related to the Opera hack that I devised for editor.js... Maybe they FINALLY, after years, fixed that bug...?
4679
Development blog / Re: Speeding up development
« on August 6th, 2012, 09:57 PM »
So that'd be we_version..?
I'd like to use a SVN revision number for simplicity (for us!), since it'll be internal use anyway... (And I don't plan to do away with our SVN rev numbers, if you catch my drift :P)
I was thinking that we could disable the forum temporarily while upgrading. The script would only be run if the admin is online (and by the admin.)
There's bound to be a few minutes where things will go awry for everyone, which is logical considering one is updating their forum files manually by FTP... At some point there'll be a v1.0 file running alongside a v2.0 file, etc. Anyway, it's no biggie.
I'd like to use a SVN revision number for simplicity (for us!), since it'll be internal use anyway... (And I don't plan to do away with our SVN rev numbers, if you catch my drift :P)
I was thinking that we could disable the forum temporarily while upgrading. The script would only be run if the admin is online (and by the admin.)
There's bound to be a few minutes where things will go awry for everyone, which is logical considering one is updating their forum files manually by FTP... At some point there'll be a v1.0 file running alongside a v2.0 file, etc. Anyway, it's no biggie.
4680
Development blog / Development, full speed ahead!
« on August 6th, 2012, 06:38 PM »
Hey everyone! Long time no blog. Nope, none of us are dead... We just had 'things' happen in real life, which slowed everything down, sometimes to a halt. I made sure to have at least a couple of commits out every week, just so I never lose focus on what I'm planning to do, but it's true that I've had a tendency to focus on smaller details rather than the big picture.
The main point is that we've often gone through the same story: deciding to implement a minor feature that would be cool, and then realizing, weeks later, that we didn't realize that 'minor' doesn't mean 'quick to implement'... And it went on, and on. As a result, I myself became wary of starting the heavy-duty work on a number of 'heavy' features that I'd like to have in Wedge from day one[1], and I think if we keep it that way, we'll always have a good excuse not to release Wedge. Not that we're in a hurry to do it -- but we've got to keep it real, and part of it means we have to keep it real for users.
So, the reason why I'm so reluctant to go public is mainly the fact that it's hard to update the database once it's installed somewhere. If you don't tell people to use the upgrade script etc, then you're likely to get annoying support questions...
So here's what I'm suggesting: storing a $settings['db_version'] variable (or a variation if there's already an equivalent), and set it to the SVN revision number corresponding to the lastest database structure change. So, at runtime we can simply, as soon as we load $settings, check for the variable, and if it's lower than the current required database version, load an extra file that will automatically adjust the database structure. e.g. if the db_version is 1652, and user installs version 1815, Wedge will execute all database (and file structure) modifier functions located between those rev numbers -- db_update_1664, db_update_1727, etc... It should be easy to calculate, really, and we can safely call them, and then update db_version to the latest database version available. Then it wouldn't be (so) hard to change the database, whether for us or for users.
What do you think...?
PS: bugger, another issue I just discovered... The selection is off by a few bytes when I click the Bold button in the bbc box, perhaps related to the Opera hack that I wrote for editor.js in both SMF and Wedge... Maybe they FINALLY, after years, fixed that bug...? :edit: Yes, they did, but they didn't fix all of it, so I'll have to keep an eye open...
The main point is that we've often gone through the same story: deciding to implement a minor feature that would be cool, and then realizing, weeks later, that we didn't realize that 'minor' doesn't mean 'quick to implement'... And it went on, and on. As a result, I myself became wary of starting the heavy-duty work on a number of 'heavy' features that I'd like to have in Wedge from day one[1], and I think if we keep it that way, we'll always have a good excuse not to release Wedge. Not that we're in a hurry to do it -- but we've got to keep it real, and part of it means we have to keep it real for users.
So, the reason why I'm so reluctant to go public is mainly the fact that it's hard to update the database once it's installed somewhere. If you don't tell people to use the upgrade script etc, then you're likely to get annoying support questions...
So here's what I'm suggesting: storing a $settings['db_version'] variable (or a variation if there's already an equivalent), and set it to the SVN revision number corresponding to the lastest database structure change. So, at runtime we can simply, as soon as we load $settings, check for the variable, and if it's lower than the current required database version, load an extra file that will automatically adjust the database structure. e.g. if the db_version is 1652, and user installs version 1815, Wedge will execute all database (and file structure) modifier functions located between those rev numbers -- db_update_1664, db_update_1727, etc... It should be easy to calculate, really, and we can safely call them, and then update db_version to the latest database version available. Then it wouldn't be (so) hard to change the database, whether for us or for users.
What do you think...?
PS: bugger, another issue I just discovered... The selection is off by a few bytes when I click the Bold button in the bbc box, perhaps related to the Opera hack that I wrote for editor.js in both SMF and Wedge... Maybe they FINALLY, after years, fixed that bug...? :edit: Yes, they did, but they didn't fix all of it, so I'll have to keep an eye open...
| 1. | Custom boards, board types, custom groups, general privacy system, general tag system, attachments as media items, and so on... |