Could not find module htmlbars-inline-precompile imported from ...

... <- here goes integration test "name-path" for component
In my component's integration test I make import:
import hbs from 'htmlbars-inline-precompile';

and use hbs this way:
this.render(hbs`
  {{component/component-name}}
`);

This works good in version: 0.3.6 but I experience the error mentioned in the title in version 0.4.0.
I'm running on ember-cli: 2.12.2 if that matters.
Did I miss something in the latest upgrade?

0.4.0 requires a miner-cli-babel@6, did you also update that?
We need to make this a peerDependency so you would see a warning about this when installing...

I didn't ;)
So now I upgrade these two together and everything is working properly :tada:
ember-cli-babel                        5.2.4  →         6.0.0
ember-cli-htmlbars-inline-precompile   0.3.6  →         0.4.0

Thanks!

No problem! We definitely need to make this a bit more obvious.  I think the first step is peerDependnecies, but we should probably also check this.parent.addons and see what ember-cli-babel version is in use then warn as appropriate...

I'm having this same problem, even after updating both of the packages:
    "ember-cli-babel": "6.1.0",
    "ember-cli-htmlbars-inline-precompile": "0.4.2",

What else do I need to do?  All of my packages are up to date.

@dfalling - I've also seen this reported by @lukemelia in slack, is there a way that you might be able to create a demo for me to look at?

@rwjblue - Sure, I'll try to whip together a much smaller demo that illustrates my problems.  Thanks!

https://github.com/dfalling/hbs_demo
I ended up slimming down an existing app rather than trying to build up a new one with the same problems.  If there's too much noise from the addons I've, I can do a few more passes through to clean them up.

Thanks for putting this together @dfalling! In case, it help narrow things down, we use ember-cli-sass and the active-model-adapter but not ember-cli-mocha, ember-cli-chai, or ember-cli-stylelint.

OK, I've tracked down what is going on. Trying to work on a fix.

Awesome, thanks for the update.  If there's anything I can do to help, I'm happy to throw some time at it as well.

https://github.com/ember-cli/ember-cli/pull/7036 fixes on the ember-cli side, but there are changes that should be made to the various linters too.

The following PR's should fix the issue for most folks that are hitting this:

https://github.com/sir-dunxalot/ember-cli-sass-lint/pull/11
https://github.com/billybonks/ember-cli-stylelint/pull/66
https://github.com/tomasbasham/ember-cli-scss-lint/pull/12

Side note: why are there so many different style linters?

We are running into this inside of our app.
We do not use any style linters, but do use ember-cli-sass. All are upgraded to the latest versions.


added nfd cr artifact on deployment tests

This PR is addressing some fails we have with NFD and OCP 4.12.
NFD is deployed, but labels do not show up on nodes. Must gather logs showed an error message, but additional information might be in the CR status.
This commit will add the CR to artifacts after the polling of the node labels. Regardless if test passed or not. While still logging the initial error if happened.

/test images

/test ?

/test 4.12-nvidia-gpu-operator-e2e

Running this ^ just to see logs/artifacts, I expect this to fail.

Looks good to me

/lgtm

/lgtm


Skip verify change log if artifact.skipVerifyChangelog==true.

Fix #26075
For spring related module, we decide to delete CHANGELOG, so delete related check logic in this PR.

Hi, @saragluna , @backwind1233 , please help to review this PR when you have time.


feat: add output to step summary

This PR allows adds the option output-to, which can be set to step-summary (or checks). This circumvents the issue mentioned in the README under "Github limitations"

Thanks for fixing this critical bug of this otherwise great action!

Can we merge please? We could use this

Can we merge please? We could use this

You can use it in your workflow already like this:
uses: phoenix-actions/test-reporting@f68b7c5fcffefd98dd230c686cca6c26683668c3

Checked this out. Works well:

It's also worth noting unlike with separate reports, updating the workflow summary doesn't need write access to the repo, and thus will also work if you open a PR from a fork, like here.

Great improvement @jcdickinson!
Merged 👍

https://github.com/phoenix-actions/test-reporting/releases/tag/v9


segmentation fault with realign

Hi
I was able to run speedseq realign without issues on one node but when I submitted it as an array job it gave me seg fault towards the end. The error messages are as follows:
291167 Segmentation fault      | /itmi/speedseq/0.1.2//bin/sambamba view -S -f bam -l 0 /dev/stdin
291168 Segmentation fault      | /itmi/speedseq/0.1.2//bin/sambamba sort -t 16 -m 18G --tmpdir=/data/tmp/sample1//full -o /data/tmp/sample1//sample1.bam.1.bam /dev/stdin
Thanks for your help!
Wendy

This seems like you may be running out of RAM. Try reducing the memory usage with the -M flag.


resolverFactory.plugin method is not a function

Bug report

What is the current behavior?
I use a plugin called webpack-concat-plugin https://github.com/hxlniada/webpack-concat-plugin, which was working correctly with webpack version 4.
When trying to migrate to version 5 I've got this error
compiler.resolverFactory.plugin is not a function

This is where the code is failing:  https://github.com/hxlniada/webpack-concat-plugin/blob/master/index.js#L121
Initially I thought there was some migration necessary, but checking webpack documentation says that should still be available and this plugin is using that exactly like in the docs here https://webpack.js.org/api/resolvers/
I did some investigation and saw that the ResolverFactory in version 4 extended Tapable and that plugin method was coming from there.
Not sure if this is a bug in webpack version 5, or if the documentation is incorrect about that method being available.
I checked the migration docs and couldn't find anything about it.
If the current behavior is a bug, please provide the steps to reproduce.
I don't know how to build a plugin, but the plugin that I mentioned (webpack-concat-plugin) above is really simple and relies on that possibly deprecated method.
import ConcatPlugin from '../../../index';

module.exports = {
    entry: './index.js',
    plugins: [
        new ConcatPlugin({
            name: 'file',
            fileName: '[name].js',
            filesToConcat: ['../../fixtures/a.js', '../../fixtures/b.js', 'is-object']
        })
    ],
};

What is the expected behavior?
This plugin should work, since the documentation says to use compiler.resolverFactory.plugin. Or the documentation should not include that information and provide a migration path.

Other relevant information:
webpack version:  5.3.2
Node.js version: 12.18.4
Operating System: Windows 10
Additional tools:

Please open an issue in webpack-concat-plugin, this plugin uses old API and it was removed

I will open an issue for updating docs

Let's keep open

Will check the deprecation note in v4 and fix that library. Thank you.

Yes, you need to migrate on hooks, please look at https://github.com/webpack/webpack/blob/master/lib/cache/ResolverCachePlugin.js#L173


feat: add ItemSeparatorComponent

linked to: https://github.com/LegendApp/legend-list/issues/6
ItemSeparatorComponent compatibility as it's common and frequently used on list

I think that will display a separator at the bottom of the list? So it should not render a separator on the last item? Could check itemIndex compared to listProps.data.length?

Absolutely! Fixed c3a25f39646d0b13b42d8be02f713ae2ef37355c

Great! Thank you!


fix: fixed issue wuth ClientSideDataCollectionStoreImpl @action metho…

…ds #191
affects: @haulmont/jmix-react-core

Doesn't look good, but since we'll move to hook based data components I think it's ok for now. @vyacheslav-pushkin  WDYT?

I think overriding should work if we make the field non-annotated (i.e. remove it from makeObservable and wrap in action method instead).


feat: added a new sandbox theme

What kind of change does this pull request introduce?
This is a feature.
What is the current behavior?
https://github.com/codesandbox/sandpack/issues/596
What is the new behavior?
This adds a new sandbox theme
What steps did you take to test this? This is required before we can merge, make sure to test the flow you've updated.
NA
Checklist

[ ] Documentation; NA
[ ] Storybook (if applicable); NA
[ ] Tests; NA
[ ] Ready to be merged;

Hey, thanks for contributing to the themes!
However, could you make some tweaks to improve the legibility of the nav bar? Once it's done, I think it's ready to go

Hey, thanks for contributing to the themes!
However, could you make some tweaks to improve the legibility of the nav bar? Once it's done, I think it's ready to go

HI , I have made changes, please review.

🎉


ITerminalService#getActiveOrCreateInstance returns a disposed terminal

Open a Terminal Editor
Close it
Call ITerminalService#getActiveOrCreateInstance
Get a terminal that has isDisposed = true
Try to reveal the terminal, and it isn't shown

Noticed this with https://github.com/microsoft/vscode/pull/180017/files#diff-0cce141a5c2c60f7c15454df04f32133a8364c97b5d67af79de9d2f4bfb0aebbR212-R215, I can work around this but it seems wrong?

PR https://github.com/microsoft/vscode/pull/180451 fixing it

This bug has been fixed in the latest release of VS Code Insiders!
@roblourens, you can help us out by commenting /verified if things are now working as expected.
If things still don't seem right, please ensure you're on version b9a77b3c7b43f229a430b28070250d55e5d14858 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.
Happy Coding!


Fix cast-double-to-real when input is beyond the limit

Summary: Presto returns Infinity on cast(1.7E308 as real) and returns -Infinity on cast(-1.7E308 as real), while Velox throws. This diff make Velox return the same as Presto.
Differential Revision: D47934413

Hi @bikramSingh91, to follow up on your comment in the internal diff

wonder if this extra check has any perf impact?
If there is, can we catch the exception thrown by folly::to() and then check or modify its behavior if its possible, since I would assume that infinity would not be the common case we can looks for ways to not penalize all rows. What do you think?

