exrmetrics: compilation error

While updating the openexr package in pkgsrc, I noticed the following compilation error on NetBSD-10.99.12/amd64 with gcc 12.4.0:
/scratch/graphics/openexr/work/openexr-3.3.0/src/bin/exrmetrics/exrmetrics.cpp: In function 'void exrmetrics(const char*, const char*, int, Imf_3_3::Compression, float, int)':
/scratch/graphics/openexr/work/openexr-3.3.0/src/bin/exrmetrics/exrmetrics.cpp:486:10: error: 'isinf' was not declared in this scope; did you mean 'std::isinf'?
  486 |     if (!isinf (level) && level >= -1)
      |          ^~~~~
      |          std::isinf
In file included from /usr/pkg/include/Imath/ImathMath.h:16,
                 from /usr/pkg/include/Imath/ImathVec.h:17,
                 from /usr/pkg/include/Imath/ImathBox.h:16,
                 from /scratch/graphics/openexr/work/openexr-3.3.0/src/lib/OpenEXR/ImfFrameBuffer.h:21,
                 from /scratch/graphics/openexr/work/openexr-3.3.0/src/lib/OpenEXR/ImfDeepFrameBuffer.h:11,
                 from /scratch/graphics/openexr/work/openexr-3.3.0/src/bin/exrmetrics/exrmetrics.cpp:10:
/usr/include/g++/cmath:605:5: note: 'std::isinf' declared here
  605 |     isinf(_Tp __x)
      |     ^~~~~

Following the compiler's suggestion fixes the build:
--- src/bin/exrmetrics/exrmetrics.cpp.orig      2024-09-26 23:34:32.000000000 +0000
+++ src/bin/exrmetrics/exrmetrics.cpp
@@ -482,7 +482,7 @@ exrmetrics (
     }
     else { compression = outHeader.compression (); }

