[jira] [Commented] (IMAGING-355) Large animated GIF takes too much heap memory in getMetadata
[
https://issues.apache.org/jira/browse/IMAGING-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741336#comment-17741336
]
Andrew Khoury commented on IMAGING-355:
---
Thanks, here is the PR https://github.com/apache/commons-imaging/pull/301
> Large animated GIF takes too much heap memory in getMetadata
>
>
> Key: IMAGING-355
> URL: https://issues.apache.org/jira/browse/IMAGING-355
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: GIF
>Affects Versions: 1.0-alpha3
>Reporter: Andrew Khoury
>Priority: Major
> Attachments: commons-imaging-test.gif,
> image-2023-06-29-15-18-17-076.png, screenshot-1.png
>
>
> When calling ImageParser.getMetadata on large animated gif files, the java
> heap consumption is extremely high.
> For example, see the test project I created:
> [https://github.com/andrewmkhoury/commons-imaging-gif-test]
> When calling ImageParser.getMetadata on the attached 5MB gif
> [^commons-imaging-test.gif], it uses ~1.5GB of heap space. When the max heap
> is set to -Xmx1488M or lower it fails with this exception. When the heap is
> set to -Xmx1489M it works.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
> at
> java.base/java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:211)
> at
> org.apache.commons.imaging.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:143)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:881)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:596)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:696)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:680)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata(GifImageParser.java:485)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata(GifImageParser.java:58)
> at
> org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:832)
> at Test.main(Test.java:28)
> {code}
> To generate the large gif file I did the following:
> 1. Install ffmpeg and gifsicle
> 2. Use quicktime to create a screen recording
> 3. Generate a gif out of the screen recording
> {code:bash}
> ffmpeg -i ~/Desktop/Screen\ Recording\ 2023-06-29\ at\ 12.09.21\ PM.mov
> -pix_fmt rgb8 -r 10 commons-imaging-test.gif && gifsicle -O3
> commons-imaging-test.gif -o commons-imaging-test.gif
> {code}
> To run the test program:
> {code:bash}
> git clone g...@github.com:andrewmkhoury/commons-imaging-gif-test.git
> cd commons-imaging-gif-test
> mvn assembly:assembly
> java -Xmx1g -jar target/IMAGING-test-0.0.1-SNAPSHOT-jar-with-dependencies.jar
> commons-imaging-test.gif{code}
> Heap analysis via Eclipse MAT shows that the ImageDescriptor.imageData
> storing the bytes of each frame is the cause of the problem:
> !image-2023-06-29-15-18-17-076.png|width=169,height=93!!screenshot-1.png|width=226,height=86!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-355) Large animated GIF takes too much heap memory in getMetadata
[
https://issues.apache.org/jira/browse/IMAGING-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741335#comment-17741335
]
Gary D. Gregory commented on IMAGING-355:
-
Hi [~akhoury],
Thank you for the update.
Would you please create a PR? This will show us if there are any side-effects.
TY.
> Large animated GIF takes too much heap memory in getMetadata
>
>
> Key: IMAGING-355
> URL: https://issues.apache.org/jira/browse/IMAGING-355
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: GIF
>Affects Versions: 1.0-alpha3
>Reporter: Andrew Khoury
>Priority: Major
> Attachments: commons-imaging-test.gif,
> image-2023-06-29-15-18-17-076.png, screenshot-1.png
>
>
> When calling ImageParser.getMetadata on large animated gif files, the java
> heap consumption is extremely high.
> For example, see the test project I created:
> [https://github.com/andrewmkhoury/commons-imaging-gif-test]
> When calling ImageParser.getMetadata on the attached 5MB gif
> [^commons-imaging-test.gif], it uses ~1.5GB of heap space. When the max heap
> is set to -Xmx1488M or lower it fails with this exception. When the heap is
> set to -Xmx1489M it works.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
> at
> java.base/java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:211)
> at
> org.apache.commons.imaging.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:143)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:881)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:596)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:696)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:680)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata(GifImageParser.java:485)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata(GifImageParser.java:58)
> at
> org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:832)
> at Test.main(Test.java:28)
> {code}
> To generate the large gif file I did the following:
> 1. Install ffmpeg and gifsicle
> 2. Use quicktime to create a screen recording
> 3. Generate a gif out of the screen recording
> {code:bash}
> ffmpeg -i ~/Desktop/Screen\ Recording\ 2023-06-29\ at\ 12.09.21\ PM.mov
> -pix_fmt rgb8 -r 10 commons-imaging-test.gif && gifsicle -O3
> commons-imaging-test.gif -o commons-imaging-test.gif
> {code}
> To run the test program:
> {code:bash}
> git clone g...@github.com:andrewmkhoury/commons-imaging-gif-test.git
> cd commons-imaging-gif-test
> mvn assembly:assembly
> java -Xmx1g -jar target/IMAGING-test-0.0.1-SNAPSHOT-jar-with-dependencies.jar
> commons-imaging-test.gif{code}
> Heap analysis via Eclipse MAT shows that the ImageDescriptor.imageData
> storing the bytes of each frame is the cause of the problem:
> !image-2023-06-29-15-18-17-076.png|width=169,height=93!!screenshot-1.png|width=226,height=86!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IMAGING-355) Large animated GIF takes too much heap memory in getMetadata
[
https://issues.apache.org/jira/browse/IMAGING-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741211#comment-17741211
]
Andrew Khoury edited comment on IMAGING-355 at 7/8/23 9:27 PM:
---
Hi [~ggregory], yes I tested against master as well and the same issue occurs.
Also, I was able to fix the issue using this change
[here|https://github.com/andrewmkhoury/commons-imaging/commit/d4a5f6a039e8ccf232750d5427f88638162db3f1]
{code:java}
readFile(byteSource, true); // instead of false to skip storing the imageData
which isn't required for getMetadata and getImageInfo{code}
Here is my updated test code I used to test the issue against git master:
[https://github.com/andrewmkhoury/commons-imaging-gif-test/tree/IMAGING-355]
was (Author: akhoury):
Hi [~ggregory], yes I tested against master as well and the same issue occurs.
Also, I was able to fix the issue using this change
[here|https://github.com/andrewmkhoury/commons-imaging/commit/d4a5f6a039e8ccf232750d5427f88638162db3f1]
{code:java}
readFile(byteSource, true); // instead of false to skip storing the imageData
which isn't required for getMetadata and getImageInfo{code}
> Large animated GIF takes too much heap memory in getMetadata
>
>
> Key: IMAGING-355
> URL: https://issues.apache.org/jira/browse/IMAGING-355
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: GIF
>Affects Versions: 1.0-alpha3
>Reporter: Andrew Khoury
>Priority: Major
> Attachments: commons-imaging-test.gif,
> image-2023-06-29-15-18-17-076.png, screenshot-1.png
>
>
> When calling ImageParser.getMetadata on large animated gif files, the java
> heap consumption is extremely high.
> For example, see the test project I created:
> [https://github.com/andrewmkhoury/commons-imaging-gif-test]
> When calling ImageParser.getMetadata on the attached 5MB gif
> [^commons-imaging-test.gif], it uses ~1.5GB of heap space. When the max heap
> is set to -Xmx1488M or lower it fails with this exception. When the heap is
> set to -Xmx1489M it works.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
> at
> java.base/java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:211)
> at
> org.apache.commons.imaging.mylzw.MyLzwDecompressor.decompress(MyLzwDecompressor.java:143)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readImageDescriptor(GifImageParser.java:881)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readBlocks(GifImageParser.java:596)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:696)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.readFile(GifImageParser.java:680)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata(GifImageParser.java:485)
> at
> org.apache.commons.imaging.formats.gif.GifImageParser.getMetadata(GifImageParser.java:58)
> at
> org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:832)
> at Test.main(Test.java:28)
> {code}
> To generate the large gif file I did the following:
> 1. Install ffmpeg and gifsicle
> 2. Use quicktime to create a screen recording
> 3. Generate a gif out of the screen recording
> {code:bash}
> ffmpeg -i ~/Desktop/Screen\ Recording\ 2023-06-29\ at\ 12.09.21\ PM.mov
> -pix_fmt rgb8 -r 10 commons-imaging-test.gif && gifsicle -O3
> commons-imaging-test.gif -o commons-imaging-test.gif
> {code}
> To run the test program:
> {code:bash}
> git clone g...@github.com:andrewmkhoury/commons-imaging-gif-test.git
> cd commons-imaging-gif-test
> mvn assembly:assembly
> java -Xmx1g -jar target/IMAGING-test-0.0.1-SNAPSHOT-jar-with-dependencies.jar
> commons-imaging-test.gif{code}
> Heap analysis via Eclipse MAT shows that the ImageDescriptor.imageData
> storing the bytes of each frame is the cause of the problem:
> !image-2023-06-29-15-18-17-076.png|width=169,height=93!!screenshot-1.png|width=226,height=86!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (POOL-411) NPE when deregistering key at end of borrow
[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741331#comment-17741331
]
Phil Steitz edited comment on POOL-411 at 7/8/23 9:16 PM:
--
[~sebb] I am not sure I understand your last comment. With the test parms (now
committed) above, the test fails regularly before Gary's last commit, so I am
not sure we need to add the sleeps to verify. I agree with what I think you
are implying - that the problem in prior code was likely between the read lock
release and write lock acquire, resulting in the possibility of two registering
threads ending up creating two different pools under the same key, one of which
ends up orphaned. More importantly, the deregister from one thread ends up
decrementing numInterested on a different deque from the one it created but
orphaned in its register activation, resulting in its premature demise. That
would lead to exactly what we saw in prior code. Gary's change effectively
double checks that the pool exists before adding to the poolMap. There is no
need to null check the deque because the computeIfAbsent creates it if it is
not there. I think we are good to resolve this unless I am missing something.
was (Author: psteitz):
[~sebb] I am not sure I understand your last comment. With the test parms (now
committed) above, the test fails regularly before Gary's last commit, so I am
not sure we need to add the sleeps to verify. I agree with what I think you
are implying - that the problem in prior code was likely between the read lock
release and write lock acquire, resulting in the possibility of two registering
threads ending up creating two different pools under the same key, one of which
ends up orphaned. Gary's change effectively double checks that the pool exists
before adding to the poolMap. I haven't looked at the ConcurrentHashMap
sources to verify, but I suspect that you can't have two threads concurrently
executing the lambda, so this should fully close the hole. There is no need
to null check the deque because the computeIfAbsent creates it if it is not
there. I think we are good to resolve this unless I am missing something.
> NPE when deregistering key at end of borrow
> ---
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
>Affects Versions: 2.11.1
>Reporter: Richard Eckart de Castilho
>Priority: Major
> Fix For: 2.12.0
>
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (POOL-411) NPE when deregistering key at end of borrow
[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741331#comment-17741331
]
Phil Steitz commented on POOL-411:
--
[~sebb] I am not sure I understand your last comment. With the test parms (now
committed) above, the test fails regularly before Gary's last commit, so I am
not sure we need to add the sleeps to verify. I agree with what I think you
are implying - that the problem in prior code was likely between the read lock
release and write lock acquire, resulting in the possibility of two registering
threads ending up creating two different pools under the same key, one of which
ends up orphaned. Gary's change effectively double checks that the pool exists
before adding to the poolMap. I haven't looked at the ConcurrentHashMap
sources to verify, but I suspect that you can't have two threads concurrently
executing the lambda, so this should fully close the hole. There is no need
to null check the deque because the computeIfAbsent creates it if it is not
there. I think we are good to resolve this unless I am missing something.
> NPE when deregistering key at end of borrow
> ---
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
>Affects Versions: 2.11.1
>Reporter: Richard Eckart de Castilho
>Priority: Major
> Fix For: 2.12.0
>
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-pool] psteitz merged pull request #228: POOL-391 fixes, docs
psteitz merged PR #228: URL: https://github.com/apache/commons-pool/pull/228 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-cli] bowbahdoe commented on pull request #21: Add module-info
bowbahdoe commented on PR #21: URL: https://github.com/apache/commons-cli/pull/21#issuecomment-1627448541 @garydgregory What is the state of the parent pom update? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-cli] bowbahdoe commented on pull request #21: Add module-info
bowbahdoe commented on PR #21: URL: https://github.com/apache/commons-cli/pull/21#issuecomment-1627447749 @michaelsavich made this pr over half a decade ago, so i'll fork his branch and rebase to move things along. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (POOL-411) NPE when deregistering key at end of borrow
[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741221#comment-17741221
]
Gary D. Gregory edited comment on POOL-411 at 7/8/23 3:08 PM:
--
Committed to master. Because {{allocate}} is accessed in and out of a lambda,
it must be final, hence the object reference instead of a primitive.
was (Author: garydgregory):
Committed to master. Because allocate is accessed in and out of a lambed, it
must be final, hence the object reference instead of a primitive.
> NPE when deregistering key at end of borrow
> ---
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
>Affects Versions: 2.11.1
>Reporter: Richard Eckart de Castilho
>Priority: Major
> Fix For: 2.12.0
>
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-400) modify primitive value in lambda/function does not affect original value
Xu Pengcheng created JEXL-400:
-
Summary: modify primitive value in lambda/function does not affect
original value
Key: JEXL-400
URL: https://issues.apache.org/jira/browse/JEXL-400
Project: Commons JEXL
Issue Type: Bug
Reporter: Xu Pengcheng
{code:java}
let count = 0;
function inc() {
count ++;
// here count is 1
}
inc();
// here count is still 0{code}
It maybe not a 'bug', just seems making it as a global variable and keep the
value consistently makes more sense.
Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (POOL-411) NPE when deregistering key at end of borrow
[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741254#comment-17741254
]
Sebb commented on POOL-411:
---
I think it would be worth temporarily adding some sleeps/yields in the lock
upgrade sequence to make it easier for tests to exercise the window that the
sequence opens.
Also, is it not necessary to recheck that the object is still in the pool after
obtaining the write lock?
> NPE when deregistering key at end of borrow
> ---
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
>Affects Versions: 2.11.1
>Reporter: Richard Eckart de Castilho
>Priority: Major
> Fix For: 2.12.0
>
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-399) Needs support more javascript syntax
[
https://issues.apache.org/jira/browse/JEXL-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-399.
Resolution: Won't Do
> Needs support more javascript syntax
>
>
> Key: JEXL-399
> URL: https://issues.apache.org/jira/browse/JEXL-399
> Project: Commons JEXL
> Issue Type: New Feature
>Reporter: Xu Pengcheng
>Priority: Major
>
> Hi, I am trying ask chatgpt to generate code for some cases, JEXL, as a
> lightweight, secure, easy to communicate with host solution, I think is the
> best option for java world as a bridge between chatgpt and app.
> Unfortunately, chatgpt seems is not familiar with Jexl syntax, so I tried to
> ask chatgpt to write as javascript, I had implements most of the javascript
> build-in objects (like Array, Object, Math, console, etc) for JEXL, 95% cases
> generated by chatgpt can run successfully.
> However, some syntax error will cause the 5% failure, for example:
> # a === b
> # a !== b
> # a = b ** 2
> # const \{a, b} = x;
> # a = \{x: 1, y: 2,}
> # func = () => (\{"a":1, "b": 2})
> # for (let k in map)
> # for (let value of map)
> These syntax looks very reasonable, It will be great to support these
> javascript syntax to let both chatgpt and developer easy to use.
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