I added a cast of doubleToReal to cast_benchmark and found something interesting. Adding the check before the try-catch block makes the performance the same as not adding the check at all. But adding the check in the catch block actually makes it slightly slower. (See below.) I think the reason is that the case where input double is beyond the float-limit is not an uncommon case because float uses 8 bits for exponent while double uses 11 bits for exponents, so the range of double is much larger than float and hence the check is likely to be satisfied. If we add the check to the catch block, then for these cases, we pay the costs of both the exception and the check.
Original code:
[...]pression/benchmarks/CastBenchmark.cpp     relative  time/iter   iters/s
scalar                                                     15.85ns    63.08M
doubleToReal                                               17.80ns    56.17M
renameSmallStruct                                          13.49ns    74.15M
renameLargeStruct                                           1.66us   603.68K
smallStructNested                                          47.76ns    20.94M
largeStructNested                                          15.87us    63.02K
Add check before try-catch:
[...]pression/benchmarks/CastBenchmark.cpp     relative  time/iter   iters/s
scalar                                                     15.82ns    63.21M
doubleToReal                                               17.88ns    55.94M
renameSmallStruct                                          13.43ns    74.48M
renameLargeStruct                                           1.66us   602.96K
smallStructNested                                          47.65ns    20.98M
largeStructNested                                          15.57us    64.22K
Add check inside catch block:
[...]pression/benchmarks/CastBenchmark.cpp     relative  time/iter   iters/s
scalar                                                     15.91ns    62.85M
doubleToReal                                               20.93ns    47.79M
renameSmallStruct                                          13.61ns    73.48M
renameLargeStruct                                           1.66us   602.33K
smallStructNested                                          47.46ns    21.07M
largeStructNested                                          15.66us    63.86K

Hi @bikramSingh91, to follow up on your comment in the internal diff

wonder if this extra check has any perf impact?
If there is, can we catch the exception thrown by folly::to() and then check or modify its behavior if its possible, since I would assume that infinity would not be the common case we can looks for ways to not penalize all rows. What do you think?

I added a cast of doubleToReal to cast_benchmark and found something interesting. Adding the check before the try-catch block makes the performance the same as not adding the check at all. But adding the check in the catch block actually makes it slightly slower. (See below.) I think the reason is that the case where input double is beyond the float-limit is not an uncommon case because float uses 8 bits for exponent while double uses 11 bits for exponents, so the range of double is much larger than float and hence the check is likely to be satisfied. If we add the check to the catch block, then for these cases, we pay the costs of both the exception and the check.
Original code:
============================================================================
[...]pression/benchmarks/CastBenchmark.cpp     relative  time/iter   iters/s
============================================================================
scalar                                                     15.85ns    63.08M
doubleToReal                                               17.80ns    56.17M
renameSmallStruct                                          13.49ns    74.15M
renameLargeStruct                                           1.66us   603.68K
smallStructNested                                          47.76ns    20.94M
largeStructNested                                          15.87us    63.02K

Add check before try-catch:
============================================================================
[...]pression/benchmarks/CastBenchmark.cpp     relative  time/iter   iters/s
============================================================================
scalar                                                     15.82ns    63.21M
doubleToReal                                               17.88ns    55.94M
renameSmallStruct                                          13.43ns    74.48M
renameLargeStruct                                           1.66us   602.96K
smallStructNested                                          47.65ns    20.98M
largeStructNested                                          15.57us    64.22K

Add check inside catch block:
============================================================================
[...]pression/benchmarks/CastBenchmark.cpp     relative  time/iter   iters/s
============================================================================
scalar                                                     15.91ns    62.85M
doubleToReal                                               20.93ns    47.79M
renameSmallStruct                                          13.61ns    73.48M
renameLargeStruct                                           1.66us   602.33K
smallStructNested                                          47.46ns    21.07M
largeStructNested                                          15.66us    63.86K

Thanks @kagamiori for thoroughly investigating. This looks good.


Stellar wallets can't be activated and no trustlines can be added

Description
can't add trustlines to wallet or activate them
JS-NG> j.clients.stellar.new("mainnet_trust")
Stellar(
  instance_name='mainnet_trust',
  network=<Network.STD: 'STD'>,
  address='GBZZ2KJEXN2PIJUVHINMSEQJ46T65XSYN6USTC2HJ4ADW5IYCT3J6XN2',
  secret='SDNSSNUOTYMTT2OELWQKRXHKSKGGM4SM5HEK6SWIVPUGE3NCFQTAUKFR'
)

JS-NG> w = _
JS-NG> w.activate_through_threefold_service()
JS-NG> w
Stellar(
  instance_name='mainnet_trust',
  network=<Network.STD: 'STD'>,
  address='GBZZ2KJEXN2PIJUVHINMSEQJ46T65XSYN6USTC2HJ4ADW5IYCT3J6XN2',
  secret='SDNSSNUOTYMTT2OELWQKRXHKSKGGM4SM5HEK6SWIVPUGE3NCFQTAUKFR'
)

JS-NG> w.add_known_trustline("TFT")
2020-12-21 09:53:43.441 | ERROR    | jumpscale.tools.errorhandler.errorhandler:_handle_exception:93 - stellar_sdk.exceptions.NotFoundError: {
  "type": "https://stellar.org/horizon-errors/not_found",
  "title": "Resource Missing",
  "status": 404,
  "detail": "The resource at the url requested was not found.  This usually occurs for one of two reasons:  The url requested is not valid, or no data in our database could be found with the parameters provided.
"
}
Traceback (most recent call last):
  File "/root/.cache/pypoetry/virtualenvs/js-sdk-vpmH-Z_5-py3.6/bin/jsng", line 8, in <module>
    sys.exit(run())
    │   │    └ <Command run>
    │   └ <built-in function exit>
    └ <module 'sys' (built-in)>
  File "/root/.cache/pypoetry/virtualenvs/js-sdk-vpmH-Z_5-py3.6/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
           │    │     │       └ {}
           │    │     └ ()
           │    └ <function BaseCommand.main at 0x7f7709ae87b8>
           └ <Command run>
  File "/root/.cache/pypoetry/virtualenvs/js-sdk-vpmH-Z_5-py3.6/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
         │    │      └ <click.core.Context object at 0x7f770d5f0f28>
         │    └ <function Command.invoke at 0x7f7709ae9158>
         └ <Command run>
  File "/root/.cache/pypoetry/virtualenvs/js-sdk-vpmH-Z_5-py3.6/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           │   │      │    │           │   └ {'command': None}
           │   │      │    │           └ <click.core.Context object at 0x7f770d5f0f28>
           │   │      │    └ <function run at 0x7f7709135bf8>

....................

          │             └ <stellar_sdk.client.response.Response object at 0x7f76f6949240>
          └ <class 'stellar_sdk.exceptions.NotFoundError'>
stellar_sdk.exceptions.NotFoundError: {
  "type": "https://stellar.org/horizon-errors/not_found",
  "title": "Resource Missing",
  "status": 404,
  "detail": "The resource at the url requested was not found.  This usually occurs for one of two reasons:  The url requested is not valid, or no data in our database could be found with the parameters provided.
"
}

{
  "type": "https://stellar.org/horizon-errors/not_found",
  "title": "Resource Missing",
  "status": 404,
  "detail": "The resource at the url requested was not found.  This usually occurs for one of two reasons:  The url requested is not valid, or no data in our database could be found with the parameters provided.
"
}

the balance for activation wallet address on mainnet
JS-NG> j.clients.stellar.main.get_balance("GCKLGWHEYT2V63HC2VDJRDWEY3G54YSHHPOA6Q3HAPQUGA5OZDWZL7KW")
Balances
  3.4408600 XLM

JS-NG>

also transactions are failing on testnet
JS-NG> j.clients.stellar.init.transfer("GAGTZFJA2ODPMNX2GRMMHXDBXBMHEHV424VDI2LTGXAGNVMIHFCNXAAB", 5, f"{a.code}:{a.issuer}", memo_text="mR4wOWvLMzPAviDkWg5jc5jCnU2v")
2020-12-21 12:03:20.462 | INFO     | jumpscale.clients.stellar.stellar:transfer:387 - Sending 5 TFT:GA47YZA3PKFUZMPLQ3B5F2E3CJIB57TGGU7SPCQT2WAEYKN766PWIMB3 to GAGTZFJA2ODPMNX2GRMMHXDBXBMHEHV424VDI2LTGXAGNVMIHFCNXAAB
Traceback (most recent call last):
  File "/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 426, in _make_request
    six.raise_from(e, None)
    └ <module 'urllib3.packages.six' from '/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/u...
  File "<string>", line 3, in raise_from
  File "/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request
    httplib_response = conn.getresponse()
                       └ <urllib3.connection.HTTPSConnection object at 0x7f98ca5647f0>
  File "/usr/lib/python3.6/http/client.py", line 1373, in getresponse
    response.begin()
    └ <http.client.HTTPResponse object at 0x7f98c575c0b8>
  File "/usr/lib/python3.6/http/client.py", line 311, in begin
    version, status, reason = self._read_status()
                              └ <http.client.HTTPResponse object at 0x7f98c575c0b8>
  File "/usr/lib/python3.6/http/client.py", line 272, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), 'iso-8859-1')