-    if (!isinf (level) && level >= -1)
+    if (!std::isinf (level) && level >= -1)
     {
         switch (outHeader.compression ())
         {

fix lgtm, thanks


Remove the fix_i18n_deprecation_warning method

fix_i18n_deprecation_warning is no longer needed since this
configuration is the default in Rails now

Removing the workaround for the deprecation warning looks like a great idea, but can you remove the unrelated changes? We'd like to keep the focus of the change small. Some of these refactorings contradict our style guide, but in any event they should be in a separate PR/commit.

@geoffharcourt done, I'll check the style guides to make another pull request with this fixes if that's ok
I did it in the same PR since some projects try to avoid PR with only code style fixes.

@gssbzn thanks!

Source:

Rails 4.1 now defaults the I18n option enforce_available_locales to true.
-- http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#i18n-enforcing-available-locales

Thank you! Merged in. :)


[Event Request] Table 36 "Sales Header" - OnBeforeUpdateOutboundWhseHandlingTime

We are migrating our code from NAV 2018 to BC16.4. In the Table 36 "Sales Header", in the procedure UpdateOutboundWhseHandlingTime, we need to modify standard code and add our own. To do so, we need a IsHandled flag and an event publisher, like this :

With this integration event :

Do you think it could be possible ?
Thank you for your work.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Newsletter 11: Macroquad & Nanoserde

Part of #172 ("Newsletter 11: Coordination/Tracking")

Made a few style changes

Made a few style changes

Merged, thanks for the PR!


Check for any skipped unit tests when running in CI

why not use this https://github.com/kaiza/tslint-jasmine-rules


Broken Link in README

'developer guides' link in README.md, https://poynt.com/tag/guides/, is broken.
Should it link to https://poynt.github.io/developer-docs/ instead?

@mll11 yup good point, it should


mouse-controls are attached to the window, behaviour should be configurable

mouse-controls are attached to the window, behaviour should be configurable
https://github.com/borismus/webvr-polyfill/blob/master/src/mouse-keyboard-position-sensor-vr-device.js#L37-L40
When custom video controls such as a seek bar are created, mouse events from those bubble to the window causing unwanted camera movement. The element used here should be configurable and/or the methods bound to the window should be configurable.
As a work-around I've modified a local copy of this file with the following,
MouseKeyboardPositionSensorVRDevice.prototype.onMouseDown_ = function(e) {
  var elem = (function (e) {
    var fn = function () {};
    if (typeof e === 'object' && e) {
      if ('target' in e) {
        fn = function (ev) {
          return ev.target;
        };
      } else if ('srcElement' in e) {
        fn = function (ev) {
          return ev.srcElement;
        };
      }
    }
    return fn(e);
  }(e));

  if (/canvas/i.test(elem.tagName)) {
    this.rotateStart.set(e.clientX, e.clientY);
    this.isDragging = true;
  }
};

Put that in a pull request!
To really get rid of all the implicit document.body assumptions, you have to modify the polyfill, boilerplate, and VREffect.js. Also, the polyfill assumes there is one window, so if you try making multiple webgl windows, they all move with the mouse. To really make this work (for things like VR slideshows) will require a significant overhaul.

I submitted a PR for some related issues. The PR was ignored and later closed.
https://github.com/borismus/webvr-boilerplate/pull/77#event-522438711

Please re-open as needed.


Example showing how to add loaded plugins

This might seems sort of obscure but in the examples in the wiki the default has a footer of "neovim loaded 63 plugins". It's not in the README but skimming through the code it looks like this information is obtained by using the dein plugin manager.
Maybe have a section in the wiki for code snippets for getting the same the in the footer. For example if the user has fd installed and is using packer to install plugins.
" we ignore the directories 'start' and 'opt'
let g:total_plugins = trim(system("fd -d 2 . $HOME'/.local/share/nvim/site/pack/packer' | head -n -2 | wc -l"))
let g:dashboard_custom_footer = ['                               loaded '. g:total_plugins .' plugins     ']

Note ~/.local/share/nvim/site/pack/*/opt and  ~/.local/share/nvim/site/pack/*/start are the default runtime for plugins in neovim. Any plugin manager that installs to this directory can use this could if they change packer to whatever their package manager uses.

Yep. dashboardh can get total plugins from vim-plug or dein. the packer use native package path and it doesn't provide any api for get plugins number.   your code snippet seems ok, but if custom the packer root path the code snippet will be failed.
Another question why not use globpath function to get the total folder number that under  pack/*/opt and pack/*/start
I think it's better  than use  command fd?

What would globpath command look like?

let path = os.getenv('HOME').'/.local/share/nvim/site/pack/packer'
echo len(filter(split(globpath(path, '.*'), '\n'), '!isdirectory(v:val)')) -- will got the folder count number.

That is much better

Now that I think about it though that tells you how many total plugins you have, not which ones you have loaded.

function totalPlugins()
    paths = {};
    for match in (package.path..';'):gmatch("(.-)"..';') do
        table.insert(paths, match);
    end
    for k,_ in pairs(paths) do
        if string.match(paths[k], "nvim/site/pack/") then
        count = count + 1
        end
    end
    print('plugins loaded: ' .. count)
end

If you using neovim you could use something like this

All your code examples only work under *nix, so you need to consider the windows environment.hmm why not
vim.fn.globpath(),Excessive use of regularization is not efficient.

Do you know what the default runtime is on Windows? I just assumed it was something similar with a different prefix. vim.fn.globpath() is great.

Now that I think about it though that tells you how many total plugins you have, not which ones you have loaded.

The number of folders in ~/.local/share/nvim/site/pack/packer/start are loaded on start, so that would be the correct number of plugins...

The number of folders in ~/.local/share/nvim/site/pack/packer/start are loaded on start, so that would be the correct number of plugins (am I missing a special case?)

Commonly optional plugins are loaded on filetype, if you use rust.vim you probably only need it when working on rust files. Some plugins are loaded on command or keymap as well. You may be working on these in other buffers and they would be loaded.

You're only supposed to see the number of plugins loaded on startup, not the other ones

by using :Dashboard

oh

closed. plan to rewrite it by lua.


⚠ Bofrost.es has degraded performance

In 345f9f3, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1871 ms

Resolved: Bofrost.es performance has improved in bee52f0 after 8 minutes.


[WIP] Don't expand all organisation details

I've identified that these fields are the only ones being used, so we don't need to present the entire details hash.
We should limit the number of fields being included in link expansion to reduce the size of content items being presented.
If we were to make dependency resolution work on second level fields, this would also help to reduce the amount of activity that happens when organisations change as there would be a limited number of fields which when changed cause updates to the dependencies.

Nice one Tom 👍


Simplify submitting logs in parallel siightly.

I haven't tested this, other than to compile it.

Thanks! I figured out basically the same thing (as mentioned on IRC :P)


Support rendering oneOf constraints for required properties

JSON schema support the following pattern to define valid groupings of required properties:
{
    "type": "object",
    "properties": {
        "emailAddress": {
            "type": "string"
        },
       "phoneNumber": {
            "type": "string"
        }
    },
    "oneOf": [
        {
            "required": [ "emailAddress" ]
        },
        {
            "required": [ "phoneNumber" ]
        }
    ]
}

Currently this render in RapiDoc as:
...
ONEOF :
  prop1: {missing-type-info}
  prop2: {missing-type-info}

What do you think would be a good rendering for this? Maybe something like:
oneOf:
  - required: *emailAddress
  - required: *phoneNumber

Thanks for bringing it up,
Will be holding discussion on it. This is how I imagine it to be shown
Schema
ONE-OF:
1: {
     emailAddress*: string
   }
2: {
     phoneNumber*: string
   }

Example
{
  emailAddress: "string"
}

I am open to take a PR on this

So we would effectively merge the oneOf required constraints w/ the outer object as if the properties definitions was in the oneOf?
Turning this:
{
    "type": "object",
    "properties": {
        "emailAddress": {
            "type": "string"
        },
       "phoneNumber": {
            "type": "string"
        }
    },
    "oneOf": [
        {
            "required": [ "emailAddress" ]
        },
        {
            "required": [ "phoneNumber" ]
        }
    ]
}

into something equivalent to:
{

    "oneOf": [
        {
            "type": "object",
            "properties": {
                "emailAddress": {
                    "type": "string"
                }
            },
            "required": [ "emailAddress" ]
        },
        {
            "type": "object",
            "properties": {
               "phoneNumber": {
                    "type": "string"
                }
            },
            "required": [ "phoneNumber" ]
        }
    ]
}

Some question raised during our discussion
with no type/property/item information is it a valid JSON schema ?
{
    "required": [ "phoneNumber" ]
 }

per the JSON schema spec
each item of oneof array must be a valid json schema.
can you point me to a location where it would confirm if just having a required property makes the object a valid JSON schema ?

Looking at the meta-schema for validation: http://json-schema.org/draft/2019-09/schema it doesn't look like any of they keyword is actually required.

My understanding is that a schema like:
{
"$schema": "https://json-schema.org/draft/2019-09/schema",
"required": ["foo"]
}
would simply means that a "foo" property is required (independently of any type constraints on the actual property).

I think thats where RapiDoc is diffing in its interpretation,
{
  "required": ["foo"]
}

the way RapiDoc would like to think about the above definition is,  items in required array is valid only when they are defined on the instance.
so the above schema def per RapiDoc would yield to
{

}

If items in required array aren't defined we wont have any type for foo and that would mean that it can be anything
a primitive, null, object or array and representing something without a type will be very dogmatic.
so if I am not wrong your interpretation of it should look like
{
  foo : <missing type info>
}

PS: This issue is still under discussion, and we are open to changes/suggestions

so if I am not wrong your interpretation of it would yield to,
{
 foo : <missing type info>
}

Maybe it should be:
{
   foo*: <missing type info>
}

to capture that is is required (notice the * before the colon).
But then it's unclear what rapidoc should do when the properties type are defined earlier in the root schema. Showing duplicate information may create more confusion and feel a bit redundant:
{
  emailAddress: string
  phoneNumber: string
}
ONE-OF:
1: {
     emailAddress*: string
   }
2: {
     phoneNumber*: string
   }

items in required array is valid only when they are defined on the instance.

I think this is aligned with the JSON schema spec wording (or at least my interpretation of it).
Maybe rapidoc could have a way to render this particular contraint: valid only when they are defined on the instance. separately from (or without knowning about) its type.
{
  emailAddress: string
  phoneNumber: string
}
ONE-OF:
1: {
      emailAddress*
   }
2: {
      phoneNumber*
   }

Highly looking for support of this feature.
ReDoc supports both definition options.

{
    "type": "object",
    "properties": {
        "emailAddress": {
            "type": "string"
        },
       "phoneNumber": {
            "type": "string"
        }
    },
    "oneOf": [
        {
            "required": [ "emailAddress" ]
        },
        {
            "required": [ "phoneNumber" ]
        }
    ]
}

{

    "oneOf": [
        {
            "type": "object",
            "properties": {
                "emailAddress": {
                    "type": "string"
                }
            },
            "required": [ "emailAddress" ]
        },
        {
            "type": "object",
            "properties": {
               "phoneNumber": {
                    "type": "string"
                }
            },
            "required": [ "phoneNumber" ]
        }
    ]
}

@bkarvas, we do support the 2nd, but I think the discussion here is on how to interpret the first schema def.
does Redoc produces the same example output with both definition ?
For the 1st schema swagger produces
{
  emailAddress: string
  phoneNumber: string
}
ONE-OF:
1: {
   }
2: {
   }

and the an example for the schema would be
{
  emailAddress: "string",
  phoneNumber: string
}

which majority of our team thinks is in more inline with json schema wording. we are inclining to go this route
if you have any opinion on it, then now is the time to bring it up.

CC: @proppy

@mrin9, yes, ReDoc produces the same result for both definition. Look at the pictures below. From my point of view you can interpret the 1st schema the same way as you do with the 2nd

Sample YAML:
openapi: '3.0.2'
info:
  title: RapiDoc Issue 253 & 259
  version: '1.0'
paths:
  /test1:
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Amount1'
        description: JSON request body for new payment initiation API.
        required: true

      responses:
        '200':
          description: OK

        "400":
          description: Bad request.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Errors'
              example:
                errors:
                - error: 'INVALID_REQUEST'
                  message: 'Invalid request.'
        "401":
          description: Unauthorized.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Errors'
              example: |
                {
                  "errors": [
                  {
                    "error": "UNAUTHORIZED",
                    "message": "Attempt to call a method without a proper licence or invalid certificate."
                  }
                  ]
                }

  /test2:
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Amount2'
        description: JSON request body for new payment initiation API.
        required: true

      responses:
        '200':
          description: OK
        "400":
          description: Bad request.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Errors'
              example:
                errors:
                - error: 'INVALID_REQUEST'
                  message: 'Invalid request.'
        "403":
          description: Forbidden.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Errors'
              examples:
                example-1:
                  value:
                    errors:
                    - error: FORBIDDEN 1
                      message: No disposal rights.
                example-2:
                  value:
                    errors:
                    - error: 'FORBIDDEN 2'
                      message: 'No disposal rights.'

components:
  schemas:
    Amount1:
      description: Payment amount.
      example:
        equivalentAmount:
          currency: USD
          value: 1245.50
        instructedAmount:
          currency: USD
          value: 1245.50
      oneOf:
        - properties:
            instructedAmount:
                $ref: '#/components/schemas/InstructedAmount'
            equivalentAmount:
              $ref: '#/components/schemas/EquivalentAmount'
          required:
            - instructedAmount
        - properties:
            instructedAmount:
                $ref: '#/components/schemas/InstructedAmount'
            equivalentAmount:
              $ref: '#/components/schemas/EquivalentAmount'
          required:
            - equivalentAmount

    Amount2:
      description: Payment amount.
      example:
        equivalentAmount:
          currency: USD
          value: 1245.50
        instructedAmount:
          currency: USD
          value: 1245.50
      oneOf:
      - required:
        - instructedAmount
      - required:
        - equivalentAmount
      properties:
        instructedAmount:
          $ref: '#/components/schemas/InstructedAmount'
        equivalentAmount:
          $ref: '#/components/schemas/EquivalentAmount'
      type: object

    InstructedAmount:
      description: Amount and currency in the instruction.
      example:
        currency: USD
        value: 1245.50
      properties:
        value:
          description: The amount value.
          example: 1245.50
          maximum:<PHONE_NUMBER>999.99
          minimum: 0
          multipleOf: 0.01
          type: number
        currency:
          description: Amount currency. Currency code according to ISO 4217 = 3 capital
            letters.
          example: USD
          maxLength: 3
          pattern: ^[A-Z]{3}$
          type: string
      required:
      - currency
      - value
      type: object
    EquivalentAmount:
      description: Equivalent amount and currency.
      example:
        currency: USD
        value: 1245.50
      properties:
        value:
          description: The amount value.
          example: 1245.50
          maximum:<PHONE_NUMBER>999.99
          minimum: 0
          multipleOf: 0.01
          type: number
        currency:
          description: Amount currency. Currency code according to ISO 4217 = 3 capital
            letters.
          example: USD
          maxLength: 3
          pattern: ^[A-Z]{3}$
          type: string
      required:
      - currency
      - value
      type: object

    Errors:
      type: object
      description: Collection of application errors.
      properties:
        errors:
          description: List of application errors.
          type: array
          items:
            $ref: '#/components/schemas/Error'
    Error:
      description: An application error item.
      type: object
      required:
      - error
      properties:
        error:
          description: Error code.
          example: ERROR_CODE
          type: string
        parameters:
          description: Error parameters.
          type: object
        scope:
          description: Error scope.
          type: string
        message:
          description: Errro detail.
          type: string
          example: Invalid request.

thanks @bkarvas for your input and the screenshots. I will keep this open for some time for other to leave their feedback/opinion about it. We will also discuss within the team and then provide a fix

Any progress on this issue?

We discussed this issues within our team and came to a consensus that the way the incomplete schema is represented in <rapi-doc> v8.3.0 is good enough.
To expand a bit more on that. We are talking about how to represent the following schema in the spec
openapi: 3.0.0
info:
  version: 0.0.1
  title: Testing incomplete schema
paths:
  /some-path:
    get:
      summary: to test
      responses:
        '200':
          description: Successful response
            application/json:
              schema:
                type: object
                properties:
                  emailAddress:
                    type: string
                  phoneNumber:
                    type: string
                oneOf:
                  - required:
                      - emailAddress
                  - required:
                      - phoneNumber

Apart from discussing within our team that, we have checked with many other commercial and open-sourced  openapi renderers. some didnt work and some representation did not make much sense.
One of the representation of the above schema was from Swagger-UI which aligns with our interpretation of this.
for an comparison below images shows how its represented in Swagger UI and RapiDoc
Swagger

RapiDoc

I hope it works for everyones use-case


libsigrok_0_3: fix

Apparently we have an old-version override and it doesn't make the bindings at all, so only run the installCheck when we know it should succeed.

Motivation for this change
Apparently we have an old-version override and it doesn't make the bindings at all, so only run the installCheck when we know it should succeed.
TOTH @eadwu for noticing.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Thanks!


Rewrite and restructure developer eaas documentation #2

anvil app tests, migration guide, new and better images, webapp ui guidelines, etc.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Stan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


gitbase: implement sql.Indexable on all tables

Most of the contents in #279 did not survive because they relied on the index being something generic for all tables when in reality, almost every table has its own logic regarding the index storage.
This implementation differs a lot from what was initially thought in #295. The way the indexes work made it impossible to work that way.
There is also a lot of code that is inside go-git, but that logic is not exposed. If it's ever exposed we might want to refactor some of that.
To sum it up, the implementation looks like this:

Every table has its own key value iterator with its own index key, because most of them need different things stored so they can be converted to rows efficiently after getting the key from the index.
There is some common logic to find packfiles for a given repository and get from there the offsets of the objects that will be indexed.
For ref_commits, commit_trees and commit_blobs there is a common logic rowKeyValueIter and rowIndexIter, since they are stored as is. The other tables had no obvious common logic, so instead of coming up with an abstraction that might be a PITA in the future, I preferred to have some more tedious and perhaps slightly repeating implementations on the other iterators (though there are no exact identical impls).

 Tree entries also needs the pos inside the tree and the rest of the tables are very different. I can make one common object for blobs and commits tho.
On Tue, 5 Jun 2018 at 18:51, Antonio Navarro Perez <notifications<EMAIL_ADDRESS>wrote:
@ajnavarro commented on this pull request.

In commits.gohttps://github.com/src-d/gitbase/pull/298#discussion_r193145645:

@@ -261,3 +294,107 @@ func (i *commitsByHashIter) nextList() (*object.Commit, error) {
return commit, nil
}
}

