igzip is 3x faster in decompressing that zlib-ng (6x than zlib)

igzip is 3x faster in decompressing that zlib-ng (6x than zlib).
https://github.com/intel/isa-l/tree/master/igzip
test.gz ==><PHONE_NUMBER> bytes (compressed)
test ==><PHONE_NUMBER>9 bytes (decompressed)

# Gzip decompression speed.
$ module load gzip
$ timeit gzip -cd test.gz > /dev/null
Time output:
------------
  * Command: gzip -cd test.gz
  * Elapsed wall time: 1:57.76 = 117.76 seconds
  * Elapsed CPU time:
     - User: 115.85
     - Sys: 1.45
  * CPU usage: 99%
  * Context switching:
     - Voluntarily (e.g.: waiting for I/O operation): 9
     - Involuntarily (time slice expired): 14919
  * Maximum resident set size (RSS: memory) (kiB): 736
  * Number of times the process was swapped out of main memory: 0
  * Filesystem:
     - # of inputs: 192
     - # of outputs: 0
  * Exit status: 0

# pigz decompression speed with zlib-ng.
module load zlib-ng
module load pigz

$ timeit pigz -cd  pigz -cd test.gz > /dev/null
Time output:
------------
  * Command: pigz -cd test.gz
  * Elapsed wall time: 1:02.13 = 62.13 seconds
  * Elapsed CPU time:
     - User: 77.85
     - Sys: 7.01
  * CPU usage: 136%
  * Context switching:
     - Voluntarily (e.g.: waiting for I/O operation): 1155349
     - Involuntarily (time slice expired): 539
  * Maximum resident set size (RSS: memory) (kiB): 1008
  * Number of times the process was swapped out of main memory: 0
  * Filesystem:
     - # of inputs: 0
     - # of outputs: 0
  * Exit status: 0

# igzip decompression speed.
# igzip: https://github.com/intel/isa-l

module load ISA-L

$ timeit igzip -cd test.gz > /dev/null
Time output:
------------
  * Command: igzip -cd test.gz
  * Elapsed wall time: 0:20.53 = 20.53 seconds
  * Elapsed CPU time:
     - User: 19.30
     - Sys: 1.17
  * CPU usage: 99%
  * Context switching:
     - Voluntarily (e.g.: waiting for I/O operation): 6
     - Involuntarily (time slice expired): 48
  * Maximum resident set size (RSS: memory) (kiB): 2840
  * Number of times the process was swapped out of main memory: 0
  * Filesystem:
     - # of inputs: 0
     - # of outputs: 0
  * Exit status: 0

zlib-ng doesn't try to be fastest... It does however include a lot of intrinsic functions to speed up things but doesn't contain hand-written assembly.
Some C compilers can't handle inline assembly so separate assembler is required for supporting hand-written assembly.

As @sebpop has noted, a less efficient compression may lead to a file that is faster and easier to decompress. To compare decompression between tools, all tools should contribute to a corpus of compressed files and then each tool is timed while decompressing this common set of files. I used this script to compare igzip on an AMD 3900X. igzip's compression is fast but generates large files (see figure). When decompression is compared in a fair test, it is faster than zlib-ng, somewhat faster than libdeflate (which tends to have higher memory demands). For completeness, I also tested AArch64 binaries on an ARM-based Apple M1, where igzip and zlib-ng performed similarly (~284 mb/s) while libdeflate was faster (341 mb/s). igzip only supports compression levels 0..3, so it is not a drop-in replacement for scripts that expect gzip to support levels 1..9 (specifying a level greater than 3 results in a invalid compression level error). Therefore, for x86-64, igzip compression fills a niche, and the decompression is class leading (~2x zlib-ng).
DecompressMethod	Min	Mean	Max	mb/s
igzip	9040	9157	9233	492.32
libdeflate	9922	9974	10017	448.59
zlibNGclang	17295	17345	17390	257.34

To try this yourself, you just need to install igzip on your computer and append one line of code around line 369:
exes.append({'exe': 'igzip', 'uncompress': ' -q -f -q -k -d ', 'compress': ' -q -f -k -', 'max_level': 3, 'ext': '.gz' })

It's not fair to compare zlib-ng+pigz combination if others are executed directly.... zlib-ng is only fast when it is given large enough buffer in memory and any disk I/O is avoided... Until today there was known issue with pigz and zlib-ng which did result in skewed results and possible data corruption.

igzip is using 1mb buffer sizes.
https://github.com/intel/isa-l/blob/ebb78fc99ef7247bd9c16cecf7faa248563ce4f6/programs/igzip_cli.c#L65
https://github.com/intel/isa-l/blob/ebb78fc99ef7247bd9c16cecf7faa248563ce4f6/programs/igzip_cli.c#L1162
https://github.com/intel/isa-l/blob/ebb78fc99ef7247bd9c16cecf7faa248563ce4f6/programs/igzip_cli.c#L1172

@nmoinvaz you are correct that igzip can use multiple threads (e.g. -T 4) for compression. However, I tested it in the default single-threaded mode against other single-threaded tools.
@mtl1979 I did test on a RAM disk to minimize disk I/O. I notice that minigzip.c defines a 16kb/48kb read/write buffer size. Perhaps we could allow the user to specify this from the command line, which might improve performance and remove this source of variability when comparing to other tools.

For me the most appealing part of igzip is the decompression speed. (compression speed is fast too, but compression ratio suffers of course). Probably I compiled igzip wrong, but specifying -T 4 when compression a file with igzip never resulted in a CPU usage higher than 100%, so seems like it couldn't find the threading library.


Save figure WPF using ScottPlot 3.1.6

I tried to save  the figure using different ways but I always get empty file.

Hi @karimshams , thanks for your feedback.
I tried to reproduce you problem on latest version of ScottPlot, and SaveFig() in WPF application works correct.

Can you reproduce problem on latest version of ScottPlot 4.0.9?
Can you provide code example to reproduce you problem?

I still have the same issue, herein the code example:
C# code:
        List<double> dataX = new List<double>();
        List<double> dataY = new List<double>();
        foreach (var Node in NodesEnvelopes)
        {
            dataX.Add(Node.Value.Key.Item2);
            dataY.Add(Node.Value.Key.Item3);

        }

        wpfPlot1.plt.PlotScatter(dataX.ToArray() , dataY.ToArray());

        wpfPlot1.plt.Title("ScottPlot WPF Quickstart");
        wpfPlot1.Render();
        wpfPlot1.plt.SaveFig(@"C:\Temp\wpftest.png");

XML:

<ScottPlot:WpfPlot Name="wpfPlot1"/>

I have the plot figure with the correct data but the issue when I try to save it.

Thanks for provided code, i get the same empty file.
This happens because at constructor time ScottPlot does not render correct.
Canvas have (0,0) size at constructor time.
After constructor time, canvas rise up to actual size, and ScottPlot rerender correct on OnResize event.
If you still want to run SaveFig from constructor, you can do the trick with awaiting of canvas rising:
...
wpfPlot1.plt.PlotScatter(dataX.ToArray() , dataY.ToArray());
wpfPlot1.plt.Title("ScottPlot WPF Quickstart");
wpfPlot1.Render();
Task.Run(() =>
{
    while (wpfPlot1.plt.GetSettings().gfxData == null)
        Thread.Sleep(100);
     wpfPlot1.plt.SaveFig(@"C:\Temp\wpftest.png");
});

Possible more general solutions of this issue:

Add Init flag indicating that ScottPlot get correct render.
Add event to ScottPlot, that rises on correct render.

@StendProg thank you for solving @karimshams problem!
Perhaps I should make SaveFig() throw an exception is a save is attempted when the size is 0,0 to make this problem easier to identify in the future 🤔


Fix typo

from "files(s)" to "file(s)"

Coverage decreased (-0.8%) to 92.857% when pulling 462c337aa98dd189d87c140888bea7ac4a454749 on NullMember:patch-1 into 5e144e4e257c2527170b0ad0ec8ed30a83319b7c on paylogic:master.

Hi @NullMember, thanks for the suggestion and sorry for the late response. This has been merged and published as part of the py2deb 3.0 release.


chore(update docs): remove bad example from apigateway-iot

Description of changes:
The examples in the aws-apigateway-iot documentation suggest using API-KEY as the authentication mechanism which is against best practices. The construct itself defaults to IAM authentication, so it is fine - just the docs need to be changed.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 07a9b46295459db414e1ecdbf94f86b7318ea5fa
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


docs: Add docs to Acknowledgement.Success

Closes #3434

Thank you @webmaster128! This is a great addition, we definitely should have added this earlier!

Merci


Inconsistency in list_id type

list_id is returned as an int in api.lists.create()

   ipdb> n
   > env/src/mailjet/mailjet/contrib/django_mailjet/forms.py(67)list_create()
        66         l = self.api.lists.create(label=self.list_label, name=self.list_name,
   ---> 67                 method='POST')
        68

   ipdb>
   > env/src/mailjet/mailjet/contrib/django_mailjet/forms.py(69)list_create()
        67                 method='POST')
        68
   ---> 69         return l['list_id']

   ipdb> print l
   {u'status': u'OK', u'list_id': 398253}

But as a unicode string in api.lists.all():

   ---> 34         for l in self.api.lists.all()['lists']:
         35             if l['id'] == list_id:

    ipdb> print l
    {u'name': u'foo', u'spam': u'0', u'created_at': u'1378992123', u'bounce': u'0', u'label': u'bar', u'click': u'0', u'last_activity': None, u'handled': u'1', u'subscribers': u'0', u'unsub': u'0', u'open': u'0', u'id': u'398253', u'sent': u'0', u'blocked': u'0'}

And of course, this results in odd results:
ipdb> print l['id'] == list_id
False
ipdb> print list_id
398246
ipdb> print l['id']
398246

I know it's probably a bug from mailjet.com API, but maybe we could fix this inside the python mailjet package or maybe you could recommend a best practice (convert all to string ?)
Thanks

I expect that mailjet fixed the issue in APIv3 and even if they haven't. This API is now deprecated regardless so I think there is no further use for this issue


MQTT data not received from inverter.

Hi.
Since this morning i only receive data on Growatt/status not on Growatt/data.
I have tried both the 1.2 and 1.3 code.
Maybe it's just my inverter, i dont know.
It have been running fine for 1 month, but stopped this morning.
MQTT explorer also only shows data from Growatt/status.

The "Error: Response timed out" is an error message from the modbus communication. For some reason your ESP is no longer talking to the inverter over modbus. I am not sure what the issue can be. I recommend to check the wiring and the connection first. Maybe one of the wires somewhere got loose.
My second guess that the modbus module has died, but it never happened with me so that I think is less likely.
Nevertheless, please use the same firmware that was working before.

Hi, thank you for getting back to me.
I did not consider wiring because i get the data from Growatt/status fine.
I will check it anyway.

I have checked the wiring, all ok.
I will try and power down/up the inverter tomorrow.
The problem exist on any of the firmware. I only tried the newest one because the old one did not work anymore.

I am not sure what to say. The client address of the inverter is 1, and I don't think it can even be changed (or how). So I really don't know why it is not communicating. Again, all I can think is that the TTL to RS485 module died.

You where right. The RS485 adapter was faulty. I replaced it with another brand, and it is working now. Sorry for the confusing.


[tensorflow-lite] update to v2.6.1

Changes
Ports

fft2d https://www.kurims.kyoto-u.ac.jp/~ooura/fft.html, https://github.com/petewarden/OouraFFT
tensorflow-lite https://github.com/tensorflow/tensorflow/tree/v2.6.1

Build Check

install fft2d in x64-osx, x64-windows, x86-windows
install tensorflow-lite in x64-osx, x64-windows, x86-windows

Related Works

#22
#7

