The real name of the assets in debug mode

Hello,
I tried to have the real names of my assets in debug mode.
I have this :
<link title="defaut" type="text/css" rel="stylesheet" href="min/min_part_1.css" media="screen">
<link title="defaut" type="text/css" rel="stylesheet" href="min/min_part_2.css" media="screen">

And I would want :
<link title="defaut" type="text/css" rel="stylesheet" href="lib/reset.css" media="screen">
<link title="defaut" type="text/css" rel="stylesheet" href="style.css" media="screen">

For debugging it's realy hard to know the good file.
How I can have the real names of my assets ?
Thanks

this is not possible, because even in debug mode, the asset being sent may not be the source file. Some filters also apply in debug mode (for instance the less and sass ones).
And btw, files could also be combined even in debug mode if you ask for it (by default, combining files depends on the debug mode, but this is only a default), so that's another reason for assets not being the source.
And last, the source file may not be in a location accessible publicly btw.

Ok and why the files min/min_part_1.css and min/min_part_2.css are not dumped ? I have no files in the min directory. Only the min.css
I missed something but I don't know what ... And I don't have the code now sorry

well, are you dumping in debug mode or in no-debug mode ? If you dump in no-debug mode, debug files will not be dumped

This is my code :
$yui_css = new Yui\CssCompressorFilter(__DIR__ . '/compressors/yuicompressor.jar');
$rewrite_css = new CssRewriteFilter();
$yui_js = new Yui\JsCompressorFilter(__DIR__ . '/compressors/yuicompressor.jar');

// Create the collection
$collectionCss = new AssetCollection();
$collectionJs  = new AssetCollection();

// Create the cache
$cache = new FilesystemCache($config['folders']['cache'] . '/assetic');

// Loop through file paths
$finder = new Finder();
$finder->files()->in(array(
    $config['folders']['public'] . '/css',
    $config['folders']['public'] . '/js',
))->name('*.css')->name('*.js');

foreach ($finder as $file) {
    // Create the asset
    $asset = new FileAsset($file->getPathname());

    // Add the filter, for example CSS minification
    if($file->getExtension() === 'css') {
        $asset->ensureFilter($yui_css);
        $asset->ensureFilter($rewrite_css);
    } else {
        $asset->ensureFilter($yui_js);
    }

    // Cache the asset so we don't have to reapply filters on future page loads
    $cachedAsset = new AssetCache($asset, $cache);

    // Add the cached asset to the collection
    if($file->getExtension() === 'css') {
        $collectionCss->add($cachedAsset);
    } else {
        $collectionJs->add($cachedAsset);
    }
}

$am = new AssetManager();
$am->set('base_css', new GlobAsset($config['folders']['public'] . '/css/*.css'));
$am->set('lib_css', new GlobAsset($config['folders']['public'] . '/css/lib/*/*.css'));
$am->set('base_js', new GlobAsset($config['folders']['public'] . '/js/*.js'));
$am->set('lib_js', new GlobAsset($config['folders']['public'] . '/js/lib/*/*.js'));

$fm = new FilterManager();
$fm->set('yui_css', $yui_css);
$fm->set('rewrite_css', $rewrite_css);
$fm->set('yui_js', $yui_js);

$factory = new AssetFactory($config['folders']['public'], !$config['prod']);
$factory->setAssetManager($am);
$factory->setFilterManager($fm);

$view->addExtension(new AsseticExtension($factory));

$lazyAssetManager  = new LazyAssetManager($factory);
$lazyAssetManager->setLoader('twig', new TwigFormulaLoader($view->getEnvironment()));

$finder = new Finder();
$finder->files()->in($config['folders']['views']);
foreach ($finder as $file) {
    $tmplBasePath = ltrim(str_replace($config['folders']['views'], '', $file->getPath()), '/');

    $lazyAssetManager->addResource(new TwigResource($view->getLoader(), $tmplBasePath . '/' . $file->getBasename()), 'twig');
}

// If the minified file doesn't exist OR the minified file is out of date, write it to the file system
if (!file_exists($config['folders']['public'] . '/min/min.css') || $collectionCss->getLastModified() > filemtime($config['folders']['public'] . '/min/min.css')) {
    file_put_contents($config['folders']['public'] . '/min/min.css', $collectionCss->dump());
}
if (!file_exists($config['folders']['public'] . '/min/min.js') || $collectionJs->getLastModified() > filemtime($config['folders']['public'] . '/min/min.js')) {
    file_put_contents($config['folders']['public'] . '/min/min.js', $collectionJs->dump());
}

I dump the files now in no debug mode because, in debug mode I don't see the file min/min_part_1.css and min/min_part_2.css
And in debug mode, it's possible to have a better name of my assets ? Like min/min_reset.css and min/min_style.css. For debugging file it's better

See https://github.com/symfony/assetic-bundle/blob/0241b135ff64c6031048c6425cd833a8300da46b/Command/AbstractCommand.php#L45 for the logic dumping assets in AsseticBundle

Ok but how I can get the name of the file for debugging ?


Run examples instead of just wave-eager.

Sorry, just one more.  I only noticed this after watching CI.  Thought we had updated this to exercise all the examples instead of just wave-eager.   Note that if this gets merged, it will also try to automatically run the MPI examples - so if there are MPI examples and the CI host is not set up to run mpiexec, then that CI step will fail.

I think you had added this for mirgecom before (https://github.com/illinois-ceesd/mirgecom/pull/55) not emirge.

You must be right.


feat(security): Add runAsUser/runAsGroup to containers

Signed-off-by: Bryon Nevis<EMAIL_ADDRESS>

@lenny-intel


Ch 5 - changed alphabeta to alphaBeta in index.html

I forgot to fix this bug in my original commit for chapter 5:
https://github.com/aimacode/aima-javascript/issues/78
Edit
I also added a feature for chapter 3 requested here:
https://github.com/aimacode/aima-javascript/issues/119

Cool, the hover effect is nice. For bug #119 we'll also want to make the same thing across diagrams. Do you want to make that change here, or should I check in this change for the node expansion diagram, and then we can leave that bug open for the other diagrams?

It was an easy fix, I'll work on implementing it for others.

I added the zoom effect for dfs, bfs, uniform search, and A*.

Looks great! For the A* diagram (which was implemented by a different author) it seems to be behaving differently — it's changing the circle on the right to red instead of changing its size like the other diagrams.

Yeah they use completely different methods of rendering. A* is all inline html and css, so if I expand a node it messes up the entire diagram. I could rewrite it all in Two.js, or maybe I can change the other diagrams to turn red instead of expanding.

Thanks! Consistency is good. I did like the other style better but this works too. Which do you prefer?


Unable to reference external Json in 2.0 spec

Spec 1.2:
{
"apiVersion": "1",
"swaggerVersion": "1.2",
"basePath": "http://localhost",
"apis": [
{
"path": "/swagger/api-docs/External", // This would return a stattic swagger spec on its, generated dynamically. It worked fine in 1.2 spec
"description": "Description"
},
]
}
Spec 2.0:
{
"swagger": "2.0",
"host": "http://localhost",
"basePath": "/",
"paths": {
"/swagger/api-docs/External": // How to return API doc here from another site???
}
}
I can see in swagger spec 1.2 the documentation for basePath was:
"The root URL serving the API. This field is important because while it is common to have the Resource Listing and API Declarations on the server providing the APIs themselves, it is not a requirement. The API specifications can be served using static files and not generated by the API server itself, so the URL for serving the API cannot always be derived from the URL serving the API specification. The value SHOULD be in the format of a URL."
This is exactly the feature im trying to accomplish with 2.0. Am i missing something, or is this feature left out?

basePath has nothing to do with referencing external JSON. If the swagger file is missing host and basePath then you can assume the host the served the swagger file is the host that provides the web services. basePath is an optional part of the full url that comes between the host and the operation's path. (host + basePath + path == url).
Splitting a swagger spec into multiple files in 1.2 was about creating categories of operations. In version 2 you put everything in one file and use tagging to categorize operations.

Hi @chasetec
Thanks for getting back. I think I've not clearly stated my problem. We are having several ASP.NET Web API's hosted on different sites (on the same server right now). We are using https://github.com/domaindrivendev/Swashbuckle for generating JSON spec on the fly from the Web API sites.
When using 1.2 of swagger spec, the following works fine:
https://gist.github.com/tynor88/d502e611cd3bcc7ae88f.js
The "path" element is pointing to another Web.API, which returns swagger spec on the fly. Swagger will in this case call this url, and get the swagger spec returned. I am trying to accomplish the same thing with 2.0 with swagger, but it seems swagger is never trying to call the website (I can see that in Fiddler).

@tynor88 - If you're looking for a way to collect several microservices hosted on different machines into a single spec, that's something that we haven't released yet.
Otherwise, I'm not sure what's your intention.

@webron But this is already working perfectly fine with Swagger 1.2 using the "apis" array in the Json. Is this not going to be supported by the 2.0 spec?

It's going to be supported in a different way.

Ok thanks for getting back. I will keep an eye for it, in the upcoming releases :+1:

Is it possible to divide operations into multiple json files in 2.0 ? If it is possible , how ? If is not possible with 2.0 , then the only choice we have is to use 1.2 spec.

This is the exact feature i am missing too. It was supported in 1.2 but it seems it is not supported yet in 2.0. @webron said earlier in this thread, that this is something that is going to be supported in a different way. Though I haven't found a work item for this yet.

Based on the reply by @webron ( "It's going to be supported in a different way" ) , i understand that operation grouping is done via tags. But , can we group the operations in multiple json files which eases the maintenance, increases the clarity and readability and decreases the complexity of having every operation in one file ?

I really wish I had a clear update on this issue, but unfortunately not yet. We have a plan, but we need to finalize it. I'll see what we can do in order to push it faster.

Some parsing libraries (such as Swagger Parser and Swagger Tools) allow external files and URLs to be referenced using $ref.   For example:
{
  "swagger": "2.0",
  "info": {
    "version": "1.0.0",
    "title": "Swagger Pet Store",
    "description": "This file includes $refs to external files"
  },
  "paths": {
    "/pets": {
      "get": {
        "responses": {
          "default": {
            "description": "references the pet.json file",
            "schema": {
              "type": "array",
              "items": {
                "$ref": "pet.json"
              }
            }
          }
        }
      }
    }
  }
}

I don't think that covers what @prashanthpatha is looking for.

Ah, ok.   I just re-read it, and it seems to me that he's wanting to reference external files for entire operations and/or paths.   Swagger Parser supports that too:
{
  "swagger": "2.0",
  "info": {
    "version": "1.0.0",
    "title": "Swagger Pet Store",
    "description": "This file includes $refs to external files"
  },
  "paths": {
    "/pets": {
      "get": {
        "$ref": "getPets.json"
      },
      "post": {
        "$ref": "postPets.json"
      }
    },
    "/pets/{name}": {
      "$ref": "petByName.json"
    }
  }
}

Again, I don't think that answers the request. It's not about splitting specific paths to different files but groups of paths to different paths. If there are 100 paths and each is described in a different file, it may be as unmaintainable as a single file.

hmmm.... ok then.    I've got nothing.  :)

@BigstickCarpet - don't get me wrong, I appreciate the comments. Didn't mean to discourage you or anything.

No worries.  No offense taken.  You know I love you guys.  :)

