Translation support for pagination

Hi there,
in pagination directive it's already possible to customize values for "next", "prev", and so on. but unfortunately there is no observer on this so dynamic translation will fail in most cases.
Especially in my case because translation will be loaded asynchronously, so the value maybe changes after directive initialisation.
Adding $observers to this directive fixes the problem (somewhere in line 1846):
        attrs.$observe("firstText", function (newValue) {
            if (angular.isDefined(newValue)){
                firstText = newValue;
            }
        });
        attrs.$observe("previousText", function (newValue) {
            if (angular.isDefined(newValue)){
                previousText = newValue;
            }
        });
        attrs.$observe("nextText", function (newValue) {
            if (angular.isDefined(newValue)){
                nextText = newValue;
            }
        });
        attrs.$observe("lastText", function (newValue) {
            if (angular.isDefined(newValue)){
                lastText = newValue;
            }
        });

Thanks for reading,
If you like this solution please add it to your project

Hi
I was working on a proof of concept application and encounter the same issue, when changing language the pagination text button weren't translated, the work around I found was to change a little bit the pagination.htnl template as follow: removed the :: so that the getText is called when any change occurs
{{::getText('first')}} ---> {{getText('first')}}
Is it a workable solution ?
Thanks

var $translate = $filter('translate');
$rootScope.$on('$translateChangeSuccess' , function(){
paginationConfig.firstText = $translate('First');
paginationConfig.lastText = $translate('Last');
paginationConfig.previousText = $translate('Previous');
paginationConfig.nextText = $translate('Next');
});

If someone read this ..
If you want a translation at runtime. Go in the ui-bootstrap-tpls.js
To Line 7539
there are this "{{::getText('first')}}" you need to update it to this --> {{getText('first')}}
activate two-way-databinding if you remove the '::'
updated Version
angular.module("uib/template/pagination/pagination.html", []).run(["$templateCache", function ($templateCache) {
$templateCache.put("uib/template/pagination/pagination.html",
"
{{getText('first')}}\n" +
"
{{getText('previous')}}\n" +
"
{{page.text}}\n" +
"
{{getText('next')}}\n" +
"
{{getText('last')}}\n" +
"");
}]);


Deserialization creates duplicate instances

Search before asking

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

Version
Fury: 0.9.0 / OS: Windows 11 / JDK 21
Component(s)
Java
Minimal reproduce step
Deserialization of two range maps in a container create two different instances of the same object. This leads to increased memory consumption. It is expected that two references to the same object instance will be recreated in the same way they were before serialization (single instance not two).
Attached is a simple Maven project that shows the deserialization problem.
apache-fury-bug.zip
What did you expect to see?
ORIGINAL:
map1: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [2061774051]]
map2: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [2061774051]]
COPY:
map1: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [1990385139]]
map2: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [1990385139]] // Expected same instance!
What did you see instead?
ORIGINAL:
map1: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [2061774051]]
map2: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [2061774051]]
COPY:
map1: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [1990385139]]
map2: [2024-01-01..2024-12-31]=[c0ee7b8d-eab0-4b7e-aeee-6ef2b9d2db8b [1380924218]] // DIFFERENT INSTANCE!
Anything Else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

You should create Fury with reference tracking enabled by FuryBuilder#withRefTracking

OK. Seems somewhat unexpected that this is not the default.

Protobuf/JSON/Flatbuffers doesn't support reference, so Fury disabled it by default


Looking for feature requests -Building a design to code tool

Hi @lukasoppermann
I have been working on an experimental project that generates readable code to be used by developers. It works cross framework and have a look here for more.
It is called ui-editor
https://github.com/imvetri/ui-editor
The concept scales to work as a design tool. However I'm looking for feature request which I can build. Would you be interested to collaborate on it?

Sorry I don't get how this is related to this plugin for Figma.

@lukasoppermann this is not related to figma, this is an open source competitor for figma. I have built the core for a designing tool that can generate readable debuggable code in reactJS, angular, svelte.

What I am say is that this repo is for a Figma plugin.

okay got it. I thought you would be interested that's why dropped a note.


React to sleep log

Is your feature request related to a problem? Please describe.
We want to be able to encourage people in the early-to-sleep channel to keep up with the habit!
Describe the solution you'd like
When a post in the early-to-sleep channel includes the words "sleep log", Horace should react with the bed (🛏) emoji.
Additional context
Make sure that this only works in the early-to-sleep club.

It has been noted by kugoi and wordvalkyrie that the sleep reaction is not occurring for all instances of "Sleep Log". It's possible this is due to some sort of formatting issue. I know wordvalkyrie had theirs underlined. We may just need to add some extra checks here for what triggers the reaction.

https://github.com/Knights-Of-Academia/horace/issues/80
Bug report here


last layer

Hi,
I am trying to find what you guys used for the last layer function? is it softmax or any specific function. I tried to go through the codes but I couldnt find how did you implement the last layer ?
can you please help me with that and also tell me where I can find the detailed code implementation please?
Thanks in advance

The typical case is a multi-task binary classification problem. So the default final layer applies a sigmoid transformation to offer a vector of 0-1 values that can roughly be interpreted as the probability of accessibility/binding/activity/whatever in each of the experiments given.
However, there are some other options coded up in there, for example for regression. You can see them here: https://github.com/davek44/Basset/blob/master/src/convnet.lua#L55-L72


Added return-to-snap-zone script

This pull request adds an XRToolsReturnToSnapZone script which returns an XRToolsPickable object to a snap-zone if dropped for longer than a specified duration. Additionally this pull request implements feature #400.

lgtm, no errors now with gdlint when returning to snapzone


TLS support for Octavia ingress controller

Is this a BUG REPORT or FEATURE REQUEST?:
Feature Request

Uncomment only one, leave it on its own line:
/kind bug
/kind feature

What happened:
OpenStack Octavia ingress controller should support TLS now as there is Barbican support in gopher cloud/openstack cloud provider.
What you expected to happen:
Annotations for TLS support need to be implemented.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

openstack-cloud-controller-manager version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/reopen


[4169] - Add missing line break in our rejection emails

Context
We have an instance where our rejection email doesn't render correctly - there is a line break missing between the reasons for rejection introduction and the reasons for rejection
Changes proposed in this pull request

Extract the 'reasons for rejection introduction' to a separate partial.

Before
After

Guidance to review

It seems like this has something to do with erb.text partials not respecting line breaks for some reason. I'm not entirely sure why the propose changes fix it.

Make sense?
Link to Trello card
https://trello.com/c/5ipsqVEp/4169-apply-missing-line-break-in-our-rejection-emails
Things to check

[ ] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] API release notes have been updated if necessary
[ ] Required environment variables have been updated added to the Azure KeyVault

Weird. Is it the moving into a separate partial which fixed this, or the line breaks within the unless condition?

It seems like this has something to do with erb.text partials not respecting line breaks for some reason.

Moving it into separate partials seems to fix this. For some reason line breaks within erb.text partials are not being respected.


make all DOM XSS tests exploitable - issue #6

Changes:

made all the DOM XSS tests listed on the front page exploitable
removed /xss/dom/escurl? since it duplicates exactly the current version of /xss/dom/domwrite (both do document.write on the URL unencoded with decodeURIComponent
verified that /xss/dom/yuinode_hash? fires XSS in Firefox (not in Webkit browsers)
added /xss/dom/yuinode_has_unencoded with decodeURIComponent(document.location.hash) before passing to YUI's setHTML, verified that it make XSS to fire in Firefox, Chrome, Safari, and Opera.
rearrange sections and fixed formatting bugs on the index page

You should be able to try it from the branch like this:
# optional backup:
mv $GOPATH/src/github.com/yahoo/webseclab $GOPATH/src/github.com/yahoo/webseclab.prev

go get -d github.com/yahoo/webseclab
cd  $GOPATH/src/github.com/yahoo/webseclab
git checkout issue6
go install -v ./... && go test -v && webseclab

Let me know if it looks good to you.  Later we will add other and more interesting and sophisticated DOMXSS tests (let me know if you have suggestions or ideas)! :smile:

CLA is valid!


Libcork build generates compiler warning (unused function)

While building libcork (make), the compiler generates a warning of an unused function. The basic conditions are: (1) Mac OS X w/ Xcode 4.3; (2) having removed libcork via epkg -r libcork; (3) stock cloned code from Github. This warning was generated in the version of libcork prior to thread-local storage (the warning was moved to another file but it was associated with the same cork_error_destroy/cork_error__tls_destroy function.
Scanning dependencies of target embedded_libcork
[  3%] Building C object src/CMakeFiles/embedded_libcork.dir/libcork/core/allocator.c.o
[  5%] Building C object src/CMakeFiles/embedded_libcork.dir/libcork/core/error.c.o
cc1: warnings being treated as errors
/Users/jzachary/redjack/libcork/src/libcork/core/error.c:46: warning: ‘cork_error__tls_destroy’ defined but not used
make[2]: *** [src/CMakeFiles/embedded_libcork.dir/libcork/core/error.c.o] Error 1
make[1]: *** [src/CMakeFiles/embedded_libcork.dir/all] Error 2
make: *** [all] Error 2

Asking the compiler to ignore this warning will result in a build but 18 out of 22 tests will fail with make test.

A-ha....I think I finally figured out what's happening here.  We end up using the cork_error__tls_destroy function inside of an assert call.  So if you're compiling the Release build type, in which assertions are left out, we never make the `pthread_key_create

This fixes the build problem. All tests pass.

This fixes the build problem. All tests pass.


Self-handling exceptions should not have priority in Exception handler

Exception handler should be a central place to define custom handlers for exceptions thrown in application.
Yet, turns out that exceptions with handle() method have higher priority than custom handlers:
https://github.com/adonisjs/adonis-framework/blob/d6a9d893e5ddc1e89c5df105175a39df80db463d/src/Exception/index.js#L70-L86
To handle such exception it's required to add a custom hook.
IMO handle() method of exception should have lower priority then custom handlers bound in main handler.

So there are 3 levels.

Global exception handler. ie app/Exceptions/Handler.js
The exception handle method
Custom exception hook Exception.handle('NAME',callback)

All above are ordered top to bottom in their priority. How do u expect them to work?

You're right.
I had to go back to a previous project to remind myself what exact problem I had.
Before Adonis I was using Laravel as my primary framework. Laravel has a "central" exception handler which is used as a catch-all for application errors. It can be used to format errors in a way that is required by the app.
I thought that this is the role of App/Exceptions/Handler. Yet it turns out that self-handling errors are not processed by App/Exceptions/Handler::handle().
 It can be even possible that right now I'm talking nonsense.
Due to this - I'll close the issue. In the upcoming days, I'll have the chance to validate this issue on my own. If it really exists I'll re-open this issue with more details.
Apologies for taking your time on this.

@thetutlage I'm back - hopefully with more valid details
Case scenario: auth attempt
Controller:
class AuthController {
  login ({ request, auth }) {
    const { email, password } = request.all()
    return auth.attempt(email, password)
  }
}

Global exception handler: (just handle method)
  async handle (error, { request, response }) {
    response.status(error.status).send('FAIL :(')
  }

Sending incorrect credentials...
Response:
[
    {
        "field": "email",
        "message": "Cannot find user with provided email"
    }
]

Expected response:
'FAIL :('

You mentioned that global exception handler is first in the priority list.
In this case, priority took Exceptions.UserNotFoundException::handle() (from @adonisjs/auth).
The only way to add a custom response to such event is to add handler via Exception.handle().
I think that this behavior is incorrect. If an application has defined global exception handler it should be the only one responsible for handling exceptions.

You took it the other way, I listed the point from top of bottom and bottom one overrides the top one.

You took it the other way, I listed the point from top of bottom and bottom one overrides the top one.

Ah, now it makes sense. Thanks.
IMO if the general exception handler is defined it should take care of all exceptions. What do you think about it?

Nope, it's there you to catch what's left behind.

This approach makes handling error responses more complicated.
Let's say that application has a custom error message format.
Now, to format those errors it's required to create global exception handler (for the "leftovers") and custom handler for each self-handling exception.
As said before - I've started new Adonis project. Till now (after just a few days) I had to declare 4 error handlers. One global handler, and three smaller for self-handling exceptions. All of them are casting exceptions to the same format. Every time, when a new exception is thrown I have to make sure that it's handled correctly.
TBH this doesn't bring me developer joy.

It depends on how to structure things, but first what do u think should happen in this case?

The routeValidator throws a ValidationException.
You have created a file called app/Exceptions/Handler.js with following content

class ExceptionHandler {
  async handle () {
  }
}

Now what should Adonis do?

Now what should Adonis do?

Do as is stated in the method - exactly nothing.
ExceptionHandler is an optional thing - one who creates it should be aware that all exceptions will be handled by this method. If it will be left empty - nothing will be returned.
I guess that make:ehandler should put some default behavior to this method.

So let's say I put some code inside this method, what should happen now?

Trying to find if I get your issue or not

class ExceptionHandler {
  async handle (error, { response }) {
    if (error.name === 'ValidationException) {
       response.send(error.message)
    }
  }
}

So let's say I put some code inside this method, what should happen now?

In this case, only ValidationException would be handled. Every other exception would be discarded (empty response would be returned)

Trying to find if I get your issue or not

Sorry for repeating myself yet, I'll try to explain myself once more.
Short version
Once defined, ExceptionHandler::handle() should be responsible for handling all exceptions cought by application
Long version
In general, I think that self-handling exceptions are bad design.

they brake SRP - exception should act as a "transport" of error details; here they're also responsible for preparing error response
each self-handling exception requires a separate handler to format it in a way one wants to.

ExceptionHandler should be the main spot in the application which takes care of how exception should be returned to the end-client.
It could even make use of handle() method of an exception.
The way I see such handler would be something like this:
class BaseHandler {
    async handle(error, { response }) {
        if ('handle' in error) {
            error.handle(response)
        } else {
            response.status(500).send(error.message)
        }
    }
}

class ExceptionHandler extends BaseHandler {
    async handle(error, ctx) {
        // here's a place for user to handle error
        if (error.name === 'ValidationException') {
            ctx.response.status(500).send('Be crazy!')
        } else {
            super.handle(error, ctx)
        }
    }
}

Does it make sense? :)

Okay so you are actually doing it the wrong way, lemme explain why.

First I want exceptions to have the power of handling themselves, this is how they can build clean abstractions, so in short Exception.handle is not going away.

You are using the Global exception handler as the source of truth for handling all exceptions, which is wrong.

If I am at your place and want to manually handle the ValidationException, I will simply bind to it.

The global handler is to build the flow, by writing 20 if/else inside it, and that is why Exception.bind exists.
Exception.bind('ValidationException', 'ExceptionHandler.validationException')
Exception.bind('SomeOtherException', 'ExceptionHandler.someOtherException')

and then inside app/Exceptions/ExceptionHandler.js file, I will way
module.exports = {
   validationException () {
   },

   someOtherException () {
   }
}

First I want exceptions to have the power of handling themselves, this is how they can build clean abstractions, so in short Exception.handle is not going away.

That's why I suggested that ExceptionHandler could delegate response to exceptions handle() method if it's defined.

You are using the Global exception handler as the source of truth for handling all exceptions, which is wrong.

Not source of truth, but error response builder. Unified for the application.

If I am at your place and want to manually handle the ValidationException, I will simply bind to it.

And that's the problem. If I'm using a custom error response format I need to bind a handler for each exception. That's quite cumbersome.

The global handler is not their to build the flow, by writing 20 if/else inside it, and that is why Exception.bind exists.

Again, as an example, I'll use application that I'm writing right now. I've defined my error response format. ExceptionHandler simply casts exceptions to that format. It's quite simple, so I don't have to write any flow logic inside it.
The same ExceptionHandler could handle PasswordMisMatchException, UserNotFoundException, ValidationException without any modifications but it's not possible.
Instead, I have to add to hooks custom handlers for those exceptions which basically do the same.
Now, if there will be any new exceptions that I need to handle I'll have to remember about adding them in hooks.
This could be done entirely by ExceptionHandler.

Handler for both of them looks like this:
module.exports = async (error, { response }) =>
  response.status(error.status)
    .send({
      error: error.name,
      details: error.messages
    })

I can introduce an option, which forward all the exceptions to the GlobalHandler

If possible I could help you with that.
I would suggest something like this:

by default all exceptions go through BaseExceptionHandler::handle()

if exception has handle() method it simply passes response to that method so that exception can handle itself - basically nothing changes here
otherwise - return some generic error response

make:ehandler creates ExceptionHandler which extends BaseExceptionHandler; handle() method calls simply super.handle() method. A developer can decide what they want to do with it.
depending on state Adonis will use either ExceptionHandler or BaseExceptionHandler
to avoid confusion I'd remove Exception.handle()

Does it make sense?

@radmen It totally makes sense. Reading the docs, I also understood it:
Once you create this file, AdonisJs hands over all the exceptions occurred during HTTP lifecycle to it. It should have the handle method with an optional report method on it.
It would also makes sense what you suggest above that it simply passes response.
@thetutlage What can you say about this? this is totally valid.

I already said it, the flow is simple and doesn't need more complications.

First priority to Exception.handle('ExceptionName'), you have the power to decide the flow.
2nd priority to handle method on the exception. So that the developer of that module/exception can have a default exception handling logic.
Both are missing, then fallback to a generic handler that is app/Exceptions/Handler.js file.

Again, you are thinking app/Exceptions/Handler is the way to go for designing the flow, but all I am saying is, this is the fallback.

Again, what I suggest:

let app/Exception/Handler do all the job
by default it passes handling to handle method of exception
developer may alter this behavior and change the whole flow in one place
remove Exception.handle()

I don't think it is feasible to have one flow for all the exceptions. I will never handle all the following exceptions in the same way

PasswordMisMatch
ValidationException
UserNotFound

So it completely makes sense to keep the flow flexible and where you want same flow for all the exceptions, you can go one step further and simply override them.
const exceptionsToOverride = [
 'UserNotFoundException',
 'PasswordMisMatchException',
 'ValidationException',
]

exceptionsToOverride.forEach((name) => {
  Exception.handle(name, 'App/Exceptions/Handler.handle')
})

Now everything is in one place as you want.
Also this is only required when the particular validation has a .handle method and there are very few of them.

So when a new library comes out we keep adding it to the exceptionsToOverride? what we are trying to emphasize is simply make the Handler.js above suggestion is not even on docs.
Example:  ValidationException
[{ field: "email", message: "..." }]

we wish to have a format on any error it returns, like:
{ success: false, errors: [{ field: "email", message: "..." }] }

What do you think? smaller in code, more generic.

Now everything is in one place as you want.

No, it's not. Those bindings have to be put in start/hooks.js file.

I will never handle all the following exceptions in the same way

And you don't have to. As I said - Exception/Handler can simply make use of exceptions handle() method.
The thing is that once everything will go through one handler it will be easier for developers to customize it for what they need (they won't be required to define custom hooks etc).
Exceptions handler is already a global place for reporting stuff (via report() method). The same thing should apply to handle().

start/hooks.js
const exceptionsToOverride = [
 'UserNotFoundException',
 'PasswordMisMatchException',
 'ValidationException',
]

exceptionsToOverride.forEach((name) => {
  Exception.handle(name, 'App/Exceptions/Generic.handle')
})

does not work either.
class GenericException {
   async handle(error, { response }) {
     response.status(error.status).send('Oops!')
   }
}

Not the expected result. Shows:
[
    {
        "field": "password",
        "message": "Invalid user password"
    }
]

What’s the file name for GenericException?

@thetutlage GenericException

@thetutlage I debug the app, Its not really working, its not registering the handler.. Exception use('Exception') looses _handlers somehow what is there is just @provider:...Exception which is binding to *. And _handlers, _reporters are empty.

Works fine for me, and hard to know, where you are writing this code and even it is getting executed or not.
start/hooks.js
const { hooks } = require('@adonisjs/ignitor')

hooks.after.providersBooted(() => {
  const Exception = use('Exception')
  Exception.handle('PasswordMisMatchException', (error, { response }) => {
    response.send('Bad password')
  })
})

and inside route. I am using wrong password intentionally.
Route.get('/', async ({ auth }) => {
  await<EMAIL_ADDRESS>'thisiswrongpassword')
})

@thetutlage Bummer, yup I got it working too by following the hooks sample for hooks.after.providersBooted() please do always assume that all users are noob on the framework :) Thanks, got it working as well. 👍

Yes, I always assume that, but half baked issues are kind of harder for me to make assumptions and form answers on top it. 😄

After reading the hole discussion, I thought as Radmen. I explain:
I am trying Adonis to create a REST API, so I need my handler to response JSON instead of HTML, so as I am used to do in Laravel, I write all my logic in the App/Exception/Handler.js file, just like
this gists
It works, but after reading this issue I think I am not using the handler the way it is supposed to be used.
But I also has some doubts:

I need to handle all the exceptions, to return them as JSON, where is the best place to do it?
I also understand that, for specific exceptions the Start/Hooks.js file is the best place, but this file is not created by default, there is no command to create it and also it does not appears on the documentation, so, without reading this document how could i know i have to manually create this file?

Sorry if there are obvious doubts but I am starting with Adonis and I am trying to do it the right way

@AyozeVera the whole point of this discussion is that I suggest that exception handler should unify handling of all exceptions (like in Laravel) :)

I need to handle all the exceptions, to return them as JSON, where is the best place to do it?

If you're defining own exceptions generic exception handler will be enough. Just create new one (using adonis make:ehandler) and define response format in handle() method.
For Adonis bultin exceptions (specially the ones which are self-handling) you need to define custom handlers.
Here's the excerpt of start/hooks.js file from one of mine projects. Basically, you can copy&paste it to your project :)
const { hooks } = require('@adonisjs/ignitor')
const requestMacro = require('../app/Validators/Macro/request')

hooks.after.providersBooted(() => {
  const Exception = use('Exception')

  const genericExceptionsHandler = use('App/Exceptions/Handler/genericExceptionsHandler')

  Exception.handle('PasswordMisMatchException', genericExceptionsHandler)
  Exception.handle('UserNotFoundException', genericExceptionsHandler)
  Exception.handle('ValidationException', genericExceptionsHandler)
})

To be complete, here're contents of App/Exceptions/Handler/genericExceptionsHandler
module.exports = async (error, { response }) =>
  response.status(error.status)
    .send({
      error: error.name,
      details: error.messages
    })

@AyozeVera If you set Accept: application/json header when making the API request, all internal exception handlers will return valid JSON automatically.
Recently someone shared this snippet, https://gist.github.com/AyozeVera/af89c828270b304d532a1f23c98dde17#file-handler-js-L24
I am not sure how you can enjoy writing 20 switch/case clauses to handle exceptions, vs handling them nicely in their own files

I am not sure how you can enjoy writing 20 switch/case clauses to handle exceptions, vs handling them nicely in their own files

I can say the same for adding separate handlers for each self-handling exception which requires different response format.
I understand that it's convenient if you don't bother about response format. In this case self-handling exceptions are fine.
The way how one wants to model exception handler is their own business. If they want to use 20 switch/case (or if/else) statements it should be possible.
Problem is that right now it's not possible. Taken that self-handling exceptions have higher priority it's required to write 1+N (where N is the number of exceptions which response have to be altered) handlers for exceptions.

Hi @radmen, I guess you need to submit a PR.

@kevmt I'd like to. First I need to make sure if I and @thetutlage are on the same page.
If not, my work may be discarded. I'd like to avoid it.
In previous comments I've written a draft of how could exception handler work:

https://github.com/adonisjs/adonis-framework/issues/718#issuecomment-346137626
https://github.com/adonisjs/adonis-framework/issues/718#issuecomment-346330447

How about using a flag. So on the global exception handler, you need to have a getter, which tells Adonis to use it always over anything else.
Which literally means it will not call handle method on the exceptions, even when those exceptions are created by you.
class ExceptionHandler {
   static get overrideAll () {
       return true
   }
}

Which literally means it will not call handle method on the exceptions, even when those exceptions are created by you.

Actually what I wanted to say is that the Exception handler should make use of exceptions handle() method.
Something like:
class ExceptionHandler {
    async handle (error, ctx) {
        if ('handle' in error) {
            error.handle(ctx)
        } else {
            // something different
        }
}

This way all error handling goes through the handler and is redirected to exceptions handle() methods.
Having this, developer will only have to overwrite handle() method of ExceptionHandler if they want different results.
Overall I'd say that this will change the priority of error handling yet, the behaviour (for defaults) will remain the same.

I believe we should have a GlobalExceptionHandler that will reside on the core of the framework.
This will check if the exception can handle itself as @radmen propose and fallback to the Youch screen if it's not possible.
Then, the ExceptionHandler created by the developer/cli will call super.handle(error, cli) to hook over every single exception.
The flow will be basically.

System throw an exception
Is ExceptionHandler available?
Call ExceptionHandler.handle(), if not hooked here --> super.handle()
GlobalExceptionHandler.handle(), self-handled?, Youch error page?

This provides a good way to hook overall exceptions you can have on the system and doesn't feel like magic.

This provides a good way to hook overall exceptions you can have on the system and doesn't feel like magic.

Exactly. Plus, it should simplify a bit code base in the framework.

Okay, So I am sync with you guys now. I will working on it in a way that it should not introduce any breaking changes, since every app will be using custom exception handlers.
@radmen Thanks for staying patient :)

@thetutlage no problem mate :)

Thanks! Works like charm :)

Hey guys, so this is an old issue, but I had understood error handling the way @thetutlage designed it originally. In my case, I wanted the error handler as a fallback to log only unhandled errors to the database. All my custom exceptions, I don't want to log, as they are handled. This way, my log only contains Exceptions I haven't handled yet. Turns out, since I added the global handlers, the self handle method is never called by my custom exceptions. Is there still a way to make it so that self handled exceptions don't fall back to the global handler?


Hide the "full screen" icon

Hi everyone,
I would like to hide the "full screen icon".
Someone can help me ?
Thanks in advance

Up please

Hello, I just figured it out.
Copy it to the folder where its components are located.
I copied it as MediaControlsCustom.js.
Don't forget to change paths.
import Slider from 'react-native-slider';
import styles from 'react-native-media-controls/lib/MediaControlsStyles';
import {humanizeVideoDuration, noop,} from 'react-native-media-controls/lib/Utils';
import PLAYER_STATES, {type PlayerState,} from 'react-native-media-controls/lib/Constants';

Since the package on line import Slider from 'react-native-slider'; is probably not installed on you, your IDE will perceive it as an error. Personally, PhpStorm says there is an error.
Let's not forget the image paths. (There are four images)
return require('react-native-media-controls/lib/assets/ic_play.png');

You can now remove the full screen icon.
<TouchableOpacity
            style={styles.fullScreenContainer}
            onPress={onFullScreen}>
            <Image source={fullScreenImage} />
</TouchableOpacity>

Finally, you can call and use it on the screen as follows.
import {PLAYER_STATES} from 'react-native-media-controls';
import MediaControls from '../../components/ThirdParty/MediaControlsCustom';


Add AMPI-only build target

This target will be customized to disable parts of Charm++ unused by AMPI and tune remaining settings for it.

There appear to be two different ways to enable the AMPI-only build, ./build AMPI-only and ./build ... --ampi-only. Would it be sufficient to have only one of these? (I'd vote for using./build AMPI-only since this disables some core functionality).
Otherwise, the patch looks good. It'd be interesting to see some performance results before merging this though. For many of the things that can be disabled mentioned above, it's hard to see how that would improve an AMPI application.

Many of the things mentioned above add overhead to array messaging for every message. We don't know exactly what the overheads are yet, but especially stuff like dynamic insertion, anytime migration, and demand creation all add extra checks to array messaging. There is also possible overheads in terms of extra memory used for bookkeeping.
Part of the motivation for this is also as sort of a test for Charm++ 7.0 where one of the stated goals is to have more sensible defaults, and most of the above features fall into the category of things we think should not be on by default, and should be opt in instead. We can't just go ahead and change all these defaults in Charm++ without breaking a ton of stuff. But since AMPI doesn't use many of these features, nor do the users of AMPI, it gives a good testbed to see how this will work.
I'm not sure if we will see a huge impact from this change just yet, because simply disabling these features may not remove all the overhead simply because the code path for all of these features is still intertwined with the basis code paths. A next step from this I'd imagine would be some actual code refactoring of these features so that when they are disabled they are more effectively removed from the relevant code paths. Something like a basic array subclass that only has the most basic functionality would be one possibility.

Changes look fine to me, although along similar reasoning we are using for Charm 7.0 better defaults, I think we'd eventually want to switch AMPI-only to AMPI. Adding an extra option just adds to the already confusing set of Charm++ build options, and if this works as intended, I don't see any reason for people to need the AMPI target unless they are already advanced users and know what they are doing.

There appear to be two different ways to enable the AMPI-only build, ./build AMPI-only and ./build ... --ampi-only. Would it be sufficient to have only one of these? (I'd vote for using./build AMPI-only since this disables some core functionality).

--ampi-only is a failsafe option for something like all-test-AMPI-tests where we can't append the -only suffix and test for it easily.

Removed mention of AMPI-only from CMakeLists.txt, since it is handled by buildcmake and not the txt itself
Fixed suffix removal in build for all-test-AMPI-tests


Survivor Game Added

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below
Fixes # <your_issue_number>

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @AbhishekPSingh07 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Hey @AbhishekPSingh07,
Please make sure to link the relevant issue using the appropriate syntax, such as "#issueNumber" 👀.
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗

Thank you  @AbhishekPSingh07 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


29: Building sasdata documentation

This is the first step to including the sasdata documentation in remote repositories (refer to sasview/sasview#2641). This auto-generates the docs during the CI process, but they are not currently stored anywhere. The next step will be to bundle the docs with the pypi release.
Much of the user documentation was ported from the SasView docs and modified for this stand-alone package.
Fixes #29

Should be part of 6.0 release

@smk did you have a chance to look at this PR?

@krzywon, looking at the docs generated by https://github.com/SasView/sasview/actions/runs/7106711492:
I see the addition of a sasdata entry in the Developer Documentation Contents:

This leads to a single entry list:

Which, in turn, leads to a dead-end:

Looking at the files changed by the PR one can see that two new docs have been created, Importing Data and Exporting Data. These are present:

But are only discoverable using the search, they are not linked from anywhere.


jdk9 with hotspot: jdk_net test -- java/net/Socks/SocksV4Test.java failed

Test category: openjdk
Testsuite name: jdk_net
Test name(s): java/net/Socks/SocksV4Test.java
Product(s) tested: jdk-9+181
OS/architecture: Ubuntu16.04 x64
Platform specific: yes
Reproducibility: always
Reproducible on machine: test-softlayer-ubuntu1604-x64-1
Regression: yes, introduced in JDK 9 181
Exception/Error from Log:
some output from log file
Error log file (if available): https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk9_hs_openjdktest_x86-64_linux/11/artifact/jvmtest/openjdk_regression/work/java/net/Socks/SocksV4Test.jtr/view/
Steps to reproduce:

Re-include test. (Search the Test class name in ProblemList_openjdk9.txt find the exclude line and comment the line
java/net/Socks/SocksV4Test.java *** linux-x86_64

make jdk_net (assuming you are running with the test material already setup, if not follow openjdk-tests/README.md instructions to set up test material first, then run the make target).

SocksV4Test.jtr.txt

I am closing all jdk9 issues, we have 2 or more other issues to capture java/nio issues in jdk8 and jdk11


Coraza always returns 'allow'

I'm using Alma 8, go version go1.21.11, haproxy 2.8.10.
I've cloned the repo, created the coraza-spoa binary, and setup all config files, essentially following this guide.
I run the binary, and it's listening on port 9000.
When I do a curl request, e.g. curl http://localhost:80/\?x\=/etc/passwd, I see the request being denied by the owasp ruleset, but coraza returns an allow to haproxy. I've checked this using the debug option in haproxy: %[var(txn.coraza.action)].
I expected a deny, as the owasp ruleset flags the request as critical as well.
Example of coraza message:
{"level":"error","ts":1722250000.55379,"msg":"[client \"<IP_ADDRESS>\"] Coraza: Warning. OS File Access Attempt [file \"/etc/coraza-spoa/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf\"] [line \"4360\"] [id \"930120\"] [rev \"\"] [msg \"OS File Access Attempt\"] [data \"Matched Data: etc/passwd found within ARGS:x: /etc/passwd\"] [severity \"critical\"] [ver \"OWASP_CRS/4.3.0\"] [maturity \"0\"] [accuracy \"0\"] [tag \"application-multi\"] [tag \"language-multi\"] [tag \"platform-multi\"] [tag \"attack-lfi\"] [tag \"paranoia-level/1\"] [tag \"OWASP_CRS\"] [tag \"capec/1000/255/153/126\"] [tag \"PCI/6.5.4\"] [hostname \"<IP_ADDRESS>\"] [uri \"/?x=/etc/passwd\"] [unique_id \"927f0d12-a6d7-4ee0-8a2d-aa3813a9b126\"]\n"}

I actually think that this commit broke it.
Also, when using the docker container I get the same results.

Hi @csuka
Have you tried changing SecRuleEngine to On on coraza.conf?
# Enable Coraza, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
#SecRuleEngine DetectionOnly
SecRuleEngine On

Got the same behavior on main:
Spoa config
cat /etc/coraza-spoa/spoa.yaml
...
    directives: |
      Include /etc/coraza-spoa/coraza.conf
      Include<EMAIL_ADDRESS>      Include<EMAIL_ADDRESS>...

Main coraza config
cat /etc/coraza-spoa/coraza.conf | grep ^SecRuleEngine
> SecRuleEngine On

Logs
journalctl -u coraza-spoa.service -n 10
> 46d71\"]\n"}
Sep 16 17:04:39 waf01 coraza[52209]: {"level":"error","ts":1726499079.543303,"msg":"[client \"212.95.5.x\"] Coraza: Access denied (phase 2). Inbound Anomaly Score Exceeded (Total Score: 10) [file<EMAIL_ADDRESS>[line \"7023\"] [id \"949110\"] [rev \"\"] [msg \"Inbound Anomaly Score Exceeded (Total Score: 10)\"] [data \"\"] [severity \"emergency\"] [ver \"OWASP_CRS/4.5.0\"] [maturity \"0\"] [accuracy \"0\"] [tag \"anomaly-evaluation\"] [tag \"OWASP_CRS\"] [hostname \"<IP_ADDRESS>\"] [uri \"/js/slideshow.js?\"] [unique_id \"a77c4a3f-0e2e-4c8e-8449-db889f646d71\"]\n"}

On https://github.com/corazawaf/coraza-spoa/pull/103 it works fine with the same coraza config includes.

Got it.
The haproxy.cfg referenced by the README.md (2nd reference) and in the docs is not blocking requests.
This one seems to do the job: https://github.com/corazawaf/coraza-spoa/blob/main/doc/config/haproxy.cfg
It seems PR https://github.com/corazawaf/coraza-spoa/pull/103 has fix the link in the README.

Can we close now that #103 was merged?

Idk, did someone did extensive testing?

The e2e test does go through HAProxy and therefore it has to be correctly working now.


add level 3

Pull Request
Description

I added level 3 after level 2 in this project, which is basically a search screen with fake login information to alert people to phishing
Related Issue
#48 I create a user-friendly search interface. And combined with the educational knowledge related to network security to realize the game logic and interaction.

Checklist

[x] I have tested the changes locally and they work as expected
[x] I have added necessary documentation or updated existing documentation
[x] I have followed the project's coding style and guidelines
[x] I have added appropriate test cases for the changes

Screenshots (if applicable)

It's great work @liuhuijuan12 👍🏻, after this we want to first complete the first level, there we want a mini game, After completing the first level we we can move to level 2 and three.
More contributions from your side are expected✨✨
From
Fuhad Kalathingal


fixes #175

Apparently the pattern matcher is unhappy if we generate code that looks like:
... match { case <freshname> => Some(...); case _ => None }, therefore I had to tune
the reification macro to avoid such codegen in rare edge cases.

/review @dveim

LGTM


[Bug]: Adding Regex validation in Currency Input throws error when input formats itself after loosing focus

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Currency Input widget throws error when a regex validation is configured in property pane and when input in currency widget gets formatted automatically after loosing focus from widget
Steps To Reproduce

Drag & Drop Currency Input widget
Add a regex validation from property pane. Eg: ^\d+$
Provide valid input in currency widget
Observe that on clicking outside of the widget, the input gets auto formatted but throws validation error

Public Sample App
No response
Issue video log
https://bthrujcsw8.vmaker.com/record/SZnPivH5iVr2cyJ5
Version
Cloud / Production

Seems like the regex is working as expected.
Having a , in the formatting was a decision that was deliberately taken.
@dilippitchika there is direct conflict between two things here. What do you say is the way forward?
Also this is not a high priority issue, Adding , in your regex expression will make it work well enough.


Add Files section and describe directory layout

Looks fine to me, beyond the will<->with typo.

@vdukhovni If you notice typos, next time you can "request change" in the review so it can be fixed before it is merged. That looks a lot better then making another PR and keeps master clean of errors.


Feature request: add api to query/list keys

The following code can be used to get a list of all keys, but it exposes the inner workings of the state-lib.  It would be nice to build this into the api so it is just an opaque-box.
potential api
async state.listKeys(continuationToken:string = '')
returning {
  keys: [],
  continuationToken: ''
}

current workaround
const stateLib = require('@adobe/aio-lib-state')
const state = await stateLib.init()
const queryPlan = state._cosmos.container.items.query(`SELECT c.id,c.ttl,c._ts from c where c.partitionKey='${state._cosmos.partitionKey}'`, {
  initialHeaders: {
    'x-ms-documentdb-partitionkey': `["${state._cosmos.partitionKey}"]`
  },
  continuationToken: params.continuationToken
})
const queryRes = await queryPlan.fetchNext()
const res = queryRes.resources.map(x => ({ key: x.id, expiration: getExpiration(x.ttl, x._ts) }))
const response = {
  statusCode: 200,
  // todo check the continuation token
  body: {
    message: 'success',
    keys: res,
    hasMoreResults: queryRes.hasMoreResults,
    continuationToken: queryPlan.continuationToken
  } // default is 24hours
}

Great suggestion @purplecabbage . Also the code above should be an implementation detail as we're abstracting the cloud service and provider and will change from one to the other.
Filing as an enhancement.

deferred


Feature Request: One Log Per Container

Hello,
Thanks for putting this together. One thing I'm confused about, however, is how to properly isolate the logs of disparate containers. With the normal agent, I can forward individual logs on the server to individual logs in Logentries. How can I send an individual container's output to an individual log in Logentries?
Could we have an equivalent of le follow container?

I would like this as well

The --matchByName REGEXP and the other regex options should help you do this.

I think that could be a temporary fix, but I wouldn't want to have to run a Logentries container for each of my services.

@jchamberlain thanks for the feedback. I think eventually we would see the UI be dynamic enough to let you separate out your various container logs. I will kick off some talk internally to see what people think about separating the logs out dynamically based on the user's containers.

@StephenHynes7, I ended up not using the logging container because of this issue. Instead, I'm logging to shared volumes and using the normal logentries daemon to collect the logs. However, I still think this would be a necessary feature to make your container useful. That said, you might consider writing a tutorial on using Logspout instead of designing your own container, as it appears to already have all the necessary features (though I haven't tried it myself).

I wouldn't mind having a look at this @StephenHynes7  do you have an idea on how you would like it to be implemented? Maybe adding support for an optional config file and match via docker labels https://docs.docker.com/userguide/labels-custom-metadata/ ?
{
   "{labelName}": "logentries-token"
}


Update Nginx to mimic ops-agent

Updated regexes to mimic ops-agent
Example Access logs:
::1 - - [26/Aug/2021:16:49:43 +0000] "GET / HTTP/1.1" 200 10701 "-" "curl/7.64.0"
<IP_ADDRESS> - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

Example Access output:
{
   "timestamp":"2000-10-10T13:55:36-07:00",
   "severity":30,
   "severity_text":"200",
   "labels":{
      "file_name":"example.log",
      "log_type":"nginx.access",
      "plugin_id":"nginx"
   },
   "record":{
      "host":"-",
      "http_request_protocol":"HTTP/1.0",
      "http_request_referer":"",
      "http_request_remoteIp":"<IP_ADDRESS>",
      "http_request_requestMethod":"GET",
      "http_request_requestUrl":"/apache_pb.gif",
      "http_request_responseSize":"2326",
      "http_request_status":"200",
      "http_request_userAgent":"",
      "user":"frank"
   }
}{
   "timestamp":"2021-08-26T16:49:43Z",
   "severity":30,
   "severity_text":"200",
   "labels":{
      "file_name":"example.log",
      "log_type":"nginx.access",
      "plugin_id":"nginx"
   },
   "record":{
      "host":"-",
      "http_request_protocol":"HTTP/1.1",
      "http_request_referer":"-",
      "http_request_remoteIp":"::1",
      "http_request_requestMethod":"GET",
      "http_request_requestUrl":"/",
      "http_request_responseSize":"10701",
      "http_request_status":"200",
      "http_request_userAgent":"curl/7.64.0",
      "user":"-"
   }
}

Example Error log
2021/08/26 16:50:17 [error] 29060#29060: *2191 open() "/var/www/html/forbidden.html" failed (13: Permission denied), client: ::1, server: _, request: "GET /forbidden.html HTTP/1.1", host: "localhost:8080"

Example Error Log output
{
   "timestamp":"2021-08-26T16:50:17-04:00",
   "severity":60,
   "severity_text":"error",
   "labels":{
      "file_name":"example.log",
      "log_type":"nginx.error",
      "plugin_id":"nginx"
   },
   "record":{
      "client":"",
      "connection":"2191",
      "host":"",
      "message":"",
      "pid":"29060",
      "referer":"",
      "request":"",
      "server":"",
      "subrequest":"",
      "tid":"29060",
      "upstream":""
   }
}

@jsirianni do we need to worry about mappings for this? Or is that process automated now?

@jsirianni do we need to worry about mappings for this? Or is that process automated now?

Yes we absolutely need to consider mappings.
I'm a bit out of the loop, what is the motivation for gaining parity with ops agent? Mappings are difficult to change once implemented.

@Mrod1598 Couple things

Can you provide input and output examples when running with Stanza v1?
Does this same change need to be made to the OTEL branch? I suspect it does. https://github.com/observIQ/stanza-plugins/tree/updated-fields

Added examples, and probably, going to chat with Josh about some this and come back to this.

Another note. We will need to update the observiq log format on our doc site and in the plugin doc.

Another note. We will need to update the observiq log format on our doc site and in the plugin doc.

is this still required?


CalendarPicker - Value is set to null but method val() returns a value

CalendarPicker - Value is set to null but method data('calendarpicker').val() returns a value e.g current date
but $(el).val() is a whitespace which is okay

Thank you, fixed in 4.2.24


Use same causal graph in different version of Dowhy, and the identification of backdoor is different

Hi, I use same causal graph in different version of Dowhy (0.7.1 and 0.6)，but the effect identification is different . This is very confusing, please help.
Version 0.7.1###
Estimand type: nonparametric-ate
Estimand : 1
Estimand name: backdoor
Estimand expression:
d
────────(Expectation(ord_num|mt_charge_fee_30days,high_confidence_age,income_l
d[isᵢₘₚ]
evel))
Estimand assumption 1, Unconfoundedness: If U→{is_imp} and U→ord_num then P(ord_num|is_imp,charge_fee_30days,high_confidence_age,income_level,U) = P(ord_num|is_imp,charge_fee_30days,high_confidence_age,income_level)
Estimand : 2
Estimand name: iv
No such variable(s) found!
Estimand : 3
Estimand name: frontdoor
No such variable(s) found!
Version 0.6###
Estimand type: nonparametric-ate
Estimand : 1
Estimand name: backdoor
Estimand expression:
d
────────(Expectation(ord_num|career,is_bind_user,marriage,count_nofee_order
d[isᵢₘₚ]
_num,alphau3,charge_fee_30days,select_hesitate_score,high_confidence_gender
,is_7_new_coup,income_level,ord_amt_90days,high_confidence_age))
Estimand assumption 1, Unconfoundedness: If U→{is_imp} and U→ord_num then P(ord_num|is_imp,career,is_bind_user,marriage,count_nofee_order_num,alphau3,charge_fee_30days,select_hesitate_score,high_confidence_gender,is_7_new_coup,income_level,ord_amt_90days,high_confidence_age,U) = P(ord_num|is_imp,career,is_bind_user,marriage,count_nofee_order_num,alphau3,mt_charge_fee_30days,select_hesitate_score,high_confidence_gender,is_7_new_coup,income_level),high_confidence_age)
Estimand : 2
Estimand name: iv
No such variable found!
Estimand : 3
Estimand name: frontdoor
No such variable found!

Both versions are correct. There are multiple valid backdoor sets possible. v0.7 updated a default which tries to show a minimal backdoor set.
If you'd like to see all valid backdoor sets, try method_name="exhaustive" as a parameter of identify_effect in v0.7. Then you can do identified_estimand.__str__(show_all_backdoor_sets=True) or use identified_estimand.estimands.
More generally, backdoor condition can be satisfied by multiple subsets of variables. So which backdoor subset to use is a statistical question that depends on the bias-variance tradeoff. This is a good read: https://ftp.cs.ucla.edu/pub/stat_ser/r493.pdf

Thanks for the reply, It really helps!


Tidy up VERSION in rest.py Resolves #159

Tidy up usage of "version" across the REST API to make it consistent
Marked methods that use an outdated version with TODOs
Fixed issues with switch_account(), delete_working_order() etc. which were not specifying a version correctly

Locally tested those that I changed version for, or those that did not have any version specified.
Resolves #159

hey @RRMXkun the CI build failed - can you run flake8 and run the tests locally before re-submitting?

@bug-or-feature This is because Session tests are split between Login v1 and v2. Is v1 still supported? I can reinstate the version argument in create_session() if it is needed, but can't see anywhere it would be used. v1 and v2 have identical in/output as far as I can tell.
I have re-run the tests locally with version reinstated in create_session() and all tests passed, so can confirm it is indeed the only blocker.

@RRMXkun the build is still failing.  See here:
https://travis-ci.org/github/ig-python/ig-markets-api-python-library/
If you want to see what the CI build does, look at the .travis.yml file. Also check the integration test, see .github/workflows/integration-test.yml. You know this library way better than me, do what you think is best - but I'm not going to merge in code that breaks the build

@RRMXkun I copied your branch onto another one and fixed the tests and flake8 errors. I've created a new task to add support for the newer versions in line with your comments. I agree there doesn't seem to be any difference between login v1 and v2, but have left both for now. I'm not sure that we should think about the newer versions as outdated or unsupported though. IG create new versions, but leave the old ones working. In the Java library for using the REST API, which they provide themselves, they have different methods/classes for each version:
https://github.com/IG-Group/ig-webapi-java-sample/tree/master/ig-webapi-java-client/src/main/java/com/iggroup/webapi/samples/client/rest/dto/session
I imagine that as its a public API, they don't want to break anyone's code that might be using the older versions. I think perhaps we should do the same. Any thoughts?

@RRMXkun I copied your branch onto another one and fixed the tests and flake8 errors. I've created a new task to add support for the newer versions in line with your comments.

Thanks, didn't find the time to correct this in my PR sorry

I agree there doesn't seem to be any difference between login v1 and v2, but have left both for now. I'm not sure that we should think about the newer versions as outdated or unsupported though. IG create new versions, but leave the old ones working. In the Java library for using the REST API, which they provide themselves, they have different methods/classes for each version:
https://github.com/IG-Group/ig-webapi-java-sample/tree/master/ig-webapi-java-client/src/main/java/com/iggroup/webapi/samples/client/rest/dto/session
I imagine that as its a public API, they don't want to break anyone's code that might be using the older versions. I think perhaps we should do the same. Any thoughts?

Yes it makes sense to keep legacy versions in the library for as long as IG keep them in theirs. However that changes the naming convention a bit i.e. we need to create a host of _v1 _v2s etc. Not a problem per se, but those without a version in their name should probably use the latest available version by default.
To clarify in my PR I have only explicitly specified the version number for each method by comparing their in/outputs to IG's doc. Where two versions had identical output I assumed the latest version. For example fetch_market_by_epic /markets/{epic} has identical in and outputs between v2 and v3 so I assumed v3 - this does not break compatibility.
However when I referred to them being outdated I meant the _v1 tests. The original author of rest.py and I assume of the _v1 tests seemed to have worked on the basis that version was determined API-wide. But as we found this is not the case; version is specific to each method. Therefore these _v1 tests are likely to keep breaking since they rely on an input and output format that the methods in rest.py, which currently only support one version of each call (and a lot of them are v2s and v3s) no longer support. If we had legacy _v1 methods then there would be value in having these _v1 tests.

@bug-or-feature could also reinstate the version parameter and default it to the latest version number each method supports.  Would that work?


Document where the config file is on the config documentation page

I was testing zoom values and broke the editor (#907), so I had to figure out where the config file was in order to fix my editor. This pull request documents its location.

Thanks for adding this, @lf- - really appreciate it!


Exception when merging files with nullable enums

Command I'm running:
% npx openapi-merge-cli --config openapi-merge.yaml

Files i'm using:
File 1:
openapi: 3.0.3
info:
  title: Test
  version: 0.0.1
paths:
  /some/endpoint1:
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/someSchema'
      responses:
        '200':
          description: successful operation
components:
  schemas:
    someSchema:
      type: object
      properties:
        someField:
          type: string
          nullable: true
          enum:
            - "A"
            - "B"
            - "C"
            - null

File 2 (identical to File 1, except for endpoint):
openapi: 3.0.3
info:
  title: Test
  version: 0.0.1
paths:
  /some/endpoint2:
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/someSchema'
      responses:
        '200':
          description: successful operation
components:
  schemas:
    someSchema:
      type: object
      properties:
        someField:
          type: string
          nullable: true
          enum:
            - "A"
            - "B"
            - "C"
            - null

Output:
## /opt/homebrew/Cellar/node/20.8.0/bin/node: Running v1.3.1 (+1ms)
## Loaded the configuration: 2 inputs (+36ms)
## Loading input 0: specs/test1.yaml (+0ms)
## Loading input 1: specs/test2.yaml (+0ms)
## Loaded the inputs into memory, merging the results. (+1ms)
An uncaught exception was thrown TypeError: Cannot use 'in' operator to search for '$ref' in null
    at Object.isReference (/Users/.../node_modules/atlassian-openapi/lib/type-checks.js:85:48)
    at compare (/Users/.../node_modules/openapi-merge/dist/component-equivalence.js:63:51)
    at /Users/.../node_modules/openapi-merge/dist/component-equivalence.js:80:39
    at Array.every (<anonymous>)
    at compare (/Users/.../node_modules/openapi-merge/dist/component-equivalence.js:80:26)
    at /Users/.../node_modules/openapi-merge/dist/component-equivalence.js:80:39
    at Array.every (<anonymous>)
    at compare (/Users/.../node_modules/openapi-merge/dist/component-equivalence.js:80:26)
    at /Users/.../node_modules/openapi-merge/dist/component-equivalence.js:80:39
    at Array.every (<anonymous>)

Platform: macOS Ventura (22D49)
Node version:
% /opt/homebrew/Cellar/node/20.8.0/bin/node -v
v20.8.0

Removing - null from one of the two files resolves the problem, but seeing as I need to do this programatically I cannot manually remove the - null option from just one of the files.


EditorConfig changes

Based on this comment here: https://github.com/blargity/toolkit-for-ynab/pull/175#issuecomment-181308886
I thought it might be nice to set a standard for formatting using EditorConfig, a cross-editor way of enforcing particular formatting preferences for a project.
The .editorconfig file is in the src tree, and the file match pattern common/res/features/*/*.{js,css} should match only user-created files one dir down, avoiding vendored files in subdirectories.
I then ran eclint from the src dir with the same parameters:
eclint fix -c utf-8 -e lf -n -w -i space -s 2 common/res/features/*/*.{js,css}
I'd rather make it universal, but figured since this conservative change affected quite a few files already, I'd leave it as is and wait for comment.

I think it's a good idea. I would also recommend specifying the indent_brace_style. My preferences would be Allman then K&R.

That, for better or worse, is not supported by EditorConfig.
Might be something to put in a style guide or the Feature contribution documentation.

Doh! Guess I missed that part. Next best thing would be to add a style
guide section to the Feature contribution doc.
On Tue, Feb 16, 2016 at 4:13 PM, Stephen Brown II<EMAIL_ADDRESS>wrote:

That, for better or worse, is not supported by EditorConfig
https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#ideas-for-domain-specific-properties
.
Might be something to put in a style guide or the Feature contribution
documentation
https://github.com/blargity/toolkit-for-ynab/blob/master/src/common/res/features/HOW_TO_BUILD_FEATURES.md
.
—
Reply to this email directly or view it on GitHub
https://github.com/blargity/toolkit-for-ynab/pull/209#issuecomment-184896749
.

I didn't care at the beginning of this project, but we've definitely grown larger than I ever expected. I now think this would be definitely worth doing.
I guess my only question here is if you don't know about EditorConfig, and you just code up some feature, is the plan at the moment that the rest of us will end up contributing the styling back the next time we run eclint? Or should I be kicking features back that use the wrong styling before merge?
I'm thinking about automating this as much as possible, so maybe if Travis can either run the fix and auto-commit the change back so everything is automatically styled, or alternatively if it fails your PR until you style properly, I think that'll be the best way to go here. I'd love to see this implemented in an automated way.
What do you guys reckon?

I think it has to be done automatically. What about adding it to the build so that it's done locally? Installing it would simply be part of the "contribution instructions". Maybe have a look at https://github.com/beautify-web/js-beautify which has a python interface and seems to be a bit more full featured. It also handles css.
I also think it would be good idea to poll the current contributors to get their opinions on the style. I know that opinions can be all over the place but in the spirit of community I think they should be sought out. IMO, @blargity should break any ties and have the final decision.

Is there any way to make js-beautifier work in python without pip installing it first? So we can have it just exist in the files like Kango does?

It looks like it might work if we include it as a submodule and then just reference it in the build script.

I believe that would work.
On Thu, Feb 18, 2016 at 8:02 AM, Kevin Brown<EMAIL_ADDRESS>wrote:

It looks like it might work if we include it as a submodule and then just
reference it in the build script.
—
Reply to this email directly or view it on GitHub
https://github.com/blargity/toolkit-for-ynab/pull/209#issuecomment-185735073
.

eclint can run as a gulp plugin, but including beautifier in the code with the right settings should work fine with the build script as well, except... that won't fix commits, just deploys... Unless... one added it as a Travis check.

My primary reason for suggesting taking a look at js-beautify was that it
already handles a few things that EditorConfig doesn't. Primarily braces.
That said, anything is better than nothing IMO.
On Thu, Feb 18, 2016 at 8:59 AM, Stephen Brown II<EMAIL_ADDRESS>wrote:

eclint can run as a gulp plugin
https://github.com/jedmao/eclint#gulp-plugin, but including beautifier
in the code with the right settings should work fine with the build script
as well, except... that won't fix commits, just deploys... Unless... one
added it as a Travis check.
—
Reply to this email directly or view it on GitHub
https://github.com/blargity/toolkit-for-ynab/pull/209#issuecomment-185756856
.

js-beautify also handles css and html, which is absolutely fine by me, I was more suggesting the time of the check being pre-commit rather than on build.

Works for me.
Of course if the necessary files are included as part of the project, I
could run it locally if I choose to. Or I could download the tools directly
and then all I'd need in the project is the beautify config file. One way
or the other I like it.
On Thu, Feb 18, 2016 at 10:26 AM, Stephen Brown II<EMAIL_ADDRESS>
wrote:

js-beautify also handles css and html, which is absolutely fine by me, I
was more suggesting the time of the check being pre-commit rather than on
build.
—
Reply to this email directly or view it on GitHub
https://github.com/blargity/toolkit-for-ynab/pull/209#issuecomment-185801485
.

@StephenBrown2, to develop your code you're going to run ./build or build.bat, so if that failed if it didn't like the style of your files I think it'd be a pretty consistent thing that people would fix it up before opening a PR. It's not 100% but it'll get most cases.
I think we can do the Travis stuff as a secondary and separate task. Travis would make sure we don't accidentally merge stuff that doesn't match the style guide, but I think this first step will definitely be enough to fix it in the vast majority of cases and would rather get it in sooner than later.
Would you like to add js-beautifier as a submodule, then add
git submodule init
git submodule update
# However you run js-beautifier's python version
# Output of success or failure

to the build scripts? I think I'm the one that'll need to set up Travis which I'll do once we have this working and the code cleaned up.
In terms of deciding what the actual style will be I'll set up a survey.
How do we feel about automatically fixing up files vs failing and telling you to do it with a script that would automatically do it? I'm in two minds, one is it's kinda weird to have it automatically change your source, but at the same time it's kinda annoying to have to run a second script when it's going to have to get done to get accepted anyway.

I'm ok with automatically fixing the style during the build. The beautify just needs to be done first so that what is built is the modified code if it was actually changed. Personally I will update my editor to match the agreed upon style so it is enforced on the fly. But that's me...

@blargity Good point I hadn't thought about that being part of the testing process. It might need to be installed in a virtual environment so as to not intrude on dev's machines, or just listed as a requirement and ./build fails if it can't find js/css/html-beautify in the PATH.
Running it should probably rely on a config file included with the source, similar to the .editorconfig file I added), and run as js-beautify --config ./beautify.js.config, css-beautify --config ./beautify.css.config, html-beautify --config ./beautify.html.config, etc, with appropriate folders listed and vendored files excluded of course.
The beautifier can be added early in the build process, and I support automatically fixing when it can, but the benefit of EditorConfig is, if you have the right plugin, it will be enforced during development like @dbaldon said.

Style survey is here: https://blargity.typeform.com/to/L1yXGL

Alrighty @StephenBrown2, we've got results back from the survey. We're discussing them on Slack (looks like you've got a pending invite). I'm recommending we follow this style guide: https://github.com/airbnb/javascript
Want to hop on Slack so we can chat in one place?

So, it may be as simple as requiring npm/node to be installed, then adding this to the build script (assuming https://github.com/airbnb/javascript has been integrated/submoduled/ripped in place to ./lib/javascript - though I'd rather name it something more descriptive like airbnb-javascript-lint):
cd lib/javascript
npm install --save-dev eslint-config-airbnb eslint babel-eslint eslint-plugin-react jshint
cd ../../
./lib/javascript/node_modules/.bin/eslint -c ./lib/javascript/.eslintrc src/common/res/features/*/*.js
./lib/javascript/node_modules/.bin/jshint -c ./lib/javascript/.jshintrc src/common/res/features/*/*.js

And then dealing with the exit codes and messages produced from the above commands.

Yup, should be that simple. We can add it as a submodule as well.
Random tip as well, you can use pushd and popd instead of just cd if you want to get back to where you started without figuring out how many levels deep you were.
What I'm getting at is who wants to do these steps exactly? Any volunteers? I think @egens may already be on it? Want to avoid doubling up effort if we can.

@blargity I'm not. Struggling to find time for the project last days.

@egens, no worries, me too at the moment!

Went to the SydJS meetup a few days ago and there's a fantastic idea around this: racheted builds.
The idea is instead of it being all of the linter stuff passes or fails, the CI server runs a baseline build before your changes, then again after the changes. If you've made the build better, it passes, if you've made it worse it fails.
http://gitratchet.org/
Would be a great way to enforce this while we're getting the older code up to snuff.

Filed #320 to continue on in this spirit, hopefully more complete this time.

I'm going to go ahead and close this PR in favour of #320 which I just merged. Thank you!


⚠ Cioos Pacific CKAN has degraded performance

In 4d5c426, Cioos Pacific CKAN (https://catalogue.cioospacific.ca) experienced degraded performance:

HTTP code: 200
Response time: 8836 ms

Resolved: Cioos Pacific CKAN performance has improved in e9e27c8 after 2 hours, 56 minutes.


WIP: Intermediate Results

Issue: https://github.com/DARPA-ASKEM/simulation-service/issues/34
A question since I'm new here:
How much configuration to the callback should be exposed?  Are there some reasonable defaults that should be hard-coded or is the frontend telling us what to do?
Roadblocks:

https://github.com/SciML/EasyModelAnalysis.jl/issues/158 prevents us from adding a callback to simulate.

Unless I'm missing something, fixing https://github.com/SciML/EasyModelAnalysis.jl/issues/158 looks trivial and I can make the PR.

The callback expects the job id and a dictionary containing the current parameter values and loss. @mwdchang might have other ideas of what to include in the dictionary. Additionally, @mattprintz mentioned we can control things like the frequency in of messages in the callback so hopefully the callback we pass in will handle much of the frontend requirements

The callback expects the job id and a dictionary containing the current parameter values and loss.

E.g. interactivity_hook(job_id, dict)?  I don't see any example usage of it in the repo.


Modified Css for responsive navbar

Issue No: #3
Modified CSS and HTML for making the navbar responsive

@ghulamyazdani With lots of changes in the main branch and conflicts in this PR, I am closing this PR.


Add Clippy

Add clippy to the diesel crate (but only the diesel library crate) and fix some of the warnings.
Just add the "dev" feature to include clippy.

Currently, these warnings remain.

(Updated to split into two commits and remove change for doc_markdown false positive.)

I just updated the PR to update clippy and deny warnings unless clippy is used. I also added a clippy 'step' to travis. You can see some of the remaining warnings here: https://travis-ci.org/diesel-rs/diesel/jobs/126730544#L1039

I just rebased this on master and updated to the latest clippy version (maybe that needs a newer nightly -- Travis will tell us).
I've also added some _allow_s for lints which I don't think are useful here (option_map_unwrap_or_else and option_map_unwrap_or or for specific parts of the code I didn't want to change. git grep -i 'feature = "dev", allow' should show all instances.

Travis confirms that this clippy version does not compile with the nightly from May 9. @sgrif, I think you mentioned that in the future you wanted to use the nightly from the date the latest stable was released, right? According to http://rusty-dash.com that'd currently be May 27 and the next one will be Jul 8.
I'm okay with downgrading clippy to get this merged, btw.

I finally updated this PR to a newer clippy version and to fix all the lints (I also enabled a few optional ones). This passes locally with a nightly from 2016-09-29. Once we bump nightly (probably along with the macros 1.1 stuff), I'd like to try to land this.
After that, I'll add clippy to other crates.

Sounds good. After Macros 1.1 I'm going to finish composite primary keys and roll a release, we can merge after that

Want to rebase so we can merge?

Rebased, bumped Clippy to version 0.0.103, and allowed/fixed some new lints. Since Clippy fails on current nightly, I made Travis stick to the one from clippy's last release.
Let's see if they manage to release 0.0.104 soon and merge after that.

Rebased, again :D
The most recent nightly is from the 19th (6 days ago), which is kinda unfortunate. Since this is open for 3/4 of a year now, I'll not squash this all right now but wait for one more nightly, and maybe for @sgrif to have quick look.
Ideally, I'd like to add another travis env with a fixed nightly that runs clippy (and is an allowed failure), until we can install clippy with rustup and have a guarantee that it compiles at all times.

Finally! This is

adding the latest clippy 0.0.103 as an optional dependency with the lint feature
improving a whole bunch of stuff in the various crates to make clippy real happy
green with #[deny(warnings)]!
adding a new entry in Travis' build matrix (which compiles quite fast as it is using no-trans)

Can you add the lint feature to the integration test lines in bin/test, too? (Maybe hold off for a few on rebasing I'm about to push up something that changes that file for MySQL)

🎉


fix broken patch url in pkgs/tools/misc/fontforge/default.nix #28270

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

It is fixed in https://github.com/NixOS/nixpkgs/pull/28212

Closed on "It is fixed in #28212"


Transactions with minimal amount leave too many fee

Context

Information
-

Version
07c0ff4eb

Platform
All

Installation
N/A

Steps to Reproduce

Have a wallet with exactly the right amount to pay for delegation fee (i.e. enough to pay for a certificate, constant fee and a single input).
Make a transaction

Expected behavior

The transaction is accepted and the wallet has a balance of 0

Actual behavior

The transaction is rejected by the server and it requires an additional amount which matches the fee for an extra input/output.

Resolution

Adjusted fee calculation to better handle edge-case ==> #1145
Use fee estimator instead of hard-coded fee in the integration tests ==> #1145

QA

See comments below.

I see that delegation fee is still shown incorrectly. Looking at our own integration tests fees config:
fees:
  certificate: 42
  coefficient: 1
  constant: 14

so, if I understand correctly, the fee for delegation fee should be 42 + 14 = 56. (if paid from one utxo)
Delegation fee endpoint shows = 58
Delegating to stake pool takes fee = 58

The same goes for transactions.
Tx fee (for single utxo tx) is calculated = 17 (instead of 16).
That is for both, making tx and tx fee.

So... tests do not catch that, Perhaps it would be better to have fee in the integration tests being part of hardcoded TestData rather than calculated by feeEstimator?
Refering to this -> https://github.com/input-output-hk/cardano-wallet/pull/1145/commits/3eee4a23f77ca8e99600c62717b5f8c122b5119d

@piotr-iohk you're forgetting the coefficient part. 1 means that each input or output cost 1. So, in the case of a standard delegation that requires only one UTxO, it'll typically cost 58 because it requires one input (the UTxO) and one change output!
Only if your input is exactly of the right amount (i.e. 57 coins) will you be able to pay 57, because no change output is needed. 56 will never be possible however because you always need an input.

We have integration tests testing for these edge-cases (sorry, I see the QA section on this ticket is empty :| ... ), let me find that back for you.

So,

https://github.com/input-output-hk/cardano-wallet/blob/master/lib/jormungandr/test/integration/Test/Integration/Jormungandr/Scenario/API/StakePools.hs#L345-L356

We are creating a wallet with a single UTxO that is exactly 57 coins (constant fee + certificate fee + coefficient fee for a single input). This is enough to create a delegation certificate. Perhaps it would be good to add an extra assertion on the resulting transaction to show that it actually has no outputs!

https://github.com/input-output-hk/cardano-wallet/blob/master/lib/jormungandr/test/integration/Test/Integration/Jormungandr/Scenario/API/StakePools.hs#L358-L366

Here's an example where we have a wallet that has 56 coins (the minimal fee - 1) and, it's not able to join.

https://github.com/input-output-hk/cardano-wallet/blob/master/lib/jormungandr/test/integration/Test/Integration/Jormungandr/Scenario/API/StakePools.hs#L368-L375

The assertion in this one might seem a bit counter-intuitive. The wallet is empty and the server returns that it can't create a delegation certificate, because it is missing 56 lovelace! Why 56 and not 57 ? Because of the way the algorithm works. We only require additional inputs when needed and at this stage, we know that the wallet hasn't even enough to cover for the flat fees (constant + certificate) and we haven't selected a single input yet! Ultimately, we could catch that edge-case and return a more meaningful error like "your wallet is empty"

OK, so is this correct then?
fees:
  certificate: 42
  coefficient: 1
  constant: 14

delegation_fee = constant + certificate + (coefficient * (inputs + outputs))
tx_fee = constant + (coefficient * (inputs + outputs))

Ultimately, we could catch that edge-case and return a more meaningful error like "your wallet is empty"

I'd be in favor of this idea. :)

OK, so is this correct then?

Yes!

@piotr-iohk see also: https://github.com/input-output-hk/cardano-wallet/blob/master/lib/jormungandr/test/integration/Main.hs#L170-L193

lgtm :+1:


Add support for "index" document name (index.yaml and index.yml)

Although OpenAPI recommends "openapi" for the name of the document, it is common for projects to use the name "index".
For some, this may be flexible. However, there are cases where the name of this document can't be changed without a lot of effort. An example would be if all specs are stored in a particular repository, and said repository is referenced in many other repositories as a submodule. A lot of work could be required to find and replace all references to this file name.

You can use a symlink, and generate code into a dedicated target.

@andrewse02 I'm not sure I fully understood the use case you're referring to.

However, there are cases where the name of this document can't be changed without a lot of effort. An example would be if all specs are stored in a particular repository, and said repository is referenced in many other repositories as a submodule. A lot of work could be required to find and replace all references to this file name.

To adopt Swift OpenAPI Generator in a project, it is already necessary to create a target with both the OpenAPI document and plugin config file. So there will be some need to copy or symlink the document you desire for each target from this repo of many specs, so presumably the symlink approach @czechboy0 suggests will suffice?

Oops, totally forgot about symlinks. Must not have been all there there when I wrote this 😅

@andrewse02 try it out, and if it solves the problem, feel free to close this issue 🙂

The workaround above should work, feel free to reopen if it doesn't.


Create a Website that list all possible commands

Would be nice if someone could create a website where users can see all the possible commands that can be done with the bot

Closing this issue. We have uploaded web files, currently available here with GitHub Pages:
https://discordstonks.github.io/discordPy/


Fix blurry fonts without dynamic padding

There were some minor rounding issues in the padding codepath without
dynamic padding. These have been fixed, which should resolve issues with
blurry fonts on monitors with a fractional DPR.
This fixes https://github.com/jwilm/alacritty/issues/1806.

Looks good to me, thanks! :)

@matthiaskrgr Thanks for testing. Waiting for CI to finish.


trying to understand expr lang more, is there anything that expression can do that goja / otto cant and vice versa?

as titled

Hello,
Let me explain the difference.
It may seem what expr and goja solves a similar problem, but they do it in a little bit different way. Also use cases can be different, goja targets more environments where JS may be needed, Expr on the other hand targets rule engines, filtering, and policy of different kinds.
A few differences between goja and expr:

Main difference is that Expr can be type checked. Expr comes with advance type checker which can use type defined directly in Go program. This is very useful, for example, if you want users to allow editing expressions in UI and on save button your program can type check the new expression and warn of any errors found.

goja/otto implement full JS, so you need to be aware of what users can write: infinite loops while(true);, self-recursions, an so on. Expr is non-Turing complete and has limited set of functionality available for users. Expr also has more expressive syntactic sugar, for example predicates all(tweets, .size <= 280). Also, in Expr you have full control other the language and what features available to users.

Patching. Another powerful tool in Expr is AST patching (expr-lang.org/docs/patch). Patching allows to modify expressions in any possible form before compilation. A lot of companies use this powerful feature in a lot of different ways.

Expr designed to be working with Go. Expr does not wrap values and uses them directly. As goja is JS vm, goja has to wrap all passed values into Value struct (sometimes with strange consequences) and unwrap ExportTo.

Speed. As Expr was designed specifically for Go and with business rule engines/expressions in mind, Expr is faster than goja/otto (bench). Expr uses own virtual machine, Expr has optimizing compiler, and Expr uses a few tweaks to speed up the Expr/Go communications.

Both Expr and goja a very cool and powerful languages. And you need to choose what suits you best for the task you are working on.

thx so much for the comprehensive explanation.
just curious, i was looking at making my own cloudflare workers (which would prefer js than wasm), so was wondering if i can use expr as replacement?
i know expr is not using js but i was wondering will it be a good fit for FaaS kind of scenario,
also i'm hoping able to do "hot reload" like detecting file changes and reload expr lang script. <- any caveats? for example i wont use plugin reload as memory is not reclaimed for the old unused golang plugins.
will expr be a good fit for FaaS? what caveats do i have to look out for?
@antonmedv appreciate this last question. thx. will use expr in filtering too.

will expr be a good fit for FaaS? what caveats do i have to look out for?

I don't have enough context to give meaningful advice here.  ¯\_(ツ)_/¯

@sprappcom

will expr be a good fit for FaaS?
What aspects or use-cases (in a  FaaS context) do you mean to refer to ? Or do you mean to ask whether expr (alone by itself) could serve as a full-blown FaaS runtime?
If it is the latter that you mean to ask, then the answer is no. Can answer in detail if you have any specific question(s).

@antonmedv

Expr is non-Turing complete

Never gave a thought to this until I read your comment. I think, expr is Turing complete. We have [practically] arbitrary memory addressing, some form or iteration/looping, and conditional code-flow, which should be enough to claim Turing completeness. If that is not enough, what definitely nails Turing completeness is the support for custom functions (i.e execution of arbitrary golang code).
WDYT?

There is no doubt what you can turn expert into turning complete language with custom functions.
But only using builtin functions, not possible.
Here is an example: using only built-in functions produce Fibonacci sequence.


Develop

Added AKDynaRageCompressor and AKRhinoGuitarProcessor.
Added some helper DSP C++ processing stuff, too.

One of the most anticipated (by me) pull requests ever!


DocsArchive-1.0.20260.3Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/conceptual-version-docfxv3-archive/pull/1 is merged into live branch.
Auto archive content to https://github.com/Pingpli/conceptual-version-docfxv3-archive.git

Docs Build status updates of commit dce9201:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

contoso/non-version.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Authorization for tus-uploads on password protected links

When I'm uploading a file via tus to a password protected public link, the initial POST request succeeds without problems: https://localhost:9200/remote.php/dav/public-files/WoXYZdRaXgPZEZZ/. The auth header is e.g. Basic cHVibGljOnRlc3Q=.
Now the second request, a HEAD request, with the exact same auth header stays in a pending state in the browser network tab. Instead, the classic Basic-Auth-Browser-Window pops up and asks for credentials as the backend response includes Www-Authenticate in its response headers.
The oCIS error log prints ERR error fetching from accounts-service error="{\"id\":\"com.owncloud.api.accounts\",\"code\":401,\"detail\":\"account not found or invalid credentials\",\"status\":\"Unauthorized\"}" query="login eq 'public' and password eq 'test'" service=proxy
I'm not a 100% sure if this is a frontend or a backend issue. But the requests seem to be correct for me, so my first impression is that something in oCIS goes wrong here.
Edit: I also ran the head request via curl, which is giving me 401 Unauthorized as well.

@kobergj FYI

Fix was merged. Problem is gone with current master
@JammingBen we can remove the workaround now

Thx, works fine 👍  See https://github.com/owncloud/web/pull/6890 for frontend follow up.


document SQL compatible null handling mode

Description
This PR does what the title says, and adds documentation for the SQL compatible null handling mode added from #4349, and advising on the potential performance implications using the data collected in #8822.

This PR has:

[ ] been self-reviewed.
[x] added documentation for new or modified features or behaviors.

This should not be merged until #8876 is merged


Use high precision elevation data

Currently we use SRTM or CGIAR both having 90m resolution but a new data set released which has 30m resolution. Still the CGIAR data is not updated and I'm not sure if using 'pure' SRTM is wise.
BTW: Instead of interpolating via surrounding tiles - maybe we should interpolate while creating an edge with the ele data?
Also it looks it is not yet fully released ... in April 2015 it will release for EU+US and other parts will follow this year.
Data sources:

http://www2.jpl.nasa.gov/srtm/ -> http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/
New srtm data now void filled. See the SRTM user guide
new and open data set from EU here
new and open data set from UK
new and open data set from Sweden, license is CC-By (ftp://download-open.lantmateriet.se/GSD-Hojddata grid 50 plus/nh/Stockholm/Sweref 99 TM/geotiff/) but there is an older data set which becomes public in ~2020, see section 2.2. of (ftp://download-open.lantmateriet.se/GSD-Hojddata grid 50 plus/hdb/Stockholm/Sweref 99 TM/ascii-tabell/)
http://ned.usgs.gov/faq.html#DATA

Interesting tool to merge these different data sets here

It is not a good idea to use SRTM. The holes and errors in mountainous regions are terrible. Best example is this lake in a valley which has an elevation difference of 400m according to SRTM.
http://www.wanderreitkarte.de/forum/thread.php?board=3&thema=28#2
Perfect for water skiing. :-)
A smaller grid does not improve on missing / nonsensical data.
The CGIAR data has been interpolated for small gaps and filled in with data from other sources. I am not aware that an update to 30m is planned. Even if it was it is a considerable piece of work.
There is also the ASTER data, but according to several analyses it only has a pseudo resolution of 30m, the actual data is comparable to SRTM and contains considerable artifacts.
In short, the best elevation data available for free at the moment is still CGIAR and viewfinderpanoramas.

Isn’t the "missing data" problem fixed with the newest release of the data? I think I read that somewhere…
I would need that data in GraphHopper for my diploma thesis, but I did not look into the SRTM integration in general. If anybody could give me a few hints on what needs to be changed, I’d give it a try :-)

I started implementing this: https://github.com/andreaswolf/graphhopper/tree/srtm-1deg. Still missing is a fallback to the low-res data for the uncovered areas, but that can be added in the high-res provider class.

Somehow missed the discussion here.
@andreaswolf nice, very interesting! As a side question: why is CGIAR or the old res not sufficient in your case? And do you intend to additionally interpolate the SRTM data similar to what people did to get CGIAR?

Actually, I did not check if the old resolution would suffice, but I think the more precise the data is, the better the results I get for my thesis will be.
I have to check again, but IIRC with version 2.1 of the SRTM data, all holes that CGIAR removed were also fixed in the original data. Is that what you mean with interpolating the data?

also fixed in the original data. Is that what you mean with interpolating the data?

Yes & interesting. But they just filled holes or also applied some low-pass / high-pass filters or whatever to make the landscape more natural ... maybe @NopMap knows more?

@andreaswolf if you like to give me some insights in your thesis (would like to hear what you plan :)) feel free to ping me via email. BTW: really diploma thesis, wow & nice ;) ?

It looks like the data is now void filled opinions? There is also a SRTM user guide

And there is a new data set from EU here

There's also data from Luxembourg here: https://data.public.lu/en/datasets/bd-l-mnt5/
It would be nice to be able to tell Graphhopper to use more than one local source.

Maybe the easiest step for us right now, would be to implement another elevation provider SRTMV3, with preferably 1 arc-second resolution (~30*30m).
You can download the new version here. However, the data is a) huge, b) downloads are ridiculously slow, and c) need an account, which makes automatic downloads hard. I am not sure if mirroring the new data is allowed, since they use the ASTER data, redistribution of the original ASTER data is not allowed AFAIK, see the OSM mailing list and wiki. Using the data itself to derive work or services should be fine.

I think the current code was adapted already to work with a more fine grained grid, but I've also not really tested this on my own in the last months. Also the license seems unclear to me and not open data (?) ASTER is technically nice but license-wise ugly.

Using the data itself to derive work or services should be fine.

Ugly license that forbids redistribution as we would redistribute it partly (for all roads).

However, the data is a) huge

Shouldn't be a big problem these days :)

I have found a very extensive list of possible elevation sources here.

I was looking into the elevation data of finnland. Understanding the mapping of coordinates to the naming of the files is quite hard, as they don't use coordinates in their name (like SRTM and others). However, I found this pdf explaining the naming schema a bit more.

Hi - is there any interest in adding an option for mapzen elevation data provider? It comes in SRTM format with global 1 arc second coverage at https://s3.amazonaws.com/elevation-tiles-prod/skadi/{N|S}{y}/{N|S}{y}{E|W}{x}.hgt.gz. I'd be happy to submit a pull request (or open another issue to track) unless there is a reason you'd prefer not to.

I think adding Mapzen's elevation data would be nice. The data has some holes and glitches from SRTM but the last time I tested it, it looked quite good overall. Not sure if there are any reasons not to add it?

If it is the same format we should probably just make it configurable (?)

Just to leave it here for future reference, the code generating the tiles is also still there:
https://github.com/tilezen/joerd/blob/master/docs/data-sources.md

configurable would be nice. I prototyped this a while ago. It’s the same format, but IIRC the file naming is slightly different and latitude is not limited (range is -90 to 90)

I took a shot at this in #1929. As it turns out it wasn't exactly the same format as the other SRTM providers (mapzen/skadi data is gzipped, SRTM is zipped, and SRTMLG1 is not compressed at all) and the naming conventions for existing SRTM providers had special cases so it was hard to extract a configuration-based template so #1929 just implements the mapzen/skadi format with a configurable base path.


i can t create community

Subject: i can t create community
Description:
because i applied twice and still didn t see anything.
Results:
I decided to create a community for my city which is Muğla (but more Bodrum because Bodrum more popular than Mugla) . I applied two different time but still didn't get any notification or anything. can you look at this?


Missing blank_penalty Configuration

I am in the process of shifting our infrastructure from Python to Go for better latency. However, I noticed that the blank_penalty configuration parameter, which is available in the Python API (see online-decode-files.py#L239), is missing in the Go package. This parameter is important for us.
Is there a way to configure blank_penalty in the Go package? I'm ready to contribute and make a PR if any package changes are needed to make it available.
Thank you!

I'm ready to contribute and make a PR if any package changes are needed to make it available.

Please follow how we add the following field
https://github.com/k2-fsa/sherpa-onnx/blob/master/sherpa-onnx/csrc/offline-recognizer.h#L39
to add support for blank_penalty.
https://github.com/k2-fsa/sherpa-onnx/blob/9ee2943ed45d9bb80bfd33f178aae7259d94188b/sherpa-onnx/csrc/offline-recognizer.h#L41

You need to change the following files at the following places

https://github.com/k2-fsa/sherpa-onnx/blob/master/sherpa-onnx/c-api/c-api.h#L429
https://github.com/k2-fsa/sherpa-onnx/blob/master/sherpa-onnx/c-api/c-api.cc#L428
https://github.com/k2-fsa/sherpa-onnx/blob/master/scripts/go/sherpa_onnx.go#L423
https://github.com/k2-fsa/sherpa-onnx/blob/master/scripts/go/sherpa_onnx.go#L531
Done!

Hey,
Suggested changes worked, I am raising this PR for same. I was hoping it would be possible for you to release this before the end of the week as I have a deadline to release to my production infrastructure. Sorry for the urgency and understand if it is not possible but just wanted to keep you informed on my timeline. Let me know if I can help in anyway to achieve this.
Thank you!

I was hoping it would be possible for you to release this before the end of the week as I have a deadline to release to my production infrastructure.

Just released a new version, v1.20.21
Please re-check.
@parth-khiera

Thanks for the quick action! @csukuangfj
Closing issue