+type commitIndexKey struct {
Could we have a generic ObjectIndexKey struct for all the objects that are into the packfile?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/src-d/gitbase/pull/298#pullrequestreview-126060182, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABQFFw_m3GywQHDl9yjWrDGTARu2rRCqks5t5rclgaJpZM4Ua80z.

Added the tests and some fixes, along with the unification of the index keys where it was possible. It can be reviewed now.

go-git 4.4.1 has dotgit logic outside internal folder, so we can use it now updating the dependency.

@ajnavarro Since this is against a feature branch and won't go straight to master, what do you think if we review and merge this one first and then in a followup PR I update the dependency and replace the manual impl with the dotgit one?

Fixed errors in travis

Check codecov, appears that squash_join is not tested at all.

Fixed the coverage thing of the squash tables

Everything is fixed now, upgraded go-mysql-server and added engine initialization to the server command.


Updated package versions and supported LUCI version

Update package versions
Update latest supported LUCI version

Is this supposed to go into staging first?


Join multiple teams

Hi,
Wondering if there is support for multiple teams in the matteruser plugin. I have multiple internal teams that it would be nice to integrate Hubot into, so if there is a way to do that without spinning up multiple Hubot instances that'd be awesome.

Never mind, just saw #15

Yeah, sorry about that, the hubot internals are not conducive to the idea.


Improve macro hygiene

Currently, the macros defined in macros.rs capture std, and their behaviour may vary if std is shadowed somewhere in the code. This PR changes this to use an unambiguous path (::std) instead.
Additional reading

@rylev thanks for the quick review! There are more macros in the crate, but those are internal and it's not as dangerous to leave them as-is, since we have full control over their usage. All the same, let me know if you'd like me to change those as well.

@rylev thanks for the quick review! There are more macros in the crate, but those are internal and it's not as dangerous to leave them as-is, since we have full control over their usage. All the same, let me know if you'd like me to change those as well.

Looks good. It's pretty hard to know for sure without tooling to validate that we haven't missed any.

Looks good. It's pretty hard to know for sure without tooling to validate that we haven't missed any.


chore(*): make all graph accesses async, remove need for lock management

This moves the lock on the snapshot graph inside the WorkspaceSnapshot, so the caller never has to manage the lock. Instead, the lock is controlled by the methods defined in the WorkspaceSnapshot implementation. A consequence of this is that all methods on WorkspaceSnapshot must be async, since the RwLock methods are async. But we want this to happen anyway, since shrinking the snapshot means all accesses will have to go through async boundaries to fetch node weights from the caches.

bors r+


[Question]The application packaged with electron-packager or electron-build cannot be opened, and the app is blank after opening

The application packaged with electron-packager or electron-build cannot be opened, and the app is blank after opening.
The page is blank and there are no errors.

There is no problem to open directly with electron .
  • electron-builder  version=22.8.1 os=10.0.19041
  • writing effective config  file=dist\builder-effective-config.yaml
  • packaging       platform=win32 arch=x64 electron=10.1.3 appOutDir=dist\win-unpacked
  • default Electron icon is used  reason=application icon is not set
  • building        target=nsis file=dist\electron-quick-start Setup 1.0.0.exe archs=x64 oneClick=true perMachine=false
  • building block map  blockMapFile=dist\electron-quick-start Setup 1.0.0.exe.blockmap

[Question]The application packaged with electron-packager or electron-build cannot be opened, and the app is blank after opening #423


Tailwind CSS

How would I get tailwind upgraded to a more current version?

@jasperkooij I created https://github.com/bingalls/gatsby-theme-codebushi with a PR.
This upgrades all of the npm packages, including Tailwind.
I ended up injecting a /dist directory, to try testing it, by following https://glebbahmutov.com/blog/npm-install-with-just-github/
It's likely better to copy this repo into the yarn workspace used by gatsby-theme-codebushi
Let me know how this works for you!

Would love to see this upgraded to a more recent version of tailwind... Nice to see a fork out there, but no reason they can't support it in the main repo.


Attachment download failed. Reason -  Buffer cannot be null

Describe the problem
When trying to export Jira there is warning regarding Attachment download. Folders Attachments with proper attachment number is empty. It applies for every attachment
Tool version

Version of the jira-azuredevops-migrator tool 3.0.115

Screenshots
Screenshot added with warning message

Any idea how to fix it?

Any information that could help us reproduce your issue? What kind of file is it?

@Alexander-Hjelm Same issue. We are also unable to download any of the attachment files, whether they are jpg, png, xlsx, pdf, etc. I can download them through the rest API (for example, https:///secure/attachment/389643/myfile.pdf).

@Alexander-Hjelm As stated by Krishna above, even I am facing the same issue, we have been using migration tool from solidify to export issues from Jira, we are unable to export the attachments, we are getting the same error as posted in this ticket.

@Alexander-Hjelm could you please address this issue in the priority..

@Alexander-Hjelm we are awaiting for your response, could you please share us any workaround for this issue, its causing delay in the data migration from jira to ADO.

Attachments are still migrated as expected in our tests for an Agile Jira projects. See the results below.
Jira view:

ADO view:

Could you share more information about the attachments you are trying to migrate? Specifically:

File extension
File size (kB)
File name (Maybe non-supported characters?)

Also ensure that you can download the attachment manually. You can test this out like this: https://support.atlassian.com/jira-software-cloud/docs/download-an-attachment-from-an-issue/. What does the file name become after downloading the issue vs the file name in Jira?
Let me know the attachment info and the results of the manual download!

Also you could try downloading the attachments directly via the Jira Rest API. Try this and let me know the results. See this discussion for example:
https://community.atlassian.com/t5/Jira-questions/Need-to-export-all-attachments-from-a-single-Project-JIRA-Cloud/qaq-p/717930

@Alexander-Hjelm  Please take a look below for the attachment file type/size/ext, also I am able to doenload the attachment manually but some how its failing via migration tool. The same export was working atleast before 10 days but not now.

@SHALINI11-maker Can you confirm that you are running on a Windows x64 system?
Any possibility of trying on a different machine and see if the results are different?

Yes @Alexander-Hjelm  I am using Windows x64 machine, i have been doing this action since February, complete export worked well as expected, for some reason attachments failed to get exported when I noticed it on early last week. even my colleague @krishna-adusumalli has tried in his WIN system, we are facing similar issue.

@Alexander-Hjelm  yes, I am also using Widows x64.  With which Jira version it is tested? Issue is there for
License Information for Jira
Jira v8.20.3

@Alexander-Hjelm  Even we are using Jira Software 8.20.3

Jira v8.x should be supported.
Maybe you fare better if you try v 2.x of our tool? Try e.g.: https://github.com/solidify/jira-azuredevops-migrator/releases/tag/untagged-99b7827246f744fa1909, and let me know the result!

@Alexander-Hjelm  Unable to open this link  https://github.com/solidify/jira-azuredevops-migrator/releases/tag/untagged-99b7827246f744fa1909 , says 404.

Can you see version 2.x if you head over to the Releases page on the main repo page?

@Alexander-Hjelm  As i mentioned before, I have tried both v 2.x/3.x , no luck..

@SHALINI11-maker Have you tried isolating the offending issues in a JQL query? Maybe you are hitting the rate limit with too many requests, and then focusing on only a few issues should work better
// Alexander

@Alexander-Hjelm My JQL query is very simple, i am just querying 1 jira issue which consists of attachments, i tried with different jira issue too, it fails..

Not sure. Without being able to reproduce it's hard to tell at the moment

@Alexander-Hjelm  can we have working session on this please? so that I can replicate and show you.

@Alexander-Hjelm  Awaiting for your response on this.


Fixing quotation marks to copy/paste friendly

Fixing quotation marks to copy/paste friendly so can be pasted in command line

Looks good; thanks @joshts0.


Add Base Entity Type for IdentityServer4.EntityFramework.Entities

As a developer, I want the entities in IdentityServer4 to inherit from a common base class, so that I can write generic repositories or services for performing CRUD functions.
Something along the lines of below would help with creating generic base classes that can be used to reduce repetitive code when writing middle tier code that perform CRUD operations on the IdentityServer4 persistence layer.
Example base class:
public abstract class BaseEntity
{
     public int Id { get; set; }
}

Inherited class:
using System.Collections.Generic;

namespace IdentityServer4.EntityFramework.Entities
{
    public class ApiResource : BaseEntity
    {
        public bool Enabled { get; set; } = true;
        public string Name { get; set; }
        public string DisplayName { get; set; }
        public string Description { get; set; }
        public List<ApiSecret> Secrets { get; set; }
        public List<ApiScope> Scopes { get; set; }
        public List<ApiResourceClaim> UserClaims { get; set; }
    }
}

This would allow for something like below to exist:
 public interface IRepository<T> : IDisposable where T : BaseEntity
    {
        Task<T> GetAsync(int id);
        Task<IEnumerable<T>> GetAllAsync();
        void Add(T entity);
        void Update(T entity);
        void Delete(T entity);
        Task SaveAsync();
        Task<IEnumerable<T>> FindByAsync(Expression<Func<T, bool>> predicate);
    }

I am exposing REST endpoints as part of a project for creating an administration platform for IdentityServer4, and without a way to create a few generics, I'm being forced to write a lot of boilerplate code. I am willing to roll out these changes and submit a PR, if it's something that other users may find useful.

Personally, I don't see a huge benefit in this. I'd only consider it if @scottbrady91 thinks there's value in it. Scott? We either do this in 2.3 or never, I think.

Agreed, I'm not sold. I think the custom stores require minimal effort to implement, allowing you to define your own entities and keys, and whatever patterns your desire.

The custom stores don't solve the problem of creating a CRUD interface for
the data store. I used a different pattern to get around this, so feel free
to close the issue.
On Fri, Aug 3, 2018, 8:35 AM Scott Brady<EMAIL_ADDRESS>wrote:

Agreed, I'm not sold. I think the custom stores require minimal effort to
implement, allowing you to define your own entities and keys, and whatever
patterns your desire.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IdentityServer/IdentityServer4/issues/1940#issuecomment-410240053,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMbxoBVoB5N9_iz5luozGRsYBx8GxSf3ks5uNEOigaJpZM4RSc3G
.

Ok, thanks for the discussion. We'll close it then.

The custom stores don't solve the problem of creating a CRUD interface for the data store. I used a different pattern to get around this, so feel free to close the issue.
…
On Fri, Aug 3, 2018, 8:35 AM Scott Brady @.***> wrote: Agreed, I'm not sold. I think the custom stores require minimal effort to implement, allowing you to define your own entities and keys, and whatever patterns your desire. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1940 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AMbxoBVoB5N9_iz5luozGRsYBx8GxSf3ks5uNEOigaJpZM4RSc3G .

Hi @jamescrowley321, would you mind sharing your solution with us please?
Thanks in advance.


Chebi supliment

Looks good in general. I made a number of changes, mostly just for formatting and to have it match the style of the rest of the code base more closely. The changes I made that will affect the output are:

Now it only outputs nodes that actually have chebi roles attached to them, which is a much smaller number of nodes. We don't need the others for this data source - the names will always come from the node normalizer not from this.
I removed the 'restroles' property which was just a list of CHEBI ids which were not converted to role properties. I left a line of code that would put them back in if that's really what we want.

If this is all good with you let me know and we'll merge it in.

Yes, you are right.
The rest roles contained both the chebis that already have roles and ones with no existing roles.
I had earlier thought of retaining only chebis with no roles in the 'restroles'; however, allowing node normalizer to take care of it sounds more reasonable.


Fixes #935, cleans up authData null keys on login for android crash

Current coverage is 91.45%

Merging #978 into master will increase coverage by +0.03% as of 3ca74f3

@@            master    #978   diff @@
======================================
  Files           73      73
  Stmts         4384    4391     +7
  Branches       876     879     +3
  Methods          0       0
======================================
+ Hit           4008    4016     +8
  Partial         10      10
+ Missed         366     365     -1

Review entire Coverage Diff as of 3ca74f3

Powered by Codecov. Updated on successful CI builds.

Remove the console.log and then LGTM

We should probably do something in the android SDK as the JS SDK does the cleanup


combine keep_attrs and combine_attrs in apply_ufunc

As discussed this extends keep_attrs in apply_ufunc to also accept merge strategy names and use merge_attrs (making it easier to add more merge strategies).
Handling attrs on variables / coords is still missing.

[x] Tests added
[x] Passes pre-commit run --all-files
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

it seems apply_ufunc already applies keep_attrs/combine_attrs on the data variables, but not the coords. Not sure if we should try to combine attrs on coords, too (should be fixed by adding a keep_attrs kwarg to align / deep_align)

this is ready, too. Not sure if we should merge before the release, though.

this is ready, too. Not sure if we should merge before the release, though.

As good a time as any! But as ever your call on whether we can be sufficiently confident

Thanks @keewis. I found the compute_attrs thing a little complicated and hard to understand. But I think it's OK and am going to merge now. If you have a clever idea for something clearer, we can address that later.
Thanks!


Documentation of meeting on 2nd December

Document meeting and add to meeting summary tool

Link here https://docs.google.com/document/d/1p7HwCWKtl_RLmkgx2SVaSPzn-QDYOyI4h2nln2NY418/edit


Modularization

Historically, we've always been dividing core artifacts of the scala.meta platform into: 1) foundation (miscellaneous helpers), 2) scalameta (trees + the entire surface of platform-independent APIs), 3) scalahost (scalac <-> scalameta adapter).
Nowadays, when we have a bunch of functionality packed into scalameta, it seems reasonable to split it into several parts, e.g. tokens + trees + prettyprinting + semantics + parsing + tql. This might be useful both for documentational (easier to understand) and psychological (minimalism) reasons.
We need to see, however, how this is going to play with the current design of "import scala.meta._ should be enough for everyone", where we take package object meta and simultaneously inherit it from all the aforementioned APIs.

Fixed in https://github.com/scalameta/scalameta/pull/242.
The number of modules ended up being almost 3 times as big as planned, but the desired property of needing only one import and only one line in an sbt build is retained.
Issues that would be nice to fix in the future:

Some tests ended up in really weird projects. For instance, an ast serialization test that requires .parse[...] to make sure that trees built from real-world inputs are serialized correctly had to be moved from trees to parsers, because trees can't depend on parsers.
I successfully removed some of the spurious circular dependencies, but inputs and tokens ended up being intertwined in a really tight way. I don't have much time now, so I let them be, but this might probably be improved upon.
Since scalac can't merge package objects from different projects, I had to split scala.meta.syntactic into several parts: tokens, tokenizers, tokenizers.common, parsers, parsers.common. Can't say I'm happy about the 3rd and the 5th.
import scala.meta._ is now implemented by a separate project, so I had to make apis of all the other modules usable without the overarching import. Doing import scala.meta.foo._ or import scala.meta.bar._ will now bring everything relevant into scope. However, if someone does both a specific import and an umbrella one, they are going to be bitten by ambiguities, and I've no idea how to fix that yet.


Renew expired certificate

Version:
v0.8.1
Describe the bug
Was installing k3s on a disconnected environment with no internet access at all. We got it to work, but incidentally we moved the server on a location with internet access. Upon startup the k3s won't start and says: x509: certificate has expired or is not yet valid.
Upon checking the certificate expiry date using this command: cat /var/lib/rancher/k3s/server/tls server-ca.crt | openssl x509 -noout -enddate we found out that the expiry date is Dec 2009. Is there a command to renew the certificate? It seems setting the date of the server does not help at all

You could perhaps try upgrading to v0.10.1 we recently introduced cert rotation this may fix your issue.
While I'm not clear the true nature of the issue this should at least resolve your problem I think.

I started hitting this issue for v0.10.0 today. Upgrading to v0.10.1 fixed my issue. I likely could've jumped to v1.0.0 but been holding off on jumping for the official release.

I believe this has been answered here https://github.com/rancher/k3s/issues/1621  and the issue can be closed.

Closing the issue. If there are further questions let us know and we can reopen if necessary.


Will the detection benefit from a vocal or instruments only version of the song?

Hey,
First of all cool project, thx for it.
I asked me if the pitch detection would maybe benefit from a song version where the vocals got splitted from the instruments using spleeter https://github.com/deezer/spleeter.
And if yes which one would be the needed input?
"For example a ballad with slow background music and a strong female voice can get an accuracy of over 90%"
Sounds like that the voice is the important part or may I be wrong?

Hi,
glad you like my software, it's always nice to get some feedback.
As for spleeter, I already did some extensive testing with the cleaned output it produces. To use it, the "vocals.wav" must be placed in the same folder as the "notes.txt" file and the "#MP3" tag must refer to the vocal file (e.g. "#MP3:vocals.wav"). The result was a bit sobering. Some songs do indeed produce a better accuracy (especially acoustic ones). However for instrumental rich audio, spleeter introduces artifacts/information loss which in turn lowers the overall accuracy. I had a heated debate about this topic with @manureini in the ultrastar play gitter chat, if you are interested in the technical details.
If you are able to get an a capella version of the song you want to transcribe, it will almost certainly produce better results, than the normal version.
I have lots of ideas how to increase the performance for future versions (including advanced signal processing, convolutional neuronal networks and better statistical postprocessing). Furthermore i do have plans to partially automate the song timings as well. However I am currently quite busy, so development is quite slow. Input and help is always appreciated :)
I hope I was able to help you

Thx for the fast reply.

Furthermore i do have plans to partially automate the song timings as well.
That would be really helpfull. I finished my first from scretch created ultrastar song yesterday. And the timing of the lyrics was really a pain in the a... For the pitch detection I tried out your project using a spleeter extracted vocals mp3. And that worked for that song really good, I was really suprised.

I met a user in a french ultrastar discord server who is working on a script for the lyrics timing. As he told me, he is using the lyrics timing which deezer has included for some songs as a beginning point, but I guess he is doing afterwards some more stuff.
I would like to tell him about you, maybe you both could talk and share your ideas :)

