Revert "net: tcp: Fix possible deadlock in tcp_conn_unref()"

Reverts zephyrproject-rtos/zephyr#42526
As I am testing this change, it seems that the net_ctx is getting leaked. So it seems it may not be the rightway to unlock the tcp_lock.
I would like to consider the option of manipulating ctx->cond.lock lock. For example get rid of (void)k_mutex_lock(ctx->cond.lock, K_FOREVER); in static void zsock_received_cb(). How do u feel about that? Because it seems to work better than the other way

you need a signoff in the commit message.

I would like to consider the option of manipulating ctx->cond.lock lock. For example get rid of (void)k_mutex_lock(ctx->cond.lock, K_FOREVER); in static void zsock_received_cb().

I don't think we should remove that mutex protection - it was added for a reason, removing it could lead to other issues with recv queue handling in the socket/net_context.
I'm thinking about the tcp_conn_unref() function - it seems to lock the mutex first, and only after that it decrements the ref count with  atomic_dec() (which should be safe w/o a mutex protection) and check if it actually needs to release the tcp context (and this part should be protected by the mutex in my understanding).
Maybe a good solution would be to move this check before the mutex lock - only one thread should attempt to lock the tcp mutex then, therefore preventing the deadlock. It's implemented in a similar way in net_context (https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/ip/net_context.c#L361).

CC @jukkar

Thanks @rlubos , that sounds reasonable. I will take a look at that

hi,
@rlubos's suggestions led me to implement the tcp_conn_unref() similary to https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/ip/net_context.c#L361, which definitely helped and revealed the hanging lock in the sockets.
There is a condition variable ctx->cond.recv which I assume is being used as a replacement to Events, but the k_condvar_wait() reaquires the lock after the wait is finished and the lock was never released which was the other reason why could tcp stack's rx_q thread be locked infinitely, hence the added k_mutex_unlock() call.

@neja20 you don't need to close the PR, just force-push to your branch instead.

@carlescufi I am sorry, I might be using git the wrong way. I will find a way to do this properly next time.

@carlescufi I am sorry, I might be using git the wrong way. I will find a way to do this properly next time.

The usual workflow is:
<make changes>
$ git add
$ git commit --amend
$ git push --force


test: synchronizing spec

What
ECS logging specs automatic sync
Why
Manually forced with the CI automation job.

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Build Cause: Pull request #132 opened

Start Time: 2021-02-05T10:53:30.006+0000

Duration: 12 min 38 sec

Commit: e802afdee90a591bf54730a8d34da3f670d9fa21

Test stats :test_tube:

Test
Results

Failed
0

Passed
70

Skipped
4

Total
74


Versioning strategy

The longer this project exists, the more difficult it becomes to keep the project in sync with existing customize-cra versions.
As an example<EMAIL_ADDRESS>now uses<EMAIL_ADDRESS>which requires a breaking change in the implementation of style loaders because modules is now an object rather than a boolean flag.
How can we best manage versions to support these diverging configuration requirements while allowing users to easily know which version to use for their project?
My initial thought is to stop using semver and mirror the customize-cra versions to the equivalent create-react-app version, e.g. the version of customize-cra that supports the new css-loader changes in<EMAIL_ADDRESS>would be<EMAIL_ADDRESS>I could use some feedback on this though. I'm not sure how to best manage this type of complexity when we're entirely dependent on an upstream project.
cc: @FezVrasta

With your proposed solution, how would you handle new features/fixes releases that target the same CRA version? Would you always use the minor version for this? (0.0.x)

Yeah, I think that'd be the plan. X.Y.Z where X & Y mirror create-react-app and then Z is for our own versioning. I've seen this pattern in the wild before, I'll see if I can find some examples.


Galaxy Hub tutorials: The Roadmap

All:
I have been creating a series of tutorials focused on usegalaxy.org that are hosted on galaxy-hub. They are heavily based on content within this repository. My intention with these are:

[ ] get a set of polished main-specific tutorials
[ ] make sure usegalaxy.org tool set is in good shape (tutorials can be run on main successfully)
[ ] move them from hub into this site once @dannon has completed syncing its styling with hub
[ ] generalize them by creating docker flavours and cloud-based versions