What @webron has pointed out is exactly what i am looking for. However thanks for the replies and looking forward to the future release to support it.

@webron any update on microservices support you reference above? Thanks!

@tmcdonnell87 - can you tell me what aspect of support are you looking for in your case?

We support a collection of services running on different servers, such as node.example.com, cxf.example.com, etc. In some cases, a service like cxf.example.com/foo might be running on a separate server than cxf.example.com/bar.
With swagger 1.2, you could have one hosted resource list that had each path as the API declaration on each server. With 2.0, I'm having trouble figuring out how that would be done, and your comment

If you're looking for a way to collect several microservices hosted on different machines into a single spec, that's something that we haven't released yet.

seemed quite promising. Though that was six months ago, and I haven't found any info about it being released.
Thanks for the quick reply!

So, the official support for it isn't quite out there and may only be part of the next version of the spec.
However, if you want to host several listings under a single swagger-ui, that's doable. Would that suffice for now?

You mean set up a proxy to combine them? Or multiple json files in the swagger ui?

Multiple jsons in the UI. A proxy won't help in this case.

@tmcdonnell87 For now we just merge the multiple specs, in to one spec ourselves. This is not elegant, but the only way to support micro services so far.
This feature worked in swagger 1.2 but unfortunately not in 2.0. I hope to see this again though in a future version of swagger-spec, as building microservices is a quite popular architecture style for larger applications.

While I normally don't comment about the probability of a one feature or another to actually make it into the next version of the spec, I can say that in this case the odds are 100% that it makes it in.

@webron Sounds good, will be looking forward to see this feature :+1:

Thanks @webron. Looking forward to it.

Any new status on this?

@webron did this feature that had 100% odds of making it in make it in to whatever release you were talking about?  I confess I haven't slogged through this whole thing to figure out what that might be.

I don't recall :(

@webron well if it's still important I imagine someone will eventually complain ;P


Example combining <!> default values and <?> documented fields?

The docs have examples using <?> for documentation and an example using <!> for default values. It's not obvious (to me at least) how to use them together. Could you provide an example of this?