............................................

        └ <requests.adapters.HTTPAdapter object at 0x7f98c5566940>
  File "/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/requests/adapters.py", line 516, in send
    raise ConnectionError(e, request=request)
          │                          └ <PreparedRequest [POST]>
          └ <class 'requests.exceptions.ConnectionError'>
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): Max retries exceeded with url: /transactions (Caused by ReadTimeoutError("HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): Read timed out. (read timeout=20)",))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/maged/Code/js-sdk/jumpscale/clients/stellar/stellar.py", line 452, in transfer
    response = horizon_server.submit_transaction(transaction)
               │                                 └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f98c575c710>
               └ <jumpscale.clients.stellar.wrapped.Server object at 0x7f98ca4c0780>
  File "/home/maged/Code/js-sdk/jumpscale/clients/stellar/wrapped.py", line 34, in submit_transaction
    return super().submit_transaction(transaction_envelope)
                                      └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f98c575c710>
  File "/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/stellar_sdk/server.py", line 109, in submit_transaction
    transaction_envelope, skip_memo_required_check
    │                     └ False
    └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f98c575c710>
  File "/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/stellar_sdk/server.py", line 124, in __submit_transaction_sync
    resp = self._client.post(url=url, data=data)
           │                     │         └ {'tx': 'AAAAAN6t2KTZZK+nvH5Jxpy09oafe9vHMcDw2vOC2Jq7AyDdAAAAyAAAAeEAAADPAAAAAQAAAAAAAAAAAAAAAF/gcwcAAAABAAAAHG1SNHdPV3ZMTXpQQXZp...
           │                     └ 'https://horizon-testnet.stellar.org/transactions'
           └ <jumpscale.clients.stellar.wrapped.Server object at 0x7f98ca4c0780>
  File "/home/maged/.cache/pypoetry/virtualenvs/js-sdk-IZdTbuKY-py3.6/lib/python3.6/site-packages/stellar_sdk/client/requests_client.py", line 139, in post
    raise ConnectionError(err)
          └ <class 'stellar_sdk.exceptions.ConnectionError'>
stellar_sdk.exceptions.ConnectionError: HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): Max retries exceeded with url: /transactions (Caused by ReadTimeoutError("HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): Read timed out. (read timeout=20)",))

HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): Max retries exceeded with url: /transactions (Caused by ReadTimeoutError("HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): Read timed out. (read timeout=20)",))
JS-NG>

mainnet should be fixed, I funded the activation wallet ( Again)