So far I have done this with RNAseq tutorials developed by @MoHeydarian and @malloryfreeberg (https://github.com/galaxyproject/galaxy-hub/pull/199). The next will be ChIP-seq tutorial from @MoHeydarian and @malloryfreeberg.
The major changes were:

emphasizing collections
using IGV instead on trackster
distributing sample datasets via Galaxy libraries (in addition to Zenodo).

I would greatly appreciate your feedback on these.

Also please look at this event and consider participating. https://docs.google.com/document/d/1dLCL5-2pkWTvmGTz7GyQkb5LEIZ3FBkPvCBoqUPGUOg
@dannon and @tnabtaf will be there and we will work also on the infrastructure of this project.

distributing sample datasets via Galaxy libraries (in addition to Zenodo).

Imho we should describe our training material very unspecific to any Galaxy instance. Datasets should be available via a DOI and we should explain howto download it. In addition we should (as community) come up with a standard way to organise data libraries and add a optional sentence to to the training: "All the needed data for the training material can be found under training_material/foo/bar/version1/". Then all supported Galaxy instances can add themself as supporter of this training (we have metadata for this) but they need to follow this library recommendations.

While I agree that training materials should be ultimately instance agnostic, the current challenge is tool sets - instances can be very different in their toolsets and so it may not be possible to run a given tutorial there

We should fix this and every instance that are listed as "supported instance" will need to have these tools installed - do you have tools that can not be shared?

No, I only use tools from IUC

I fact the main reason I'm putting tutorials to hub is to have a "curated" set where all pieces work. Should we create a curated section in training-materials?

We could define some sorts of training dependencies, we need this as well for the docker image. And if a Galaxy instance do support all of these, we will annotate the training with this instance and provide the link to this instance to the user.

Ideally all training should have this curation here. We just rushed and moved this repo too early to galaxyproject and now we need to clean-up. But I would like to have all trainings here stick to these standards.

I'm not sure the 'supported instance' bit is the best path.  My concern is that it isn't maintainable, both in keeping tutorials here up-to-date, and on the server maintenance side.  How about having some code that can just query a server's API to see where it'll work?  Then a list of 'compatible' servers is always available.

IMO all Galaxy instances should carry the tools that the tutorials of the GTN utilize. These tutorials cover the basic bioinformatic pipelines and use established and vetted tools. If there is a "base list" of Galaxy tools, it should start with the ones in the GTN tutorials.
It isn't realistic to have all public versions of Galaxy carry tools we deem necessary, but we can make sure that at least Main, Test, Cloudman (on AWS and JS), and instances maintained by committers and close friends of the project have this "base list" of tools installed.
I'm still not sold on having a Docker image for each tutorial with the idea that users will be able to successfully: 1) launch the Docker image on their machines and 2) have a machine with the resources to accomplish the tasks in the tutorial.

@nekrut how does using IGV instead of Trackster make this tutorial more Main-centric? Won't this require users to download and launch IGV from their machines? With Trackster users can transfer data from a history to the genome browser view quite seamlessly, or am I missing something?

I do feel like that limits the tutorials we can curate within this repo, and unnecessarily.
What if, as a part of the build process (or some separate on-demand or automated mechanism) were able to generate a matrix of which tutorials worked on which servers, given a list of servers to query?  This should be fairly straightforward to implement, as long as we can annotate tutorial requirements expressively enough.  I'd imagine we could also, for UI features, require particular versions, which we can verify via the API.
It'd have the added benefits of allowing us to easily add more public servers, and also ensure servers remain compatible.

Hi all,
IMO some Galaxy instances don't have NGS related tools as some are related to proteomics, bioimaging and others... and maybe there will be GTN tutorials on these topics in the future...
Moreover I think that Docker can be something more usable by Biologists in thé future... Testing Galaxy flavors through kitematic for Windows since months give me some hope that this can be reachable...
In the meantime, I'm agree that making all tutorials usable from usegalaxy.org is a very good thing.
Finally, concerning IGV, I personally always prefer showing mapping results and others through Trackster because it works easily on every Galaxy instance...

I completely agree with @yvanlebras we should not limit the scope of Galaxy training. People currently developing material for literature mining and metabolomics and I'm not sure usegalaxy.org wants to have this. Moreover, the Docker setup will maybe power soon the backend of Cloudman. And I have discussed ideas with @afgane to lunch all these training instances from cloudlaunch. There is no much potential in this training - we just need to get the things together.
@dannon I completely agree. We can test the the annotated servers and maintain a list. Vice versa I see the docker-directory also as a good way to ease the way for admins to install all all necessary bits to support one tutorial. E.g. the tool yaml file, the populate data-library scripts etc can all be run in a cron job if needed to keep up-to-date.

Hi @nekrut ,
As I will give a RNAseq training session at the end of the week, I have tested your (so beautifull) tuto! Here are some comments, I hope some are of interest...

Maybe you can propose a history name like "RNAseq training : Finding and quantifying new transcripts" for those who are not inspired
Concerning the Filter SAM or BAM step after HISAT, we don't see the choosen parameter for "select the output format". Maybe not of interest, but maybe some users will ask the question....
Concerning the creation of a collection of paired datasets, maybe you can mention that the user have to select "Build List of Dataset Pairs"
Typo on the trimmomatic section: "labeled as unpaired; we one we" instead of "labeled as unpaired; the one we" I guess
Concerning the "Filter SAM or BAM", once again, it will be of interest specifying for others paramters if we have to choose default.
Using the "Filter data on any column" tool with "c7<0.05", I found 127 transcripts when you find 128, I lost! ;)
Typo megakarycyte instead of megakaryocytes (paragraph after the "Joining filtered DeSeq2 output" step.
Instead of having "MSTRG.977.1" and "MSTRG.78.1" in the joined file, I have "MSTRG.976.1" and "MSTRG.77.1".. this looks like there is a "-1" applied on the GeneID.. An update of the db ? A mistake I made ?

Moreover, I'm not sure about the strands of the reads compared to the Refseq genes... Obiously, using Trackster, if I don't make a mistake, it appears that we have, by pairs, first (left) sens reads then (right) antisens reads... and the Hoxb13 RefSeq gene is oriented from left to right. So this seems to indicate a FR library type, not a RF one? When we look at the original article, they also proposed FR:
were sequenced on the Illumina HiSeq 2000 to obtain 2*99-nucleotide paired-end reads. All samples were determined as biological replicates. RNA-seq reads were mapped using TopHat2 in a reference-assisted manner (Trapnell et al. 2009;
Kim et al. 2013; Paralkar et al. 2014). We used Cuffdiff2 (Trapnell et al. 2013) to identify DE genes, using the following options: dispersion-method=per-condition, library-type= fr-firststrand, max-bundle-frags = 20000000, min-reps-for-js-test =2, -b for bias correction, and –M to mask globin transcripts."

Here are my History (https://usegalaxy.org/u/ylebras/h/rnaseq-training--finding-and-quantifying-new-transcripts-rnaseq) and the related Trackster visu: https://usegalaxy.org/u/ylebras/v/rnaseq-tuto-de

@yvanlebras Thank you! I'm about to make another pass (one @davebx merges gffcompare in) and I'll fix things you have noticed.

(G4) Would be nice to use training-materials repo for all content management to avoid duplication, but publish to galaxyproject.org.

Galaxy-training should have it's own website, hub should embed it - or is the search enough?
Summary page in the Hub linking out to the training?

training.galaxyproject.org (proposed) or galaxyproject.org/tutorials (current) doesn't make a difference to me, as long as we render it all with the same infrastructure/processes so we can share efforts there and look&feel.

This is mostly all complete with the usegalaxy.* efforts and our workflow testing. Thanks everyone!


bugfix-select-and-move-shape-when-nofil-only-stroke

When a shape is drawn with stroke and no-fill, the selection tool doesn't work as expected. You have to select the border in order to move it.  Ideally selecting anywhere within the shape should enable us to move it.
This thing work when the shape is filled.
Just thought of fixing this as this was a small fix in shape.js.  Instead of checking for fill, always fill the offcanvas to enable
hit testing with shapes (I am not sure of any edge cases of it) but thought of trying and raise a pull request.
In case you think this is good feel free to merge.

Thanks! I made the update you suggested during the stream :-)


Ability to overwrite styles

Would be great to have ability to overwrite various style to customize the control to the L&F of the app. border colors, fonts, highlight colors etc.

You can customize the styles by setting the customStyle prop.
<Calendar
  ...
  customStyle={{day: {fontSize: 15, textAlign: 'center'}}} // Customize any pre-defined styles
/>

The styles that are available for customization are in CalendarIOS.js

Thank you @andykuo


Add Sharaku

Project URL

https://github.com/makomori/Sharaku
Description

Instagram-like image filter ViewController.
Why it should be included to awesome-ios (optional)
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 or later
[x] Supports Swift 3
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Error

:no_entry_sign:
Found 1 link issue

          1 Warning

:warning:
Please update the Pull Request title to contain the library name

Link issue by awesome_bot

Line
Status
Link

754
301
https://github.com/zalando/MapleBacon redirects tohttps://github.com/zalando-incubator/MapleBacon

  Generated by :no_entry_sign: danger

@makomori good work!

@naeemshaikh90 Thanks man!

Thx


Merge "Product" and "Digital" into "Carbon" menu link in the top right switcher menu

Remove the link to "Digital".
Change "Product" to "Carbon".
Add a link to the Digital PAL to his page - https://www.carbondesignsystem.com/community/domain-guidance.

@shinytoyrobots Let’s talk more about this issue with this. The switcher is currently meant to represent the IBM Design Org.
At the top we have IBM Design / Brand Center / IDL / Accessibility which represent the POV and Brand expression regarding design. Under those are the Disciplines and Practices. It currently takes you to the site that represents that design discipline. The flaw in this structure is that Product and Digital are really just one Design system (including PALs via Carbon site) which should really be a merged discipline since both dependent on the same design system (Carbon).
It’s not just a place where links to useful things exist. I also suggest running whatever solution by Todd since he’s close to this and drove this current list of items. It’s definitely not right as is but the solution will include other updates/considerations within the sites. i.e adding an About on IDL left nav, adding a large card at the top of IDL to aim to Carbon, updating the switcher, finessing language and clarity in Carbon site, etc. All of these need to be addressed together.

The app switcher panel content has changed since this issue was originally opened. Is the current content structure in a good place?


[FAQ] How to add alias with | pipe?

Hi, i want to know if there is a way to add commands like: "pacman -Q | fzf".
When i add this as a normal alias it return:

I don't know too much about lua. Sorry if i'm a dumb!

Oh. Ignore it.
I'll fix adding this: "sh -c 'pacman -Q | fzf'"

this was a problem with how hilbish and the sh interpreter work interactively. i just expanded the alias before going to the sh runner now, so it is fixed.
note that this still not work if you want to pipe to/from the alias (that never worked)

fyi before i fixed it you could have aliased to hilbish.runner.sh "<command here>" and that would be faster and less overhead

fyi before i fixed it you could have aliased to hilbish.runner.sh "<command here>" and that would be faster and less overhead

Amazing!!! I will check it now. Thx u


koji_import tries to read media-types from pulp_pull in exit plugins first, then worker annotations

Please re-base against master to fix stickler-ci.

Fix for unreleased bug, so no release notes update needed.


[gamenetworkingsockets] update to 1.3.0

What does your PR fix?
Fixes #18312

Which triplets are supported/not supported? Have you updated the CI baseline?
Same with previous version

Does your PR follow the maintainer guide?

Yes

Is the usage of vcpkg_fixup_pkgconfig correct without any arguments? I've checked the buildtrees of gamenetworkingsockets and couldn't find and .pc files.

Is the usage of vcpkg_fixup_pkgconfig correct without any arguments? I've checked the buildtrees of gamenetworkingsockets and couldn't find and .pc files.

This is the official reference document of vcpkg_fixup_pkgconfig. You can refer to it. I found the .pc file in the buildtrees of gamenetworkingsockets before. I have re-run CI, and I will check it again after running.

Is the usage of vcpkg_fixup_pkgconfig correct without any arguments? I've checked the buildtrees of gamenetworkingsockets and couldn't find and .pc files.

This is the official reference document of vcpkg_fixup_pkgconfig. You can refer to it. I found the .pc file in the buildtrees of gamenetworkingsockets before. I have re-run CI, and I will check it again after running.

After rerun, I also tested locally and did not find the .pc file, the files below it are all correct

Cool, thanks @aizuon!


🚀 Feature: Option to only unified the file without compression

🔖 Feature description
Control the compression level to reduce resource usage: pay bigger on storage to pay less in CPU.
This can be done only with .env for compression level, example: COMPRESSION_LEVEL on:
https://github.com/stonith404/pingvin-share/blob/46305ed1881fcebbd8e868ebe7b67bd6e6d16ddc/backend/src/share/share.service.ts#L107
🎤 Pitch
On have compressed files maybe don't make sense use compression, like images, videos or others correlated formats.

Yes this is quite an exciting feature, it would be useful to change the compression rate, we would need to add a new field in the db, and then add another input field in the frontend with a Native Select Input.

Yes this is quite an exciting feature, it would be useful to change the compression rate, we would need to add a new field in the db, and then add another input field in the frontend with a Native Select Input.

I think initially can be done with a env var used in docker

Well, not everyone use docker, and it'll be easier to change it directly in the config panel. It's not really a big change, but it requires time

Well, not everyone use docker, and it'll be easier to change it directly in the config panel. It's not really a big change, but it requires time

Exactly and additionally we shouldn't mix config variables that are configurable through the frontend with environment variables. It could lead to confused users that don't know where to change these settings.

Well, not everyone use docker, and it'll be easier to change it directly in the config panel. It's not really a big change, but it requires time

Exactly and additionally we shouldn't mix config variables that are configurable through the frontend with environment variables. It could lead to confused users that don't know where to change these settings.

This maybe can be splited in two tasks, one for the environment variables and another to use the frontend.

Don't you think an input field in the website settings is enough ?

Don't you think an input field in the website settings is enough ?

I think its, 0 for compression level means 'only agregate' like *.tar and should work fine for most users, so no more further advanced options.

Released :)


Make ujson opt-in

Since https://github.com/tomchristie/apistar/pull/99 was merged, I think it would be a good idea to remove ujson as a required dependency (i.e. part of install_requires). It's not really optional if I have to manually uninstall it post-install.
I'm just not a big fan of forcing dependencies for stuff the standard library already covers (and does so well). Especially a C/C++ dependency. Apparently it's not even a drop-in replacement[1]. Seg-faults are also nice[2].
Maybe using extras_require in setup.py would be a good middle ground, and mention it in the documentation somewhere...?
setup(
    name='apistar',
    ...
    extras_require={
        'maxspeed': ['ujson', 'uvloop'],  # I just mentioned uvloop because of issue #9
    },
)