Still some GPU Delegates' symbol are missing.
PS /.../packages/tensorflow-lite_x64-osx/lib> nm ./libtensorflow-lite.dylib | grep TfLiteCoreMlDelegateCreate
PS /.../packages/tensorflow-lite_x64-osx/lib> nm ./libtensorflow-lite.dylib | grep TfLiteXNNPackDelegateOptionsDefault
0000000000018ad0 T _TfLiteXNNPackDelegateOptionsDefault
PS /.../packages/tensorflow-lite_x64-osx/lib> nm ./libtensorflow-lite.dylib | grep TFLGpuDelegateOptionsDefault


Logo rendering incorrectly on ubuntu

This is how the logo appears on ubuntu, for me at least.

@mingard what font do you use in the terminal?

@jimlambie it's a monotype. Found the issue. There's a setting in iterm for treating ambiguous spacing characters as double. It's a default in Window command prompt. I'm looking into it.

I like it, very avant garde

So the issue is with the character code. U2593 has no fixed width, but U2591 does. This means one will render okay on all clients and the other is kind of a guess.
Here are the two:
Current (Dark shade)
▓▓▓▓▓  ▓▓▓▓▓▓▓
              ▓▓▓▓
     ▓▓▓▓▓▓▓    ▓▓▓▓
              ▓▓▓▓
          ▓▓▓▓▓▓▓

Alternative (Mid shade)
░░░░░  ░░░░░░░
              ░░░░
     ░░░░░░░    ░░░░
              ░░░░
          ░░░░░░░

One for @abovebored to decide.

When you test this, could you share a screenshot of how the logo with the new character looks in the console?

If this is still an issue, I suggest we move it to https://github.com/dadi/boot, where the logo is being used and pulled into various products. Closing here.


Add YellowFade example

https://gist.github.com/steida/c4a8d2cfd1f05ee6ae88

For login form after redirect to it.

or not


MAINT: Use builtins directly

Avoid warnings with latest numpy of the form:
E   DeprecationWarning: `np.complex` is a deprecated alias for the builtin `complex`. Use `complex` by itself, which is identical in behavior, to silence this warning. If you specifically wanted the numpy scalar type, use `np.complex_` here.

Thanks, Eric. Maybe the core devs have different opinions, so you should wait for further reply. I am just curious if we could instead do a catch_warnings() here, as the idea is to alias "whatever NumPy uses". Not saying these are likely to be changed again on the NumPy side, but if they do, it would still be bulletproof. Just my two cents...

Thanks for the fix! As for now, I think the proposed change is reasonable. (Although I prefer from builtins import int style.)
After NumPy 1.20 release, CuPy should mimic DeprecationWarning behavior. (I think that will be after CuPy v8 release)
https://github.com/cupy/cupy/wiki/Development-policies#numpyscipy-compatibility

Although I prefer from builtins import int style

Changed to use this and added a comment that the types should be deprecated after NumPy releases 1.20

LGTM!
pfnCI, test this please.

Jenkins CI test (for commit 574887ccbe4a284af4cb2634a53f3610cdc9565e, target branch master) succeeded!


RuntimeError: max(): Expected reduction dim to be specified for input.numel() == 0. Specify the reduction dim with the 'dim' argument.

I get this error while training Faster RCNN on Pascal VOC dataset. Created the conda environment as suggested using the yml file (uses python 3.7) and all other packages are intact.
Could you please let me know how to solve this issue?
Thanks in advance :)

Thanks for flagging! I need more details to help resolve this. Can you please share the full terminal error (from the line that runs the file all the way to the bottom of the error)?

There was a very low batch-size in the config file for Pascal VOC-OS which may have led to the error. Seems to be working now on my machine.

Hi again :)
Thank you very much for the quick assistance on this! I'm able to successfully train now. I shall close this issue :)
Best,
Apoorva

I realized that the training works only with certain specific parameters in mmdetection\configs_base_\models\faster_rcnn_r50_fpn_voc_wAnchor.py (with very low iou values set). Also, it is not fool-proof. The first time, the training completed successfully. I tried to perform the same training again with various combinations of ious, and it fails.
train_cfg=dict(
        rpn=dict(
            assigner=dict(
                type='MaxIoUAssigner',
                pos_iou_thr=0.1,         #here   0.7, 0.3, 0.3
                neg_iou_thr=0.0,
                min_pos_iou=0.0,
                match_low_quality=True,
                ignore_iof_thr=-1),
            sampler=dict(
                type='RandomSampler',
                num=256,
                pos_fraction=0.5,
                neg_pos_ub=-1,
                add_gt_as_proposals=False),
            allowed_border=-1,
            pos_weight=-1,
            debug=False),
        rpn_proposal=dict(
            nms_pre=2000,
            max_per_img=1000,
            nms=dict(type='nms', iou_threshold=0.1), #here 0.7
            min_bbox_size=0),
        rcnn=dict(
            assigner=dict(
                type='MaxIoUAssigner',
                pos_iou_thr=0.3,           #here 0.5, 0.5, 0.5
                neg_iou_thr=0.3,
                min_pos_iou=0.3,
                match_low_quality=False,
                ignore_iof_thr=-1),
            sampler=dict(
                type='RandomSampler',
                num=512,
                pos_fraction=0.25,
                neg_pos_ub=-1,
                add_gt_as_proposals=True),
            pos_weight=-1,
            debug=False)),

It's unclear whether this is an issue introduced by our Anchor loss, or whether it's an instability in the training of Faster R-CNN.
My recommendation would be to try training a standard cross-entropy Faster R-CNN with these new parameters, to see if that's stable. If so, then try re-training with Anchor loss but be prepared to play with the hyper-parameters, specifically the one that weights the Anchor loss. You may need to train for a few epochs with just cross-entropy loss, then add in the Anchor loss once it is stable.
In the paper, we used the Faster R-CNN parameters that can be found in the original config. I hope you can get it working for what you need, but going to close this issue now as it's outside the scope of the paper that this code supports.


Update parser.py

Full explanation is here  :  https://github.com/eleme/thriftpy/issues/269
and here : https://github.com/wbolster/happybase/issues/148

Corresponding code change and pull request have been submitted to HappyBase as well.
https://github.com/wbolster/happybase/pull/149

Thanks.


.map fn

@aryaemami59 another potential helper that occurred to me might be useful. I'm not totally convinced it's worth it, but thought I'd open a draft PR in case you had thoughts. Given .toBeCallableWith doesn't work well for generic functions, it's a catch-all way to say "I am allowed to do this with my object" and make assertions on the result, without actually calling the function or performing side-effects, etc.:
const capitalize = <S extends string>(input: S) =>
  (input.slice(0, 1).toUpperCase() + input.slice(1)) as Capitalize<S>

expectTypeOf(capitalize)
  .map(fn => fn('hello world'))
  .toEqualTypeOf<'Hello world'>()

But the assertion could just as easily (maybe more easily) be written as:
expectTypeOf(() => capitalize('hello world')).returns.toEqualTypeOf<'Hello world'>()

Which also doesn't actually call capitalize at runtime.
Advantages of .map:

it makes it clearer it's an asertion about capitalize rather than an inline callback.
it works fine with expectTypeOf<X>() as well as expectTypeOf(x)
implementation is v simple so the cost is low

It could also sub in for how we do .toBeCallableWith in #83 too:
type Factorize = {
  (input: number): number[]
  (input: bigint): bigint[]
}

expectTypeOf<Factorize>().map(f => f(12)).toEqualTypeOf<number[]>()
expectTypeOf<Factorize>().map(f => f(12n)).toEqualTypeOf<bigint[]>()

Not sure about this one yet, I'd say let's get #83 in first then we can use this one to potentially fill in any left over gaps.


can not find MonoFlex config

Hi. Thanks for supporting new models in v1.0.0rc0. However, the links to the config, pre-trained model and training log are blank. Could you please update these links? Thx.

Monoflex config will be updated in a few days.

@ZCMax Sorry for troubling you, it has been more than a year, but the config and model are still blank. Could you please update it? Thanks a lot.

Please refer to https://github.com/open-mmlab/mmdetection3d/issues/1747, sorry for that again.


Schematic Image in Dark Mode

Issue:

Currently, @jmafoster1's new schematic image that's been merged in the main repo does not work with systems that have dark-mode enabled.
Steps to reproduce: toggle dark mode on your system and go to /main

Solution:

Create two separate images, one for light mode enabled and another for dark mode enabled.
I've pushed the two images into this branch, which yields the correct image when either dark/light mode is enabled.

@jmafoster1 Thoughts on this? Is this a decent solution, or is there anything else you'd like me to change before I open a PR?


Add macOS build environment, enhance CI routine, and document.

Trivial changes so I just merge for it.


UI issue when using Column Pinning.

I found this while using column pinning. A small rectangular section appears on top of the last row, covering half of the data value of the pinned columns. Please refer the screenshot.

This is a dup of #35

yup it's a dupe, i know what's going on here, will be fixed soon


Allow one step tutorials, strip metadata before parsing, tests

Stripping metadata to ensure parsing of legacy tutorials (### Step) is supported

@pelikhan Nope, this should preserve existing behavior


I can't get the best result after training

I tried to train this model from scratch but failed to get the accuracy of 91.92%. I only get the best model with Acc of 89.16% and mAP of 79.81%. I used the configuration and dataset you provided. Look forward to your help.
# CUDA
cuda_devices: '3'   # multi-gpu training is available

# dataset
dataset:
  data_root: 'ModelNet40_MeshNet/'
  augment_data: true
  max_faces: 1024

# result
ckpt_root: 'ckpt_root/'

# MeshNet
MeshNet:
  structural_descriptor:
    num_kernel: 64
    sigma: 0.2
  mesh_convolution:
    aggregation_method: 'Concat'  # Concat/Max/Average

# train
lr: 0.01
momentum: 0.9
weight_decay: 0.0005
batch_size: 64
max_epoch: 500
milestones: [30, 60]
gamma: 0.1

91.92%.

i get always the same accuarcy  0.0418

@XiwuChen Sorry for the late reply. The best result I got was trained from a more complex training strategy, which has not been organized into an automated script. And the result may be slightly different when you train several times. (This could be caused by the problems in the dataset.)

Hello @thss15fyt,
Thank you for your work.
I trained your model and I'm not able to recreate the test accuracy of the pre-trained model. I'm getting a test accuracy of 0.8847 after 150 epochs and a training accuracy of  0.9054.
Can you tell me what was this complex training strategy or share its code?
Also, what problem in the data set are you referring to?
Thank you.


Does Perlite support XAMPP

I use the XAMPP and follow non-docker setup step, but can't find the www.conf file to start
does Perlite support XAMPP setting or someone can share the setup step with XAMPP will be appreciated
thanks !!

Never tried it on windows but if you have XAMPP with PHP running you can easy test it. But maybe some things (probably path related) won't work. The graph for example uses the /tmp directory on linux to store the pre-calculated path, this won't work on windows without adjustments

I think, XAMPP probability workable even not 100% support
but I don't know how to start to setup actually, 'casue XAMPP PHP path not same as original PHP setting

Still not sure on which point you are at the moment, do you get PHP already running (without Perlite)?

Yes, apache, PHP and Web all working
I just don't know how to start setup the Perlite on XAMPP env's PHP, 'cause without setup document can be referenced

No idea how to define php environment variables in xampp but you can just download the latest release and put the perlite folder ind your htdocs (or whatever) web root directory and check if the demo works


Tutorials not working with new keras 2.0

I get this when I run the unmodified version of the tutorial on CPU, with the latest keras.
The error does not show up with keras 1.2
(tensorflow) rva5120@cse-p336mcro05:~/tensorflow/cleverhans/tutorials$ python mnist_tutorial_tf.py
Using TensorFlow backend.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE3 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.1 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX instructions, but these are available on your machine and could speed up CPU computations.
X_train shape: (60000, 28, 28, 1)
60000 train samples
10000 test samples
/home/grads/rva5120/tensorflow/cleverhans/cleverhans/utils.py:143: UserWarning: Update your `Conv2D` call to the Keras 2 API: `Conv2D(64, (8, 8), padding="same", strides=(2, 2))`
  border_mode="same"
/home/grads/rva5120/tensorflow/cleverhans/cleverhans/utils.py:147: UserWarning: Update your `Conv2D` call to the Keras 2 API: `Conv2D(128, (6, 6), padding="valid", strides=(2, 2))`
  border_mode="valid"),
