Remove is_expand: false from is_compress input

by forcing is_expand false by default:
is_compress: "false"
    opts:
      ...
      is_expand: false

I cannot pass in an environment value into this step like this:
    -<EMAIL_ADDRESS>        inputs:
        - is_compress: $MY_COMPRESS_OPTION

which blows.  When I attempt to do so by specifying opts: -is_expand: false on the is_compress input, I get:
Error: Config (path:bitrise.yml) is not valid: failed to cast options value: ([]interface {}{map[interface {}]interface {}{"is_expand":true}})

When I attempt to do so by specifying

Most likely an indentation issue.
Please try it this way:
    - deploy-to-bitrise-io:
        inputs:
        - is_compress: "$MY_COMPRESS_OPTION"
          opts: { is_expand: true }

is_compress (the input's key) and opts have to be indented to the same "column"


[EventHubs] Support for Custom endpoint adddress and custom certificate

addressing issues: https://github.com/Azure/azure-sdk-for-python/issues/16047
also see gist: https://gist.github.com/jsquire/f0948c9a5ffe2741b03d312dcf8d899e
Champion Scenarios
Connecting on a restricted network
A local hospital employs a strict set of network policies to ensure the safety of their network and the security of their patient information. As part of this strategy, all traffic is routed through a security proxy which performs a threat analysis and logging of connections.
In order to allow for trusted internal applications to embrace cloud services, a special bank of IP addresses has been reserved which passes through a secure DMZ path rather than the security proxy. In order for trusted connections to work appropriately, they must resolve to one of the reserved IP addresses using a CNAME configured in the local DNS service.
Because of these restrictions, applications are unable to perform direct connections to the Azure Event Hubs service using the standard endpoint address and require the ability to specify a custom host name to ensure they route through the proper intermediary for the connection to be made.
sample code:
# use constructor
consumer_client = EventHubConsumerClient(
        "<FULLY QUALIFIED NAMESPACE>",
        "<EVENT HUB NAME>",
        "<CONSUMER GROUP>",
        credential,
        custom_endpoint_address="sb://eventhubs.mycompany.local",
        connection_verify="path_to_cert_file"
)

# use connection string
consumer_client = EventHubConsumerClient.from_connection_string (
        "<CONNECTION STRING>",
        "<CONSUMER GROUP>",
        custom_endpoint_address="sb://eventhubs.mycompany.local",
        connection_verify="path_to_cert_file"
)

Test:
by following the steps in

https://github.com/Azure/azure-sdk-for-js/pull/12909#issue-540828683
https://gist.github.com/chradek/d4d6ce32ef4c5b46bf55d6e1b979b991
I'm able to set an Azure Applicate Gateway and verify this feature

Pending:
pending uamqp v1.2.14 release: https://github.com/Azure/azure-uamqp-python/pull/202

/azp run python - eventhub - tests

/azp run python - eventhub - tests

/check-enforcer evaluate

/check-enforcer override

/azp run python - eventhub - tests

/azp run python - eventhub - ci

/check-enforcer evaluate

/check-enforcer evaluate

/azp run python - eventhub - tests

/check-enforcer override


Add spring with binstubs

Create binstubs for rails, rake, and rspec

Looks fine to me

Why do we need Spring?

Having spring makes the rails tests feel as fast as the non-rails tests, which always gives me a warm little feeling inside.
It's not like we're in a dire need of spring, but it just feels little better

We've been pretty conscious about keeping Hound's test suite fast. spring tends to "hide" the fact that the tests suite is slow -- if it's an obvious pain then we should work to improve the speed of the tests. Also, on the minor note, there are certain issues with spring that can waste hours of time debugging, because it didn't pick up the latest change.
Right now, on my machine, the test suite runs in under 30 seconds.
I'm :-1: on this, as I see spring as a crutch, and I'd like to keep it out.

I agree, let's avoid including spring unless we need it.

Thanks for weighing in @gylaz, @salbertson. I'll close this and we'll revisit this once we feel the need for spring


SLO URL

Hi,
I have installed plugin as a SP and unable to find a URL on plugin which will receive the Logout Response from my IDP. Like there is an ACS Url to consume Assertion, what is the Url to consume Logout response, and does it support POST.
Also how to set up SP private key in plugin, I have dumped it in certs folder but it doesn't work.
Thanks.
Sumit

You can see it on the metadata of your SP which link appears on the WP SAML settings configuration panel. Be sure you previously enabled Single Logout and saved the configuration with this parameter enabled.

Thanks for your prompt response Sixto. Though I was able to figure out the SLO link and able to successfully log out, but I am still having problems with setting Service Provider Key on the plugin. I am dumping the sp.key in the certs folder but it's unable to read the key. I have a pfx file which I renamed with .key extension and put it in certs folder. Please suggest.
Sumit

I have set up the key and certificate on the server. Hence closing


deleteOnFileDelete:true marks files as deleted if deleted from Windows Explorer

I'm using VSCode 1.11.2 with vscode-perforce 2.0.1.
Reproduction case:

Enable perforce.deleteOnFileDelete. Restart VS Code to ensure the option is honored.
Open a folder that's tracked by Perforce with VSCode. Expand the tree view to reveal files.
Also open that folder in the Windows Explorer.
From the Windows Explorer window, delete one file that's visible in VSCode's tree view.
Observe that the file was marked as deleted in the P4 workspace's default changelist.

This might be intended behavior, but I'd only expect vscode-perforce to mark as deleted the files that I'm explicitly deleting from within VSCode (especially since re-creating those files does not re-add them).

cc @jel-massih

Yeah it uses a filesystemlistener so anything that affects the files while extension is running will get picked up.
I think a better course would to be more naturally handle delete/add (so if a file is marked for delete then re-added, it would be marked for edit).


New package: michidk.vscli version 0.1.4

Pull request has been created with Komac v1.10.1 :rocket:
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Exception during executable launch operation System.AggregateException: One or more errors occurred. (The specified executable is not a valid application for this OS platform.)  ---
System.ComponentModel.Win32Exception (216): The specified executable is not a valid application for this OS platform.
--- End of stack trace from previous location where exception was thrown ---    --- End of inner exception stack trace ---    at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)

Installing in a 64-bit Windows VM gives a message indicating a dependency on VCRedist:

Manual Validation ended with:

Apparently the dependency isn't being installed.

Apparently the dependency isn't being installed.

I am not sure how I would fix that.

@wingetbot waivers Add Validation-Executable-Error


Text template required even when using only put_html_layout

Hey there,
Firstly, just wanted to thank you for creating/maintaining the Bamboo family of libs, they really make email rendering easy!
I am using bamboo-phoenix to render email templates using Phoenix views.
I setup a basic example:
my_app_web/emails/invite.ex

defmodule MyAppWeb.InviteEmail do
  use Bamboo.Phoenix, view: MyAppWeb.EmailView

  def invite do
    new_email()
    |><EMAIL_ADDRESS>    |> put_html_layout({MyAppWeb.LayoutView, "email.html"})
    |><EMAIL_ADDRESS>    |> subject("You've been invited")
    |> render(:invite)
  end
end

my_app_web/views/email_view.ex

defmodule MyAppWeb.EmailView do
  use MyAppWeb, :view
end

my_app_web/templates/email.html.eex

    <%= render @view_module, @view_template, assigns %>

my_app_web/templates/email/invite.html.eex

You've been invited!

I have a basic test, just to ensure the email is successfully created, however, when I run the test I get the following error:
     ** (Phoenix.Template.UndefinedError) Could not render "invite.text" for MyAppWeb.EmailView, please define a matching clause for render/2 or define a template at "lib/my_app_web/templates/email/*". The following templates were compiled:

     * invite.html

     Assigns:

     %{view_module: MyAppWeb.EmailView, view_template: "invite.text"}

     Assigned keys: [:view_module, :view_template]

          stacktrace:
       (phoenix 1.5.7) lib/phoenix/template.ex:337: Phoenix.Template.raise_template_not_found/3
       (phoenix 1.5.7) lib/phoenix/view.ex:472: Phoenix.View.render_to_iodata/3
       (phoenix 1.5.7) lib/phoenix/view.ex:479: Phoenix.View.render_to_string/3
       (bamboo_phoenix 1.0.0) lib/bamboo_phoenix.ex:283: Bamboo.Phoenix.render_html_and_text_emails/1
       test/my_app_web/emails/invite_test.exs:5: (test)

If I add an invite.text.eex template, then the test runs just fine, however, I'm only calling put_html_layout({MyAppWeb.LayoutView, "email.html"}) from my email module, so not sure why it requires me to also have a text template.
Any help would be greatly appreciated!

Hi @sepowitz thanks for opening the issue.
When passing an atom, Bamboo assumes you want to render both html and text templates. If you only want to render the html template, you should change the render call to pass a string:
my_app_web/emails/invite.ex

defmodule MyAppWeb.InviteEmail do
  use Bamboo.Phoenix, view: MyAppWeb.EmailView

  def invite do
    new_email()
    |><EMAIL_ADDRESS>    |> put_html_layout({MyAppWeb.LayoutView, "email.html"})
    |><EMAIL_ADDRESS>    |> subject("You've been invited")
-    |> render(:invite)
+    |> render("invite.html")
  end
end

That's highlighted in the render/3's docs, but if you have suggestions for improving those docs, contributions are always welcome.
Let me know if that fixes your issue.

@germsvel Really appreciate it! Fixes my issue.


Update DBT JSON Schema

We should make the DBT config and security requirements more epxlicit
{
  "$id": "https://open-metadata.org//schema/entity/services/ingestionPipelines/databaseServiceMetadataPipeline.json",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "DatabaseServiceMetadataPipeline",
  "description": "DatabaseService Metadata Pipeline Configuration.",
  "definitions": {
    "databaseMetadataConfigType": {
      "description": "Database Source Config Metadata Pipeline type",
      "type": "string",
      "enum": [
        "DatabaseMetadata"
      ],
      "default": "DatabaseMetadata"
    },
    "dbtConfig": {
      "description": "DBT Catalog and Manifest file path config.",
      "type": "object",
      "properties": {
        "dbtCatalogFilePath": {
          "description": "DBT catalog file to extract dbt models with their column schemas.",
          "type": "string"
        },
        "dbtManifestFilePath": {
          "description": "DBT manifest file path to extract dbt models and associate with tables.",
          "type": "string"
        }
      },
      "additionalProperties": false,
      "required": ["dbtCatalogFilePath", "dbtManifestFilePath"]
    }
  },
  "properties": {
    "type": {
      "description": "Pipeline type",
      "$ref": "#/definitions/databaseMetadataConfigType",
      "default": "DatabaseMetadata"
    },
    "markDeletedTables": {
      "description": "Optional configuration to soft delete tables in OpenMetadata if the source tables are deleted.",
      "type": "boolean",
      "default": true
    },
    "includeTables": {
      "description": "Optional configuration to turn off fetching metadata for tables.",
      "type": "boolean",
      "default": true
    },
    "includeViews": {
      "description": "Optional configuration to turn off fetching metadata for views.",
      "type": "boolean",
      "default": true
    },
    "generateSampleData": {
      "description": "Option to turn on/off generating sample data during metadata extraction.",
      "type": "boolean",
      "default": true
    },
    "sampleDataQuery": {
      "description": "Sample data extraction query.",
      "type": "string",
      "default": "select * from {}.{} limit 50"
    },
    "enableDataProfiler": {
      "description": "Run data profiler as part of this metadata ingestion to get table profile data.",
      "type": "boolean",
      "default": false
    },
    "schemaFilterPattern": {
      "description": "Regex to only fetch tables or databases that matches the pattern.",
      "$ref": "../type/filterPattern.json#/definitions/filterPattern"
    },
    "tableFilterPattern": {
      "description": "Regex exclude tables or databases that matches the pattern.",
      "$ref": "../type/filterPattern.json#/definitions/filterPattern"
    },
    "dbtProvider": {
      "description": "Method from which the DBT files will be fetched. Accepted values are: 's3'(Required aws s3 credentials to be provided), 'gcs'(Required gcs credentials to be provided), 'gcs-path'(path of the file containing gcs credentials), 'local'(path of dbt files on local system), 'http'(url path of dbt files).",
      "type": "string",
      "enum": ["local", "http", "gcs", "gcs-path", "s3"]
    },
    "dbtConfig": {
      "$ref": "./#definitions/dbtConfig"
    },
    "dbtSecurityConfig": {
      "description": "DBT configuration.",
      "oneOf": [
        {
          "$ref": "../security/credentials/gcsCredentials.json"
        },
        {
          "$ref": "../security/credentials/awsCredentials.json"
        }
      ]
    },
    "dbtCatalogFileName": {
      "description": "DBT Catalog file name",
      "type": "string",
      "default": "catalog.json"
    },
    "dbtManifestFileName": {
      "description": "DBT Manifest file name",
      "type": "string",
      "default": "manifest.json"
    }
  },
  "additionalProperties": false
}

cc @OnkarVO7


can't open doc site (https misconfig)

Open https://docs.pybitshares.com/ with Chromium, you'll get this prompt:

This server could not prove that it is docs.pybitshares.com; its security certificate is from *.readthedocs.io. This may be caused by a misconfiguration or an attacker intercepting your connection.

README says http://docs.pybitshares.com/ (without "s").

oops, sorry, my 'https everywhere' addon added 's' automatically.
BTW, any plan to make it https available? (though trivial)

See here https://github.com/rtfd/readthedocs.org/issues/2652


radial-gradient doesn't work on chrome

Hey,
@include radial-gradient(#1e5799, #3dc3d1);
produces:
    background-image: -webkit-radial-gradient(#1e5799, #3dc3d1, , , , , , , , );
    background-image: radial-gradient( #1e5799, #3dc3d1, , , , , , , , );```

which is invalid syntax for Chrome (version 45)

This is probably an issue that occurs when using libsass. See #729 for more information.

@kazkovsky Are you compiling with LibSass? If not, can you provide more details regarding your dev environment?
Also: are you sure you still need prefixes? Support for gradients these days is pretty strong: http://caniuse.com/#feat=css-gradients
I would use Autoprefixer, instead of Bourbon, if you do indeed need prefixes…

I'm also compiling with libsass, and can confirm linear gradients not always work on Firefox even if they work on Chrome and Safari.

Personally, I’d use Autoprefixer if you’re looking to prefix your gradients. But you can find a workaround for Bourbon via my comments in both #767 & #729.

Oh, I didn't realize vendor-prefixing was out of scope for Bourbon..?

@jareware We are removing them in v5: https://github.com/thoughtbot/bourbon/issues/702

Ah, solid reasoning, :+1:!


typo fix

@rwhitmire : Thanks for your contribution to the Azure documentation! The author, @chackdan, has been notified to review your proposed change.

#please-close.
Thankyou for the suggestion for the change. I have already made that fix in the document. I truly appreciate you taking the time to review the document.


Configuration updates for GitHub pages review

To ease the review of idr.openmicroscopy.org PRs, this adds the functionalities already used by https://github.com/openmicroscopy/www.openmicroscopy.org:

a default _config.yml  file is created that sets the baseurl to idr.openmicroscopy.org so that URLs like https://idr.github.io/idr.openmicroscopy.org/ and https://snoopycrimecop.github.io/idr.openmicroscopy.org/ render the latest and merge version of this repo
a _prod.yml configuration file overrides the baseurl for production deployment. This file is consumed in the build.sh script used by Travis to create release artifacts
the build.sh is updated to use the pages tag of the jekyll/builder Docker image

With a CI job pushing to http://github.com/snoopycrimecop/idr.openmicroscopy.org (master or gh_pages branch), this should be deployed on https://snoopycrimecop.github.io/idr.openmicroscopy.org/ for review

Latest version of this branch now integrated and deployed at https://snoopycrimecop.github.io/idr.openmicroscopy.org/. Note the 3c08d67 removes the build time variable dependencies on https://github.com/IDR/deployment but means an extra PR might be necessary in all cases for bumping the IDR version number in _config.yml even with no change to the content of the Jekyll site.

@manics feel free to open https://github.com/IDR/idr.openmicroscopy.org/pull/30#pullrequestreview-142776847 directly against this repo now this is integrated (I suspect we might need a corresponding deployment PR to validate the workflow)


Defer parts of style resolution and layouting

Resvg currently draws SVGs without any context. While rendering SVGs in isolation works for one-shot rasterization of standalone files, it doesn't allow for integration with documents and UI.
I'm suggesting the resvg::render function signature changes into something like:
pub fn render(
    tree: &usvg::Tree,
    context: resvg::Context,
    pixmap: &mut tiny_skia::PixmapMut,
)

where resvg::Context holds the Transform as it previously did but also top-level defaults:

text properties

alignment-baseline
baseline-shift
color a.k.a. currentColor
direction
dominant-baseline
font-family
font-size
font-size-adjust
font-stretch
font-style
font-variant
font-weight
glyph-orientation-horizontal
glyph-orientation-vertical
letter-spacing
text-anchor
text-decoration
unicode-bidi
word-spacing
writing-mode

fill & stroke

color-interpolation
color-interpolation-filters
color-rendering
fill
fill-opacity
fill-rule
stroke
stroke-dasharray
stroke-dashoffset
stroke-linecap
stroke-linejoin
stroke-miterlimit
stroke-opacity
stroke-width
marker-end
marker-mid
marker-start
opacity

convenience

filter - can be applied top-level with tiny_skia

filters

flood-color
flood-opacity
image-rendering
lighting-color
mask
overflow

render options (currently static in usvg::Options)

shape-rendering
text-rendering
vector-effect

transform (set in tiny_skia; currently passed in directly)

also transform-origin

Some of these are currently set in usvg::Options, but usvg shouldn't resolve computed values unless it's an obvious optimization (e.g. parent has explicit value and child has inherit; outer ctx doesn't matter). Output of usvg parsing an SVG document should really be a function which produces a different usvg::Tree based on the values above or some new usvg::ResolvedTree type.
usvg handles text-to-path conversion so a lot of text related options should really be passed into usvg::text::layout::layout_text and text layouting should be deferred too.

Don't take my word for it, but the goal of usvg is to turn the SVG into a representation that is as simple as possible, so that it's easy to build a renderer on top of it. Not resolving relative units during the creation of the tree would complicate the tree a lot (How would you resolve objectBoundingBox for example if you don't know the actual size in px?), which kind of goes against the philosophy of usvg. I guess that point is a bit moot if it were implemented, like you mentioned, as an additional intermediate represetnation (Tree vs ResolvedTree), but that would also come with a bit of overhead.
I don't really get the problem though, why can't you just create a new usvg tree and populate it with the corresponding values in Options (leaving aside the fact that some of the options you mentioned aren't configurable yet)?

Don't take my word for it, but the goal of usvg is to turn the SVG into a representation that is as simple as possible, so that it's easy to build a renderer on top of it.

Externally, but passing Options to usvg in a separate call from parsing is an improvement.

How would you resolve objectBoundingBox for example if you don't know the actual size in px?

It depends on where I'm rendering it. If it's a dropdown menu icon then it's smaller, but if I draw the same icon in toolbar then it will be larger. Currently (hypothetically), I'd have to multiply the bounding box with the transform I'm passing to tiny_skia which is less convenient.

Creating a tree isn't that expensive, the expensive part is usually rendering it.

If I want to animate SVG colors I need to parse XML every frame - that part makes no sense to me. XML parsing is an added cost, and it's much slower than simply rendering after configuration (clone). This becomes much more apparent if you want to animate 10+ SVGs at once.
The properties I listed are just what SVGs pick up from surrounding context in browsers. The same mechanism allows a bunch of different animations via #821 or <animate> (for which it's required).
I can work around this limitation by generating a lot of animations at build time (for icons), but deferred evaluation is one of the big pieces that allow the format to be fully interactive.

In short, this is not possible and not planned. You need a separate library for that.
Also, if you want to change SVG appearance - the only correct way to do so is by CSS style injection, which we already support. Which obviously requires re-parsing.
I think you fundamentally misunderstand how SVG works, because I do not see how resvg::Context can meaningfully change the document's style.

If I want to animate SVG colors I need to parse XML every frame

Rendering SVG in real-time is a fruitless endeavor. It's not possible. SVG isn't designed for fast rendering.

I think you fundamentally misunderstand how SVG works, because I do not see how resvg::Context can meaningfully change the document's style.

I think you skimmed through this too much because I know you wrote code which maps "auto" attribute values to 0 and defaults text color to black. I know you understand those values are something browsers propagate from parent HTML document for inlined SVGs, the spec says they're implementor defined, and that they affect the final appearance of the document.
It's a meaningful difference if I draw a black icon on a dark gray bg, or a red one.

Rendering SVG in real-time is a fruitless endeavor. It's not possible. SVG isn't designed for fast rendering.

Same goes for OBJ - which is why engines apply skeletal animations to an in-memory format.
The problem is internal representation which destroys structural information used by browsers to animate SVGs, not some inherent limitation of the format itself. You could parse Lottie (for some given frame) into the same structure used by usvg and you'd have the same problem with having to re-parse the JSON to draw another frame.
In other words, the usvg library wasn't designed with this goal in mind, and you don't intend to do such a large redesign.

I'm well aware how a browser handles user styles. And if you look at Chrome's inspector, you will notice that you basically define a user CSS, which is exactly what style injection does in resvg.
Not only you need an ability do define which elements must be affected by a certain style override, but in many cases a style change would cause the whole tree recalculation (like for stroke width change or text font change). So you will still end up re-parsing/recalculating everything.
And no, resvg isn't designed to modify already parsed tree. Unlike browsers, the original SVG tree isn't preserved and you would need a brand new library to achieve that. Which is exactly what I wrote already.


Error: The gulp task detection didn't contribute a task for the following configuration

VSCode Version: 1.30 (Nov 14 build)
OS Version: Ubuntu 18.04

Steps to Reproduce:

Clone https://github.com/LoneSimba/RCSE.git
(Optional) Change anything in /public_html/themes/RCS/pages/main_template/*.scss
Try running "Terminal->Run Task", it will output "Error: The gulp task detection didn't contribute a task for the following configuration" and the rest of it.

Does this issue occur when all extensions are disabled?: Yes
This does not happen on Windows, but always occur on Ubuntu (at least, never tested on other Linux systems). Is there a way over this trouble, or just work with SCSS on Windows?

@LoneSimba the reason for this is that under Ubuntu VS Code can't find the gulp command. Do you may be have it installed globally on Windows but not under Ubuntu ?

@dbaeumer sorry for not responding, have been busy a little. Gulp is installed both globally and locally on both Win and Ubuntu

Decided to check one more time. Globally it wasn't installed ('cause of this: https://github.com/sass/node-sass/issues/1098), but even after installation haven't any success on finding gulp tasks.BTW, even updated to newest version available of insiders

@LoneSimba can you provide me with a GitHub repository that demos this?

@dbaeumer It's the same with in first post here.

@LoneSimba, check the output from Gulp Auto Detection (in the output pane it's in the dropdown menu). I found a couple issues in there that were easily fixed. In your repo I had the wrong version of gulp-sass installed and gulp.task only takes two parameters.

Actually, even in VSCode Task Guide usage of gulp.task with 3 params present. And this composer was based on that guide (but it looked differently in sept). And this code works just fine on Windows PC. So, it's something with Linux version. BTW, this trouble (gulp autodetection) brings arse-pain to lots of users.
If my gulptask.js is wrong, can you show expacle of improving it?

I'll look into the VSCode Task Guide, thank you for pointing it out! I just went through the issues in the Gulp Auto Detection output to see how I could make it work.


Update the schema and ingestion code to support noisy relations

Need to specify which relations/observations are noisy

What do you think about moving the model 4 hirm schema to look a bit more like PClean class variable declarations?  Something like:
R1 ~ bernoulli(D1)
R3 ~ bigram(D2)
R6 ~ normal(D1)
R2 ~ gaussian(R6; D1, D2)
R4 ~ gaussian(R2; D1, D2, D3)
R5 ~ sometimes_bitflip(R1, D1)
The primary benefit would be readability; "R6 ~ normal(D1)" is IMHO a lot more understandable than "clean normal R6 D1".  But having the same syntax between the two schemas would also help lower cognitive barriers to entry (and perhaps even allow some code reuse).

Yep!  I'm planning on basing the Model 5 schema pretty heavily on PClean.

Cool, I'll update #95

I didn't get to #95 today -- let me know if you'd rather take it over, since you're owning the schema stuff and probably have a better sense of how it fits with Model 5 and where/how code can be reused. Otherwise I'll try to do it tomorrow.

I could take over #95 if you like.  The schema will have to be slightly different, because HIRM relations are (in the schema) conditioned on domains and PClean class variables aren't.  But some the parsing code could be shared.

Thank you, I'd appreciate that!


Attribute pairs with names like 'name' and 'name_id' are unsettable.

This is a bit of an odd one, minimal failing example with a work around available here: https://github.com/mbell697/factory_girl_bug_example (tests are very long winded to allow monkeying around with them independently).
If you have two attributes with names like thing and thing_id they don't appear to be settable at the same time when calling build, create, etc.
For example:
build(:my_model, domain: 'example.com', domain_id: 'ID-32423-234')
Will result in both attributes being nil, I've monitored the setters for these attributes, and they are never called (both for plain old ruby classes and mongoid models, tests for both in the linked repo).
calling this however:
build(:my_model, domain: 'example.com')
Will set the domain attribute correctly but domain_id will remain nil, even if there is a sequence defined for it.
If you have sequences setup for both of the attributes, then calling build(:my_model) sets them correctly.
I couldn't track a specific cause of this in the FG source, my best guess is that there is an assumption somewhere that paired attributes like this represent an association. There are factories with implicit and explicit (add_attribute) attribute definitions in the test repo. The functioning work around is to set these fields to be transient and assign them in an after(:build) callback.
Edit: This seems to be the result of the default alias definition in: https://github.com/thoughtbot/factory_girl/blob/7e2bed5938be2e1314a7df6a647031a47d01c2c8/lib/factory_girl/aliases.rb
Given that, I assume the transient approach is likely the best work around.

I would rename the attribute domain_id since the suffix _id is used by Active Record to detect associations between your models.

Any news on this?

@mbell697 you're correct, I actually outline this a bit more in depth here as well.
Basically, the concept of aliases helps ensure associations aren't incorrectly set given AR's naming conventions. The best solution might be to extract that domain concept into a separate model and manage it as such.

@mbell697 Since we have two separate entities; Factory Girl and Factory Girl Rails ("factory_girl_rails provides Rails integration for factory_girl")... Shouldn't then Factory Girl aim to be Rails agnostic and hand that part over to factory_girl_rails? Still, FG has gem dependencies on both active_support and active_record, so it is hard to see where vanilla FG ends and the FG:Rails start.
Long story short: People expect FG to work with foo and foo_id.
For example, lets say that you want to create a factory for a json object/representation of a model with the Hashie::Mash class. We would like an event factory to have both the interaction_id it belongs to, as well as the interaction json object serialized within it:
{
  id: 100
  interaction_id: 10,
  interaction: {
    id: 10
    name: "bar",
  }
}

This may be a json representation of a Rails model, it doesn't matter. It is not unreasonable to have both, and it clearly illustrates the issue. It is today unfortunately not possible to do this with FG. Unless you work around this quirk in one way or another.
What would be best of both worlds would not be to opt in or opt out entirely, but to be able to customize it per factory definition (the default being as is) so we could opt out per factory using a keyword e g active_record: false
What do you think?


Physics Primitives : PrimitiveImporter and PrimitiveAssetAttributes

Motivation and Context
To instantiate primitive assets, we wish to use a configuration object to hold desired parameters and feed this object to a PrimitiveImporter, which provides all the primitive object instantiation functionality we require.  This PR sets the groundwork for this functionality :

Attributes : Primitive asset template attribute classes with appropriately named functions are added so that the underlying configuration object will be usable by PrimitiveImporter to instantiate an appropriate object.  These templates will synthesize their own handles internally based on their parameters when any parameter changes.

PrimitiveImporter : cmake files have been modified appropriately to reference necessary PrimitiveImporter functionality.  ResourceManager has been modified to instance a PrimitiveImporter via PluginManager.

All references to "AbstractPhysicsAttributes::XXXXMeshHandle" have been changed to "AbstractPhysicsAttributes::XXXXAssetHandle" to more accurately reflect the role these handles are expected to play once primitive assets become generally available.

How Has This Been Tested
run_tests and pytest executed successfully

Types of changes

[x] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

And I'm too late to this, again. General question -- can we please have at least a 24-hour window before opening a PR and merging it, unless it's straightforward enough? This one got opened at 8 PM in my timezone (at which time I didn't have enough brain cells anymore to absorb all the new code) and because I was finishing up a leftover task from yesterday I didn't have time to look at this until now.

getBoolDispStr(), CYLINDER_WF, primitiveAssetTmpltLibByID_, physicsSynthObjTmpltLibByID_, ...

I have to admit I don't like the direction in which these names are going ... to me the last one could as well be just b and it wouldn't make it any less meaningful. Is primitiveAssetTemplateLibraryByID_ really too long to type? Abbreviation overuse makes the code harder to read than it could be. (Of course if I'm the only one who has a problem with this feel free to ignore me.)
Skimming over the rest of the code, I'm a bit surprised that what were originally just pure functions in the Primitives library is now a complex class hierarchy with virtual calls, severals getters and setters and a caching scheme. In the beginning I suggested to use either the Primitives library directly or the PrimitiveImporter, whichever would result in less code. I thought, since we already have a lot of code operating with generic Importer plugins, the PrimitiveImporter would be easier to integrate as it's just switching from AnySceneImporter to PrimitiveImporter and adding a possibility to extract just a particular mesh. (That's precisely why it exists, so I have a possibility to inject primitives into apps that can only open files.) I didn't expect it to become this :sweat_smile: The Primitives library itself is also exposed in full to Python, while all the complex code here needs completely fresh bindings.
What's probably the most complex part of this is the buildOriginHandleIndiv() (what's Origin and Indiv btw?) -- do we really need to expose all of the flexibility and then cache every single variant under a unique handle? Why not cache just one base variant (that's smooth enough and has all important attributes) and then provide a flexible-but-uncached API when someone really needs a circle with exactly 76 vertices (in which case they could just supply the MeshData directly from the Primitive library anyway)?
I wasn't fully involved in the discussion leading to this and I have only very little understanding of the concept behind physics attributes and template object libraries etc., so if there's some high-level architecture I'm missing which warrants existence of all this code, I'd be happy to know more about it. However from a pure GPU developer perspective, if our goal is to reduce memory consumption, overhead and move towards immutable memory-mapped assets shared among several instances, this new code makes it harder, not easier.

I agree with many of the points raised by @mosra here.  When it comes to changes such as in this PR that have a sizable footprint on the codebase, it would be good to go through a more deliberate process.  I propose that we clarify the design goals surrounding templates, have an API sketch and iterate on that once before we go into PRs.  @jturner65 @aclegg3 @mosra let's followup regarding the above on slack.


Settings -> Groups allows assignment of Global Role to an arbitrary User, not just Groups, with SAML Authentication Provider configured

Internal reference: SURE-6436
Reported in 2.7.3
We originally did some work to fix this in https://github.com/rancher/dashboard/issues/6932 but another scenario arose; whether it implies regression or an expansion of the original issue is something to research. (That ticket has a long history that @richard-cox may assist upon jogging his own memory.)
Currently, to reproduce:

Users & Authentification -> Groups -> Assign Global Roles
Add text "saytest\iaminagroup"  -> Enter -> Save

The result is that the Group Name systest\iaminagroup was created

Per @nwmac, this may be tied to false search results from SAML, which means backend help is required but we may be limited. There may be a backend ticket somewhere already but I couldn't find one easily.

I think this is the same root cause as https://github.com/rancher/dashboard/issues/8361
I believe this will require a backend fix

@Shavindra or @nwmac is there a backend ticket to track what UI needs here? I can follow up if you can point me to one but let me know if one needs to be filed still.

OK @Shavindra if we need backend to do something, can you file a ticket?

@nwmac may know where the appropriate existing backend ticket is.

@gaktive Backend issue is: https://github.com/rancher/rancher/issues/43131

We completed the backend work for this a few weeks ago FYI @gaktive

@nwmac to review the state of this and the related #8361 to confirm how the new API works. This doesn't feel critical for 2.10.0 in contrast to other tickets but there has been around a while.

/backport v2.10.1

Related backend: https://github.com/rancher/rancher/issues/44441 which was addressed as noted in 2.10.0 so this should be unblocked but I'll allow @nwmac to proceed with https://github.com/rancher/dashboard/issues/8361 first.


Added Modular Exponential [Python] Closes #96

Closes #96

By submitting this pull request I confirm I've read and complied with the below requirements.

[x] I have read the Contribution guidelines and I am confident that my PR reflects them.
[x] I have followed the coding guidelines for this project.
[x] My code follows the skeleton code structure.
[x] This pull request has a descriptive title. For example, Added {Algorithm/DS name} [{Language}], not Update README.md or Added new code.

Now is it okay.
On Sun, Mar 26, 2017 at 10:13 AM, Pratyush Singh<EMAIL_ADDRESS>wrote:

@singhpratyush commented on this pull request.
In modular_exponential/modular_exponential.py
https://github.com/iiitv/algos/pull/97#discussion_r108051752:

@@ -0,0 +1,16 @@
+def mod_expo(_base, _pow, _mod):

res = 1  # Initialize result
_base = _base % _mod  # Update base if it is more than or equal _mod
while _pow > 0:

   if _pow & 1:  # if _pow is odd multiply it with result

       res = (res * _base) % _mod

   _pow = _pow >> 1  # _pow must be even now

That is because you didn't followed the coding guidelines.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/iiitv/algos/pull/97#discussion_r108051752, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARMqT1xaGl7Tx5Nujibs0MyYLXKl9_TQks5rpez-gaJpZM4MpIWR
.

@singhpratyush Please review it. So that it can be merged? :+1:


Emitter "loaderror" opposed to camel cased "loadError" in docs

Thanks for the PR, but it's the docs that should change, not the event name. All events are lower-case through-out the API.

@photonstorm ahh I see. Alright, fixed the docs to reflect emitted event names.


add nelSep

The NEL character was added to the Unicode official line endings list. We must support it.

What about updating other code that need to know where linebreaks are, like in splitterLines?

Yes, I intend to update those. But this comes first.

Fair enough.

Auto-merge toggled on

thanks!


Automate 'X-Shopify-Server-Side-Rendered' header addition for server-side GraphQL queries

Overview
Right now, quilt_rails has documentation about a CSRF strategy + SSR header, but this is quite easy to overlook.
If possible, a React-side library should automatically augment GraphQL requests with the X-Shopify-Server-Side-Rendered header.

Didn't realize it was a duplicate but I also opened https://github.com/Shopify/quilt/issues/1297 for the same thing. We should use that one because I've updated it with input from the security team.

Solved in latest versions of the packages :)


Enhancement - Feature to send email to user to update default keycloak password

Usecase scenario:
After creating a user in registry, if keycloak-user.set-default-password:true the default password will be set and this will raise security concerns.
we have implemented a feature to send an email to user with a link to update the password. Using the same password, the user can generate the keycloak token.
Configuration changes:

Email details should be configured in keycloak realm settings.

Set the keycloak-user.email-actions property to UPDATE_PASSWORD in application.yml file. To execute the send email action by keycloak, when a user is created.

Following are the step by step images of the flow:
Email sent by keycloak to user:

Clicking the link in the email, user will be redirected to the below page:

Click here to proceed will taken to update password page:

After setting the password and submitting, user will be taken to confirmation screen:

Using the new password, user can generate keycloak token:

Discussion link: https://github.com/Sunbird-RC/community/discussions/118

Hi @dileepbapat
We have implemented this feature as part of Swasth Health Claims Exchange registry use case and we would like to contribute back to Sunbird-RC, Can you please review the PR and share your feedback.
cc: @vrayulu @maheshkumargangula


Refresh (reconnect) from IE crashes the server

HI,
I tested the provided testwebsock.php with client.html and observed this on Internet Explorer 11:

I ran the server srcript, testwebsock.php, on an apache server on ubuntu.
I ran the client.html on Internet Explorer 11. The client successfully connected to the server. I could send a message and received the echo.
When I clicked the "Refresh" button on IE, the server crashed, printing out this message: "Socket error: Connection reset by peer"

Any suggestion on why this might happen or how to fix/investigate?
Thanks

I think the Exception was thrown here:
$numBytes = @socket_recv($socket,$buffer,$this->maxBufferSize,0);
if ($numBytes === false) {
throw new Exception('Socket error: ' . socket_strerror(socket_last_error($socket)));
}
I don't know what cause the IE to send the error 104 (Connection reset by peer) though. May be IE did not follow the closing protocol properly? But in general, should this error be handled somewhat more gracefully? E.g., in case of 104 error should we just close the socket (if I understand the error code correctly, the client basically told us that it is disconnected already) and continue?
Please let me know if I am wrong. Thanks

First, the http server you use is irrelevant because php-websocket is a standalone server using cli ( command line interface).
When you refresh did you see IE reconnect?
Simply because when you refresh with IE it's like  "slamming the phone back on the hook". Not polite close session "using quit".  It's normal behavior this error is sent when the connection did not say goodbye to each other.
I'm not sure but I think you are right throwing execption break the loop you need to keep server alive.
try replacing this with :
 if ($numBytes === false) {
	    $this->stdout('Socket error: ' . socket_strerror(socket_last_error($socket)));
    }
```

Thanks Xaraknid. I have somewhat the same thought about slamming the phone. Though it should be noted that same thing does not happen to Firefox, Opera, and Chrome (the browsers I tested).
Regarding keeping the server alive, I am thinking of this:

if ($numBytes === false) {
$err_num = socket_last_error($socket);
if ( $err_num == 104) {
socket_clear_error($socket);
$this->disconnect($socket);
$this->stdout(socket_strerror($err_num));
} else {
throw new Exception('Socket error: ' . socket_strerror(socket_last_error($socket)));
}

Basically I think in case of error 104 we probably should close the socket (because the remote site already disconnected) and generally we also need to clear the error (because the document of socket_last_error indicating that the error will not be cleared unless we call socket_clear_error).
I have not read all other errors, so I dont know if it is always save to continue, though.

There are standard used by Firefox, Opera and Chrome and IE alone in other side of the ring.  Most probably in first team when you refresh they close gracefully any connection before refresh it.
The problem is not the error but ANY error throw WILL break the loop causing server to stop. Most probably cause by how exception work in php.  So we should maybe not use try...catch for the server.
try {
  $echo->run();
}
catch (Exception $e) {
  $echo->stdout($e->getMessage());
}

replace it by
$echo->run();

There is no need to clear error as you only call socket_last_error when error occur and you will see the last error.

If you don't have the try/catch block, it'll throw a fatal exception.
I just pushed a fix up to the legacy dev branch, but I don't have my development server in a stable state tonight, so I can't do a smoke test.
It should cover each case where just one client is disconnected or fails to fully connect and the issue is at the Transport layer.

You are right try/catch is needed if you use throw statement.  But I think using throw statement is not a good idea because any throw end the execution of run() method. It's good if the server only wait for only one client ( you ).
Only need to drop connection to current socket not end the whole server. It's my tought that's why I did not think  try/catch and throw should be used.

Agreed about preserving the server and limiting the termination to the
socket only.  It's not uncommon to have socket failure of some kind with
large connection pool and many clients.  Cleanly removing them and continue
to process new/current connections is key.
On May 12, 2015 1:53 AM, "Xaraknid"<EMAIL_ADDRESS>wrote:

You are right try/catch is needed if you use throw statement. But I think
using throw statement is not a good idea because any throw end the
execution of run() method. It's good if the server only wait for only one
client ( you ).
Only need to drop connection to current socket not end the whole server.
It's my tought that's why I did not think try/catch and throw should be
used.
—
Reply to this email directly or view it on GitHub
https://github.com/ghedipunk/PHP-Websockets/issues/32#issuecomment-101140836
.

Removed throwing the exception.  Still untested and is on dev-legacy.
Once tested, I'd like to merge into master, then merge master into legacy.

Hi ghedipunk,
Your switch statement makes sense to me, and in testing, it would fix the 104 error (it should fix all those disconnecting errors that you included out also). However, I receive the following warning message when I reset IE (to reproduce the 104 error):

PHP Warning:  socket_clear_error(): 9 is not a valid Socket resource in /home/xxx/phpwebsocket/websockets.php on line 89

I believe it is because you disconnect before clearing error. I think the disconnect function would close the socket and hence when you call socket_clear_error you give it an already closed socket. The problem should be fixed if you clear the error before closing the socket. On the other hand, I am wondering if we actually have to clear the error at all since closing the socket would "clear" the error anyway? To be safe I am inclined to clear it, but you were right in your comment that someone might implement their own check for error condition on the socket.
For a longer term solution, may be we should consider adding a call back explicitly for error handling?

Commented out the socket_clear_error() line.  Once the socket is closed the error wouldn't need additional explicit clearing.
Added an optional parameter to the disconnect() method, to allow a developer to get the actual error that is triggering the disconnect.

Current behavior when refreshing with IE:
Client connected. Resource id #7
frame #1 position : 0 msglen : 2 + headers_size 6 = framesize of 8
########    PACKET END         #########
Unusual disconnect on socket Resource id #7
Client connected. Resource id #8
frame #1 position : 0 msglen : 2 + headers_size 6 = framesize of 8
########    PACKET END         #########
Unusual disconnect on socket Resource id #8
Client connected. Resource id #9
frame #1 position : 0 msglen : 2 + headers_size 6 = framesize of 8
########    PACKET END         #########
Unusual disconnect on socket Resource id #9
Client connected. Resource id #10

I'm happy with the results.  I'm merging dev-legacy into master, then master into legacy.
Leaving open for a day in case anyone else has problems.

Thank you all again for the fix and the discussion.

Just to let you know it's not required to send a close request to client who have allready hang-up the line.  In fact there's no need at all to implicitely call disconnect because the server allready catch the windowed connection with :
elseif ($numBytes == 0) {
   $this->disconnect($socket);
   $this->stderr("Client disconnected. TCP connection lost: " . $socket);
}

There a great idea by @trungdinhtrong :
For a longer term solution, may be we should consider adding a call back explicitly for error handling?

If we add an abstract onerror($user,$sockerror) the dev can deal the way he want with the error with client.  As example client reset by peer can mean the client never recieve the message so you can save it and send it back when he come back.


Add .bidsignore

Bids-validator has a .bidsignore option to define files that should be ignored by the validator. This option helps to ignore dataset includes file types not yet supported by BIDS specifications. Should we add this option to ancp-bids?

if there is a .bidsignore file in the root folder, it will be processed to ignore resources (files/folders) in the dataset


duplicated key error when defining a super-table afterward

Hi, thank you for this wonderful tool!
I was recently playing with some TOML configuration files, and I have found that coc-toml throws duplicated key "gui" error with the following TOML content:
[gui.gtk]
# ...
[gui.qt]  # Error: duplicated key "gui"
# ...
[gui]  # Error: duplicated key "gui"
# ...

Yet, if I move the last [gui] section above the other two sections, the error is gone:
# No error
[gui]
# ...
[gui.gtk]
# ...
[gui.qt]
# ...

While the above two TOML contents can both be properly deserialized with the toml Rust crate.  I have skimmed through the TOML spec and found that it has an example saying defining super-tables afterwards is OK:
# (Copied from https://toml.io/en/v1.0.0#table):
# [x] you
# [x.y] don't
# [x.y.z] need these
[x.y.z.w] # for this to work

[x] # defining a super-table afterward is ok

So I think there might be a bug in coc-toml, it would be great if this can be resolved, thank you!

Sorry for the late reply. A library could cause this problem that it relies on, so updating it might fix the problem, but I'm overwhelmed with university exams right now, so please give me some time to work on it.
I think all I have to do is update the dependencies, and if you would like to contribute, I would be happy to do so.

@blurgyy This issue has been resolved in the latest one. Please update to the new one.


Popup with diff is transparent and overlaps with a line at bottom

atom version 0.172
your plugin version: 0.5.0

Thanks for reporting this. I'll take a look at this as soon as possible, for now what you could try is change the css in your own stylesheet.

thanks, added background-color: #000 to outer style.
Other problems:

it's not possible to copy just part of text from old version
it's not handy to hide the window - need to press once again alt+g alt+d. Would be nice to react to Esc key

+1 Esc or click to close the window

https://github.com/atom/highlights/issues/20

fixed with #11 and #12


az storage remove fire RemoteException

I am using az storage remove in a custom DevOps Task (PowerShell script) on DevOps Pipeline.
at run time it returns an exception:
##[debug]az client version: azure-cli                          2.5.1  command-modules-nspkg              2.0.3 core                               2.5.1 nspkg                              3.0.4 telemetry                          1.0.4  Extensions: azure-devops                      0.18.0  Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe' Extensions directory 'C:\Program Files\Common Files\AzureCliExtensionDirectory'  Python (Windows) 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 02:47:15) [MSC v.1900 32 bit (Intel)]  Legal docs and information: aka.ms/AzureCliLegal   Your CLI is up-to-date.  Please let us know how we are doing: https://aka.ms/clihats and let us know if you're interested in trying out our newest features: https://aka.ms/CLIUXstudy
##[debug]Leaving D:\a\_tasks\AutoDownloadDeploy_7e16b0a0-3f12-47f7-8058-5746bc02eafe\1.0.10\Deploy.ps1.
##[debug]Caught exception from task script.
##[debug]Error record:
##[debug]This command is in preview. It may be changed/removed in a future release.
##[debug]    + CategoryInfo          : NotSpecified: (:) [], RemoteException
##[debug]    + FullyQualifiedErrorId : RuntimeException
##[debug]
##[debug]Script stack trace:
##[debug]
##[debug]Exception:
##[debug]System.Management.Automation.RemoteException: This command is in preview. It may be changed/removed in a future release.
##[error]This command is in preview. It may be changed/removed in a future release.
##[debug]Processed: ##vso[task.logissue type=error]This command is in preview. It may be changed/removed in a future release.
##[debug]Processed: ##vso[task.complete result=Failed]

the source is:
az storage remove --container-name $containerName --include-path $BlobPrefix --include-pattern "$ApplicationName*.copy" --account-name "$StorageAccountName" --sas-token "$SASToken" --only-show-errors

I tried to encapsulate it in a try-catch, it make is passing but the target file is not removed, I expect the exception breaks the execution of the statement.

note: The same issue happens with version 2.5.0 (provided natively in last window version image of DevOps Pipeline)

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

ID: b8c4e415-fc8d-26d5-3213-da937fd6932c
Version Independent ID: dcb2f2d6-fd80-495d-8582-8be859d68792
Content: az storage
Content Source: src/azure-cli/azure/cli/command_modules/storage/_help.py
Service: storage
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

hi @Juliehzl  could you pls have a look?

add to S170

some news about this issue?

will be fixed in this sprint.


Implement a canary edition system

This PR implements an edition system for buffrs manifests. This allows us to version manifests properly and show users errors (or map the manifests internally behind the scenes)
Error:   × could not deserialize Proto.toml
  ╰─▶ TOML parse error at line 1, column 1
        |
      1 | edition = "0.7"
        | ^^^^^^^^^^^^^^^
      unsupported manifest edition, supported editions of 0.8.0 are: 0.8

This is a preliminary feature to roll out before driving wide adoption of buffrs to be able to still make breaking changes (and introduce new features) while having an existing user base.
Closes #64

Canary Edition
The canary edition correlates (and de/encodes to 0.x where x is the current minor version of buffrs). This means that until the stable release there is an option to introduce potentially breaking changes with every minor release.
Unknown Edition
Every other manifest release edition that is not matching the current canary one is deserialized into unknown and thus triggers an error for users.

Introduces

pub enum Edition – The edition enum
pub const CANARY_EDITION – The current canary edition of this crate

Changes

Manifest / RawManifests internal layouts to accommodate the edition logic
Implements a custom serializer / deserializer for branching and adding backwards compatibility
The semantics of buffrs package: The compressed package will always contain a manifest with the current canary edition inside. Even if the "source" manifest didn't contain any edition pin
The edition is optional in the Porto.toml and inferred to be the canary edition, which means that users are responsible for keeping it compatible (this also ensures that this feature works out of the box with existing projects!)

Examples
Editioned (supported)
edition = "0.7"

[package]
name = "xyz"
version = "xyz"
type = "lib"

Uneditioned (supported)
[package]
name = "xyz"
version = "xyz"
type = "lib"

Unknow / Outdated (unsupported)
edition = "0.6"

[package]
name = "xyz"
version = "xyz"
type = "lib"

This causes the following error:
Error:   × could not deserialize Proto.toml
  ╰─▶ TOML parse error at line 1, column 1
        |
      1 | edition = "0.6"
        | ^^^^^^^^^^^^^^^
      unsupported manifest edition, supported editions of 0.8.0 are: 0.8

Open Points
After the review of the core concept of editions the following points are open and must be addressed before merging:

[x] Document this in the guide
[x] Write tests for this

I just want to add one thing here, which is a pattern that I have used before that I found rather useful for when you have versioned data structures and getting them to parse easily with serde. From glancing at the code in this PR, it looks like this strategy might be useful here as well. Some of this explanation includes stuff we are already doing, but I repeat it here for completness' sake.
The idea is that we use serde's support for internally tagged enums to get the decoding for free. To do this, we can have an Edition enum, and a Manifest struct (this one is internal, it can change at any time):
// could be auto-derived from VersionedManifest using strum, for better maintainability
#[derive(Serialize, Deserialize)]
#[serde(rename_all = "snake_case")]
pub enum Edition {
    V1,
    V2,
}

// internal representation of a manifest (we are free to change this, as it is now decouple from the
// representation on disk).
#[derive(Serialize, Deserialize)]
pub struct Manifest {
    edition: Edition,
    authors: Vec<String>,
    frobnicate: bool,
}

Now, when we actually parse the manifests, we use a different type called a VersionedManifest (this is raw data that we parse from the filesystem). Note that this is now an enumeration.
// external representation of a manifest (add new variants here for new editions)
#[derive(Serialize, Deserialize)]
#[serde(tag = "edition", rename_all = "snake_case")]
pub enum VersionedManifest {
    V1(ManifestV1),
    V2(ManifestV2),
}

To translate this: with the tag = "edition", we are telling serde that in our TOML there is a field called edition, which it should parse first to figure out which variant it should match. We also tell it to snake_vase the variant names. So basically, the edition field can now be v1 and v2. We are also able to override them with something else using #[serde(tag = "something")].
The variants of this enumeration should obviously align with the Edition enum. In fact, the Edition enum can be automatically derived from this VersionedManifest using the strum crate, if desired.
Now, we can define these manifests. These are public-facing and may never change (part of the public API, if you wish):
// on-disk representations for manifests, one for every edition
#[derive(Serialize, Deserialize)]
pub struct ManifestV1 {
    // these fields can be public because they may never change
    pub author: String,
}

#[derive(Serialize, Deserialize)]
pub struct ManifestV2 {
    pub authors: Vec<String>,
    pub frobnicate: bool,
}

You can see that these two have different shapes — one has an author which is a single string, and one has a list of authors. This is fine — we can totally change the shape between versions. We have full flexibility to make any kind of breaking changes in between editions.
Finally, we write a bit of glue code to convert a VersionedManifest into our internal Manifest representation:
// this is where we translate the public-facing versioned manifest into our
// internal representation. we can change our internal representation at any point
// and change how we do this translation, as long as we don't change the semantics
impl Into<Manifest> for ManifestV1 {
    fn into(self) -> Manifest {
        Manifest {
            edition: Edition::V1,
            authors: vec![self.author],
            frobnicate: false, // fallback to default value
        }
    }
}

impl Into<Manifest> for ManifestV2 {
    fn into(self) -> Manifest {
        Manifest {
            edition: Edition::V2,
            authors: self.authors,
            frobnicate: self.frobnicate,
        }
    }
}

impl Into<Manifest> for VersionedManifest {
    fn into(self) -> Manifest {
        match self {
            VersionedManifest::V1(manifest) => manifest.into(),
            VersionedManifest::V2(manifest) => manifest.into(),
        }
    }
}

What is nice about this is that now, the two toml files parse properly:
edition = "v1"
author = "Snoop Doggy Dogg"

and this one as well:
edition = "v2"
authors = ["Snoop Doggy Dogg", "Dr. med. Dre"]
frobnicate = true

And yet, once we have parsed them both fully and turned them into a Manifest, they produce the same shape of data (but yet we still have that edition field, so that we can in the code have different behaviours depending on which edition you have chosen, if you really want):
Manifest {
    edition: Edition::V1,
    authors: vec!["Snoop Doggy Dogg"],
    frobnicate: false,
}

I'm a really big fan of how easy serde makes it to compose things like this. We could even have support for unknown editions, by writing something like this:
// the untagged makes it try to match the input as a Known variant first, and if it cannot, fall
// back to keeping it as a string. so "v1" => Known(V1), "v4" => Unknown("v4").
#[derive(Serialize, Deserialize)]
#[serde(untagged)]
pub struct RawEdition {
    Known(Edition),
    Unknown(String),
}

Not that we would ever want that, probably, but the way this stuff composes makes it possible to mix strongly-typed stuff with a fallback to loosely-typed, dynamic data.

Maybe this is something we could implement here as well, it might save us some custom serde parsing code?

Another cool trick with serde (while I'm at it): suppose you have some data structure that is typed, but maybe in the future you might add fields to it. You don't care about those fields, but you also don't want to lose them. So what do you do?
This:
#[derive(Serialize, Deserialize)]
pub struct MyType {
    author: String,
    uuid: Uuid,
    tags: BTreeSet<Tag>,

    // anything else not present when parsing gets dumped into this
    #[serde(flatten)]
    other: BTreeMap<String, serde_json::Value>,
}

Serde is so cool!

@xfbs so, I agree, and I have used internally tagged serde enums before for these kinds of work. The problem here is that the Canary edition does not serialize to one specific edition, but to a different string on every buffrs version hence the custom serialization logic is needed.
The custom deserializers for the RawManifest enable us to treat the missing tag differently from how serde would behave by default. So to summarize this quickly: Its not possible to teach serde the current implementation's behavior through combinations of rename and tag. This is why I opted to implement this manually.
If you find a way of having untagged variants default to a specific tag + rename a variant dynamically let me know! Im open for suggestions but after carefully consulting the docs and lib of serde this is just not covered by the derive syntax.

@mara-schulke I see! As far as I understand, we can certainly have untagged variants default to a specific tag. However, you are right indeed in that we cannot rename a variant dynamically, this is tracked in https://github.com/serde-rs/serde/issues/450.
As far as I understand, the manually-implemented behaviour can be (almost) reimplemented like this:
#[derive(Serialize, Deserialize)]
#[serde(tag = "edition")]
pub enum TaggedManifest {
    #[serde(rename = "0.7")]
    Canary(CanaryManifest),
}

#[derive(Serialize, Deserialize)]
#[serde(untagged)]
pub enum Manifest {
    Tagged(TaggedManifest),
    Untagged(FallbackManifest),
}

The only caveat being that due to the missing dynamic rename functionality, we have to write rename = "0.7" and we currently cannot write rename = concat!("0.", env!("CARGO_MANIFEST_VERSION_MINOR")). So, if we are okay with having a place in the code that we need to manually update with the current version name (this can be unit tested quite easily), then this approach might be useful to us here.
If we don't want to have to manually update that 0.7, then obviously implementing Serialize and Deserialize manually (as is the current approach) is the only way to go 😢

Well, but the current behavior of "untagged" manifests is to deserialize as the current canary edition. I don't think that this is possible as of right now?

So we only have two parsing cases:

edition = "0.7" or missing: treat as current canary
edition = "0.6" or any other, non-current edition: emit warning

Is that correct?

Well, no, because 0.7 may be compatible with 0.6, then we would not emit an error.

@xfbs @tomkarw @Tpt @qsantos: this is blocking the migration from kicking of, may we either merge this or get concrete change requests?👀🙈
I'm open on reiterating the implementation, I'm just waiting on suggestions / concrete feedback here. If you don't have any, may we shift the discussion to a github discussion / issue and move on?

Sorry from my side for being slow!

I think the code looks good, I also approve this

I have a bit of uncertainty/lack of understanding of the strategy around the canary editions, backwards compatibility and all that good stuff

Are we maybe overloading the edition key with the version, and what we really want is:
edition = "alpha"
buffrs_version = "0.7" # requires 0.7 at minimum

and
edition = "1"

Or something like that (aka have separate fields for edition versioning and buffrs minimum versions)? (not sure if we do, just thinking out aloud)

It scares me a little bit that the current approach is that you need to re-publish a package to upgrade to a new edition (and all of the dependencies need to do the same), if I understood that correctly (did I understand that correctly?)

I feel like there are some thoughts that could be better discussed synchronously, because I feel bad when I ask stupid questions or write a wall of text :smile:

I think @Tpt left some good comments, and maybe I'm just overthinking it!

It scares me a little bit that the current approach is that you need to re-publish a package to upgrade to a new edition (and all of the dependencies need to do the same), if I understood that correctly (did I understand that correctly?)

I think what you need to acknowledge is that you would need to do this either way. If we break the compat (for whatever reason) you can't use old packages. This is already the case as of right now and will always be the case prior to being stable. What this edition system solves is that you gain stability and awareness of when this is the case (and if it is the case, you get the ability to repair it, by mapping the old manifest to the new).
Re mixing editions and versions: buffrs doesn't have editions as rust has them. We only version the manifest through editions thus there is no need to use "alpha", "beta" etc for the manifest version. The only version we track is the stability of the package manager and thus strictly related to the server version string of it. The versioning system described by this pr is basically just formalizing what is already the case: every new minor version (pre 1.0) may be incompatible with the prior one. The manifest may change completely between each version and thus the edition tracks when the manifest was valid / how it should look like and enables us to write migration guides between each edition.
Most likely each breaking change in buffrs (and thus each new minor version) will come along with some, potentially breaking, manifest change. If that is not the case anymore we are approaching stable.

You are obviously much more knowledgeable on buffrs than me, so always take what I say with a grain of salt 😅

If we break the compat (for whatever reason) you can't use old packages. This is already the case as of right now and will always be the case prior to being stable.

We could make a conscious choice to say: while buffrs is unstable (there will be breaking changes in it's API), we are explicitly versioning the manifests and guaranteeing that newer versions will be able to use older manifests. if we wanted to, anyways.
My understanding is that that is not something we want to do, because we want to be able to make many breaking changes or changes to the manifests that are not easily "convertible" (aka bijective)?

Most likely each breaking change in buffrs (and thus each new minor version) will come along with some, potentially breaking, manifest change. If that is not the case anymore we are approaching stable.

Does the manifest change often? I think I was under the impression that it is relatively stable — but I am likely wrong!
Sorry for opening a can of worms with my comment but I think this explanation from you really helped me understand the motivation behind the design the way it is 😊


Update page doesn't show newest release version and notes

From:  atom/atom#12311
Description
The atom updater, when there's a new update, always shows the currently-installed vesion.
Steps to Reproduce

Launch atom
DO NOT open the about page
Wait until there's a new release
Click the Squirrel icon in the lower-right

Expected behavior:
The Restart & Update section on the About tab should show the newest release version and link to its notes.
Actual behavior:
The Restart & Update section shows the currently-installed version number and links to the currently-installed version's release notes.

Versions
Windows version
ver
Microsoft Windows [Version 10.0.10586]

Atom version
atom --version
Atom: 1.9.2
Electron: 0.37.8
Chrome: 49.0.2623.75
Node: 5.10.0

Atom package manager version
apm --version
apm: 1.10.0
npm: 2.13.3
node: 0.10.40
python
git
Visual Studio

Since I'm on Windows, the apm --version colors may not be displaying correctly. I had a hard time reading the Node version output for that command.
Also, as far as I know, this has been happening at least since Atom 1.5 or 1.6. I just didn't think to report it until now.

Based on my analysis, I've found the following:
The logic checking whether there is an update available seems to vary in different parts of the plugin:
main.js appears to listen to the atom.onUpdateAvailable event, and then caches the available version in localStorage.
https://github.com/atom/about/blob/v1.7.2/lib/main.js#L28
this.subscriptions.add(atom.onUpdateAvailable(({releaseVersion}) => {
  window.localStorage.setItem(AvailableUpdateVersion, releaseVersion)
  this.showStatusBarIfNeeded()
}))

However, update-manager.js listens for a completely different event, atom.autoUpdater.onDidCompleteDownloadingUpdate:
https://github.com/atom/about/blob/v1.7.2/lib/update-manager.js#L32
listenForAtomEvents () {
  this.subscriptions = new CompositeDisposable()

  this.subscriptions.add(
    //...
    atom.autoUpdater.onDidCompleteDownloadingUpdate((detail) => {
      let {releaseVersion} = detail
      this.setAvailableVersion(releaseVersion)
    })
    //...
  )
}

My suspicion is that the atom.onUpdateAvailable event is being fired/received, but the atom.autoUpdater.onDidCompleteDownloadingUpdate event is not.
This is resulting in the inconsistent state that's then visible in the about page.

Would be awesome if this leads to fixing the issue.
Also, I didn't realize there was a repo specifically for "About". Thanks for posting this.

I've encountered this issue forever, but it seems fixed now

It's not fixed for me - I saw this issue as recently as 1.12.3 upgrading to 1.12.4 (as you've shown above).
The screenshot and version numbers I took from above are from the original issue raised in the atom/atom repo.
Based on my analysis, it would still make sense for the issue being sporadic - maybe that event gets fired sometimes, but not always?

In fact, still there in 1.12.4:

The above screenshot was on Mac. I had the about page closed whilst the update was downloading. Below is my Windows VM - I had the about page open:

Right, so my suspicion is correct here.
The subscriptions in https://github.com/atom/about/blob/v1.7.2/lib/update-manager.js#L32 aren't added until the about page is opened.
This means that the version is only displayed correctly if the about page had already been opened in the current editor session before the update was downloaded.
Presumably the fix would be to add the subscriptions regardless of whether the about page has been opened?

same here for the last 4-5 updates on mac


Release materials for jspf 1.0.5

Why this line is not changed as well?
https://github.com/apache/james-project/blob/d8d8fc40100f4a4cc42de06abf325b0d77fce063/pom.xml#L614

Why this line is not changed as well?

We need to release communication material before maven central artifacts are available. Maven updates is generally done in a follow up step.


Fixed incorrect method call.

No clue how this was working before...

This is actually dependant on the phpunit version. (and maybe laravel version?) anyway, is not a fix for all branches.


How to init customer style for all matches?

for example:
<mj-text>Hello</mj-text>

it'll render
...
<div style="cursor: auto; color: #000000; font-family: Ubuntu, Helvetica, Arial, sans-serif; font-size:
Hello
</div>
...

so, even if I set <mj-style inline="inline"></mj-style>, I can't change anything instead of mjml hardcode style in inline.
which means I have to add classes for all of div or even I must to add all the same attributes/values for all div.
another issue, how can I set default font color for all elements?
<mj-head>
  <mj-style inline="inline">
    body {
       color: blue;
    }
  </mj-style>
  <mj-style>
    body {
       color: blue;
    }
  </mj-style>
</mj-head>

it isn't working....
mjml will use inline style to force all things, if it set.
Suggestion
try to make all the values of attribute of style to be in default <style></style> , not use inline to write style for elements, otherwise it's very very very difficult to change, it made simple into complicated.
And then it'll write inline style when mjml developers are really using attributes to set something.

Sorry, you might not get my point.
Can you tell me how to set default text for all of page?
what do you think that's easier?
body {
  color: #424242;
}

or
.main-color {
  color: #424242;
}

      <mj-section>
        <mj-column>
          <mj-text color="#4a4a4a" font-size="22px">Defined by mjml</mj-text>
          <mj-text>
             It'll be #000000
          </mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
          <mj-text css-class="main-color">I have to assign class-name all the time for default definition.</mj-text>
        </mj-column>
      </mj-section>

The default means it mostly use for using.

Hey @monochrome-yeh, in mj-attributes pointed by @iRyusa, you can set a default style for every components, like that: https://mjml.io/try-it-live/SyPmEkGCZ
<mjml>
  <mj-head>
    <mj-attributes>
      <mj-text color="blue" font-family="Helvetica" />
    </mj-attributes>
  </mj-head>
  <mj-body>
    <mj-container>
      <mj-section>
        <mj-column>
          <mj-text>
            I'm a text with a default style.
          </mj-text>
          <mj-text>
            And I'm another text with the same default style!
          </mj-text>
        </mj-column>
      </mj-section>
    </mj-container>
  </mj-body>
</mjml>

If you want to set a style for every components rather than just a specific one, you can also use <mj-all />.

@ngarnier , thanks for your reply, it almost reach my thought, through it has to define for every components, but it better than use mjml-class.
I still hope it will look alike my suggestion, so that we can reduce lots of code onmjml.


CMD closing after download start

Hello,
So my problem is that the cmd is closing after starting the download.
That i did:

I just first started the program through the .exe
Made the setup (choosing using the offline web gui)
used the download helper and searched for: "That time i got reincarnated as a slime"
Chossen anime "1" was listed after the search
program searched for seasons and episodes
choosen to download all seasons
cmd closed

I noticed the download folder for the anime is created and got image.jpg, info.html, info.json and stream.json
Thankyou for your help.
EDIT:
The Template has wrong relative paths, insted of "../../x" there is only one "../x" needed.
Also then i click on streams it tries to open "streams.json" which does not exits, is the file "stream.json" meaned?

Could you run the exe trough a terminal?
(Open cmd, cd into the folder, ./AniWorld.exe and then provide the error message)

So it turns out the vow Downloader I am using does not work because vow updated Their site. I will fix it as soon as I get back

I only saw it now sorry @JMcrafter26 ... Nice that you found the problem @Someone266,  im looking forward to the fix!

It should work now. No need to manually update. The downloader will update itself automatically to the version 1.1.5

I don´t ask why two account xD... So i noticed that the offline web server doesn´t load the css correkt which i think is because of the ../../x.css in the html files and coud be fixed by replacing it with ../x.css and the same with the scripts(Forkes for me). Also the videos player isn´t finding the videos(this coud be because the downloader not finished all episodes yet), I think the problem with the video player is caused because of the location the script is searching for the video files which is anime/video/season/episode.mp4 but the episodes are in the folder where the .exe is located.


ggml.o missing.

Hi,
I've created a blank Rust project with a single dependency:
llama_cpp_rs = "0.3.0"

However, when I tried to compile it, the build failed with the following error:
cargo:warning=ar: /Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/llama.cpp/ggml.o: No such file or directory

  --- stderr

  error occurred: Command ZERO_AR_DATE="1" "ar" "cq" "/Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/libbinding.a"
"/Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/073db387043af495-common.o"
"/Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/30b5508d68fcb5a8-llama.o"
"/Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/8f1a5a601f45df90-binding.o"
"/Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/llama.cpp/ggml.o" with args ar did not execute successfully (status code exit status: 1).

I checked the folder /Users/.../llm-test/target/debug/build/llama_cpp_rs-fbb4c38a7b53ae1d/out/ and found that there was no llama.cpp subfolder, nor the expected files.
Interestingly, when I cloned the llama_cpp_rs repository directly and compiled it, the build succeeded without any issues. As a workaround, I copy-pasted the missing files into my blank project and retried the compilation—it worked.
Is there something I’m doing wrong, or could this be a configuration issue with my system? Any advice on resolving this without using the manual workaround would be greatly appreciated.
Host: Apple M2 Pro
OS: macOS Sonoma 14.5
Rust: rustc 1.80.1 (3f5fd8dd4 2024-08-06)

same issue

Clone the repository in your project root.

git clone --recurse-submodules https://github.com/mdrokz/rust-llama.cpp

cd to folder

cd rust-llama.cpp/

Build the project

cargo build

or
cargo build -- release

Add dependency in your toml file like this:

[dependencies]
llama_cpp_rs = {path = "rust-llama.cpp"}


UI of login page

Hey @codervivek5 I am GSSOC contributor
Please level this issue as GSSOC'24
The UX of login page  seems quite boring it can be improved a bit by adding background images and providing additional features.

Let's connect with us on discord so that I can tell the exact requirements


add data to the package

We will be using the Santa Barbara Corpus of Spoken American English to attach to the package. The data is licensed under CC-BY-ND, which means we are not allowed to distribute a derivative; unfortunately, an R object with a dataset is a derivative, so we need to distribute only the raw data and create the R object on the fly.
Perhaps contacting<EMAIL_ADDRESS>to ask for specific permission is worthwhile? The original author mentioned with the license (John W. DuBois) does not seem to be connected to the department anymore (his page is empty).

I have not succeeded in getting in touch with the corpus creator. It also occurs to me that creating an R object on the fly would replicate the work done in scikit-talk (unless it can be done by invoking that package, e.g. through reticulate).
I think we should look more seriously into the GPL-licensed IFADV corpus — it was specifically designed for free use including commercial use so it would be very painful if it were not possible. The 2008 LREC paper by the corpus creators is very clear about this:
https://www.fon.hum.uva.nl/IFA-SpokenLanguageCorpora/IFADVcorpus/Documents/LREC2008RvSetal.pdf

A freely available annotated corpus is presented, gratis and libre, of high quality video recordings of face-to-face conversational speech. Within the bounds of the law, everything has been done to remove copyright and use restrictions.
and:

All our participants were asked to sign copyright transfer forms that allow the use of the recordings in a very broad
range of activities, including unlimited distribution over the Internet.

The paper foresees some of the implications of using the GPL (see §6) and specifies that the "source" that must be included to make the derivative version GPL-proof:

The GPLv2 allows unlimited use and distribution of the licensed materials. There is however a condition to (re-)distributing adapted or changed versions of the “works”. Whenever such changes fall under copyright laws, ie, when they create a derivative work in the sense of of the law, they must be distributed under the same license, ie, the GPLv2. And that license requires the release of the “source” behind the works
This condition raises the question of what the source of a corpus recording or annotation is. The short answer is, everything needed to reproduce the changes in whatever format is customary for making changes. Examples would be Praat TextGrid or ELAN EAF files.

On one reading then, it seems we could use a portion of the IFADV data in the package, if we also include the original TextGrid or EAF files for that portion. However, it is not clear to me whether this ultimately comes down to the same issue was with the English data, and whether we'd need to create an R object on the fly. Given the express goal of the IFADV project to allow any uses including unlimited distribution that would be a shame.

I had come to similar conclusions.
This does mean we need to change our license to GPL, but that should be OK; especially since we have good reason to do so. (I will nevertheless double check this.)
The source behind the works in this context means code or software; this is openly available in our case, so not a worry. As for manipulations done on the source material, R actually has a neat standard to include any additional code that was required to create the derivative objects we ship with our package: we can include a script in the data_raw/ folder of the package. This way, datasets can be recreated should this be necessary when the package is updated.
To cover all our bases, and work reproducibly, we can use this standard to clearly document our workflow from original data to our included data objects.

Another proposal:
Instead of including the IFADV dataset in this package, we can package it separately for R users. Given the sheer amount of materials, and the fact that our code does not depend on it (and can easily use the dataset once it's packaged) this would make sense and make the talkr package lighter.
This would also allow us to stay outside the GPL for our code (or at the very least: avoid complex dual licensing issues), which is worthwhile (see e.g. explanations in this discussion on the ggplot2 github). Knowing that the tidyverse/ggplot2 folks made an extensive effort to relicense away from GPL, and we want to contribute to their ecosystem, is another argument for me to keep with the more permissive Apache license.
Do you agree @mdingemanse? If so, I will close this PR and generate a new GPL-licensed data package that includes the ifadv data (we can simply call it ifadv).

I'm totally happy with that!

The data package is here: https://github.com/elpaco-escience/ifadv


change petset to statefulset for elasticsearch and cockroachdb

minor change, to make petset to statefulset.

Closing due to inactivity. Feel free to re-open if you decide to work on this again.

Sorry for late response, submitted another PR for part of the fix in this one: https://github.com/kubernetes/charts/pull/1273/
and for elasticsearch, I need to do more test before upload another seperate PR.


Is wrapStore still needed

https://github.com/StyleT/webext-pegasus/blob/e3f19980efb3ca1b501f5b21414e7d87dbaaa80c/packages/store-zustand/README.md?plain=1#L21C1-L52C4
Doesn't seem like the import is used in this example.

Hi! It shouldn't be needed. I'll take a closer look tomorrow

Thanks, pretty sure it's not needed I'm not using it and works great, awesome library!

Published as v0.3.6. Thanks for your contribution!


merge from template-coveralls

.github/workflows/codeql_analysis.yml

chore: add 16.10.0 (jobs.analyze.steps.with.node-version)

:tada: This PR is included in version 4.3.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v4.3.8

Your semantic-release bot :package::rocket:


RuntimeError: mat1 and mat2 shapes cannot be multiplied (1x2 and 6x64)

Hi,
Thank you for your work. The code at cityscapes_mtl_xtc.py bounced with this error. Could you please have a look? I'm using torch 1.12.0 + cu116.
Traceback (most recent call last):
  File "/share/castor/home/leh/projects/MTPSL/cityscapes_mtl_xtc.py", line 191, in <module>
    con_loss = mapfns(train_pred_ind, train_target_ind, feat_aug[ind_].unsqueeze(0), copy.deepcopy(w), ssl_type=opt.ssl_type)
 File "/share/castor/home/leh/projects/MTPSL/model/mapfns.py", line 167, in forward
    mapout_source = self.mapfns(source_pred, input_task=source_task)
File "/share/castor/home/leh/projects/MTPSL/model/mapfns.py", line 90, in forward
    g_encoder[i][0] = self.encoder_block[i](x)
File "/share/castor/home/leh/projects/MTPSL/model/mapfns.py", line 36, in forward
    gamma = torch.mm(A_taskpair, self.gamma.t())
RuntimeError: mat1 and mat2 shapes cannot be multiplied (1x2 and 6x64)

Perfect! Thank you for the promptly fix.


[FLINK-11929][runtime] remove not used transientBlobCache

What is the purpose of the change
remove not used transientBlobCache
Brief change log
removed the transientBlobCache in ClusterEntrypoint class
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no )
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@tillrohrmann can you help me to review this pr? thanks.

@flinkbot approve all


Kotlin icon does not display for Kotlin scripts (files with *.kts extension)

In VS Code, the extension provides a nice looking icon for regular Kotlin files (.kt) but not for Kotlin script files (.kts).

It would be nice if the icon were used for Kotlin scripts as well.

@TAGC Your file icon theme is reponsible for the icons, so you might want to report the issue there. Just as a side note, I have added Kotlin icons for .kt and .kts files to the Seti UI theme, which is the default icon theme in VSCode:

With Seti, both .kt and .kts files will be highlighted:

Neat! Thanks for looking into this.


Use stb libs instead of raylib

In atlas_builder.odin I currently use raylib to do the image processing. Raylib probably just uses the stb libs that I can instead use directly.

Fixed in https://github.com/karl-zylinski/atlas-builder/commit/fb0597344ca14370a5ac5ba1015a879a31878424 and the last few commits before it


Bash Completions (bashcompinit)

Can/Are bash completions (be) supported using bashcompinit  detailed here ?
cheers

I put the following to ~/.zshrc to load completion, and this will load https://github.com/ohmyzsh/ohmyzsh/blob/master/lib/completion.zsh to your zsh which should contain bash completion.
zinit snippet OMZ::lib/completion.zsh

The bashcompinit & associated stuff isn't directly related to Zinit, so they can be used with it with no obstacles.

Thanks.
So there is no "mechanism" in zinit for bashcompinit like there is for compinit ?
cheers

I bumped into an issue with bashcompinit as well and thought it might fit in here. If it's unrelated, please apologize and let me know.
I've tried to load the azure-cli completions (az) like this:
zi lucid for \
 has'az' \
 as'completion' \
 id-as'az_completion' \
 mv'az_completion -> _az' \
 atinit'autoload -Uz bashcompinit && bashcompinit' \
    https://github.com/Azure/azure-cli/blob/dev/az.completion \

The completions however won't work. bashcompinit seems to be loaded correctly (after the shell startup has finished), but my .zcompdump doesn't contain an entry for that. Sourcing the file manually after startup works, so there shouldn't be an issue with the file itself, I guess. Any ideas?

@Gerrit-K Try running zicdreplay.
@thecontinium No there's no need to.

@medina7 Thanks, but unfortunately this doesn't help. I already have zicdreplay in my atinit ice for fast-syntax-highlighting. I also tried to run it directly after bashcompinit as well as manually in the loaded shell - all without success.

@Gerrit-K What does the zinit cdreplay  say in the running shell, does it say something about the plugin?

Btw. With the recent Zinit you can use autoload'#bashcompinit'  instead of the atinit''.

@psprint thanks for the hint on autoload 👍  Unfortunately zinit cdreplay doesn't say anything about the az completion, only from another plugin:
$ zi cdreplay
Running compdef: _tmux _zsh_tmux_plugin_run

It's been a while ... but this is bugging me every time I'm using az, which I needed to increasingly often in the last half year. I was trying to make it to work by putting the autoload -Uz bashcompinit && bashcompinit at different (and multiple) locations in my startup scripts and also deactivating other completion-related plugins one by one, but it just wouldn't want to cooperate with the zinit completion handling.
What I now ended up with is this "hack":
zi wait lucid for \
 has'az' \
 as'null' \
 id-as'az_completion' \
 mv'az_completion -> _az' \
 atload'autoload -Uz bashcompinit && bashcompinit && source _az' \
    https://github.com/Azure/azure-cli/blob/dev/az.completion

This does seem to work consistently, but:

It essentially completely bypasses the zinit completion system
I can't use as'completion' because that doesn't work
I can't use pick'_az' or src'_az' because these are called before atload (I couldn't make it to work using atinit either)
autoload'#bashcompinit' instead of atload'autoload -Uz bashcompinit && bashcompinit && ... didn't work
I'm expecting this to be a bad workaround performace-wise

As I said, it currently "works", but, @psprint (or anyone else familiar with the code), I would greatly appreciate if you could take another look at it. Thanks!

in my case I installed awscli with arch's pamac, but the completion won't work as documented in turbo mode.


[client cli]: export blocks on db with no blocks prints junk

$  ./target/debug/substrate export-blocks --from 0 --to 100
2019-12-12 11:57:58 DB path: /share/substrate/chains/flaming-fir/db
2019-12-12 11:57:59 Initializing Genesis block/state (state: 0xd733…e696, header-hash: 0xb653…1d25)
2019-12-12 11:57:59 Loading GRANDPA authority set from genesis on what appears to be first startup.
2019-12-12 11:57:59 Loaded block-time = BabeConfiguration { slot_duration: 3000, epoch_length: 200, c: (1, 4), genesis_authorities: [(Public(00299981a2b92f878baaf5dbeba5c18d4e70f2a1fcd9c61b32ea18daf38f4378 (5C4vDQxA...)), 1), (Public(482a3389a6cf42d8ed83888cfd920fec738ea30f97e44699ada7323f08c3380a (5DhKqkHR...)), 1), (Public(482dbd7297a39fa145c570552249c2ca9dd47e281f0c500c971b59c9dcdcd82e (5DhLtiaQ...)), 1), (Public(6e7e4eb42cbd2e0ab4cae8708ce5509580b8c04d11f6758dbf686d50fe9f9106 (5EZaeQ8d...)), 1)], randomness: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], secondary_slots: true } milliseconds from genesis on first-launch
2019-12-12 11:57:59 Creating empty BABE epoch changes on what appears to be first startup.
2019-12-12 11:57:59 Exporting blocks from #0 to #100
e3U_    ,1۝ T,g
              A]?
2019-12-12 11:57:59 #0
.uL9bW燆L%

From what I understand, this is intended behaviour?
When we export blocks we encode them, so here we're seeing an encoded version of the blocks.
We could try and differentiate based on whether isatty() returns true or something of the sort but I don't think that's necessary..?
The code that's generating this is here https://github.com/paritytech/substrate/blob/3cc0973aff3f5b507c8ed1a13934bd35697b251f/client/service/src/chain_ops.rs#L231-L252
Specifically, lines 237 and 248.

Yeah, we should probably add a mandatory output file argument to the CLI. Or use json format as default.