Congratulations on your first successful transcription! ;D If you want to make it available for others, you can upload the notes.txt file to http://usdb.animux.de/. Nice to see that my software produces satisfying results ^^.
As for the timing, there exists only a rough concept on my side so far. The main idea is to train a network to differentiate beween lyric and acoustic parts. This way would be a lot easier to set up than trying full fledged syllable matching. However the lyrics have to be manually added afterwards.
Using Deezer probably isn't the ideal solution, because it limits the available song to what is in their database. However it could serve as a starting point. So sure, go ahead and contact him. As stated above, new input is always welcome!


thrift: add temporary mutex implementation

The Thrift library has its own abstraction for mutexes, which normally just a wrapper around std::mutex using the PIMPL idiom (pointer-to-impl).
Since Zephyr does not yet support std::mutex, a workaround was added in Zephyr that was essentially no-op.
We cannot yet use a struct k_mutex due to some additional userspace requirements, but for now we can fake a mutex interface with a spinlock.
We hope to eventually drop this workaround entirely and just support std::mutex.
Fixes #60941
Tested-with:  run-thrift-trials.sh.txt
west build -p auto -b qemu_x86_64 tests/lib/thrift/ThriftTest
ninja: no work to do.

real    0m0.166s
user    0m0.134s
sys     0m0.032s
done
********************************************************************************
Job 0/100                                       [ OK ] Pass Rate: 100 %
********************************************************************************
Job 1/100                                       [ OK ] Pass Rate: 100 %
********************************************************************************
Job 2/100                                       [ OK ] Pass Rate: 100 %
********************************************************************************
Job 3/100                                       [ OK ] Pass Rate: 100 %
********************************************************************************
Job 4/100                                       [ OK ] Pass Rate: 100 %
..
********************************************************************************
Job 93/100                                      [ OK ] Pass Rate: 100 %
********************************************************************************
Job 94/100                                      [ OK ] Pass Rate: 100 %
********************************************************************************
Job 95/100                                      [ OK ] Pass Rate: 100 %
********************************************************************************
Job 96/100                                      [ OK ] Pass Rate: 100 %
********************************************************************************
Job 97/100                                      [ OK ] Pass Rate: 100 %
********************************************************************************
Job 98/100                                      [ OK ] Pass Rate: 100 %
********************************************************************************
Job 99/100                                      [ OK ] Pass Rate: 100 %
RESULT: 100/100