$ pip3 install apistar[maxspeed]

What do you think?
[1] https://github.com/esnme/ultrajson/issues/252
[2] https://github.com/esnme/ultrajson/issues/258

I absolutely want a minimal install option, yes.
That extends to other packages as well as ujson (eg. we'll probably install Jinja2 by default, but it'd be nice to have an option that avoids that)
I don't want this to be too granular, we should just have "the standard install" and "a minimal install - probably just werkzeug and click, and install whatever else you happen to need.
My problem with extras_require is that I'd really like the standard install to be a wider set of packages, and the optional install case to be the minimal variant. We could have pip install apistar[standard] but it feels a bit weird.
This environment variable based approach might also work?... https://github.com/channelcat/sanic/blob/master/setup.py#L50

What if it stops the install though?
Building wheels for collected packages: apistar, coreapi, ujson, itypes, MarkupSafe
  Running setup.py bdist_wheel for apistar ... done
  Stored in directory: /home/w-daspdp/.cache/pip/wheels/24/89/fc/1a7ad4e150a8cb87641d47aa02e0c27813840ea4711512e8dc
  Running setup.py bdist_wheel for coreapi ... done
  Stored in directory: /home/w-daspdp/.cache/pip/wheels/37/03/ff/1ad3d35cb205faedfb91b8ada05c11970be690e1a0ea1058c5
  Running setup.py bdist_wheel for ujson ... error
  Complete output from command /home/w-daspdp/.virtualenvs/pdp_stage/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-XG4ov5/ujson/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmpxbZpI9pip-wheel- --python-tag cp27:
  running bdist_wheel
  running build
  running build_ext
  building 'ujson' extension
  creating build
  creating build/temp.linux-x86_64-2.7
  creating build/temp.linux-x86_64-2.7/python
  creating build/temp.linux-x86_64-2.7/lib
  gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I./python -I./lib -I/usr/include/python2.7 -c ./python/ujson.c -o build/temp.linux-x86_64-2.7/./python/ujson.o -D_GNU_SOURCE
  unable to execute gcc: No such file or directory
  error: command 'gcc' failed with exit status 1

  ----------------------------------------
  Failed building wheel for ujson

The ujson as part of the required install forces the installing machine to have gcc, at least in my case, I don't have access to it (RHEL 7) because sysadmins don't want developers compiling anything they want on their servers.

Thanks for the reply. Standard and minimal sounds like a good approach. I'm just not sure how the minimal installation is supposed to work if the standard installation is the default? Would it just be something like this?
$ pip3 install --no-deps apistar
$ pip3 install click werkzeug

But that's also two steps, might as well just do pip3 install apistar && pip3 uninstall usjon then. But perhaps pip install apistar[full] instead of pip install apistar[standard] sounds better?

I'm also not a huge fan of relying on environment variables to determine how a Python package gets installed.

Yeah fair point really.

But perhaps pip install apistar[full] instead of pip install apistar[standard] sounds better?

I like this, yup.

I wish there was a way that if a pip install failed to build a C/C++ it would fall back, like part of the standard install but if it fails its considered optional.
I hate to have apistar[full] just because some developers have awful setups, but I can't think of a better way to do it.

Perhaps people who can't / don't want ujson can have a different install path, e.g. apistar[purepy] where all c/c++ deps are excluded and for everyone else it is just the normal install

I hate to have apistar[full] just because some developers have awful setups, but I can't think of a better way to do it.

For me it's not so much that my setup is awful, it's that I really don't want to use ujson for various reasons.

Perhaps people who can't / don't want ujson can have a different install path, e.g. apistar[purepy] where all c/c++ deps are excluded and for everyone else it is just the normal install

The problem is that extras_require is exactly what its name suggests, extra stuff, not less. So using it to install less stuff than the normal install procedure isn't possible.
There's only three possible solutions as I see it:

pip install apistar installs the bare minimum required to run apistar (i.e. no ujson). And document somewhere that it's possible to manually install some stuff for a faster experience (basically just suggest adding ujson to your own requirements.txt).
Same as but offer a apistar[full] variant as well.
Use environment variables as conditionals as sanic does. I personally don't like this approach.
Install everything by default like it's done today and make it the user's problem if they don't happen to have gcc available or otherwise don't want all dependencies.

I guess 1 and 2 can (and perhaps should?) be combined.

Maintain two different packages on PyPi, one "lite" version, and one regular.

I really see no reason not to go with 2.
This isn't just about ujson. Stuff like templating and (later) static file support are things we'd want in '[full]' but not in the base install.

Let's start by just dropping ujson, and forcing it to be an explicit install of the user wants it. Docs could mention it in the performance section.


⚠ Hartman Foundation has degraded performance

In 084552d, Hartman Foundation (https://gordonhartman.com/) experienced degraded performance:

HTTP code: 200
Response time: 3812 ms

Resolved: Hartman Foundation performance has improved in e35b3be.

Resolved: Hartman Foundation performance has improved in e35b3be.


(feat): upgrade view configs to use 0.0.34 data

Background
Upgrades view configs to use new data.
Change List

Change view config data versions
Use new settings as in https://github.com/vitessce/vitessce-python/pull/211

Checklist

[ ] Ensure PR works with all demos on the dev.vitessce.io homepage
[ ] Open (draft) PR's into vitessce-python and vitessce-r if this is a release PR
[ ] Documentation added or updated

It appears cellxgene changed obs/ethnicity to obs/self_reported_ethnicity in the anndata object

ah ok @keller-mark I haven't gotten test these out yet completely, but if you approve, I'll have a look and we can get this in if you want.

I tested them out (tried clicking a gene/feature in every demo that was modified in the PR) but don't think we necessarily need to rush to get them in before #1365

Yeah so kuppe has a broken gene (at least one) for ATAC: AC138969.4

Ok yes I will need to re-generate kuppe with a shared var index as well.

.


CLI default output is too verbose

Executing either ng or ng --help outputs the entire list of possible commands + their options. This can be very overwhelming.
Is that something we want to trim down a little bit?
For example, git gives us a nice little overview of the most commonly used commands. I think this is a good way to handle this.
usage: git [--version] [--help] [-C <path>] [-c name=value]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]

The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find by binary search the change that introduced a bug
   branch     List, create, or delete branches
   checkout   Checkout a branch or paths to the working tree
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, commit and working tree, etc
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty Git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories together
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and integrate with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete or verify a tag object signed with GPG

'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.

This comes from ember-cli at the moment. It has a mechanism were it lists all commands from itself and addons.
I don't think it's feasible to change it right now but I also got scared when I ran ng --help three days ago, so yeah. Very verbose.

@filipesilva so, do we want to discuss this and maybe determine what subset of commands ng-cli should display by default?

I think it should be discussed, but while keeping in mind it is hard to change right now. Overwriting the current one will drop support for addons. We're moving away from them right now but want to revisit after ng-conf.
Discussion wise... I think all commands the CLI supports should be there, but without the flags. And that ng help command-name should show the flags.

We can override this command as we are overriding some others already. I think it's not so hard to change it.

I went to check and there is actually an option to set help verbosity in ember-cli... which doesn't seem to be used. Maybe it's actually a bug.

It could be a bug, yes. If we decided to override this command it actually provides availability for json output with the --json flag which can be used to prettify the output.

Checked ember-cli itself, and --verbose is working. It makes stuff even more verbose though.

As we are fully concentrated on the alpha release, ng help will remain unchanged until ng-conf. There's a plan to clean up everything inherited from ember-cli in the future, after the release.
Closing this.


MGMT-15507: Set restricted list of approvers for protected release-ocm-2.9 branch

/cc @gamli75 @filanov

/cc @osherdp


Allow for multiple backends

Currently we only generate a single backend for a given futhark file, but there is nothing that should make it impossible to generate multiple. At the moment it will not work since we use features but that will be resolved by #31.
So to bring this change to frutition we need to have different names for each backend and then be able to select which to link and use at compile time in the generated project.

Hi @SafariMonkey, I can see that you have done this on your own fork. Would you be willing to try and upstream it with the new Enum style selection implemented in #31?


installation: extension should not provide config  entrypoint

Package version (if known):
Describe the bug
A config entry point was added to Invenio-Accounts:
[2021-05-20 22:18:32,819] DEBUG in entrypoint: Loading config for entry point invenio_accounts = invenio_accounts.config

https://github.com/inveniosoftware/invenio-accounts/blob/master/setup.py#L127-L129
Additional context
An Invenio module should load config through the extension and not through a config entrypoint. Otherwise it's not possible to properly override the configuration in an Invenio instance.

Discussed changes with @max-moser:

remove the config entrypoints from both modules
document better the config vars, explaining that have to be set in the final app
change the rdm cookiecutter instance to add such config vars

Fixed here:

https://github.com/inveniosoftware/invenio-accounts/pull/371
https://github.com/inveniosoftware/invenio-oauthclient/pull/253


Extension reinstalled but it's not running

I've reinstalled the extension but it doesn't seem to be running.
I have a pod.yaml file that reads // kind: P // it is supposed to show a pop up next to the P that shows 'Kubernetes Pod' but instead nothing happens.

error

Hi @codereyes-1 , if you have an empty file do you see a list of suggestions like Kubernetes: ....?


Can't build in VS 2015