/home/grads/rva5120/tensorflow/cleverhans/cleverhans/utils.py:149: UserWarning: Update your `Conv2D` call to the Keras 2 API: `Conv2D(128, (5, 5), strides=(1, 1))`
  Convolution2D(nb_filters * 2, 5, 5, subsample=(1, 1)),
Defined TensorFlow model graph.
Epoch 0
	Epoch took 52.5618000031 seconds
Traceback (most recent call last):
  File "mnist_tutorial_tf.py", line 122, in <module>
    app.run()
  File "/home/grads/rva5120/tensorflow/local/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 44, in run
    _sys.exit(main(_sys.argv[:1] + flags_passthrough))
  File "mnist_tutorial_tf.py", line 81, in main
    evaluate=evaluate, args=train_params)
  File "/home/grads/rva5120/tensorflow/cleverhans/cleverhans/utils_tf.py", line 142, in model_train
    evaluate()
  File "mnist_tutorial_tf.py", line 70, in evaluate
    args=eval_params)
  File "/home/grads/rva5120/tensorflow/cleverhans/cleverhans/utils_tf.py", line 206, in model_eval
    keras.backend.learning_phase(): 0})
ValueError: operands could not be broadcast together with shapes (128,) (16,) (128,)

Thanks for letting us know @rva5120, I didn't upgrade to 2.0 yet but I'll take a look

Code assumes now keras <2.0.0. Easiest solution is to add keras==1.2.2 to requirements.txt, but maybe a better solutions is to remove any dependency on keras in cleverhans? I feel that cnn_model (as well as some other functions) shipped with package would be "better off" defined in examples

Yes, in the meanwhile I added the requirements.txt tweak in #111
I have been thinking about keras as well. We designed cleverhans with the goal of giving the tools needed to apply adversarial attacks and defenses to models on tensorflow (and optionally theano). Keras was added in the tutorials to help users experiment with different architectures easily (by modifying the few lines that define the model with Keras). But in the end, Keras is making a lot of things more complicated than they should be (e.g., with the learning phase var in the Keras backend, which needs to be fed in the dict when running Keras models with tensorflow).
We are in the process of fixing the new API to harmonize the interface of different attacks, and I'll get back to the keras issue once that process is done

I have fixed the Keras issue on my local version and I am happy to make a pull request if needed. Here are the steps I followed (please let me know if we can improve and/or is not the right approach):
1 - Change the Convolutional2D into CNNMODEL to the new keras 2.0 api (CONV2D), note that the following parameters have changed name/format:
nb_filter -> filters float kernel dimension arguments become a single tuple argument, kernel size.    E.g. a legacy call Conv2D(10, 3, 3) becomes Conv2D(10, (3, 3))
kernel_size can be set to an integer instead of a tuple, e.g. Conv2D(10, 3) is equivalent to Conv2D(10, (3, 3)).
subsample -> strides. Can also be set to an integer.
border_mode -> padding
2 - Inside model_eval in utils_tf.py at the end of the for loop we have the following:
accuracy += cur_batch_size * acc_value.eval(
feed_dict={x: X_test[start:end],
y: Y_test[start:end],
keras.backend.learning_phase(): 0})
Just added a if to ignore the remaining points in case the batch has a size that is lower than the current batch size (Not sure if this would be the right approach, but at least it worked for now):
if cur_batch_size == args.batch_size:
accuracy += cur_batch_size * acc_value.eval(
feed_dict={x: X_test[start:end],
y: Y_test[start:end],
keras.backend.learning_phase(): 0})

Thank you for the feedback @rafaelpossas
Regarding 2., we cannot ignore some test inputs when evaluating the accuracy. It's ok to repeat the inputs processed during training, but we need to ensure the accuracy returned was computed by evaluating exactly once each test input.


[r] Initial pkgdown attempt

Issue and/or context: Issue #1041. See also PR #1097 which disables publishing from main-old.
Changes:
Simply promotes main-old logic to main.
Notes for Reviewer:
This publishes to https://single-cell-data.github.io/TileDB-SOMA

Codecov Report
Patch coverage has no change and project coverage change: -18.97 :warning:

Comparison is base (fe69cde) 61.17% compared to head (f1ee645) 42.20%.

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

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1095       +/-   ##
===========================================
- Coverage   61.17%   42.20%   -18.97%
===========================================
  Files          81       51       -30
  Lines        5906     3625     -2281
===========================================
- Hits         3613     1530     -2083
+ Misses       2293     2095      -198

Flag
Coverage Δ

python
?

r
42.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 30 files with indirect coverage changes
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 in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@eddelbuettel weird, this repo doesn't have a _pkgdown.yml ... 👀 ...

Then I am confused it rendered at all.  You probably want to add one, we will need it eventually methinks.


[Docs] The links for example Rayclusters are broken

Search before asking

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

Description
Examples RayClusters in this link is broken.
ray-cluster.mini.yaml	Small example consisting of 1 head pod.
ray-cluster.heterogeneous.yaml	Example with heterogenous worker types. 1 head pod and 2 worker pods, each of which has a different resource quota.
ray-cluster.complete.yaml
Use case
No response
Related issues
No response
Are you willing to submit a PR?

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

@goswamig Thanks for pointing it out! If you can file a PR to help fix it, that would be great!

https://github.com/ray-project/kuberay/pull/305

Our component docs are actually soft links to exiting README.md files.

The tricky thing is all the referenced files (../config/xxx/xx.yaml) are not included in docs (mkdoc site) folder. That's the reason files are missing.

We can see the warning messages when building the docs as well

I am thinking a better way to solve the issue instead of directly update the path. We want to make sure Github README.md and mkdocs work at the same time.

Makes sense, let me know if I could help anyway. I haven't build the doc but happy to try it out :)


Show last deployed image and URL to service in Bridge

Within Keptn's Bridge the user should see the last successful deployed image for a service, as well as the URL to the service.

This feature requires a proper user-story. Let's define what a user wants to see for each service in Bridge.

Could display the deploymentURIPublic from the last successful deployment in the stage tile on the left side?  See #1402 and #1404.
But I don't know if that is always the correct URL? Maybe there is a better way to determine the current deployed image and URL?


Adding in 1.60 release notes

Updating with thaJetzah's comments
Adding in Fred's copy edits
Signed-off-by: Mary Anthony<EMAIL_ADDRESS>(cherry picked from commit 1f4ef5192c05723e231acc47813c4c8455a0166b)

LGTM (not a maintainer)

@thaJeztah yet...

ping @docker/docs-owners

LGTM

LGTM


Why not just escape every character?

Is there any reason to only escape a specific subset? It's harmless to add slashes, right?

It makes the resulting string longer, other than that it's harmless.
This is what some programming languages (Python escapes non alphanumeric strings) do where others escape a strict set (like C#).

Might be worth mentioning this as a design alternative in the readme, with the pro that it's more future-proof.

Good idea, I'll add that when I'm in front of a computer :) (you're welcome to if you'd like of course).

Updated the README, I'll leave this open for a week to see if anyone has any further input on it.

Following the research https://github.com/benjamingr/RegExp.escape/blob/master/data/other_languages/discussions.md it appears that other languages that used to escape every character have either made exceptions (like Python) or changed it (like Perl). The discussion notes contain links to posts with reasons on why changes were made.

Python's new regex engine (under development) gives you a choice; either escape all non-alphanumerics, or only metacharacters (and NUL), see https://bitbucket.org/mrabarnett/mrab-regex/src/6193ea4246da272cf18a190c46aa116737067780/regex_3/Python/regex.py?at=default#cl-342
In your discussion you mentioned a problem with wide characters; you ran into the Python re limitations with UCS-2 vs. UCS-4 builds (all Python versions up to 3.2 use one or the other based on a compile-time switch), the regular expression engine does not handle codepoints but codeunits, which in a UCS-2 build means 2 per non-BMP character. The escaping is correct for their respective builds.

I think we're good with not escaping every character. I want to focus on the discussion about big set vs readable set.


Make solution URI-safe when sending to API

My correct solution for 2022 day 25 was failing when submitting through aocrunner. I know it was correct because submitting it manually on the website worked.
I suspect that the problem is that the solution isn't being URI encoded, and since the solution contained equals (=) characters, the answer was not properly received at the API end.
This PR simply wraps the solution in encodeURIComponent() in the body of the POST fetch.
I haven't confirmed that this is the reason it was rejecting my correct answer, but the solution should be URI encoded regardless.

Thanks! I had the same issue.


fix: update sokol_gp to the latest bindings_cleanup changes in sokol_gfx

Hi! This PR fixes all the compile errors due to the changes to bindings that happened in sokol_gfx.
I also updated the samples that needed it except the sdf one, as sokol-shdc is trying to optimize away the fields of the uniform that are unused in its vertex and fragment shader, thus making the bindings incompatible with each other, so they cannot assigned the same binding slot due to that.

I will take a look and merge this eventually. Thanks for the contributions. I am usually not quick on merging breaking changing from upstream Sokol, it's expected to take some months for me to take a look and work on it.

Many thanks @kkukshtel , I've merged your changes along with additional improvements to make the sample-sdf with the changes. Unfortunately this included a breaking change in the sgp_set_uniform API, but is for the better.


Reduce compilation memory

As pointed out in https://github.com/ros2/rviz/issues/539 , it can take a lot of memory to compile rviz_default_plugins.  This PR aims to reduce the maximum amount of memory necessary to compile by doing two major things:

Only compiling display_test_fixture.cpp one time for the tests.  Previously, each test compiled its own copy, and since it takes ~1GB of memory to compile each time, this can push up the maximum consumption if we have many threads compiling.  This PR changes that file to be a library, and then all of the tests link that library in.
Split up the compilation of the MOC QT5 stuff.  Previously we were using CMAKE_AUTOMOC, which takes all of the MOC stuff and combines it into one large file.  When trying to compile that, it can take upwards for 2.5GB of memory, and we can run out of memory if we are compiling it alongside other things.  This PR changes that to generate one MOC per header file, and then compiling those MOC files separately.

The rest of the changes are to support the above.
I've done some basic testing of RViz2 locally with these changes, both the tests and RViz2 itself.  I believe this will close #539 .

CI:

Linux
Linux-aarch64
macOS
Windows

gah, osx failure as soon as I approve :(

Bah.  Maybe I need to link something into display_test_fixture.  Will take a look.

I think f83a9d8 fixes the problems on Windows and macOS.  Still waiting for local confirmation of that; once I have it, I'll fire up CI again.

New CI:

Linux
Linux-aarch64
macOS
Windows

All right, the macOS warning is in the nightly as well: https://ci.ros2.org/view/nightly/job/nightly_osx_release/1638/ .
I've opened up https://github.com/ament/ament_cmake/issues/255 to track the addition to ament_cmake, and #543 to track the refactoring of display_test_fixture.cpp.
With that, I'm going to go ahead and merge this.  Thanks for the reviews.

Please squash when merging...

Please squash when merging...

I intentionally didn't here, since the changes were a logical progression from one to the next.  I thought it would be easier to understand what I did in the individual commits rather than one squashed one.

From a changelog perspective, it's not any easier to read, because all the same information is there, as the commit messages from the component commits end up in the squashed commit message. The separate commits continue to exist here on this pr, and squashing makes it easier to cherry-pick this set of changes if we wanted to do that. I think squashing is pretty much always better, and at least on this repository I'd like to keep doing that in the future.


Create initial plan and working agreement for partnering with service teams to build out design system components

Background
The design system team has been contacted by the "Housing" team (Jarett Hailes - PO). They would like to partner with the design system team to build a data table component. This is a high-value component used widely across the organization and the Housing team has strong links to the design system team. It has been deemed that this would be a good opportunity to try out this way of working.
As a: Design system team
I want to: partner with service teams on building ui-components
so that: The platform team gets clear requirements for ui-components that are aligned to the needs of a service team.
Acceptance criteria

[ ] A working agreement is to be created that covers the following:

[ ] Contributions (on both sides)
[ ] Expectations around communications practices

[ ] Meeting attendance
[ ] Responsiveness

[ ] Team/group culture
[ ] Responsibilities/ownership (who has the final say, among other things)
[ ] Accountability
[ ] How the teams will work together

[ ] Outline for a set of recurring meetings

[ ] Methods to be reviewed by the product owner

Presentable outcomes
N/A
Sprint Ready Checklist

Acceptance criteria defined
Team has defined steps to satisfy acceptance criteria
Acceptance criteria is verifiable / testable
External / 3rd Party dependencies identified

Related issues:
Resources:
Working agreement for design system team

As per discussions on April 29th, this story will be set aside until #655 is completed


inherited connections are not query-optimized

Describe the Bug
When inheriting from a strawberry_django.type the relay-connections defined on the base-type are not respected by the query-optimizer anymore when querying the relay-connection on the sub-typ
Example:
@type(models.Place)
class PlaceType(relay.Node):
    '''This is the the base-type'''
    some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection(prefetch_related=['some_m2m_relation'])

@type(models.Restaurant)
class RestaurantType(PlaceType):
    '''This is the the sub-type'''
    another_field: auto

Querying the RestaurantType for the some_m2m_relation shows the n+1 problem unless i repeat the field definition of some_m2m_relation on the RestaurantType, preventing me from keeping my code DRY:
This works well:
@type(models.Place)
class PlaceType(relay.Node):
    '''This is the the base-type'''
    some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection(prefetch_related=['some_m2m_relation'])

@type(models.Restaurant)
class RestaurantType(PlaceType):
    '''This is the the sub-type'''
    another_field: auto
    some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection(prefetch_related=['some_m2m_relation'])

Is this the intended behavior?
System Information

strawberry-graphql 0.204.0
strawberry-graphql-django  0.16.0

Additional Context

Hi @TWeidi ,
This seems to be the same issue reported in https://github.com/strawberry-graphql/strawberry-graphql-django/issues/340 and https://github.com/strawberry-graphql/strawberry-graphql-django/issues/337
As I mentioned in both, can you try removing the prefetch_related from the connection and tell me if it starts working properly?

Hey,
thank you for your response. I tried all possible combinations of field definitions on both Place and Restaurant model:
Variant1:  some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection(prefetch_related='some_m2m_relation'])
Variant2:  some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection()
Variant3:  connection field not defined
PQ: Place query:
places {
edges {
node {
some_m2m_relation {
edges {
node {
id
}
}
}
}
}
}
RQ: Restaurant query:
restaurants {
edges {
node {
some_m2m_relation {
edges {
node {
id
}
}
}
}
}
}
`
Place
Variant1            Variant2            Variant3
                                        PQ        RQ        PQ        RQ        PQ        RQ

                 Variant1         Yes        Yes         No       Yes        N/A       Yes

Restaurant    Variant2         Yes         No         No       No        N/A       No
Variant3         Yes        No*        No       No        N/A       N/A
`

I would expect a 'Yes' here due to inheriance. All other cases behave as I would expect

Hi @TWeidi ,
Ohhh, I'm so sorry, I got confused by the bug report because it was very similar to the other 2 I mentioned. You are mentioning n+1 here, not the lack of query optimization for those queries.
Regarding those issues:

Nested queries are currently skipped by the optimizer, as you can see in this line

The reason for that is because connections are used for pagination. If you prefetch all the results, you would either be fetching a lot more than you want to then slice a possibly very large list in memory, or your cache would be thrown away and you would have to make another query for the connection itself.
To avoid that the optimizer would need to prefetch results for all items in the parent connection considering the applied pagination (together with any kind of filtering/ordering), and I haven't find a way to be able to do that correctly yet. Not sure if it is even possible TBH, consider this example:

Parent1: ChildConnection1
Parent2: ChildConnection2
Parent3: ChildConnection3

For lists django can easily prefetch all 3 child connections for the 3 parents, but if it does that trying to apply pagination on those, how can it tell that query to limit it to like 10 results for each child connection? Maybe this would require the usage of RowNumber and filter the results which rownumber is < 10, but I'm not sure if performance-wise this would be better than letting the n+1 for very large results. e.g. say each childconnection has 1m+ results, rownumber as a window function would be applied after the results are materialized, meaning you could be replacing 3 ~1ms extra queries by 1 ~100ms.

The prefetch_related issue is that, if you ask the optimizer to do that, it will do the prefetch for all items I mentioned in the previous issue. Meaning that you would be fetching in memory all the rows for them to be sliced in a list, or even to be thrown away after pagination is applied to the queryset, making it even worse than not optimizing.

For those kinds of nested relations, specially considering those limitations, I would say that you either want a simple list if the results from it are small enough, or let the n+1 issue happen and try to avoid letting too many queries happen if possible. e.g. avoid exposing a root query with a connection/list of a type that has nested connections

Hey @bellini666,
I guess I get your point regarding the nested m2m queries not being limited leading to a lot of overhead but as far as i have tested your library this query below is working perfectly fine:
places(first: 50) {
  edges {
    node {
      some_m2m_relation(first: 10) {
        edges {
          node {
            id
          }
        }
      }
    }
  }
}

So i can indeed limit the nested lists to some sensible length and get the expected result within acceptable time while it costs me only 2 database queries (no matter how many "some_m2m_relation"s are associated with one place) according to the django toolbar, but if i replace the places query with the restaurants query, the toolbar shows, that this will hit the database a lot more often, depending on the number of  "some_m2m_relation"s are associated with each place.
To rephrase my actual question: Why is this property:
some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection(prefetch_related=['some_m2m_relation'])

not inherited as is when inheriting the type for the Restaurant model from that of the Place model but obviously replaced by:
some_m2m_relation: ListConnectionWithTotalCount[SomeRelatedType] = connection()

A quick comment in here. I'll soon try to workaround this with something like this


68 allow base type to be specified

First pull req on this project, so please let me know if I need to do anything else. This adds a BaseClass option, that, if set, will create a blank base class and an extender class that uses partials to make each output class derive from that.

@dconder thanks! could you please make sure all tests are passing

@petrsvihlik  Sorry, the text files weren't configured to copy to the output folder. Tests passing.

@dconder - I went through the code briefly and it looks OK. I will make a proper review hopefully tomorrow and merge it to the master.

Hi @Simply007 ,
I’ve made the requested updates. There are now three tests. I also ran it by SonarQube and it’s green on my side. I had to keep the regex whitespace cleanup because while the tests are green locally, after being pushed into git, there were differences in line endings and the tests were failing in appveyor.

Thanks for the updated @dconder!
I have went through the changes and everything looks fine!
I will tak a look to the app veyor, why it is failing when the line endings should be ignored.
Sorry for the delay, we had a national holiday last Thursday and Friday.
Have a nice day,
@dconder

Could you send me the result of the command:
git config --global --get-all core.autocrlf
git config --local--get-all core.autocrlf

I have tried to remove the regex filter and use the parameters and my build succeeded on AppVeyor:

https://ci.appveyor.com/project/kentico/cloud-generators-net

@Simply007
git config --global --get-all core.autocrlf  >> returns "true"
git config --local--get-all core.autocrlf >> returns nothing

Thank @dconder. As I wrote in the previous comment, I have removed regular expression striping and it has worked.
I would like to leave it that way and if this error shows up again, I might be more successful in reproducing the issue.


Movement Testing 2.0

More testing is required in order to determine motor and chassis movement dependability.

try to use battery pack so that the wire doesnt pull on the robot

battery pack solution functional


aix: fix netmask for IPv6

Use SIOCGIFNETMASK6 for IPv6 network interfaces.
Refs: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/communicationtechref/ioctl_socket_control_operations.html
Fixes: https://github.com/nodejs/node/issues/30504

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1626/
Node integration CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/112/

Without this change on AIX the SIOCGIFNETMASK ioctl() call errors with EADDRNOTAVAIL when used on an interface without any IPv4 addresses which caused uv_interface_addresses() to return UV_ENOSYS due to
https://github.com/libuv/libuv/blob/f9618443920fd0cbd3ab11c9d37c1f24a7aa1067/src/unix/aix-common.c#L256-L259

cc @libuv/ibmi as aix-common.c is used there as well.

The changes look good to me. @dmabupt please also review and test this one.
At some point, we may switch implementations to use getifaddrs() instead.

It appears that on AIX the SIOCGIFNETMASK and SIOCGIFNETMASK6 ioctl() calls are returning the the address family as 0 which is causing the platform_output test to report all netmasks as none.
e.g. https://ci.nodejs.org/job/libuv-test-commit-aix/1669/nodes=aix72-xlc-ppc64/console
on test-osuosl-aix72-ppc64_be-2:
# uv_interface_addresses:
#   name: en0
#   internal: 0
#   physical address: 00:00:00:00:00:00
#   address: <IP_ADDRESS>
#   netmask: none
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: <IP_ADDRESS>
#   netmask: none
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: ::1
#   netmask: none

where
$ ifconfig -a
en0: flags=1e084863,814c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
        inet <IP_ADDRESS> netmask 0xffffff00 broadcast <IP_ADDRESS>
         tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>
        inet <IP_ADDRESS> netmask 0xff000000 broadcast <IP_ADDRESS>
        inet6 ::1%1/64
         tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
$

Explicitly setting the address family fixes the netmask reporting:
https://ci.nodejs.org/job/libuv-test-commit-aix/1673/nodes=aix72-xlc-ppc64/console
# uv_interface_addresses:
#   name: en0
#   internal: 0
#   physical address: 00:00:00:00:00:00
#   address: <IP_ADDRESS>
#   netmask: <IP_ADDRESS>
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: <IP_ADDRESS>
#   netmask: <IP_ADDRESS>
#   name: lo0
#   internal: 1
#   physical address: 00:00:00:00:00:00
#   address: ::1
#   netmask: ffff:ffff:ffff:ffff::

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1628/

CI looks good.

@bnoordhuis Consolidated the cleanup code via goto. PTAL.

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1635/

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1638/

Landed in https://github.com/libuv/libuv/commit/e3d378747c3adc5656daed964f4f66386c3cd551 and https://github.com/libuv/libuv/commit/cf6a678fa4b915a23feac0aa35f511c80cb855ee. Thanks!


Docker couldn't start ckgapp

I believe this is due to the NumPy version. Can you freeze the current working environment on a running instance?
Any idea/suggestion would be appreciated.

Also in Jupyter Notebook

RuntimeError                              Traceback (most recent call last)
RuntimeError: module compiled against API version 0xe but this version of numpy is 0xd

ImportError                               Traceback (most recent call last)
/tmp/ipykernel_1240/652071742.py in
6 from ckg.graphdb_builder.experiments.parsers import proteomicsParser
7
----> 8 from ckg.report_manager import project
9 from ckg.analytics_core.analytics import analytics
10 from ckg.analytics_core.viz import viz
/CKG/ckg/report_manager/project.py in
9 from ckg import ckg_utils
10 from ckg.graphdb_builder import builder_utils
---> 11 from ckg.report_manager.dataset import Dataset, DNAseqDataset, ProteomicsDataset, InteractomicsDataset, PhosphoproteomicsDataset, ClinicalDataset, LongitudinalProteomicsDataset, MultiOmicsDataset
12 from ckg.analytics_core.viz import viz
13 from ckg.analytics_core import utils as acore_utils
/CKG/ckg/report_manager/dataset.py in
5 from collections import OrderedDict
6 from ckg import ckg_utils
----> 7 from ckg.report_manager import report as rp, knowledge
8 from ckg.analytics_core import analytics_factory
9 from ckg.analytics_core.analytics import analytics
/CKG/ckg/report_manager/report.py in
11 from ckg.report_manager import utils
12 from ckg import ckg_utils
---> 13 from ckg.analytics_core.viz import viz
14 from ckg.analytics_core import utils as acore_utils
15
/CKG/ckg/analytics_core/viz/viz.py in
26 import json
27 from ckg.analytics_core import utils
---> 28 from ckg.analytics_core.analytics import analytics
29 from wordcloud import WordCloud, STOPWORDS
30 from nltk.corpus import stopwords
/CKG/ckg/analytics_core/analytics/analytics.py in
15 import scipy.stats
16 from scipy.special import factorial, betainc
---> 17 import umap
18 from sklearn import preprocessing, ensemble, cluster, metrics
19 from scipy import stats
/usr/local/lib/python3.7/site-packages/umap/init.py in
1 from warnings import warn, catch_warnings, simplefilter
----> 2 from .umap_ import UMAP
3
4 try:
5     with catch_warnings():
/usr/local/lib/python3.7/site-packages/umap/umap_.py in
26 from scipy.sparse import tril as sparse_tril, triu as sparse_triu
27 import scipy.sparse.csgraph
---> 28 import numba
29
30 import umap.distances as dist
/usr/local/lib/python3.7/site-packages/numba/init.py in
37
38 # Re-export decorators
---> 39 from numba.core.decorators import (cfunc, generated_jit, jit, njit, stencil,
40                                    jit_module)
41
/usr/local/lib/python3.7/site-packages/numba/core/decorators.py in
10
11 from numba.core.errors import DeprecationError, NumbaDeprecationWarning
---> 12 from numba.stencils.stencil import stencil
13 from numba.core import config, extending, sigutils, registry
14
/usr/local/lib/python3.7/site-packages/numba/stencils/stencil.py in
9 from llvmlite import ir as lir
10
---> 11 from numba.core import types, typing, utils, ir, config, ir_utils, registry
12 from numba.core.typing.templates import (CallableTemplate, signature,
13                                          infer_global, AbstractTemplate)
/usr/local/lib/python3.7/site-packages/numba/core/ir_utils.py in
14
15 import numba
---> 16 from numba.core.extending import _Intrinsic
17 from numba.core import types, utils, typing, ir, analysis, postproc, rewrites, config, cgutils
18 from numba.core.typing.templates import (signature, infer_global,
/usr/local/lib/python3.7/site-packages/numba/core/extending.py in
17 from numba.core.datamodel import models   # noqa: F401
18 from numba.core.datamodel import register_default as register_model  # noqa: F401, E501
---> 19 from numba.core.pythonapi import box, unbox, reflect, NativeValue  # noqa: F401
20 from numba._helperlib import _import_cython_function  # noqa: F401
21 from numba.core.serialize import ReduceMixin
/usr/local/lib/python3.7/site-packages/numba/core/pythonapi.py in
10
11 import ctypes
---> 12 from numba import _helperlib
13 from numba.core import (
14     types, utils, config, lowering, cgutils, imputils, serialize,
ImportError: numpy.core.multiarray failed to import

Hi, I changed the numpy version to 1.19.5 for compatibility reasons. It should work and it should solve some issues experienced when creating new projects.

Hi,
1.19.5 seemed to be the cause for the initial bug that SushantGautam reported and that I could confirm.  How should we proceed? Test again and reopen this issue?

Hi,
just checked the 1.19.5 docker on macOS Big Sur. Here, it works. So maybe this is a strange bug that only occurs on docker on Windows and not on Mac. Did anyone test on Windows and can confirm?

Hi,
I tested yesterday and today again on MacOS Catalina and it worked. I am now going to test on Windows and Ubuntu.
What OS did you tested it in?

Hi, I just tested it on Windows 10 and it works. Ubuntu next.

Hi, tested it now on a Microsoft Windows 10 Pro - which previously didn't work and now seems to work.


feat: mirror & mirror-modules port from dhctl

This PR adds 2 new subcommands to deckhouse-cli, mirror and mirror-modules that are directly ported from dhctl and serve the same purpose.
More information on this commands can be found in the Deckhouse FAQ.

@asviel I'm done with refactoring and testing this, review please


Scan for partial env in WARDEN_HOME_DIR to allow customizations

This addition allows users to customize the docker-compose files by adding similarly-named files in the ~/.warden/environments... directory.

Thanks for the contribution @k4emic. This should be included in the next tagged release (no ETA on exactly when I'll tag it though, as I'm about ready to go on paternity leave for a couple weeks and not sure I'll have time to complete the 0.10.0 milestone before then)


🚀 Feature: Add pop up on "chat" if user is not registered/connected

🔖 Feature description
Currently when clicking to "chat" without being registered or connected, nothing happen, so now we will need a pop up to say we need to be online or create account
🎤 Why is this feature needed ?
It is needed because it's better to handle this
✌ How do you aim to achieve this?
Just adding pop up when clicking the chat button is okey
🔄 Additional Information
No response
👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

Are you willing to submit PR?
None

I am willing to work on this issue, please assign it to me !

@DoTheBestToGetTheBest  @QuantuM410  Please assign me this issue .

i would love to work on this

@DoTheBestToGetTheBest I currently dont see how this is going to be implemented in the open source version without auth.
Otherwise for connection, are you suggesting we check if backend is up?


Does this fork support Nvidia Optimus

I have a laptop which has both a nvidia dGPU that is wired to the HDMI port and an Intel iGPU that powers the internal display.
Does this fork work with that kind of configuration

Hi, @gi-yt
I can't say for use because never had such configuration.

I will Install it soon. I will update you if i have any issues

finally got my hands on wlroots-eglstreams. Will update you if I have any issues

I was out for a while… so couldn't test it out.
With wlroots-eglstreams when the external GPU is disabled with optimus-manager…
It does not work when only my external GPU (driver 495 on arch) is enabled.
Sway exits with the following output when I do sway --unsupported-gpu
00:00:00.002 [ERROR] [sway/main.c:62] !!! Proprietary Nvidia drivers are in use !!!

sway: render/eglstreams_allocator.c:103: wlr_eglstreams_allocator_create: Assertion 'wlr_backend_is_multi(backend)' failed.

I was out for a while… so couldn't test it out.
With wlroots-eglstreams when the external GPU is disabled with optimus-manager…
It does not work when only my external GPU (driver 495 on arch) is enabled.
Sway exits with the following output when I do sway --unsupported-gpu
00:00:00.002 [ERROR] [sway/main.c:62] !!! Proprietary Nvidia drivers are in use !!!

sway: render/eglstreams_allocator.c:103: wlr_eglstreams_allocator_create: Assertion 'wlr_backend_is_multi(backend)' failed.

Oops, forgot to send the debug output

Log output from sway -d --unsupported-gpu
```
00:00:00.000 [INFO] [sway/main.c:340] Sway version 1.6-5f4162f4 (Dec 23 2021, branch 'master')
00:00:00.000 [INFO] [sway/main.c:341] wlroots version 0.16.0
00:00:00.002 [INFO] [sway/main.c:120] Linux aspire 5.15.12-xanmod1-tt-1 #1 SMP Thu, 30 Dec 2021 19:40:05 +0000 x86_64 GNU/Linux
00:00:00.002 [INFO] [sway/main.c:136] Contents of /etc/lsb-release:
00:00:00.002 [INFO] [sway/main.c:120] LSB_VERSION=1.4
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_ID=EndeavourOS
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_RELEASE=rolling
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_DESCRIPTION="EndeavourOS Linux"
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_CODENAME=rolling
00:00:00.002 [INFO] [sway/main.c:136] Contents of /etc/os-release:
00:00:00.002 [INFO] [sway/main.c:120] NAME=EndeavourOS
00:00:00.002 [INFO] [sway/main.c:120] PRETTY_NAME=EndeavourOS
00:00:00.002 [INFO] [sway/main.c:120] ID=endeavouros
00:00:00.002 [INFO] [sway/main.c:120] ID_LIKE=arch
00:00:00.002 [INFO] [sway/main.c:120] BUILD_ID=2021.12.17
00:00:00.002 [INFO] [sway/main.c:120] ANSI_COLOR="38;2;23;147;209"
00:00:00.002 [INFO] [sway/main.c:120] HOME_URL='https://endeavouros.com'
00:00:00.002 [INFO] [sway/main.c:120] DOCUMENTATION_URL='https://discovery.endeavouros.com'
00:00:00.002 [INFO] [sway/main.c:120] SUPPORT_URL='https://forum.endeavouros.com'
00:00:00.002 [INFO] [sway/main.c:120] BUG_REPORT_URL='https://forum.endeavouros.com/c/arch-based-related-questions/bug-reports'
00:00:00.002 [INFO] [sway/main.c:120] LOGO=endeavouros
00:00:00.002 [INFO] [sway/main.c:108] LD_LIBRARY_PATH=
00:00:00.002 [INFO] [sway/main.c:108] LD_PRELOAD=
00:00:00.002 [INFO] [sway/main.c:108] PATH=/home/ak/.npm-packages/bin:/home/ak/.local/bin:/home/ak/.local/share/go/bin:/home/ak/.local/share/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/flutter/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
00:00:00.002 [INFO] [sway/main.c:108] SWAYSOCK=
00:00:00.002 [ERROR] [sway/main.c:62] !!! Proprietary Nvidia drivers are in use !!!
00:00:00.002 [DEBUG] [sway/server.c:50] Preparing Wayland server initialization
00:00:00.002 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:80] Could not connect to socket /run/seatd.sock: No such file or directory
00:00:00.002 [INFO] [wlr] [libseat] [libseat/libseat.c:76] Backend 'seatd' failed to open seat, skipping
00:00:00.009 [INFO] [wlr] [libseat] [libseat/libseat.c:73] Seat opened with backend 'logind'
00:00:00.010 [INFO] [wlr] [backend/session/session.c:110] Successfully loaded libseat session
00:00:00.011 [INFO] [wlr] [backend/backend.c:220] Found 2 GPUs
00:00:00.011 [INFO] [wlr] [backend/drm/backend.c:183] Initializing DRM backend for /dev/dri/card0 (i915)
00:00:00.011 [DEBUG] [wlr] [backend/drm/drm.c:89] Using atomic DRM interface
00:00:00.011 [DEBUG] [wlr] [backend/drm/drm.c:102] ADDFB2 modifiers supported
00:00:00.011 [INFO] [wlr] [backend/drm/drm.c:261] Found 3 DRM CRTCs
00:00:00.012 [INFO] [wlr] [backend/drm/drm.c:182] Found 9 DRM planes
00:00:00.012 [INFO] [wlr] [backend/drm/backend.c:183] Initializing DRM backend for /dev/dri/card1 (nvidia-drm)
00:00:00.012 [DEBUG] [wlr] [backend/drm/drm.c:89] Using atomic DRM interface
00:00:00.012 [DEBUG] [wlr] [backend/drm/drm.c:102] ADDFB2 modifiers supported
00:00:00.012 [INFO] [wlr] [backend/drm/drm.c:261] Found 4 DRM CRTCs
00:00:00.012 [INFO] [wlr] [backend/drm/drm.c:182] Found 12 DRM planes
00:00:00.016 [INFO] [wlr] [render/egl.c:203] Supported EGL client extensions: EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11 EGL_EXT_platform_x11 EGL_EXT_platform_device EGL_KHR_platform_wayland EGL_EXT_platform_wayland EGL_KHR_platform_gbm EGL_MESA_platform_gbm EGL_MESA_platform_xcb EGL_MESA_platform_surfaceless
00:00:00.018 [DEBUG] [wlr] [render/egl.c:528] Using EGL device /dev/dri/card1
00:00:00.019 [INFO] [wlr] [render/egl.c:409] Using EGL 1.5
00:00:00.019 [INFO] [wlr] [render/egl.c:410] Supported EGL display extensions: EGL_EXT_buffer_age EGL_EXT_client_sync EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_MESA_image_dma_buf_export EGL_EXT_output_base EGL_EXT_output_drm EGL_EXT_protected_content EGL_EXT_stream_consumer_egloutput EGL_EXT_stream_acquire_mode EGL_EXT_sync_reuse EGL_IMG_context_priority EGL_KHR_config_attribs EGL_KHR_create_context_no_error EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_partial_update EGL_KHR_swap_buffers_with_damage EGL_KHR_no_config_context EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_reusable_sync EGL_KHR_stream EGL_KHR_stream_attrib EGL_KHR_stream_consumer_gltexture EGL_KHR_stream_cross_process_fd EGL_KHR_stream_fifo EGL_KHR_stream_producer_eglsurface EGL_KHR_surfaceless_context EGL_KHR_wait_sync EGL_NV_nvrm_fence_sync EGL_NV_quadruple_buffer EGL_NV_stream_consumer_eglimage EGL_NV_stream_cross_display EGL_NV_stream_cross_object EGL_NV_stream_cross_process EGL_NV_stream_cross_system EGL_NV_stream_dma EGL_NV_stream_flush EGL_NV_stream_metadata EGL_NV_stream_remote EGL_NV_stream_reset EGL_NV_stream_socket EGL_NV_stream_socket_inet EGL_NV_stream_socket_unix EGL_NV_stream_sync EGL_NV_stream_fifo_next EGL_NV_stream_fifo_synchronous EGL_NV_stream_consumer_gltexture_yuv EGL_NV_stream_attrib EGL_NV_stream_origin EGL_NV_system_time EGL_NV_output_drm_flip_event EGL_NV_triple_buffer EGL_NV_robustness_video_memory_purge EGL_WL_bind_wayland_display EGL_WL_wayland_eglstream
00:00:00.019 [INFO] [wlr] [render/egl.c:412] Supported EGL device extensions: EGL_NV_device_cuda EGL_EXT_device_drm EGL_EXT_device_drm_render_node EGL_EXT_device_persistent_id
00:00:00.019 [INFO] [wlr] [render/egl.c:414] EGL vendor: NVIDIA
00:00:00.019 [INFO] [wlr] [render/egl.c:416] EGL driver name: nvidia
00:00:00.020 [DEBUG] [wlr] [render/egl.c:181] Supported DMA-BUF formats: AB24 XB24 R8   RG88 UYVY AB4H AR24 AS24 XS24 XR24 RG16 AR30 R101 R100 AB30 B101 B100 YU12 NV12 NV21 NV16 NV24 P010 P210 P012 HD01 UHD0
00:00:00.020 [DEBUG] [wlr] [render/egl.c:182] EGL DMA-BUF format modifiers supported
00:00:00.023 [DEBUG] [wlr] [render/egl.c:479] Obtained high priority context
00:00:00.023 [DEBUG] [wlr] [render/egl.c:579] Using EGL_PLATFORM_DEVICE_EXT
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:825] Creating GLES2 renderer
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:826] Using OpenGL ES 3.2 NVIDIA 495.46
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:827] GL vendor: NVIDIA Corporation
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:828] GL renderer: NVIDIA GeForce GTX 1650/PCIe/SSE2
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:829] Supported GLES2 extensions: GL_EXT_base_instance GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_buffer_storage GL_EXT_clear_texture GL_EXT_clip_control GL_EXT_clip_cull_distance GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_conservative_depth GL_EXT_copy_image GL_EXT_depth_clamp GL_EXT_debug_label GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_EGL_image_array GL_EXT_EGL_image_storage GL_EXT_EGL_image_external_wrap_modes GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_gpu_shader5 GL_EXT_map_buffer_range GL_EXT_multi_draw_indirect GL_EXT_multisample_compatibility GL_EXT_multisampled_render_to_texture GL_EXT_multisampled_render_to_texture2 GL_EXT_multiview_texture_multisample GL_EXT_multiview_timer_query GL_EXT_occlusion_query_boolean GL_EXT_polygon_offset_clamp GL_EXT_post_depth_coverage GL_EXT_primitive_bounding_box GL_EXT_raster_multisample GL_EXT_render_snorm GL_EXT_robustness GL_EXT_separate_shader_objects GL_EXT_shader_group_vote GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix GL_EXT_shader_io_blocks GL_EXT_shader_non_constant_global_initializers GL_EXT_shader_texture_lod GL_EXT_shadow_samplers GL_EXT_sparse_texture GL_EXT_sparse_texture2 GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_compression_bptc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map_array GL_EXT_texture_filter_anisotropic GL_EXT_texture_filter_minmax GL_EXT_texture_format_BGRA8888 GL_EXT_texture_mirror_clamp_to_edge GL_EXT_texture_norm16 GL_EXT_texture_query_lod GL_EXT_texture_rg GL_EXT_texture_shadow_lod GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_view GL_EXT_draw_transform_feedback GL_EXT_unpack_subimage GL_EXT_window_rectangles GL_KHR_context_flush_control GL_KHR_debug GL_EXT_memory_object GL_EXT_memory_object_fd GL_NV_memory_object_sparse GL_KHR_parallel_shader_compile GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_EXT_semaphore GL_EXT_semaphore_fd GL_NV_timeline_semaphore GL_KHR_shader_subgroup GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_sliced_3d GL_KHR_texture_compression_astc_hdr GL_NV_bgr GL_NV_bindless_texture GL_NV_blend_equation_advanced GL_NV_blend_equation_advanced_coherent GL_NVX_blend_equation_advanced_multi_draw_buffers GL_NV_blend_minmax_factor GL_NV_clip_space_w_scaling GL_NV_compute_shader_derivatives GL_NV_conditional_render GL_NV_conservative_raster GL_NV_conservative_raster_pre_snap_triangles GL_NV_copy_buffer GL_NV_copy_image GL_NV_draw_buffers GL_NV_draw_instanced GL_NV_draw_texture GL_NV_draw_vulkan_image GL_NV_EGL_stream_consumer_external GL_NV_explicit_attrib_location GL_NV_fbo_color_attachments GL_NV_fill_rectangle GL_NV_fragment_coverage_to_color GL_NV_fragment_shader_barycentric GL_NV_fragment_shader_interlock GL_NV_framebuffer_blit GL_NV_framebuffer_mixed_samples GL_NV_framebuffer_multisample GL_NV_generate_mipmap_sRGB GL_NV_geometry_shader_passthrough GL_NV_instanced_arrays GL_NV_internalformat_sample_query GL_NV_gpu_shader5 GL_NV_image_formats GL_NV_memory_attachment GL_NV_mesh_shader GL_NV_occlusion_query_samples GL_NV_non_square_matrices GL_NV_pack_subimage GL_NV_packed_float GL_NV_packed_float_linear GL_NV_path_rendering GL_NV_path_rendering_shared_edge GL_NV_pixel_buffer_object GL_NV_polygon_mode GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_NV_representative_fragment_test GL_NV_sample_locations GL_NV_sample_mask_override_coverage GL_NV_scissor_exclusive GL_NV_shader_atomic_fp16_vector GL_NV_shader_noperspective_interpolation GL_NV_shader_subgroup_partitioned GL_NV_shader_texture_footprint GL_NV_shading_rate_image GL_NV_shadow_samplers_array GL_NV_shadow_samplers_cube GL_NV_sRGB_formats GL_NV_stereo_view_rendering GL_NV_texture_array GL_NV_texture_barrier GL_NV_texture_border_clamp GL_NV_texture_compression_latc GL_NV_texture_compression_s3tc GL_NV_texture_compression_s3tc_update GL_NV_timer_query GL_NV_viewport_array GL_NV_viewport_array2 GL_NV_viewport_swizzle GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_depth24 GL_OES_depth32 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_buffer GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_gpu_shader5 GL_OES_shader_io_blocks GL_OES_texture_view GL_OES_primitive_bounding_box GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_image_atomic GL_OES_shader_multisample_interpolation GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_cube_map_array GL_OES_texture_npot GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_vertex_array_object GL_OES_vertex_half_float GL_OES_viewport_array GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture GL_ANDROID_extension_pack_es31a
sway: render/eglstreams_allocator.c:103: wlr_eglstreams_allocator_create: Assertion `wlr_backend_is_multi(backend)' failed.
```

Also I forgot to mention that i am using sway-borders-git (from aur) and wlroots-eglstreams-git (from the chaotic aur which builds things automagically every 2-3 days or so iirc).

Oops, forgot to send the debug output

Log output from sway -d --unsupported-gpu
```
00:00:00.000 [INFO] [sway/main.c:340] Sway version 1.6-5f4162f4 (Dec 23 2021, branch 'master')
00:00:00.000 [INFO] [sway/main.c:341] wlroots version 0.16.0
00:00:00.002 [INFO] [sway/main.c:120] Linux aspire 5.15.12-xanmod1-tt-1 #1 SMP Thu, 30 Dec 2021 19:40:05 +0000 x86_64 GNU/Linux
00:00:00.002 [INFO] [sway/main.c:136] Contents of /etc/lsb-release:
00:00:00.002 [INFO] [sway/main.c:120] LSB_VERSION=1.4
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_ID=EndeavourOS
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_RELEASE=rolling
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_DESCRIPTION="EndeavourOS Linux"
00:00:00.002 [INFO] [sway/main.c:120] DISTRIB_CODENAME=rolling
00:00:00.002 [INFO] [sway/main.c:136] Contents of /etc/os-release:
00:00:00.002 [INFO] [sway/main.c:120] NAME=EndeavourOS
00:00:00.002 [INFO] [sway/main.c:120] PRETTY_NAME=EndeavourOS
00:00:00.002 [INFO] [sway/main.c:120] ID=endeavouros
00:00:00.002 [INFO] [sway/main.c:120] ID_LIKE=arch
00:00:00.002 [INFO] [sway/main.c:120] BUILD_ID=2021.12.17
00:00:00.002 [INFO] [sway/main.c:120] ANSI_COLOR="38;2;23;147;209"
00:00:00.002 [INFO] [sway/main.c:120] HOME_URL='https://endeavouros.com'
00:00:00.002 [INFO] [sway/main.c:120] DOCUMENTATION_URL='https://discovery.endeavouros.com'
00:00:00.002 [INFO] [sway/main.c:120] SUPPORT_URL='https://forum.endeavouros.com'
00:00:00.002 [INFO] [sway/main.c:120] BUG_REPORT_URL='https://forum.endeavouros.com/c/arch-based-related-questions/bug-reports'
00:00:00.002 [INFO] [sway/main.c:120] LOGO=endeavouros
00:00:00.002 [INFO] [sway/main.c:108] LD_LIBRARY_PATH=
00:00:00.002 [INFO] [sway/main.c:108] LD_PRELOAD=
00:00:00.002 [INFO] [sway/main.c:108] PATH=/home/ak/.npm-packages/bin:/home/ak/.local/bin:/home/ak/.local/share/go/bin:/home/ak/.local/share/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/flutter/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
00:00:00.002 [INFO] [sway/main.c:108] SWAYSOCK=
00:00:00.002 [ERROR] [sway/main.c:62] !!! Proprietary Nvidia drivers are in use !!!
00:00:00.002 [DEBUG] [sway/server.c:50] Preparing Wayland server initialization
00:00:00.002 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:80] Could not connect to socket /run/seatd.sock: No such file or directory
00:00:00.002 [INFO] [wlr] [libseat] [libseat/libseat.c:76] Backend 'seatd' failed to open seat, skipping
00:00:00.009 [INFO] [wlr] [libseat] [libseat/libseat.c:73] Seat opened with backend 'logind'
00:00:00.010 [INFO] [wlr] [backend/session/session.c:110] Successfully loaded libseat session
00:00:00.011 [INFO] [wlr] [backend/backend.c:220] Found 2 GPUs
00:00:00.011 [INFO] [wlr] [backend/drm/backend.c:183] Initializing DRM backend for /dev/dri/card0 (i915)
00:00:00.011 [DEBUG] [wlr] [backend/drm/drm.c:89] Using atomic DRM interface
00:00:00.011 [DEBUG] [wlr] [backend/drm/drm.c:102] ADDFB2 modifiers supported
00:00:00.011 [INFO] [wlr] [backend/drm/drm.c:261] Found 3 DRM CRTCs
00:00:00.012 [INFO] [wlr] [backend/drm/drm.c:182] Found 9 DRM planes
00:00:00.012 [INFO] [wlr] [backend/drm/backend.c:183] Initializing DRM backend for /dev/dri/card1 (nvidia-drm)
00:00:00.012 [DEBUG] [wlr] [backend/drm/drm.c:89] Using atomic DRM interface
00:00:00.012 [DEBUG] [wlr] [backend/drm/drm.c:102] ADDFB2 modifiers supported
00:00:00.012 [INFO] [wlr] [backend/drm/drm.c:261] Found 4 DRM CRTCs
00:00:00.012 [INFO] [wlr] [backend/drm/drm.c:182] Found 12 DRM planes
00:00:00.016 [INFO] [wlr] [render/egl.c:203] Supported EGL client extensions: EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11 EGL_EXT_platform_x11 EGL_EXT_platform_device EGL_KHR_platform_wayland EGL_EXT_platform_wayland EGL_KHR_platform_gbm EGL_MESA_platform_gbm EGL_MESA_platform_xcb EGL_MESA_platform_surfaceless
00:00:00.018 [DEBUG] [wlr] [render/egl.c:528] Using EGL device /dev/dri/card1
00:00:00.019 [INFO] [wlr] [render/egl.c:409] Using EGL 1.5
00:00:00.019 [INFO] [wlr] [render/egl.c:410] Supported EGL display extensions: EGL_EXT_buffer_age EGL_EXT_client_sync EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_MESA_image_dma_buf_export EGL_EXT_output_base EGL_EXT_output_drm EGL_EXT_protected_content EGL_EXT_stream_consumer_egloutput EGL_EXT_stream_acquire_mode EGL_EXT_sync_reuse EGL_IMG_context_priority EGL_KHR_config_attribs EGL_KHR_create_context_no_error EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_partial_update EGL_KHR_swap_buffers_with_damage EGL_KHR_no_config_context EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_reusable_sync EGL_KHR_stream EGL_KHR_stream_attrib EGL_KHR_stream_consumer_gltexture EGL_KHR_stream_cross_process_fd EGL_KHR_stream_fifo EGL_KHR_stream_producer_eglsurface EGL_KHR_surfaceless_context EGL_KHR_wait_sync EGL_NV_nvrm_fence_sync EGL_NV_quadruple_buffer EGL_NV_stream_consumer_eglimage EGL_NV_stream_cross_display EGL_NV_stream_cross_object EGL_NV_stream_cross_process EGL_NV_stream_cross_system EGL_NV_stream_dma EGL_NV_stream_flush EGL_NV_stream_metadata EGL_NV_stream_remote EGL_NV_stream_reset EGL_NV_stream_socket EGL_NV_stream_socket_inet EGL_NV_stream_socket_unix EGL_NV_stream_sync EGL_NV_stream_fifo_next EGL_NV_stream_fifo_synchronous EGL_NV_stream_consumer_gltexture_yuv EGL_NV_stream_attrib EGL_NV_stream_origin EGL_NV_system_time EGL_NV_output_drm_flip_event EGL_NV_triple_buffer EGL_NV_robustness_video_memory_purge EGL_WL_bind_wayland_display EGL_WL_wayland_eglstream
00:00:00.019 [INFO] [wlr] [render/egl.c:412] Supported EGL device extensions: EGL_NV_device_cuda EGL_EXT_device_drm EGL_EXT_device_drm_render_node EGL_EXT_device_persistent_id
00:00:00.019 [INFO] [wlr] [render/egl.c:414] EGL vendor: NVIDIA
00:00:00.019 [INFO] [wlr] [render/egl.c:416] EGL driver name: nvidia
00:00:00.020 [DEBUG] [wlr] [render/egl.c:181] Supported DMA-BUF formats: AB24 XB24 R8   RG88 UYVY AB4H AR24 AS24 XS24 XR24 RG16 AR30 R101 R100 AB30 B101 B100 YU12 NV12 NV21 NV16 NV24 P010 P210 P012 HD01 UHD0
00:00:00.020 [DEBUG] [wlr] [render/egl.c:182] EGL DMA-BUF format modifiers supported
00:00:00.023 [DEBUG] [wlr] [render/egl.c:479] Obtained high priority context
00:00:00.023 [DEBUG] [wlr] [render/egl.c:579] Using EGL_PLATFORM_DEVICE_EXT
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:825] Creating GLES2 renderer
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:826] Using OpenGL ES 3.2 NVIDIA 495.46
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:827] GL vendor: NVIDIA Corporation
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:828] GL renderer: NVIDIA GeForce GTX 1650/PCIe/SSE2
00:00:00.046 [INFO] [wlr] [render/gles2/renderer.c:829] Supported GLES2 extensions: GL_EXT_base_instance GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_buffer_storage GL_EXT_clear_texture GL_EXT_clip_control GL_EXT_clip_cull_distance GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_conservative_depth GL_EXT_copy_image GL_EXT_depth_clamp GL_EXT_debug_label GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_EGL_image_array GL_EXT_EGL_image_storage GL_EXT_EGL_image_external_wrap_modes GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_gpu_shader5 GL_EXT_map_buffer_range GL_EXT_multi_draw_indirect GL_EXT_multisample_compatibility GL_EXT_multisampled_render_to_texture GL_EXT_multisampled_render_to_texture2 GL_EXT_multiview_texture_multisample GL_EXT_multiview_timer_query GL_EXT_occlusion_query_boolean GL_EXT_polygon_offset_clamp GL_EXT_post_depth_coverage GL_EXT_primitive_bounding_box GL_EXT_raster_multisample GL_EXT_render_snorm GL_EXT_robustness GL_EXT_separate_shader_objects GL_EXT_shader_group_vote GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix GL_EXT_shader_io_blocks GL_EXT_shader_non_constant_global_initializers GL_EXT_shader_texture_lod GL_EXT_shadow_samplers GL_EXT_sparse_texture GL_EXT_sparse_texture2 GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_compression_bptc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map_array GL_EXT_texture_filter_anisotropic GL_EXT_texture_filter_minmax GL_EXT_texture_format_BGRA8888 GL_EXT_texture_mirror_clamp_to_edge GL_EXT_texture_norm16 GL_EXT_texture_query_lod GL_EXT_texture_rg GL_EXT_texture_shadow_lod GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode GL_EXT_texture_storage GL_EXT_texture_view GL_EXT_draw_transform_feedback GL_EXT_unpack_subimage GL_EXT_window_rectangles GL_KHR_context_flush_control GL_KHR_debug GL_EXT_memory_object GL_EXT_memory_object_fd GL_NV_memory_object_sparse GL_KHR_parallel_shader_compile GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_EXT_semaphore GL_EXT_semaphore_fd GL_NV_timeline_semaphore GL_KHR_shader_subgroup GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_sliced_3d GL_KHR_texture_compression_astc_hdr GL_NV_bgr GL_NV_bindless_texture GL_NV_blend_equation_advanced GL_NV_blend_equation_advanced_coherent GL_NVX_blend_equation_advanced_multi_draw_buffers GL_NV_blend_minmax_factor GL_NV_clip_space_w_scaling GL_NV_compute_shader_derivatives GL_NV_conditional_render GL_NV_conservative_raster GL_NV_conservative_raster_pre_snap_triangles GL_NV_copy_buffer GL_NV_copy_image GL_NV_draw_buffers GL_NV_draw_instanced GL_NV_draw_texture GL_NV_draw_vulkan_image GL_NV_EGL_stream_consumer_external GL_NV_explicit_attrib_location GL_NV_fbo_color_attachments GL_NV_fill_rectangle GL_NV_fragment_coverage_to_color GL_NV_fragment_shader_barycentric GL_NV_fragment_shader_interlock GL_NV_framebuffer_blit GL_NV_framebuffer_mixed_samples GL_NV_framebuffer_multisample GL_NV_generate_mipmap_sRGB GL_NV_geometry_shader_passthrough GL_NV_instanced_arrays GL_NV_internalformat_sample_query GL_NV_gpu_shader5 GL_NV_image_formats GL_NV_memory_attachment GL_NV_mesh_shader GL_NV_occlusion_query_samples GL_NV_non_square_matrices GL_NV_pack_subimage GL_NV_packed_float GL_NV_packed_float_linear GL_NV_path_rendering GL_NV_path_rendering_shared_edge GL_NV_pixel_buffer_object GL_NV_polygon_mode GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_NV_representative_fragment_test GL_NV_sample_locations GL_NV_sample_mask_override_coverage GL_NV_scissor_exclusive GL_NV_shader_atomic_fp16_vector GL_NV_shader_noperspective_interpolation GL_NV_shader_subgroup_partitioned GL_NV_shader_texture_footprint GL_NV_shading_rate_image GL_NV_shadow_samplers_array GL_NV_shadow_samplers_cube GL_NV_sRGB_formats GL_NV_stereo_view_rendering GL_NV_texture_array GL_NV_texture_barrier GL_NV_texture_border_clamp GL_NV_texture_compression_latc GL_NV_texture_compression_s3tc GL_NV_texture_compression_s3tc_update GL_NV_timer_query GL_NV_viewport_array GL_NV_viewport_array2 GL_NV_viewport_swizzle GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_depth24 GL_OES_depth32 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_buffer GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_gpu_shader5 GL_OES_shader_io_blocks GL_OES_texture_view GL_OES_primitive_bounding_box GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_image_atomic GL_OES_shader_multisample_interpolation GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_cube_map_array GL_OES_texture_npot GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_vertex_array_object GL_OES_vertex_half_float GL_OES_viewport_array GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture GL_ANDROID_extension_pack_es31a
sway: render/eglstreams_allocator.c:103: wlr_eglstreams_allocator_create: Assertion `wlr_backend_is_multi(backend)' failed.
```

