[jira] [Commented] (VELOCITY-919) Velocity is removing the Zero-Width space from the text
[
https://issues.apache.org/jira/browse/VELOCITY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921042#comment-16921042
]
Sanford Whiteman commented on VELOCITY-919:
---
Totally agree, was just saying the assertion in {{com.test.VelocityTestMain}}
was guaranteed to fail for other reasons. (I was looking at that while you were
confirming the actual bug!)
Comparing the _number_ of ZWSPs, for example, would've been a fairer (if overly
coarse) comparison.
> Velocity is removing the Zero-Width space from the text
> ---
>
> Key: VELOCITY-919
> URL: https://issues.apache.org/jira/browse/VELOCITY-919
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Rob van Dalen
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
> Attachments: TestVelocity.zip
>
>
> I am not sure if this is a bug but we have the following situation.
> We have a recognition application of recognizing text and decorating the text.
> When we putting the below input text to the application:
> *Input for the application:*
> {code:none}
> see art. 1 of the WW and then some other text
> {code}
> _Just before the text *art. 1* there is a Zero-Width space._
> The application will make the text like this:
> *Input for the VelocityEngine:*
> {code:none}
> see ${decorations[0]} and then some other text
> {code}
> _Just before the text *$\{decorations[0]}* there still is a Zero-Width space.
> because our application only changed *art.1 of the WW* into
> *$\{decorations[0]}*_
> When we put this text to the VelocityEngine together with the decoration
> template and a list of laws in the context, the engine is changing my text.
> It's removing the Zero-Width Space.
> Just before the VelocityEngine is using the text and the template,
> VelocityEngine is removing the Zer0-Width Space
> Velocity should only do some markup and not change the original input text.
> *decoration.vm:*
> {code:none}
> #set($decorations = [])
> #foreach($type in $annotationsMap.keySet())
> #foreach($citation in $annotationsMap.get($type))
> #set($hideAddResult = $decorations.add("##
> $citation##
> "))
> #end
> #end
> {code}
> This is a pace of Java code:
> {code:java}
> Path templateFile = TEMPLATE_FILE.toPath();
> VelocityEngine velocityEngine = new VelocityEngine();
> Path pathName = templateFile.getParent();
> velocityEngine.setProperty(FILE_RESOURCE_LOADER_PATH,
> pathName.toFile().getAbsolutePath());
> velocityEngine.init();
> Map> annotationsMap = getAnnotationsMap();
> StringBuilder templateStringBuilder = new StringBuilder("see
> \u200B${decorations[0]} and then some other text");
> templateStringBuilder.insert(0, "#parse(\"" + templateFile.getFileName() +
> "\")");
> VelocityContext context = new VelocityContext();
> context.put("escape", new EscapeTool());
> // annotationsMap is put in context as a whole, so that template script can
> decide what to do with different CitationTypes
> context.put("annotationsMap", annotationsMap);
> StringWriter writer = new StringWriter();
> velocityEngine.evaluate(context, writer,
> templateFile.getFileName().toString(), templateStringBuilder.toString());
> {code}
> The output of this application is:
> {code:html}
> see art. 1 of the WW and then some other text
> {code}
> But just before ** i expected the Zero-Width Space, but it's
> gone. So somewhere in the methode evaluate of the VelocityEngine this
> character is removed, because it's still present in the template text *"see
> $\{decorations[0]} and then some other text"*
> Please help.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-919) Velocity is removing the Zero-Width space from the text
[
https://issues.apache.org/jira/browse/VELOCITY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921032#comment-16921032
]
Sanford Whiteman commented on VELOCITY-919:
---
(OTOH, the original test case comparing VTL output to the expected String seems
off, no? The {{decoration.vm}} contains extra whitespace, which would always
make for different output.)
> Velocity is removing the Zero-Width space from the text
> ---
>
> Key: VELOCITY-919
> URL: https://issues.apache.org/jira/browse/VELOCITY-919
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.1
>Reporter: Rob van Dalen
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.2
>
> Attachments: TestVelocity.zip
>
>
> I am not sure if this is a bug but we have the following situation.
> We have a recognition application of recognizing text and decorating the text.
> When we putting the below input text to the application:
> *Input for the application:*
> {code:none}
> see art. 1 of the WW and then some other text
> {code}
> _Just before the text *art. 1* there is a Zero-Width space._
> The application will make the text like this:
> *Input for the VelocityEngine:*
> {code:none}
> see ${decorations[0]} and then some other text
> {code}
> _Just before the text *$\{decorations[0]}* there still is a Zero-Width space.
> because our application only changed *art.1 of the WW* into
> *$\{decorations[0]}*_
> When we put this text to the VelocityEngine together with the decoration
> template and a list of laws in the context, the engine is changing my text.
> It's removing the Zero-Width Space.
> Just before the VelocityEngine is using the text and the template,
> VelocityEngine is removing the Zer0-Width Space
> Velocity should only do some markup and not change the original input text.
> *decoration.vm:*
> {code:none}
> #set($decorations = [])
> #foreach($type in $annotationsMap.keySet())
> #foreach($citation in $annotationsMap.get($type))
> #set($hideAddResult = $decorations.add("##
> $citation##
> "))
> #end
> #end
> {code}
> This is a pace of Java code:
> {code:java}
> Path templateFile = TEMPLATE_FILE.toPath();
> VelocityEngine velocityEngine = new VelocityEngine();
> Path pathName = templateFile.getParent();
> velocityEngine.setProperty(FILE_RESOURCE_LOADER_PATH,
> pathName.toFile().getAbsolutePath());
> velocityEngine.init();
> Map> annotationsMap = getAnnotationsMap();
> StringBuilder templateStringBuilder = new StringBuilder("see
> \u200B${decorations[0]} and then some other text");
> templateStringBuilder.insert(0, "#parse(\"" + templateFile.getFileName() +
> "\")");
> VelocityContext context = new VelocityContext();
> context.put("escape", new EscapeTool());
> // annotationsMap is put in context as a whole, so that template script can
> decide what to do with different CitationTypes
> context.put("annotationsMap", annotationsMap);
> StringWriter writer = new StringWriter();
> velocityEngine.evaluate(context, writer,
> templateFile.getFileName().toString(), templateStringBuilder.toString());
> {code}
> The output of this application is:
> {code:html}
> see art. 1 of the WW and then some other text
> {code}
> But just before ** i expected the Zero-Width Space, but it's
> gone. So somewhere in the methode evaluate of the VelocityEngine this
> character is removed, because it's still present in the template text *"see
> $\{decorations[0]} and then some other text"*
> Please help.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854935#comment-16854935
]
Sanford Whiteman edited comment on VELTOOLS-182 at 6/4/19 7:44 AM:
---
Yes, it's quite bad!
Why not delegate entirely to Java instead? This method is to avoid running a
sort proper against the collection, since it only needs a single return value,
right? Which I understand for large collections, but does this represent
real-world use? (I don't know, I personally never try to get the max of 2-3
user/system/default environment variables.)
was (Author: swhiteman):
Yes, it's quite bad!
Why not delegate entirely to Java instead? This method is to avoid running a
sort proper against the collection, since it only needs a single return value,
right? Which I understand for large collections, but does this represent
real-world use? (I don't know, I personally never try to get the max of 2-3
user/system/default environment variables.)
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Priority: Major
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.max(0)}} (just one arg) but at least that could be
> considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanford Whiteman updated VELTOOLS-182:
--
Description:
It appears that {{$math.max}} has had a bug since at least 2.0, or at least I'm
at a loss as to why the observed behavior would be expected, and it doesn't
appear to be documented.
{code:java}
$math.max(0,0) {code}
returns
{code:java}
4.9E-324{code}
that is, Double.MIN_VALUE.
It's easy to see why in the source. Using
[3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
here, we see:
{code:java}
public Number max(Object... nums)
{
double value = Double.MIN_VALUE;
Number[] ns = new Number[nums.length];
for (int i=0; ihttps://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
here, we see:
{code:java}
public Number max(Object... nums)
{
double value = Double.MIN_VALUE;
Number[] ns = new Number[nums.length];
for (int i=0; i MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Priority: Major
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.max(0)}} (just one arg) but at least that could be
> considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855279#comment-16855279
]
Sanford Whiteman commented on VELTOOLS-182:
---
Sure, that approach LGTM.
({{Arrays.stream().mapToDouble()}} though, right?)
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Priority: Major
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.min(0)}} (just one arg) but at least that could be
> considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854935#comment-16854935
]
Sanford Whiteman commented on VELTOOLS-182:
---
Yes, it's quite bad!
Why not delegate entirely to Java instead? This method is to avoid running a
sort proper against the collection, since it only needs a single return value,
right? Which I understand for large collections, but does this represent
real-world use? (I don't know, I personally never try to get the max of 2-3
user/system/default environment variables.)
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Priority: Major
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.min(0)}} (just one arg) but at least that could be
> considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
Sanford Whiteman created VELTOOLS-182:
-
Summary: MathTool.max longtime bug with args (0,0)
Key: VELTOOLS-182
URL: https://issues.apache.org/jira/browse/VELTOOLS-182
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Sanford Whiteman
It appears that {{$math.max}} has had a bug since at least 2.0, or at least I'm
at a loss as to why the observed behavior would be expected, and it doesn't
appear to be documented.
{code:java}
$math.max(0,0) {code}
returns
{code:java}
4.9E-324{code}
that is, Double.MIN_VALUE.
It's easy to see why in the source. Using
[3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
here, we see:
{code:java}
public Number max(Object... nums)
{
double value = Double.MIN_VALUE;
Number[] ns = new Number[nums.length];
for (int i=0; i