The Menge code base isn't compatible with Visual Studio 2015.  This is a known problem that comes down both to compilation as well as linker problems.

Is this problem related to the osx linker problems?

  I won't be able to get to this until this evening/afternoon (Pacific Coast Time).  If you have a chance to play with it now, I'd appreciate hearing how it goes.

can someone replace the not working Libpng libs with working ones. I am compiling x64.

I've got a work in progress here: https://github.com/curds01/Menge/tree/vs2015
I've been able to build and run with a 32-bit build.  I don't quite have a 64-bit build running.  I have to handle 64-bit SDL (that may require moving from SDL 1.2 to SDL 2.0).


Error in build

Hello,
I cannot build android after installing this plugin

Error: /Users/Documents/testing/test/MobileV2/platforms/android/gradlew: Command failed with exit code 1 Error output:
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
/Users/Documents/testing/test/MobileV2/platforms/android/src/com/adrianodigiovanni/permission/CDVPermission.java:16: error: diamond operator is not supported in -source 1.6
private SparseArray mCallbackContexts = new SparseArray<>();
^
(use -source 7 or higher to enable diamond operator)
/Users/Documents/testing/test/MobileV2/platforms/android/src/com/adrianodigiovanni/permission/CDVPermission.java:21: error: lambda expressions are not supported in -source 1.6
cordova.getThreadPool().execute(() -> {
^
(use -source 8 or higher to enable lambda expressions)
2 errors
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':compileReleaseJavaWithJavac'.

Compilation failed; see the compiler error output for details.

I think the error is you are using JAVA 6 to build codes in the JAVA 7 or higher version.

Thanks..
Thank you for the plugin...


how to add a http video stream

I use the app "IPCamera - high-end networkcam" which works very easy and fine for the purpose I need. But I would like to add the stream to Homekit.
I hoped to use via this plugin on Homebridge which also works fine for me.
But I don't get a http://ip-address stream working.
Can somebody help me how to add it in the config.
I tried this:
{     "name": "Camera FFmpeg",     "cameras": [         {             "name": "Nestkastje",             "model": "iPhone SE",             "unbridge": true,             "videoConfig": {                 "source": "-i http://<IP_ADDRESS>/",                 "stillImageSource": "-i http://<IP_ADDRESS>/",                 "maxWidth": 0,                 "maxHeight": 0,                 "maxFPS": 0,                 "audio": false             }         }     ],     "platform": "Camera-ffmpeg" }
but with no succes, and errors in the logs of homebridge:
[07/02/2024, 00:25:05] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:25:14] [Camera FFmpeg] [Nestkastje] Starting video stream: native x native, native fps, 802 kbps
[07/02/2024, 00:25:15] [Camera FFmpeg] [Nestkastje] FFmpeg exited with code: 1 and signal: null (Error)
[07/02/2024, 00:25:15] [Camera FFmpeg] [Nestkastje] Stopped video stream.
[07/02/2024, 00:26:01] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:27:42] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:29:23] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:31:04] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:31:33] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:31:35] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:32:45] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:34:26] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:36:07] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
[07/02/2024, 00:37:48] [Camera FFmpeg] [Nestkastje] Failed to fetch snapshot.
[Nestkastje 6769] Snapshot request handler provided empty image buffer!
Thanks!

@PvdGulik:  I'm not sure what you mean.  This plugin is for working with Nest devices in HomeKit apps.  It does not expose any HTTP endpoints for viewing camera streams.

Closing as this does not appear to be an issue with this plugin.


Add support for easily converting GeoPandas objects to geojson