we still can't add known trust line TFT
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='horizon-testnet.stellar.org', port=443): M
ax retries exceeded with url: /transactions (Caused by ReadTimeoutError("HTTPSConnectionPool(host='horizo
n-testnet.stellar.org', port=443): Read timed out. (read timeout=20)"))

Full logs in my case
JS-NG> ax = j.clients.stellar.new("aa11", network="TEST")
JS-NG> ax.activate_through_friendbot()
2020-12-21 16:08:55.254 | INFO     | jumpscale.clients.stellar.stellar:activate_through_friendbot:239 - account with address GDHFQEPOABBXBLDAWZ2RZLGI6G3YFVXCJKAITIF3V5GUBVPW66NAI6ZK activated and funded through friendbot
JS-NG> ax.add_known_trustline("TFT")
2020-12-21 16:10:47.627 | ERROR    | jumpscale.tools.errorhandler.errorhandler:_handle_exception:93 - stellar_sdk.exceptions.BadResponseError: {
  "type": "https://stellar.org/horizon-errors/timeout",
  "title": "Timeout",
  "status": 504,
  "detail": "Your request timed out before completing.  Please try your request again. If you are submitting a transaction make sure you are sending exactly the same transaction (with the same sequence number)."
}
Traceback (most recent call last):
  File "/home/xmonader/wspace/js/js-sdk/.venv/bin/jsng", line 8, in <module>
    sys.exit(run())
    │   │    └ <Command run>
    │   └ <built-in function exit>
    └ <module 'sys' (built-in)>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
           │    │     │       └ {}
           │    │     └ ()
           │    └ <function BaseCommand.main at 0x7f9b08ad6310>
           └ <Command run>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
         │    │      └ <click.core.Context object at 0x7f9b0902a3a0>
         │    └ <function Command.invoke at 0x7f9b08ad6ca0>
         └ <Command run>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           │   │      │    │           │   └ {'command': None}
           │   │      │    │           └ <click.core.Context object at 0x7f9b0902a3a0>
           │   │      │    └ <function run at 0x7f9b0831a5e0>
           │   │      └ <Command run>
           │   └ <function Context.invoke at 0x7f9b08ad5dc0>
           └ <click.core.Context object at 0x7f9b0902a3a0>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
           │         │       └ {'command': None}
           │         └ ()
           └ <function run at 0x7f9b0831a5e0>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/jumpscale/entry_points/jsng.py", line 34, in run
    sys.exit(embed(globals(), locals(), configure=ptconfig, history_filename=HISTORY_FILENAME))
    │   │    │                                    │                          └ '/home/xmonader/.jsng/history.txt'
    │   │    │                                    └ <function ptconfig at 0x7f9b07f8f280>
    │   │    └ <function embed at 0x7f9b07dc8280>
    │   └ <built-in function exit>
    └ <module 'sys' (built-in)>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/ptpython/repl.py", line 350, in embed
    repl.run()
    │    └ <function PythonRepl.run at 0x7f9b07dc6dc0>
    └ <ptpython.repl.PythonRepl object at 0x7f9b07f88b80>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/ptpython/repl.py", line 74, in run
    self._process_text(text)
    │    │             └ 'ax.add_known_trustline("TFT")'
    │    └ <function PythonRepl._process_text at 0x7f9b07dc6e50>
    └ <ptpython.repl.PythonRepl object at 0x7f9b07f88b80>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/ptpython/repl.py", line 88, in _process_text
    self._handle_exception(e)
    │    │                 └ BadResponseError(<stellar_sdk.client.response.Response object at 0x7f9b0128a070>)
    │    └ functools.partial(<function patched_handle_exception at 0x7f9b09d5e280>, <ptpython.repl.PythonRepl object at 0x7f9b07f88b80>)
    └ <ptpython.repl.PythonRepl object at 0x7f9b07f88b80>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/ptpython/repl.py", line 163, in _execute
    six.exec_(code, self.get_globals(), self.get_locals())
    │   │     │     │    │              │    └ <function embed.<locals>.get_locals at 0x7f9b07dc8310>
    │   │     │     │    │              └ <ptpython.repl.PythonRepl object at 0x7f9b07f88b80>
    │   │     │     │    └ <function embed.<locals>.get_globals at 0x7f9b08a81430>
    │   │     │     └ <ptpython.repl.PythonRepl object at 0x7f9b07f88b80>
    │   │     └ <code object <module> at 0x7f9b013b7ea0, file "<stdin>", line 1>
    │   └ <built-in function exec>
    └ <module 'six' from '/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/six.py'>
> File "<stdin>", line 1, in <module>

  File "/home/xmonader/wspace/js/js-sdk/jumpscale/clients/stellar/stellar.py", line 296, in add_known_trustline
    self._change_trustline(asset_code, issuer)
    │    │                 │           └ 'GA47YZA3PKFUZMPLQ3B5F2E3CJIB57TGGU7SPCQT2WAEYKN766PWIMB3'
    │    │                 └ 'TFT'
    │    └ <function Stellar._change_trustline at 0x7f9b037e28b0>
    └ Stellar(
        instance_name='aa11',
        network=<Network.TEST: 'TEST'>,
        address='GDHFQEPOABBXBLDAWZ2RZLGI6G3YFVXCJKAITIF3V5GUBVP...

  File "/home/xmonader/wspace/js/js-sdk/jumpscale/clients/stellar/stellar.py", line 341, in _change_trustline
    server.submit_transaction(transaction)
    │      │                  └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f9afbf66490>
    │      └ <function Server.submit_transaction at 0x7f9b038479d0>
    └ <jumpscale.clients.stellar.wrapped.Server object at 0x7f9b020547f0>

  File "/home/xmonader/wspace/js/js-sdk/jumpscale/clients/stellar/wrapped.py", line 34, in submit_transaction
    return super().submit_transaction(transaction_envelope)
                                      └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f9afbf66490>

  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/stellar_sdk/server.py", line 108, in submit_transaction
    return self.__submit_transaction_sync(
           └ <jumpscale.clients.stellar.wrapped.Server object at 0x7f9b020547f0>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/stellar_sdk/server.py", line 125, in __submit_transaction_sync
    raise_request_exception(resp)
    │                       └ <stellar_sdk.client.response.Response object at 0x7f9b0128a070>
    └ <function raise_request_exception at 0x7f9b07954160>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/stellar_sdk/exceptions.py", line 204, in raise_request_exception
    raise BadResponseError(response)
          │                └ <stellar_sdk.client.response.Response object at 0x7f9b0128a070>
          └ <class 'stellar_sdk.exceptions.BadResponseError'>

stellar_sdk.exceptions.BadResponseError: {
  "type": "https://stellar.org/horizon-errors/timeout",
  "title": "Timeout",
  "status": 504,
  "detail": "Your request timed out before completing.  Please try your request again. If you are submitting a transaction make sure you are sending exactly the same transaction (with the same sequence number)."
}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/xmonader/wspace/js/js-sdk/jumpscale/clients/stellar/stellar.py", line 296, in add_known_trustline
    self._change_trustline(asset_code, issuer)
    │                      │           └ 'GA47YZA3PKFUZMPLQ3B5F2E3CJIB57TGGU7SPCQT2WAEYKN766PWIMB3'
    │                      └ 'TFT'
    └ Stellar(
  instance_name='aa11',
  network=<Network.TEST: 'TEST'>,
  address='GDHFQEPOABBXBLDAWZ2RZLGI6G3YFVXCJKAITIF3V5GUBVPW66...
  File "/home/xmonader/wspace/js/js-sdk/jumpscale/clients/stellar/stellar.py", line 341, in _change_trustline
    server.submit_transaction(transaction)
    │                         └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f9afbf66490>
    └ <jumpscale.clients.stellar.wrapped.Server object at 0x7f9b020547f0>
  File "/home/xmonader/wspace/js/js-sdk/jumpscale/clients/stellar/wrapped.py", line 34, in submit_transaction
    return super().submit_transaction(transaction_envelope)
                                      └ <stellar_sdk.transaction_envelope.TransactionEnvelope object at 0x7f9afbf66490>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/stellar_sdk/server.py", line 108, in submit_transaction
    return self.__submit_transaction_sync(
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/stellar_sdk/server.py", line 125, in __submit_transaction_sync
    raise_request_exception(resp)
    │                       └ <stellar_sdk.client.response.Response object at 0x7f9b0128a070>
    └ <function raise_request_exception at 0x7f9b07954160>
  File "/home/xmonader/wspace/js/js-sdk/.venv/lib/python3.8/site-packages/stellar_sdk/exceptions.py", line 204, in raise_request_exception
    raise BadResponseError(response)
          │                └ <stellar_sdk.client.response.Response object at 0x7f9b0128a070>
          └ <class 'stellar_sdk.exceptions.BadResponseError'>
stellar_sdk.exceptions.BadResponseError: {
  "type": "https://stellar.org/horizon-errors/timeout",
  "title": "Timeout",
  "status": 504,
  "detail": "Your request timed out before completing.  Please try your request again. If you are submitting a transaction make sure you are sending exactly the same transaction (with the same sequence number)."
}

{
  "type": "https://stellar.org/horizon-errors/timeout",
  "title": "Timeout",
  "status": 504,
  "detail": "Your request timed out before completing.  Please try your request again. If you are submitting a transaction make sure you are sending exactly the same transaction (with the same sequence number)."
}

https://github.com/threefoldtech/tf_operations/issues/64 issue to run stellar private network

this one can be closed, because we are implementing a new testnet backend


'@ ' modifier

This PR implements @ <timestamp> modifier as per this design doc.
An example query:
rate(process_cpu_seconds_total[1m])
  and
topk(7, rate(process_cpu_seconds_total[range()] @ end()))

which ranks based on rate with range equal to the query_range range and w.r.t. the end of the query_range time but actually plots the 1m rate.
TODO

~[ ] Implement start()~
~[ ] Implement end()~
~[ ] Implement range()~
[x] Add selector test cases
[x] Fix the TODO test cases
[x] Add more dedicated @ test cases with nested @ with different timestamps
[ ] Add a flag to hide this behind
[x] Testing with 0 and timestamps with decimal values

We have this prototype running at http://<IP_ADDRESS>:9090/graph if anyone wants to try it out.

Can we use scalar, instead of creating a new timestamp type?

What do you mean by a scalar here? Does the timestamp<PHONE_NUMBER> count as a scalar?

Also, thanks for this and the demo!!
I am asking for the timestamp/scalar because the first thing I tried is up @timestamp(up) :)

oooh wait the @ is not evaluated on every step, so my idea would not work.

up @timestamp(up) means the timestamp is dependent on the evaluation time, right? So it is not actually using the fixed timestamp benefit :)

Since the above server is still gathering data, here is a peek from one of our internal servers

I think there are benefits in making the argument of @ dynamic.
For one, we probably want it to support an upcoming function now() to, for example, graph the top 10 fullest disk as of now. But that function's return value still won't depend on the evaluation time.
However, I can see MTD-like queries where I want it to depend on the evaluation time, e.g. where you want to compare a value at time t to the value at the beginning of the month relative to t, i.e. something like @ start_of_month(time()). (The yet-to-be-created start_of_month function would probably take time() as the default, and of course there could be more elegant ways, referring to what I wrote about fields in a fully-fledged time struct.) This would allow error-budget burn graphs, which you want to reset at the beginning of a new billing period etc.
To make the latter work nicely, we probably want an @-style start of a range in a range selector. If we allowed dynamic ranges, it could look like increase(errors_total[time()-start_of_month()]), but an @-syntax could say "from then to the time of evaluation", i.e. increase(errors_total[@start_of_month()]). But I guess I'm digressing…
The final plug for a dynamic argument of @ would be to retrieve it from recording rules or do arithmetic on it, which relates to my musings about timestamps and durations.
See https://docs.google.com/document/d/1jMeDsLvDfO92Qnry_JLAXalvMRzMSB1sBr9V7LolpYM/edit#heading=h.vmb7pe7hp12

To be clear: The above are just musings, not concrete suggestions what to implement in this PR. I think this is great as a demo.

Yeah this prototype is just barebone stuff required for a PoC, other helpers like now() end() etc would be based on what we decide and I don't plan implementing in this PR yet.

Note that this PR constitutes a breaking change to PromQL, and thus should not be merged.

I see this as an incremental additional without breaking anything that exists right now. But anyway, should not be merged yes, just a PoC.

Note that this PR constitutes a breaking change to PromQL, and thus should not be merged.

I agree with @codesome that it is not breaking anything from what I can see

It breaks the invariant that has existed for 5+ years that PromQL does not look into the future, and thus that no samples beyond the evaluation time of a query may be accessed. Users could be depending on this, thus it is a breaking change.

I am definitely in favor of this modifier, love it! Thanks, @codesome for this prototype. What I like about this syntax is that is quite clear. Sure, there is some boilerplate but it's fully understandable and does what expected.

It breaks the invariant that has existed for 5+ years that PromQL does not look into the future, and thus that no samples beyond the evaluation time of a query may be accessed. Users could be depending on this, thus it is a breaking change.

Hm @brian-brazil  if that's the case isn't this as easy as returning an error when requested @timestamps is outside or requested range? :thinking:

Users could be depending on this, thus it is a breaking change.

That's not the definition of a breaking change.
https://xkcd.com/1172/

if that's the case isn't this as easy as returning an error when requested @timestamps is outside or requested range?

First of all, no, it's not the case. This is not a breaking change. Everything that works before will continue to work in exactly the same way.
Second, it is core to this feature that you @-request a timestamp from outside the queried range. For example, if you have a topk graph for the busiest CPUs over the last hour, and then you want to zoom in to look at a particular peak, you are now looking at a time interval in the past but still need to run the selecting query with the same fixed @-time. (This is BTW what most competing metrics systems get wrong with the "easy" task of displaying the top-5 busiest CPUs.)

Hm @brian-brazil if that's the case isn't this as easy as returning an error when requested @timestamps is outside or requested range? thinking

That would cover it, as long as it's not after the start time it can't break anyone downstream due to this.

Everything that works before will continue to work in exactly the same way.

I disagree. Anyone who depends on the not looking into the future invariant would be broken, and this is highly likely to affect at the least both explicit and implicit caching. We'd basically be asking for all users to audit all their uses of the API to see if this would impact on them, or any of their downstream users.
Just because something isn't an explicitly enumerated behaviour doesn't mean that we can change it without causing breakage.

Is anyone aware of any software relying this current behavior or is this a theoretical concern?
A feature flag which is on for PromCorThanos and off by default would solve this if anyone is aware of anyone needing opt-in.

Being theoretical is sufficient for it to be breaking. There's stuff I'd like to break that I'd expect to have zero real impact, but can't.
In terms of concrete examples the most obvious would be Trickster, but I expect this would impact on large chunks of the userbase causing non-obvious breakage. I imagine there's tons of scripts out there running queries over "past" data and caching/storing it somewhere, presuming that the query result can't change as new data comes in.

A feature flag which is on for PromCorThanos and off by default would solve this if anyone is aware of anyone needing opt-in.

I don't think this is what you meant to write, as upgrading does not equate to opting in to breaking changes.

I feel we can discuss if it's breaking change or not in a different thread as this is not blocking this proposal as far as I get this, right? (: We expect the timestamp to be inside the queried range.

Second, it is core to this feature that you @-request a timestamp from outside the queried range. For example, if you have a topk graph for the busiest CPUs over the last hour, and then you want to zoom in to look at a particular peak, you are now looking at a time interval in the past but still need to run the selecting query with the same fixed @-time. (This is BTW what most competing metrics systems get wrong with the "easy" task of displaying the top-5 busiest CPUs.)

I have updated this PR with the actual implementation and not a prototype anymore. I still have to fix 1-2 edge cases (the test cases failing are commented out), and have the add a flag. But otherwise, it is good for a review now.

(Also, currently it only works with a timestamp, I will be adding support for start() end() soon)

(The printer is yet to be updated and the position ranges needs updating too :P)

(Also, currently it only works with a timestamp, I will be adding support for start() end() soon)

do we want range() too ? max_over_time(foo[range()]) @ end()

Yes. I will add that too. (I had it in the doc, forgot the mention here. So start() end() and range() but not now() is what I remember as what we decided).

So start() end() and range() but not now() is what I remember as what we decided).

We haven't decided anything here, beyond not having any form of now(). So whether these would be present nor a proposed their syntax is agreed.

We haven't decided anything here

So let's decide now? I propose adding start() end() and range() which is not any form of now().

We haven't decided anything here

So let's decide now? I propose adding start() end() and range() which is not any form of now().

I second this. I wonder if the () are really needed.

I wonder if the () are really needed.

If we remove it, they are valid metric names, hence can cause confusion. With (), we would be consistent with time().

I propose adding start() end() and range()

First, what would range() be for an instant query? I don't think range() makes sense as a PromQL feature semantically. I also question what the use case is here. Why should the width of a graph affect the ranges of the rates within it?
Secondly that's a confusing syntax, as those look like functions but they aren't. That would make it look like you could use scalar expressions as ranges and timestamps - which you can't. Or that you can use them as part of expressions - which you can't. I think that any syntax here needs to make it really obvious that they are not scalar expressions.
Thirdly, these would break the current ability to take any PromQL query_range and evaluate one of its steps using the query endpoint by only adjusting the times. This could in particular cause issues for backfilling rules, and other places where you might shard a query across time to parallelise it

If we remove it, they are valid metric names, hence can cause confusion. With (), we would be consistent with time().

Being consistent with time() is a problem, and being consistent with metric names is also a problem - as neither of those can go after an @.

Do we want to introduce some kind of templating then? {start} {end} {range}

Or $start $end $range

I propose adding start() end() and range()

First, what would range() be for an instant query? I don't think range() makes sense as a PromQL feature semantically. I also question what the use case is here. Why should the width of a graph affect the ranges of the rates within it?

Instant query is 0 as maxt-mint = 0
It is not for rates but more for the topk_over_time @ end case.

Secondly that's a confusing syntax, as those look like functions but they aren't. That would make it look like you could use scalar expressions as ranges and timestamps - which you can't. Or that you can use them as part of expressions - which you can't. I think that any syntax here needs to make it really obvious that they are not scalar expressions.

Yes, hence juste @ end would be enough

Thirdly, these would break the current ability to take any PromQL query_range and evaluate one of its steps using the query endpoint by only adjusting the times. This could in particular cause issues for backfilling rules, and other places where you might shard a query across time to parallelise it

We agreed during the dev summit that this is an experimental feature and the feeling I got was that some people would be ok to break that promise with @ end queries.

Do we want to introduce some kind of templating then? {start} {end} {range}
Or $start $end $range

Those are possibilities, how would they interact with Grafana? Layering similar syntaxes across languages tends not to end well.
{start} looks like an (invalid) selector. $start looks like it could be used as a scalar expression.

Instant query is 0 as maxt-mint = 0

That's a parse error, you can't have a zero range (and it wouldn't be of much use anyway). Therein lies the problem.

Yes, hence juste @ end would be enough

end is a valid expression. It can't go after an @ for non-trivial semantic reasons, but most users wouldn't realise that.

$start looks like it could be used as a scalar expression.

We define what $ or anything else for that matter mean. I see these to be equivalent to pre-processing, so I don't see anything wrong with $end to be used in place of scalar expression as it would get reduced to a number before the query execution.

Yes, hence juste @ end would be enough

end is a valid expression. It can't go after an @ for non-trivial semantic reasons, but most users wouldn't realise that.

How is that different from offset being a valid expression ?

How is that different from offset being a valid expression ?

It's a question of parsing. offset can only go after a selector, in all other cases it's a metric name. Here it's quite a bit more involved.
I'm expecting at some point that someone is going to propose allowing expressions after the @. Such expressions would have to quite restricted for semantic/performance reasons, however taking advantage that would be very confusing for users. For example end meaning one thing in what is nominally a PromQL expression and another in a part of PromQL expression would be confusing.

I don't get it, offset is also a valid selector (metric name)

I don't get it, offset is also a valid selector (metric name)

offset always has type instant vector. If we go with what you're talking about, start could end up being either be a scalar or an instant vector depending on context. That sort of context-dependent typing is extremely challenging for users of a language to deal with, such as seen in Perl.

We agreed during the dev summit that this is an experimental feature and the feeling I got was that some people would be ok to break that promise with @ end queries.

Thinking a bit, I'm not so sure. The base change proposed here means that trickster would have to update their code to deal with the new feature so their cache invalidation remains correct, but trickser can still cache these new queries.
If we add in start/end then trickster can no longer cache such queries in any useful way, as it's only safe to cache when start/end are identical - it can't use prior evaluations over other ranges to avoid recalculating things. That's quite a bit different, as that's preventing an entire class of performance optimisations that many users currently rely on.

You see end as a scalar when I see it as a keyword.

I think that breaking trickster/caching was accepted because it would be disabled by default and that we could add additional caching headers to help them.

You see end as a scalar/timestamp when I see it as a keyword.

That it's a keyword isn't relevant, the problem is that it would have a type. The other potential parsing of that token has a different type. So if I see the token end I can't know its type from local information, I'd have to potentially look at the broader query.
In the case of offset I only need to look forward a token to see if the next token is a duration.

we could add additional caching headers to help them.

This is something different. My point is that cacheablitiy would be greatly diminished in practice, no matter what extra hints are sent back. A refresh of a graph pane always needs to reevaluate the entire range of the query. You could no longer re-use parts of results from previous queries using this feature, only entire other queries that have exactly the same start and end.

Continuing the discussion about the start, end, range, I also feel having just start and end would be confusing, the keywords right now don't have any types that can be used as a value somewhere.  And {start} or {$start} is also ruled out as it looks similar to a vector selector.
I see $xyz1 as a viable option which can explicitly be a "pre processor", something which is replaced before execution (and even before parsing the query if $ is not a valid character for label value)

And {start} or {$start} is also ruled out as it looks similar to a vector selector.

I wouldn't say they're fully ruled out. Python added {1, 2, 3} for sets when it already had {1: 2, 3: 4} for dicts. I'd be more worried that {} and $ are used by Grafana templating.

And {start} or {$start} is also ruled out as it looks similar to a vector selector.

I wouldn't say they're fully ruled out. Python added {1, 2, 3} for sets when it already had {1: 2, 3: 4} for dicts. I'd be more worried that {} and $ are used by Grafana templating.

grafana uses $var, ${var} and [[var]] IIRC.

How about {{ xyz }} then? Also since this is experimental AND behind a feature flag, I don't see a problem breaking this syntax and improving it based on the feedback that we receive.

That could also be an option, but might run into issues with other templating systems such as Jinga2 used by Ansible.

All familiar looking templating would be used somewhere :P
We can also call it out loud as TEMPLATE{xyz} :P or maybe just T{xyz} for example.
I am currently focusing on getting the @ implementation with just a unix timestamp working correct, I will jump into these template variables / pre-processors after that.

How about {{ xyz }} then? Also since this is experimental AND behind a feature flag, I don't see a problem breaking this syntax and improving it based on the feedback that we receive.

And threat this as golang/template, allowing to template full promql queries like alerting rules?

All familiar looking templating would be used somewhere :P

Yes, that's a big problem with layering templating systems. It's best to do it in only one place.

And threat this as golang/template, allowing to template full promql queries like alerting annotations?

That's a good point, that directly clashes with console/alert templating - so that's ruled out.

I'd say let's stick  with $end. Within grafana we would need to type $$end, not the end of the world.

I did not know we could escape $ with $$ in Grafana. Then I don't see a problem with $end at all.

I did not know we could escape $ with $$ in Grafana. Then I don't see a problem with $end at all.

mmh apparently that's not that easy after all... I don't remeber how to escape but  by default anyway it will send $end if you say $end unless there is a variable called  end

Keeping in mind that users will tend to directly copy expressions from Grafana into the expression browser and expect them to work, which is one of the reasons I was asking about interactions with Grafana templating.

@brian-brazil while I am adding more test cases, the PR is ready for another round of review

Don't try this at home, but I tried:
irate(label_join({__name__=~".*_bytes_.*"},"__name","","__name__")[5m:]) and (topk(5, max_over_time(label_join({__name__=~".*_bytes_.*"},"__name","","__name__")[5m:])) @1606838617 )

and got:
Error executing query: invalid parameter 'query': 1:79: parse error: @ modifier must be preceded by an instant or range selector or a subquery, but follows a *parser.AggregateExpr instead

We also do not allow ParetExpr:
Error executing query: invalid parameter 'query': 1:78: parse error: @ modifier must be preceded by an instant or range selector or a subquery, but follows a *parser.ParenExpr instead

That's all as expected.

Oh indeed.
However, this (bad) query created a panic:
irate(label_join({__name__=~".*_bytes_.*"},"__name","","__name__")[5m:]) and (max_over_time(label_join({__name__=~".*_bytes_.*"},"__name","","__name__")[1h]  @1606838617  ))

Because we do not set *timestampp
parser panic: runtime error: invalid memory address or nil pointer dereference
goroutine 159 [running]:
github.com/prometheus/prometheus/promql/parser.(*parser).recover(0xc0013a0000, 0xc001302f78)
        /home/roidelapluie/dev/prometheus/promql/parser/parse.go:274 +0x125
panic(0x2586b80, 0x42cdb50)
        /home/roidelapluie/godist/go/src/runtime/panic.go:969 +0x175
github.com/prometheus/prometheus/promql/parser.(*parser).setInstant(0xc0013a0000, 0x31bb780, 0xc0011f1a00, 0x41d7f19a56400000)
        /home/roidelapluie/dev/prometheus/promql/parser/parse.go:731 +0x5d
github.com/prometheus/prometheus/promql/parser.(*yyParserImpl).Parse(0xc0013a0078, 0x31bb980, 0xc0013a0000, 0x0)
        generated_parser.y:391 +0x4bc5
github.com/prometheus/prometheus/promql/parser.(*parser).parseGenerated(0xc0013a0000, 0xe046, 0xc0013a0000, 0xc0001c06f8)
        /home/roidelapluie/dev/prometheus/promql/parser/parse.go:644 +0x6d
github.com/prometheus/prometheus/promql/parser.ParseExpr(0xc0009de8f0, 0xad, 0x0, 0x0, 0x0, 0x0)
        /home/roidelapluie/dev/prometheus/promql/parser/parse.go:110 +0xdb
github.com/prometheus/prometheus/promql.(*Engine).NewInstantQuery(0xc0007843f0, 0x7f4b2e840358, 0xc000473800, 0xc0009de8f0, 0xad, 0x174e2fc0, 0xed7
586410, 0x0, 0x0, 0x0, ...)
        /home/roidelapluie/dev/prometheus/promql/engine.go:333 +0x3f
github.com/prometheus/prometheus/web/api/v1.(*API).query(0xc000165900, 0xc00121dd00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/roidelapluie/dev/prometheus/web/api/v1/api.go:355 +0x26b
github.com/prometheus/prometheus/web/api/v1.(*API).Register.func1.1(0x31dea80, 0xc0011f15c0, 0xc00121dd00)
        /home/roidelapluie/dev/prometheus/web/api/v1/api.go:265 +0xa2
net/http.HandlerFunc.ServeHTTP(0xc000970460, 0x31dea80, 0xc0011f15c0, 0xc00121dd00)
        /home/roidelapluie/godist/go/src/net/http/server.go:2042 +0x44
github.com/prometheus/prometheus/util/httputil.CompressionHandler.ServeHTTP(0x31a7b60, 0xc000970460, 0x7f4b2ea20478, 0xc000a954a0, 0xc00121dd00)
        /home/roidelapluie/dev/prometheus/util/httputil/compression.go:90 +0x7e

And my good query is not returning data ;) I suspect we do not pass data corretly to remote read?
irate(label_join({__name__=~".*_bytes_.*"},"__name","","__name__")[5m:]) and (topk(5,label_join( {__name__=~".*_bytes_.*"} @1606838617 ,"__name","","__name__")   ))

And my good query is not returning data ;) I suspect we do not pass data corretly to remote read?
irate(label_join({__name__=~".*_bytes_.*"},"__name","","__name__")[5m:]) and (topk(5,label_join( {__name__=~".*_bytes_.*"} @1606838617 ,"__name","","__name__")   ))

(this does not return data:)
{__name__=~".*_bytes_.*"} @<PHONE_NUMBER>

I suspect we do not pass data corretly to remote read?

Most likely. I guess it is via hints? I have added test more tests cases (pushing shortly) with maybe fixing issues that you have seen.

However, this (bad) query created a panic:

That would happen even if you use offset instead of @. I will fix both together.

Most likely. I guess it is via hints?

That's what my minTime comments related to.

@brian-brazil I have added more test case for @ in TestAtModifier in engine_test. Can you suggest more cases that I need to test? You had mentioned that the time functions could be broken

I don't see tests with @ milliseconds (@ 200.56) and with  multiple @ in one query

with multiple @ in one query

I have sum_over_time(sum_over_time(metric{job="1"}[100s] @ 100)[100s:25s] @ 50)[3s:1s] @ 3000 and couple others

Can you suggest more cases that I need to test?

I recommend you work on fixing the issues I've already raised first, such as the handling of functions not being correct.
Tests are about quality not quantity, and a lot of the tests currently are trivial happy path tests. In test terms you'd be far better off making the unittests handle all of that systemically (like how we check that no tests violate the instant evaluation vs range evaluation invariant), rather than creating lots of tiny tests by hand for all the basic stuff. This also makes it hard for me to figure out what has and hasn't been tested, as I'd have to look through 1k lines of uninteresting tests.

@ 0 is ignored at the moment

And since we have backfilling, I think we could have @ -1 working as well.

I have now updated the PR to just modify the offset of the selectors instead of playing with the timestamp everywhere. I feel it should be easier to review the PR now.
The flow is like 1. Wrap with the StepInvariant node -> 2. Finding the mint and maxt for TSDB and populating the series still uses the timestamps to be more accurate -> 3. Adjust the offset of the selectors w.r.t. the start time. A different handling of offsets for subqueries (you modify it twice) -> 4. Run the query as usual. StepInvariant node queries for 1 step and duplicates the result while also caching the result.
I will add more test cases for trickier cases and negative (and 0) timestamp (and also remove some test cases which are not needed). The PR is ready for another review otherwise.

Something just doesn't feel right with all the subquery handling here.

What exactly is that "something"? With the latest commit, subquery is also using the offset and not the timestamp directly. The setting of right offset has to change for subquery eval since the evaluator is changing.

What exactly is that "something"? With the latest commit, subquery is also using the offset and not the timestamp directly. The setting of right offset has to change for subquery eval since the evaluator is changing.

I don't know, the code is split across 4 disparate places and I've yet to get my head around it. But something feels off.

I think this is good for another review now. I have removed a lot of unwanted tests and fixed most of the comments. The sample limit and tests for 0 and float timestamps is yet to be added.

PR is ready for another review, I guess I have fixed all reviews. I will add the flag after I get a +1 on the @ implementation.

Plus: I would like to tackle docs in a follow up PR

What did you change for timestamp()? I didn't see any special casing in the engine (which is good).

The wrapping

Opened https://github.com/prometheus/prometheus/pull/8314 for refactoring TestMaxQuerySamples. Should be ready for another review.
I will add the docs and flag along with fix any comments in 2021. Merry Christmas and Happy New Year :partying_face:

Release date is approaching! It would be nice, of course, to have this in the next release, but note that the anticipated date to cut the RC is in two days (2020-12-30).

This won't make it in, there's still more work to be done and @codesome is on holiday this week.

Should be ready for another review. I have added the flag and docs.

Should be ready for another review. I have added the flag and docs.

Should be ready for another review. I have added the flag and docs.

Should be ready for another review. I have added the flag and docs.

I have fixed all the comments. I hope it is close to merge now :)

I have fixed all the comments. I hope it is close to merge now :)

(In case it was missed, the PR was ready for review after the last commit)

(In case it was missed, the PR was ready for review after the last commit)

:+1:

:+1:

I'm pretty sure one or two blog posts were written showing how to use this feature, but I can't find them.
Would someone post the link(s) please?

https://prometheus.io/blog/2021/02/18/introducing-the-@-modifier/


TransactionContextMiddleware seems unnecessary

The website, in the sections about Transactions, mentions to register the TransactionContextMiddleware in AppModule. I am using GraphQL and Fastify (in Nest 8). Fastify has no native middleware support which could be why I'm getting a very vague error from Middie (a middleware package for Fastify).
This would be a problem, but it seems the @Transactional decorator works fine. It shows a message in the console saying a transaction has started at the right moment in the code, and it cleans it up properly as well. What is the TransactionContextMiddleware supposed to do? Could it be depricated and the website not updated?

Hey @NilsMoller !! Happy new year!
Are you using Fastify via NestJS or directly?
TrasnactionContextMiddleWare does this:
 return inDrivineContext().run(async () => {
            this.transactionContext.databaseRegistry = this.databaseRegistry;
            return Promise.resolve(next());
        });

And what that does is just run a method inside a NodeJS AsyncLocalStorage context. This feature of NodeJS allows us to store information in call-chain (similar to a ThreadLocal in a traditional web server).
We also use it for the integration test feature where a transaction is started and rolled back when the test completes.
For transactions to work as expected, you need to set that up. I believe if you use Fastify via NestJS it will 'just work' in most cases, as their middleware is portable between the two platforms.
I'm guessing that's what you're doing. (I planned to publish NestJS support in a separate module, so people can use drivine anywhere, but never had time for that).

Thank you! Same to you!
I use Fastify with NestJS.

For transactions to work as expected, you need to set that up. I believe if you use Fastify via NestJS it will 'just work' in most cases, as their middleware is portable between the two platforms.

When I try to add the TransactionContextMiddleware in AppModule, it gives me the error below. Without it, the @Transactional decorator works fine. I have not checked the integration tests, but I presume they will not work as you said. Do you have any recommendations/have you seen this before? Otherwise I will have to start messing around with custom middleware to either wrap yours or write the same code.
When running with this:
export default class AppModule implements NestModule {
  public configure(consumer: MiddlewareConsumer): any {
    consumer.apply(TransactionContextMiddleware).forRoutes("**/**");
  }
}

it gives this error:
E:\Git_repos\content-experience-center-api\node_modules\middie\node_modules\path-to-regexp\src\index.ts:157
    throw new TypeError(`Unexpected ${nextType} at ${index}, expected ${type}`);
          ^
TypeError: Unexpected MODIFIER at 1, expected END
    at mustConsume (E:\Git_repos\content-experience-center-api\node_modules\middie\node_modules\path-to-regexp\src\index.ts:157:11)
    at parse (E:\Git_repos\content-experience-center-api\node_modules\middie\node_modules\path-to-regexp\src\index.ts:227:5)
    at stringToRegexp (E:\Git_repos\content-experience-center-api\node_modules\middie\node_modules\path-to-regexp\src\index.ts:493:25)
    at pathToRegexp (E:\Git_repos\content-experience-center-api\node_modules\middie\node_modules\path-to-regexp\src\index.ts:620:10)
    at Object.use (E:\Git_repos\content-experience-center-api\node_modules\middie\engine.js:23:16)
    at Object.use (E:\Git_repos\content-experience-center-api\node_modules\middie\index.js:26:21)
    at E:\Git_repos\content-experience-center-api\node_modules\@nestjs\platform-fastify\adapters\fastify-adapter.js:254:27
    at MiddlewareModule.registerHandler (E:\Git_repos\content-experience-center-api\node_modules\@nestjs\core\middleware\middleware-module.js:154:9)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

I don't know why it would throw that error. What do the NestJS docs say about using middleware with Fastify?
If it works without the middleware, then it means that the fastify endpoints are already running inside an async local storage context. This is plausible.
For tests you can just use the approach in the docs/instructions - on the website.

I was going to reply with a "Middleware is abstracted by Nest, which wraps any middleware using NestMiddleware, meaning there is no difference between express and fastify." I went to double check the docs, and it turns out there is one difference:

The fastify package uses the latest version of the path-to-regexp package, which no longer supports wildcard asterisks *. Instead, you must use parameters (e.g., (.*), :splat*).

Apparently the error I posted previously is what happens when the .forRoutes argument is invalid.
Thank you for your help once again!
For completeness sake, this is my current AppModule and it is working:
export default class AppModule implements NestModule {
  public configure(consumer: MiddlewareConsumer): any {
    consumer.apply(TransactionContextMiddleware).forRoutes("(.*)");
  }
}

Glad that you got it solved @NilsMoller !!


Add an Option to Display Non-Constant Strings

Ghidra uses "Default settings" for string mutability, which Hex-Rays uses a decompiler flag for it. Is it feasible for Ghidra decompiler to display all string literals whether they are constant or not?

As far as I know this is being done by the plugin, the decompiler itself I dont believe contains such a setting.  The default string settings you show is part of the Ghidra Java frontend and nothing to do with the decompiler backend.  Which means this would basically be an additional feature for the plugin.  As far as I know it tries to display all strings, is this not happening, mutable strings arent displayed?

Yes, strings in the mutable address parts are not displayed as strings, but as symbols.


Upper bounding step size to 1.0 for stability

In https://github.com/TuringLang/Turing.jl/pull/621 I added code to set an upper bound for the step size (https://github.com/TuringLang/Turing.jl/blob/89e012567774e2c4c749ce47646cc85be918a6e4/src/samplers/adapt/stepsize.jl#L97).
We would like to either formally justify this upper bounding or remove it when other stability issues is resoled.

Fixed by #709


Enable /chat and /chat_stream in watsonx.ai

In this PR I have added the ability to use the /chat and /chat_stream APIs in watsonx.ai.
Now the developer can choose with the property quarkus.langchain4j.watsonx.chat-model.mode whether to use the generate mode or the chat mode (default).
Using both modes allows the developer to use the tools in streaming mode. On this topic, it might be useful (as discussed with Clement) to have the possibility to use the @RunOnVirtualThread annotation for the tools' methods. Today the implementation is locked to Infrastructure.getDefaultWorkerPool().
A note about the PromptFormatter implementation. I didn't remove it because the /chat API can't be used with all the models provided in watsonx.ai. I'll remove it when this limitation is no longer there.

Thanks!
I'll have a look tomorrow


Question: how do I get Id token from signout request?

The case is: I need to call admin.auth().revokeRefreshTokens(uid) at the sign out request.
The problems:

tokenChangedHandler only has a token at sign in and I can't set a header at sign out
It's said in readme Future requests to SSR pages receive the user info and ID token from cookies, but there is no example how to verify cookies, and admin.auth().verifySessionCookie fails to accept cookies I can take from req and there is no ID token in req.

Going to close this, but we can reopen if you run into problems.


First attempts

So I have been following this project with anticipation, and finally decided to give it a go.

simple but obvious, the cmake is missing the main :)
the vocab.bin ships with the repo, so why require it for the conversion (i commented it out)
running main yields in a allocation error, trying to allocate 47GiB :rofl:

$ ./main -m models/bark_v0/
bark_model_load: loading model from 'models/bark_v0/'
bark_model_load: reading bark text model
gpt_model_load: n_in_vocab  = 129600
gpt_model_load: n_out_vocab = 10048
gpt_model_load: block_size  = 1024
gpt_model_load: n_embd      = 1024
gpt_model_load: n_head      = 16
gpt_model_load: n_layer     = 24
gpt_model_load: n_lm_heads  = 1
gpt_model_load: n_wtes      = 1
gpt_model_load: ggml tensor size = 272 bytes
gpt_model_load: ggml ctx size = 1894.87 MB
gpt_model_load: memory size =   192.00 MB, n_mem = 24576
gpt_model_load: model size  =  1701.69 MB
bark_model_load: reading bark vocab

bark_model_load: reading bark coarse model
gpt_model_load: n_in_vocab  = 12096
gpt_model_load: n_out_vocab = 12096
gpt_model_load: block_size  = 1024
gpt_model_load: n_embd      = 1024
gpt_model_load: n_head      = 16
gpt_model_load: n_layer     = 24
gpt_model_load: n_lm_heads  = 1
gpt_model_load: n_wtes      = 1
gpt_model_load: ggml tensor size = 272 bytes
gpt_model_load: ggml ctx size = 1443.87 MB
gpt_model_load: memory size =   192.00 MB, n_mem = 24576
gpt_model_load: model size  =  1250.69 MB

