I've seen the following code (A list of ip addresses that need debugging) for Application.cfc:
<!---seen in blogs and perhaps earlier versions of CF documentation, livedocs isn't working for CF 7 & 8 for me tonight--->
<cfset this.debugipaddress = "192.168.1.15,192.168.1.27">
and
<!--- documented in CF 9 & 10--->
<cfset this.debuggingIPAddresses = "192.168.1.15,192.168.1.27">
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-750b.html
http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-750b.html
I was wondering if there was a difference between the two variables? I'm using ColdFusion 10, is one preferred over the other if they are the same? Perhaps this.debugipaddress was deprecated?
From what I can find it is a documentation bug. According to Ray Camden's blog and the comments in it, it should be debuggingipaddresses not debugipaddress. Ray also used it here and pointed out that there was a correction.
Pretty standard and he appears to have nailed everything. A part of me
strongly wishes that Ben Forta would have never used UPPERCASE scope
names in the WACK books so that my eyes wouldn't have to bleed every
time I see someone else do that, but oh well :). One minor correction
- this.debugipaddress is actually this.debuggingipaddresses (see here) - no points deducted for that since it's a doc bug. I also would have liked to have seen him mention the struct keys for smtpServerSettings
({server="",username="",password=""}).
Related
As always, naming things is hard.
Power Query Formula Language is long
M is short
Is there a nice middle ground or are we sticking with 'M'?
For example, there might be conflicts when it comes to creating things like Syntax Highlighting packages in Sublime Text... m.tmTheme. An example of someone who changed name at v1. Or are we happy with powerqueryformulalanguage.thTheme.
I know this question might be flagged as subjective, but seriously, it is early days so hopefully soon it is an easy answer.
BTW What tags do I use for this question?? :/
m - The M Modelling Language was a component of Microsoft's "Oslo" project, later known as SQL Server Modeling CTP. The project was canceled in late 2010.
powerqueryformulalanguage - does not exist...
Not too happy with the short M as well, but:
1) Power Query will be called Get&Transform from Excel 2016 onwards, so might die out as a name as well
2) R delivers acceptable search results by now
How about M# as an alternative? (As the # already sneaks into the stepnames...)
Re the editor: You can find an improved version with IntelliSense and Parameter hints here: http://power-bi-usergroup.blogspot.de/2015/11/creating-editor-for-power-query-with.html?utm_source=hootsuite&m=1
I think M is for 'Mashup'! Microsoft's language specification document alludes to this, but doesn't state it explicitly:
https://learn.microsoft.com/en-us/powerquery-m/power-query-m-language-specification
I don't think the marketing team were going to let that through though...
I'm creating a simple editor in Mac OS X and I've come to the point where my editor needs to do some highlighting of code, for example, comments.
I am using Regex to find all comments, which I initially thought, was slow. Turns out, it does rather amazing job. For example, for 387 comments, regex needs "only" 0.008404 s to find them and returns array of NSRanges.
But here comes disaster. When I try to set different color to my text with method setTextColor:range: it completes very slow. It needs additional 9.872964 s (for those 387 comments I mentioned before) and it gets worse really fast when number of comments is increased.
So... Is there any way to do this faster? With NSAttributedStrings, perhaps?
I'm really sorry guys, but stackoverflow gave me suggestion on similar question (which I didn't found when I was searching).
It turns out you simply have to tell NSTextViews TextStorage that you will begin doing some editing. And when you finish, you commit those changes. Code looks like:
[textView.textStorage beginEditing];
// do some stuff here
[textview.textStorage endEditing];
Now I ran code with 456 comments, Regex needed 0.013887 s and coloring 0.215761 s, which is amazing drop!
Anyway, I hope someone will find that useful.
How do you make a list double spaced and continue the number? For example
This
Shouldn't
Be
Hard
If I add a line break then the numbering restarts from 1 again. Is there a way to make a whole numbered list double spaced or at least manually add some line breaks without resetting the count?
What is the point of wiki markup, why not just use HTML? It's at least as simple, if not more.
This works for me with Trac-1.0.1:
1. This [[BR]][[BR]]
1. Shouldn't [[BR]][[BR]]
1. Be [[BR]][[BR]]
1. Hard
I think it's because wiki markup is platform-, browser- and version-independent.
Complementing falkb's valuable answer on the first two of your three questions here are some words on Wiki markup:
I strongly disagree on your notion ('why not just use HTML?'), even more after being switched forcefully from Trac to a MS SharePoint business application. Me personal experience is:
Wiki markup is
simpler (and rather figurative/intuitive)
allows higher typing rate
easiler reviewable
faster to copy-n-paste and adapt
compared to equivalent HTML markup.
Most often used features like headings and list markup are a good example - very few extra characters in Wiki, just one additional char to add/remove for making a 2nd level a 3rd level heading. After I got a grip on Trac wiki markup syntax I started making plaintext notes outside of Trac's wiki editor in the same style too for clear text structur with minimal effort.
I'm seeing a difference in how HTMLEditFormat works in CF9 and CF10.
HTMLEditFormat(">")
In CF9: showing up as ">" (no difference)
In CF10: showing up as ">" (double-escaped, which seems correct to me)
I've looked through the CF10 notes and reviewed the HTMLEditFormat documentation, but cannot find any mention of there being a difference in how this function works. Does anyone know of a difference, or know of documentation that proves there is no difference? ...Or know of any other settings (ColdFusion or web server) that might cause this to work different?
(This question is not a duplicate because am not asking about encodeForHTML. I understand that is the ideal solution, but am asking to understand why HTMLEditFormat might be different in CF9 vs. CF10.)
I can't imagine why that function would behave differently. Especially when it's was planned for deprecation going into CF 10. By chance, are you calling it from within a CFINPUT tag?
<cfinput id="foo" value="#htmlEditFormat(someValue)#" />
If so, in CF6 - CF9, that tag uses HTMLEditFormat() on values automatically. Calling a 2nd instance of HTMLEditFormat() doesn't affect the output. But CF 10+ updated the tag to use encodeForHTML() on values. If you also throw in an HTMLEditFormat(), then you're double-encoding the output.
For better security, you should stop using HTMLEditFormat() and start using encodeForHTML() if it's available (CF10+). As of ColdFusion 11, HTMLEditFormat() has been officially deprecated and by ColdFusion 12, the function should be removed completely.
HTMLEditFormat() only encodes 4 characters: <, >, &, ".
encodeForHTML() encodes almost every character, including UTF-8 characters. The updated "encodeFor" functions are contextual, so you have to pick the right on for the right context (html, htmlattribute, js, css, xml, etc.).
I have a fairly long cfc file, about 1800 lines long, that worked fine in ColdFusion 8, but after upgrading my development system to ColdFusion 9 and doing some testing I get a compile error for a cfc and the message says "Branch target offset too large for short". I modified the file to eliminate some unused functions and consolidated one to make it shorter and this resolved the problem to get it to work. But still, why did it die on me now when I upgraded to CF9? Anyone else run into this problem in previous or the current version of ColdFusion? Are there any solutions other than modifying the cfc file such as upgrading the jvm?
EDIT
If you have an answer to the questions I have, great! Post that, but don't waste time telling me something that I already know. If you are going to post a response, please read the question carefully and answer only if you know the answer. Don't do a google search and post crap that I already know and utilized to get the code to work. The question is, why did it work in CF8 and now not in CF9? Are there other solutions besides what I did?
This is a problem inherent with the JVM as you already know, CF9 has likely added more innate functions to a component and if the methods are all referenced via a giant switch statement with a short being used as the offset, we have less offset pointer space to work with each successive version. People moving from CF7 to CF8 also had the same problems.
So short answer is no.
Most recommendations you find basically tell you to split a large method into a smaller method and several helper methods. The first time I ran into an issue this worked for a large cfc I had. But then as it got bigger no number of helper functions would fix it. Eventually it had to be split into multiple cfcs.
PS: This guy said removing a transaction helped (CF7), there are none wrapping my calls though, so it's not a guaranteed fix I guess http://www.coldfusionmuse.com/index.cfm/2007/9/28/Branch.Target.Offset
Edit
Looks like my previous issue was a different function being too large, splitting the CFC into multiple CFCs was in error. I've since split that problem method into smaller methods, and have been able to consolidate all the functions in one CFC. So that is the solution it seems.
If you haven't already, try running the Code Analyzer in the CFAdmin page, "Debugging & Logging > Code Analyzer". This is a useful tool to find some changes which were made in the language between CF8 and CF9.
We had to change several variable names and function names as CF added them in 9.
Also check here:
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7ff0.html
CF version: 10
OS: Linux CentOS 6.0
Did face a similar issue where I had 1300+ lines of code in my cfc and one fine day I get the "Branch Target offset.." error. I tried
Code Analyser to find any loopholes of legacy- DID NOT FIX
Edited the cfc to trim down any last bit of redundant code or comments - reduced around 20+ lines of code - DID NOT FIX
I split the code into 2 cfc and extended one to the other- DID NOT FIX
I removed any unwanted dump of queries and arrays (part of testing) : THIS WORKED
so I would suggest ensure you don't have any dumps of large data content. Hope this helps.