IsDebugMode

[theprophecy]

There seems to be a difference in the way IsDebugMode() behaves on Lucee 4.5.1 vs ACF. It essentially does nothing but reflect the radio button in the admin's debugging.settings page; it returns true at all times even if the request is not one that receives debug output. Given that radio button being set to Yes,

• IsDebugMode() if your IP is not in the administrator console's debugging list: ACF false / Lucee true
• IsDebugMode() if <cfsetting showdebugoutput=false>: ACF false / Lucee true

Is this by design? Has anyone else encountered this and cared enough to find a workaround? (For those wondering, the reason I care is that I have my error handler set to show me the "real" exception data instead of a customer-friendly message when IsDebugMode(), a method which will no longer work after migrating to Lucee.)

[Andrew Dixon]

Hi,

Sounds like a bug to me, please raise an issue on the issue tracker:

https://luceeserver.atlassian.net

Kind regards,

Andrew

about.me - mso - Lucee Association Member

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/0379a286-a0d7-4454-97cf-44b903475d6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

In my opinion this is a bug in ACF, the function name is "IsDebugMode" what you only can enable in the admin, what you control with the tag cfsetting is "showDebugOutput", so only if the debug output is shown or not. we could consider a function names "isDebugShown". But if "isDebugMode" is set to true, Lucee is logging the debug information in any case and you can see it in the admin, so again "cfsetting-showDebugOutput" has no influence on the debug mode.

Micha

--

[theprophecy]

There's value in maintaining compatibility with ACF, but beyond that the name could be whatever you want.

The name of the function notwithstanding, the functionality in ACF is useful in a wider range of scenarios; the limited functionality currently in Lucee has a very narrow use case. That lost functionality is the reason I brought it up. Whatever form it comes back in would be great.

[Michael Offner]

In some times we decide against a compatibility to ACF, because we see a functionality in ACF as a bug and not as a feature.

So the question for is not only "is this a bug", it is also "what behaviour is the best for the community".

Interesting is the doc for this function with ACF:

"If debugging output is enabled in ColdFusion Administrator and has not been overridden by setting the cfsettingtag showDebugOutput attribute to No, the IsDebugMode function returns Yes; No, otherwise."

So it does matches the functionality but the definition of "return" is matching our implementation.

"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if debugging mode is disabled."

so it is unclear at best, one other way to do it would be, to match the ACF functionality but mark this function as deprecated and add one that is more precise in the functionality.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/03cad62e-fece-45c3-a8c6-738fe76ddfbb%40googlegroups.com.

[Adam Cameron]

On Monday, 15 June 2015 08:22:07 UTC+1, Micha wrote:

In some times we decide against a compatibility to ACF, because we see a functionality in ACF as a bug and not as a feature.

If you were to be honest: is that what happened here, or did you just make incorrect assumptions when implementing it, and got it slightly wrong? (which surely is in the "hey: shit happens" category).

 

So the question for is not only "is this a bug", it is also "what behaviour is the best for the community".

Your current implementation doesn't value-add anything. However it *does* cause a real-world cross compat issue. So the net worth of this variation is a negative one.

If you want to vary the behaviour of this: vary it on .lucee to your heart's content.

 

Interesting is the doc for this function with ACF:

"If debugging output is enabled in ColdFusion Administrator and has not been overridden by setting the cfsettingtag showDebugOutput attribute to No, the IsDebugMode function returns Yes; No, otherwise."

So it does matches the functionality but the definition of "return" is matching our implementation.

Huh? (I mean "I don't understand what you have written there"). CF does exactly what it says in the docs you quote above. Lucee - apparently - does not.

 

"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if debugging mode is disabled."

so it is unclear at best,

No, at best it does exactly what it claims to do, although the wording could stand improvement.

It's only if you read a latter statement without the context of the previous statement that your can claim it's unclear. Which is a bit of contortion of how ppl usually go about things.

Basically you seem to be engaging in apologetics to justify (only to yourself, I think) why you didn't implement the function as per ColdFusion's specification (such as it is).

Look: there's nothing wrong with having an implementation glitch. But increasingly you (singular. I mean "Micha") are twisting about the place trying to justify why you're actually right when - in reality - the conversation is only taking place because you made a mistake at some point.

The problem here resides solely in Lucee and in your head, I'm afraid.

 

one other way to do it would be, to match the ACF functionality but mark this function as deprecated and add one that is more precise in the functionality

To me that is kinda adding more language clutter for no good reason.

You're quibbling over the notion of "debug mode" and ascribing it a precise definition that the inventors of the platform & language in question clearly didn't mean. It's a slightly clumsy function name, but it's not like it's the only clumsy function name in CFML. However it's behaviour makes sense in the context of the description in the docs. Which have been the same for over a decade.

No-one gains anything from adding a similar-named function which does something pretty much the same thing. That's how PHP would "solve" a problem.

You have your own language to "improve" in the .lucee thing, so perhaps just fix the situation their, and don't mess with CFML in such a way that just leave the language slightly worse off.

-- 

Adam

[Adam Cameron]

On Monday, 15 June 2015 08:46:46 UTC+1, Adam Cameron wrote:

 

Interesting is the doc for this function with ACF:

