July 26, 2009 at 1:14 am
I created a not so large chunk of code and posted it to the code window. Now, that post doesn't work because the script that colorizes the code window either went into an endless loop or it just can't handle the code and takes forever to finish colorizing.
The post is located at the following URL. [font="Arial Black"]If you good folks could delete my last post and then let me know, I can post the code a different way. [/font] Thanks...
http://www.sqlservercentral.com/Forums/Topic457120-19-1.aspx
I don't believe I'll be using the code windows anymore... they're just too unpredictable. I really don't have the time to not use the code windows but I sure don't have the time to go through another hour like I just did the last one.
It sure would be nice if you could get the code windows to work in a reliable fashion.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 26, 2009 at 1:15 am
I almost forgot... yes, I'm using IE.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 26, 2009 at 8:34 am
oh no wonder... I was not able to open that post.
July 26, 2009 at 10:10 am
yeah i saw that...IE spins forever. tried with firefox, and after a couple of "do you want to stop the runaway script" warnings, it would finally open. at least from there it would be editable, if you care to grab firefox.
Lowell
July 26, 2009 at 10:36 am
Lowell (7/26/2009)
yeah i saw that...IE spins forever. tried with firefox, and after a couple of "do you want to stop the runaway script" warnings, it would finally open. at least from there it would be editable, if you care to grab firefox.
Thanks, Lowell... but we shouldn't have to do that kind of stuff. What I'd really like for them to do is either go back to the "old" purple code windows which were working just fine except for the occasional smiley face or fix the current colorized code windows so that they actually work correctly. They've been at it for months and still haven't been able to pull it off. It's not only taking a lot of their time, but it costs folks like me a fair bit of time to make sure the work correctly each and every time. Last night, between writing messages to folks to alert them of the problems and trying to figure out what happened, it cost be about an hour just for that one post. That's so counter-productive.
I don't know about other folks... I like my code to not only look nice, but I also want it so that someone can copy and paste it from this forum to their machine without any format changes occuring or any long waits, etc, etc. I'm going back to my old ways... screw the color... the format and the function are what it's all about. The "new" code windows have been contradicting that since their inception.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 26, 2009 at 11:22 am
I know exactly what you mean.
I post here because it gives me personal satisfaction to help someone else out. It's a huge advantage to their learning curve for us to present copy-and-paste-able code that references the tables/objects they ask about. when they see code referencing their stuff, they understand it much better than an abstract example that they have to try to adapt.
I agree with you, the color coding gets too deep for javascript to handle properly after a certain point.
simplifying the code windows so they don't syntax color everything they can think of, and maybe a much smaller subset of the keywords would probably help.
Lowell
July 28, 2009 at 3:39 am
Hi,
I've edited the post to temporarily fix it, without deleting it. Essentially, if you want 'simple' blocks, with no code formatting, rather than surrounding your code with a
[ c o d e = "s q l" ]
tag, use a
<pre>
tag.
Mel HarbourProject ManagerRed Gate Software
July 28, 2009 at 6:28 am
Mel Harbour (7/28/2009)
Hi,I've edited the post to temporarily fix it, without deleting it. Essentially, if you want 'simple' blocks, with no code formatting, rather than surrounding your code with a
[ c o d e = "s q l" ]
tag, use a
<pre>
tag.
Ok and thanks, but you're missing the point... the code blocks do not work correctly and can easily be overwhelmed to cause this problem on other threads quite by mistake. Go to the Prime Number contest thread currently on the home page and see. Every post makes it slower and slow and it's now giving errors when someone tries to post in IE.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2009 at 6:33 am
Jeff,
Don't worry - I do understand the slightly larger problem, and we're looking into what we can do to fix it in general, or find a nice compromise position. Essentially a small scale fix was deployed, using a third party script, a version of http://code.google.com/p/syntaxhighlighter/
As is becoming apparent, that script doesn't seem to be the right thing for what people are doing with it.
Mel
Mel HarbourProject ManagerRed Gate Software
July 28, 2009 at 6:41 am
As a further note, what we will probably try and do is start again from the ground up, but beginning with a home grown solution. Start out with it being really simple, and only expand forwards if it's really needed, or when problems are exposed.
One fundamental question we need to decide on architecturally though is how we write it. At the moment it's all done in JavaScript. We could adopt the same model. Alternatively, to give us a bit more power, we could implement the code formatter as a web service that the JavaScript could call out to in order to do the real 'heavy lifting' (this may be necessary if we want it to do anything resembling a partial parse of the code). It depends on how involved we want to make the script.
Mel
Mel HarbourProject ManagerRed Gate Software
July 28, 2009 at 10:46 am
Mel Harbour (7/28/2009)
Jeff,Don't worry - I do understand the slightly larger problem, and we're looking into what we can do to fix it in general, or find a nice compromise position. Essentially a small scale fix was deployed, using a third party script, a version of http://code.google.com/p/syntaxhighlighter/
As is becoming apparent, that script doesn't seem to be the right thing for what people are doing with it.
Mel
Heh... thanks for the link, Mel. I checked the detail especially where they talk about "performance". It says...
[font="Arial Black"]Performance[/font]
SyntaxHighlighter uses regular expressions to parse the text. It's not extremely fast, in fact, it's pretty slow. If you are trying to highlight a few dozens lines of code, you won't see any problems. Trying to highlight 10kb worth of text will result in JavaScript being aborted because of long execution time.
As a fellow truly concerned with the greatness of SQL Server Central, my suggestion would be to drop that code like a red hot potato and go back to the simple ol' light purple code windows we used to have. I'll put up with the occasional smiley face and I believe you'll make everyone a lot happier because of the speed those old code windows had. And trust me... from what I've seen, it doesn't take 10KB to make the current code crash and burn for IE users. I've also got some indications that it's also causing a pretty good slowdown even for FireFox.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2009 at 10:51 am
As I say, I think that's probably what we'll wind up doing, and then looking to start building it back up again, but working at a decent speed.
Aside from the speed, their use of Regexs in JavaScript means that some of the things that would be needed to actually do a good job are simply not possible. JavaScript doesn't have some parts of the Regex syntax that you really need, hence why a really slick solution would probably need to run server side, or as a web service.
Mel
Mel HarbourProject ManagerRed Gate Software
July 28, 2009 at 10:52 am
BTW, thanks for fixing the post for me. You can just bet I'll be using the "pre" code until you good folks have a chance to wittle on the code windows as they currently stand. I just hope that no one else posts "large" code or your team will end up spending a lot of time fixing threads that will no longer load like mine did.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2009 at 10:59 am
Just testing for smileys in the "pre" code...
SELECT 1; SELECT (1); SELECT ( 1 ) SELECT ( 1 ); SELECT ( 1 ) ; ) ;) );
Heh... ironically, you guys finally fixed the purple code windows by changing the codes for smiley faces a while back... the occasional aberrant smiley no longer shows up. My recommendation stands... drop the script that colorizes stuff and go back to these nice, simple code windows. Thanks for listening.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 28, 2009 at 11:02 am
Just testing for smileys in the "pre" code...
SELECT 1; SELECT (1); SELECT ( 1 ) SELECT ( 1 ); SELECT ( 1 ) ; ) ;) );
Heh... ironically, you guys finally fixed the purple code windows by changing the codes for smiley faces a while back... the occasional aberrant smiley no longer shows up. My recommendation stands... drop the script that colorizes stuff and go back to these nice, simple code windows. The only bad part about the bloody things is the same problem they had before... in order to keep the code from coming out on all one line, you have to paste the code into Word and then you can paste it into QA with the approriate line breaks intact. Thanks for listening.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply