Document Psalm in readme

Codecov Report
Base: 73.59% // Head: 73.59% // No change to project coverage :thumbsup:

Coverage data is based on head (f2542ee) compared to base (21d6616).
 Consider uploading reports for the commit 8b6bf0b to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             develop      #49   +/-   ##
==========================================
  Coverage      73.59%   73.59%
  Complexity       195      195
==========================================
  Files             33       33
  Lines            587      587
==========================================
  Hits             432      432
  Misses           155      155

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Note missing - Azure Active Directory Global Administrator needed

In the Requirements section there is a note missing:
The first Azure Databricks account admin must be an Azure Active Directory Global Administrator at the time you first log in to the Azure Databricks account console.
we were only able to successfully setup the metastore with the help of support and this hint.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: e8a44621-ac8f-caa2-f0b5-e967aed05bdf
Version Independent ID: e8a44621-ac8f-caa2-f0b5-e967aed05bdf
Content: Create a Unity Catalog metastore - Azure Databricks
Content Source: databricks/data-governance/unity-catalog/create-metastore.md
Service: azure-databricks
GitHub Login: @mssaperla
Microsoft Alias: saperla

Hi @gfallerBCAG
Thanks for reporting this! We have created a PR for this issue and the changes should go live soon.

@gfallerBCAG
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Refactor DataTables factory

In this PR, I would like to refactor a clean API for the DataTables factory.
ref: https://github.com/yajra/laravel-datatables/pull/1462#issuecomment-340034303

[BC] Exchange key and value for the builders config.
Builders should be mapped from engines to types because the engines are unique. This change will allow configuring different engines for the same type.

Keys in the builders config can be an engine alias which defined in the engines config, or an engine class name.
Engines in the builders config can be a class name now.
'builders' => [
    Illuminate\Database\Eloquent\Builder::class => 'eloquent',
    App\BillData => App\DataTables\BillDataTable::class,
],

Add support to specify any types in the builders config.
'builders' => [
    'image' => [
        'resource',
        'array',
        Illuminate\Support\Collection::class,
    ],
],

[BC] Change static methods of() and make() in DataTables to instance methods. Remove Yajra\DataTables\DataTables::of and Yajra\DataTables\DataTables::make usage.
Since the DataTables has been registered as a singleton in the container, using the ugly (original DataTables) class directly is a bad design in this situation. Think about if the user or an extended package override make() method, the user must replace all DataTables::make to CustomDataTables::make.
If someone prefers to access DataTables methods using static way, the facade is the best choice.
\DataTables::make(...)
\Yajra\DataTables\Facades\DataTables::instanceMethod()

Add support to make DataTable instances using configured engines alias as DataTables methods.
'engines' => [
    'eloquent' => ...,
    'foo_bar' => ...,
],

\DataTables::eloquent($data);
datatables()->fooBar($data);

Remove unnecessary canCreate, create interfaces for DataTable engines.
To implement a new DataTable, just start with __construct.

Remove unnecessary Macroable trait for the DataTables.
For now, the DataTables is just a factory to create DataTable instances, we do not want user to add macros to make it messy. If you want to register a custom engine, just add alias to the engines configuration.

Remove support of variable length parameters for make().
See https://github.com/yajra/laravel-datatables/pull/1487#issuecomment-340184553

[TODO] Remove needless backward compatibility. @yajra
$request
$html

getRequest()
getConfig()
queryBuilder()
getHtmlBuilder()

Extending Notes

The DataTables factory depends upon the configuration of engines and builders.
engines config just acts as class aliases, like app()->bind('eloquent', 'Yajra\DataTables\EloquentDataTable'). Adding an engine alias is only needed if you want to use this alias as a method of DataTables to resolve the DataTable instances, like datatables()->eloquent(...).
make() automatically decides an engine class by comparing the type of given data with types defined in the builders config.
There may be different engines for the same type, in this case we can not autoselect in anyway, so let the user (application) decide. make() will use the first match.
If you are developing a public package that contains some DataTable engines, it is not recommended to change/set/merge user's datatables.builders configuration. Just document what you provide, and let user be free to use them.

Here are my 2cts.

Fixing the use of the singleton class in DataTables looks like a nice fix!

Removing dependency on Macroable and using __call in DataTables ourselves is fine with me. I used Macroable as its the go to method for plugin features in Laravel but I have no issue with removing that.

Relying on is_xxx functions makes custom engines less flexible. Eg what if I want to switch engine based on a class property? Then I need to add two separate / custom is_propery_a and is_property_b helper functions. Imho using canCreate is much cleaner as the DataTable engine has full control and all the logic is in one place.

Because you removed the factory method create you now cant specify the correct source type in the constructor of Collection. Imho that is bad design, the constructor for the Collection engine should only accept variable types it really can works with. Now I can instantiate a CollectionEngine as follows

$someClass = new EloquentDataTable(); // could be anything, just an example
$engine = new CollectionDataTable($someClass);

Imho above code should give an error like First parameter of CollectionEngine should be an instance of Collection, but EloquentDataTable given and not just fail on the new Collection($source) line as the EloquentDataTable source cannot be converted to a Collection.

Using 2nd level config parameters is ill-advised, mergeConfigFrom doesnt do a 'deep merge' but only merges the 1st level of config variables. So by adding the array option to engines/builder you now need to make sure to merge default values for them as well in setupAssets.

One of the key features I tried to do in #1462 was to make configuration easier. To me this PR does exactly the opposite by still relying on the builder mapping for default functionality and even introducing a second level of parameters. When you create a package that package should always provide the functionality as (the developer) intended. It is nice if you are able to extend (and in some degree override) that functionality, but the basics should always work. That shouldnt only count for this package but also for any custom engines. This will prevents issues like 'This package s*cks because it doesnt work' just because somebody completely f*cked up their config causing everything you have written carefully down in your documentation not to apply anymore.

Because you removed the factory methods canCreate and create I introduced, you now indeed have the problem you describe in #1487. Your solution to therefore just remove variable parameters exactly proves my third point: this PR makes things less flexible

That said, from a technical point of view I understand that the major difference between my PR and this PR is possibly the memory profile. Probably this PR uses a bit less memory, as using static factory methods on the DataTable engine class itself needs to load all DataTable engine classes into memory until it finds a matching one.
But I think there is a good reason to accept that memory usage, because (as explained above) the trade in is that we otherwise are less flexibel.
And very importantly, it will only use more memory if and only if you use the make method. If you really care about memory usage you shouldnt use generic methods like DataTables::make anyway but write your code in a style so that you already know which DataTable engine is going to be used.

@pimlie
Thanks very much for your kind points.
I think DataTables::make() is just a factory which provides a convenient way to create DataTable instances, and without using it, all DataTable engines can and should work as normal too. There is no relationship between DataTables and engines. We should not force users to only use DataTables factory methods to create engines.
If the user pass unproper source to an engine, in my opinion, failure as error is just OK. I think you wont like the following code, right?
$query = User::query();

if (QueryDataTable::canCreate($query)) {
    $dataTable = QueryDataTable::create($query);
} else if (EloquentDataTable::canCreate($query)) {
    $dataTable = EloquentDataTable::create($query);
} else {
    abort(500);
}

return $dataTable->toJson();

If an engine needs exact type of data to create, type hinting in the constructor will be fine, like QueryDataTable does.
And for another example, let's see the built in CollectionDataTable:
public function __construct(Collection $collection)
{
    $this->collection = $collection;
}

Actually it can handle any type which could be converted to a Collection instance, such as array, Arrayable, Jsonable. For convenience, we can remove the type hinting:
public function __construct($source)
{
    $this->collection = $source instanceof Collection
        ? $source : new Collection($source);
}

Now user can create a CollectionDataTable instance from array, Arrayable or Jsonable directly.
And imagine this, the Collection may add support for other types in the future, such as Traversable, JsonSerializable, our CollectionDataTable can still work well without any upgrade, to the author of CollectionDataTable or to the user. FYI here and here.

Relying on is_xxx functions makes custom engines less flexible. Eg what if I want to switch engine based on a class property?

I think PHP built-in is_xxx functions are sufficient for a DataTable engine. Does anyone want to implement such engine:
class AwesomeDataTable implements DataTable
{
    protected $source;

    public function __construct($source)
    {
        $this->source = $source;
    }

    public function count()
    {
        if (is_array($source)) {
            return count($source);
        } else if (is_string($source)) {
            return strlen($source);
        } else if ($source instanceof Collection) {
            return $source->count();
        } else if ($source instanceof Builder) {
            return $this->countForBuilder();
        } else if ($source instanceof DbQuery) {
            return $this->countForDbQuery();
        } else if ...
    }
}

BTW, if we want to use create method to make DataTable engines, we may should add canCreate and create interfaces to the DataTable contract.

For now, I can not think of any case that need variable parameters to create a DataTable engine. If there is, autoselect of make() may not work correctly, even with canCreate and create support.
For example:
class CollectionDataTable extends \Yajra\DataTables\CollectionDataTable
{
}

class FooDataTable implements DataTable
{
    public static function canCreate($data, $options)
    {
        return $data instanceof Collection && is_array($options);
    }
}

class BarDataTable extends FooDataTable
{
}

Since FooDataTable or BarDataTable needs two parameters to create, and they have the same signature, we can not specify them in the builders config.
// Configuration
'engines' => [
    'collection' => 'App\DataTables\CollectionDataTable',
    'foo' => 'App\DataTables\FooDataTable',
    'bar' => 'App\DataTables\BarDataTable',
],

'builders' => [
    'Illuminate\Support\Collection' => 'collection'
],

// DataTables::make
$args = func_get_args();
foreach ($builders as $class => $engine) {
    if ($source instanceof $class) {
        return call_user_func_array([$engines[$engine], 'create'], $args);
    }
}

foreach ($engines as $engine => $class) {
    if (call_user_func_array([$engines[$engine], 'canCreate'], $args)) {
        return call_user_func_array([$engines[$engine], 'create'], $args);
    }
}

For DataTables::make($collection, $array) :

It will always create a CollectionDataTable instance because if ($source instanceof $class) only checks the first parameter.
After removing collection in builders, it will always create a CollectionDataTable instance.
After removing collection in engines and builders, it will always create a FooDataTable instance.

Factory depended upon configuration is a common design. Think about Laravel Auth Guards, Cache, Database, Filesystems, Queue, etc. Users are free to config/override/remove any of built-in engines. So mergeConfigFrom is not an issue, we don't need to merge default values for them.
Everything is limited. I'd like to make it simple, clean, unify, easy to use, in a reasonable range.

should give an error like First parameter of CollectionEngine should be an instance of Collection

public function __construct($source)
{
    if (! ($source instanceof Collection || is_array($source))) {
        throw new InvalidArgumentException(...);
    }

    // ...
}

I think most of our differences are just because we have a different preference on how to setup our code, I really dont think the constructor of a class should be the place that automagically converts sources.
Again, this is just a personal preference. You could argue that using non type hinted / mixed arguments on a function in php is as close as you can get to function overloading like you can do in strictly typed languages. But the major difference is that with function overloading you still exactly define which types you accept and with accepting a non type hinted argument in php you accept everything and have to check afterwards.
With regards to your comment about the FooDataTable and BarDataTable, this is actually the reason why I proposed in my last comment in #1462 to remove the engines builder configuration as well :wink: Have a look at the boot method in the service provider I added to the mongodb engine as I exactly have the problem you describe with the Eloquent engine there: https://github.com/pimlie/laravel-datatables-mongodb/blob/master/src/MongodbDataTablesServiceProvider.php
This would imho be the preferred way of registering custom engines. Also read my comments in the readme about the order of adding the mongodb dataservice provider. This way a custom DataTable engine also has control over the order of datatable engines and can even insert itself between two existing datatables.
I am sorry but I just really dont see the advantages of this PR except for the changes to the DataTables singleton. Not sure why you are so set to reverse my changes but my PR is as flexibel as it can get. This PR is just a different way of doing things but I disagree with you that this PR is simpler and/or cleaner.
As I am sure that you and me will probably never get to agree about this, I guess its up to @yajra to decide what to do :smile:

Yeah, different stands.

@ElfSundae and @pimlie , thanks for the very informative exchange of comments.
Maybe you could combine this together with #1462 I prefer using both of them.

@ChaosPower I don't think combining is a good idea.
Think about it for the sake of users:

How can I use the DataTable engines or their factory?
What things should I know before extending built-in engines or adding a new one? Are they easy to understand?
If I want to publish a package providing my extended built-in engines or new engines, what other things should I care except implementing the DataTable contract? And which kinds of updating should I follow from yajra/laravel-datatables?

@ElfSundae I like both your PRs and can see combining them benefits more audience.

How can I use the DataTable engines or their factory?
I want to be able to use both DataTable engines and custom factories

What things should I know before extending built-in engines or adding a new one? Are they easy to understand?
Should know OOP and they should be easy to understand. Of course well document. Provided with samples.

If I want to publish a package providing my extended built-in engines or new engines, what other things should I care except implementing the DataTable contract? And which kinds of updating should I follow from yajra/laravel-datatables?

If I want to publish for Laravel 5.5+ the 3rd party package or plugin should be auto-discovered. I care about performance but of course sometimes when you are in a hurry, a quick way to implement and check things should be available. I do not quite get what you meant by which kinds of updating should be followed. I will leave that for @yajra to answer.`
I like how the configs are now merged.

    /*
     * DataTables accepted builder to engine mapping.
     * This is where you can override which engine a builder should use.
     */
    'builders'       => [
        'eloquent'   => [
            Illuminate\Database\Eloquent\Builder::class,
            Illuminate\Database\Eloquent\Relations\Relation::class,
        ],
        'query'      => Illuminate\Database\Query\Builder::class,
        'collection' => [
            'array',
            Illuminate\Support\Collection::class,
        ],
    ],

@ChaosPower As mentioned before, please note that if a user at first decides to empty the collection config like this collection' => [] (eg as they think they will not use it and removing codes makes everything run faster /s) he/she will not be able to use the CollectionEngine at all anymore. Unless he/she adds it back again or we add a deep merge in the service provider boot.
That is a breaking change compared to how the config works currently, but with what benefits? Its mostly esthetics and actually it provides the possibility to add the same builder class to two different engines, thus with unexpected results.
I agree with @ElfSundae that combining code (except for the changes to the singleton and macroable) is probably not really useful as we do mostly the same things just in a slightly different way. My PR is really DataTableEngine centric and this PR is more generally centered around DataTables config. Both have advantages and disadvantages and both have even more overlap with the other then we discussed until know.
Actually I was trying to write a list of major differences here but while making that list every time I came to the conclusion that 'yes but then for the other PR you could do this and the result would be the same'...
So eh, I guess its really up to @yajra to decide who is going to get the final :trophy:

@pimlie Actually I don't understand clearly some of your thought such as "flexible", "full control using canCreate", and "make configuration easier", even I tried to accept for many times. @yajra merged your PR before, maybe he will be more able to agree with your point of view. So could you please submit a PR with patches such as "the changes to the singleton and macroable" ? Thanks.
And I have several issues with your idea, these may be resolved to improve your PR:

If the factory uses canCreate and create to make engines instances, should we add these interfaces to the Yajra\DataTables\Contracts\DataTable ?
If we need to add them for some reasons like you said, "the DataTable engine has full control", "the constructor of the engine should only accept variable types it really can works with", do users need to update their code from new EloquentDataTable($query) to EloquentDataTable::canCreate($query) ? EloquentDataTable::create($query) : what_will_be_here() ?
If we don't add these interfaces, custom engines may never be created by the factory, as they may implement the contract directly (not a subclass of DataTableAbstract), or they did not override the canCreate (the default value in DataTableAbstract is false).
I found your PR when I updated composer and my custom engine could not be resolved just because the default canCreate is false.

If we want to support variable parameters for the engines, should we fix the default implementation of create and the method signature for canCreate create in the DataTableAbstract :
public static function create($source)
{
    return new static($source);
}

You may try to implement a new engine which accepts variable parameters.
And please take note of if ($source instanceof $class), it only checks the first argument.

If we use Macroable for the factory, do we need to bootstrap a service provider to repeatedly register macros like you did in your PR and your mongodb package:
foreach (static::$engines as $engine => $class) {
    $engine = camel_case($engine);

    if (!DataTables::hasMacro($engine)) {
        DataTables::macro($engine, function () use ($class) {
            if (!call_user_func_array(array($class, 'canCreate'), func_get_args())) {
                throw new \InvalidArgumentException();
            }
            return call_user_func_array(array($class, 'create'), func_get_args());
        });
    }
}

Imho above code should give an error like "First parameter of CollectionEngine should be ...

How to achieve this exception? The factory does not know what checks in canCreate. If we throw it in canCreate or create, I can not see any advantage over throwing it in __construct.

About the note for the order of engines config, I read the readme of your mongodb package. It seems the service provider is optional and the only purpose of this provider is to help user to add engines (with the author preferred names) which your package provided to the first order, on every request, and it should be registered after Yajra's provider which means users using Laravel 5.5+ need to disable package discovery for yajra/laravel-datatables-oracle. What if another package provides the same provider?
To me, after reading the readme and exploring the code of the service provider, finally I found that all I need to do is just adding engines which the package provided to my datatables config file, e.g. 'any-name-i-love' => 'Pimlie\DataTables\MongodbDataTable::class',.
Or I misunderstood something?

Quite some remarks, see below

About create methods:

Yes, you are right. They should probably be added there as well. Good catch!
In this case the factory method is supplemental just for the make method. If you know you need the EloqouentDataTable just instantiate that class directly. Just as before, nothing has changed about that.

Although custom engines can use multiple parameters, default behaviour is just one. We should probably add a comment in the doc of the DataTables contract about this. Dont think it is wrong that the default behaviour doesnt reflect all the possibilities you can do when you build a custom engine?

About macroable

I already mentioned a couple of times I am ok to use your solution for this
What do you mean with 'repeatedly'? If DataTables is a singleton the if hasMacro prevents registering the same macro twice.

Maybe we have a misunderstanding about the factory methods. But as said above, the create methods were only meant to be used by the magic make method. Also maybe I just don't understand your use-case? How many custom engines do you have for a standard laravel Eloquent model? And what are the differences between them and how/when do you use one or the other?

About your last point, sorry but I feel like now you are just starting nit-picking a bit and I have to explain the obvious. Yes, if a laravel package depends on another laravel package and one of them uses auto-discovery it seems you cant be assured that the providers will be loaded in the correct order. This is not specific to our use case.
I also said in the readme that the service provider or config only needs to be added/changed if you want to use the magic make or of method. If you dont use either of those, you dont have to add the service provider. Please remember that a convenience / magic method like make will always come at a price.

Hopefully to finally end this discussion, all the partially pseudo code below are (still) valid ways of getting a datatable:
class eloquentUserModel extends Eloquent\Model {
  use EloquentDataTableTrait;
}

$dataTables = new EloquentDataTable(eloquentUserModel::all());
$dataTables = eloquentUserModel::dataTables();
$dataTables = DataTables::eloquent(eloquentUserModel::all())
$dataTables = DataTables::make(eloquentUserModel::all())
$dataTables = datatables(eloquentUserModel::all())

If you use the first 2 methods, the create methods and/or datatables configuration are not used. If you care about performance etc you write your code in a way that you use one of these methods!
If you use the 3rd method, the datatables config should have an engines array to map the called function name to an engine class. As you can't type hint these dynamic functions we could use the create methods here, but we could also just try to instantiate the class. I have a slight preference for the latter as when the user specifically calls eloquent we should be assured that the user will pass a eloquent model. But I have no problem with using a create here. I dont really see the need for these methods actually, maybe we should remove them in a next major? For now we should support them in the best way
If you use the 4th or 5th method the create methods will be used. You need at least the engines config but if you also provide builders you can override default behaviour of the engines. This is a convenience method which has draw backs. Its nice to have but if you write your code well you'd actually make sure you will never depend on this method.

In my opinion the following behaivour is also correct:
$array = array_to_be_used_in_datatable();

// Throws error as array !== Collection
$dataTable = new CollectionDataTable($array);

// Throws error as array !== Collection or not? Up for discussion
$dataTable = DataTables::collection($array);

// Works as the create method converted the array to Collection. What a _convenience_! ;)
$dataTable = DataTables::make($array);

// Works, duh
$collection = new Collection($array);
$dataTable = new CollectionDataTable($collection);
$dataTable = DataTables::collection($collection);

I think most of our differences are just because we have a different preference on how to setup our code

You are right, different personal preferences on coding.
My preference is going to decouple the DataTables factory from others, by removing unnecessary canCreate create methods which being called only from the factory, and removing other currently unneeded legacies like getHtmlBuilder() getRequest() which the html or buttons plugin (depended on v8.* of this package) does not use them any more.
Please forgive my bad eyes, I can not see any helpful or strong reasons for adding canCreate or create to the DataTable engines, except throwing an exception of "No available engine for xxx" instead of failure on error when improper data source being given to the sole DataTables::make() method.
Besides, in my opinion using them will bring confusion somewhere, such as I need to pay attention to data type in three places: canCreate, create, and __construct; or new CollectionDataTable($array) failed while datatables($array) working fine.
To me, less is more.
BTW, I was not nit-picking in my last point. Using the factory to create DataTable engines is the recommended way in the readme of this package and the datatables:make command, then most of users will use the factory way. My point was just the truth that I found out: the service provider which ships with one-time & one-situation task is unnecessary to bootstrap on every request, even without thinking of another same provider.
Let's end this kind of discussion. Please submit your patched PR, let @yajra decide 👻

Thanks for your insights, this really is/was an interesting discussion! Maybe you look more to it from a developers point of view, someone who is actively working on custom engines? And my view is more from a users point of view, where the engines have already been created and its just about using them?
I fully agree with you that using the service provider to register the engine is a bit more costly then including it in the datables config, but again convenience comes at a price. The reason I thought you were nitpicking was mostly because of what you said about the order of loading the service providers. In the mean time I looked into this, and it seems this will not be a problem due to PR 19646 in @laravel /framework.
Although I am happy to submit a PR, I will wait until @yajra speaks his mind about this :smile:
One final note, could you maybe share your config that failed due to the missing canCreate method? Maybe this is just a bug? Because my impression was that my PR would be fully backwards compatible but if you got an error due to the default canCreate returning false I guess its not?

Yeah, as I said, different stands. But our users are also developers. :smile:
To general users which just use the built-in engines, it's all okay to use out of the box before/after your/my PR.
FYI: The order of package discovery may be from vendor/composer/installed.json, see PackageManifest::build.
Sorry I was messed, I wanted to say create, not canCreate. I have a custom engine that just implements the DataTable contract, it has no create method.

Merged 8.0 branch.
@yajra StyleCI analysis  seems strange, see https://styleci.io/analyses/qv5b5V and https://styleci.io/analyses/zRb21j
I need to fix it to :
'builders' => [
    'eloquent' => [
        Illuminate\Database\Eloquent\Builder::class,
        Illuminate\Database\Eloquent\Relations\Relation::class,
    ],
    'query'      => Illuminate\Database\Query\Builder::class,
    'collection' => [
        'array',
        Illuminate\Support\Collection::class,
    ],
],

Is there something wrong with our StyleCI config?

Going to hold-off this atm since there are some breaking changes. Please target to master branch since this may need a major bump? Thanks!

Updated base branch to master.
And I am thinking restore the builders format...

Updated:

Reverted builders configuration to the original format, no BC now.
Improved engine auto choosing

Updated PR description.

It does not make sense to support number/bool/string for a DataTable engine, so I removed is_xxx() condition.
Now the DataTables::make can automatically choose the optimum engine for the data source, there is no need to care about the engines order in the builders configuration.

Outdated and too many conflicts, may not be needed anymore on latest version. Thanks!


Coverage report of built app doesn't map to source files

Link to bug demonstration repository
Repro repo
I think I followed the docs correctly, but it's certainly possible I missed a step 🤣
Expected Behavior
According to this, running a coverage report for a built app should map back to original source files.
Steps taken in above repo:

Create empty app using create-react-app
Build app, which generates sourcemaps
Following these docs, instrument build output using nyc instrument ./static ./static-i
Swap static directories so instrumented code is served
Run automated tests, aggregating window.__coverage__
Following these docs, dump coverage data to .nyc_output/out.json
Run nyc report --reporter=html

Observed Behavior
The report shows coverage for built files, not source files.
Troubleshooting steps

[x] still occurring when I put cache: false in my nyc config

Environment Information
System:
    OS: macOS 10.14.5
    CPU: (4) x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
    Memory: 242.63 MB / 16.00 GB
Binaries:
    Node: 10.13.0 - /usr/local/bin/node
    Yarn: 1.7.0 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm

For more context, I can run remap-istanbul and that generates reports (mostly) correctly, but I'd like to move to the currently supported version of IstanbulJS.

@evanbb try setting the configuration setting "remap-after-coverage" to false.

@bcoe thanks - I gave it a go with command below:
npx nyc report --remap-after-coverage=false --reporter=html
However, it seems to produce the same result with or without that option set. I also tried setting it in my package.json, but that didn't seem to work, either.
I also tried with --exclude-after-remap=false as suggested here, but no luck 😞
Do those flags need to be set at time of instrumentation instead of at time of reporting?

Hmm, tried running with those options during instrumentation and got the same result 😞

@evanbb mind sharing a repository that's having the issue you're describing?

@bcoe sure thing: https://github.com/evanbb/nyc-instrument-and-report-bug
I stepped into it a bit, and it looked like the reporting logic is trying to reload the sourcemaps from cache here:

I'm having the same problem.
When using nyc instrument, the window.__coverage__ is generated for the compiled files instead of source files. nyc report then shows empty report because the window.__coverage__ values does not have contentHash, only hash.
I've also tried adding the instrumentation during the build step using babel-plugin-istanbul. Using this approach, window.__coverage__ is generated for the correct source files. However, nyc report again shows empty report because even in this case, window.__coverage__ does not have contentHash value.
So I think we have two separate issues

How to make nyc instrument process source maps?
How to make nyc report accepts coverage data stored in window.__coverage__?

I am having this exact issue. I didn't see this issue when creating my own so i will close mine because this has exact process I went through even when I tried debugging on my own. I need the coverage to map to the source files because of multiple reasons.

Are you supposed to instrument the code before it is transpiled? Because there isn't any clear documentation on that, so maybe that is my issue

this appears to still be an issue - i updated dependencies and spelled out repro steps in the repo linked above - hopefully its something obvious 😆


Better window management keybindings for tmux

If there is not currently a marked window, then ` \ should prompt you for a window to swap with, instead of being a no-op.
Preferably, ` I would default to inserting a window before the marked window, if there is one.
We also need a keybinding to insert the current window (rather than a new window) at a given position (default to marked, prompt otherwise).
I've asked a question on Unix & Linux Stack Exchange.

Closing as stale: I haven't been bothered by the lack of this feature in many years, and nobody else has complained about it.


biggan-deep race condition / variable stripping issue

i suspect the biggan-deep models have the same race condition issue with the previous truncation value, as the biggan vanilla v1 models, later fixed in v2. this also prevents stripping the graph for inference. can we have a biggan-deep v2 fixing this?

@eyaler ,
Sorry for the delayed response. Can you please provide the reproducible code so that we can check it at our end.

this is indirect evidence, but using intel's export_tf from https://github.com/intel-analytics/analytics-zoo/blob/master/pyzoo/zoo/util/tf.py , you can see that deep_512/v1 fails in a similar fashion to 512/v1 addressing the variables related to the race condition, while in 512/v2 it's ok. so i suspect deep-512/v1 requires the same fix that was done from 512/v1 to 512/v2
`
import tensorflow as tf
import tensorflow_hub as hub
import os
from tf import export_tf #https://github.com/intel-analytics/analytics-zoo/blob/master/pyzoo/zoo/util/tf.py
with tf.Session() as sess:
module = hub.Module('https://tfhub.dev/deepmind/biggan-deep-512/1') #fails
#module = hub.Module('https://tfhub.dev/deepmind/biggan-512/1') #fails
#module = hub.Module('https://tfhub.dev/deepmind/biggan-512/2') #works
sess.run(tf.global_variables_initializer())
inputs = {k: tf.placeholder(v.dtype, v.get_shape().as_list(), k) for k, v in module.get_input_info_dict().items()}
output = module(inputs)
export_tf(sess, "c:/temp/saved5", inputs=[inputs["y"], inputs["z"], inputs["truncation"]], outputs=[output])#, variable_names_blacklist='module/prev_truncation:0')
tf.reset_default_graph()
with tf.Session() as sess:
with tf.gfile.GFile(os.path.join('c:/temp/saved5', 'frozen_inference_graph.pb'), 'rb') as f:
gd = sess.graph_def
gd.ParseFromString(f.read())
tf.import_graph_def(gd, name='')
`

@eyaler ,
Thank you for the code. Can you please elaborate the Issue which you are facing, and also the log of error, which you are facing. That will help us understand the issue exactly. Thanks.

see here: https://github.com/intel-analytics/analytics-zoo/issues/1271#issuecomment-485199439
Traceback (most recent call last):
File "C:\Anaconda3\lib\site-packages\tensorflow\python\framework\importer.py", line 418, in import_graph_def
graph._c_graph, serialized, options) # pylint: disable=protected-access
tensorflow.python.framework.errors_impl.InvalidArgumentError: Input 0 of node module_apply_default/cond/AssignVariableOp/Switch was passed float from module/prev_truncation:0 incompatible with expected resource.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "C:/python/biggan/issue2.py", line 18, in
tf.import_graph_def(gd, name='')
File "C:\Anaconda3\lib\site-packages\tensorflow\python\util\deprecation.py", line 488, in new_func
return func(*args, **kwargs)
File "C:\Anaconda3\lib\site-packages\tensorflow\python\framework\importer.py", line 422, in import_graph_def
raise ValueError(str(e))
ValueError: Input 0 of node module_apply_default/cond/AssignVariableOp/Switch was passed float from module/prev_truncation:0 incompatible with expected resource.

Process finished with exit code 1

Is there any easy way to overcome this and optimize the biggan-deep-512 for serving?
Only having what is needed for inference?

Hi @eyaler. I'm not sure what the problem is with exporting the biggan-deep models using the Intel analytics script. The biggan-deep models do not have the particular race condition issue I'm aware of with the original broken  biggan (v1) models.  The biggan-deep models were exported with essentially the same fixed script used to export the biggan (v2), and I've manually checked for the race condition I know of with the biggan-deep models and it's not there.
Do you see the same error message for biggan (v1) modules as you do for biggan-deep (v1)?
It could be an issue with the Intel analytics export script rather than with these modules. In general all of these BigGAN modules do somewhat eccentric stuff (mainly, assigning variables as part of inference to use the correct BN stats depending on the trunc input, which looks like is what's giving you problems now) and I would have expected many "export for inference" type scripts tested against more conventional models (where all of the assign ops can be removed for inference) to break on these. (I'm rather surprised it seems to work on the biggan (v2) modules.) You might have to resort to manual graph editing to make some of these inference scripts work.

@eyaler ,
Can you please respond to @jeffdonahue's comment and can we work towards closure of this issue.

Thanks @jeffdonahue . I am indeed seeing the same error message for biggan (v1) as i do for biggan-deep (v1). I moved to the intel script to overcome the issue I had here: https://github.com/tensorflow/hub/issues/224 with freezing and loading the graph. As it was working with v2, and giving the same error for v1 and deep-v1, I conjectured that the issue might be the race condition solved in v1->v2 and though this condition may be present also in deep-v1.


CI issue relating to gdal

CI currently breaks due to a gdal issue.  See #255 for details.

Resolved with #259 .


[Docs]: Update Audit Logs Structure

Combining Audit Logs docs back into a single page; consider redirect links

Going to make a case for the events list alone here again, if I may. It is bound to grow so does it warrant a separate page?

@danciaclara Do you have an opinion for this case?

Thanks @spark-c, @danciaclara just shared why.

Resolved by merged PR 543


getTransactionByRequestId added

Coverage increased (+0.03%) to 90.766% when pulling<PHONE_NUMBER>2f6b06b03729006b88829ec81667a5 on GPP-443 into f867afe88a4a1fa990f67496ea7dce332569c0e5 on master.


Paired end read option in Mageck not working

Hi, thank you so much for developing this fantastic MAGeCK package, its really helpful in analysing CRISPR-screen data. However, I am facing issues when I try to analyse the data using the paired end read sequencing (--fastq-2) option.
I have detailed the problem below :-
This is the code I use to to run MAGeCK :
source activate mageck-vispr
cd into/the/directory_that_contains_library.csv_and_all_the_.fastq.gz_files
mageck count -l library.txt -n AML_CRISPR_Screen_SJM --sample-label cd11bc1,cd11bc2,cd11bc3,toc1,toc2,toc3 --fastq cd11bc1_IGO_12933_4_S218_L004_R1_001.fastq.gz cd11bc2_IGO_12933_5_S219_L004_R1_001.fastq.gz cd11bc3_IGO_12933_6_S220_L004_R1_001.fastq.gz toc1_IGO_12933_1_S215_L004_R1_001.fastq.gz toc2_IGO_12933_2_S216_L004_R1_001.fastq.gz toc3_IGO_12933_3_S217_L004_R1_001.fastq.gz --fastq-2 cd11bc1_IGO_12933_4_S218_L004_R2_001.fastq.gz cd11bc2_IGO_12933_5_S219_L004_R2_001.fastq.gz cd11bc3_IGO_12933_6_S220_L004_R2_001.fastq.gz toc1_IGO_12933_1_S215_L004_R2_001.fastq.gz toc2_IGO_12933_2_S216_L004_R2_001.fastq.gz toc3_IGO_12933_3_S217_L004_R2_001.fastq.gz
This is the output I get (error message is towards the end).
INFO  @ Mon, 12 Sep 2022 13:26:51: Parameters: /Users/soumyasharma/opt/anaconda3/envs/mageckenv/bin/mageck count -l library.txt -n AML_CRISPR_Screen_SJM --sample-label cd11bc1,cd11bc2,cd11bc3,toc1,toc2,toc3 --fastq cd11bc1_IGO_12933_4_S218_L004_R1_001.fastq.gz cd11bc2_IGO_12933_5_S219_L004_R1_001.fastq.gz cd11bc3_IGO_12933_6_S220_L004_R1_001.fastq.gz toc1_IGO_12933_1_S215_L004_R1_001.fastq.gz toc2_IGO_12933_2_S216_L004_R1_001.fastq.gz toc3_IGO_12933_3_S217_L004_R1_001.fastq.gz --fastq-2 cd11bc1_IGO_12933_4_S218_L004_R2_001.fastq.gz cd11bc2_IGO_12933_5_S219_L004_R2_001.fastq.gz cd11bc3_IGO_12933_6_S220_L004_R2_001.fastq.gz toc1_IGO_12933_1_S215_L004_R2_001.fastq.gz toc2_IGO_12933_2_S216_L004_R2_001.fastq.gz toc3_IGO_12933_3_S217_L004_R2_001.fastq.gz
INFO  @ Mon, 12 Sep 2022 13:26:51: Welcome to MAGeCK v<IP_ADDRESS>. Command: count
INFO  @ Mon, 12 Sep 2022 13:26:51: Header line of the library file detected; skip the first line ...
INFO  @ Mon, 12 Sep 2022 13:26:51: Loading 13474 predefined sgRNAs.
WARNING @ Mon, 12 Sep 2022 13:26:51: There are 0 sgRNAs with duplicated sequences.
INFO  @ Mon, 12 Sep 2022 13:26:51: Parsing FASTQ file cd11bc1_IGO_12933_4_S218_L004_R1_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:26:51: Determining the trim-5 length of FASTQ file cd11bc1_IGO_12933_4_S218_L004_R1_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:26:51: Possible gRNA lengths:20
INFO  @ Mon, 12 Sep 2022 13:26:51: Processing 0M reads ...
INFO  @ Mon, 12 Sep 2022 13:26:53: Read length:101
INFO  @ Mon, 12 Sep 2022 13:26:53: Total tested reads: 100001, mapped: 23399(0.23398766012339878)
WARNING @ Mon, 12 Sep 2022 13:26:53: Only 23.398766012339877 % of the reads can be identified.
INFO  @ Mon, 12 Sep 2022 13:26:53: --trim-5 test data: (trim_length reads fraction)
INFO  @ Mon, 12 Sep 2022 13:26:53: 21	21217	0.9067481516304116
INFO  @ Mon, 12 Sep 2022 13:26:53: 20	647	0.027650754305739562
INFO  @ Mon, 12 Sep 2022 13:26:53: 19	202	0.008632847557587931
INFO  @ Mon, 12 Sep 2022 13:26:53: 18	201	0.008590110688490962
INFO  @ Mon, 12 Sep 2022 13:26:53: 17	199	0.008504636950297021
INFO  @ Mon, 12 Sep 2022 13:26:53: 16	138	0.005897687935381854
INFO  @ Mon, 12 Sep 2022 13:26:53: 14	136	0.005812214197187914
INFO  @ Mon, 12 Sep 2022 13:26:53: 13	113	0.004829266207957605
INFO  @ Mon, 12 Sep 2022 13:26:53: 12	112	0.004786529338860635
INFO  @ Mon, 12 Sep 2022 13:26:53: 15	105	0.004487371255181846
INFO  @ Mon, 12 Sep 2022 13:26:53: 22	73	0.003119791444078807
INFO  @ Mon, 12 Sep 2022 13:26:53: 11	63	0.002692422753109107
INFO  @ Mon, 12 Sep 2022 13:26:53: 8	46	0.001965895978460618
INFO  @ Mon, 12 Sep 2022 13:26:53: 7	34	0.0014530535492969785
INFO  @ Mon, 12 Sep 2022 13:26:53: 10	34	0.0014530535492969785
INFO  @ Mon, 12 Sep 2022 13:26:53: 9	19	0.0008120005128424291
INFO  @ Mon, 12 Sep 2022 13:26:53: 1	13	0.0005555792982606094
INFO  @ Mon, 12 Sep 2022 13:26:53: 6	9	0.0003846318218727296
INFO  @ Mon, 12 Sep 2022 13:26:53: 3	8	0.00034189495277575963
INFO  @ Mon, 12 Sep 2022 13:26:53: 4	7	0.0002991580836787897
INFO  @ Mon, 12 Sep 2022 13:26:53: 0	7	0.0002991580836787897
INFO  @ Mon, 12 Sep 2022 13:26:53: 2	7	0.0002991580836787897
INFO  @ Mon, 12 Sep 2022 13:26:53: 5	3	0.00012821060729090986
INFO  @ Mon, 12 Sep 2022 13:26:53: 25	2	8.547373819393991e-05
INFO  @ Mon, 12 Sep 2022 13:26:53: 24	1	4.2736869096969954e-05
INFO  @ Mon, 12 Sep 2022 13:26:53: 23	1	4.2736869096969954e-05
INFO  @ Mon, 12 Sep 2022 13:26:53: 34	1	4.2736869096969954e-05
INFO  @ Mon, 12 Sep 2022 13:26:53: 45	1	4.2736869096969954e-05
INFO  @ Mon, 12 Sep 2022 13:26:53: Auto determination of trim5 results: 21
INFO  @ Mon, 12 Sep 2022 13:26:53: Determining the trim-5 length of FASTQ file cd11bc1_IGO_12933_4_S218_L004_R2_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:26:53: Possible gRNA lengths:20
INFO  @ Mon, 12 Sep 2022 13:26:53: Processing 0M reads ...
INFO  @ Mon, 12 Sep 2022 13:26:59: Read length:101
INFO  @ Mon, 12 Sep 2022 13:26:59: Total tested reads: 100001, mapped: 283(0.002829971700282997)
WARNING @ Mon, 12 Sep 2022 13:26:59: Only 0.2829971700282997 % of the reads can be identified.
INFO  @ Mon, 12 Sep 2022 13:26:59: --trim-5 test data: (trim_length reads fraction)
INFO  @ Mon, 12 Sep 2022 13:26:59: 20	36	0.127208480565371
INFO  @ Mon, 12 Sep 2022 13:26:59: 21	23	0.0812720848056537
INFO  @ Mon, 12 Sep 2022 13:26:59: 41	11	0.038869257950530034
INFO  @ Mon, 12 Sep 2022 13:26:59: 63	10	0.0353356890459364
INFO  @ Mon, 12 Sep 2022 13:26:59: 19	10	0.0353356890459364
INFO  @ Mon, 12 Sep 2022 13:26:59: 70	9	0.03180212014134275
INFO  @ Mon, 12 Sep 2022 13:26:59: 65	7	0.024734982332155476
INFO  @ Mon, 12 Sep 2022 13:26:59: 38	6	0.02120141342756184
INFO  @ Mon, 12 Sep 2022 13:26:59: 46	6	0.02120141342756184
INFO  @ Mon, 12 Sep 2022 13:26:59: 42	6	0.02120141342756184
INFO  @ Mon, 12 Sep 2022 13:26:59: 48	6	0.02120141342756184
INFO  @ Mon, 12 Sep 2022 13:26:59: 62	6	0.02120141342756184
INFO  @ Mon, 12 Sep 2022 13:26:59: 40	6	0.02120141342756184
INFO  @ Mon, 12 Sep 2022 13:26:59: 25	5	0.0176678445229682
INFO  @ Mon, 12 Sep 2022 13:26:59: 23	5	0.0176678445229682
INFO  @ Mon, 12 Sep 2022 13:26:59: 61	5	0.0176678445229682
INFO  @ Mon, 12 Sep 2022 13:26:59: 26	5	0.0176678445229682
INFO  @ Mon, 12 Sep 2022 13:26:59: 64	5	0.0176678445229682
INFO  @ Mon, 12 Sep 2022 13:26:59: 59	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 5	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 67	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 18	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 39	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 69	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 66	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 36	4	0.014134275618374558
INFO  @ Mon, 12 Sep 2022 13:26:59: 81	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 44	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 2	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 3	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 15	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 79	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 73	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 60	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 56	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 72	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 1	3	0.01060070671378092
INFO  @ Mon, 12 Sep 2022 13:26:59: 31	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 35	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 53	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 57	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 52	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 55	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 16	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 0	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 75	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 10	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 30	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 37	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 34	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 4	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 71	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 29	2	0.007067137809187279
INFO  @ Mon, 12 Sep 2022 13:26:59: 78	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 13	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 76	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 54	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 27	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 7	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 51	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 11	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 77	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 12	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 24	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 28	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 68	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 49	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 47	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 17	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 6	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 9	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: 45	1	0.0035335689045936395
INFO  @ Mon, 12 Sep 2022 13:26:59: Auto determination of trim5 results: 20,21,41
INFO  @ Mon, 12 Sep 2022 13:26:59: Possible gRNA lengths:20
INFO  @ Mon, 12 Sep 2022 13:26:59: Processing 0M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:05: Processing 1M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:11: Processing 2M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:17: Processing 3M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:23: Processing 4M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:29: Processing 5M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:35: Processing 6M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:41: Processing 7M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:47: Processing 8M reads ..
INFO  @ Mon, 12 Sep 2022 13:27:53: Processing 9M reads ..
INFO  @ Mon, 12 Sep 2022 13:26:53: Determining the trim-5 length of FASTQ file cd11bc1_IGO_12933_4_S218_L004_R2_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:26:53: Possible gRNA lengths:20
INFO  @ Mon, 12 Sep 2022 13:26:53: Processing 0M reads ...
INFO  @ Mon, 12 Sep 2022 13:26:59: Read length:101
INFO  @ Mon, 12 Sep 2022 13:26:59: Total tested reads: 100001, mapped: 283(0.002829971700282997)
WARNING @ Mon, 12 Sep 2022 13:26:59: Only 0.2829971700282997 % of the reads can be identified.
INFO  @ Mon, 12 Sep 2022 13:26:59: --trim-5 test data: (trim_length reads fraction)
INFO  @ Mon, 12 Sep 2022 13:26:59: 20	36	0.127208480565371
INFO  @ Mon, 12 Sep 2022 13:27:59: Processing 10M reads ..
INFO  @ Mon, 12 Sep 2022 13:28:05: Processing 11M reads ..
INFO  @ Mon, 12 Sep 2022 13:28:11: Processing 12M reads ..
INFO  @ Mon, 12 Sep 2022 13:28:18: Processing 13M reads ..
INFO  @ Mon, 12 Sep 2022 13:28:24: Processing 14M reads ..
INFO  @ Mon, 12 Sep 2022 13:28:30: Processing 15M reads ..
INFO  @ Mon, 12 Sep 2022 13:28:33: Total: 15477650.
INFO  @ Mon, 12 Sep 2022 13:28:33: Mapped: 3341122.
INFO  @ Mon, 12 Sep 2022 13:28:33: Parsing FASTQ file cd11bc2_IGO_12933_5_S219_L004_R1_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:28:33: Determining the trim-5 length of FASTQ file cd11bc2_IGO_12933_5_S219_L004_R1_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:28:33: Possible gRNA lengths:20
INFO  @ Mon, 12 Sep 2022 13:28:33: Processing 0M reads ...
INFO  @ Mon, 12 Sep 2022 13:28:36: Read length:101
INFO  @ Mon, 12 Sep 2022 13:28:36: Total tested reads: 100001, mapped: 22696(0.22695773042269576)
WARNING @ Mon, 12 Sep 2022 13:28:36: Only 22.695773042269575 % of the reads can be identified.
INFO  @ Mon, 12 Sep 2022 13:28:36: --trim-5 test data: (trim_length reads fraction)
INFO  @ Mon, 12 Sep 2022 13:28:36: 21	21050	0.9274762072611914
INFO  @ Mon, 12 Sep 2022 13:28:36: 20	717	0.03159146986253084
INFO  @ Mon, 12 Sep 2022 13:28:36: 19	147	0.006476912231230173
INFO  @ Mon, 12 Sep 2022 13:28:36: 18	145	0.006388790976383504
INFO  @ Mon, 12 Sep 2022 13:28:36: 17	116	0.005111032781106803
INFO  @ Mon, 12 Sep 2022 13:28:36: 14	105	0.004626365879450123
INFO  @ Mon, 12 Sep 2022 13:28:36: 16	100	0.0044060627423334504
INFO  @ Mon, 12 Sep 2022 13:28:36: 22	92	0.0040535777229467745
INFO  @ Mon, 12 Sep 2022 13:28:36: 12	61	0.002687698272823405
INFO  @ Mon, 12 Sep 2022 13:28:36: 15	57	0.002511455763130067
INFO  @ Mon, 12 Sep 2022 13:28:36: 13	56	0.0024673951357067326
INFO  @ Mon, 12 Sep 2022 13:28:36: 11	12	0.0005287275290800141
INFO  @ Mon, 12 Sep 2022 13:28:36: 8	6	0.00026436376454000703
INFO  @ Mon, 12 Sep 2022 13:28:36: 10	5	0.00022030313711667254
INFO  @ Mon, 12 Sep 2022 13:28:36: 6	3	0.00013218188227000352
INFO  @ Mon, 12 Sep 2022 13:28:36: 0	3	0.00013218188227000352
INFO  @ Mon, 12 Sep 2022 13:28:36: 24	2	8.812125484666901e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 1	2	8.812125484666901e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 9	2	8.812125484666901e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 7	2	8.812125484666901e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 3	2	8.812125484666901e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 5	2	8.812125484666901e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 23	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 31	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 68	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 30	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 53	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 2	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 26	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 45	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: 47	1	4.406062742333451e-05
INFO  @ Mon, 12 Sep 2022 13:28:36: Auto determination of trim5 results: 21
INFO  @ Mon, 12 Sep 2022 13:28:36: Determining the trim-5 length of FASTQ file cd11bc2_IGO_12933_5_S219_L004_R2_001.fastq.gz...
INFO  @ Mon, 12 Sep 2022 13:28:36: Possible gRNA lengths:20
INFO  @ Mon, 12 Sep 2022 13:28:36: Processing 0M reads ...
INFO  @ Mon, 12 Sep 2022 13:28:42: Read length:101
INFO  @ Mon, 12 Sep 2022 13:28:42: Total tested reads: 100001, mapped: 79(0.0007899921000789992)
ERROR @ Mon, 12 Sep 2022 13:28:42: Cannot automatically determine the --trim-5 length. Only 0.07899921000789992 % of the reads can be identified.
(mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:53: Determining the trim-5 length of FASTQ file cd11bc1_IGO_12933_4_S218_L004_R2_001.fastq.gz...
info: No menu item '@' in node '(dir)Top'
(mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:53: Possible gRNA lengths:20
info: No menu item '@' in node '(dir)Top'
(mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:53: Processing 0M reads ...
info: No menu item '@' in node '(dir)Top'
(mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:59: Read length:101
info: No menu item '@' in node '(dir)Top'
(mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:59: Total tested reads: 100001, mapped: 283(0.002829971700282997)
-bash: syntax error near unexpected token (' (mageckenv) MAC303388:fastq soumyasharma$ WARNING @ Mon, 12 Sep 2022 13:26:59: Only 0.2829971700282997 % of the reads can be identified.   -bash: WARNING: command not found (mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:59: --trim-5 test data: (trim_length reads fraction)  -bash: syntax error near unexpected token ('
(mageckenv) MAC303388:fastq soumyasharma$ INFO  @ Mon, 12 Sep 2022 13:26:59: 20360.127208480565371
info: No menu item '@' in node '(dir)Top'
Also, when I run using just the R1 fastq.gz files (only using the fastq option and not --fastq-2) using the code below
mageck count -l library.txt -n AML_CRISPR_Screen_SJM --sample-label cd11bc1,cd11bc2,cd11bc3,toc1,toc2,toc3 --fastq cd11bc1_IGO_12933_4_S218_L004_R1_001.fastq.gz cd11bc2_IGO_12933_5_S219_L004_R1_001.fastq.gz cd11bc3_IGO_12933_6_S220_L004_R1_001.fastq.gz toc1_IGO_12933_1_S215_L004_R1_001.fastq.gz toc2_IGO_12933_2_S216_L004_R1_001.fastq.gz toc3_IGO_12933_3_S217_L004_R1_001.fastq.gz
MAGeCK runs without any errors and gives me the expected results.
Can you please help me figure out what's going on when I try to run MAGeCK on the paired-end sequencing reads and why I am getting that error?
Would really appreciate the help!

Hi,I'm new to MAGeCk too.Have you solved your problem now? cause I have the same problem with you now. Thank you so much for any reply!


Add support for dr.dk

[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', 'http://www.dr.dk/bonanza/serie/portraetter/Talkshowet.htm?assetId=65517']
[debug] Encodings: locale UTF-8, fs UTF-8, out None, pref UTF-8
[debug] youtube-dl version 2014.12.01
[debug] Python version 2.7.9 - Linux-3.16.0-4-amd64-x86_64-with-debian-8.0
[debug] exe versions: avconv 11-6, avprobe 11-6, rtmpdump 2.4
[debug] Proxy map: {}
[generic] Talkshowet: Requesting header
WARNING: Falling back on generic information extractor.
[generic] Talkshowet: Downloading webpage
[generic] Talkshowet: Extracting information
ERROR: Unsupported URL: http://www.dr.dk/bonanza/serie/portraetter/Talkshowet.htm?assetId=65517; please report this issue on https://yt-dl.org/bug . Make sure you are
using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/youtube_dl/extractor/generic.py", line 651, in _real_extract
doc = parse_xml(webpage)
File "/usr/lib/python2.7/dist-packages/youtube_dl/utils.py", line 1411, in parse_xml
tree = xml.etree.ElementTree.XML(s.encode('utf-8'), **kwargs)
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1300, in XML
parser.feed(text)
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1642, in feed
self._raiseerror(v)
File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
raise err
ParseError: mismatched tag: line 73, column 3
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py", line 553, in extract_info
ie_result = ie.extract(url)
File "/usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py", line 241, in extract
return self._real_extract(url)
File "/usr/lib/python2.7/dist-packages/youtube_dl/extractor/generic.py", line 1044, in _real_extract
raise ExtractorError('Unsupported URL: %s' % url)
ExtractorError: Unsupported URL: http://www.dr.dk/bonanza/serie/portraetter/Talkshowet.htm?assetId=65517; please report this issue on https://yt-dl.org/bug . Make sur
e you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete outpu
t.

@flehen: Yours didn't work because of https. It has been fixed in #4684.
The original url by @mortenivar can now be downloaded as per the #4687.
It's worth noting, that when downloading DR Bonanza-links you should preferable include the assetId-query-parameter. Otherwise it will just download the first video on the page.
If you navigate onto a video and the query-parameter doesn't get updated (because it's an old JavaScript/Flash website) the easiest way to get the updated URL is to find the "Email a friend"-link and copy it from there.


Chunked Request: different header values on Sign vs Upload

Hi, I'm getting a SignatureDoesNotMatch error on chunked uploads only.  It seems that the header values are different on the signature request vs the POST request.  The sign request looks like this:
POST
/556e749ae2b6350d6d47c68fdf2624a8/assets/ab45a649-3541-4651-a74e-fbfe05f897be
uploads=
host:s3-us-west-2.amazonaws.com
x-amz-acl:private
x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
x-amz-date:20171216T010045Z
x-amz-meta-qqfilename:Postman-osx-5.3.2.zip

host;x-amz-acl;x-amz-content-sha256;x-amz-date;x-amz-meta-qqfilename
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

and the POST request looks like this:
POST
/sandbox-assets.bam.zone/556e749ae2b6350d6d47c68fdf2624a8/assets/ab45a649-3541-4651-a74e-fbfe05f897be
uploads=
host:s3-us-west-2.amazonaws.com
x-amz-acl:private
x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
x-amz-date:20171216T010045Z
x-amz-meta-qqfilename:Postman-osx-5.3.2.zip

host;x-amz-acl;x-amz-content-sha256;x-amz-date;x-amz-meta-qqfilename
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

S3-fineuploader is adding the bucket name to the object key on the POST request.   Here is my options object:
options: {
                objectProperties: {
                    region: "us-west-2",
                    key: fileId => {
                        return `${this.props.user.client}/assets/${this.uploaderInstance.qq.getUniqueId(fileId)}`
                    },
                    host: `s3-us-west-2.amazonaws.com`,
                    bucket: config.bucket,
                },
                chunking: {
                    enabled: true
                },
                resume: {
                    enabled: true
                },
                request: {
                    endpoint: `${config.assetUrl}`,
                    accessKey: credentials.aws.accessKeyId,
                },
                signature: {
                    endpoint: `${config.baseUrl}/api/assets/signedPolicy`,
                    version: 4,
                    region: 'us-west-2',
                    customHeaders: {
                        Authorization: this.props.user.token
                    }
                },
                callbacks: {
                    onComplete: this.uploadCompleteHandler,
                    onAllComplete: this.allUploadsCompleteHandler,
                    onValidateBatch: this.validateBatchHandler,
                    onError: err => {
                        this.props.modalActions.setMessage({
                            type: 'ERROR',
                            msg: err.message || 'Unable to upload file'
                        })
                        this.props.modalActions.openModal('MessageModal')
                    }
                },

I have searched the other issues and only found one similar problem - it appears the user changed the source code to resolve it.  Is this user error or something in the code?  Thanks!

React Fine Uploader is nothing more than UI code, so this isn't the appropriate place to file such an issue. If you can find a specific issue in Fine Uploader's code, please file an issue in the fine-uploader repo, but it sounds like this is an issue with your server signing code.


Cannot verify SmartContract on BSCscan.. help please to flatten code?

Closing to clean up the repository. If this problem persists, please open a new issue with a clear explanation.


TS3.7 regression: renamed exports in namespaces do not resolve in nested namespaces

TypeScript Version:  3.7.0-beta
Search Terms: namespace renamed export
Code
export declare const x: number;
declare global {
  namespace clutz {
    export {x as some$mangled$name$x};
  }
  namespace clutz.some$mangled$name {
    export {some$mangled$name$x as x};
  }
}

(Using the mangled alias name some$mangled$name$x instead of x makes sure that no other symbol in the namespace accidentally shadows the outer x.)
Expected behavior:
In TypeScript 3.6, some$mangled$name$x within the nested namespace clutz.some$mangled$name resolves to export {x as clutz.some$mangled$name$x} in the parent namespace, and thus eventually to x.
Actual behavior:
In TypeScript 3.7, some$mangled$name$x does not resolve in the nested namespace.
Playground Link: (no 3.7 playground around)
Related Issues:

Looked into this but not entirely sure of the right answer.
It looks like namespaces were brought to act a bit more like how es modules work in the allowJs + declarations PR here making it so that code like this:
declare namespace clutz {
    var x: string

    export {x as some$mangled$name$x};
    var y: typeof some$mangled$name$x;
  }

3.6 works | 3.7 fails
Which is also the same as how the lookups across the cascading namespaces. The underlaying question is should the names of named export declarations be visible across namespaces in a way that's different from es modules? e.g. should this be allowed in a namespace but not an esmodule:
const x = 3;
export { x as foo };
export { foo as bar };

/cc @weswigham @RyanCavanaugh

Mmmm, so the key here is that declare module "..." and actual module files need to behave the same way (so declarations for outFile work as expected). Ambient namespaces getting caught up in the change is probably unintentional. If the original change is restricted to just external module declarations, I think it's OK? The tests should show if it's not. The JS declaration emitter runs up against, like, all the quirks of name resolution, so hopefully the examples and tests should show what's needed.

@weswigham I’m not sure if I interpreted your suggestion correctly, but we tried this:
- if (location.kind === SyntaxKind.SourceFile || (isModuleDeclaration(location) && location.flags & NodeFlags.Ambient && !isGlobalScopeAugmentation(location))) {
+ if (location.kind === SyntaxKind.SourceFile || (isNonGlobalAmbientModule(location) && location.flags & NodeFlags.Ambient)) {

And a bunch of JS declaration emit tests fail, like this one:
// @allowJs: true
// @checkJs: true
// @target: es5
// @outDir: ./out
// @declaration: true
// @filename: bar.js
class Bar {}
module.exports = Bar;
// @filename: cls.js
const Bar = require("./bar");
const Strings = {
    a: "A",
    b: "B"
};
class Foo extends Bar {}
module.exports = Foo;
module.exports.Strings = Strings;

which produces the declarations
export = Foo;
declare const Foo_base: typeof import("./bar");
declare class Foo extends Foo_base {
}
declare namespace Foo {
    export { Strings };
}
declare namespace Strings {
    export const a: string;
    export const b: string;
}

and our change produces the error TS2303: Circular definition of import alias 'Strings'.. It seems like ambient namespaces do need to behave the same way as ES modules here.

Yeah, ok, that was definitely the motivator for the change.

To me, it definitely feels like the new behavior is good/expected behavior. I never expect export { x as y } to introduce a locally visible name y. It feels weird to treat that differently in ambient namespaces and real modules.

To clarify from our perspective, I think this is easy to fix for us, but I
wanted to call out the regression and see if it was intentional. So wontfix
is ok :-)


Add tab "Pool" to app

I added a "Pool" section to ml_app that includes updated info about items in the questionnaire (including IPA transcriptions).


Enhancement: Add SINGLEFILE_ARGS to pass custom CLI args to singlefile

I see there're WGET_ARGS and CURL_ARGS in config.py passed to corresponding binaries. But I don't find a way to customize the options passed to singlefile binary. Is there any way to do so?

Ah sorry looks like we still need to add SINGLEFILE_ARGS and make sure it plays nicely with CHROME_ARGS. This will be a TODO for the next release. Contributors welcome.

@renaisun Looks commit good to me. You should make a pull request asap, it might just get accepted with a button press on @pirate's end.

Closing as done! https://github.com/ArchiveBox/ArchiveBox/pull/1021 thanks @notevenaperson


TopBar Rework

Selectors should be on the right

So, does this means these three selectors's position all need to be fixed on right side of the top bar?

should be done once the PR is merged


Doesn't repro in blocks.

Fixed with new sprite editor


Extension needs Symfony service?

Excuse me, how to make this work? I installed by composer and enabled the extension. But I get
Service 'arachne.parameterValidation.handler' (type of Arachne\ParameterValidation\Rules\ValidateRuleHandler): Service of type Symfony\Component\Validator\Validator\ValidatorInterface needed by Arachne\ParameterValidation\Rules\ValidateRuleHandler::__construct() not found.
exception.
Do I need to configure Symfony Validator explicitly?

Yeah. To be more precise you need these extensions:
https://github.com/Arachne/ParameterValidation/blob/master/tests/integration/config/config.neon#L7-L12

Thank you, it helped! Maybe it could be described somewhere in the documentation. I am a bit confused what depends on what and where to put the info. So I will shy away from creating more pull requests in that matter.


Problem in changing the maxHeight of suggest's style

Short description
I was trying to change the maxHeight of suggestion list
  <Geosuggest style={{ 'input': {},'suggests': {'maxHeight':'4em'},'suggestItem': {} }}
                         queryDelay='0'
                         placeholder='Event location'
                         initialValue=''
                         onSuggestSelect={this.suggestLocation}
                         onChange={this.storeLocation}/>

Expected results
I expected that it would decrease the height of the suggestion list
Actual results
It decreased the height of the suggested list. But it doesn't retract back or hide after after selecting a suggested place.

Reproduction steps

Add style for "suggests"

'suggests': {'maxHeight':'4em'}

Type location name and select a suggested place.

BUG -> Suggestion list doesn't retracts back and stays in same specified height (4em)

Additional Information
This is how it looks after selecting the suggested place

Problem is element style's css (max-height:4em) overrides .geosuggest__suggests--hidden (max-height:0px)

You should either use CSS or the inline styles. Pick one and stick with that.


Add Host API CRUD

Implements the CRUD Host API calls
Add a brand icon to the project (golang robot with AWX in the body)
Add Host API usage examples

BTW, functions like AssociateGroup, DisAssociateGroup should also have its own testcase.


Cannot Build on MacOSX 10.15.7

$ python3.9 setup.py build
Looking for libOpenEXR...
running build
running build_py
creating build
creating build/lib.macosx-10.9-x86_64-3.9
copying Imath.py -> build/lib.macosx-10.9-x86_64-3.9
running build_ext
building 'OpenEXR' extension
creating build/temp.macosx-10.9-x86_64-3.9
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -g -I/usr/include/OpenEXR -I/usr/local/include/OpenEXR -I/opt/local/include/OpenEXR -I/usr/include/Imath -I/usr/local/include/Imath -I/opt/local/include/Imath -I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c OpenEXR.cpp -o build/temp.macosx-10.9-x86_64-3.9/OpenEXR.o -g -DVERSION="1.3.8" -std=c++11 -Wc++11-extensions -Wc++11-long-long
In file included from OpenEXR.cpp:40:
In file included from /usr/local/include/OpenEXR/ImfBoxAttribute.h:21:
In file included from /usr/local/include/OpenEXR/ImathBox.h:65:
In file included from /usr/local/include/OpenEXR/ImathVec.h:46:
In file included from /usr/local/include/OpenEXR/ImathExc.h:46:
In file included from /usr/local/include/OpenEXR/ImathNamespace.h:78:
/usr/local/include/OpenEXR/IlmBaseConfig.h:32:9: warning: 'IEX_INTERNAL_NAMESPACE' macro redefined [-Wmacro-redefined]
#define IEX_INTERNAL_NAMESPACE Iex_2_5
^
/usr/local/include/OpenEXR/IexConfig.h:19:9: note: previous definition is here
#define IEX_INTERNAL_NAMESPACE Iex_3_1
^
OpenEXR.cpp:118:21: error: virtual function 'tellg' has a different return type ('Imath_2_5::Int64' (aka 'unsigned long')) than the function it
overrides (which has return type 'uint64_t' (aka 'unsigned long long'))
virtual Int64   tellg ();
~~~~~   ^
/usr/local/include/OpenEXR/ImfIO.h:82:22: note: overridden virtual function is here
virtual uint64_t    tellg () = 0;
~~~~~~~~    ^
OpenEXR.cpp:119:21: warning: 'C_IStream::seekg' hides overloaded virtual function [-Woverloaded-virtual]
virtual void    seekg (Int64 pos);
^
/usr/local/include/OpenEXR/ImfIO.h:90:18: note: hidden overloaded virtual function 'Imf_3_1::IStream::seekg' declared here: type mismatch at 1st
parameter ('uint64_t' (aka 'unsigned long long') vs 'Imath_2_5::Int64' (aka 'unsigned long'))
virtual void        seekg (uint64_t pos) = 0;
^
OpenEXR.cpp:183:21: error: virtual function 'tellp' has a different return type ('Imath_2_5::Int64' (aka 'unsigned long')) than the function it
overrides (which has return type 'uint64_t' (aka 'unsigned long long'))
virtual Int64   tellp ();
~~~~~   ^
/usr/local/include/OpenEXR/ImfIO.h:154:22: note: overridden virtual function is here
virtual uint64_t    tellp () = 0;
~~~~~~~~    ^
OpenEXR.cpp:184:21: warning: 'C_OStream::seekp' hides overloaded virtual function [-Woverloaded-virtual]
virtual void    seekp (Int64 pos);
^
/usr/local/include/OpenEXR/ImfIO.h:162:18: note: hidden overloaded virtual function 'Imf_3_1::OStream::seekp' declared here: type mismatch at 1st
parameter ('uint64_t' (aka 'unsigned long long') vs 'Imath_2_5::Int64' (aka 'unsigned long'))
virtual void        seekp (uint64_t pos) = 0;
^
OpenEXR.cpp:746:33: error: allocating an object of abstract class type 'C_IStream'
object->istream = new C_IStream(fo);
^
/usr/local/include/OpenEXR/ImfIO.h:90:18: note: unimplemented pure virtual method 'seekg' in 'C_IStream'
virtual void        seekg (uint64_t pos) = 0;
^
OpenEXR.cpp:995:33: error: allocating an object of abstract class type 'C_OStream'
object->ostream = new C_OStream(fo);
^
/usr/local/include/OpenEXR/ImfIO.h:162:18: note: unimplemented pure virtual method 'seekp' in 'C_OStream'
virtual void        seekp (uint64_t pos) = 0;
^
3 warnings and 4 errors generated.
error: command '/usr/bin/gcc' failed with exit code 1

$ gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Hey!
For family related reasons i cannot handle this now. I'll try to get back ASAP

Hey!
Can you check what happens if you add #include<Imath/ImathConfig.h> at the beginning of OpenEXR.cpp?

Also I have no idea if this will help but try building lmath and openexr yourself if you installed them through brew. Also see https://github.com/jamesbowman/openexrpython/issues/44#issuecomment-1231008327 for more details on what I did to get it to work.


Build in further accessibility checks

research things like lighthouse & others

One off lighthouse reports and A11Y checks look great. If we automate these, I think it should be done outside of the netlify build step so as not to slow down deploys.


Type conversion unnecessary

if(this.mime == "text/xml)
Credits to @shrimpy.
https://github.com/projectkudu/kudu/pull/1635#issuecomment-124707732

Hi @snobu, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

merged in a6c01b2262c23431e47ce9483207dfb788366ec6


Windows 7 desktop shortcuts keep getting added

Hyper seems to constantly replace a shortcut on my desktop every time I open it, deleting the shortcut only works as long as I leave the program closed. Screenshot below shows the most recent attempts to delete this shortcut since I last cleared my recycle bin. As I write this I just noticed a new one get added to my desktop, how do I disable the creation of new desktop shortcuts?

    Hyper 2.0.2
    Electron 1.7.6
    win32 x64 6.1.7601

Hi! thanks for reporting this, I think we should change the code to only add the shortcut when installing and not running hyper 👍

If I could make another suggestion along the same lines, what about including a setting in the user .hyper.js file to control the creation of the desktop shortcut? Obviously this would only apply after the first time it's installed, but if that user file isn't replaced on upgrade, this would at least let people specify whether or not they want a desktop shortcut going forward.
I for one am starting to get really tired of constantly deleting it now. Not everybody likes desktop shortcuts, you know... 🖖

I'm still having this issue on Windows 10. Is there a fix going in for this?


accept null from getContent

In response to issue #186
Return null from getContent to hide tooltip.

Good catch, but typeof null === 'object', so I've sent another PR that can support both undefined and null. https://github.com/wwayne/react-tooltip/pull/202
Anyway, thanks for your suggestion and PR 👍

@wwayne That's correct, and that fact is exactly why this PR works. I'm confused as to your reasoning, this and #202 are accomplishing the same exact thing...

For the same goal but not the exact thing, I dealt with getContent and children separately and worked with a new state which introduced from previous PR to control it so that it can cover more edge cases.
No offend, but for this PR

it can't deal with getContent={() => { return }}
it can't deal with <ReactTooltip>{}</ReactTooltip>
it doesn't work when working with delayHide, for example

(･ω´･ )
 { return null }}>(･ω´･ )
<ReactTooltip id='custom-class' class='extraClass' delayHide={1000} effect='solid'/>

I think we don't need to add typeof getContent !== 'undefined', I suppose if (getContent) is enough here


Dashless detection: crossinject links

It seems that the logic for dashless detection only works one way. It is probably only matter of crosslinking dashful versions to dashless versions instead of just adding the dashless version to matrix.
Example:

https://cleasby-vigfusson-dictionary.vercel.app/word/otta-lauss
https://old-icelandic.vercel.app/word/ottalauss

On second thought, it may need mapping of "dashless to dashful". Then we'd need to check slugs against that to also see if current entry may contain dashfull version, as we can't easily predict where the dash would be.


Sir, Excuse me, how about nnDetection compared with yolo v5 or v7?

I was using nnUnet, it is really great!
Now I want to detect the medical lesions, but the paper and model was 3 years ago, I wonder how about nnDetection compared recent most famous model yolo (v5 or v7)？Do you tested them with yolo？

YOLOv5 and v7 are models from the natural image processing domain and thus primarily design for natural images. nnDetection in contrast is designed for volumetric (3D) detection and thus a direct comparison might be difficult. From my experience, translating architectures/improvements from natural images to medical images is rather difficult and rarely produces improved results.

YOLOv5 and v7 are models from the natural image processing domain and thus primarily design for natural images. nnDetection in contrast is designed for volumetric (3D) detection and thus a direct comparison might be difficult. From my experience, translating architectures/improvements from natural images to medical images is rather difficult and rarely produces improved results.

I get it, thank you


Add Package Differencing to Open PR's and base branch

https://gitlab.com/khumba/nvd could be utilized to provide a diff between the current PR's nix closure and the base branch's closure, providing more visibility into what is changing fundamentally with each PR.

see #13


Ensure logical focus hierarchy for My Courses

Description
MA-2349
Implemented UIAlertController for can't find courses button, and set voice over focus to navigation button when the alertController is closed.
How to test this PR

Turn voice over on.
Double tap on "Can't find one of your courses?" button to open the UIAlertController.
Close to alertController to notice that the focus is properly set to top left navigation button.

Reviewers
If you've been tagged for review, please check your corresponding box once you've given the :+1:.

[ ] Code review: @saeedbashir
[ ] Code review: @BenjiLee

Current coverage is 23.25% (diff: 0.00%)

Merging #802 into master will decrease coverage by 20.65%

@@             master       #802   diff @@
==========================================
  Files           361        676     +315
  Lines         25423      56378   +30955
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          11163      13109    +1946
- Misses        14260      43269   +29009
  Partials          0          0

Powered by Codecov. Last update a4ec26b...821cd30

Please review @saeedbashir @BenjiLee

codecov-io is now including Pods and third party frameworks in code coverage as well, due to which the overall code coverage has decreased. I recommend we ignore the decrease for now.

Ready for another pass @saeedbashir @BenjiLee

👍

👍


Feature: add date_added property

add date_added that corresponds to when the photos was added to Photos
Look at ZGENERICASSET.ZADDEDDATE (Photos 5)
and
RKImportGroup.ImportDate (Photos 4)

PhotoInfo.date_added is implemented but not accessible from command line. Add {date_added} and --added-after --added-before?


Substr takes 3 parameters, 4 given

PHP Warning:  substr() expects at most 3 parameters, 4 given in /xxxxxx/securimage/securimage.php on line 2314

Thank you for spotting that and creating this issue.  I have fixed the issue and update the release on github and phpcaptcha.org.


Add compatibility for RN 0.47-

@mehcode The current version does not support react-native 0.46 and inferior on Android.
To keep that and assure compat for 0.47+ too, you should keep the createJSModules method, only remove the @Override annotation.
See https://github.com/airbnb/react-native-maps/blob/master/lib/android/src/main/java/com/airbnb/android/react/maps/MapsPackage.java#L27

Support for non-current React Native is not really something I'm interested in. I don't mind back-porting something to 4.x if support for <0.47 + something-that-happened in 5.x is something you need.


My game is about following the maze to reach the goal.

How do you play your game?
You have to get to the coin. In some later levels, white boxes that you can't see appear and you can't go through them, so you have to go around them. Use WASD to move.

Code
Check off the items that are true.

[x] The game was made using the Sprig editor.
[x] The game is placed in the in the /games directory.
[x] The code is significantly different from all other games in the Sprig gallery (except for games labeled "demo").
[x] The game runs without errors.
[x] The name of the file/game contains only alphanumeric characters, -s, or _s.
[x] The game name is not the same as the others from gallery

Image (If an image is used)

[ ] The image is in the /games/img directory.
[ ] The name of the image matches the name of your file.

Thanks for your PR!

I'm pretty sure I made those changes BTW.

Sorry for the delay! I'll check

Is there a way to change the name of the file (Maze Runner) to maze-runner without re-uploading it? I think that might be a problem.

no problems with the name, but it would be nice if you changed it, we have 2 games with that name

Is it good for publishing now?


how can i use this ?? i am a beginner

is this working very well ?? i am goint to use it. but can you how about example??

go to learn php. beginner.


Aioclock as an alternative to rocketry?

This library remained unmaintained since a year Pydantic 2 is still missing. Although there are couple alternative that are fairly compared to rocketry by documentation, there's also another one by me.
https://github.com/ManiMozaffar/aioclock
Aioclock is inspired from rocketry, but without dependency to redbird (another library by same maintainer) which I found it very complicated.
I fairly compared rocketry to aioclock, which you can find it here
Would be my honor if rocketry could also consider my library as alternative and update its documentation in future :)

Why not maintain this library

I'm not maintainer of this library
and this library is very complicated.
Aioclock whole source code is 500 line i guess, while also being much faster/lightweight.


Issue/task 1220 UI tests

Changes in this Pull Request:

UI Tests for saving all colors of "Profile" page: primary color, font color, navbar bg, navbar link color, input bg color.
Check successful message and verification of saved values of the colors.

Mandatory checks:

[X] Branch is up to date (latest changes were fetched from the upstream branch before creating this PR)
[X] Changes were tested manually
[ ] Java code changes are unit tested
[X] Webtests are successful

To be checked by the reviewer:

[X] Clean Java code and unit tested changes
[X] UI customizablity is preserved: No hard-coded styling and URL references in JSF views

To be checked by the pull request owner:

[ ] .MASTER/job/BES_MASTER_IT/
[ ] .MASTER/job/OSCM_WS_Tests_INTERNAL/
[ ] .MASTER/job/OSCM_WS_Tests_OIDC/
[ ] .MASTER/job/OSCM_Integration_Tests_INTERNAL/
[ ] .MASTER/job/OSCM_Integration_Tests_OIDC/

Cross repository and core changes:

[ ] Interdependent changes have been communicated to the team (if applicable)
[ ] This pull request includes high risk modifications or core changes (e.g API, datamodel, authentication...). Mandatory reviewers: @goebell or @kowalczyka.

OSCM Build References:

<CI node number>: <tag>, example: ci10:goebell

Screenshot (if applicable):

add a screenshot illustrating your change

This change is

oscm-ui-tests/src/main/java/org/oscm/webtest/WebTester.java, line 310 at r1 (raw file):
Previously, KabacinskiPiotr wrote…
Add an error log with a description of what happened here

Done.


How to decode a QR code from an image with Javascript?

Like this.

Is there any sample code that could be of help? I wanna get the qrcode (an image format) and give user the url or text


PageID format changes

Hi,
Notion changed the format of the Page ID, it's no longer a random long value, but rather a page name and a random value.
The current workflow fails as it can't import it based on the page ID format.
022/02/11 11:03:11 can't export page: '********-c5454f30bbf24e7bbc061535e8666935' is not a valid notion id
Complete job
Any idea how to fix it?
Thanks in advance.

Sorry, I no longer use notion. Will put a banner in the README.


Failed connections to analytics API block CLI indefinitely

I have encountered a problem in the mlstacks CLI, which will be blocked from terminating indefinitely in case the Segment analytics API is unreachable (full disclosure: I run PiHole on my local network, which blackholes DNS requests to the api.segment.io API server - however, the same behavior would occur with "real" network connectivity issues). The hang occurs after the main operations have concluded successfully (in my case, deploying a stack).
Setting MLSTACKS_ANALYTICS_OPT_IN=0 when invoking the mlstacks CLI resolves the issue (as does disabling PiHole, thereby allowing the DNS resolution of the API endpoint). However, since analytics are arguably a secondary function of the CLI, a failure there should not affect the main functionality.
The hang occurs in the segment.analytics.client.Client.join() method (executed upon interpreter exit), which in turn waits for its Consumer thread to terminate (which seems to be the root cause). I'm unsure if there is anything mlstacks can do to prevent that issue (short of substituting the atexit handler registered by the Segment Client). Still, I wanted to raise the issue here nonetheless as it negatively impacts core functionality in certain environments.
Happy to help out in case you need further steps to reproduce!
As an aside: I find the naming of the environment variable controlling analytics a bit misleading: in fact, it is an opt-out rather than an opt-in since the default behavior is to enable analytics unless explicitly disabled.

Thanks for reporting this! I am able to reproduce it and will work on a fix.

@AdrianoKF this has now been fixed thanks to @marwan37 's PR. If you use the 0.8.1 release you'll have this fix in action. Thanks for reporting and thanks again @marwan37 for the fix! Closing this issue now.