False negative on BelongsTo::associate()

Larastan Version: 0.6.2
--level used: 5

Description
PHPStan reports the following error: Method App\Post::setAuthorAttribute() should return App\User but returns App\Post.
The associate method of the BelongsTo relation does not return the related model, but the child model: https://github.com/laravel/framework/blob/7.x/src/Illuminate/Database/Eloquent/Relations/BelongsTo.php#L216
But Larastan assumes the opposite: https://github.com/nunomaduro/larastan/blob/master/stubs/BelongsTo.stub#L11
Laravel code where the issue was found

class Post extends Model
{
    public function author(): BelongsTo
    {
        return $this->belongsTo(User::class, 'author_id');
    }

    public function setAuthorAttribute(User $user): self
    {
        return $this->author()->associate($user);
    }
}

I have no idea how Larastan or PHPstan works, otherwise I would send a PR for this issue.

Hi,
Thanks for the report! Yes, this looks like a wrong assumption in the stub file. Maybe additionally we need to keep track of the child in the relation clasess. I'll take a look into this :+1:

Fixed with #633
I could only find this situation (returning child model) in  associate, dissociate, and getChild methods of BelongsTo relation. If you encounter this behavior in different relation methods, let me know :+1:


When switch the language, click "Finish" of "Getting Started" and choose a "Examples", the page gets unresponsive

Repro steps:

Navigate to https://pxt.microbit.org/beta
Click "More..." --> "Language", then choose "Chinese(Simplified, China)"
Choose the "Getting Started" and click one by one
Click "Finish", choose "More Tutorials"-->"Examples"-->"Rando"

Results:
The page gets dark and unresponsive.

@microsoftsam can you take look?

Most likely related to #2103


Question: Exposing courses.json?

First of all, thank you so much for building this!
I saw the website being referred by @acantril on Slack and was thrilled to discover its existence.
I am considering building a small browser extension to tag lectures within https://learn.cantrill.io/ with all the courses they appear in. This would make it easier to filter out duplicates that may already be covered in other courses. The general flow I have in mind is:

The browser extension would have buttons that can be toggled for each of the courses that the user has completed.
When the user starts a new course, any duplicate lectures would be marked with a small badge indicating the course in which they were covered. If a lecture was covered in more than one course, all courses would be displayed.

Here is a small screenshot showing a simple version of what the badges might look like. I may further reduce their size and position them absolutely to avoid interfering with the existing layout.

Since your website already generates all of the information that would be needed to build this extension, I hope to not duplicate the work/logic, especially since the matching relies on fuzzy matching, which could lead to different results between what I would build and what can be found here.
Thus, I was wondering if you would consider exposing the generated courses JSON file to the public internet. I noticed that it can be found at the top of index.js with const courses = _.chain(JSON.parse('<courses>')), but downloading and parsing that file to strip the JSON would be very hacky and error-prone. Ideally, I would prefer a way of fetching the JSON directly from an endpoint.
Please let me know your thoughts on exposing this file. If you think it's a good idea, I'm happy to work on a pull request for this.
Feel free to close this whenever, I wasn't sure what the best channel was to ask a question.

Looks great! Thanks!
I'll work on the extension tomorrow, and update this issue once I have a working prototype.
If you like the idea of the extension and you are interested in consolidating the codebases, I'd be happy to add the extension code directly to this repo and add the necessary CI/CD pipelines to release the extension.

Hey @sfanous,
Just wanted to give you a quick update. I got the initial version of the application working on Chrome and Firefox and here is the link to the repo https://github.com/ghassanachi/cantrill-web-ext.
Firefox was a little more restrictive when it came of CORS policies and HTTP usage, so I ended up adding a small https/cors reverse_proxy for http://cantrill.io-dev.i-aws.cloud/courses.json (proxy is hosted at https://cantrill-json.ghassanachi.com -- uri is optional since the proxy is rewriting the request).
If you want to test the extension, you can use the following steps:
Firefox:

Clone the repo and install dependencies witn yarn install or npm install
Build the extension with yarn package:firefox or npm run package:firefox. This will generate a web-ext-artifacts folder containing the zip file for the extension
Head to the URL about:debugging in Firefox
Click on This Firefox on the sidebar
Click on Load Temporary Add-On, an select the extension zip from the web-ext-artifacts folder

Chrome

Clone the repo and install dependencies witn yarn install or npm install
Build the extension with yarn build or npm run build
Head to the URL chrome://extensions in Chrome
Toggle the Developer mode switch at the top right of the page
Click on the Load unpacked and select the dist folder in the cloned repository.

Since I don't own the courses, I'm still missing information about for the Advanced Networking and Security Specialties (specifically the <course_id> url parameter for each of the courses). But once I have those I'll work on releasing the extension to the Firefox and Chrome Stores.
If possible I'd like to point to an https/production version of the http://cantrill.io-dev.i-aws.cloud/courses.json file directly on your domain.

Hey @ghassanachi
I had a crazy busy week.
I've copied the file to https://cantrill.io.i-aws.cloud/courses.json
Also check out https://cantrill.io.i-aws.cloud/config_files/courses.json for the list of courses my app currently tracks.
I'll try to give the extension a test drive over the weekend.

Thanks @sfanous! No worries and no rush on getting the file to automatically update. I don't think the courses change that often, and being able to point it at the production endpoint should be more then sufficient for now.
Thanks for pointing out  https://cantrill.io.i-aws.cloud/config_files/courses.json, I had that information hardcoded on my end (I might still need that just because I am mapping the courses to local images), but this should allow me to stay consistent with the courses being tracked on your end.
Thanks again for all the help.

I don't think the courses change that often

Bad assumption to make, i change courses v. often.

Thanks for the info @acantril.
If that is the case, I'll be a little more patient with the initial release and make sure to refresh course data on the extension more often, and I'll wait for the automatic update of the couses.json file to be published.
@sfanous, if you are a little busy and  want a hand for the automatic update of courses.json, let me know and I would be happy to help when I have a little bit of time.

@ghassanachi All is done now. There was some down time yesterday as I had been wanting to migrate this app to a separate AWS account within my Org but all should be good now and the courses.json file is now updated on every scheduled run.


Creat ensemble

fix step blank

Codecov Report

Merging #1471 (ccd1d31) into main (43fc4ed) will increase coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1471      +/-   ##
==========================================
+ Coverage   67.97%   68.05%   +0.08%
==========================================
  Files         311      311
  Lines       17772    17772
  Branches     2912     2912
==========================================
+ Hits        12080    12095      +15
+ Misses       4865     4848      -17
- Partials      827      829       +2

Impacted Files
Coverage Δ

towhee/engine/operator_runner/runner_base.py
92.16% <0.00%> (+0.60%)
:arrow_up:

towhee/engine/operator_context.py
84.78% <0.00%> (+2.17%)
:arrow_up:

towhee/engine/graph_context.py
90.76% <0.00%> (+4.61%)
:arrow_up:

towhee/engine/task_scheduler.py
71.60% <0.00%> (+11.11%)
:arrow_up:

Continue to review full report at Codecov.

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

/approve
/lgtm


action invoke requires leading slash on packaged action

> nim action invoke whisk-system/utils/context
 ›   Error: failed to invoke the action: the requested resource does not exist. (404 Not Found)

but this works:
> nim action invoke /whisk-system/utils/context
{...}

this one is ugly - the real issue is in npm openwhisk, which tolerates an optional leading / when it parses out the namespace and asset name from the options.name property but then drops this information when it checks explicitly if the given name starts with a / and proceeds to ignore the parsed namespace.

Making the change in npm openwhisk is difficult in my assessment. Instead, I've taken as a requirement that the name should be fully qualified when using the SDK. So accordingly, qualify the names fully on the client.

Closed by 0e1f6c6ecc768b1ef1c6362651a85032511ec22d - will upstream to aio.


All note time is reported as UTC 0

Is there any way to set a timezone or use the current host server timezone?
All the notes I create with permanote via the sandstorm software are set to UTC 0.  All other apps use the timezone set on the Ubuntu server.  If I look at the grains it shows the correct time of the last change to permanote, but the notes themselves show time in UTC.
Is this a bug or do I need to set something where?

@keybits I think the best way it to use moment.
I had luck with flask-moment https://github.com/miguelgrinberg/Flask-Moment

I, too, have the issue with UTC time


example: esp32s3 compile error no wifi.c

hi,  sepfy
wifi.c is removed in example esp32, But example esp32s3 adds wifi.c to CMakeLists.txt

I think you can refer to this commit https://github.com/sepfy/libpeer/commit/7af49b6338594e493792d132740a782e35406c06

Removed wifi.c. Use ESP32 connect example


Does the collectionView has to be full screen?

Hi,
Does the collectionView has to be full screen?
What if I want to pin my collectionView to the  1/3 top ?
Is it possible ?
thanks :)

I think it's fine. The size of the collectionView should be a limit of this library. (the size of the cell might though)


Feat/metadata overview

Refactoring of the list page with metadata and labelings added as additional information.

Where did the select boxes go for delete operations?

The wohl card is clickable

IMHO, there is quite a lot of white space in the collapsed version. It would be great if unused white space could be used as a preview in the collapsed state (I know it might be a bit difficult to do reactively …)
To explain my use case: if you want to delete all datasets related to a certain set of metadata, you do not want to expand all dataset descriptions.
Just my 2 cents. Otherwise, it looks great!

The whole card is clickable

I think for both usability and accessibility, I would show the check boxes. It makes the interface much more intuitive (you can keep whole thing clickable). Particularly with the collapse also you might to need to really hit everything quite accurately to not trigger the wrong action (Might want to try it on a mobile device: Here a long press would I guess be the typical select op. Short presses for select are typically very annoying)

I like this very much!


Improve trait Visitor

If we already use a macro for scaffolding method signatures we might as well use it for scaffolding the corresponding match arms.
Took the opportunity to add the missing node types for completeness while I'm at it, in preparation for a possible extraction into a separate crate (Yes, please! 🙏🏻).
(I used rust-analyzer's /xtask/src/ast_src.rs file to source the node kinds.)

https://docs.rs/rust-visitor
I will make it more generic and move Semantics out to keep it pure visitor crate.

On second thought, I don't think any other argument is even needed since this is a trait. All the stuff people might need can be pushed into the type which is implementing this trait.
@regexident What do you think about converting like below?
fn $method(&mut self, _: &ast::$node, _semantics: &Semantics) {}

to
fn $method(&mut self, _: &ast::$node) {}

Removing _semantics: &Semantics sounds good to me. 👍


Added Awesome Mobile Conferences by @amobconf

Awesome Mobile Conferences is a collaborative list of awesome mobile conferences around the world, it uses a json db that allow to generate on push the readme file and send push notifications to related mobile apps.

Awesome Mobile Conferences
I decided to create awesome mobile conferences in order to allow iOS and Android developers to find easily the best conferences around the world. The repo uses the same approach I set in Awesome Swift, a JSON file generates on push the ReadMe file and two dedicate mobile apps allow to browse data on iOS and Android.
By submitting this pull request I confirm I've read and complied with the below requirements.
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

I have read and understood the contribution guidelines and the instructions for creating a list.
This pull request has a descriptive title.For example, Add Name of List, not Update readme.md or Add awesome list.
The entry in the Awesome list should:

Include a short description about the project/theme of the list. It should not describe the list itself.Example: - [Fish](…) - User-friendly shell., not - [Fish](…) - Resources for Fish..
Be added at the bottom of the appropriate category.

The list I'm submitting complies with these requirements:

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
It's the result of hard work and the best I could possibly produce.
Non-generated Markdown file in a GitHub repo.
Includes a succinct description of the project/theme at the top of the readme. (Example)
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate.
Only has awesome items. Awesome lists are curations of the best, not everything.
Includes a project logo/illustration whenever possible.

Either fullwidth or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.
Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of sub-lists, preferably none.

Has an appropriate license.

That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
If you use a license badge, it should be SVG, not PNG.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Drop all the A / An prefixes in the descriptions.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.

Go to the top and read it again.

The repo has been archived.


Fix Driver Name editor setting not requiring an editor restart

This closes https://github.com/godotengine/godot/issues/70401.
This issue doesn't occur in master.

Thanks!

Cherry-picked for 3.5.2.


TOC: Candidate Eligibility: Non-code contributions

https://github.com/cloudfoundry/community/blob/main/TOC.md#candidate-eligibility
Similar to #58, TOC members, WG Leads, and Approvers seems to favour code contributions over non-code contributions. I'd like to ask the question if this is the intention when it comes to TOC candidates?

This came up already when we were talking about the bootstrapping of the TOC, as there are currently no eligible candidates at all.

This came up already when we were talking about the bootstrapping of the TOC, as there are currently no eligible candidates at all.

Ability to ask for an exception for TOC eligibility criteria should be added to both TOC and MIGRATION

@chipchilders: When you write "ask for an exception" it sound like "usually" we do favour code contributions over other contributions for TOC candidates. Not sure if this is the intent, thus I opened this Github issue.

@loewenstein says that @bkrannich is happy now and that we can close it

Hi @chipchilders,
Looking at the latest version in the repo together with @loewenstein, I am not sure my initial intent for opening this issue is still represented in the current wording when it comes to non-code contributions.
I understood from @loewenstein that https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md#scope-of-technical-contributions is a disclaimer that is trying to include non-contributions for the remainder of the document but I am not sure people reading the document would intuitively understand this intent.
Let's make a couple of examples:

Would the authors of a document like https://docs.google.com/document/d/1rG814raI5UfGUsF_Ycrr8hKQMo1RH9TRMxuvkgHSdLg/edit?usp=sharing be Approvers according to https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md#role-summary ? Would we want them to be Approvers so that they are eligible for the TOC?
See https://github.com/cloudfoundry/cfar-proposals/issues/22 - it links https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit ; would we want the authors of that document to be eligible? The document doesn't mention it's authors, would it be sufficient to list them inside the document and would that be a suggestion for similar documents moving forward?
Another one is https://docs.google.com/document/d/17zIHB-L6tLEJPdbB4JYUEb4ii8w2YIUL5TQU7fV9jlM/edit - same questions as with the previous bullet.
Would the person organizing the CAB call be viewed as an Approver even though they don't need to be officially part of a working group? Or would CAB need to turn into an official working group to allow for an Approver role?
I frequently refer back to @emalm 's https://docs.google.com/document/d/1uPLab3F0LwbpV4ryGtaERfxdOx0Q4BCvbS8J-dVG29g/edit document - would we want the creator of such a document to be an Approver according to the definition?

I think the above examples are less clear than the ability to merge code into an official repo. However, I believe the intention is for the above examples to allow these types of contributions to fall under the Approver role. This is why I liked your suggestion in https://github.com/cloudfoundry/community/issues/59#issuecomment-773457158 to define an exception process but I learned from @loewenstein that the exception process has been removed meanwhile.
I guess my ask would either be to make it more clear in the wording of the documents how the above examples would be viewed or to reconsider an exception process for them.
Thanks in advance.

The community should discuss during the Friday meeting. If you can make it, that would be helpful!

@bkrannich hopefully the discussion last week helped clarify the working group's prior deliberations that led to the current approach. I believe, based on that conversation, that you were OK with (1) that voter eligibility was clear enough and (2) that TOC eligibility should absolutely require demonstrated support for the project in an official technical community leadership role. The only question was about the role definitions, to be sure that they clearly indicated the types of technical community work that qualified "non-code" contributors for leadership roles. You took the action to review with that context in mind. Can you let the governance working group know if you are OK, or if you have any suggested changes, via either this issue or a PR into the appropriate files?

@chipchilders Yes, I am fine with your summary. In terms of the actual text, Valentina is about to prepare some suggestions to make the wording more clear (without changing what you wrote in your previous comment, I'd say) and will send that to you as input by EOB today.

Reviewed and approved by GB. We can continue to iterate on the ROLES.md as the new TOC leads the community through the necessary changes.


Update to Swift 5.1

Hi! @naoty
I tried to use this tool from a brew installation but some errors were occurred.
We needed Swift 5.1 (latest), but it was not supported.
So I tried to support, please review.

@tasaiii725 Thanks. I cannot review your code because I am away from iOS development. But, I will merge your commit.


Update 300-many-to-many-relations.mdx

The many-to-many connect case of assignment of existing categories requires that the model being assigned match the schema letter case (i.e. must be capitalized).
Describe this PR

Changes

What issue does this fix?

Any other relevant information

I just ran into this in my own project. I have a joins table of MealsOnMenus which join a Meal and Menu model. In this example where I was creating a Menu with associated (existing) Meal objects. The query was creating the Menu object but I was getting an error on the Meal connect query. The issue was that originally I was using meal, once I capitalized the connect query to Meal the query worked as expected.
async function createMenu({ userId, menu, meals }) {
  return db.menu.create({
    data: {
      userId,
      name: menu.name,
      description: menu.description,
      meals: {
        create: meals.map((meal) => ({
          Meal: { // <--- capitalized this `Meal`.
            connect: {
              id: +meal.id,
            },
          },
        })),
      },
    },
  });
}

I actually do see my error in raising this ticket. The examples I was following on the Prisma docs has lowercase columns, where in my code I am using capitalized columns. So I am incorrect in this. Closing.

Yep, easy mistake to make unfortunately. In your example the schema seems to come from Introspection, which just uses the model name as the field name (because it is hard to make a decision what the correct name should be).
Good you figured it out!


Definition of Functor is inconsistent with base-<IP_ADDRESS> etc.

The agda2hs prelude puts void as a member of the typeclass, but the latest GHC base libraries do not.
Compare void in
https://github.com/agda/agda2hs/blob/7b3e48a35448acff9bb5823ca22623eafb000d15/lib/Haskell/Prim/Functor.agda#L15-L24
and to it's top-level placement in
https://github.com/ghc/ghc/blob/f3225ed4b3f3c4309f9342c5e40643eeb0cc45da/libraries/base/Data/Functor.hs#L210-L211
The same problem occurs for several other members of Functor and for several other typeclasses.

Currently we are not very explicit about which version of GHC or the Haskell Prelude we support. But in this case I believe it makes sense to remove void as a field so we are compatible with the latest release at least.


Remove utils.createFragment

It was only used once.
A fragment is unnecessary where it was used.

LGTM 👍
Please resolve conflicts :octocat:

Rebased


Twind or tailwind support

Feature request
Ability to use tailwind css to style components

Have a look at https://github.com/gbj/leptos/discussions/125#discussioncomment-4245279
There's a ticket in cargo-leptos already: https://github.com/akesson/cargo-leptos/issues/18
Feel free to contribute with a PR 😄

@akesson I only just started looking at tutorials on rust programming, pretty sure I am a little ways off contributing to a rust built hyper tuned reactivity framework 😅

There is certainly a learning curve, but once you pass it you'll never regret spending that time. I'm super happy to use Rust myself. And once you feel ready for contributing: the Leptos community (and most Rust communities) is a great one to help you get your first contributions ready. But in any case, join the Discord where you can ask any questions you'd like: https://discord.gg/YdRAhS7eQB

Just chiming in to add: also, check out the tailwind example.
I'm going to close this one, as this is already possible and I've seen examples of folks using it in their apps!


NEI Handler Request

Hello! I was wondering if it was possible for you to add NEI handlers for the following crafting systems:
-Sewing Machine (Necromancy):
It would be extremely helpful to be able to view the Sewing recipes to create corpse limbs from Necromancy. :)
-Clockwork Assembly Table (Clockwork Phase):
This isn't really necessary, but it would be useful for noobs to the new Clockwork Phase mod.
-Energy Collector (ProjectE):
It would be useful to be able to see what 'fuels' can be made by using the Energy Collector upgrading feature.
-Soul Forge (Soul Shards: The Old Ways):
The Soul Forge is used to make Soul Shards and Soulium... and since they're the main items of the mod it would be extremely useful.
I hope you consider all of these, and it will greatly benefit me and most likely many others who use your wonderful NEI addon! :D

Moved into #48


Fix invalid XML regex

Use the NChar character class to specify Unicode noncharacters rather than specify the ranges manually. This fixes a typo in the first range (should end with \uFDEF not \uFDDF).
See here.

I've rebased this onto the latest master and updated the description. This actually fixes part of the regex so I updated the description as well.

I added #438 to test this and it shows that, at least, characters that should be removed are removed.
Can we document more about what the NChar character class means / where it came from?  I cannot find it defined anywhere.  I think we should have a comment that explains how this character class is derived from or related to the docs below as well as the link in the description above that gives the expansion of the character range.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape
https://unicode.org/reports/tr18/

If you want to merge my PR into this one that's fine.


Incorrect version sorting

Reported by @Suor and @amritghimire.
If you register 3.0.0, then 2.5.2-bugfix, then the latest will be 2.5.2-bugfix:
https://github.com/iterative/gto/blob/e32504686e250609662b5698301edbb1e77c5c7e/gto/base.py#L76-L87
Related to #132

There are a bunch of (contradicting) ways to do this, using distutils (marked for deprecation), and setuptools as well has some parsing mechanism that will resolve to some python-specific versioning (see PEP440)
None are actually semver :)
I suggest the element of least surprise and also being compliant with semver (language agnostic).
Something like using semver package -> with well defined/expected semver ordering, and non-semver compliant tags can be pushed to bottom and sorted using something which sorts "all" - like natsort

@aguschin Can you create a publicly available key or compare function while you implement the version sorting in GTO?

I'm implementing this right now and will ship the new release with this and #147 today. Do you need something beside that?

Thanks, That will be all for now. @aguschin

closed by #161
release 0.1.8 should happen in an hour, so you could try it out
@amritghimire, please note that GTO doesn't support sorting of SemVers with suffixes, e.g. 2.5.2-bugfix yet. It will properly sort x.y.z, but not x.y.z-suffix. I plan to address it a bit later in #146


Add DRAMSim2 Support to our test memory

This will enable a more accurate performance regression. The most likely path forward is through SV-DPI calls into the libdramsim.so library. This will also allow us to support higher ranges than VCS, as the memory will be dynamically allocated in C++

Live in dev


Fixes #595. Avoid endless recursion in Cell.getRowspan()

Grand. Appveyor build failed because Windows archives for graphviz moved to a new location 🤦♂

Travis build succeeded.
For this change it is safe to assume that Windows is not affected and it really only failed because the graphviz packages could not be installed.


Emscripten support

Lean 3 can run on the web browser. The code is compiled into javascript using emscripten https://emscripten.org/
We need this feature in Lean 4 to be able to have interactive documentation again.

A note for people stumbling upon this issue: for our Lean 4 course at KIT, we have had good experience with using Gitpod in effectively the same manner. But since this is using somebody else's infrastructure using limited accounts, it is not a proper solution.

Initial build support, but no editor integration yet: https://github.com/leanprover/lean4/pull/505

What is the status of this?
I'm guessing this is not supported in the nix build and removed from the CI?
I'm interested in getting this to work (in nix).
Is it enough to run:
emcmake cmake ../..
emmake make -jN

So, can lean4 compile to javascript? I would like to use it instead of https://github.com/purescript/purescript

@srghma You can try lean2wasm. I have not tried this out myself and do not know how well it works though!


Simply can't get started with this. Error: Cannot find module 'dojo/dojo'

Frustrating when you can't even get started with the simple examples.

npm install
 grunt
grunt test

Running "intern:client" (intern) task Error: Cannot find module 'dojo/dojo'   at Function.Module._resolveFilename  <module.js:339:15>   at Function.require.resolve  <internal/module.js:27:19>   at <node_modules/intern/lib/executors/PreExecutor.js:498:32>   at new Promise  <node_modules/intern/browser_modules/dojo/Promise.ts:411:3>   at PreExecutor.swapLoader  <node_modules/intern/lib/executors/PreExecutor.js:489:11>   at swapLoader  <node_modules/intern/lib/executors/PreExecutor.js:449:17>   at <node_modules/intern/browser_modules/dojo/Promise.ts:393:15>   at runCallbacks  <node_modules/intern/browser_modules/dojo/Promise.ts:11:11>   at <node_modules/intern/browser_modules/dojo/Promise.ts:317:4>   at run  <node_modules/intern/browser_modules/dojo/Promise.ts:237:7>

Ideally we should be depending on a version of dojo-loader for this instead of using the Dojo 1 loader, which, resolving it as a dependency is what is going on.

@tfsimondouglas the missing dependencies have been added in #3, look forward to more updates as we work through #2. Thanks for raising this.


Mastodon doesn't support type(s) h-card, or no content was found.

I'm confused. Brid.gy is running and synced to my website. Mentions from Mastodon are showing in the Brid.gy dashboard, but they're reporting no webmention targets. I modified my site theme to include the h-card properties, which are validated by https://indiewebify.me. Yet, when I go back to brid.gy, I get the error: Mastodon doesn't support type(s) h-card, or no content was found. What am I doing wrong?

Looks like it's sent at least a handful of webmentions! For example, the one currently at the top of https://brid.gy/mastodon/<EMAIL_ADDRESS>. Sent 2023-11-06 20:48:47 UTC, source https://brid.gy/repost/mastodon/<EMAIL_ADDRESS>target https://justincox.com/blog/2023/11/write-now-with-lauren-roberts/ , to your webmention endpoint https://justincox.com/webmentions/receive/ , which returned HTTP 202.
I expect Bridgy didn't do anything for most of the other responses because it needs a way to connect each post on Mastodon to its corresponding post on your web site: https://brid.gy/about#link to your web site

As for the doesn't support type(s) h-card error, it sounds like you were entering your site into the publish form. That cross-posts from your site to Mastodon, while backfeed sends replies, likes, reposts etc from Mastodon back to your site. Separate features.
Sorry for the confusion. Happy to answer any other q's!

It's not enough for your Mastodon profile to link to your web site or vice versa. Bridgy needs to know which specific post on your site matches which specific post on Mastodon. You can do that for each post either by including a link inside a Mastodon post to the original post on your site, or by including syndication links on the original post that point to the Mastodon copy. The link I posted has more details.

Welcome! Tentatively closing.


How to catch the render completed event?

Im trying to capture a screen shot of the pdf once the pdf has loaded, instead i get the page number on the right side but no screen dump i presume its still rendering.
If i add the same code in the page change function i can get a screen shot but i cannot use page 0 as it also have not completed the render process.
My question is how do you catch when the process has completed, i presume the function does not return this event.
Anyone stumbled across a solution to render completed ?

@barteksc
Reading deeper into the onRender event,
Add OnRenderListener, that will be called once, right before document is drawn on the screen
Where can you catch the completion of the render event when the screen has been rendered?


Rock, Paper, Scissor, Spock and Lizard Game

I want to create a rock, paper, scissor, spock and lizard game in reactjs. This is a slightly advanced version of the common rock, paper scissor game that we play.
But an amazing game it is!! Fun logic!

@raj03kumar Please assign this project to me under gssoc23

Please assign me this issue under GSSOC'23

Hi, this was my idea and I proposed it first. So please assign this to me.

Assigned this issue to you. Kindly get it done within a week and go through the readme and contributing.md for successful merge. All the best to your work Priyanshu...!!!


IOS cordova build ios

Help my guys please:)
After build that: cordova build ios --device --buildFlag="-UseModernBuildSystem=0" or cordova build ios --device i can see:

n file included from :1:
/Users/admin/.taco_home/remote-builds/taco-remote/builds/Thisislogic.Gtrk37/platforms/ios/Pods/Headers/Public/Firebase/Firebase.h:15:9: fatal error: 'FirebaseCore/FirebaseCore.h' file not found
#import <FirebaseCore/FirebaseCore.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
/Users/admin/.taco_home/remote-builds/taco-remote/builds/Thisislogic.Gtrk37/platforms/ios/GTRK«CyrillicName»/Plugins/cordova-plugin-firebasex/FirebasePlugin.m:4:9: fatal error: could
not build module 'Firebase'
#import "Firebase.h"
2 errors generated.

I had this error in XCode, in bash... I think that at the time of installing the plugin something went wrong. But I checked pods (1.9.1 installed by sudo), added and removed it. Not help:( But meybe you will help me?:)

This is insufficient information to diagnose the cause of the issue.
However, at a guess I see a possible cause with GTRK«CyrillicName» as Cyrillic characters in paths are known to cause issues with iOS builds - try removing any Cyrillic characters in the path.
Also please attempt to build and run the example project as a known working codebase to validate your dev environment.
If you encounter a similar problem with the example project, please complete the issue template in full including full console output by appending the --verbose flag to any CLI commands.


Developer Discord link is invalid

The developer discord link at https://github.com/Ribbit-Network/ribbit-network-dashboard is invalid. When I click it, I get the message:
Invite Invalid
This invite may be expired, or you might not have permission to join

Oh noooooooo let me fix that now
This link should work I believe: https://discord.gg/vq8PkDb2TC

Link updated! Let me know if that worked!

That works now - thanks!


About the generation of the data_nq_sampled.jsonl file passages field

data_nq_sampled.jsonl
Seeing that you wrote in your last issue that you used OpenMatch/t5-ance to do the embedding, I went and generated new vector embeddings using generate_passage_embeddings.py in self-rag, the original text is still in the psgsw100.tsv file, and I used the first example in nq { “id”:“-5011119306587397321”, “question”: “who sings the theme song to all that”}, the results of the recall are not quite the same
The text in this file is relatively long, but the array elements in your passages field are relatively short, and there are a lot of data in the format “BULLET::::”.
Is the text column of psgsw100.tsv chunked and processed more carefully when generating the embed?

Hi, @BlueCestbon
We use the OpenMatch toolkit for retrieval, with all settings consistent with their default settings. Why not try about this one?
Noise ""BULLET::::"" is normal, this is due to the quality of the Wiki-KILT.

Wiki-KILT

Thanks for your reply. I will try again with OpenMatch toolkit and Wiki-KILT.


[WIP] Unlocking different domains using config loader

Added support for:

Enabling different domains using mmio_cfg_loader
Using enabled domain data to identify address access faults
Checking access to domains other than current in host

LGTM for openpiton stuff.  I think there are some simplifications we'll need before merging into mainline


whether to use deduplicated bam

When I ran Msisensor， I found the results are quite different between using the deduplicated bam and not deduplicated bam.  I wonder which bam shoud be used , the deduplicated bam or not deduplicated bam .
not_dedeplicated.bam
Total_Number_of_Sites	Number_of_Somatic_Sites	%
9739	1501	15.41

dedeplicated.bam
Total_Number_of_Sites	Number_of_Somatic_Sites	%
8798	122	1.39

what is the data coverage? WGS or WES or targeted sequencing?
When I ran Msisensor， I found the results are quite different between using the deduplicated bam and not deduplicated bam. I wonder which bam shoud be used , the deduplicated bam or not deduplicated bam .
not_dedeplicated.bam
Total_Number_of_Sites   Number_of_Somatic_Sites %
9739    1501    15.41
dedeplicated.bam
Total_Number_of_Sites   Number_of_Somatic_Sites %
8798    122     1.39
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/ding-lab/msisensor/issues/29, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB9s-8n9bqtREHkiLxof0R7RtG-3Ig8jks5u_XFQgaJpZM4ZngYf.

It is WES ,  the mean coverage is 180 and the dup_ratio is 54.88%

I have noticed the same behavior and now routinely msisensor on dedupped BAMs (obtained using samtools view -F 1024). The results are then much closer to MSI status obtained by orthogonal method.

You should use the deduplicated BAMs. In the end, you can get the correct results only by using the data that you think is the cleanest.

I am wondering whether bam with marked duplicates is sufficient or I have to export deduplicated reads to a separate bam? Thanks!

Marking duplicates is not sufficient. There is often a notable difference between using a BAM file with duplicates marked and with duplicates removed.

Thank you very much for the quick response! In addition, there is a closed issue where people suggested using coverage normalization. I find score slightly changes. But this classifies samples with score around cutoff point 3.5% differently. Do you have any suggestion? Many thanks!

We suggest : MSI_H: msiscore >= 10%,  MSI_L:    3.5% =< msiscore < 10%;  MSS: msiscore < 3.5%

Thank you very much for the great information! Do you suggest coverage normalize for normal and tumor samples? Thanks!

We din't normalize the TCGA UCEC data ( msiscore: 3.5% ) in MSIsensor original version. You can test with or without normalization option. We suggest that you choose this option when normal and tumor coverage are very different.

Thank you very much! Can you please specify how you implement coverage normalization and/or how normalization affects the the length distribution / msi calling? This is very important to me because with and without normalization classify my samples to MSI_H and MSI_L respectively. Thanks!

The difference in the depth of sequencing between tumor tissue and normal tissue will affect the judgment of whether the site is stable. Therefore, we normalize the read distribution so that the area of their distribution is in the same magnitude. The specific practices are as follows: compare the sequencing depth of normal tissues and tumor tissues and correct the sequencing data with a small depth, that is,
the number of supported reads after normalization of the site = the number of supported reads * (max / min).
Where max is the total number of supported reads of the tissue with a large depth of the site, and min is the total number of supported reads of the tissue with a smaller sequencing depth.

Thank you very much, this is very clear! I plan to extract the coverages of tumor and normal samples at all possible MS loci that are qualified for MSI calling, then see whether I need to adopt "coverage normalization". Do you have a suggestion about what range of coverage difference between normal and tumor is good for using "coverage normalization"? Thanks!


NULL value support for all data types

Currently in Pinot we don't have real NULL value support, but use some special default values for NULL. For dimensions, the default value is the minimum value for numeric types, "null" for STRING, empty byte array for BYTES; for metrics, the default value is 0 for numeric types, empty byte array for BYTES. #4214 adds support to treat empty byte array as NULL for BYTES, but it's not the general way to support NULL for all data types.
We should add another type of index to mark if the value is null, and apply that while filtering or fetching the values to skip all NULL values.

Here is the high-level idea

add isNullable=true/false in the FieldSpec
if isNullable set to true, we can generate a presence vector or null vector. I think presence vector is better than null vector since the query will mostly be x != NULL. Having a presence vector means we don't have to invert the bitmap for every query
Add presence bit vector to DataSource (similar to bloom filter etc)
Nothing changes in the forward index for now. we will still use the default value.
We have two options during query execution 1. users explicitly add x != NULL in the query or we automatically add x != NULL if we see column x as part of the group by or aggregation function.

One open question is, should we restrict generating presence vector to segment creation phase or allow generating them on the fly when we load the segment (similar to inverted index). Generating them on the fly means we need to generate presence vector from the forward index. We can't do this as we represent NULL using the defaultValue in fieldSpec. One workaround is to treat the default value in the forward index as NULL. I think this might work but not 100% sure. Does anyone see any issues with treating default value in forward index implies NULL?
For the first phase, I think restricting it to segment generation phase should be good enough.
Thoughts?

Few thoughts:

How would defaultValue and isNullable in the FieldSpec work? Does one take precedence over the other?
Although I like the idea of presence vector, would it be better to have it a bit more dynamic by allowing for a metadata field that says whether it indicates the presence or absence depending on the type of data? This is an interesting consideration from storage pov (as we can use whatever results in better storage representation), but would make execution a bit non-straight forward.
Do we want to generate the bit vector for metric fields?
Regarding the open question, if we don't allow on the fly generation, how would this work with older segments? I think interpreting existing default values to generate the bit vector sounds ok to me.

@sunithabeeram Changed bullet to the numbered list.

When an input column value is NULL, there are two things we need to consider a. what do we store in the forward index b. How do we support x != NULL in the query without generating inverted index for every unique value. We need defaultValue to support a and this issues is about supporting second scenario.
Not sure if ithe saving in storage space ts worth the complexity, the presence bit vector should be small. This is equivalent of storing one additional posting list.
Yes, metric columns will benefit a lot from this feature
Older segments will continue to use the default values during aggregation and assume that nothing is NULL. If the user is ok with considering defaultValue as NULL, we can support old segments as well by generating NULL vector on the fly.

A few questions:

How do we return NULL in response for selection queries?
If we don't change what is stored in the fwd index, where/how to tie the default null value stored in the fwd index with the NULL keyword in (x != NULL) specified in the query? For new indices (generated after this feature is implemented), is there any value of supporting default null value?
How will presence vector work for MV columns, where one of the MV values is NULL?
From the proposal I take it that the idea is to filter out NULLs during filtering phase of query execution? What about the case where filtered columns don't have NULL, but the column being aggregated has NULL. When/where will these NULLs be filtered so that individual aggregation functions don't need to filter them out explicitly?

Good questions.

We will still return the defaultValues
The only reason we need defaultValue is to avoid storing NULL in the forward index. Typically, column stores skip storing null values in the forward index but that will impact random lookup speed. My goal is  to support NULL without compromising on latency.
I thought we just skip NULL values in MV columns. Presence bit for the row will be set if there is at least 1 non-null value.
This is exactly what we want to avoid. Once we support this feature, one can add x != NULL for any column (it can be filter, aggregation, group by etc) . for e.g. select sum(m1) from T , the user will have to add m1 != NULL explicitly. Eventually, we can automatically rewrite the query to  select sum(m1) from T where m1 != NULL.

For 4: Is there a reason where users would not want to filter out NULL values for metrics? With default value of 0 for metrics, sum works. However, min/max/avg may give incorrect answers in presence of NULLs. And for specialized structures such as TDigest/HLL, the question becomes what value to store in the index such that the it is de-serializable into memory as well as result is not polluted due to presence of NULLs.
Also +1 to building presence vector in segment generation phase.

Can't think of a case where users would NOT want to filter out NULL for metrics. I feel our first goal should be able to give the users to get the behavior they want without compromising a lot on performance.  So for hyperloglog one can do one of the following

Set defaultValue as EmptyHyperloglog().bytes() which is some large byte array
or set defaultNullValue as byte[] but add x != NULL during query.
We support 1 already but it's expensive in terms of storage and performance (if there are too many NULLs). This issue will allow them to do 2.

But, as you mentioned, for aggregation functions such as min, max, avg user can't really get the behavior
they want without support for NULL.

Interacting through the issue is a bit limiting as its hard to reference comments appropriately. Will try my best.
For #1 in the questions I asked;as I think more through this: isNullable seems to just be an optimization hint, correct? All columns are currently nullable, so adding that explicitly could be confusing - what does it mean when a user says isNullable=false and we encounter null values? Should an exception be thrown? (ie, if the column is not set as nullable OR a defaultValue is not specified, throw an excpetion; This is probably a better thing to do in my mind because currently our default defaultNullValues could really backfire for certain aggregations but this is introducing a behavior change - not sure if you had that in mind.)
If its purely an optimization hint, we could probably build the presence vector at all times and avoid the extra field in schema.

@kishoreg  for 4: If it is safe to assume that users would always want to filter out the NULL for metrics, why not implicitly filter out NULLs for metrics in the first implementation (as opposed to eventually)?
@sunithabeeram Re-iterating our offline discussion (to share with all), unless there's a functional reason for adding isNullable in the fieldSpec, I'd recommend not adding it. We should auto derive it (and put in metadata) during segment generation. The only issue would be consuming segments, and in that cases, we can always build the presence vector for all columns. I see the following issues with requiring this information in fieldSpec:

Not always possible for clients to know if a column may contain null, especially, when they don't own the upstream data pipeline.
Yet another config to manage

Good suggestions @mayankshriv @sunithabeeram.
Yes, we can filter out NULLs for metrics automatically if we see the presence vector.
Also, agree with not adding isNullable in fieldSpec. We can generate this for all columns.
@mayankshriv what is the issue with consuming segments?

consuming segments will need a mutable presence vector. While committing the segment to persistent store, the presence vector should also be translated.
This is where I thought the isNullable option will be used. If the user sets isNullable, then we use presense vector. Otherwise we use default value in the fwd index (or dictionary as the case may be). Perhaps call it handleNullValues instead of isNullable. The field is nullable always, just that whether we treat it as null or as default value is the question.
Default value for metric is 0. Metric can very likely have a value of 0, so translating 0 to null value (i.e. building the presence vector on the server while loading) is not an option, I would think.

@mcvsubbu is there an issue if the presence vector is always built?
If I understand things correctly, I believe the current state of handling nullables is a bit unfortunate. The scenario you mentioned is not just an issue for building presence vector, but, as @mayankshriv pointed out, it can actually result in incorrect aggregations.
Is the defaultNullValue of 0 just for metrics? Or is it based on datatype?
In either case, should the actual behavior be corrected? We should not allow default "defaultNullValues" but we elevate the presence vector to a first class citizen - something that should always be present (no pun intended); if users provide a "defaultValue", we can use that if the column is missing for a row (and don't filter it out at any stage?)

@mcvsubbu Presence vector is nothing a but a single roaring bitmap for each column. When we ingest a row, we set the corresponding bit to 1 (not null)/0 (null). In case of real-time, it will be a mutable roaring bitmap and in the case of offline, it will be an immutable roaring bitmap.

Exactly what I was thinking. However, don't we need a switch to decide whether to use presence vector or retain current behavior? Or, are you thinking that the current behavior will be obsoleted (i.e. null becomes default value)

@mcvsubbu is there an issue if the presence vector is always built?
No issue, just that we change the behavior from what people are used to. I am guessing there is at least someone out there who relies on the fact that a null will be auto-populated by default null value. Many applications also set custom default null values in their schema.
If I understand things correctly, I believe the current state of handling nullables is a bit unfortunate. The scenario you mentioned is not just an issue for building presence vector, but, as @mayankshriv pointed out, it can actually result in incorrect aggregations.
Is the defaultNullValue of 0 just for metrics? Or is it based on datatype?
0 for metrics, and Long.MIN or Int.MIN or "null" for dimensions.

In either case, should the actual behavior be corrected? We should not allow default "defaultNullValues" but we elevate the presence vector to a first class citizen - something that should always be present (no pun intended); if users provide a "defaultValue", we can use that if the column is missing for a row (and don't filter it out at any stage?)

@mcvsubbu there is absolutely no change in the existing behavior on what gets stored in the forward index in the segment. null values will be auto-populated with the default value. The only change I am proposing is to have an additional presence vector that will allow the users to skip rows where x is NULL by adding a predicate x != NULL. This will make sure that there is no change in existing behavior (even though its incorrect in some cases). Mayank is suggesting that we add this predicate automatically if x is a metric. This will fix the incorrect behavior. We can control this behavior via some feature flag if needed.

Just adding predicate x != NULL is not good enough. We need to plug-in the NULL handling logic into all predicates as well. E.g. x = NULL, x != n (other than NULL), x NOT IN (a, b, c) (other than NULL) should return true, all other predicates should return false.

@Jackie-Jiang yes.
Also, you logged an issue to document the behavior of default value #4188. Having that will definitely help. Is anyone working on that?

@kishoreg bumping up one point which I would like to get explicit acknowledgement/agreement on.
Currently, all columns are nullable. If user doesn't specify a defaultNullValue, we use "default" values (as mentioned in the description of this issue as well as confirmed by @mcvsubbu in one of the comments). The problem with the "default" defaultNullValues is that they can result in incorrect behavior for metrics or dimensions. I think it is important that this be corrected as we attempt to build presence vectors. Here is the behavior I would like considered going forward:

Do not use default defaultNullValues. Use presence vectors to guide decisions in the rest of the exeuction phases as needed.
If users specify defaultNullValue, that is used when the data for column is missing; the presence vector in this case does not indicate that the value is "missing".
To maintain backward compatibility, existing schemas are updated to explicitly add the "default" defaultNullValues in the schema. (We may need some versioning info in schema config to direct this correctly).

If the above is not acceptable, it would be good to clarify the reasons we think its OK to continue with the existing default defaultNullValues in the face of incorrectness. And we should update the user facing documentation so its clear to users what they can expect.
Let me know what you think.

We should avoid asking users to upgrade schema to maintain backward compatibility. It will be challenging operationally.
If I understand you correctly, what you are suggesting is basically the same as my original proposal - adding isNullable field. Instead of adding isNullable explicitly in the fieldSpec you are proposing deriving that based on the presence/absence of defaultNullValue. I prefer having isNullable explicitly instead of deriving it based on defaultNullValue.
It might be easier if we break this into two parts and look at the options on the table. Segment Generation and query execution.
Segment Generation (Creating Presence Vector): Options

Create the presence vector by default for all columns. If the column is present and not null in the row, set the presence bit.
Create the presence vector only when isNullable = true  or createPresenceVector = true. By default createPresenceVector = false
Same as 2 but derive it based on presence/absence of defaultNullValue

Query Execution: Options

Let users use x != NULL explicitly in the query to filter out rows with NULL values
Pinot automatically uses the presence vector in the query execution as needed.

Note: We are not going to change what's stored in the forward index. We will always use defaultNullValue (it can be default defaultNullValue based on dataType or something user specifies in the schema).
I prefer starting with option 2 for Segment Generation and option 1 for Query Execution. This will be backward compatible with current behavior and provide the flexibility to the user to achieve the behavior they want by changing the fieldSpec and query as needed.
We can always move to 1 in Segment Generation by changing the default value of createPresenceVector=true in phase 2.  We can also start to move to option 2 for Query Execution over time.

I would prefer always assume all columns are nullable unless users explicitly mark it nonNull (which is very rare, but might be useful for boolean type. A default null value is required).
For the existing segment, leave it as is. For default column, generate empty presence vector if the column is nullable.
For query execution, we should automatically filter out NULLs as needed, and also support explicit filters on NULLs.

In the long term, may be we can consider leveraging Apache Arrow's inmemory columnar and wire format for our execution engine, then we will get support for nullability as part of moving to Arrow (not suggesting that we should move to Arrow to support nullability but bringing up Arrow as something we may want to consider).
An Arrow vector is an off-heap data structure for a column of any particular type (it supports both primitive and complex type). The vector has 2 buffers in direct memory -- data buffer for storing column values and nullability buffer (a bitmap) for indicating if the corresponding column value is NULL or not.

@siddharthteotia Yes, at some point we would love to support various formats such as Parquet, ORC etc and Arrow will definitely be something that we can consider. For now, Pinot execution code is tightly coupled with storage format and bringing in Arrow will require a lot of changes.

@kishoreg One potential issue with Query Execution Option 1 (explicitly add x != NULL) is when there are multiple aggregations: eg: select sum(col1), avg(col2) where ... col1 !=NULL AND/OR ... col2 != NULL
Here we need to come up with the right filtering condition. Do you think making it implicit might be better ?

@icefury71 Good point. I think the challenge is to come up with the right filtering condition. Whether the filtering is explicit or implicit is just a syntactic convenience.

Updating this thread with some of the offline discussions I had with a few folks (Devesh and @fx19880617 ). This proposal is to filter out null values in the form of predicates (leaf nodes of query execution). This has 2 potential issues:

Incorrect results when transforms are used in aggregation functions (eg: MAX(ADD(A, B)) if either A or B is null, ADD should return NULL. However if we filter out nulls very early, then we will return a non null value here - which is not consistent with ANSI SQL.
Multiple aggregation functions in the same query: This also might be inconsistent if we filter out the nulls very early in query execution.

Looks like a better approach might be to "tag" DocIDs as null or non-nulls and let the aggregation function (or another intermediate node) process it in the right manner. However, this will affect the entire query execution flow and is a much bigger effort than what's proposed in this issue.
Thoughts ?

@icefury71 Good questions. I don't have a good answer. Let's create a separate issue on how to use presence vectors in the query execution layer. At a high level, there are 3 possible options

users explicitly specify the predicate in the query.
Pinot implicitly updates the where clause appropriately based on the query
Pinot passes the presence vectors to the aggregation functions so that each function can handle it appropriately.

For now, let us focus on supporting 1. we can start design discussion for  2/3

Opened PR: https://github.com/apache/incubator-pinot/pull/4585

I'm trying to plot a timeseries with gaps showing null/missing data.
Trying to avoid doing:

Caller-side mask on the data and the NULL value vector.
Caller-side mask using some defaultNullValue.

Can this be done in the query?

I'm trying to plot a timeseries with gaps showing null/missing data.
Trying to avoid doing:

Caller-side mask on the data and the NULL value vector.
Caller-side mask using some defaultNullValue.

Can this be done in the query?

I'm not sure I understand your question. I'm assuming you want to filter out null values in your query response, does the column IS NOT NULL not work for you ?
Or do you want this to happen automatically without specifying such predicates ?

No I want to include null values but as null and not as defaultNullValue so I can distinguish the two cases.
If defaultNullValue is zero and nullHandling is enabled and some points are actually zero.
t: 1 v: 110
t: 2 v: 0     <- actually zero
t: 3 v: 114
t: 4 v: null  <- null
t: 5 v: 113
So I can make a plot with gaps:
https://codepen.io/curriedfloat/pen/WNprwWP

Unfortunately that's not possible with the current implementation. Current implementation will ignore nulls or treat them as default values in the filter operator. Everything else in query processing currently, does not need to care about nulls. It is definitely in the scope of this issue to ensure all query processing layers can handle null values - however hasn't been done yet.

Hi, (just want to make a summary of this) in this case if a column in INT type, and we would like to check IS NOT NULL value, does it mean we need to do
column IS NOT NULL AND column != 0

@monicaluodialpad If the purpose is just to exclude the null values, with the null value enabled, column IS NOT NULL is enough, which won't filter out the actual 0s


mold: 1.4.0 -> 1.4.2

Description of changes
Also added myself as a maintainer and did a big refactor.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Would also be good if we could de-vendor the bundled tbb and mimalloc at some point.

Would also be good if we could de-vendor the bundled tbb and mimalloc at some point.

I've managed to compile it with our mimalloc. I didn't however make our TBB work with mold: I even tried doing something like this because our TBB doesn't supply a CMake module but that didn't work because of (I'm assuming) how old out TBB is.
I would be glad if someone could help me check if this works on MacOS because waiting for ofborg to build this is going to take a while.

Builds & runs for me, macos 10.15.

Hmm, it fails on aarch64-linux because the <span> header is missing. People already hit this bug in #178258. Should I mark aarch64-linux as broken?

Yes, my comment was only really about macos, because I immediately recognized the error. I don't off the top of my head know how to fix the aarch64 issue.

Done.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/1016/20

@risicle @SuperSandro2000 can we get this merged?


Create CONTRIBUTING.md

I think I have input for that. Will provide a draft if OK.

I think I have input for that...

Surely Marcel, you are much better at writing than I am. Feel free

ping @marcellanz

@sleipnir I'm guilty :)

@sleipnir will be a task inline with what we do in our roadmap for Code BEAM.

I think so
Em qua., 2 de jun. de 2021 às 18:13, Marcel Lanz @.***>
escreveu:

@sleipnir https://github.com/sleipnir will be a task inline with what
we do in our roadmap for Code BEAM.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eigr/massa/pull/23#issuecomment-853386163, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACTTZRXPVSH3ICH45KIKNTTQ2NHHANCNFSM4ZNOD6IQ
.

--
Adriano P. Santos
"O homem erudito é um descobridor de fatos que já existem - mas o homem
sábio é um criador de valores que não existem e que ele faz existir."
Albert Einstein

opened https://github.com/eigr/massa/pull/50
@sleipnir sorry for the duplicate; found out just now that this one aleady exists and is not an issue.


Add analysis to extract eval expressions

This commit adds an analysis to extract expressions
passed to eval. The necessary analysis infrastructure
has also been developed in the process. The analysis
infrastructure follows the Observer pattern.
AnalysisDriver implements the subject of the Observer
pattern. It stores a reference to each analysis object
and calls its appropriate method.
EvalExpressionAnalysis implements the observer that
extracts the expression passed to eval.
A couple of other classes have been created -
Configuration is a lightweight object that stores
settings passed to the tracer.
TableWriter is a simple writer for tabular data. It
provides configurable row and column separators.
State class encapsulates the AnalysisDriver and
Configuration. It essentially encapsulates the user facing
state of the tracer.
spdlog has been removed. dyntrace_log_{info, error, warn}
are suitable replacements for it. spdlog increases compilation
times and does not really provide any required functionality
over its replacements.

There are 2 things missing from this implementation, I will add them tomorrow.

An updated README.md file for the new Makefile rules.
The technique to extract expr from the eval assumes that the expr is alway the first argument to eval. This may be generally true but is an incorrect assumption. One can use keyword arguments and change the order.

I think I have addressed all my self goals on this pull request. I will merge it now.


refactor: cleanup and optimize code order

Remove redundant comments
Move some check to top of functions
Change order of some return events
Refactor some load commands

Codecov Report
Patch coverage: 95.65% and project coverage change: -0.59% :warning:

Comparison is base (a19e2be) 85.66% compared to head (dad1675) 85.08%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
- Coverage   85.66%   85.08%   -0.59%
==========================================
  Files           4        4
  Lines         307      295      -12
==========================================
- Hits          263      251      -12
  Misses         44       44

Files Changed
Coverage Δ

contracts/halo-farm/src/contract.rs
87.38% <95.65%> (-0.67%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


rearrange search bar

added change for search bar form on search enter

hey @16BitNarwhal can you please take a look here?

@nicoella maybe add a screenshot of the new UI to this thread?

https://github.com/user-attachments/assets/834ec8ab-5e74-48b1-9822-fac163cb66e9
Here's a demo video!


why do you use Redis Pubsub

Hi, I am reading your project and I love this project
I have a question, why do you choose Redis Pubsub in your project instead of others like RabbitMQ or Kafka, are there any special features that others dont have it. Can you share me it. I am wondering when I should choose Redis Pubsub instead of others like RabbitMQ or Kafka

Her @MaryLilian , glad you found this useful, the reality is that this package in particular only enhance the already there Redis pub-sun system, so only if you have already chosen Redis for you go solution, this package can be of help to you, for example if you need performance over keeping a truthful state of the messages that have been sent, then you can go with Redis intend of Kafka.


Add support for controlling which side ActionMenu renders on (via a side prop on ActionMenu.Overlay)

Adds a side prop to ActionMenu.Overlay so the consumer can control which side of the anchor the ActionMenu renders on. This prop is forwarded verbatim to ` Also adds a story and updates docs.
Closes https://github.com/primer/react/issues/3712
Screenshots

Merge checklist

[ ] Added/updated tests
[x] Added/updated documentation
[x] Changes are SSR compatible
[x] Tested in Chrome
[ ] Tested in Firefox
[ ] Tested in Safari
[ ] Tested in Edge
Stacks on:

[ ] https://github.com/primer/react/pull/3713

Can we also add a story with nested menus to keep in examples of the ideal use case?

Unfortunately the nested menu case requires a bit more wiring up than that because of keyboard navigation & roles. We are internally working on a NestedActionMenu component which I think we should probably eventually upstream to Primer.