test still failing sporadically, see https://github.com/zephyrproject-rtos/zephyr/actions/runs/5697038294/job/15443170454?pr=60942#step:13:282

test still failing sporadically, see https://github.com/zephyrproject-rtos/zephyr/actions/runs/5697038294/job/15443170454?pr=60942#step:13:282

Yes, that's the tlsTransport, which I've not yet addressed. I'm not even sure if that is a problem with Thrift, to be honest. Separate issue. This PR is to address the binaryProtocol issues that you observed after the initial fix.


Replace link to obsolete repository with link to the new one

The isomorphic-material-relay-starter-kit is no longer supported and is superseded by the universal relay boilerplate. The new version adds react native to the mix.

Hi @thelordoftheboards , thanks a lot for the PR! The content here is automatically crawled and generated. So if awesome-graphql merges your change, it will be reflected here next time I run the script.
At the same time, I'm wondering do you use GitHub search to identify and report to every repository that indexes your repo? Thanks!

Indeed I did, I wanted to remove the old one. I was not aware that the content was automatically generated. Thank you for the explanation.

It is updated already. https://github.com/chaconnewu/awesome-augmented/blob/master/awesomes/awesome-graphql.md


history of news in dashboard

apparently the history of the newsmessages (as in Neerpelt and probably others ) is only till 25/10/2016.
We miss the messages between 25/10 and the release of the new design in the store.

Is this still needed? We dont recommend this anymore since there are already more recent news items published

ok not needed anymore indeed.


[Python] .srv with specific field cause incomplete generation

Specific field 'int8' in a .srv file in a ROS2 custom message package causes incomplete generation of C++ code: ReceiveRequest{srv_name}.cpp and ReceiveRspRequest{srv_name}.cpp
(pub/ sub may have the same)
Suspected causes:

Insufficient support for C++ types corresponding to ROS message types in python code
Dictionary variable initialization issue

fix #1

add case of other field : [int8, int16, uint8, ...] in func ros_field_type_to_default_value(), ros_field_type_to_cpp_type()


Not working for me

I tried the official version, not sure if it is in sync with this repo, but it's not working for me.
After selecting PT and adding successfully the integration, it shows no entities, not allowing me to arm or disarm.
Is this still working?
Not sure if this can be cause by my Prosegur account having two separate installations.

Hi!
I will need some help from you to get this debugged.
Are you able to install the latest version of this integration as a custom_component? I can guide you through the process, reach out for me on Home Assistant Discord (I go by @dgomes)


Deploy Checklist: New Expensify 2023-05-05

Release Version: 1.3.11-5
Compare Changes: https://github.com/Expensify/App/compare/production...staging
This release contains changes from the following pull requests:

[x] https://github.com/Expensify/App/pull/15685
[ ] https://github.com/Expensify/App/pull/15811
[x] https://github.com/Expensify/App/pull/16545
[x] https://github.com/Expensify/App/pull/17583
[x] https://github.com/Expensify/App/pull/17718
[x] https://github.com/Expensify/App/pull/17878
[x] https://github.com/Expensify/App/pull/18019
[x] https://github.com/Expensify/App/pull/18148
[x] https://github.com/Expensify/App/pull/18167
[x] https://github.com/Expensify/App/pull/18247
[x] https://github.com/Expensify/App/pull/18253
[x] https://github.com/Expensify/App/pull/18337
[x] https://github.com/Expensify/App/pull/18354
[x] https://github.com/Expensify/App/pull/18365
[x] https://github.com/Expensify/App/pull/18393
[ ] https://github.com/Expensify/App/pull/18425
[x] https://github.com/Expensify/App/pull/18430
[x] https://github.com/Expensify/App/pull/18439
[x] https://github.com/Expensify/App/pull/18464
[x] https://github.com/Expensify/App/pull/18465
[x] https://github.com/Expensify/App/pull/18470
[x] https://github.com/Expensify/App/pull/18490
[x] https://github.com/Expensify/App/pull/18599
[x] https://github.com/Expensify/App/pull/18611
[ ] https://github.com/Expensify/App/pull/18619

Deploy Blockers:

[x] https://github.com/Expensify/App/issues/18516
[x] https://github.com/Expensify/App/issues/18525
[x] https://github.com/Expensify/App/issues/18527

Deployer verifications:

[ ] I checked the App Timing Dashboard and verified this release does not cause a noticeable performance regression.
[ ] I checked Firebase Crashlytics and verified that this release does not introduce any new crashes. More detailed instructions on this verification can be found here.
[ ] I checked GitHub Status and verified there is no reported incident with Actions.

cc @Expensify/applauseleads

:rocket: All staging deploys are complete, @Expensify/applauseleads please begin QA on version https://github.com/Expensify/App/releases/tag/1.3.11-1 :rocket:

@Beamanator regression is completed
PR https://github.com/Expensify/App/pull/15811 is failing https://github.com/Expensify/App/issues/18526
PR https://github.com/Expensify/App/pull/18253 can you help us out with it?
PR https://github.com/Expensify/App/pull/18365 is failing repro in prod. Checking off
PR https://github.com/Expensify/App/pull/18470 is failing. Getting the issue in a few

:clap: Heads up @Expensify/applauseleads :clap:
A new pull request has been :cherries: cherry-picked :cherries: to staging, and will be deployed to staging in version 1.3.11-3 :rocket:

:clap: Heads up @Expensify/applauseleads :clap:
A new pull request has been :cherries: cherry-picked :cherries: to staging, and will be deployed to staging in version 1.3.11-4 :rocket:

:tada: All set?…You bet! @Expensify/applauseleads https://github.com/Expensify/App/releases/tag/1.3.11-3 has been deployed to staging :tada:

Aldo confirmed that https://github.com/Expensify/App/issues/18516 is resolved, checking it off.

I verified that https://github.com/Expensify/App/issues/18525 is resolved, checking it off.

The issue with https://github.com/Expensify/App/pull/15811 should be resolved in 1.3.11-5 by https://github.com/Expensify/App/pull/18619

:clap: Heads up @Expensify/applauseleads :clap:
A new pull request has been :cherries: cherry-picked :cherries: to staging, and will be deployed to staging in version 1.3.11-5 :rocket:

I wasn't able to manually verify https://github.com/Expensify/App/pull/18253 on staging because I see a balance on my Payments page, but the PR is safe enough and the bug simple enough that I don't think we'll block deploy on that.

Seems like https://github.com/Expensify/App/pull/18465 was just missed, going to verify that one now...

#18465 is pass. @roryabraham  looks like i just missed to check it off.

Verified https://github.com/Expensify/App/pull/18465#issuecomment-1539243215

https://github.com/Expensify/App/pull/18425 has been verified last regression. its pass. it just hasn't deploy to prod yet. OK to check it off or we need to verify again?

Ok, here's the status for everything left unchecked here:

https://github.com/Expensify/App/pull/15811 should be fixed in 1.3.11-5
https://github.com/Expensify/App/pull/18425 needs retest, should have been fixed by https://github.com/Expensify/App/pull/18599 in 1.3.11-3
https://github.com/Expensify/App/pull/18619 cherry-picked in 1.3.11-5

Okay, last thing to do is retest https://github.com/Expensify/App/pull/15811 in 1.3.11-5, which is deploying here.

:tada: All set?…You bet! @Expensify/applauseleads https://github.com/Expensify/App/releases/tag/1.3.11-5 has been deployed to staging :tada:

Verified on staging, let's do this thang.

:shipit:

This issue either has unchecked items or has not yet been marked with the :shipit: emoji of approval.
Reopening!

:shipit:


Great project, code looks sound, but just does not work

Hi!  I'm doing an app that organizes videos and then enables user to view them. Sounds pretty simple enough. I worked all aspects of the app and work, except for the video playing part.   I found your app and studied it and makes total sense.   Tried running it pointing it to LOCAL files and it just wont play the mp4s no matter where or how I copy them, or what flags I turn or not.  I then tried loading a few mp4s to a website so I would have external URLs, and it also does not work.  I tried several things including modifying the plist.info file to Allow arbitrary loads, etc. - but no success.   Now as I said, the code seems logical and very similar to the approach I was planning to follow.  I tried coding similar on my own and failed to do so.   All apps I've done using iOS and Swift have worked so far, but it seems video has it's secrets.   would love to exchange notes on how you made it work!

Hmm it works fine for me. I just had to set the url using Bundle.main i.e.:
.init(title: "First video", url: Bundle.main.url(forResource: "my_local_video", withExtension: "MOV")!.absoluteString)


pkg/email: tolerate newline characters after #syz

It look like email clients can insert newlines there if the line is too long.

@dvyukov PTAL


Add ERC: Upgradeable Clone

Migrate from EIPs repository

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.

@SamWilsn
My apologies for the delayed response. Following your suggestions, we have significantly revised this ERC. Could you please review the updated version?

@SamWilsn
My apologies for the inconvenience, and thank you for your patience and support.
I have updated the reference implementation based on the feedback received and have changed the license to CC0.
Could you please take a moment to review the updated implementation and the license change?


docs: Added [Dataset, Keystore] documentation

Description

TODO

Issues

Closes: #TODO

Testing

TODO

Checklist

[ ] CI passed

can you review the PR

@saymedgm  I am not a reviewer but I think you should edit the PR content and attach the issue #479  like this, so that other people who lookup on issue see that , a PR has already been made. :)

Closing due to inactivity


manifest issues

Is it possible to remove supportsRtl and allowbackup attributes in the manifest file? Gradle sync fails when trying to use this project if my attributes are different.

Yes sure. Why not raise a pull request for this issue with the fixes?


Explore Use of QueryStrings For Specifying Limit / MaxResultCount