Really handy for Polygon visualizations which can be created with a single line from a GeoPandas GeoDataFrame
What I did (feel free to comment, it's not a finely polished solution):

Changed df_to_geojson into a generic _to_geojson
Added df_to_geojson and gdf_to_geojson wrappers

Oh, didn't realize the contributing guidelines state I should create a new branch. Hope this doesn't make a mess. If needed I can close and re-create...

@zoharby thanks for the PR!
Would this simpler solution work well for your use case?  https://github.com/mapbox/mapboxgl-jupyter/issues/66#issuecomment-377607459
I think we could just perform this is_gf_a_geodataframe check on the df variable passed to the df_to_geojson function.  If it is, use the logic in the comment above to convert the geodataframe to geojson.  If the filename option is present, save the output to a file.  Otherwise, return the geojson-format python dictionary.

Right, I completely missed this much simpler solution...
Will try to make a new PR based on this approach

Issued a new PR #122 based on the mentioned solution. Closing this one.


[spaceship] Adding missing method to fetch build IDs for beta group

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context
Implementing the following missing TestFlight/Beta Groups endpoint to fetch build IDs for a beta group: https://developer.apple.com/documentation/appstoreconnectapi/get_all_build_ids_in_a_beta_group

Is there any reason why the existing get_builds_for_beta_group(group_id: group_is).map(&:id) couldn't be used instead?

So, we were using that call initially and experienced pretty significant performance/slowness issues (very heavy TestFlight presence). We tried calling this other endpoint instead, and it was noticeably quicker. No formal benchmarking, happy to do more and share here if you prefer?

So its not actually returning an array of build ids but partial models

This didn't even occur to me. I suppose the naming becomes a bit imprecise 🙈 Hmm...

@gsavit Ahhh, yeah yeah, it makes sense that doing the other way would be slower! I'm not really sure this new method belongs in the way that it's currently implemented.
I think we either need to think of a new way to do this so it doesn't create an array of partial models or... maybe you can continue just hitting this endpoint directly in your implementation? 🤷♂

@joshdholtz that's fair enough! We'll try hitting the endpoint directly for now, will close this and revisit later on if needed. Thanks for the consideration!


Change language

how do i make turkish language

Set language to tr-TR

I couldn't do it, is there a detailed video of it?


[Fix included] GoogleMaps.java getLicenseInfo() not working before initializing the map

GoogleMaps.java
line 218:
if (("getMap".equals(action) == false && "isAvailable".equals(action) == false ) && [...]){ ... }
The above causes the plugin to reject the getLicenseInfo action if the map plugin has not been initialized. This action does not require initializing the map in order to display the License Information.
The fix is quite simple:
line 218:
if (("getMap".equals(action) == false && "isAvailable".equals(action) == false && "getLicenseInfo".equals(action) == false) && [...]){...}
I've tested this on my application on my Android device (Verizon Motorola Droid Mini) and it works. This problem does not seem to exist on the ios part of this plugin.
The application I am developing doesn't load a googlemap as the first screen. I also have the licensing info somewhere else in the application that doesn't require creating a google map screen initially. Please put this fix in for others who need this functionality in order to satisfy the terms of use.
You may need to  review other commands that could have this same issue.
Thank you!

Thank you @jpcancienne
I patched it on the test branch, and it will include in the next release.

Can you explain how you used this function, because I'm using v1.2.5 and when i try to call this function from plugin.google.maps.Map.getLicenseInfo() it is undefined?
I only use the map in one of my tabs so it is not always initialized either.

via:
https://github.com/wf9a5m75/phonegap-googlemaps-plugin/wiki/Map.getLicenseInfo()
plugin.google.maps.Map.getLicenseInfo(function(txt1,txt2){
    var textToUse = txt1 || txt2;
    //show the information
});

Remember that this is a native function, so you need to use a callback javascript function.

worked like a charm, thanks!


Add How many network printers can DRA support? FAQ

Information garnered from the Platform Update 12 (Nov 2017) document:
https://docs.microsoft.com/en-us/dynamics365/unified-operations/fin-and-ops/get-started/whats-new-platform-update-12#reporting-document-routing-agent-scale-improvements
Thanks for contributing
Please describe the changes that you recommend that we make, and why. If you have any issues with formatting, please see the CONTRIBUTING file, or just submit the change, and we'll be happy to help. The content publishing team for Microsoft Dynamics 365 for Finance and Operations team will review your pull request, and be in touch.

TJ is the PM for this area.  He is on vacation, but I've added him as a reviewer so that he can review the change when he gets back.

Updated based on review with TJ yesterday.


Still cannot reproduce the results using the released model

Similar to #5, I still cannot reproduce the results using the released model and the results I got were extremely poor.
{"r_precision": {"top-1": 0.06051829268292683, "top-2": 0.1298780487804878, "top-3": 0.19603658536585367}, "fid": 1481.7516534444785, "clip_score": {"clip_score": 0.14643903637110403}, "mid": -53.25080871582031}
I had installed pytorch-lightning and transformers with correct versions ( 1.8.6 and 4.19.2). I tested the released model on GTX 1080Ti using the command python test.py model=diffusion_hml3d.yaml datamodule=humanml3d.yaml ckpt_path=pretrained/flame_hml3d_bc.ckpt.  I reproduced the close numbers to the benchmark on the paper, so there might be a difference in testing files. All testing samples should be generated from test.py to reproduce the result.

The number of files in generated_samples is 6559 (hml3d). The testing samples were generated from test.py. There is no random operation in test.py and I am confused about why there is a difference in testing files.

@ToBeCodeCreater From my side, I have 6,557 test samples and generated results from running test.py. I know it takes some time in the testing stage, but can you try it again? Sorry for the inconvenience but I have made two clean containers and set up the repository from scratch and got similar numbers from the paper.

@jihoonerd I had tested the released model three times and got similar results. I'm wondering what the problem is causing this result. The size of testing data in HumanML3D/processed/test_data is 6557 and the size of training data in HumanML3D/processed/train_data is 34936.

I find that the model trained using this repository performs well on testing dataset ( got similar numbers from the paper). But the results of the released model are very poor. Very confusing.

I also got similar results when I use the pretrained weight (for HumanML3D). It will be thankful if the authors check whether the pretrained weight has some problem or not.


migrate to remote plugins for buf

https://buf.build/docs/migration-guides/migrate-remote-generation-alpha
The alpha packages are hosted on go.buf.build which no longer as a valid certificate. Following the steps outlined in the guide above, we can just switch the package to the new remote plugin system

I have read the CLA Document and I hereby sign the CLA

This change looks good to me, but the commit message/PR title is misleading.
We use local buf plugins explicitly for the because remote plugins are built with different compiler versions at different times. This breaks reproducibility in our build process, so we keep all versions pinned with local plugins. See here: https://github.com/authzed/spicedb/blob/main/buf.gen.yaml
This change is changing one place where we don't care about versions (because the Prometheus remote write API is standardized and very much so unchanged), so we just import the module from the BSR.
Maybe we could reword it something like
"update prometheuspb module to new upstream domain"

makes sense, I made some changes and took the suggestion for the title

Can you edit the commit message too?


04/23/2018 18:33 : Create Pull Request for branch master -> prTesting1_2018042318

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


rawgit.com

This site hosts user generated content from github, blocking it blocks a lot of of legitimate things in addition to any potential mining scripts.

Hmm odd it is in the Block list. I'm removing it. Thanks for pointing it out!


Add runtime files for HCL and Terraform

Thanks. I include it. Next time, can you please use a one commit per language?


nimble/host: Allow setting adv data when advertising

Not sure why this was not allowed, but it is perfectly ok to do so and
controller will update data while advertising. And even if for some
reason it won't, there will be proper error returned.

@ccollins476ad I see that you added these checks in 3890be32 so let me know if there was any issue with this as updating advertising data while advertising works perfectly fine for me.


Extremely high GC pause times on Node 12

This could also be a regression in Node, but anyhow, here's a reduced test case of behavior I've observed. All test have been run on a Macbook Pro running macOS Catalina.
const libxml = require("libxmljs");

const xml =
  '<?xml version="1.0" encoding="utf-8" ?>' +
  "<root>" +
  new Array(10000)
    .fill()
    .map(() => "<element />")
    .join() +
  "</root>";

while (true) {
  libxml.parseXml(xml);
}

If I run this script on Node 11.15.0, 10.16.3 or 8.16.1 (with --trace-gc enabled), everything works as expected. Mark-sweep operations take approximately 10 milliseconds each.
$ node --trace-gc test.js
[55391:0x102849000]      521 ms: Mark-sweep 5.5 (11.2) -> 4.2 (11.2) MB, 94.0 / 92.9 ms  (+ 11.1 ms in 40042 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 120 ms) (average mu = 1.000, current mu = 1.000) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]      774 ms: Mark-sweep 4.2 (11.2) -> 4.1 (11.2) MB, 104.8 / 104.0 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 131 ms) (average mu = 0.578, current mu = 0.578) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     1056 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 117.4 / 116.9 ms  (+ 11.9 ms in 40036 steps since start of marking, biggest step 1.5 ms, walltime since start of marking 147 ms) (average mu = 0.579, current mu = 0.579) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     1302 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 96.1 / 95.6 ms  (+ 11.4 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 123 ms) (average mu = 0.590, current mu = 0.602) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     1562 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 95.8 / 95.1 ms  (+ 13.1 ms in 40036 steps since start of marking, biggest step 2.2 ms, walltime since start of marking 127 ms) (average mu = 0.606, current mu = 0.623) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     1803 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 93.0 / 92.7 ms  (+ 10.7 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 119 ms) (average mu = 0.607, current mu = 0.608) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     2044 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 93.2 / 92.8 ms  (+ 11.2 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 119 ms) (average mu = 0.606, current mu = 0.604) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     2280 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 91.8 / 91.4 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 118 ms) (average mu = 0.606, current mu = 0.605) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     2521 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 93.7 / 93.4 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 120 ms) (average mu = 0.604, current mu = 0.603) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     2756 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 93.1 / 92.7 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.9 ms, walltime since start of marking 119 ms) (average mu = 0.600, current mu = 0.597) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     3003 ms: Mark-sweep 4.1 (11.2) -> 4.1 (11.2) MB, 95.9 / 95.4 ms  (+ 11.1 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 122 ms) (average mu = 0.602, current mu = 0.604) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     3243 ms: Mark-sweep 4.1 (11.2) -> 4.1 (8.2) MB, 93.7 / 93.2 ms  (+ 11.2 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 120 ms) (average mu = 0.602, current mu = 0.601) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     3481 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.5 / 93.0 ms  (+ 11.1 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 120 ms) (average mu = 0.601, current mu = 0.600) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     3716 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.3 / 90.9 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 117 ms) (average mu = 0.602, current mu = 0.604) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     3951 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.3 / 92.8 ms  (+ 11.3 ms in 40036 steps since start of marking, biggest step 2.0 ms, walltime since start of marking 120 ms) (average mu = 0.599, current mu = 0.595) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     4186 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.9 / 91.4 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 118 ms) (average mu = 0.600, current mu = 0.601) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     4419 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.7 / 91.3 ms  (+ 11.2 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 118 ms) (average mu = 0.599, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     4655 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.3 / 92.8 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 119 ms) (average mu = 0.598, current mu = 0.597) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     4889 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.4 / 93.0 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 120 ms) (average mu = 0.596, current mu = 0.595) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     5129 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.0 / 91.6 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 118 ms) (average mu = 0.603, current mu = 0.609) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     5375 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 96.1 / 95.5 ms  (+ 12.6 ms in 40036 steps since start of marking, biggest step 2.9 ms, walltime since start of marking 125 ms) (average mu = 0.600, current mu = 0.597) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     5623 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 96.0 / 95.5 ms  (+ 11.9 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 125 ms) (average mu = 0.603, current mu = 0.606) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     5865 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 89.9 / 89.5 ms  (+ 12.3 ms in 40036 steps since start of marking, biggest step 2.2 ms, walltime since start of marking 118 ms) (average mu = 0.612, current mu = 0.621) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     6103 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.3 / 91.9 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 118 ms) (average mu = 0.608, current mu = 0.604) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     6342 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 96.8 / 96.4 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 123 ms) (average mu = 0.597, current mu = 0.587) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     6575 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.0 / 90.6 ms  (+ 10.7 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 116 ms) (average mu = 0.600, current mu = 0.602) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     6810 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 94.1 / 93.7 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 120 ms) (average mu = 0.596, current mu = 0.593) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     7045 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.8 / 91.3 ms  (+ 11.7 ms in 40036 steps since start of marking, biggest step 2.0 ms, walltime since start of marking 120 ms) (average mu = 0.599, current mu = 0.601) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     7280 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.5 / 92.0 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 119 ms) (average mu = 0.598, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     7517 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 95.5 / 95.0 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 121 ms) (average mu = 0.594, current mu = 0.590) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     7752 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.6 / 93.2 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 119 ms) (average mu = 0.595, current mu = 0.596) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     7987 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.1 / 92.7 ms  (+ 10.7 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 118 ms) (average mu = 0.596, current mu = 0.596) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     8220 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.6 / 92.1 ms  (+ 11.2 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 118 ms) (average mu = 0.595, current mu = 0.595) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     8457 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 94.6 / 94.2 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 120 ms) (average mu = 0.595, current mu = 0.594) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     8691 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.2 / 91.8 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 118 ms) (average mu = 0.596, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     8926 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 94.3 / 93.9 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 120 ms) (average mu = 0.594, current mu = 0.591) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     9165 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.2 / 92.8 ms  (+ 11.1 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 120 ms) (average mu = 0.599, current mu = 0.603) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     9401 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.7 / 92.2 ms  (+ 11.1 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 119 ms) (average mu = 0.599, current mu = 0.600) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     9638 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 96.7 / 96.2 ms  (+ 11.2 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 123 ms) (average mu = 0.592, current mu = 0.585) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]     9873 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.2 / 92.8 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 119 ms) (average mu = 0.594, current mu = 0.596) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    10107 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.1 / 91.7 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 118 ms) (average mu = 0.596, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    10339 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.4 / 91.0 ms  (+ 11.1 ms in 40036 steps since start of marking, biggest step 1.9 ms, walltime since start of marking 117 ms) (average mu = 0.597, current mu = 0.599) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    10575 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 94.3 / 93.9 ms  (+ 11.1 ms in 40036 steps since start of marking, biggest step 2.0 ms, walltime since start of marking 120 ms) (average mu = 0.594, current mu = 0.592) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    10810 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.4 / 92.9 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 119 ms) (average mu = 0.594, current mu = 0.594) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    11047 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 90.7 / 90.2 ms  (+ 12.4 ms in 40036 steps since start of marking, biggest step 2.0 ms, walltime since start of marking 120 ms) (average mu = 0.602, current mu = 0.609) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    11282 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.0 / 92.6 ms  (+ 10.6 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 118 ms) (average mu = 0.600, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    11518 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 94.6 / 94.1 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 121 ms) (average mu = 0.596, current mu = 0.593) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    11752 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 93.5 / 93.0 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 119 ms) (average mu = 0.595, current mu = 0.593) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    11986 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.5 / 92.1 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 118 ms) (average mu = 0.596, current mu = 0.597) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    12217 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.2 / 90.8 ms  (+ 10.9 ms in 40036 steps since start of marking, biggest step 1.7 ms, walltime since start of marking 117 ms) (average mu = 0.597, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    12448 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 91.3 / 91.0 ms  (+ 11.0 ms in 40036 steps since start of marking, biggest step 1.8 ms, walltime since start of marking 117 ms) (average mu = 0.597, current mu = 0.598) finalize incremental marking via stack guard GC in old space requested
[55391:0x102849000]    12681 ms: Mark-sweep 4.1 (8.2) -> 4.1 (8.2) MB, 92.6 / 92.2 ms  (+ 10.8 ms in 40036 steps since start of marking, biggest step 1.6 ms, walltime since start of marking 118 ms) (average mu = 0.596, current mu = 0.595) finalize incremental marking via stack guard GC in old space requested

On Node 12, the following behavior can be observed.
$ node --trace-gc test.js
[58317:0x1028c4000]       33 ms: Scavenge 2.3 (3.0) -> 1.9 (4.0) MB, 1.3 / 0.0 ms  (average mu = 1.000, current mu = 1.000) allocation failure
[58317:0x1028c4000]       43 ms: Scavenge 2.4 (4.3) -> 2.2 (5.0) MB, 1.0 / 0.0 ms  (average mu = 1.000, current mu = 1.000) allocation failure
[58317:0x1028c4000]    83077 ms: Mark-sweep 2.8 (5.0) -> 1.9 (4.0) MB, 112.7 / 110.1 ms  (+ 82707.5 ms in 24342 steps since start of marking, biggest step 7.4 ms, walltime since start of marking 82898 ms) (average mu = 1.000, current mu = 1.000) finalize incremental marking via stack guard GC in old space requested
[58317:0x1028c4000]   166046 ms: Mark-sweep 2.0 (4.0) -> 1.9 (4.3) MB, 97.4 / 96.2 ms  (+ 82685.5 ms in 24342 steps since start of marking, biggest step 4.4 ms, walltime since start of marking 82854 ms) (average mu = 0.999, current mu = 0.999) finalize incremental marking via stack guard GC in old space requested
[58317:0x1028c4000]   249031 ms: Mark-sweep 1.9 (4.3) -> 1.9 (4.3) MB, 101.0 / 100.6 ms  (+ 82687.1 ms in 24342 steps since start of marking, biggest step 5.6 ms, walltime since start of marking 82873 ms) (average mu = 0.999, current mu = 0.999) finalize incremental marking via stack guard GC in old space requested
[58317:0x1028c4000]   332024 ms: Mark-sweep 1.9 (4.3) -> 1.8 (4.3) MB, 110.2 / 109.7 ms  (+ 82684.6 ms in 24342 steps since start of marking, biggest step 4.5 ms, walltime since start of marking 82879 ms) (average mu = 0.999, current mu = 0.999) finalize incremental marking via stack guard GC in old space requested
[58317:0x1028c4000]   415008 ms: Mark-sweep 1.9 (4.3) -> 1.8 (4.3) MB, 108.5 / 108.1 ms  (+ 82683.3 ms in 24342 steps since start of marking, biggest step 4.5 ms, walltime since start of marking 82863 ms) (average mu = 0.999, current mu = 0.999) finalize incremental marking via stack guard GC in old space requested

The Mark-sweep operations now take over 80 second each and everything grinds to a halt. Any ideas? For what it's worth, I haven't been able to observe any actual memory leaks.
I've tested and observed this on the following Node 12 versions: 12.0.0, 12.8.0 and 12.12.0.

Addendum: On the time taken seems to be roughly proportional to size of the XML document.

Number of elements in the document
Average pause time

100
~950ms

1000
~8300ms

10000
~82000ms

100000
~1080000ms

Having same issues. Please help us to resolve it, it renders lib useless when performance is needed.

@sluukkonen sorry for offtop: I see that work with xml in node is a big pain. Maybe we can unite to solve it together? Please take a look at nstd.io site.

Any updates/plans/anything on this one?

Any updates/plans/anything on this one?

Your best bet is to use libxmljs2. It’s actually maintained.

Any updates/plans/anything on this one?

Your best bet is to use libxmljs2. It’s actually maintained and the issue is fixed there.

Wow, you're a hero :) Thanks for a quick answer, will give it a try.


[1.20.1 Forge] Can't launch the game - Crash

Describe the Bug
crash-2024-05-09_10.37.47-fml.txt
Reproduction Steps

Install 0.3.3 version
Try to launch the game
...

Expected Result
No response
Additional Context
I've removed config/missions and mods/missions folders after update

I've seen that there is some issues with the forge version, I'm working on a fix


not able to change notebook kernel to python

Azure Data Studio Version:
I tried 1.8.0 as well as latest insider build on my Mac. I am getting the following error:

Failed to change kernel. Kernel SQL will be used. Error was: Notebook process exited prematurely with error: 1, StdErr Output: Traceback (most recent call last):
File "/Users/alanren/azuredatastudio-python/0.0.1/bin/jupyter-notebook", line 6, in
from notebook.notebookapp import main
File "/Users/alanren/azuredatastudio-python/0.0.1/lib/python3.6/site-packages/notebook/notebookapp.py", line 62, in
from tornado import httpserver
File "/Users/alanren/azuredatastudio-python/0.0.1/lib/python3.6/site-packages/tornado/httpserver.py", line 29, in
import ssl
File "/Users/alanren/azuredatastudio-python/0.0.1/lib/python3.6/ssl.py", line 101, in
import _ssl             # if we can't import it, let the error propagate
ImportError: dlopen(/Users/alanren/azuredatastudio-python/0.0.1/lib/python3.6/lib-dynload/_ssl.cpython-36m-darwin.so, 2): Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
Referenced from: /Users/alanren/azuredatastudio-python/0.0.1/lib/python3.6/lib-dynload/_ssl.cpython-36m-darwin.so
Reason: image not found

@MaddyDev was this the same Python issue you had?

Yes! I asked @yualan to add this the docs.

@MaddyDev @yualan , what is workaround here?

workaround is to: brew install openssl

Closing this now, we haven't seen anyone complain since then and am not able to repro it either.


Suppress “Found 0 error(s)” message

When ruff is run from a script alongside many other linters, the noisy default messages from each one saying that no errors were found can easily drown out a real error. Only print the error count if it’s nonzero or --verbose was specified.
(I’m open to making this opt-out rather than opt-in if you prefer, although I’m not sure what I’d call the option. --quiet already means something else, suppressing all output including errors.)

This seems reasonable to me.


rename App.NostrPubkey to App.AppPubKey

Reasoning: if we change to store both the app pubkey and the wallet pubkey, they should be easily identified and differentiated (see https://github.com/getAlby/hub/pull/736)


Small changes to the comments in the script templates

Capitalized the first phrase.
Made the C# template have the same wording as the GDScript one.

CC @godotengine/documentation, it would be good to get this settled. If there's a need for better clarity in those templates, some documentation eyes on it wouldn't hurt :)

Good to see this discussion happening. I've taken the suggestions and this is the result, good to go?
extends Node

# Declare member variables here. Examples:
# var a = 2
# var b = "text"

#func _ready():
#	# Code placed here runs once each time the node is added to a scene.
#

#func _process(delta):
#	# Called every frame. 'delta' is the elapsed time since the previous frame.
#

And while we're in the topic of templates, should something be done about the "No comments" template? It's a just a _ready with a pass. Should _process be added to it as well, as in "default, but with no comments"? Honestly, I would just remove this template entirely, as it seems kinda pointless to me.

The template proposal seems good to me, I'd just remove the extraneous # on an empty line for _ready and _process.

@akien-mga The # actually has a tab besides it, to leave a line to start coding. Tt made sense in the C# tempalte, so I did it for GDScript one as well.

@YeldhamDev Could you try replacing #\t# Something with \t# Something? The double # is weird indeed.

Could you try replacing #\t# Something with \t# Something? The double # is weird indeed.

Well the idea is that the whole code block is commented out, and when you uncomment it to actually use it, you shouldn't have a comment with no leading #. So you do need both #, one before the indentation (code block commenting) and one after (comment in the code block).

That said, I'm not sure about making the template have _ready commented out. Personally I use _ready in most scripts, and having to un-comment it each time will be a bother.

@akien-mga I agree, also, one final suggestion, the comments being place above the functions:
extends Node

# Declare member variables here. Examples:
# var a = 2
# var b = "text"

# Called when the node enters the scene tree for the first time.
func _ready():
	pass

# Called every frame. 'delta' is the elapsed time since the previous frame.
#func _process(delta):
#	pass

Also, I noticed that the C# template is hardcoded to use spaces, is this on purpose?

Spaces for the C# template are expected yes.
Comment above the function declaration seems fine.
We still have the issue with pass being shown as something to use in all functions when it is not though. Maybe it could be replaced by print("I'm ready!") or something like that? Since users are meant to delete this pass, they could just as well delete this pointless print :p

How about this?
# Called when the node enters the scene tree for the first time.
func _ready():
	pass # Replace with your code.

LGTM. Thanks!

Now that Godot 3.1 has been released, we don't plan to cherry-pick new features and enhancements to the 3.0 branch, unless there is very strong support in favor of it. Removing cherrypick label for 3.0.


Upgrade ramsey/uuid to ~3.4

hi @martijncalker, I'm closing this since https://github.com/qandidate-labs/broadway-uuid-generator/pull/8 is merged.


AstroPaper v3

Updates
Major Changes 🔥

upgrade to Astro version 3
add ViewTransitions

Other Changes 🎯

add whitespace-nowrap in title
remove showing featured posts in Recent Posts section of the home page. (in order to avoid duplicates and to be compatible with new ViewTransitions API.
add prettier-plugin-astro for formatting .astro files.

TODO 👀

update the docs

Suggestions 🤷🏻♂
Here, I'm requesting some suggestions for the newer version of AstroPaper.

should we add testing with playwright?
should we remove commitizen from AstroPaper? Since this way of committing is a little bit too opinionated for general users.

Live URL
You can now check the preview of AstroPaper v3 here. Any kind of suggestions are welcome!

Hello @satnaing, great work maintaining this Astro Paper! When are you planning to merge the 3.0? I am looking forward to updating my blog to the latest version and this template is my personal choice. Let me know if you need some help.

Hello @Talento90
This PR is going to be merged within this week (maybe around coming weekend).
If you want to try this rn, you can checkout the feature/version-3. It is pretty much stable now.
I just need to update docs and probably fix minor bugs.

@satnaing, I can't understand why we are using a dummy endpoint to generate all OG images at once. Also this way you cant even access them on the dev server because they will get generated during the build. What am I missing here?

@satnaing, I can't understand why we are using a dummy endpoint to generate all OG images at once. Also, this way you can't even access them on the dev server because they will get generated during the build. What am I missing here?

@tanishqmanuja
I use satori package to automatically generate OG images during build. However, Satori has its own limitations. At the time of writing this, Satori is only able to produce SVG images and cannot generate PNG images directly. While this is typically not an issue for regular images, it becomes problematic when dealing with Twitter cards, as they do not support SVG format.
To work around this limitation, I've implemented a solution in src/utils/generateOgImages.tsx to convert the generated SVG images into PNG format.
As you said, src/pages/[ogImage].png.ts is just a dummy endpoint that does not produce an actual OG image. Nevertheless, during build time, it can invoke generateOgImages() function inside src/utils/generateOgImages.tsx file, which is responsible for generating the necessary OG images in PNG format.
Using [ogImage].png.ts to trigger generateOgImages() is kinda "hacky", but it allows us to achieve the desired functionality without the need for additional configuration or scripts.
Another thing is that, while we can't access them on dev environment, we can build and preview them by
running npm run build and npm run preview. But keep in mind that in order to view them on dev server, we will have to update the astro.config.ts file a little bit.
export default defineConfig({
  site: "http://localhost:4321/", // we just replaced with localhost
  // other config
});

Currently, there is no option to disable "automatic OG image generation". In the future, that option might be included.
If you have any alternative suggestions or ideas for a more streamlined approach, please feel free to share them.

Sure, I have few ideas but that could delay the 3.0 release. So probably the best option will be that I will make a draft PR which you can merge or iterate over with some commits of your own within 3.1 or whatever is the release after 3.0.

@satnaing I've found one more issue in hamburger menu when I've added one more menu item:

vs

I've just added "publications" and ... Is it possible to line up search and theme switch icons? You can check it here https://alec-c4.com

file: Header.astro

Thanks a lot!!!!!


Mint token block does not compatible with previous version

Problem description
We have policy published with previous version 2.2.0 when token transfer happen after mint without AccountId setup on mint block. At that time token will be transfer to the owner of MRV .
We upgrade the code base to 2.3.0, the token is minted but not transfer anywhere. we still able see VP document in policy. No transfer steps will appear in logs
Step to reproduce
Steps to reproduce the behavior:

publish policy with 2.2.0
Upgrade the code to 2.3.0
Mint token
We expect token s will be transfered to Mrv Onwer, but it  does not happen

Expected behavior
It is important to keep old logic still happening to avoid re-published the policy with new version as that not an easy process we can do on our production environment
Screenshots
If applicable, add screenshots to help explain your problem.

sorry my bad, I only look at guardian logs to expect the transferLog message like previous version. the code actually does transfer and works
question?: why did we remove the transfer logs message?


Update cli-client.md

typo

Hi @georgescharlesbrain This is trying to merge to devnet but it need to go to main.

Hi, yes, I started from the docs, as always. Not sure why it wasn't automatically set to main.
Corrected it.

The site loads with the Devnet version selected by default, so the link at the bottom to GH opens that branch. Latest is built from the main branch.


image dimension

hi adam
the magnifiers disable when use an image with lower than 1400 dimension.
i wanna use magnifires in 500 * 500 images,whats your idea?

when i use the lib i get this warning too about passive event
[Violation] Added non-passive event listener to a scroll-blocking 'touchmove' event
can u fix that too or any advice?

I just published a fix to NPM (version 1.0.6) that should fix those non-passive event warnings. The update should also help avoid the size issues you mentioned before by minimizing the chance of CSS affecting certain elements within the components.

thx adam,
I checked that the problem was fixed.


Support specifying specific tests for local snapshots through task invocation

#131  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rbro112 and the rest of your teammates on  Graphite


NumpyAwareEncoder Class Monkey Patch

Added NumpyAwareEncoder override class to fix an issue with passing numpy arrays to Unity.
@bzinberg @fplk Can you please verify that this branch fixes the numpy array issue for you? I'll also add some new tests as part of my current integration testing ticket.

I am re-running the scene beta_0002_01_debug.json which @fplk reported a crash on and I reproduced at the time.  For the re-run now, I am using the current version of our TA1 team's infra, v0.3.7 of the Unity app, and this branch of the MCS python library.
I'm getting the following, different error:
┌ Warning: Skipping scene: run_scene() encountered exception: BoundsError: attempt to access 0-element Array{Any,1} at index [0]
│ Stacktrace:
│  [1] getindex at ./array.jl:809 [inlined]
│  [2] last(::Array{Any,1}) at ./abstractarray.jl:362
│  [3] extract_transform_params_from_initial_frame_agency(::PyCall.PyObject, ::GenGridSLAM.CameraIntrinsics; resolution::Float64) at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgency.jl/src/perception.jl:13
│  [4] extract_transform_params_from_initial_frame_agency at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgency.jl/src/perception.jl:13 [inlined]
│  [5] solve_agency_online(::PyCall.PyObject, ::McsAgent, ::McsConfiguration, ::PyCall.PyObject, ::Dict{String,String}; tv_thresh::Float64, ll_thresh::Float64, tv_step_thresh::Float64, ll_step_thresh::Float64, n_samples::Int64, kwargs::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}) at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgency.jl/src/GenAgency.jl:151
│  [6] solve_agency_online at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgency.jl/src/GenAgency.jl:151 [inlined]
│  [7] #solve_agency#92 at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgency.jl/src/GenAgency.jl:264 [inlined]
│  [8] solve_agency at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgency.jl/src/GenAgency.jl:263 [inlined]
│  [9] run_scene(::PyCall.PyObject, ::Function, ::McsConfiguration, ::String, ::Array{Float64,2}) at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgent.jl/src/GenAgent.jl:87
│  [10] macro expansion at ./timing.jl:233 [inlined]
│  [11] run(::Array{String,1}, ::String, ::Bool, ::Bool) at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgent.jl/src/GenAgent.jl:236
│  [12] run(::Array{String,1}, ::String) at /home/bzinberg/probcomp/GenPRAM_workspace/GenAgent.jl/src/GenAgent.jl:220
│  [13] top-level scope at none:6
│  [14] eval(::Module, ::Any) at ./boot.jl:331
│  [15] exec_options(::Base.JLOptions) at ./client.jl:272
│  [16] _start() at ./client.jl:506
└ @ GenAgent ~/probcomp/GenPRAM_workspace/GenAgent.jl/src/GenAgent.jl:171

This might be an issue with our infra, so ball is in my or @fplk's court to diagnose and get back to you.

Ah, it was because part of our codebase was still looking for an mcs_config.yaml to determine the metadata level, but as of MCS 0.3.7 that's no longer what the simulator uses.  Fixing and then I'll retry.


No warning if branch in lakefile and manifest differ

Add require a from git "../a.git"@"master" to the lakefile.
Run lake update.
Change to require a from git ".../a.git"@"develop".
Run lake build.

Then lake build will happily use the old version of a from the master branch in step 4, without printing a single warning.
I'm not sure what the best solution here would be.  A warning will be lost in the inevitable barrage of build errors.  Different dependencies might refer to different branches (or explicit revisions), so a fatal error is maybe too much.
This trips me up all the time now.  A compounding issue is that lean_packages/manifest.json was gitignored in older repositories, and so it's very easy to end up in a situation where the manifest is not checked in and you get nonreproducible errors due to different manifests on different machines.

Nix will automatically reset the lockfile entry if the "input descriptor" in flake.nix changed (i.e. switch everything to develop in this case), I found that behavior quite reasonable.

@gebner
A question that occurred to me today about this:

A compounding issue is that lean_packages/manifest.json was gitignored in older repositories, and so it's very easy to end up in a situation where the manifest is not checked in and you get nonreproducible errors due to different manifests on different machines.

Lake currently uses the top-level manifest to lock dependencies. So it should not matter if nested dependencies did not check in their manifest as long as the top-level one (i.e., your project) has checked its manifest in?

Right, but I have more top-level projects than nested dependencies, and thus a lot of projects where a need to remember to unignore/add the manifest. :smile:

I was working on this issue today and realized that we hadn't come to a conclusion as to what the solution should be. @gebner, @Kha what is the desired behavior here. A warning, an automatic update of the manifest, or something else?

Currently, I have implemented a warning. While as @gebner mentioned it can be lost in a barrage of build errors, it does appear at the very top of the log so it may stand out.

Hmm, is there a use case where enforcing the lakefile branch would be wrong? I guess doing manual changes to the checkout? I did that before and I felt bad for doing it, but it admittedly is convenient.

@Kha I think both approaches make sense. I stuck with the warning because it mirrors the current behavior for other mismatches (e.g., change in URL). If we decided to force update it here, we should probably force it in those cases as well.
One reason to stick with the warnings is that since the manifest is likely to undergo manual modifications in some cases (e.g., to fix version conflicts), it makes sense to avoid automatically update it unless requested (e.g., via lake update) to avoid clobbering user changes. However, version control may be sufficient to recover from that and the automatic updates can be more convenient, so I can see arguments for both approaches.


Move upgrader data into files.

Maintain hard whitelist, adds soft override.

I think I said it on discord but I would prefer the upgrade stuff being technically part of paramdex (even if dsms specific) as if we do do a repo split which allows independent updating of paramdex we would want this part of that. I'd also change the name of versionWhiteList.txt to just version.txt and put it in the directory of the XML def files.


Add automatic dark mode detection

Fixes #87
@zentox I am a bit hesitant to merge this, since it requires adding adding the jitpack repository to all Repositories that want to use FOPBot. What do you think?

Merging, since no concerns were raised. We have to remember to update the repos though


Support Apple silicon

Trying to load the dylib on Apple silicon gives this error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /private/var/folders/1b/331lr8s90xxcdx51x0pbwc7w0000gn/T/libjava-tree-sitter.dylib: dlopen(/private/var/folders/1b/331lr8s90xxcdx51x0pbwc7w0000gn/T/libjava-tree-sitter.dylib, 0x0001): tried: '/private/var/folders/1b/331lr8s90xxcdx51x0pbwc7w0000gn/T/libjava-tree-sitter.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/1b/331lr8s90xxcdx51x0pbwc7w0000gn/T/libjava-tree-sitter.dylib' (no such file), '/private/var/folders/1b/331lr8s90xxcdx51x0pbwc7w0000gn/T/libjava-tree-sitter.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
	at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
	at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
	at java.base/java.lang.Runtime.load0(Runtime.java:755)
	at java.base/java.lang.System.load(System.java:1953)
	at ch.usi.si.seart.treesitter.LibraryLoader.load(LibraryLoader.java:73)
	at org.example.Main.<clinit>(Main.java:11)

Important part being (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
This is revealed with lipo:
$ lipo -archs libjava-tree-sitter.dylib
x86_64

It should be possible to create a universal binary using something like this method: https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary#Update-the-Architecture-List-of-Custom-Makefiles

Hi @ivangreene
Thank you for the report. Unfortunately, this is a long-standing issue that we are very much aware of. The original developers wrote the build script used for this project. The file is quite messy and will most likely be rewritten from scratch soon. The way it works is it builds for only one specified OS and architecture at a time. At the same time, when we build for release we do it locally on one of our machines, before publishing to Maven Central. Since we use only one machine with specific specs, we can only reliably compile for the x86_64 architecture. We plan to address this by migrating our build, test and release to GitHub actions, which will allow us to support a wider range of architectures.
Currently, the only way to work around the issue is to compile the JAR yourself locally and include it in your project. Since you are running this on MacOS you would need to modify the build-shared-object-library-macos execution to include the appropriate architecture parameter:
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>3.1.1</version>
  <executions>
    <!-- OMITTED FOR BREVITY -->
    <execution>
      <id>build-shared-object-library-macos</id>
      <phase>compile</phase>
      <goals>
        <goal>exec</goal>
      </goals>
      <configuration>
        <executable>python3</executable>
        <workingDirectory>${project.basedir}</workingDirectory>
        <arguments>
          <argument>build.py</argument>
+         <argument>-a</argument>
+         <argument>aarch64</argument>
          <argument>-o</argument>
          <argument>${project.build.outputDirectory}/libjava-tree-sitter</argument>
        </arguments>
      </configuration>
    </execution>
    <!-- OMITTED FOR BREVITY -->
  </executions>
</plugin>

Since you are compiling locally for just MacOS, you can also skip the Linux compilation entirely:
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>3.1.1</version>
    <!-- OMITTED FOR BREVITY -->
    <execution>
      <id>build-shared-object-library-linux</id>
      <phase>compile</phase>
      <goals>
        <goal>exec</goal>
      </goals>
      <configuration>
+       <skip>true</skip>
        <!-- OMITTED FOR BREVITY -->
      </configuration>
    </execution>
  </executions>
</plugin>

I'll keep the issue open for the moment, but it might be superseded by a more general one in the future.

Thanks, looking forward to a build with both architectures in the future. As a note, the build works as-is locally because the build.py determines the host's architecture, so didn't need to add the argument in the pom


This new tools can't be used for gallery visuals

Can'find a way to add thumbnail and screenshot images to pbiviz using tools.
It made pbiviz not gallery ready

I think the screenshot and thumbnail should be included in the submission separately. I don't think there is any reason for them to be inside of the pbiviz file.
In the current model they can just be included in the e-mail along with the pbiviz. In the future the developer portal should have a way for the developer to upload / change screenshots and thumbnails independently from the visual implementation (pbiviz).

Makes sense. Thank you. I'll change gallery publisher then

On 02 Sep 2016, at 01:11, Lenny<EMAIL_ADDRESS>wrote:
I think the screenshot and thumbnail should be included in the submission separately. I don't think there is any reason for them to be inside of the pbiviz file.
In the current model they can just be included in the e-mail along with the pbiviz. In the future the developer portal should have a way for the developer to upload / change screenshots and thumbnails independently from the visual implementation (pbiviz).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


refactor around config history handling

More description, link to file(s)?

https://github.com/fluent/fluentd-ui/blob/master/app/models/fluentd/agent/common.rb#L60
https://github.com/fluent/fluentd-ui/tree/master/app/models/fluentd/setting_archive
These code, but we have some plans for extend config history feature such as history diff displaying.
This issue like a TODO comment after that, because we can't see the final file/code structure for now.
Sorry for poor information issue.

History diff is displayed.


Improve documentation for non-linux users

We need to state in the documentation that we are currently only supporting linux and point windows users to the vagrant instructions an mac osx users to the docker deloyment

I will do this.

Resolved by PR #96


Allow setting a port for the DHT when used as binary

When starting the dht it will use a given port to connect. However, by adding a dht.listen(port) here it should be possible to use a predictable port.

Found its way to the hyperswarm cli: https://github.com/hyperswarm/cli


review swifttype searches for providers

it might be neat to analyze the swifttype data for search terms in which people may have been looking for particular providers

might be neat if we could return a result to the contributing docs in these cases


FIX: concatenate_epochs available from mne

Closes https://github.com/mne-tools/mne-python/issues/2983#issuecomment-192182428

I thin the python reference rst also needs an update. Check as we have done with the other functions.

Is this me who makes an awful lot of modules crash on one of the Travis' version?

looks like travis has some endogenous sufferings ...

Ah non. It seems as if we have a classical circular import problem. Can you import mne on your branch without issues?

Ah non. It seems as if we have a classical circular import problem. Can you import mne on your branch without issues?

Ah oui :)

Surprising. Let me take a look. Bug smell.

Running tests locally.

Running tests locally.

did it pass?

Inmporting yes, and If our tests were faster I could tell you already ;)