Also I forgot to mention that i am using sway-borders-git (from aur) and wlroots-eglstreams-git (from the chaotic aur which builds things automagically every 2-3 days or so iirc).

Its fixed now.
I followed what was suggested by this redditor on r/voidlinux (https://www.reddit.com/r/voidlinux/comments/mor7n5/comment/h3bd6wh/?utm_source=share&utm_medium=web2x&context=3)
I just had to change WLR_DRM_DEVICES=/dev/dri/card0 to WLR_DRM_DEVICES=/dev/dri/card1
This seems to have fixed the issue.
I will update you if I have any issues.

Its fixed now.
I followed what was suggested by this redditor on r/voidlinux (https://www.reddit.com/r/voidlinux/comments/mor7n5/comment/h3bd6wh/?utm_source=share&utm_medium=web2x&context=3)
I just had to change WLR_DRM_DEVICES=/dev/dri/card0 to WLR_DRM_DEVICES=/dev/dri/card1
This seems to have fixed the issue.
I will update you if I have any issues.

Its fixed now.
I followed what was suggested by this redditor on r/voidlinux (https://www.reddit.com/r/voidlinux/comments/mor7n5/comment/h3bd6wh/?utm_source=share&utm_medium=web2x&context=3)
I just had to change WLR_DRM_DEVICES=/dev/dri/card0 to WLR_DRM_DEVICES=/dev/dri/card1
This seems to have fixed the issue.
I will update you if I have any issues.

Did you confirm if this supports external monitors on optimus laptops?
Or did you simply only use the external monitor by only powering the dgpu?


ENOENT: no such file or directory ./dict.txt

Hello,
If I understand correctly if there's no dict.txt on the current working dir then it should use the libraries' own dict.txt? This works if you have dict.txt on the current directory from where you're launching your script from but fails when it's launched outside of the directory where there's no dict.txt.

Yeah it ought to be using __dirname

:smile: Thanks. I thought that was how it was supposed to work. You're quick!!

happened to catch the email


User notes that many Dickeya genomes are the wrong size when compared to GenBank

We got a user ticket about this, and just talked to Jim and he confirms that this is a problem.  This could be an indication of other problems that we don't know about.

1224148.3       Dickeya chrysanthemi NCPPB 3533
1223569.3       Dickeya chrysanthemi NCPPB 402
1223571.3       Dickeya chrysanthemi NCPPB 516
1224149.3       Dickeya dadantii NCPPB 3537
1223572.3       Dickeya dadantii NCPPB 898
1223574.3       Dickeya dadantii subsp. dadantii NCPPB 2976
1226343.9       Dickeya dianthicola GBBC 2039
1223570.4       Dickeya dianthicola NCPPB 3534
1223568.4       Dickeya dianthicola NCPPB 453
1226344.5       Dickeya solani GBBC 2040
1225786.1       Dickeya solani IPO 2222
1224151.3       Dickeya solani MK10
1224152.3       Dickeya solani MK16
1224144.3       Dickeya sp. CSL RW240
1225785.3       Dickeya sp. DW 0440
1224145.3       Dickeya sp. MK7
568766.3        Dickeya sp. NCPPB 3274
568768.3        Dickeya sp. NCPPB 569
1223567.3       Dickeya zeae CSL RW192
1224153.3       Dickeya zeae MK19
1223573.3       Dickeya zeae NCPPB 2538
1224146.3       Dickeya zeae NCPPB 3531
1224147.4       Dickeya zeae NCPPB 3532

Here are some more:
1223567.3
1223568.4
1223569.3
1223570.4
1223571.3
1223572.3
1223573.3
1223574.3
1224144.3
1224145.3
1224146.3
1224147.4
1224148.3
1224149.3
1224151.3
1224152.3
1224153.3
1225785.3
1225786.3
1226343.9
1226344.5
568766.3
568768.3
999430.4
999431.3
999434.3
1312920.4
1321951.4
1239783.3
139.77
698953.3
1302421.3
1302425.3
1302427.3
1435053.3
1491.410
1491.411
1491.412
1491.413
1491.414
1491.415
1491.416
1491.417
1491.418

I have deleted all Dickeya genomes reported by the user and other bad genomes reported by Jim from the database.
Except Clostridium genomes in Jim's list. Some of them are much longer than other clostrodium genomes. However, they match with corresponding genomes at NCBI. That means the version we have in PATRIC may be a low quality sequence, but it is not corrupted.
The correct version of the deleted genomes will be added soon.
-Maulik

What is the cause of the bad/corrupted sequences?  If we have found
quite a few in the course of testing / doing work, there are likely many
others, due to some systemic problem.
Ron
On 11/19/16 9:14 PM, Maulik Shukla wrote:

I have deleted all Dickeya genomes reported by the user and other bad
genomes reported by Jim from the database.
Except Clostridium genomes in Jim's list. Some of them are much longer
than other clostrodium genomes. However, they match with corresponding
genomes at NCBI. That means the version we have in PATRIC may be a low
quality sequence, but it is not corrupted.
The correct version of the deleted genomes will be added soon.
-Maulik
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PATRIC3/patric3_website/issues/1273#issuecomment-261753534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCnWmio9i0mR3wlwsGOmL7EP0Tj3tssks5q_60OgaJpZM4K0OuX.Web
Bug from
https://github.com/notifications/beacon/ADCnWgTVqWHbryRIMnuWcDDbCLgy0pGZks5q_60OgaJpZM4K0OuX.gif

--
Ron Kenyon
PATRIC Project Manager, patricbrc.org
Project Director, Biocomplexity Institute
Virginia Tech
<EMAIL_ADDRESS>

Ron,
These problematic genomes were reported by Jim as part of the genome QC
matrix he is working on, before they were reported by the users. There were
31 genomes in total (including 23 Dickeya) that were identified to be problematic
and deleted from the database.
Most of these genomes were draft genomes in multiple contigs that got completed
into single chromosomes later. We had both versions merged as a single genome
in the database. This was an artifact from the old data processing workflows
in PATRIC2.
The new workflow for incorporating new genomes relies on NCBI assembly database
and has multiple checks to make sure the same genome doesn’t get loaded multiple
times.
Any time we find a problematic case, I usually run a check on the entire database to find
other similar cases. The same checks are then run periodically.
-Maulik

On Nov 21, 2016, at 6:40 AM, rkenyon<EMAIL_ADDRESS>wrote:
What is the cause of the bad/corrupted sequences? If we have found
quite a few in the course of testing / doing work, there are likely many
others, due to some systemic problem.
Ron
On 11/19/16 9:14 PM, Maulik Shukla wrote:

I have deleted all Dickeya genomes reported by the user and other bad
genomes reported by Jim from the database.
Except Clostridium genomes in Jim's list. Some of them are much longer
than other clostrodium genomes. However, they match with corresponding
genomes at NCBI. That means the version we have in PATRIC may be a low
quality sequence, but it is not corrupted.
The correct version of the deleted genomes will be added soon.
-Maulik
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PATRIC3/patric3_website/issues/1273#issuecomment-261753534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCnWmio9i0mR3wlwsGOmL7EP0Tj3tssks5q_60OgaJpZM4K0OuX.Web
Bug from
https://github.com/notifications/beacon/ADCnWgTVqWHbryRIMnuWcDDbCLgy0pGZks5q_60OgaJpZM4K0OuX.gif

--
Ron Kenyon
PATRIC Project Manager, patricbrc.org
Project Director, Biocomplexity Institute
Virginia Tech
<EMAIL_ADDRESS>—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PATRIC3/patric3_website/issues/1273#issuecomment-261926328, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLd73YNWsmgFaIcM62siS_KfGfj-YOsks5rAZE1gaJpZM4K0OuX.

OK, that makes sense to me.  I had mentioned the issue to Tom during the
business call this morning, so he may inquire about it.
Thanks,
Ron
On 11/21/16 9:09 AM, Maulik Shukla wrote:

Ron,
These problematic genomes were reported by Jim as part of the genome QC
matrix he is working on, before they were reported by the users. There
were
31 genomes in total (including 23 Dickeya) that were identified to be
problematic
and deleted from the database.
Most of these genomes were draft genomes in multiple contigs that got
completed
into single chromosomes later. We had both versions merged as a single
genome
in the database. This was an artifact from the old data processing
workflows
in PATRIC2.
The new workflow for incorporating new genomes relies on NCBI assembly
database
and has multiple checks to make sure the same genome doesn’t get
loaded multiple
times.
Any time we find a problematic case, I usually run a check on the
entire database to find
other similar cases. The same checks are then run periodically.
-Maulik

On Nov 21, 2016, at 6:40 AM, rkenyon<EMAIL_ADDRESS>wrote:
What is the cause of the bad/corrupted sequences? If we have found
quite a few in the course of testing / doing work, there are likely
many
others, due to some systemic problem.
Ron
On 11/19/16 9:14 PM, Maulik Shukla wrote:

I have deleted all Dickeya genomes reported by the user and other bad
genomes reported by Jim from the database.
Except Clostridium genomes in Jim's list. Some of them are much
longer
than other clostrodium genomes. However, they match with
corresponding
genomes at NCBI. That means the version we have in PATRIC may be a
low
quality sequence, but it is not corrupted.
The correct version of the deleted genomes will be added soon.
-Maulik
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

https://github.com/PATRIC3/patric3_website/issues/1273#issuecomment-261753534,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ADCnWmio9i0mR3wlwsGOmL7EP0Tj3tssks5q_60OgaJpZM4K0OuX.Web

Bug from

https://github.com/notifications/beacon/ADCnWgTVqWHbryRIMnuWcDDbCLgy0pGZks5q_60OgaJpZM4K0OuX.gif

--
Ron Kenyon
PATRIC Project Manager, patricbrc.org
Project Director, Biocomplexity Institute
Virginia Tech
<EMAIL_ADDRESS>—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/PATRIC3/patric3_website/issues/1273#issuecomment-261926328,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABLd73YNWsmgFaIcM62siS_KfGfj-YOsks5rAZE1gaJpZM4K0OuX.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/PATRIC3/patric3_website/issues/1273#issuecomment-261947669,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCnWmtE-d-MjuxnlrF4vfJ_YdcTFDmxks5rAaYUgaJpZM4K0OuX.Web
Bug from
https://github.com/notifications/beacon/ADCnWvidFTbuEIY2GT5fcLcFYJY_OKmrks5rAaYUgaJpZM4K0OuX.gif

--
Ron Kenyon
PATRIC Project Manager, patricbrc.org
Project Director, Biocomplexity Institute
Virginia Tech
<EMAIL_ADDRESS>


Cannot open some builds "Unknown Passive Tree Version"

I got this message:
"The builds you are trying to load uses an unrecognised version of the passive tree skill. You may need to update the program before loading this build"
The program is already updated.
The version tree was the previous heist league

Hi with the last update now i have no more this problem 👍

Hi with the last update now i have no more this problem 👍


Jump to definition

New feature: Provide a 'jump-to-definition' functionality for functions, methods and classes.

Implemented in our code base with the dumb-jump package.
Works fine for functions but fails with methods at the moment.
Closing for now as this is mostly resolved on our side.
(use-package dumb-jump
  :config
  (add-to-list
   'dumb-jump-language-file-exts
   '(:language "javascript" :ext "pjs" :agtype "js" :rgtype "js"))
  (add-to-list
   'dumb-jump-language-file-exts
   '(:language "javascript" :ext "ojs" :agtype "js" :rgtype "js")))


Could you release the dataset of re10k of generate_point_cloud_figure？

Thank you for your amazing job
Could you release the dataset of re10k of generate_point_cloud_figure.py？ (2c52d9d606a3ece2, 71a1121f817eb913, d70fc3bef87bffc1, f0feab036acd7195, a93d9d0fd69071aa, which are not in sub_re10k)
Thank you!

I've compiled a subset of the dataset that includes all of the scenes referenced in generate_point_cloud_figure.py. You can find it with the rest of the datasets here. As a reminder, feel free to send us an email if you want the full processed dataset!


Cannot sign-up with email on https://appget.net/

"Network Error" is displayed underneath the email field.

should be fixed :)

Thank you Keivan! Confirmed :)