bark_model_load: reading bark fine model
gpt_model_load: n_in_vocab  = 1056
gpt_model_load: n_out_vocab = 1056
gpt_model_load: block_size  = 1024
gpt_model_load: n_embd      = 1024
gpt_model_load: n_head      = 16
gpt_model_load: n_layer     = 24
gpt_model_load: n_lm_heads  = 7
gpt_model_load: n_wtes      = 8
gpt_model_load: ggml tensor size = 272 bytes
gpt_model_load: ggml ctx size = 1411.25 MB
gpt_model_load: memory size =   192.00 MB, n_mem = 24576
gpt_model_load: model size  =  1218.26 MB

bark_model_load: reading bark codec model
encodec_model_load: model size    =   44.32 MB

bark_model_load: total model size  =  4170.64 MB

bark_generate_audio: prompt: 'this is an audio'
bark_generate_audio: number of tokens in prompt = 513, first 8 tokens: 20579 20172 20199 33733<PHONE_NUMBER>95<PHONE_NUMBER>95
bark_forward_text_encoder: ...........................................................................................................

bark_forward_text_encoder: mem per token =     4.80 MB
bark_forward_text_encoder:   sample time =    17.30 ms
bark_forward_text_encoder:  predict time =  6746.21 ms / 18.48 ms per token
bark_forward_text_encoder:    total time =  6825.61 ms