Sourced from a discussion in this thread https://github.com/edgexfoundry/edgex-go/issues/1326
Explore the possibility of utilizing a "limit" querystring parameter rather than a routing segment in order to specify the maximum number of results returned by a GET request.
For example, the following core-data endpoint will return events for a given device, capped at the number provided in the {limit} segment
/event/device/{deviceId}/{limit}
We should explore implementing an alternative mechanism like so
/event/device/{deviceId}?limit=100
The old endpoint MUST be maintained for backward compatibility. If this can be done in a backward-compatible manner for 1.x releases, then we can assign this issue and others like it to the Fuji release cycle. This issue will track the one specific use case above. If we decide to adopt the pattern, subsequent issues will be used to track specific API route changes.

Do you think it would be beneficial to support more of a page response? For example, query parameters like page size and page offset. My thought here is that if we have 1 million devices, and the MaxResultCount is something lower, like 1,000. We will never be able to get all the devices as we will always be limited to the MaxResultCount(1,000) regardless of the limit query parameter.
Another thought, should we consider supporting chucked/streaming responses? As these responses get bigger we will be consuming a lot of memory while building the response for the user. If we return 1,000 devices, we could be using a lot of memory where as if we stream we could get the same result as if were only stream say 100 devices.

For answers to those questions, I would rely on input from our UI teams or else from a partner company bringing a real business requirement. I don't want to build that stuff to support a hypothetical case.

Do you think it would be beneficial to support more of a page response?

Yes, this is how I've seen it implemented in other APIs and how I'd recommend it. As I mentioned on the original issue, I think there should be both server side limits, and client side limits. The limit paramater here in the naive implementation would be a client side limit, but it would be much more useful it if paging was implemented.

Do you think it would be beneficial to support more of a page response? For example, query parameters like page size and page offset. My thought here is that if we have 1 million devices, and the MaxResultCount is something lower, like 1,000. We will never be able to get all the devices as we will always be limited to the MaxResultCount(1,000) regardless of the limit query parameter.

@AnthonyMBonafide I'm putting this into the OpenAPI spec I'm building for the Core Services for the Geneva release. All endpoints returning a list of results will have this capability.

Closing. This will be facilitated by the pagination that all multi-result GET endpoints must support in the API 2.0 definition


Select Image or Take Photo and go to new ViewController

Hi,
Is it possible to make minor modifications with code so after selecting photo or taking it it takes me to new view controller for example uploadViewcontroller where is selected image presented ( later it would be good to make another view after taking photo to confirm it or retake)?

I made a pull request to manually dismiss Fusuma
https://github.com/ytakzk/Fusuma/pull/149
With this, you could choose to present Fusuma in a NavController and push your new ViewController onto the stack when you receive the corresponding Fusuma delegate callbacks.

I am also struggling to send selected images or captured image to new controller and I am totally new in swift so please help me to solve my problem.


issue with instalacion

Hi,
Recently  trying to install on a ubuntu 16.04 but im getting this error
`Bundler could not find compatible versions for gem "bundler":
In Gemfile:
rails (= 4.0.3) was resolved to 4.0.3, which depends on
bundler (< 2.0, >= 1.3.0)
  Current Bundler version:
    bundler (2.0.2)
   This Gemfile requires a different version of Bundler.
 Perhaps you need to update Bundler by running `gem install bundler`?

      Could not find gem 'bundler (< 2.0, >= 1.3.0)', which is required by gem 'rails (= 4.0.3)', in any of the sources.

     Bundler could not find compatible versions for gem "coffee-rails":
     In Gemfile:
     coffee-rails (~> 4.0.0)

       turbolinks (= 2.2.1) was resolved to 2.2.1, which depends on
      coffee-rails

      Bundler could not find compatible versions for gem "rails":
     In Gemfile:
       rails (= 4.0.3)

       wicked_pdf (= 0.9.10) was resolved to 0.9.10, which depends on
  rails

         Bundler could not find compatible versions for gem "turbolinks":
         In Gemfile:
        turbolinks (= 2.2.1)

        jquery-turbolinks (= 2.0.2) was resolved to 2.0.2, which depends on
        turbolinks

`

try gem install bundler -v 1.17.3


Eliminate finalizer on BlazeConnection

Finalizers incur a substantial performance penalty.  Effective Java quotes the damage at 430x to garbage collect a simple object.  We're making everyone pay to warn of a mistake we've made rather difficult to make in the first place.

How often does this happen?

I don't think I've seen this warning since we fixed some bugs in the client, but we're paying for it on every blaze connection.

There's another one in blaze itself.  I think these are all the finalizers in our part of the world.


no response from register_scan

I enabled verbose output. For some registers the device seems to answer, but register_scan gives no output. What happens and how should I try to debug?
My device is a "SUN600G3-EU-230" with
Firmware version  MW3_15U_5406_1.471

Scanning input registers
DEBUG:pysolarmanv5.pysolarmanv5:SENT: a5 17 00 10 45 00 00 b9 0d 2f f7 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 04 75 30 00 01 2b c9 f9 15
DEBUG:pysolarmanv5.pysolarmanv5:RECD: a5 10 00 10 15 00 0d b9 0d 2f f7 02 01 d8 e2 01 00 c0 01 00 00 b4 c8 aa 63 05 00 3b 15

The Deye inverters respond only to read_holding_registers (function 0x03). Also the registers in the example here are too high. Try in the range(0, 700). Alternatively you can install the library I've been working on lately  and use the deye-read command.


No verification email received.

Description
I registered my app got back a successful message that includes "check your email for a verification link". I never got an email to verify my app and increase my rate limits.
Reproduction

Register App via the 'https://api.openverse.engineering/v1/auth_tokens/register' endpoint.
Get back successful response, with client_id, client_secret, and msg that says "Check your email for a verification link"
No Email received, waited 10 hours (to make sure), checked my spam folder.

Expectation
Get an email to verify my email.

Thank you for reporting @DantrazTrev this is a know issue and we will deploy our fix tomorrow! Feel free to email<EMAIL_ADDRESS>for specifics regarding verifying your API account's API access.

@zackkrida Is this fixed? I tried to register for a token today using the following request and got a 502 from cloudflare and no email:
curl \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name": "Testing current auth flow", "description": "@sarayourfriend testing", "email"<EMAIL_ADDRESS>\
  "https://api.openverse.engineering/v1/auth_tokens/register"

However, I believe the token is actually created as when I make the request again, I get back this response:
{"name":["o auth2 registration with this name already exists."]}

No email though :cry:

I believe this is still an issue, related to: https://github.com/WordPress/openverse-infrastructure/issues/52

As discussed elsewhere this is still an issue, but with an upcoming fix. Thanks @sarayourfriend and @AetherUnbound for your ongoing efforts to fix this.

@dmathewwws This issue is resolved. Feel free to request another token, you should receive an email as expected now. Otherwise, we're in the process of finding a way to get people access to the tokens they originally requested and you'll hear from us eventually about that.


Added Simply Random as random numbers generating alternative

Very simple library that only uses MCRYPT_DEV_URANDOM, which is 'the right thing to do' instead of all the libs that go and do their own custom mixing of various other libs.
see:
http://timoh6.github.io/2013/11/05/Secure-random-numbers-for-PHP-developers.html
and more:
https://news.ycombinator.com/item?id=6216101
http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939

Thanks for the suggestion.


feat: support context file location in repository (#38)

This PR adds support of the context file's location in repository.

default context file's name was changed to .asyncapi-cli
getContextFilePath() searches for a context file named as specified in CONTEXT_FILENAME:

in current directory,
if it doesn't find, it goes upper, and upper, and repeats, up to the root of the repository,
if it still cannot find the context file, it searches in the user's home directory,
if there is no context file even there, the function stops execution, the context file's name is defaulting to be ${os.homedir()}/.asyncapi-cli and this path is assigned to CONTEXT_FILE_PATH which is then returned on every request.

isContextFileValid() performs boolean validation of context file's format against interface IContextFile
context files that have wrong format (didn't pass validation by isContextFileValid()) are ignored even if they have proper name
catch(error), catch(err) and catch(e) were brought to unified form
messages of existing errors and exceptions were made more meaningful and new ones were added
ContextNotFound was renamed to ContextNotFoundError, to keep error objects' naming in ./src/errors/context-error.ts in the same style
src/errors/context-error.ts was tidied up overall
minor typos in various outputs were fixed
./src/models/Context.ts was formatted with Prettier
testing code was updated and new tests were added

Current @oclif/test's implementation leads to unexpected results in some scenarios, all observations were described in ./test/commands/context.test.ts as comments. Making fixes to @oclif/test is out of scope.
Resolves https://github.com/asyncapi/cli/issues/38

I tried manual testing

Current CLI behaviour
$ asyncapi config context current
ContextError: No context is set as current, please set a current context.

$ asyncapi config context list
myapp: /Users/wookiee/sources/cli/test/fixtures/asyncapi_v1.yml

PR behaviour - when I have no context
$ bin/run config context current
ContextError: These are your options to specify in the CLI what AsyncAPI file should be used:
        - You can provide a path to the AsyncAPI file: asyncapi <command> path/to/file/asyncapi.yml
        - You can provide URL to the AsyncAPI file: asyncapi <command> https://example.com/path/to/file/asyncapi.yml
        - You can also pass a saved context that points to your AsyncAPI file: asyncapi <command> context-name
        - In case you did not specify a context that you want to use, the CLI checks if there is a default context and uses it. To set default context run: asyncapi config context use mycontext
        - In case you did not provide any reference to AsyncAPI file and there is no default context, the CLI detects if in your current working directory you have files like asyncapi.json, asyncapi.yaml, asyncapi.yml. Just rename your file accordingly.

$ bin/run config context list
ContextError: These are your options to specify in the CLI what AsyncAPI file should be used:
        - You can provide a path to the AsyncAPI file: asyncapi <command> path/to/file/asyncapi.yml
        - You can provide URL to the AsyncAPI file: asyncapi <command> https://example.com/path/to/file/asyncapi.yml
        - You can also pass a saved context that points to your AsyncAPI file: asyncapi <command> context-name
        - In case you did not specify a context that you want to use, the CLI checks if there is a default context and uses it. To set default context run: asyncapi config context use mycontext
        - In case you did not provide any reference to AsyncAPI file and there is no default context, the CLI detects if in your current working directory you have files like asyncapi.json, asyncapi.yaml, asyncapi.yml. Just rename your file accordingly.

Expected behaviour - when I have no context
//no error but info
$ bin/run config context current
No context is set as current. Run 'asyncapi config context' to see all the available options.

//no error but info
$ bin/run config context list
You have no context configured. Run 'asyncapi config context' to see all the available options.

./bin$ ls -a
.asyncapi

./bin$ ./run config context current
ContextError: These are your options to specify in the CLI what AsyncAPI file should be used:
	- You can provide a path to the AsyncAPI file: asyncapi <command> path/to/file/asyncapi.yml
	- You can provide URL to the AsyncAPI file: asyncapi <command> https://example.com/path/to/file/asyncapi.yml
	- You can also pass a saved context that points to your AsyncAPI file: asyncapi <command> context-name
	- In case you did not specify a context that you want to use, the CLI checks if there is a default context and uses it. To set default context run: asyncapi config context use mycontext
	- In case you did not provide any reference to AsyncAPI file and there is no default context, the CLI detects if in your current working directory you have files like asyncapi.json, asyncapi.yaml, asyncapi.yml. Just rename your file accordingly.

./bin$ ./run config context list
ContextError: These are your options to specify in the CLI what AsyncAPI file should be used:
	- You can provide a path to the AsyncAPI file: asyncapi <command> path/to/file/asyncapi.yml
	- You can provide URL to the AsyncAPI file: asyncapi <command> https://example.com/path/to/file/asyncapi.yml
	- You can also pass a saved context that points to your AsyncAPI file: asyncapi <command> context-name
	- In case you did not specify a context that you want to use, the CLI checks if there is a default context and uses it. To set default context run: asyncapi config context use mycontext
	- In case you did not provide any reference to AsyncAPI file and there is no default context, the CLI detects if in your current working directory you have files like asyncapi.json, asyncapi.yaml, asyncapi.yml. Just rename your file accordingly.

./bin$ mv .asyncapi .asyncapi-cli
./bin$ ./run config context current
ContextError: No context is set as current, please set a current context.

./bin$ ./run config context list
myapp: /Users/wookiee/sources/cli/test/fixtures/asyncapi_v1.yml

./bin$ ./run config context list # context file was emptied as '{"store":{}}'
Context file "/.../bin/.asyncapi-cli" is empty.

default context file's name was changed to .asyncapi-cli

Please make sure you are testing this PR with context file's name .asyncapi-cli.
Other change requests are being worked on.

yes yes, I know, the errors show up when there is no .asyncapi-cli

nice you're adding docs, but from my side - it was not in scope.

After this moment the doc became intertwined with the code I wrote
https://github.com/asyncapi/cli/pull/567#discussion_r1262136364
and it is likely that changes to code will need to be introduced basing on the doc, so I'll need to steer both of them simultaneously.
It is a yet another Bounty Program usecase.
What should be the process of extending timeline for a Bounty task in case of unpredicted force majeure circumstances, which are beyond control of both contributor and maintainer and appeared in fact out of thin air?
@thulieblack

We extend the deadline to fit the appropriate time to complete the issue. These are some things we are learning through this Bounty Trial, and since it is necessary to add documentation, we have to extend the deadline.

Integration of context.md into website structure can be viewed at
https://8mnlsn-3000.csb.app/docs/tools/cli/context

/rtm


Dev: console error if we open RHN page directly

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Try to open direct link of RHN(for eg, http://localhost:8082/settings)
Observe the console error

Expected Result:
Should not occur console error
Actual Result:
Error Failed prop type: The prop isBlockedFromConciergeis marked as required inAttachmentPickerWithMenuItems, but its value is undefined. occurs
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: DEV
Reproducible in staging?: dev
Reproducible in production?: dev
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/9ff55e9e-0e2f-4662-a396-a6e5487bf0b2
Expensify/Expensify Issue URL:
Issue reported by: @Pujan92
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1692985306887049
View all open jobs on GitHub

Proposal from @Pujan92
Please re-state the problem that we are trying to solve in this issue.
Console error for isBlockedFromConcierge passed undefined but it’s required prop
What is the root cause of that problem?
In PR we added prop isBlockedFromConcierge required in AttachmentPickerWithMenuItems & ComposerWithSuggestions components. But from ReportActionCompose it gets passed undefined when we directly open the RHN screen.
https://github.com/Expensify/App/blob/7217a18a78ec2b01a45267f476fd95ed0cde0fb0/src/pages/home/report/ReportActionCompose/ReportActionCompose.js#L158
Bcoz by the time the report gets loaded it has a default value {reportID: ‘0’}, so condition ReportUtils.chatIncludesConcierge(report) returns undefined, with that undefined && false returns undefined and issue persist.
What changes do you think we should make in order to solve the problem?
We need to update the condition to make sure it will return a boolean value instead of undefined.
https://github.com/Expensify/App/blob/57603a08d0e018c5a428a5839ddb48a0b66115cd/src/libs/ReportUtils.js#L809-L811
!_.isEmpty(report.participantAccountIDs)

OR
We can use double negate or Boolean constructor to make ReportUtils.chatIncludesConcierge a boolean value.
https://github.com/Expensify/App/blob/7217a18a78ec2b01a45267f476fd95ed0cde0fb0/src/pages/home/report/ReportActionCompose/ReportActionCompose.js#L158

Just doing an expedited review as this is annoying. When refresh app every time, hard to see other console errors caused by test branch as this one shows always.
@Pujan92's proposal looks good - !_.isEmpty(report.participantAccountIDs)
@sonialiap as this is dev-only issue, I am going to pull up engineer directly - 🎀 👀 🎀 C+ reviewed

@Pujan92 's proposal looks good, but seems like I can't assign them to the issue, maybe because they didn't post the proposal to this issue by themselves?

Commenting to get assigned.

@nkuoch can you please do actions in this order?

unassign @Pujan92
assign @situchan
add External label
after a few seconds, assign @Pujan92

@Pujan92 please let me know when PR is ready

@Pujan92 please let me know when PR is ready

@situchan PR is ready for review!

Payments - sent ✔
@Pujan92 report + fix + bonus = $50 + $500 + $250 = $800
@situchan review + bonus = $500 + $250 = $750

@situchan please fill out the checklist so that we can close this issue :)

This doesn't require BZ checklist.
Console error check is already in PR checklist and it's just dev error, not affecting production app.

@sonialiap Can you plz check this slack thread https://expensify.slack.com/archives/C01GTK53T8Q/p1694444733848299 and confirm whether this should be eligible for old payment price or not as this issue gets reported on 25th aug before new pay price(31st aug) applied.

@Pujan92 Thanks for bringing this up! I went by the date the gh issue was opened and didn't check the reporting date.
The reporting date was Aug 26 so you are eligible for the old reporting bonus of $250. I have already issued a payment of $50 so you're owed $200. I just sent an offer for $200.

Thanks @sonialiap for reconsidering but I believe contributor price also needs to be updated by considering it($1000+$500 for urgency bonus)

@Pujan92 The GH issue was created and became available after the pricing change so the fix and review are both $500

Oh, ok @sonialiap. I thought all payments needs to be with old price. Thanks for clearing.

I believe all payments have been processed, please reopen if I missed anything in the discussion

I believe all payments have been processed, please reopen if I missed anything in the discussion

@sonialiap payment is pending here, could you plz check.

Bump @sonialiap

Bump @sonialiap for remaining payment

@Pujan92 my apologies! Payment completed!

No issues, Thanks!


Public documentation improvements based on common incidents analysis

A few more details were added to improve the public docs regarding Repositories, including branches comparison, PR conflict resolution, missing and lost changes

@microsoft-github-policy-service agree [company="Microsoft"]

@microsoft-github-policy-service agree company="Microsoft"

@vijayma

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@vijayma - please approve this PR to update the public doc. Thanks.

@vijayma, because of the moniker, these changes need to be moved to the private repo, so they can be viewed on staging. Can you do that? Thanks.

@vijayma, after @vijayma asked me for clarification, I realized it wasn't necessary to move this to the private repo, as no formatting changes were made that would be to be viewed on staging there. So, I am merging it now.

@vijayma, because of the moniker, these changes need to be moved to the private repo, so they can be viewed on staging. Can you do that? Thanks.

@vijayma, after @bjanousek asked for clarification, I realized this PR didn't have to be moved to the private repo because no actual formatting changes were made. So I'm merging it here.


Pass through does not work on v7.0.0-5

Hi,
I'm using Traffic Server version 7.0.0-5 on debian server and want to pass through non-http traffic running on port 80. I have modified records.conf file as below:
CONFIG proxy.config.http.server_ports STRING 8080:tr-full:tr-pass 8080:ipv6
Unfortunately, I cannot connect to https or ssh services running on port 80. As an example, connecting to some https server running on port 80, following error line is generated to squid.blog:
1512298757.585 0 <IP_ADDRESS> ERR_INVALID_REQ/400 0 - / - NONE/- text/html

If this is still an issue please reopen.


when will u update to the v3?

hello! can u please update to the v3 models?

We are already working on craiyon.py 0.4.0, which will support the v3 model.
It should be released hopefully sometime soon.

Thanks. We are waiting 🐱

Hello, @nirmind24 @GenifeUA !
We just released the v1.0.0 that supports the new v3 model on PyPI and github as well.

Hello, @nirmind24 @GenifeUA ! We just released the v1.0.0 that supports the new v3 model on PyPI and github as well.

thanks


Dialog component's scroll prop doesn't support body value

Describe the bug
In the MUI Dialog component, the scroll prop can take either "paper" or "body". In the SDS Dialog component, scrolling will scroll the DialogPaper first, but once it reaches the end, it will scroll the body too, so it seems to not be working properly. In SDS's version,  setting scroll to body doesn't have any affect.
To Reproduce
Steps to reproduce the behavior (or see GIF below):

Go to the Dialog component's index.stories.tsx file, just as a place to temporarily test this functionality
Add scroll="body" to the <RawDialog>s props at the end (~line 60)
Run yarn start to open Storybook; shorten yor browser window to as short as it will go
In the control panel, set longContent to true
Scroll the dialog and watch the scroll bars first move within the dialog itself, and then once you reach the end, see the scroll bar in the body of the window scroll a bit as the bottom edge of the dialog moves upward

Expected behavior
scroll="paper" and scroll="body"'s functionalities should not co-exist, but should each behave as shown and described in the MUI documentation when set
Screenshots

How to Fix
To address this issue, the recommendation is to remove the width CSS attribute from the DialogPaper component.
Additionally, it's essential to verify the response Dialog sizes in collaboration with the @chanzuckerberg/sds-design team for confirmation.


[Bug]user login failed and receive authenticate failure error message

Already searched before asking?

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

Scaleph Version or Branch
master
What happened

Error Exception
errorCode: "401"
errorMessage: "用户认证不通过！"
showType: 4
success: false

Screenshots
No response
Are you willing to submit PR?

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

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@jczk please describe  the problem in detail

1、cd scaleph-ui
npm install --location=global @angular/cli
npm install --force
2、cd scaleph
mvn clean package -DskipTests
3、nginx setting
4、java -jar scaleph-api.jar
5、http://IP/login
sys_admin/123456

wechat  gleiyu
email<EMAIL_ADDRESS>

nginx 配置也是参考如下配置的：https://github.com/flowerfine/scaleph/blob/dev/docs/build/build.md#nginx-setting详情见附件
----- 原始邮件 -----
发件人：gleiyu @.>
收件人：flowerfine/scaleph @.>
抄送人：jczk @.>,  Mention @.>
主题：Re: [flowerfine/scaleph] [Bug]user login failed and receive authenticate failure error message (Issue #147)
日期：2022年07月22日 10点01分
@jczk please describe  the problem in detail
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>


Provide binaries as part of releases

What version of gRPC and what language are you using?
v1.19.0
All supported languages
What operating system (Linux, Windows,...) and version?
All
What runtime / compiler are you using (e.g. python version or version of gcc)
N/A
What did you expect to see?
I would love if there were binaries included with each release for grpc_.*_plugin similar to how protoc is released at https://github.com/protocolbuffers/protobuf/releases. The build takes a long time, and this would help a lot of people. I searched existing GitHub issues for this request because I assumed this has been filed before, but I was surprised that I couldn't find an equivalent issue (maybe I've missed something).
I'm sure this has been considered and brought up before in some manner, but I want to say I do think this would be highly valuable, and it would be great if we could do this for future releases.

These are the grpc-tools packages provided for each language.
https://pypi.org/project/grpcio-tools/
https://rubygems.org/gems/grpc-tools/
https://www.npmjs.com/package/grpc-tools

That's just for Python, Ruby, and Node, and uses language-specific install mechanisms. There's a bunch more from this repo as well:
grpc_cpp_plugin
grpc_csharp_plugin
grpc_node_plugin
grpc_objective_c_plugin
grpc_php_plugin
grpc_python_plugin
grpc_ruby_plugin

A definite +1 from me. For the life of me I can't get the grpc_php_plugin to build and it's not realistic to expect users to debug the mammoth makefile when encountering environment-specific errors.

Definitely would make it easier to get started working with polyglot gRPC environments if you could get all the generators + protoc from the release page.

I was giving you a few examples. All of them except for the C++ one should be available in their individual package corresponding to each language.

The above doesn't cover:

objective_c (which is special-cased and already being released partially with GitHub Releases)
php
csharp
cpp

The above also requires usage of individual installation methods. Our goal here is to have this available, similar to protoc, from GitHub Releases. Is there a reason not to do this?
Some examples of what people are doing now to get around this:

https://github.com/znly/docker-protobuf/blob/master/Dockerfile#L26 is building from source, which takes a long time
https://github.com/uber/prototool/blob/dev/Dockerfile#L95 is relying on Alpine's edge testing repository to get around the build time, but this is not released on the same schedule as gRPC

The reason is it's difficult to set up build pipelines. Doing a grpc release involves a lot of moving pieces due to the amount of languages and platforms. Adding a new vector of things to do isn't something that I am keen of burdening our team with, especially if this is a duplicate of what already exists in another form.
I am fairly certain there is a c# nugget package for grpc-tools, as well as a pecl one for php. If we are distributing a precompiled binary package for grpc in a language, there should be a corresponding grpc-tools package next to it, and this is usually documented in the corresponding quickstart document.
For example, in c#: https://grpc.io/docs/quickstart/csharp.html

The example in this walkthrough already adds the necessary dependencies for you (Grpc, Grpc.Tools and Google.Protobuf NuGet packages).

I can understand not wanting to burden the team, for sure. I might be missing something, but this doesn't seem like a huge task though.
You're already distributing one binary with GitHub Releases, the objective_c binary for Darwin https://github.com/grpc/grpc/releases/tag/v1.19.0 so this means there is already a pipeline to add binaries to GitHub Releases in some form. This just needs to be expanded to include the rest, and at least across Darwin and Linux. Since you're already compiling these for those language packages, that means the build process for released binaries is there as well for some of the other languages.
This would be hugely helpful, as at least speaking for myself, I've been hacking around the fact that there are no pre-compiled binaries for years, and I'm sure others have been too (see above). It's a one-time cost, and since there's already a pipeline to do so for one binary, it shouldn't be that difficult to do the rest.
Even if there is C#, that still leaves php and cpp not compiled.

As I said, there should be one for php. C++ is the only exception because working with grpc in C++ requires compiling from source anyway. If there are missing packages beside C++, this should be the bug to report.
Yes, there is existing pipeline for each package system, each in their own individual paradigm. Some may use docker. Some will require a certain version of the building tools incompatible with other languages. So the build is completely fragmented and siloed per language, which keeps it to a certain level of simplicity.
Doing a final cross platform and polyglot gathering-and-publishing system however is not easy.
At the end of the day, you only want a single point of download instead of having to do pip install ..., gem install ... npm install ... for each language.

This means I have to install pip, gem, npm, and any other language tools just to get the binaries for gRPC. This is way more complicated than the typical curl that I can do for other binaries, including protoc.
Lots of people are generating stubs in locations other than where the stubs are actually being used. This is a pretty common use case, including for integration testing. I think there's pretty bountiful evidence that a lot of people want this https://github.com/search?l=Makefile&q=grpc%2Fgrpc+make+plugins&type=Code and this would be very useful. People don't want to have to install other language tools to just get the gRPC binary, that's just as complicated as building from source, if not moreso.

So you're saying you DO understand the complexity of the task you're asking us to accomplish.

I mentioned I can understand not wanting to burden a team with unnecessary and difficult work, I am not sure this is unnecessary and I guess I don't understand the complexity here.
If this won't be fixed, we can close this issue, it was just a suggestion. I do think many in the community want this, however, and it's not the best that we have to work around this not being done.

The request is still a valid one, despite its difficulty, which is why I didn't close it with a "won't fix".

Binaries are built on master and put on https://packages.grpc.io every day, but not for specific builds. That should be good enough for many use-cases.

People want the binary that matches the version of the library they are using. Master does not cover this.
That link also just provides the packages described above that we have explained why they are not adequate.
What we want is binaries for every release on GitHub Releases.
If this issue won’t be addressed, let’s close this.

@peter-edge Fair point about master, but that can be addressed by adding releases to the pipeline. Should not be that much work.
I think you are mistaken about the latter point though: there are also a protoc+plugins zip/tar file that specifically contain the plugins (click on a Build ID and look at the first section). For example:
https://packages.grpc.io/archive/2019/03/b52bac7888731e14a470fb19fd6e6cab4069c8d2-1ea8591d-4139-4fb1-bbdc-81efd0695e56/protoc/grpc-protoc_linux_x64-1.20.0-dev.tar.gz

Ah yes I am - sorry about that. I’m on my phone, do those tarballs contain
all the grpc_.*_plugin binaries produced by make plugins? If so, then yep,
adding releases to the pipeline solves the problem! It would be a big help.
On Fri, Mar 8, 2019 at 3:46 AM Mehrdad Afshari<EMAIL_ADDRESS>wrote:

@peter-edge https://github.com/peter-edge Fair point about master, but
that can be addressed by adding releases to the pipeline. Should not be
that much work.
I think you are mistaken about the latter point though: there are also a
protoc+plugins zip/tar file that specifically contain the plugins (click
on a Build ID and look at the first section). For example:
https://packages.grpc.io/archive/2019/03/b52bac7888731e14a470fb19fd6e6cab4069c8d2-1ea8591d-4139-4fb1-bbdc-81efd0695e56/protoc/grpc-protoc_linux_x64-1.20.0-dev.tar.gz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/issues/18260#issuecomment-470851637, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AECGvKiiM0EYVZ_ZFQNN8qvTo6YoIg_Eks5vUiNvgaJpZM4bfmAw
.

@peter-edge Yes they contain protoc from the protobuf submodule in the repo at the commit point, plus all seven plugins that you can build with make for macOS, Linux, and Windows. The code underlying these rarely change so for quick testing where you don't have the tools this should be enough but I agree that the release pipeline should be changed to put releases on packages.grpc.io and then download from there and ship to the respective package managers.

As described above, there are many use cases, one of which would be docker image building. I would never use master for plugin binaries and a stable release point for the library.

@peter-edge I created https://github.com/grpc/grpc/issues/18307 to serve as a direct action item that would resolve this issue as well. @nicolasnoble I think we can close this issue in favor of that one. (cc: @jtattermusch fyi)

Sgtm!

Closing this in favor of  #18307.


[SMALLFIX]Supply the variable name to Preconditions.checkNotNull for class GreedyAllocator

[SMALLFIX]Supply the variable name to Preconditions.checkNotNull for class GreedyAllocator

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17326/
Test PASSed.


Properly skip null files (no preview) and notify user

A user ran into this issue earlier, rather than cleanly skipping null files it would error out, if a file is null it should not return none and instead have logic to skip it when downloading.

Fixed in 0.0.7, users are now notified if a tracklist is incomplete and asked whither to proceed or not anyway.


Headers (wrongly) removed

In this page https://creator.poe.com/docs/quick-start
all the (bold and big) headers are wrongly removed by Jina.
Example (html on the left, jina markdown (rendered) on the right)

At the html level they look like this:

We are using the @mozilla/readability for content transformation instead of anything visual-related.
It seems that the text in the div block was ignored because it lacks an explicit semantic meaning despite its visual significance.
I believe it will be captured as headings if put in h1-h6 tags.

from the screenshot it looks like it is in h2.

the Reading mode of Edge have it correctly:

i'm encountering this as well, where headings are removed.  Perhaps when they are not in article tag.