Here is an example of using both:
{-# LANGUAGE DataKinds          #-}
{-# LANGUAGE DeriveGeneric      #-}
{-# LANGUAGE FlexibleInstances  #-}
{-# LANGUAGE OverloadedStrings  #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeOperators      #-}

import Options.Generic

data Example w = Example
    { foo :: w ::: (Int    <?> "Documentation for the foo flag" <!> "1"  )
    , bar :: w ::: (Double <?> "Documentation for the bar flag" <!> "2.0")
    } deriving (Generic)

instance ParseRecord (Example Wrapped)
deriving instance Show (Example Unwrapped)

main = do
    x <- unwrapRecord "Test program"

    print (x :: Example Unwrapped)


Reveal: Cannot read property 'bg_class' of undefined

This is directly related to #3766.
When modals are generated after Foundation is initialized, it seems possible for them to not have reveal-init settings. I've run into this bug during a project where the modals are generated by an Angular directive. The bug occurs when you attempt to click the modal's .close-reveal-modal button.
I've been able to remedy this locally by defaulting settings to the default settings object in the touchend.fndtn.reveal and click.fndtn.reveal events handler.
I've submitted a pull request (#5282) that implements this change in foundation.reveal.js.

Look like this was closed with PR https://github.com/zurb/foundation/pull/5282


This can enter in conflicts with the design of some CSS frameworks (with a very specific expected DOM structure) and preventing the reuse of generic components then.
It is also surprising this can't be added on custom elements...
Besides all that, using an attribute for that purpose could potentially enter in conflict in case that attribute would be relevant on an element, primary or custom.
Proposal
Introduce a {#slot slotname}{/slot} statement, which would solve all issues: allows text nodes only, allows list of elements, allows custom components.
It's also very concise and logical and there's already the code base to support such statements (it's like if, each and so on).

I forgot the case of using contextual variables (the "lets"). Syntax could be:
{#slot name with prop1, prop2 as aliasProp2}
{/slot}


EIP1559 Fix testnet issues part2

Signed-off-by: Karim TAAM<EMAIL_ADDRESS>PR description

Merge PR #1176
Update eip1559 Pool and Legacy pool part based on the last version of the EIP (https://eips.ethereum.org/EIPS/eip-1559).
there was also a problem converting long to int which made the value invalid

- EIP1559_INITIAL_GAS_TARGET: BLOCK_GAS_TARGET / 2. The maximum amount of gas that EIP-1559 transactions can use in INITIAL_FORK_BLOCK_NUMBER.
- LEGACY_INITIAL_GAS_LIMIT: BLOCK_GAS_TARGET / 2. The maximum amount of gas that legacy transactions can use in INITIAL_FORK_BLOCK_NUMBER.
- EIP1559_GAS_TARGET: The target gas used by EIP-1559 transactions in a given block.
if CURRENT_BLOCK_NUMBER >= FINAL_FORK_BLOCK_NUMBER then
  BLOCK_GAS_TARGET
elif CURRNT_BLOCK_NUMBER < INITIAL_FORK_BLOCK_NUMBER then
  0
else
  EIP1559_INITIAL_GAS_TARGET + (BLOCK_GAS_TARGET / 2) * (CURRENT_BLOCK_NUMBER - INITIAL_FORK_BLOCK_NUMBER) / MIGRATION_DURATION_IN_BLOCKS
- LEGACY_GAS_LIMIT: BLOCK_GAS_TARGET - EIP1559_GAS_TARGET. The maximum amount of gas legacy transactions can use in a given block.
- EIP1559_GAS_LIMIT: EIP1559_GAS_TARGET * 2. The maximum amount of gas EIP-1559 transactions can use in a given block.

This modification allows to fix part of the following issue (illegal block mined) https://github.com/hyperledger/besu/issues/1223

Update BlockTransactionSelector to use the transactionGasBudgetCalculator in order to fix the second part of the illegal block mined issue (Transaction processing error: transaction gas limit 21000 exceeds available block budget remaining XXX)

We had an issue calculating gasUsed at the AbstractBlockProcessor level. We must have a separate counter for eip1559 and Legacy transactions because they have different pools

Add check to verify that gasPrice is not less than the current BaseFee

Add missing block header validator for Clique network

LGTM


Feature: Granular Update, part 2

Changes:

Adds dependencies to hot registrations and signatures. This allows foreign binding detections and compares them on module reload, prompting a remount if the dependencies change (You can think of this as React's useEffect). This is useful to detect if the component signature is unchanged (meaning no code change) but the dependencies changed. This currently evaluates any identifier expressions and jsx member expressions' object as valid bindings and crawls upwards the scope to detect if it doesn't belong in the root scope.
Partially restructured signature construction, this is to potentially make the output code smaller.
Fixes error for nested/compositional components. The error occurs due to a missing set handler for the Proxy wrapper. It tries to read from the original source however the Proxy writes properties to its new source.
Add @refresh local-skip: Make component opt-out of HMR processing
Add @refresh local-granular: Make component opt-in to granular reloading (this is similar to @refresh granular except that it's component-based).
Add @refresh local-reload: Prompt a full page reload if a component changes (similar to @refresh reload except that it only checks for an specific component change).
Adds snapshot testing
"vite" bundler mode no longer normalizes to "esm" mode due to differing interpretations of import.meta.hot.accept.
Added module.hot.decline compat for Parcel and Nollup
"esm" and "vite" accept handler can now return true for module invalidation. This changes how import.meta.hot.accept code is also generated.

Tested with:

[x] Vite
[x] Parcel 2
[x] Webpack (possibly solved by Parcel test)
[x] Nollup (possibly solved by Parcel test)
[ ] Rollup (through rollup-plugin-hot) (possibly solved by Vite test) Has non-standard ESM HMR
[ ] Snowpack (possibly solved by Vite test)

Todo

Rewrite the README

Question:

At this point, if granular mode does not pose any issues, should this be the default behavior now? Being not the default behavior is still okay.

Some unexpected behavior

When opting-in to @refresh local-skip after module reload, esm invalidates the module while standard does not do anything and would require manual reload. The reason is local-skip does not generate any hot component (this is both true to esm and standard) however standard re-evaluates the same module which is unlike esm HMR whose original module persists.

For those who wants to test:
npm install solid-refresh@npm<EMAIL_ADDRESS>
Webpack, Nollup are the important ones to test with, specially for the side-effect testing and the nested components testing.
I'm pretty curious if we should write something of a per-bundler (webpack, parcel) mode instead of per-hmr (esm, standard) mode just to strictly cover some bundler differences as well as to optimize the code.

Tested with Webpack and Nollup. Snowpack and rollup-plugin-hot should be minor concerns.

That looks good to me. Are we ready?
I think we merge this with granular as opt in test it for a bit in the wild and then move to another minor version where this is the default behavior.

I'm still yet unsure if local-skip has a role. It behaves differently when in granular mode in contrast with default mode.

Do we need the local- at all? I wasn't really looking at this as an options thing initially. Just needed to solve a very specific problem with Document level hydration. I wrote skip initially so that I could manually handle Hot in the file, and then decided to build the reload mechanism after. I guess its nice to have that level of control but I also think its overkill. Like turn it on or turn it off for the file. Having the local switches introduces potentially different behaviors/combinations. If feels like just asking for trouble unless necessary.

I could definitely justify those 3 when it comes to default mode, however, things behave differently when it comes to granular mode. If we decide to make the granular mode the default mode, we could totally remove these local- pragmas

Okay I decided to just remove the local pragmas. Let me test this again.

Added setup guides

I could definitely justify those 3 when it comes to default mode, however, things behave differently when it comes to granular mode. If we decide to make the granular mode the default mode, we could totally remove these local- pragmas

Yeah I think we want to move to granular by default as soon as we feel comfortable. I think we aim for that. Unless you have any concerns?

No concerns anymore, I removed it now since I do think the granular mode will be the default if we proved it effective.


Unknown class _TtC22WWCalendarTimeSelector7WWClock in Interface Builder file.

Application getting crash with this issue and crash occur at line no 770.I tried it using cocoapods and source code.

Hi,
Any solutions for the same ?

No. Instead of using from cocoapods use source code.It will work fine.

Hello,
Please go through the below link you will have the answer of it:
https://github.com/weilsonwonder/WWCalendarTimeSelector/issues/20


Fix/cicd builds

Codecov Report

Merging #48 (59191ec) into master (2ca07e3) will not change coverage.
Report is 1 commits behind head on master.
The diff coverage is n/a.

:exclamation: Current head 59191ec differs from pull request most recent head 7639632. Consider uploading reports for the commit 7639632 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@           Coverage Diff           @@
##           master      #48   +/-   ##
=======================================
  Coverage   72.09%   72.09%
=======================================
  Files          26       26
  Lines         473      473
  Branches       56       56
=======================================
  Hits          341      341
  Misses        123      123
  Partials        9        9

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add build config for logo

This PR addresses the issue https://bugzilla.redhat.com/show_bug.cgi?id=1881970
Now we can add a .env file with the contents
BRAND_TYPE=RedHat

at build time to override the default Konveyor brand setting. This will allow us to display the redhat logo downstream.
Note: As of January 2020, ES2020 supports Promise.allSettled out of the box removing the need for the Q library. This library was causing some dependency clashes with the dotenv webpack plugin, so it is removed as a part of this PR.

Trying to confirm this actually works building an image and deploying, will ack and merge as soon as I can do that


Added more test environments to full and normal tests

No review needed.

There were the following issues with your Pull Request

Commit: 3d88df3a561c1e02404a682ccd072bcd63ad100d
Your commit message body contains a line that is longer than 80 characters

Guidelines are available at https://github.com/zhmcclient/zhmccli/blob/master/CONTRIBUTING.rst

This message was auto-generated by https://gitcop.com

Coverage: 31.475%. Remained the same when pulling 720d26ae19d614aacc468ed0696775752c2dd898 on andy/add-tests into e4134495eb45f82fc099ee58538aa9e1b5d1c43c on master.


Yarn PnP support doesnt work - Jest location cannot be resolved properly

Hi Guys,
Unfortunately, I'm unable to use vscode-jest-runner for debugging purposes. Environment details:
Version: 1.49.3 (system setup)
Commit: 2af051012b66169dde0c4dfae3f5ef48f787ff69
Date: 2020-10-02T17:57:01.595Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19041
vscode-jest-runner version: v0.4.27
When switching on the yarn PnP flag "jestrunner.enableYarnPnpSupport" extensions still tries to resolve jest location under "node_modules".
Rejected candidate: c:*\workspace\node_modules\jest\bin\jest.js
Rejected candidate: c:*\workspace\node_modules\jest\bin\jest.js.js
Rejected candidate: c:*\workspace\node_modules\jest\bin\jest.js.json
Rejected candidate: c:*\workspace\node_modules\jest\bin\jest.js.node
Switching on the flag "jestrunner.detectYarnPnpJestBin" doesn't work as well.
The same paths are used for jest resolution without even considering the .yarn/cache/*.
The only way to make the extension partially working is to override the command by:
"jestrunner.jestCommand": "yarn run jest ${fileBasenameNoExtension} --no-cache --no-watch --runInBand",
but the problem is that it's triggered only for test run but not for debug.
Would be glad for look at it.
Kind Regards
Karol Pawlowski

hey @karol1990 thx for this detailed report.
the feature was implemented by @alexkuc with https://github.com/firsttris/vscode-jest-runner/pull/103
he mentioned that he doesn't know how to invoke yarn with pnp feature enabled on windows.
https://github.com/firsttris/vscode-jest-runner/blob/master/src/jestRunnerConfig.ts#L37
my understanding is if jestrunner.detectYarnPnpJestBin is true it should return yarnPnpJestBinPath() which is 'yarn bin jest'
is this correct for windows?
regards
Tristan

Hey @firsttris, the path that gets generated with flag "jestrunner.detectYarnPnpJestBin" is following:
Rejected candidate: C:***\workspace`yarn bin jest Rejected candidate: C:\***\workspace\yarn bin jest.js Rejected candidate: C:\***\workspace\yarn bin jest.json Rejected candidate: C:\***\workspace\yarn bin jest`.node
what means "yarn bin jest" doesn't get evaluated but gets combined with workspace directory.
Looking at the code I can't locate the place that yarn bin jest would be evaluated.
Worth to mention that 'yarn bin jest' returns the absolute path to jest location in the yarn cache:
C:**\workspace.yarn\cache*jest-npm-26.4.2-65f7183830-e577e48631.zip\node_modules\jest\bin\jest.js
so you won't be able to invoke it from within the command. "Yarn unplug jest" would have to be called first but not sure if this is a good idea.
What about giving users the possibility to override debug command?
regards
Karol

@karol1990 @firsttris
From my recollection of how this feature works.

isYarnPnpSupportEnabled: executes node --require .pnp.js (reference)
detectYarnPnpJestBin: detects path to Jest bin by running yarn bin jest as shell code; as noted in GUI, it is currently supported only on Linux/Unix systems

So if you are on Windows, you would need to manually specify path to binary in one of the VSCode Jest Runner plugin settings.

@karol1990

Looking at the code I can't locate the place that yarn bin jest would be evaluated.

There are actually back ticks to execute the code in shell (source). Normally, the execution should happen in the root of the repository i.e. folder where .pnp.js is located

@karol1990

so you won't be able to invoke it from within the command.

You are not meant to invoke jest.js directly but rather require it via node --require <absolute_path_to_jest_bin>.
While on Linux/Unix systems, it is fairly straight forward to execute a sub-shell command to determine the path dynamically, I am not sure how the workflow works on Windows. I am referring to different flavors of shells and how they are configured. For example, you could invoke node.exe via cmd or via P$ or via miniGW. All of these would have different implications hence my PR included support only for areas I knew better.
Ps. I have used back ticks instead of better format $(…) due to me not being able to avoid the dollar sign being escaped.

Hey @alexkuc,

So if you are on Windows, you would need to manually specify path to binary in one of the VSCode Jest Runner plugin settings.

I've tried this way by overriding jestrunner.jestPath settings. The problem is that you would have to unplug the package what is I don't want to do. Wouldn't be easier to give programmer option to override both run and debug commands in such circumstances ?

@karol1990

The problem is that you would have to unplug the package what is I don't want to do.

I am not sure if I follow but why would you need to unplug the binary? You would manually run yarn bin and specify it as jestrunner.jestPath. If you would navigate to the path given by Yarn 2 Pnp, you would notice that it is pointing to the inside of the .zip file. E.g. .yarn/cache/jest-cli-npm-26.4.2-046301e896-1dc23b584d.zip/node_modules/jest-cli/bin/jest.js, which is why it is necessary to require .pnp.js otherwise Yarn 2 Pnp module would not load properly (vanilla Node does not support loading modules for archives such as zip files).

Wouldn't be easier to give programmer option to override both run and debug commands in such circumstances ?

Technically, that would be an entirely different feature and you would still need the necessary knowledge to load Yarn 2 Pnp. This Yarn 2 Pnp is like a preset of a configuration.

Hey @alexkuc, I'm not sure why I've been failing before to use the relative path of yarn location. It worked well now and will go with jestrunner.jestpath setting. Thanks

@karol1990
I think in some circumstances you need to use absolute path. Glad you got it working!

@alexkuc, unfortunately, an absolute path is not considered as the setting is set in the workspace file and shared with other developers. I see that if the solution was opened via workspace file, even if I change the current directory, debug/run actions bring back the workspace location and set it as current and so it makes the relative path working well.

closing the issue here,
thx for your help @alexkuc


Add isCollapsed boolean or size value to the Imperative API

It would be handy to include either a status boolean or the current size of a panel in the Imperative API to use alongside the methods it provides.
Scenario:
You have a panel you want to toggle open or closed via another button component:
 import {
   ImperativePanelHandle,
   Panel,
   PanelGroup,
   PanelResizeHandle,
 } from "react-resizable-panels";

 const ref = useRef<ImperativePanelHandle>(null);

 const collapsePanel = () => {
   const panel = ref.current;
   if (panel.isCollapased) {
     panel.expand();
   } else {
     panel.collapse();
   }
 };

 <PanelGroup direction="horizontal">
   <Panel collapsible ref={ref}>
     left
   </Panel>
   <PanelResizeHandle />
   <Panel>
     right
   </Panel>
 </PanelGroup>

I see why this could be convenient in some cases, but I'm not sure it's worth adding to the library since it's not new functionality.
import {
  ImperativePanelHandle,
  Panel,
  PanelGroup,
  PanelResizeHandle
} from "react-resizable-panels";

const ref = useRef < ImperativePanelHandle > null;

const [isCollapsed, setIsCollapsed] = useState(false);

const collapsePanel = () => {
  const panel = ref.current;
  if (isCollapased) {
    panel.expand();
  } else {
    panel.collapse();
  }
};

<PanelGroup direction="horizontal">
  <Panel collapsible ref={ref} onCollapse={setIsCollapsed}>
    left
  </Panel>
  <PanelResizeHandle />
  <Panel>right</Panel>
</PanelGroup>;

@bvaughn I was just about to ask the same question.
In the snippet you posted above, you assume that the panel is collapsed to begin with, which is not necessarily true. When the panel is collapsed and the user reloads the page, isCollapsed is out of sync. It would require developers to derive the initial value of isCollapsed from the size state of the panel from local storage (developers should not rely on it as its encoding is internal to this library) or track it independently in local storage (which has great potential for sync errors). Please correct me if I have something wrong.
Btw, I really enjoy yours library, great work 👍🏻

Ah, that's an interesting point. I had assumed onCollapse would be called for the Panel on load if it was initialized to size 0 but that doesn't seem to be the case.
Seems like maybe that's something that we could change.

Ah, that's an interesting point. I had assumed onCollapse would be called for the Panel on load if it was initialized to size 0 but that doesn't seem to be the case.

Even though the imperative API change has landed, I'm going to fix this too, because I think it's unexpected ~> #75

I must admit, I would not have expected onCollapse to be fired on the first mount if the panel was initially collapsed. I think of methods with the prefix on as reacting to a change (usually triggered by a user interaction). But then again, I don't think it will hurt anyone if onCollapse is called initially...

I think it's important to synchronize any external state. How else would you know if the panel group had saved a previously collapsed state?

Totally agree with you, sync errors should be avoided at all cost. It's possible to get the initial state using the ref passed to the panel via ref.current.getCollapsed(), no?
The onCollapse prop (and also ref.current.getCollapsed()) will provide the correct value only after the first render. It the panel contents fetch a lot of data, it would be ideal to delay the fetching until the user expands the panel. Not sure if you consider lazy mounting of panels as something that should be part of this package. I still think a hook called something along usePanelGroup that reads the panel group state directly from local storage (or cookie storage for SSR) and provides the correct state during the initial render might be something to consider in the future 👍🏻

Yes but not reliably bc of the server rendering approach to mount with an initial size of 1 for every panel. You would have to know to ignore the mount effect and read the second render- and I think this is too much an implementation detail to make for a good api.

Good point 👍🏻

The hook suggestion is an interesting one, but I would like to keep the api small if possible (avoid redundant ways of doing something) just to make maintenance more manageable for me.

I have to admit that I'm pretty short on time at the moment. I don't need lazy loading at this moment, but possibly in the future. If my solution can be generalized, I would be happy to contribute back.

I have to admit that I'm pretty short on time at the moment. I don't need lazy loading at this moment, but possibly in the future. If my solution can be generalized, I would be happy to contribute back.

Fair!
I think my suggestion at this point would be to use the onResize callback for this for the foreseeable future :smile:
import { lazy } from "react";
import { Component } from "wherever";

const LazyComponent = lazy(Component);

function App() {
  const [shouldLoad, setShouldLoad] = useState(false);

  const onCollapse = (collapsed: boolean) => {
    setShouldLoad(shouldLoad || !collapsed);
  };

  return (
    <PanelGroup autoSaveId="example" {...otherProps}>
      <Panel collapsible {...panelProps} onCollapse={onCollapse}>
        {shouldLoad && <LazyComponent />}
      </Panel>
      {/* ... */}
    </PanelGroup>
  );
}


✨ feat(*): Complete Rewrite

💛 This pull request is a complete rewrite of the entire site.
Some notable changes:

✍ Fixes spelling mistakes
📂 Better file architecture
➡ Moved inline CSS to assets/css/style.css
📱 More responsiveness
🎨 Fully new styling
🔔 Better CTA buttons
🗑 Removed many Bloat
🌍 Small QoL changes (Eg. _blank targets)

⚠ Changes that will have to be made!

Hosting on another host (Eg. Netlify (Free))*

* Hosting somewhere else will have to be done, as GitHub pages does not like the way the file architecture is. Netlify provides free hosting from a GitHub repo with automatic syncing. (DM me for help with this)
🔀 When merging this PR
Please make sure to Squash & Merge, this will make the commits way cleaner.
(Use the following Squash message)
✨ feat(*): Complete Rewrite (See PR)

Very epic redesign

Thanks for your pull request, but I cannot see why we would need Netlify to host this content, as all content is fully static, and the files are named index.html and placed in subdirectories. The only reason I could see is to have the content in /public and avoid have a LICENSE file hosted, but we could create a simple GitHub Actions workflow to fix that by copying the content in /public to the gh-pages branch.


Austria's app missing

In Austria we also have an app called "stop corona" https://www.roteskreuz.at/site/meet-the-stopp-corona-app/
Never tried it myself yet. But wanted to let you know. You'll find the links to the download in the link above.

Thanks Jurgen!
I just ran the analysis for Austria, you can find the results here.


Stacktrace instead of error message when MacOS::Xcode.version is null

Please follow the general troubleshooting steps first:

[x] Ran brew update and retried your prior step?
[x] Ran brew doctor, fixed as many issues as possible and retried your prior step?

Bug reports:
After upgrading to OS X 10.11, a few actions trigger a stacktrace, which suggests that MacOS::Xcode.version is null. brew doctor suggests that developer tools weren't installed; arguably, it'd still a better user experience if MacOS::Xcode.version (or a variant for this scenarios) displayed a suitable error message.
However, this is an unsupported configuration (it's about quality of error messages) so I'd this issue is low-priority.
Error: undefined method `<' for nil:NilClass
Please report this bug:
    https://git.io/brew-troubleshooting
/usr/local/Library/Homebrew/formula_support.rb:21:in `valid?'
/usr/local/Library/Homebrew/formula.rb:851:in `keg_only?'
/usr/local/Library/Homebrew/diagnostic.rb:837:in `block in check_for_linked_keg_only_brews'
/usr/local/Library/Homebrew/diagnostic.rb:836:in `select'
/usr/local/Library/Homebrew/diagnostic.rb:836:in `check_for_linked_keg_only_brews'
/usr/local/Library/Homebrew/cmd/doctor.rb:42:in `block in doctor'
/usr/local/Library/Homebrew/cmd/doctor.rb:35:in `each'
/usr/local/Library/Homebrew/cmd/doctor.rb:35:in `doctor'
/usr/local/Library/brew.rb:87:in `<main>'

After upgrading to OS X 10.11, a few actions trigger a stacktrace

Can you elaborate on this a bit, in terms of which commands cause the issue?

I got it both from brew upgrade --cleanup, after it completed darcs and at gd, and from brew doctor.
But the stack traces are slightly different for the two commands, I'm sorry; below there are more accurate ones (the one given was from brew doctor). Line numbers should be from commit d363ae53c08abd7e658a0124e7d3bb79d38a1f08.
Some formulas did upgrade successfully. It turns out that one needs to invoke f.keg_only_reason.valid? on a formula f that is marked as keg-only for reason :provided_until_xcode43 or :provided_until_xcode5.
The upgrade command checks recursive dependencies of the formula to upgrade, to ensure they're either keg-only or linked. So for me this only happened when upgrading gd—that can trigger the above bug on any of autoconf, automake, libtool because they're all :provided_until_xcode43.
$ brew upgrade --cleanup
==> Upgrading 13 outdated packages, with result:
cabal-install <IP_ADDRESS>_1, curl 7.49.1, darcs 2.12.0, gd 2.2.1_1, ghc 8.0.1, graphicsmagick 1.3.24, haskell-stack 1.1.2_3, imagemagick 6.9.4-7, homebrew/dupes/make 4.2, node 6.2.1, poppler 0.44.0, tmux 2.2, vim 7.4.1864_1
[... successful upgrades...]
==> Upgrading darcs
==> Downloading https://homebrew.bintray.com/bottles/darcs-2.12.0.el_capitan.bottle.1.tar.gz
######################################################################## 100.0%
==> Pouring darcs-2.12.0.el_capitan.bottle.1.tar.gz
🍺  /usr/local/Cellar/darcs/2.12.0: 7 files, 46.2M
Removing: /usr/local/Cellar/darcs/2.10.3... (7 files, 30.4M)
Error: undefined method `<' for nil:NilClass
Please report this bug:
    https://git.io/brew-troubleshooting
/usr/local/Library/Homebrew/formula_support.rb:21:in `valid?'
/usr/local/Library/Homebrew/formula.rb:851:in `keg_only?'
/usr/local/Library/Homebrew/formula_installer.rb:148:in `block in check_install_sanity'
/usr/local/Library/Homebrew/formula_installer.rb:147:in `select'
/usr/local/Library/Homebrew/formula_installer.rb:147:in `check_install_sanity'
/usr/local/Library/Homebrew/formula_installer.rb:124:in `prelude'
/usr/local/Library/Homebrew/cmd/upgrade.rb:78:in `upgrade_formula'
/usr/local/Library/Homebrew/cmd/upgrade.rb:56:in `block in upgrade'
/usr/local/Library/Homebrew/cmd/upgrade.rb:55:in `each'
/usr/local/Library/Homebrew/cmd/upgrade.rb:55:in `upgrade'
/usr/local/Library/brew.rb:87:in `<main>'

[...]
Warning: No developer tools installed.
Install the Command Line Tools:
  xcode-select --install
[...]
Warning: Your Xcode is configured with an invalid path.
You should change it to the correct path:
  sudo xcode-select -switch /Developer
Error: undefined method `<' for nil:NilClass
Please report this bug:
    https://git.io/brew-troubleshooting
/usr/local/Library/Homebrew/formula_support.rb:21:in `valid?'
/usr/local/Library/Homebrew/formula.rb:851:in `keg_only?'
/usr/local/Library/Homebrew/diagnostic.rb:837:in `block in check_for_linked_keg_only_brews'
/usr/local/Library/Homebrew/diagnostic.rb:836:in `select'
/usr/local/Library/Homebrew/diagnostic.rb:836:in `check_for_linked_keg_only_brews'
/usr/local/Library/Homebrew/cmd/doctor.rb:42:in `block in doctor'
/usr/local/Library/Homebrew/cmd/doctor.rb:35:in `each'
/usr/local/Library/Homebrew/cmd/doctor.rb:35:in `doctor'
/usr/local/Library/brew.rb:87:in `<main>'

$ brew irb
> 'gd'.f.recursive_dependencies.map(&:to_formula).select do |f| f.keg_only_reason != nil end.map do |f| [f.name, f.keg_only_reason] end
=> [["autoconf", #<KegOnlyReason:0x007fb2093b3bd0 @reason=:provided_until_xcode43, @explanation="">], ["automake", #<KegOnlyReason:0x007fb2093bb0d8 @reason=:provided_until_xcode43, @explanation="">], ["libtool", #<KegOnlyReason:0x007fb2093c8fa8 @reason=:provided_until_xcode43, @explanation="">], ["gettext", #<KegOnlyReason:0x007fb20889de30 @reason=:shadowed_by_osx, @explanation="OS X provides the BSD gettext library and some software gets confused if both are in the library path.">], ["libpng", #<KegOnlyReason:0x007fb2093b9878 @reason=:provided_pre_mountain_lion, @explanation="">], ["freetype", #<KegOnlyReason:0x007fb2093d03c0 @reason=:provided_pre_mountain_lion, @explanation="">], ["fontconfig", #<KegOnlyReason:0x007fb208837888 @reason=:provided_pre_mountain_lion, @explanation="">]]

BTW, since I was looking at this code — I noticed it seems to run afoul of the "deprecation" in https://github.com/Homebrew/brew/blob/master/Library/Homebrew/os/mac/xcode.rb#L103-L107.
class KegOnlyReason
  # ...
  def valid?
    case @reason
    # ...
    when :provided_until_xcode43
      MacOS::Xcode.version < "4.3"
    when :provided_until_xcode5
      MacOS::Xcode.version < "5.0"

@Blaisorblade Thanks for the report and for the detailed and spot-on analysis! Fixed this in 25baaa61acc8743e69032233823a5ac33858d49e, so it should no longer fail for you after a brew update.

@UniqMartin You're on a roll of fixing things before I swing back online this week, thank you for picking this up ❤.

Thanks, that's better! But in case others have opinions, I have a nitpick on the fix here... But this nitpick only applies to old configurations, so before you look at it I wonder: do you actually support OS X before Mavericks? You have code but no testbot for it and I couldn't find info in docs.
I ask because I do see a bug, but I'd rather delete the offending feature than spend your time explaining it.
https://github.com/Homebrew/brew/commit/25baaa61acc8743e69032233823a5ac33858d49e#commitcomment-17745007

do you actually support OS X before Mavericks?

We haven't barred people from running Homebrew on 10.8 or lower but we no longer officially support doing so and people encountering issues are expected to help fix them, essentially. brew issues a warning on <10.8 and below.
I don't think any maintainer is running less than 10.9 & as you've noted we've only the CI capacity to continuously test/support 3 OS X releases at a time, so our capacity for testing & fixing things for older OS X releases is fairly slim. CI is sadly very maintenance heavy even supporting "only" the three most recent releases.

Additionally, it doesn't make much sense to fully support older OS X releases as they have been abandoned by Apple, too. (But we don't try to actively rip out code so that Homebrew only runs with the OS X releases we and Apple officially support either.)

ask because I do see a bug, but I'd rather delete the offending feature than spend your time explaining it EDIT have you spend time reading the issue.
https://github.com/Homebrew/brew/commit/25baaa61acc8743e69032233823a5ac33858d49e#commitcomment-17745007

Thanks for taking the time to look into this more thoroughly! I think the remaining inaccuracy is negligible, as it really only affects legacy systems that don't have Xcode 4.3.x-4.6.x installed, but have the matching Command Line Tools on their systems. Furthermore, it only affects users that have the cvs formula installed and the only undesirable (?) effect would be that now our cvs is no longer keg-only and thus would take precedence over the one provided by the Command Line Tools. I think this is a sufficiently small attack surface that we should only act on this if prompted by a bug report where this actually creates an issue. Solving the original issue you reported here has a much greater impact and certainly for the good (since we no longer abort with a stack trace).


[Feature][state] seatunnel 如何实现自定义状态

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
seatunnel 如何实现自定义状态
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

hi，@Xuzhengz   In what context does he need to apply it

hi，@Xuzhengz In what context does he need to apply it

譬如用作周期性sql增量查询的依据。
参考logstash：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html#_predefined_parameters
seatunnel能实现同样的功能？


example showing serialization stack overflow during upgrade

Demonstrate failure to upgrade due to candid serialization failure on deeply nested data structure (stack overflow).

@rossberg @ulan  another nail in the coffin for candid stabilization

He he. But isn't this a problem for our Candid implementation in general? Shouldn't it be impossible to send such a list to another canister?

He he. But isn't this a problem for our Candid implementation in general? Shouldn't it be impossible to send such a list to another canister?

Yes, it is, but given the 3MB message limit, it might be hard to exercise it. I'm not sure if it affects the Rust implementation but we should check. @chenyan-dfinity did you try this with Rust?

With deeply nested single field records (which don't cost extra bytes in the data array) it should be easy to get very deeply nested data structures in 2M, at least quadratic in input size, so maybe a billion deep.

Solved by enhanced orthogonal persistence


Remove issues staleness

Close only stale PRs.

Thanks!
No complaints, let's keep some issues open!


Prevent "index too long" error

This PR fixes the error from issue #5294.

@rickmacgillis, As you've undoubtedly discovered at this point, your prefix is the cause of the error you're getting.  Obviously this problem is not unique to you, but I do have a couple concerns with your solution.  I agree that hard-coding a name for that index is likely the correct solution, but we also have to weigh that against the complaints we'll get from users about how it's not using their configured prefix.
Perhaps there's a way to use the configured prefix and a simplified index name to keep it under the 64 character limit.  Obviously, a 63 character prefix would still break, but at least that would be consistent across the entire laravel app, not just this one migration.
@emptynick / @MrCrayon, any thoughts?

I think that would be the right solution:
https://github.com/the-control-group/voyager/issues/3751#issuecomment-555580542
Setting the unique-option per column is the same that was intended by bulk-setting this and it doesn't have a problem with the character limit.


Error when using http/https scheme with UriSource

Consider the plan below, which sources data from a single URL.
Upon execution, Myria reports java.io.IOException: No FileSystem for scheme: http (full exception below).  I'm virtually positive that I have successfully loaded data using an http scheme (the only other possibility is that I was using a custom DataSource implementation).  It's also possible that I had frameworks that expose a HttpFileSystem co-installed at the time (e.g., Hadoop's HttpFS).
Is this a regression bug, a configuration issue, or does the UriSource really not currently support these schemes?  It's also possible that I've gone insane, because I was sure that this used to work.
(Originally observed by @ryanmaas)
{
   "fragments":[
      {
         "workers":[
            1
         ],
         "operators":[
            {
               "source":{
                  "dataType":"URI",
                  "uri":"http://s3-us-west-2.amazonaws.com/myria-sdss/oceanography/smallsample_ocean_seq.csv"
               },
               "opId":0,
               "opType":"FileScan",
               "schema":{
                  "columnNames":[
                     "col",
                     "col2",
                     "col3",
                     "col4",
                     "col5"
                  ],
                  "columnTypes":[
                     "LONG_TYPE",
                     "DOUBLE_TYPE",
                     "DOUBLE_TYPE",
                     "DOUBLE_TYPE",
                     "DOUBLE_TYPE"
                  ]
               }
            },
            {
               "argOverwriteTable":true,
               "opId":1,
               "opType":"DbInsert",
               "relationKey":{
                  "userName":"public",
                  "relationName":"testMyriaUpload",
                  "programName":"adhoc"
               },
               "argChild":0
            }
         ]
      }
   ],
   "logicalRa":"Parallel Import [(1, 'http://s3-us-west-2.amazonaws.com/myria-sdss/oceanography/smallsample_ocean_seq.csv')]",
   "rawQuery":"Parallel Import [(1, 'http://s3-us-west-2.amazonaws.com/myria-sdss/oceanography/smallsample_ocean_seq.csv')]"
}

Full exception:
edu.washington.escience.myria.DbException: Query #66690.0 failed: java.io.IOException: No FileSystem for scheme: http\n\tat edu.washington.escience.myria.parallel.MasterSubQuery$WorkerExecutionInfo$2.operationComplete(MasterSubQuery.java:105)
	at edu.washington.escience.myria.parallel.LocalSubQueryFutureListener.operationComplete(LocalSubQueryFutureListener.java:45)
	at edu.washington.escience.myria.util.concurrent.OperationFutureBase.notifyListener(OperationFutureBase.java:583)
	at edu.washington.escience.myria.util.concurrent.OperationFutureBase.notifyListeners(OperationFutureBase.java:542)
	at edu.washington.escience.myria.util.concurrent.OperationFutureBase.wakeupWaitersAndNotifyListeners(OperationFutureBase.java:151)
	at edu.washington.escience.myria.util.concurrent.OperationFutureBase.setFailure0(OperationFutureBase.java:506)
	at edu.washington.escience.myria.parallel.LocalSubQueryFuture.setFailure(LocalSubQueryFuture.java:69)
	at edu.washington.escience.myria.parallel.MasterSubQuery.workerFail(MasterSubQuery.java:320)
	at edu.washington.escience.myria.parallel.QueryManager.workerFailed(QueryManager.java:308)
	at edu.washington.escience.myria.parallel.Server$MessageProcessor.run(Server.java:182)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at edu.washington.escience.myria.util.concurrent.RenamingThreadFactory$1.run(RenamingThreadFactory.java:33)
	Suppressed: edu.washington.escience.myria.DbException: Worker #1 failed: java.io.IOException: No FileSystem for scheme: http
		at edu.washington.escience.myria.operator.FileScan.init(FileScan.java:249)
		at edu.washington.escience.myria.operator.Operator.open(Operator.java:402)
		at edu.washington.escience.myria.operator.Operator.open(Operator.java:392)
		at edu.washington.escience.myria.parallel.LocalFragment.initActually(LocalFragment.java:707)
		at edu.washington.escience.myria.parallel.LocalFragment.access$700(LocalFragment.java:44)
		at edu.washington.escience.myria.parallel.LocalFragment$2.call(LocalFragment.java:225)
		at edu.washington.escience.myria.parallel.LocalFragment$2.call(LocalFragment.java:218)
		at edu.washington.escience.myria.util.concurrent.ExecutableExecutionFuture.call(ExecutableExecutionFuture.java:193)
		... 4 more
	Caused by: edu.washington.escience.myria.DbException: java.io.IOException: No FileSystem for scheme: http
		... 12 more
	Caused by: java.io.IOException: No FileSystem for scheme: http
		at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:1443)
		at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:67)
		at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:1464)
		at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:263)
		at edu.washington.escience.myria.io.UriSource.getInputStream(UriSource.java:56)
		at edu.washington.escience.myria.operator.FileScan.init(FileScan.java:241)
		... 11 more

Good timing -- I just sent a mail to the Myria list that has the below content.
I suspect somewhere along the line the hadoop jar loading got broken. Andrew definitely tested s3, http, and file links when he wrote this code. (Although we clearly need unit tests of them!)
Relevant stack overflow issue:
http://stackoverflow.com/questions/17265002/hadoop-no-filesystem-for-scheme-file

All of the SO links that appeared relevant deal with the file scheme, which does works (as does hdfs).  So this isn't confusion between the FileSystem and DistributedFileSystem locations.  What boggles me is that it doesn't appear that hadoop-core-1.2.1.jar ever supported http (though I haven't looked very deeply here).
I did clone a commit from approximately August of 2014 and verified that the problem exists as far back as then.

@BrandonHaynes I think we're both crazy, is the answer.

How would you feel about explicitly checking for http/https schemes and just getting a stream via URL.openConnection().getInputStream()?  I suspect that, overall, this might be cleaner than registering a HTTP-oriented FileSystem implementation.

Seems reasonable to me.

@BrandonHaynes FYI, I think if you had used "Fix #721" instead of "Corrects #721" in the PR description for #727 then GitHub would have auto-closed this upon merging :)


Type annotations can skip values

Currently the grammar only supports type annotations in the form,
string (foo = "bar", baz = "qux")

The Thrift grammar allows for skipping the '= value' component of the annotation.
string (foo, bar = "qux")

Thrift defaults the value to the string "1" when the value is skipped.
We should probably support this too. Especially for the case where the only valid value for an annotation is "true".

Oh this is a dupe of #84.


DOC Fixes link to init methods in extension types user guide

This PR fixes the link to init methods in extension types user guide

Thanks


Improve Left/Right/Inner Join

Fix #190
For left (right) join, set pd.NA to observations not matched by equality or inequality condition from the right (left) table.
Add new data sets and tests for complex join.

Thanks @flcong - looks like a lot of work! I might need some time checking the content. Make sure to ping me if I take too long... In the meantime, maybe @rajagurunath can have a first look (although this is also new code for you, sorry!)

Codecov Report

Merging #223 (29a201d) into main (4dab949) will decrease coverage by 0.03%.
The diff coverage is 96.96%.

@@             Coverage Diff             @@
##              main     #223      +/-   ##
===========================================
- Coverage   100.00%   99.96%   -0.04%
===========================================
  Files           64       64
  Lines         2589     2609      +20
  Branches       362      366       +4
===========================================
+ Hits          2589     2608      +19
- Partials         0        1       +1

Impacted Files
Coverage Δ

dask_sql/physical/rel/logical/join.py
99.31% <96.96%> (-0.69%)
:arrow_down:

dask_sql/utils.py
100.00% <0.00%> (ø)

dask_sql/context.py
100.00% <0.00%> (ø)

dask_sql/server/responses.py
100.00% <0.00%> (ø)

dask_sql/physical/rex/core/call.py
100.00% <0.00%> (ø)

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 4dab949...29a201d. Read the comment docs.

Thanks @flcong - looks like a lot of work! I might need some time checking the content. Make sure to ping me if I take too long... In the meantime, maybe @rajagurunath can have a first look (although this is also new code for you, sorry!)

No problem! First time contributing to a python package.

Hi @flcong,
Thanks for fixing this issue and welcome to dask-sql and open source :)

Am I too simple?
Just to make my point clear: if you replace your changes in join.py inside the filter_condition check just with

logger.debug(f"Additionally applying filter {filter_condition}")
df = filter_or_scalar(df, filter_condition)

# make sure we recover any lost rows in case of left, right or outer joins
if join_type in ["left", "outer"]:
    df = df.merge(df_lhs_renamed, on=list(df_lhs_renamed.columns), how="right")
elif join_type in ["right", "outer"]:
    df = df.merge(df_rhs_renamed, on=list(df_rhs_renamed.columns), how="right")

df = df.drop(columns=["left_idx", "right_idx"])

your tests still succeed

That's brilliant! I didn't think of that. I rolled back join.py to the previous version and added the lines you mentioned.
One caveat is that in this case, if any input column has type int and there are unmatched rows, np.nan will be added and the column type will be cast to float, instead of nullable int. Since we don't know whether or not there are unmatched rows without triggering compute() (I guess), we have to either leave it as is (users may want to type-cast float into nullable int later) or we cast all int columns to nullable int (which may not be good either). What do you think?
By the way, I also find a bug in the merge_single_partitions function in join.py. (I don't know how you quote code in the conversation XD.) In the returned dataframe, there is an extra column "common" which causes a metadata mismatch for left join when there are only inequality conditions (e.g. my time-series table tests), so I dropped the column.


PSWriteWord generates empty word file

I'm using the latest released version of PSWriteWord (https://github.com/EvotecIT/PSWriteWord/tree/v1.1.8), and an example snippet but I only get an empty file:
Import-Module $PSScriptRoot\PSWriteWord.psd1 -Force

$T1 = [PSCustomObject] @{
  Test   = 1
  Test2  = 7
  Ole    = 'bole'
  Trolle = 'A'
  Alle   = 'sd'
}

$T2 = [ordered] @{
  Test   = 1
  Test2  = 7
  Ole    = 'bole'
  Trolle = 'A'
  Alle   = 'sd'
}

$FilePath = "$Env:USERPROFILE\Desktop\PSWriteWord-Example-Tables9.docx"

$WordDocument = New-WordDocument $FilePath

Add-WordText -WordDocument $WordDocument -Text "Before" -Supress $true
Add-WordTable -WordDocument $WordDocument -DataTable $T1 -Design ColorfulGrid -Supress $true
Add-WordText -WordDocument $WordDocument -Text "After" -Supress $true
Add-WordTable -WordDocument $WordDocument -DataTable $T1 -Transpose -Design ColorfulGrid -Supress $true

Add-WordText -WordDocument $WordDocument -Text "Before T2" -Supress $true
Add-WordTable -WordDocument $WordDocument -DataTable $T2 -Design ColorfulGrid -Supress $true
Add-WordText -WordDocument $WordDocument -Text "After T2" -Supress $true
Add-WordTable -WordDocument $WordDocument -DataTable $T2 -Transpose -Design ColorfulGrid -Supress $true

Save-WordDocument $WordDocument -Language 'en-US' -Supress $True -OpenDocument

I think this problem is due to using PowerShell 6.2 instead of 5.*

Yes. It's not supported on 6 or 7. This is due to Xceed Library not supporting this in free version. THey only support Net Standard in pay version. I've been asking them to add support for Core to community edition, but failed.

Ah Ok. That's too bad. It's also a really hard error to track down. Maybe adding a Warning or Exception to PSWriteWord could help to avoid this in the future. Feel free to close this issue then.

I'll add compatible editions in next release (PSD1):
    CompatiblePSEditions       = @('Desktop')

Which should prevent installing/importing from the gallery I hope.

The thing is, I actually had tested it with the trial version and it was working. So it's in theory possible to get pay version running with PSWriteWord.

Btw.
Works only on Windows (as NET CORE is not supported by DLL) - until Xceed ads that to their version. Which will take a while for the free version to have (if ever).
Works only on PowerShell 5.1 (not tested on PowerShell 6.0 with Windows compatibility pack)

It's in the requirements in README :-) And I just confirmed it doesn't work with windows compatibility in PS 7. Sorry.


Preprocessing Problem about N4BiasFieldCorrection module

Hello,
When I run the preprocessing code,  while getting an IOError: No command "N4BiasFieldCorrection" found. Is there any configuration problem or something wrong with my code?

First installed antsbin in your home directory....then cd brats18...then write  export PATH=${PATH}:$Home/antsbin/bin in terminal in case of Ubuntu....after that python pre_processing.py /path to your dataset...it will take more than 5 hours......

Thanks !

First installed antsbin in your home directory....then cd brats18...then write export PATH=${PATH}:$Home/antsbin/bin in terminal in case of Ubuntu....after that python pre_processing.py /path to your dataset...it will take more than 5 hours......

Hi, can you tell me how to begin to traing after preprocessed data? I hava switched python2.7,but it doesn't work.


fix regression in detecting active instances

Fixes a regression introduced with commit https://github.com/googlei18n/glyphsLib/blob/d9d1da4e/Lib/glyphsLib/interpolation.py#L146
The 'exports' parameter was being interpreted as a string instead of as a boolean, hence the following test if '0': ... would always return True.
Notice how in line 146, the cast to int() was not used for the 'exports' parameter, but only for the 'active' one.
Because of this, all the instances were always generated no matter what their 'exports' value...
The tests in interpolation_test.py did not catch this bug, because in there we were passing an integer instead of a string as the 'exports' parameter value.
The 'exports' parameter is now explicitly being cast to boolean (db826fe).

LGTM

LGTM


Lab Suggestions

Great lab.  I just ran through it.  Some suggestions for the lab are below:

In the prerequisites, add a version number for Terraform.  e.g. 1.7
In Part 1, step 2, add cd avm-lab
In Part 1, step 12, let the users know what success looks like.  eg:

Also point them to the Outputs for the resource group name:

In Part 2, step 5, suggest pointing users to the VNet AVM Terraform registry and VNet AVM opensource for the module for review.
Note that the copy commands are all for Linux (e.g. forward slash "/").  Some users may be using Windows.
In Part 5, there is no mention of calling Terraform apply

I've added these updates, thanks.


FanIn TLS Benchmark

Overall, I don't think we need a TLS/fanin benchmark.
The other TLS was using fanout as a way to exercise encryption.
What I think is more interesting is 2 new benchmark: fan-in and fan-out without TLS.


Class with property interface of List

If you have class:
class ClassWithPropertyInterfaceOfList
        {
            public IList<string> List { get; set; }
            public IDictionary<string, string> Dictionary { get; set; }

            public ISet<string> Set { get; set; }
        }

and create object:
            var expected = new ClassWithPropertyInterfaceOfList
            {
                List = new List<string> { "Item1" },
                Set = new HashSet<string> { "Item1" },
                Dictionary = new Dictionary<string, string> { { "Key", "Value" } }
            };

I've got exception:
ExtendedXmlSerializer.ExtensionModel.References.CircularReferencesDetectedException was unhandled by user code
HResult=-2146233088
Message=The provided instance of type 'ExtendedXmlSerializer.Tests.ExtensionModel.Xml.ExtendedXmlSerializerTests+ClassWithPropertyInterfaceOfList' contains circular references within its graph. Serializing this instance would result in a recursive, endless loop. To properly serialize this instance, please create a serializer that has referential support enabled by extending it with the ReferencesExtension.
Source=ExtendedXmlSerializer
StackTrace:
at ExtendedXmlSerializer.ExtensionModel.References.ReferenceAwareSerializers.Serializer.Write(IFormatWriter writer, Object instance) in C:\Work\ExtendedXmlSerializer\src\ExtendedXmlSerializer\ExtensionModel\References\ReferenceAwareSerializers.cs:line 77
at ExtendedXmlSerializer.ExtensionModel.Xml.ExtendedXmlSerializer.Serialize(XmlWriter writer, Object instance) in C:\Work\ExtendedXmlSerializer\src\ExtendedXmlSerializer\ExtensionModel\Xml\ExtendedXmlSerializer.cs:line 55
at ExtendedXmlSerializer.ExtensionModel.Xml.InstanceFormatter.Get(Object parameter) in C:\Work\ExtendedXmlSerializer\src\ExtendedXmlSerializer\ExtensionModel\Xml\InstanceFormatter.cs:line 50
at ExtendedXmlSerializer.ExtensionModel.Xml.Extensions.Serialize(IExtendedXmlSerializer this, IXmlWriterFactory factory, Func`1 stream, Object instance) in C:\Work\ExtendedXmlSerializer\src\ExtendedXmlSerializer\ExtensionModel\Xml\Extensions.cs:line 132
at ExtendedXmlSerializer.ExtensionModel.Xml.Extensions.Serialize(IExtendedXmlSerializer this, Object instance) in C:\Work\ExtendedXmlSerializer\src\ExtendedXmlSerializer\ExtensionModel\Xml\Extensions.cs:line 118
at ExtendedXmlSerializer.Tests.Support.SerializationSupport.Assert[T](T instance, String expected) in C:\Work\ExtendedXmlSerializer\test\ExtendedXmlSerializer.Tests\Support\SerializationSupport.cs:line 46
at ExtendedXmlSerializer.Tests.ExtensionModel.Xml.ExtendedXmlSerializerTests.PropertyInterfaceOfList() in C:\Work\ExtendedXmlSerializer\test\ExtendedXmlSerializer.Tests\ExtensionModel\Xml\ExtendedXmlSerializerTests.cs:line 205
InnerException:
I'll add test to repo.

It was working in v1.5.

Maybe we should work on the exception message (it's a little old)?

Serializing this instance would result in a recursive, endless loop. To properly serialize this instance, please create a serializer that has referential support enabled by extending it with the ReferencesExtension.

Should be:

Serializing this instance would result in a recursive, endless loop. To properly serialize this instance, please create a serializer that has references enabled by calling the EnableReferences extension method.

Try that out and let me know how it goes.  It should work. 👼

I don't understand. What should I do?
I don't see any reference in this example.

For me it should work without configuration.

Doh!  You are correct.  I thought this was a reference class by the title.  That's what I get for reading this while working out. :)  I will look into this.  (I'll also fix that message, too).

Ok thanks!
I've already added a failed test.

There is test in Legacy code: ExtendedXmlSerializer.Tests.Legacy.TestObject.TestClassPropertyInterfaceOfList

There is legacy test: https://github.com/wojtpl2/ExtendedXmlSerializer/blob/v2.0.0/test/ExtendedXmlSerializer.Tests.Legacy/SerializationPropertyInterfaceOfListTest.cs#L30-L45

Ahhh... guess what?  This is working exactly as designed.  It's a little tricky, but that "Item1" is a reference in the object graph.  If you change the 2nd one to "Item2" it will serialize as expected without an error.  Here is what it looks like when you enable references:
<?xml version="1.0" encoding="utf-8"?>
<ExtendedXmlSerializerTests-ClassWithPropertyInterfaceOfList xmlns="clr-namespace:ExtendedXmlSerializer.Tests.ExtensionModel.Xml;assembly=ExtendedXmlSerializer.Tests">
	<List xmlns:sys="https://extendedxmlserializer.github.io/system" xmlns:exs="https://extendedxmlserializer.github.io/v2" exs:type="sys:List[sys:string]">
		<Capacity>4</Capacity>
		<sys:string exs:identity="1">Item1</sys:string>
	</List>
	<Dictionary xmlns:sys="https://extendedxmlserializer.github.io/system" xmlns:exs="https://extendedxmlserializer.github.io/v2" exs:type="sys:Dictionary[sys:string,sys:string]">
		<sys:Item>
			<Key>Key</Key>
			<Value>Value</Value>
		</sys:Item>
	</Dictionary>
	<Set xmlns:ns1="clr-namespace:System.Collections.Generic;assembly=System.Core" xmlns:sys="https://extendedxmlserializer.github.io/system" xmlns:exs="https://extendedxmlserializer.github.io/v2" exs:type="ns1:HashSet[sys:string]">
		<sys:string exs:reference="1" />
	</Set>
</ExtendedXmlSerializerTests-ClassWithPropertyInterfaceOfList>

You can see it is using exs:reference to point to the previous string (a reference).  This seems a little overkill with a simple string, but imagine if there is a long string/message/text.  If it occurs one than once in the object graph, they will all point to the same one automatically (with references enabled, of course).
It's a little different from v1, but more powerful.  However, I am open to suggestions on any better way to handle this for the user.  We could probably print out the references. In the case of strings, this will print out the strings themselves, leading to less confusion.

For me it is wrong designed. Valuable types (and string too) shouldn't be used as referenced object.
Eg, If you have list of Person:
public class Person{
   public string Name { get; set; }
   public int salary { get; set; }
}

List<Person> list = new List<Person>()

And you have on the list many items ( >= 1000) and many the same names (eg. Mike). With this design won't be able to read xml because in many places you will have references to other items.
And if I had:
            var expected = new ClassWithPropertyInterfaceOfList
            {
                List = new List<string> { "Item1" },
                Set = new HashSet<string> { "Item1" },
                Dictionary = new Dictionary<string, string> { { "Key", "Value" } }
            };

The first Item1 is another object from the second Item1. If you deserialize your xml you will have one string. If you change first Item1 you change second object too, don't you?

OK good points.  Maybe we can have a type collection property on ReferencesExtension for IgnoredTypes, and by default string is in there?

It is good solution for now.
Do you know what will happen with class Point. It be working if I would have many the same Points?

Point is a value type so it would not be considered for references.  String is really the only fuzzy/questionable type because it does seem like a primitive type (and is actually a "primitive" type, heh), but it is a reference/class type.  Confusing I know. :)

Alright, this is now done.  Please see PropertyInterfaceOfList, PropertyInterfaceOfListEnabledReferences, and PropertyInterfaceOfListReferencesCleared in ReferencesExtensionTests for examples.

Great! Thanks!
I will check it tomorrow.

I cun't run this tests. I have trouble because I have VS 2017 update 3 preview 6 and .net core 2.0. In this version I can't run unit tests. I got some error message. It is issue in VS.
I need to have this version VS for another project.

Ahhh no worries.  I was using R# EAP and it wasn't able to debug tests until EAP9.  Funny how it is 3 months after launch and nothing really works still haha.  Let me know when you are able to test and check it out. 👍

I believe this is working as expected now.  Please feel free to comment/re-open this issue if not. :)

I also get this ExtendedXmlSerializer.ExtensionModel.References.CircularReferencesDetectedException even when I create it this way: var serializer = new ConfigurationContainer().EnableReferences().Create();
This is happens with EF6 data model where class foo has public virtual bar Bar { get; set; } and class bar has public virtual ICollection<foo> Foo { get; set; }.
With Json needed to ignore the entries, this is why I play with ExtendedXmlSerializer, but it also fails.

Can you provide a reproducible test, @MagicAndre1981?  I tried using your schema above and it seems to pass:
https://github.com/wojtpl2/ExtendedXmlSerializer/blob/363b584f1a4a62ef764bf70a782bab95ab23fe51/test/ExtendedXmlSerializer.Tests/ReportedIssues/Issue98Tests.cs#L11-L40

not really. I'm already playing with a console demo, but here it works with the Employee database of Firebird. btw EF6 uses new HashSet<Foo>(), so I have no idea if this makes a difference.

Ah OK.  Sounds like the failure is occurring on EF6's end, if I understand correctly. A quick test of Hashset on our end seems to work as expected.  If you do find a reproducible failure, please let us know and we'll take a look at it. 👍

I still don't understand this message. From Callstack I can see that I the CircularReferenceEnabledSerialization is used.
I want to serialize a list<foo> to save it with Application.Current.Properties  which has several of those virtual entries which are used by EF for Foreign Key access to linked table. And this linked table has reference back with a virtual ICollection property.

Looks to be working here:
https://github.com/wojtpl2/ExtendedXmlSerializer/blob/34ca6295e3a182670e9269ae002bdf8cf30c0efb/test/ExtendedXmlSerializer.Tests/ReportedIssues/Issue98Tests.cs#L32-L51
Sorry @MagicAndre1981, English just gets in the way. 😂  You are going to need to create a simple hello world example (Console application) and post it in your GitHub somewhere.
I can then take a look at it to see if I can assist further. 👍

ok, the code stops because I configured VS to stop at this exception. I see the code works and generates XML and deserialized objects include the references again.
I see you catch the exception and ignore it by still writing the content in ReferenceAwareSerializers.cs
catch (CircularReferencesDetectedException e)
{
     e.Writer.Write(writer, instance);
}

I configured VS to stop because I saw this CircularReferencesDetectedException before app closes and debugging stops 🤔 🤷♂

Ah!  So it seems like a development environment-specific issue then, @MagicAndre1981?  And one that occurs on exit?
FWIW, indeed we check for that exception on a container configured with EnableReferences and continue writing instead.  That is, we handle the exception in this case whereas the default behavior is to throw.

FWIW, indeed we check for that exception on a container configured with EnableReferences and continue writing instead. That is, we handle the exception in this case whereas the default behavior is to throw.

this confused me. So the app was not crashing because of this, but something else, but last exception was the CircularReferencesDetectedException and I configured VS to stop at CircularReferencesDetectedException and wondered why it gets thrown when I already called EnableReferences()

and wondered why it gets thrown when I already called EnableReferences()

That's a good point, @MagicAndre1981.  Try/Catch incurs a performance hit as well, so it might be better to maybe put that in a handler of some sort and use that instead.  The default handler throws the exception and a container configured with EnableReferences will handle it instead.
Something to carry forward with v3. :)

Something to carry forward with v3. :)

should I open a new issue on this or will you do this?

v3 it's an unofficial project at the moment, and I probably shouldn't have mentioned it.  Trying to pump myself into it. 😆
For some context, the plan is to create a new serializer as a separate project that supports numerous formats and then have ExtendedXmlSerializer be the XML version (along with classical support).
I emphasize plan as every developer has a plan until their code punches them in their face. 🤣  That's how it is for me, anyway.
In any case, I have captured our discussion here:
https://github.com/SuperDotNet/Super.NET/issues/27

ok, I notice that the performance is bad. Serialization of a List with the references to other classes and around 1 items takes several seconds (4-5).
Are there any plans for logging (ETW EventSource based) that would help pinpoint slow parts?

Ah, is this in debug mode, by chance @MagicAndre1981?  If an exception occurs in debug mode, there is a performance hit for sure (especially if you are emitting them in debug/console window), but in release mode it should operate more along expectations.

happens in both (debug and release, where release is only a bit faster)

Bummer.  If you can provide a simple repro/object graph in a new issue I will take a look at it to see if there is an obvious issue at play.

Here is what happens when I serialize the list:

Do you see anything to improve it?

Looks like something isn't getting cached correctly.  If you are able to create a simple hello world repro in a new issue, I can take a look into it. 👍

ok, I have now a small demo with Employee database of Firebird where a list of 42 items take 1.3s to serialize. Is this slow enough? What are expected times such serializing should take?

Ah, I am a bit confused on what you mean by Firebird/database, @MagicAndre1981.  Ideally, a simple Hello World demo is using ExtendedXmlSerializer exclusively without any other components such as a database or other APIs.  Then we know for certain it is our library without others being the culprit, if that makes sense.
My concern here is that your object graph is exposing a bug on our end that has yet to be discovered, which is why I am curious on how you're configuring/using our API for further discovery.

the data come from databases all time, to avoid network calls I currently use JSON to serialize them, but without references, when I use the cached data again, I need to do more network calls to fetch the reference data.
The graphic only show calls which occur during serializing in your lib, no other code.
If you don't want a demo with database calls I'm out here and can't help.

Ah, OK @MagicAndre1981.  What I would need to assist you is a simple Hello World .NET Core Console application hosted on your GitHub somewhere that demonstrates the issue.  Once you make that available I can further investigate to see if there is something obvious in your object graph that is causing the performance issue (or if there is one).
By the looks of the dotTrace graphic above, it would seem that the lambda expressions we are compiling are not being cached, but it is difficult to know for certain without being able to see the code/graph you are using to produce such results.

If you don't want a demo with database calls

To be certain, I do want a demo without database calls. 😁


Add: cell_nats service

This PR adds the cell_nats service, a NATS exporter for received cell signal strength metrics as reported by ModemManager. Exposed metrics include: RSSI, RSRQ, RSRP, and SNR for LTE, and RSSI, ECIO and SNR for UMTS (a.k.a 3G).
Metrics are exported though the cell.* topic, where each metric is a subtopic.
Cell signal metrics are expected to be received as:
[#1] Received on "cell.rssi"
{'value': -74.0, 'time': '2021-11-09 19:19:03'}

[#2] Received on "cell.rsrp"
{'value': -97.0, 'time': '2021-11-09 19:19:03'}

[#3] Received on "cell.rsrq"
{'value': -10.0, 'time': '2021-11-09 19:19:03'}

[#4] Received on "cell.snr"
{'value': 10.2, 'time': '2021-11-09 19:19:03'}

[#5] Received on "cell.tech"
{'value': 'lte', 'time': '2021-11-09 19:19:03'}

TO DO:

Test docker container in Toradex and Raspberry Pi test units
Test container after several sleep/wake cycles.

@facastiblancor I can do a proper code review next week.
In the meantime, a few quick questions.
Modem ID
Should we include some sort of modem identification in this message? We may have two or modems of various types over time.
Format
Are the metrics gathered at once / related to the same timestamp? If so, maybe something like
[#1] Received on "cell.status"
{"time": "2021-11-09 19:19:03", "rssi": -74.0, "rsrp": -97.0, "rsrq": -10.0, "snr": 10.2, "tech": "lte"}

could be easier to work with?
Some things worth discussion:

Subing to many topics and then re-indexing under the common time has been annoying in the past.
Data serialization / de-serialization overhead vs. costs of additional NATS messages. I'm not sure here, but I suspect 5 messages is more over head then de-serializing the joined JSON for just a few of the parameters. Also, using not JSON would also help.

Time / Avena standard structure
We should have standard structure across our messages. For another thread, but are we ready to pick a better format like protobuf, etc? Adding to a message schema is easy, but changing existing fields is breaking.
Time: String like "2021-11-09 19:19:03" or UNIX timestamp. A min, if a string we should include the timezone. I vote timestamp personally.
Only cell?
Using the paper's lingo. Is this a HAS or CAS? In other words, is this a generalize interface for radio strength or a MM/cell specific wrapper?
If we had a CBRS/TVWS/LoRaWAN/etc. radio would also want?
[#1] Received on "radio.status"
{'time': '2021-11-09 19:19:03', 'rssi': -74.0, 'rsrp': -97.0, 'rsrq': -10.0, 'snr': 10.2, tech: 'lte'}

[#2] Received on "radio.status"
{'time': '2021-11-09 19:19:03', 'rssi': -74.0, 'rsrp': -97.0, 'rsrq': -10.0, 'snr': 10.2, tech: 'lte'}

I ask, because maybe we do want a cell.* as you have hear then is combined with lorawan.*, cbrs.*, etc. to make a radio.* topic?

@abalmos Sounds good. Just wanted to open up the discussion.
Should we include some sort of modem identification in this message?
Indeed we can include a modem ID. Though, ModemManager IDs are not consistent for each system, and are very likely to change after each sleep/wake cycle. I have seen cases where the modem ID keeps increasing daily during the season to numbers like 400.
Are the metrics gathered at once / related to the same timestamp?
Yes, they are gathered at once and can be related to the same timestamp, even though they are split into 5 different messages.
...could be easier to work with?
Indeed it is easier to work with a single status message, and I consider the deserialization overhead lower than that of creating 5x the amount of messages. However, the reason I chose to split into different topics was to be consistent with j1939d's and cand's, by splitting the main topic into subtopics for each metric.
Time / Avena standard structure
I vote for UNIX timestamp. It's better to leave all the time/date decoding to other services. However, the reason I chose the format presented on the initial commit was to ease testing. I plan to change this right before merging. Also, I don't think timezone info is necessary, as long as UTC is enforced for all services.
Is this a HAS or CAS?
CAS. Planned this as a MM wrapper to ease signal strength info collection. However, a model to standarize radio status logging would be great. Could be the opener for a future discussion.


metrics: exception when browsing to product metrics

when browsing directly to a product metrics page, there is no referrer and this generates an exception:
Internal Server Error: /product/156/metrics
Traceback (most recent call last):
  File "/home/valentijn/venv/lib/python3.8/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/valentijn/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/valentijn/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/valentijn/dd/dojo/user/helper.py", line 79, in _wrapped
    return view_func(request, lookup_value, *args, **kwargs)
  File "/home/valentijn/dd/dojo/product/views.py", line 408, in view_product_metrics
    view = identify_view(request)
  File "/home/valentijn/dd/dojo/product/views.py", line 206, in identify_view
    if referer.find('type=Endpoint') > -1:
AttributeError: 'NoneType' object has no attribute 'find'

Seems to be caused by multiple levels of 'get earliest finding' and 'get earliest date' and daterangefilter in the productmetricsfindingfilter.


Docker

Sabj

Hello there , what's the issue here?

I did not find the image on the docker hub

Because there isn't one


Removes unused files, types, exports, dupe exports, and adds unlisted deps

Checklist:

[X] I have read freeCodeCamp's contribution guidelines.
[X] My pull request has a descriptive title (not a vague title like Update index.md)
[X] My pull request targets the main branch of freeCodeCamp.
[X] I have tested these changes either locally on my machine, or GitPod.

Closes #47971

Should close all checklist items from #47971 in a single PR. I think I covered everything, but not 100% sure.
I had to leave some functions/classes as exports because they were actually being used and needed to be tested in unit tests. This was only the case with a few of them.

Hi @tom-raley thanks for your hard work on this, it's looking great.
We just merged a couple of PRs that dealt with some of the tasks. I believe there are some minor conflicts that GitHub has not picked up on.  If you could rebase your PR onto main, that would be awesome.
Finally, a few tests have started failing. Could you see what's going on there?

Hi,
We are closing old issues/pull requests that we think are stale. If you still need help or are fixing this, please open a new issue/pull request.
Thanks for your understanding.
Happy contributing.


No link to the ScalaTags Google Group in doc?

The link to the ScalaTags Google Group has been removed from the readme. Maybe is better to add it back?
https://groups.google.com/forum/#!forum/scalatags

Fixed, there's a link in http://lihaoyi.github.io/scalatags/ =)


DimensionMismatch error in MPC_models.jl

Hi,
I am trying to run the LMPC with the simulator by the following command:
roslaunch barc barc_sim.launch
However, I faced with the following run-time error:
ERROR: LoadError: DimensionMismatch("dimensions must match")
 in promote_shape(::Tuple{Int64,Int64}, ::Tuple{Int64}) at ./operators.jl:365
 in setvalue(::Array{JuMP.Variable,1}, ::Array{Float64,2}) at /home/alex/.julia/v0.5/JuMP/src/JuMP.jl:902
 in MpcModel_pF(::MpcParams, ::ModelParams, ::TrackCoeff) at /home/alex/catkin_ws/src/barc/src/barc_lib/LMPC/MPC_models.jl:342

I have replaced  line 342 on several lines:
            setvalue(z_Ol[i,1],(i-1)*dt*v_ref)
            setvalue(z_Ol[i,2],0)
            setvalue(z_Ol[i,3],0)
            setvalue(z_Ol[i,4],v_ref)
            setvalue(z_Ol[i,5],0)

Also I have replaced line 345 on several lines.
After replacing there is no the error, but I am not sure that it is correct way, because I see in log that IPOPT cannot find solution:
WARNING: Not solved to optimality, status: UserLimit
Finished solve 1: UserLimit
WARNING: Ipopt finished with status Restoration_Failed
WARNING: Not solved to optimality, status: Error
Finished solve 2: Error

What is right way to solve this issue?
PS. I am using the LMPC branch, Ubuntu 14.04 and ROS Jade.
Alex

Hi Alex,
Which version of Julia are you using?
We developed the simulator using Julia 0.4.7 and unfortunately the code does not run with Julia 0.5.
I tested the code on my machine using 0.4.7 and it worked correctly.
Please let me know if this fixes the issue or we need to look at it more carefully
Thanks
Ugo

Hi Ugo,
Yes, I used the Julia 0.5. I will install 0.4.7 and test it.
Thank you!
Alex

Hi Alex,
Let me know if you have any question about the code or the LMPC
Thanks
Ugo

I have installed the Julia 0.4.8 and the issue disappeared.


[FP]: SnakeYAML 1.32 is no longer affected by CVE-2022-38725

Package URl
<EMAIL_ADDRESS>CPE
cpe:2.3:a:snakeyaml_project:snakeyaml:1.32:::::::*
CVE
CVE-2022-38752
ODC Integration
{"label"=>"Maven Plugin"}
ODC Version
7.1.0
Description
There is no version range included in https://nvd.nist.gov/vuln/detail/CVE-2022-38752. But although the underlying issue https://bitbucket.org/snakeyaml/snakeyaml/issues/531/stackoverflow-oss-fuzz-47081 was fixed in 1.32 this version is still reported as being affected.

Unfortunately the CVE is of poor quality by not including affected versions, however the generated suppression rule is too broad, as it does not include a version.
I've created a PR with Github to add the version: https://github.com/github/advisory-database/pull/667

Since this is an issue with a single CVE the upstream data should be fixed rather than doing so in OWASP dep check itself. I believe suppressions here are supposed to only be about package <> CPE mismatches.
Have contacted NVD to try and get it fixed upstream anyway.

It has been fixed upstream at NVD. Thanks a lot for your help.

Yeah, they responded pretty quickly to my request for review 👍


Restore support for pure-native/hybrid Projects

Description
While greenfield React Native projects are well supported on Android, support for brownfield / pure-native ones seems to be broken. With an effort I assume to be not incredibly large, we ought to have this fixed.
Related issues: #1220, #1093.

@d4vidi any ideas if we have enough capacity for now to take a look at it this summer at least?

It's hard to tell for sure at this point, but it does seem unlikely - at least for ~Q3 area.
Presumably, we'll be busy introducing multi-apps support and doing some refactoring, all-the-while having a slow Q overall (in work-days perspective).

Hi @d4vidi is there a timeline for this issue to be fixed?

updates will you get android support?


Solved multiple page loading issue

Mam @sanika391 Resolved multiple page loading issues #22 .
Screencast from 2024-05-23 12-30-50.webm

Thank you, @Pra-kas, for resolving the multiple page loading issues. Your contribution is greatly appreciated, and I see that it addresses issue #22 effectively.
I'll review the changes, and if everything looks good, I'll proceed with merging the PR. Please make sure to add any relevant labels to this PR.
Best regards,
Sanika Chavan.
[https://www.linkedin.com/in/sanika-chavan-52457b236]

@sanika391 Mam this PR is not reflected in my performance.All 3 PR i contributed is not reflected in my leaderboard mam.


[1.12] evaluate new single-letter flags before GA

With the SwarmKit integration, many new commands and options were added; we should be careful when adding shorthand (single-letter) flags to commands, and only use shorthand flags for frequently used options.
In doubt; remove the shorthand flag, so that we can decide later when really needed.
Opening this issue so that we don't forget to evaluate all new flags before GA

Here is a list of short flags, along with the command, the long flag version and a quick consistency check with other docker command.
| Command | Short flag | Long flag | Consistency |
|---|---|---|---|---|---|
| node inspect | -f | --format | yes (docker inspect) |
| node inspect | -p | --pretty | no, see #24122 && #24148 |
| node ls | -f | --filter | yes (docker ps) |
| node ls | -q | --quiet | yes (docker ps) |
| node tasks | -a | --all | yes (docker ps) |
| node tasks | -f | --filter | yes (docker ps) |
| node tasks | -n | --no-resolve | no, -n means --last in docker ps |
| service create | -e | --env | yes (docker run) |
| service create | -l | --label | yes (docker run) |
| service create | -m | --mount | no, -m means memory for docker run |
| service create | -p | --publish | yes (docker run) |
| service create | -u | --user | yes (docker run) |
| service create | -w | --workdir | yes (docker run) |
| service inspect | -f | --format | yes (docker inspect) |
| service inspect | -p | --pretty | no, see #24122 && #24148 |
| service ls | -f | --filter | yes (docker ps) |
| service ls | -q | --quiet | yes (docker ps) |
| service tasks | -a | --all | yes (docker ps) |
| service tasks | -f | --filter | yes (docker ps) |
| service tasks | -n | --no-resolve | no, -n means --last in docker ps |
| service update | -e | --env | yes (docker run) |
| service update | -l | --label | yes (docker run) |
| service update | -m | --mount | no, -m means memory for docker run |
| service update | -p | --publish | yes (docker run) |
| service update | -u | --user | yes (docker run) |
| service update | -w | --workdir | yes (docker run) |
Overall, there is not that much, and most of them seems consistent with current cli. I think the main question are for :

-m/--mount on service create/update
-p/--pretty on inspect commands (note that, I do agree with @cpuguy83 on #24122 on the fact that pretty should be a format, and we could use --format=pretty).
-n/--no-resolve on node/service tasks commands.

Wow, this is awesome; thanks so much Vincent!

On 09 Jul 2016, at 02:58, Vincent Demeester<EMAIL_ADDRESS>wrote:
Here is a list of short flags, along with the command, the long flag version and a quick consistency check with other docker command.
Command	Short flag	Long flag	Consistency
node inspect	-f	--format	yes (docker inspect)
node inspect	-p	--pretty	no, see #24122 && #24148
node ls	-f	--filter	yes (docker ps)
node ls	-q	--quiet	yes (docker ps)
node tasks	-a	--all	yes (docker ps)
node tasks	-f	--filter	yes (docker ps)
node tasks	-n	--no-resolve	no, -n means --last in docker ps
service create	-e	--env	yes (docker run)
service create	-l	--label	yes (docker run)
service create	-m	--mount	no, -m means memory for docker run
service create	-p	--publish	yes (docker run)
service create	-u	--user	yes (docker run)
service create	-w	--workdir	yes (docker run)
service inspect	-f	--format	yes (docker inspect)
service inspect	-p	--pretty	no, see #24122 && #24148
service ls	-f	--filter	yes (docker ps)
service ls	-q	--quiet	yes (docker ps)
service tasks	-a	--all	yes (docker ps)
service tasks	-f	--filter	yes (docker ps)
service tasks	-n	--no-resolve	no, -n means --last in docker ps
service update	-e	--env	yes (docker run)
service update	-l	--label	yes (docker run)
service update	-m	--mount	no, -m means memory for docker run
service update	-p	--publish	yes (docker run)
service update	-u	--user	yes (docker run)
service update	-w	--workdir	yes (docker run)
Overall, there is not that much, and most of them seems consistent with current cli. I think the main question are for :
-m/--mount on service create/update
-p/--pretty on inspect commands (note that, I do agree with @cpuguy83 on #24122 on the fact that pretty should be a format, and we could use --format=pretty).
-n/--no-resolve on node/service tasks commands.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.

ping @sfsmithcha

I think we should remove the -m, -p and -n flags, and adding a --file for stack deploy. Especially the -m for service create, because people would expect this to be --memory

Actually, looks like we picked --bundle as long flag for stack deploy, which may be really confusing;
 -f, --bundle string   Path to a Distributed Application Bundle file (Default: STACK.dab)