bark_forward_coarse_encoder: ...................................................................................................................................................................................................................................................................................................................................

bark_forward_coarse_encoder: mem per token =     8.51 MB
bark_forward_coarse_encoder:   sample time =     4.79 ms
bark_forward_coarse_encoder:  predict time = 30730.57 ms / 94.85 ms per token
bark_forward_coarse_encoder:    total time = 30784.73 ms

fine_gpt_eval: failed to allocate<PHONE_NUMBER>6 bytes
bark_forward_fine_encoder: ggml_aligned_malloc: insufficient memory (attempted to allocate 47874.75 MB)
GGML_ASSERT: ggml.c:4408: ctx->mem_buffer != NULL
Aborted (core dumped)

Hello @Green-Sky ! Thanks for your interest in bark.cpp and for reporting these bugs. This is very valuable.

Thanks for catching that. Could you submit a PR to fix this?
You're right. vocab.bin is in the repo so that the test-tokenizer script can run.
Ouch... I have never faced such a bug in all the experiments I made. In any case, it's interesting to see that this excessive memory allocation occurs for the fine encoder, as it is the one which does not pass a unit test I wrote to compare the output against the original bark implementation. Are you able to track down which node in the computational graph is responsible for this excessive memory allocation?

sure will do, will orient myself on ggml/llama.cpp
actually, we might need to be careful here, in case we have different vocab/tokenizers. I know llama.cpp optionally lets you define a vocab, but uses the default by default (see llama.cpp convert.py)
ehh. maybe? did not work with ggml ml specific code yet, would be nice to be given some pointers here.

ran it in the debugger:
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7a52859 in __GI_abort () at abort.c:79
#2  0x00005555555a3f4c in ggml_init (params=...) at /home/green/workspace/bark.cpp/ggml.c:4410
#3  0x0000555555565422 in fine_gpt_eval (model=..., n_threads=4, codebook_ix=3,
    embd_inp=std::vector of length 8, capacity 8 = {...},
    logits=std::vector of length 2, capacity 2 = {...}, mem_per_token=@0x7fffffffba28: 5106640)
    at /home/green/workspace/bark.cpp/bark.cpp:555
#4  0x000055555556fbb9 in bark_forward_fine_encoder (
    tokens=std::vector of length 162, capacity 256 = {...}, model=..., rng=..., n_threads=4, temp=0.5)
    at /home/green/workspace/bark.cpp/bark.cpp:1494
#5  0x0000555555571f8e in bark_generate_audio (model=..., vocab=..., text=<optimized out>, n_threads=4)
    at /usr/include/c++/9/bits/stl_tree.h:129
#6  0x000055555555c6e3 in main (argc=<optimized out>, argv=<optimized out>)
    at /usr/include/c++/9/bits/basic_string.h:2316

Closing as this should be fixed with #139 . Feel free to share your feedbacks @Green-Sky in another issue :)


chore(package): update moment to version 2.19.1

Codecov Report

Merging #140 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #140   +/-   ##
=======================================
  Coverage   83.16%   83.16%
=======================================
  Files          11       11
  Lines         594      594
  Branches      181      181
=======================================
  Hits          494      494
  Misses        100      100

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 55cb4f1...6b3358a. Read the comment docs.

Coverage remained the same at 78.419% when pulling 6b3358a9ec03304d41f0d8b11c5181f7b6cb1ef6 on greenkeeper/moment-2.19.1 into 55cb4f1f82e3a2cb6f84a9b56f493726d394bbdb on master.


A simple mobile app

Hi Harish
I have a small mobile app that I need to develop as soon as possible. Could you pl. help me develop it using this kit? I do not have any contact id / phone where I can reach you out, therefore reaching you out here. My email id is<EMAIL_ADDRESS>Kindly contact me asap.
Thank you

I do not have Telegram.. Kindly send me your mobile phone

Please reply me on mail thanks

What is your email, kindly share

Okay I got it. Thanks


filer server concern the lead change

Chris
I made some code change for filer, please take a review,thanks!

Thanks!!!


Add patterns submodule repo

@Jim-Parker Added submodule to support patterns governance / pattern templates.

@mattbriggs so I understand what I'm merging, where is this file being added?

This is the repo that contains the templates that are governed by the pattern program.
We briefly discussed but we may need to talk through the nuts and bolts and find out if this is an approach you like.
https://github.com/MicrosoftDocs/content-patterns