"If debugging output is enabled in ColdFusion Administrator and has not been overridden by setting the cfsettingtag showDebugOutput attribute to No, the IsDebugMode function returns Yes; No, otherwise."

"Returns

True, if debugging mode is set in the ColdFusion Administrator; False if debugging mode is disabled."

so it is unclear at best,

I have, btw, clarified the ColdFusion docs for isDebugMode(). It now reads:

Description

Determines whether debugging output will be displayed.

Returns

"Yes", if debugging information will be output; otherwise "No".

Usage

If debugging output is enabled in ColdFusion Administrator either globally or for the current machine's IP address and has not been overridden by setting the cfsetting tag showDebugOutput attribute to No, the IsDebugModefunction returns Yes; No, otherwise.

I've varied the "Description" and "Returns" sections to make them less vague / ambiguous.

-- 

Adam

[Michael Offner]

Until today I was not aware that there is a differents between Railo/Lucee and ACF, but now that we know we need to decide what is the best for the future. I just tried to point out what is important for us to make the best decision.

Micha

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/a1563bb6-dd8b-44bb-8612-2865a6582379%40googlegroups.com.

[Adam Cameron]

On Monday, 15 June 2015 09:10:07 UTC+1, Micha wrote:

I just tried to point out what is important for us to make the best decision.

No, Micha, that wasn't all you were doing. Most of what you wrote was trying to justify yourself.

now that we know we need to decide what is the best for the future.

OK. So if we limit this discussion to "what's best for the future",my suggestions would be:

For CFML

Follow Adobe's precedent. There's no gain to be had in making a variation here. So I guess a bug should be raised (if one hasn't been already).

For .lucee

You make a *reasonable* point that the naming of the function might be misleading. I'm not sure if this is a function-naming thing or just a documentation. thing though. Honest question: does my revision of the docs for ColdFusion's isDebugMode() remove the perceived lack of clarity? Is that perhaps the path of least possible work here?

Going even further... perhaps a better API could be exposed for debug-setting-management, eg a DebugService class which both reflects current settings, as well as lets one with appropriate credentials to modify them? I suppose the CFADminAPI has this already (does Lucee have that? Never checked), but the API is a very clumsy one. It could simply be something like:

DebugService.isDebugEnabled()

DebugService.isDebugOutputEnabled()

DebugService.getDebugIpAddresses()

etc

Moving from headless functions to a more OO approach would be a good thing, perhaps?

-- 

Adam

[Michael Offner]

It is always nice you know my intention better than I do, I always assumed that is my wife's job.

I agree on your approach about how we should handle this, of course moving away from functions to objects with methods is a general decision that is worth thinking about it (lang.lucee.org).

Micha

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3cd2afd6-3923-49fc-a9ee-4e835d638338%40googlegroups.com.

[Adam Cameron]

On Monday, 15 June 2015 09:33:11 UTC+1, Micha wrote:

It is always nice you know my intention better than I do, I always assumed that is my wife's job.

No special spousal telepathy needed, honey ;-)

I just read what you write. It's easier that way.

What do you want for dinner tonight, btw?

-- 

Adam

xxx

[ADK]

Not to hijack the thread, but I'm still unsure what the vision is here for the multiple dialects for Lucee? So I get that we're going to have the "new" dialect which breaks from ACF but is still based upon it (perhaps a "cousin"?) but Micha has also stated that CFML compat is still vitally important to the Lucee project and so we will always have the "CFML compatibility dialect" ... but we'll still have incompats within that: those that have been brought over from Railo days and then new ones too? Doesn't that then give us 2 divergent, not wholly compatible dialects?

It would be really helpful to get an official, clear, concise document on what the vision for this language is moving forward. I think this would go a long way to helping a lot of us understand what's going on behind the scenes and would provide better context for us to comment on threads like this very one.

[Michael Offner]

i like it burnt like my wife does ;-)

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/615c9544-9475-4cd0-b2fe-4d184e149d01%40googlegroups.com.

[Michael Offner]

yeah with introduction of the Lucee dialect the position of the CFML dialect also change, compatibilty to ACF get even more important. but that does not mean we will follow every stupidity behaviour ACF has on every price without thinking about it.

Best example is passing arrays to functions "by value", as long i have something to say Lucee will never follow that behaviour in the CFML dialect, even we have an incompatibility here. but like i pointed out before in this thread:

So the question for is not only "is this a bug", it is also "what behaviour is the best for the community".

For me the answer here is very clear, that acf behaviour is not in the interest of the community, because ACF clones ALWAYS any array that is passed to a function or comes back from a function what of course slow down the process in 99.9..% of the cases for no reason.

in that case i agree that we should follow ACF on this, even i was first thinking that this is a bug in ACF, but even it is it will not affect the majority of the users anyway. 

So compatibility yes, but not at any price

Micha

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/eba9ab58-1c36-4a15-9f4d-8ca90de9cd72%40googlegroups.com.

[Adam Cameron]

On Monday, 15 June 2015 09:40:28 UTC+1, Micha wrote:

i like it burnt like my wife does ;-)

As we will no-doubt be (deservedly) burning in hell after this conversation, this should be easily achievable.

See you tonight.

-- 

Adam