which test do you run nosetools doc? This fails on mine, but I think I have a problem with beautifulsoup

One of the options in our Makefike, make all or test-doc

ok good to know

no example or test to update?

no example or test to update?

I don't know. Since there's now more than one way to load concatenate_epochs, update isn't necessary.
No example use concatenate_epochs.

I confirm. This function has been a bit secret nothing else to update. I think the error is unrelated. My +1.

thx @kingjr


host doesn't support requested feature

Because my host does not have an apt environment, I can't use cpu-checker to check my host support KVM.
Display output is not active in web VNC, which that means maybe my host dont support this project?
Please let me know if needs more information.
Docker log:
❯ Starting Windows for Docker v2.09...
❯ For support visit https://github.com/dockur/windows

swtpm: seccomp_load failed with errno 125: Operation canceled
Waiting for TPM socket to become available...
❯ ERROR: TPM socket not found? Disabling TPM support...
❯ Booting Windows using QEMU emulator version 8.2.1 ...
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8]

oh it works, thanks!


Clustering markers on the map via vuejs component

Any idea how can I transform the example here https://docs.mapbox.com/mapbox-gl-js/example/cluster/ to the format that works with Vuejs component?

@jdseen:

[x] Source code – https://github.com/vinayakkulkarni/cluster
[x] Demo – https://vinayakkulkarni.github.io/cluster/


Setting WP salts with /dev/random

NEW_RELIC_APP_NAME: Heroku WP
Setting WP salts with /dev/random
last output : Setting WP salts with /dev/random
script does not return.

This is actually a /dev/random issue try googling it. There is not enough "entropy" in the system. Try downloading a large file in the background.

And how exactly can we do that?

bro, like i say, try googling.
when it hangs at /dev/random, u try to open a browser tab and download any random file

@punggolzenith is correct, in order to make your WordPress install more secure I've set this to use /dev/random to generate the salts. The downside is this is "blocking" meaning it does not return until it is able to get enough randomness. Moving around a mouse cursor, downloading a large file, using the wifi or even walking around with the laptop (if that's what you're using) is normally enough to get more random data from the environment around you.