From: Jim Parker @.>
Sent: Monday, June 12, 2023 6:44 AM
To: MicrosoftDocs/content-templates @.>
Cc: Matt Briggs @.>; Mention @.>
Subject: Re: [MicrosoftDocs/content-templates] Add patterns submodule repo (PR #26)
@mattbriggshttps://github.com/mattbriggs so I understand what I'm merging, where is this file being added?
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/content-templates/pull/26#issuecomment-1587372767, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMPCVSEQLBMW4HFHBOW3ALXK4MKRANCNFSM6AAAAAAZBHSLKA.
You are receiving this because you were mentioned.Message ID: @.***>


Experiment link returns 404

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to 'Pipelines'
Click on 'Experiments'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

If applicable, add screenshots to help explain your problem.
Environment

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
MLX Version [e.g. 22]

Additional context
Add any other context about the problem here.

Hi @JiaxuanYang can you describe how you deployed this instance of MLX? I.e. is this on IKS or OpenShift (IBM Cloud or Fyre) or a local Kind deployment?

I deployed it locally

I deployed it locally

With KIND I suppose (Kubernetes version 1.21)? And your port-forward is not to the mlx-ui directly but to the istio-ingress service?
When you use your browser developer tools, what do you see in the network traffic log when you click on experiments?

@JiaxuanYang besides clearing browser cookies (private window), could you check if all of the kubeflow pods came up fine?

Actually, there still is an issue here. Although the VIEW EXPERIMENTS link works for cluster deployments (incl. KIND), it does not work for the local Quick-Start deployment with docker compose. For that we should disable (remove) the "VIEW EXPERIMENTS" link.


print() to sys.stdout if it's not actually stdout

This allows e.g. contextlib.redirect_stdout to work with print()

I don't think I know enough about this topic. Could anyone review this PR? @palaviv @windelbouwman


feat: add Discord android playstore link

Description
Add Discord Android Playstore URL after Discord announce to use React Native for Android https://discord.com/blog/android-react-native-framework-update

Hello @akinncar, thank you for the update, but I'm going to close this one, since we are working on the Showcase update which will include he Discord Android app addition as well as various other changes and I want to avoid conflicts.
Superseded by #3235.


Update xpp module

Fix #1980

I don't know why we never ran into any issues with this. That commit hash shouldn't even be in our repo.


feat(c/driver/postgresql): TimestampTz write

closes #867
The lifecycle of setting the session time zone in this isn't great. I think should be handled during connect somehow? But not sure if postgres even supports that reading things like:
https://stackoverflow.com/a/11779621/621736
I think there is also something awry with the release callback for timezone schemas; needs further investigation

Think the polars issue is unrelated


create a page for how to log progress in the registry

describe the metadata file

created the page ✅
now on to writing the content

revamped to turn this page into the first step of the workflow


Commit hash for 6.6.7? (Please use git branches/tags to denote versions.)

TLDR: Please can you point me to the commit for v6.6.7 so I can branch off and submit a PR?

 We are using it on our first site, and we've been so impressed by it we've paid for an unlimited license to try to offer some kind of support. I know it isn't much, but anyway...
I'm having a problem that I haven't created an issue for yet, I'm hoping to resolve it and submit a PR rather than just create an issue, but I've hit a couple of stumbling blocks.
I'm using version 6.6.7, but the code is obfuscated (with all the whitespace and comments stripped out) as part of your build process. I could add whitespace back in, but I wouldn't be able to submit a PR cleanly as the formatting would be different and comments would be stripped.
So I look at the repo on here, but you are now working on the next major version, so master isn't the point of the currently released version. So then I look at the branches and the tags, but none of those appear to be for version 6.6.7.
So then I try searching for 6.6.7 and nothing comes up, I did find a commit for 6.6.6 though, which leads me to start browsing the history of the readme.txt file, but I can't find the point at which it is updated to 6.6.7.

I think I may have figured it out. The release notes for 6.6.7 are to update a problem in the README, so it might just be that was never committed to the repo (just edited in the previously built obfuscated files) and re-submitted to WP Plugins.
I will base my PR off of 6.6.6 and hope for the best:
https://github.com/WP2Static/wp2static/commit/a71e5ca8114e678e8917f47b19ac200248dc5831

@lukearmstrong I think what is likely is that I'll open up another repo for v6x as it's such a different beast.
It's been an awkward shift to V7 and I've changed decisions throughout the process - benefit and downside of being solo developer.
Tagging does need to come back, it's been partly due of hard pushing people to V7, getting annoyed with sharing releases via GitHub (many users downloaded the snapshot of repo zip's vs installer zips added to GH release page last time, so I got over enthusiastic with deleting tags).
There seems to be enough interest in users of V6 to warrant keeping a repo, receiving PRs and (possibly) offering V6 builds to users, with one user already offering to support a fork.
Thanks for your patience with all this and for providing such detailed issues, really appreciated!
Cheers~

Setting up the new repo now.
I may have just bumped the version number in the SVN repo wp.org uses: https://plugins.svn.wordpress.org/static-html-output-plugin/tags/
There shouldn't be much difference from 6.6.5-7

@lukearmstrong have set up the repo at https://github.com/wp2static/wp2static-v6
I will (slowly) move the issues over that are relevant and check any pending PRs.
Feel free to submit any PRs here.
I have a few common issues to add/resolve for V6 and will use similar linting/static analysis tooling as in V7.

@leonstafford Thanks for doing that, that's really helpful. Thanks for responding to all of my issues, I find it a bit daunting commenting on an open source project, as it's very easy to come across as unappreciative and get an unpleasant reply.
I may try to submit PRs for the two issues I came up against.
The HTML one may be fixed by using different parsing settings or output methods from the DomDocument() class. The CSS one may be fixed by implementing a checkbox to ask if they want CSS to not be processed. (May be simpler than trying to fix the issue with the underlying parser library, unless this is a bug and has been fixed upstream)
The site I used v6 on was for a client project at work, which is why I picked the stable release.
As you are now working towards a v7 release, I'm going to try v7 on our own agency site, even though it is alpha, so hopefully I can offer some PRs if I come up against any issues. I'll let you know how I get on.
Thanks again for making this plugin, I wish I had found about it sooner as it solves so many issues with hosting a public WordPress site.

@lukearmstrong you're more than welcome!
I try to empathise, as I've been that frustrated/angry commenter on projects before. For WP plugins, it's most annoying when they come in the wp.org Reviews page, getting a low review and complaint of an issue vs opening a support request!
Got to have thick skin for those and if it's an actual fault of the software, good to be called out on it :D
I really appreciate anyone who's taken the time to file an issue or submit code. It's embarrassing to know people have read through the V6 codebase, last time I went to quickly lookup a JS issue, I needed a shower afterwards! So, will be glad to get that cleaned up and some of the long time issues fixed.
I thought I had a "Parse CSS" checkbox in V6, but it may have been in the first attempt at V7, which is quite different again from today's.


Use the version instead of the url for emojify.

I have an issue when installing the plugin, related with emojify. Probably this will fix it. @Glavin001 could you review this PR?

Looks good to me. However @wesleycoder could you please squash these commits. Thanks!


initial files

Added initial files and connection, server.js info.  Took a stab at models and typeDefs.  These need reviewing.


Pick plane color in FFA

Would it be possible/easy to add the ability to decide which player/bot spawns as which plane color?
This is mostly intended for FFA where players spawn with random colors, so forcing specific colors on them shouldn't break gameplay, right?
You might be wondering why I want to decide the color of planes in FFA, it's to give players the ability to customize. Altitude doesn't exactly offer a lot of character customization, and having a command with which players can decide their color would be great for that.
So ideally there'd be a command and options like:
/planeColor green playername
The color could be replaced by none, random, false, etc to get back to the default.
The playername could be omitted to use it on yourself. Only admins can use it on others.
Option to enable/disable usage of /planeColor for non-admin players.
My idea for this is to have paint shops for each color on my MMORPG map/server and let players buy a different color with in-game currency.
I assume plane color and team assignment and treated as one and the same in Altitude, so it wouldn't be possible to let players spawn as different colors while still being part of their team, right?

So, you need Xal's server patches to do this, but it is actually very doable as long as his patches are loaded.
You should think about how you would want this to work more.  You could allow players to specify their color as a perk.  You could also use the colors for levels, and show each player what level another player was by their color (e.g. red is level 1, and brown is level 9).
The way this works now is, in ffa, you assign the players to a team.  Each team number has a color associated with it.  So, if you had a player stored in object $p, you would run plus::assign($p, 'green') to assign the player stored in the $p object to the green team, and therefore change their plane color to green.
So, the basis for the code is all there.  You would just have to figure out if you needed to add your own command to allow players to set this themselves, or if you would prefer to hold onto it for yourself for some other purpose.

levels

Nice idea, and that would definitely fix the problem with getting player level to be visible to everyone else in-game (without having to use commands), but I'm not sure if it's worth the tradeoff of letting go of customization options. Also players might not like the color that I assigned to their level (i prefer the ace 9 icon over the ace 10 one in alti~), I don't want players to have to fly around in colors they don't like.
So technically ffa has teams in it, it just doesn't care about them and even allows friendly fire~
I see, I think I'll be going with: assign random color at first join; and later on allow players to change it via in-game shops. the powerup will have to check for player permission (requires specific quest or something so it's unlocked), currency (takes x coins, not useable if player has less than x), and also a countdown so it doesnt  buy it ten times while the player flies through (i guess that can be handled via powerup properties in the map editor), potentially also check if the player already has the color he wants to buy~
I don't think it's possible to set that a powerup at a specific location executes a command upon pickup, via the plus.txt, is it? Should be doable via script though just fine, right?

Correct, you would want a hook for powerupPickup and you could check the coordinates.  If you are going to do it a lot, I would recommend having one of the first lines be my($powerup)=join(',', @$e{'positionX','positionY'});, I have that line in the base code's powerupPickup hook.  This will allow you to check pickups like: if($powerup eq '123,456') {  Or, if you wan't to get fancy and have a lot of custom functions you could do something like:
MAP 'ffa_foomap';

my(%POWERUPS)={
    '123,456' => sub {
            my($p)=@_;
                  ...
         },
    '1000,500' => sub {
            my($p)=@_;
                  ...
        },
};

...

HOOKS {
    'powerupPickup' => sub {
        my($e, $p)=@_;
        my($powerup)=join(',', @$e{'positionX','positionY'});

        if(exists($POWERUPS{$powerup})) {
            $POWERUPS{$powerup}->($p);
       }
    },
}


Support long lines

This plugin is great, but I seem to be able to make it stop working..by having a long string concatination.
Look at this example:
var bar = "hello";
return "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean eget elit euismod, porttitor neque vitae, scelerisque dui. Sed luctus lorem at mollis euismod. Praesent mi lectus, vulputate eget sodales sed, viverra id enim. Quisque no" + bar;

This throws an error - 'Bar' is defined ut never used. W098
However if you remove 1 character from the string
var bar = "hello";
return "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean eget elit euismod, porttitor neque vitae, scelerisque dui. Sed luctus lorem at mollis euismod. Praesent mi lectus, vulputate eget sodales sed, viverra id enim. Quisque n" + bar;

It works.
(250 chracter limit)

https://github.com/MiguelCastillo/Brackets-InteractiveLinter/issues/34

added better detection of minified javascript.  The linter should be able to handle your sample code correctly. please let me know if you run into other issues.