Design of the public API

We choose to start working on the library by defining the public interface. Defining pre-built kernels has several advantages:

It forces us to settle on a reasonable interface with which the internals will need to work;
They are a good entry points in the library. Probably what people would like to try first, for most of them these pre-built algorithms will be enough;
Since their behavior is known, these are a good target for integration tests and benchmarking. As a result they will come with some guarantees of robustness and performance.

BlackJAX will expose two objects publicly: kernels (NUTS and HMC) as well as Stan's window adaptation scheme. In this PR we define these objects' public API. You can look at the code in this PR for the proposed implementation. I discuss some of the points I judged important below.
Example use
One would create and run a (HMC) kernel as in:
from blackjax import hmc
from jax import random

rng_key = jax.random.PRNGKey(2020)
init_position, inv_mass_matrix = get_position()

parameters = hmc.new_parameters(inv_mass_matrix)  # has default value of step_size and num_integration_steps
init_state = hmc.new_state(init_position, logpdf)
hmc_kernel = hmc.kernel(logpdf, parameters)

new_state, info = hmc_kernel(rng_key, init_state)

Note that I said a kernel. BlackJAX returns one kernel, that runs one chain. The execution loop and batching is done user-side. While everyone more or less agrees on what should go in a general-purpose NUTS or HMC kernel, I don't want to force my opinionated choice on the users for batching and looping. And I suspect users who do not want to bother with this mechanic would use their favorite modeling language.
The choice to JIT-compile or not the kernel is left to the user.
Interface
logpdf or potential
Do we require a logpdf or a potential_fn to create the kernel? I used logpdf in the example above in the code because this a potentially confusing one. I am not opposed to potential_fn since it simplifies the code a little. Maybe someone with more experience could chime in?
I/O
A crucial point is the I/O: how should the initial values of the random variables be passed? What do we get as an output? This is where JAX and its pytrees shine, really. Users would have to respect the following constraints:

The state of the chain needs to be contained in either a list, a (named) tuple or a dictionary of arrays. The arrays can indifferently be Numpy arrays or JAX DeviceArrays;
If the state is called x then logpdf(x) must return the value of the log-probability at position x.

These constraints are rather loose, and suit most existing application with little to no modifications. As an output, state.position returns the current values of random variables in the same format they were passed in.
Let's do a tour of 3 of the PPLs involved in this project, see if they would have do change anything (correct me if I'm wrong).
Numpyro
Numpyro's potential takes a dictionary as an argument; the state of the chain is passed around in a dictionary. It would work as is.
PyMC3
PyMC3's potential is a function of the random variables; the state of the chain is passed around as a list. It would have to pass the function lambda x: logpdf_pymc3(*x) to BlackJAX's kernels if it wanted to keep the same format for the state of its chains.
MCX
MCX's potential is a function of the random variables; the state of the chain is passed around as a dictionary. I would have to pass the function lambda x: logpdf_mcx(**x) to BlackJAX's kernel if it wanted to keep the same format for the state of its chains.
state, info
We separate the state of the chain from additional information about the transition. This allows user to choose whether they want to keep it or discard it at each step. This is the pattern followed in MCX.
The state in a NamedTuple with fields position, potential_energy, potential_energy_grad. The last 2 avoid wasteful computations. The arrays in position are JAX DeviceArrays.
The info is a nested NamedTuple. For instance in MCX:
class HMCInfo(NamedTuple):
	proposed_state: HMCProposedState
    acceptance_probability: float
    is_accepted: bool
    is_divergent: bool
    energy: float
    proposal_info: HMCProposalInfo

proposal_info is where info about the NUTS transition would be stored (number of leapfrog steps taken, etc.). Some of the info is used internally, some is included in the trace and everything else is discarded.
Everything else is in this PR's code.
Adaptation
Exposing a simple API for Stan's window adaptation is no small feat. Here is the simplest example possible where the user has full control over the looping/batching:
import jax

from blackjax import window_adaptation
import blackjax.hmc as hmc

rng_key = jax.random.PRNGKey(2020)
num_warmup_steps = 1_000
init_position = get_position()

init_parameters = hmc.new_parameters()
init_state = hmc.new_state(init_position, logpdf)

init, update, final = window_adaptation(logpdf, hmc.kernel, num_warmup_steps)
state, warmup_state = init(rng_key, init_parameters, init_state)

for _ in range(num_warmup_steps):
    _, rng_key = jax.random.split(rng_key)
    state, warmup_state = update(rng_key, state, warmup_state)

parameters = final(warmup_state)

However I am not sure that even to adapt multiple chains the user needs to have control over the inner loop. We could thus take care of the updating loop ourselves, thus simplifying the API a lot. window_adaptation becomes a big function so the previous example would look like:
import jax

from blackjax import window_adaptation
import blackjax.hmc as hmc

rng_key = jax.random.PRNGKey(2020)
num_warmup_steps = 1_000

init_position = get_position()
init_state = hmc.new_state(init_position, logpdf)

init_parameters = hmc.new_parameters()
state, parameters, warmup_chain = window_adaptation(rng_key, hmc.kernel, logpdf, init_state, init_parameters, num_warmup_steps)

Users can adapt the parameters of several chains by vmap-ing over the rng_key, init_state and init_parameters. The current code implements this design. It is shown with no guarantee of actually working, but it gives the general idea of what needs to be implemented, how it relates to the core, and how complex it is.
With hindsight this does not allow users to add a progress bar so we should probably go with the first solution.
Misc questions

Do we expose both recursive and iterative NUTS?

Next steps
Once we've agreed on the API I suggest to take HMC and run with it, open a discussion on the internals and get something running quickly. Tests can be set up simultaneously, targeting the publicly exposed HMC.

Indeed. I removed those, thanks.
On Fri, 11 Dec 2020 at 16:08, Tymoteusz Wołodźko<EMAIL_ADDRESS>wrote:

@twolodzko commented on this pull request.
In blackjax/hmc.py
https://github.com/blackjax-devs/blackjax/pull/1#discussion_r541013342:

try:

   step_size = float(step_size)

except ValueError:

   raise ValueError(f"Could not convert `step_size` to float: {step_size}")

try:

   num_integration_steps = int(num_integration_steps)

except ValueError:

   raise ValueError(

       f"Could not convert `num_integration_steps` to int {num_integration_steps}"

   )

Those try... excepts... seem unnecessary, since they repeat the same
error that would be raised without them:

float("hello world")Traceback (most recent call last):
File "", line 1, in ValueError: could not convert string to float: 'hello world'

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/blackjax-devs/blackjax/pull/1#pullrequestreview-550180090,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5UP5BDB6RRDE62DOTULOTSUIYWNANCNFSM4UVUPKEA
.

--
*Rémi Louf *
@remilouf https://twitter.com/remilouf

PS: if there ever is a good moment to nitpick, this is the moment.

PS: if there ever is a good moment to nitpick, this is the moment.

Do you want us to nitpick on just the api or anything in the code?

Both for NUTS and HMC. It's not worth spending too much time on the code inside the window_adaptation at this point, mostly on the API.

Im not an expert on the guts of MCMC algos so I cant' say if these things are "right", but as someone who has read a lot of code these implementations are very readable and importantly seem to encapsulate the core details in a great interface.
I am more curious about the return values as that defines the other side of the interface, but same comment as the one before, if its too early to ask feel free to ignore!
Overall this seems fantastic though and I'm even more excited about where this is heading

Thanks! This is a very important concern, and if you are curious you can check https://github.com/rlouf/mcx/blob/master/mcx/inference/kernels.py for what I have in mind. Every part of the algorithm that advances the chain returns a (state, info) tuple where state is needed to move the chain and info extra information that can be kept or discarded.

Thanks for documenting everything in the PR description and making a note of all the relevant design choices. I'll go through the API in more detail, but some initial thoughts:

logpdf or potential: logpdf is more intuitive for beginners, but is a bit misleading. My slight preference would be for a more verbose unnormalized_logpdf, but at that point potential_fn begins to sound like a reasonable choice too.
Do we expose both recursive and iterative NUTS? - We will not be able to JIT compile the recursive version, and it was unusably slow from what I remember with the earlier JAX versions (though things might have changed now). My vote would be to only provide the iterative version in the public API to keep maintenance overhead low, but it's okay to have a recursive one for initial testing/debugging.
Regarding IO, as we discussed earlier, pytrees is a great interface choice. All we need is the consistency between whatever pytree the user passes in and the logpdf function's input type. NumPyro also follows this and just requires the type of potential_fn and the initial params to HMC to line up.

Other thoughts:

User defined diagnostics: A function(def diagnostics(state:HMCState): PyTree) that can capture user-defined diagnostic information (e.g. log density at a specific site) which can be included as an additional field in HMCInfo might be useful for other libraries, though would love to hear other thoughts on this.

Hi @rlouf. This looks like a really interesting project! Can I check whether there would be scope for the kernel implementations here being designed in such a way to allow use with integrators other than the standard Störmer–Verlet / leapfrog integrator?
I develop a Python package Mici which includes implementations of various HMC algorithms including methods which simulate constrained Hamiltonian dynamics and dynamics with a position-dependent metric (i.e. Riemannian-manifold HMC) which require different integrators. In Mici the NUTS / dynamic HMC implementation is decoupled from the details of the integrator and Hamiltonian system to allow it to be shared across the different algorithms.
Given that the draft API here includes an integrators module it seems like you might be already thinking of allowing for different integrators to be added?  If there was interest in abstracting to allow different integrators to be used, it seems like it could be useful to include a definition of the expected interface of an integrator within the API and also adding the integrator as an optional keyword argument to the kernel factory functions. It would also potentially make sense in this case to separate the HMCParameters tuple in to separate structures for kernel specific parameters (e.g. number of leapfrog steps, maximum tree depth, change in Hamiltonian to trigger divergence), integrator specific parameters (e.g. step size, tolerances / maximum number of iterations for solvers in implicit integrators) and 'system' / Hamiltonian specific parameters (e.g. metric / mass matrix, form of kinetic energy, whether to use a non-standard Hamiltonian splitting).
As well as allowing for using different integrators, abstracting like this would also make it easier to implement methods in which the potential energy (and gradient) used in the integrator differs from that used in the kernel for calculating the probabilities of accepting a move to a state on the generated trajectory, e.g. shadow Hamiltonian methods, Section 5.5 in Radford Neal's 'MCMC using Hamiltonian dynamics' book chapter.
There are some related comments / suggestions I have about the suggested API if you are open to designing it to work with different integrators / types of Hamiltonian systems, but I thought I would check first if this is something that comes within the scope of the project or if it is extra source of complexity you would prefer to avoid!

@neerajprad thank you for weighing in.

You made a good case for potential_fn; I agree with you but let's see what the others think.
Is recursive NUTS still slow after JIT-ing the gradients of potential_fn + kinetic_ernegy and the integrator? We should keep this in mind when we discuss the internals. Still, it probably can't be made as performant as the iterative version and I agree the high-level API should only expose the latter. We can always implement the implicit doubling procedure in the internals for those who want to experiment.

Most custom diagnostics can be computed outside of the inference kernel (like log-probability at different sites) using the information that is returned. You can even compute them in the inference loop if you wish:
def one_step(state, rng_key):
    state, info = kernel(state, info)
    diagnostic = compute_custom_diagnotic(state, info)
    return state, (state, info, diagnostic)

which I think ends up being similar to what you suggested? The burden on the user is identical, but this design keeps the maintainance on our end lower and the code leaner. What do you think?
Designing the internals so everything is a kernel or a composition of kernels really did simplify MCX's backend and made it more general. I hope I can make a case for it 😁

@matt-graham Thanks! I have been following mici for a while, it is really impressive, and we would definitely be happy to have your feedback/ideas.
There is scope for the use of different integrators. However, these will likely not be exposed in the high-level API (which, in my opinion, is for users who only want something that works). This does not mean, however, that they won't be easily accessible. In fact, the internals will be designed so advanced users can easily assemble custom kernels. You have probably already read the code corresponding to the definition of the HMC kernel in this PR, but let me copy it here for those who are only following the discussion:
momentum_generator, kinetic_energy_fn, _ = metrics.gaussian_euclidean(inv_mass_matrix)
integrator = integrators.velocity_verlet(potential_fn, kinetic_energy_fn)
proposal = proposals.hmc(integrator, step_size, num_integration_steps)
kernel = base.hmc(proposal, momentum_generator, kinetic_energy_fn, potential_fn)

As you can see, the choice of the integrator is completely decoupled from the proposal (which is where NUTS differ from, say, HMC). It is also possible to initialize it with a different potential energy (thank you for the reference on shadow Hamiltonian methods, which I did not know about!). Internally it only interfaces with the rest of the code by taking a state, a step size and returning a state.
This is not entirely fantasy code since this is exactly how kernels are built in MCX. MCX also provides implementations for several palindromic integrators. It is also possible to choose a different integrator with a keyword argument at a higher level.
What you provide at a higher level is always a delicate balance to strike, but I think that in the context of BlackJAX the responsibility of building something more complex than a reasonable default should be left to the user (in the case of a PPL like MCX, its maintainers).
It may seem like a huge gap between providing pre-built kernels with opinionated defaults on the one hand and lego pieces on the other hand. But it is actually not, building a custom kernel takes 4 lines of code! This way we can focus on having robust pre-built kernels, and spend the time we would have spent on maintaining an array of customizations adding new elements. For this reason I largely prefer composition over parametrization.
Additional thoughts in no particular order:

threshold for divergence should go in HMCParameters with a reasonable default you're right.
I am not a big fan of separating HMCParameters in different substructures for the high-level API. And at the lower level, as you see, you can do whatever you want.
metric is changed by replacing gaussian_euclidean with your favorite metric in the code above. You may have to change the integrator, but we can safely assume users know what they're doing when they start tinkering with metrics :) We can always add a couple sentences in the docstring for the curious.

Finally, constraints is not something that I had foreseen for the internals and I think it is worth including it in future discussions. Since you have a lot of experience building modular internals for the HMC family your opinions on the internals would be invaluable. We are still working on the design document for the internals, but in the meantime you can check out MCX's internals for the general inspiration.

Is recursive NUTS still slow after JIT-ing the gradients of potential_fn + kinetic_ernegy and the integrator?

Good point, I remember that the gains were substantial enough that we decided to remove the recursive version, but you are right that simply JITing the integrator loop might be fairly competitive.
Regarding custom diagnostics, I agree with you. Since we are doing single step here, it's best for the client code to handle that.

Hi all, apologies for kind of randomly jumping into this discussion.
Right now the API seems to assume that the logpdf or potential_fn is written in JAX and that one can use JAX's autodiff tools to get the gradient of that function, is that correct? How much work would it be to allow an interface where the user can manually specify the gradient function as well? For example, this is possible in Turing's AdvancedHMC.jl and that allows AdvancedHMC.jl to be used with Julia's different autodiff libraries.
One application this could potentially enable is using algorithms implemented in blackjax with Turing! In principle it is possible to call Julia functions from Python and vice versa. Because it is quite straightforward to add new sampling algorithms to Turing it shouldn't be too much work to add compatibility with blackjax. I'm just going to ping the Turing people here because they might have more insights about this than me: @yebai @mohamed82008 @devmotion @xukai92 @trappmartin @torfjelde .
More generally, not assuming that the potential_fn is written in JAX could potentially also make it possible to use this library with PyTorch/Tensorflow (or really arbitrary Python code) but to be honest I don't know enough about them to understand whether that would be a sensible thing to do.

Actually specifying the gradient function separately would also be useful for pymc3 where we can compute the gradient through theano/aesara.

Thank you for chiming in @treigerm ! I have my own opinion but I think that @neerajprad and @fehiepsi are more apt to answer this question on a technical level than I am.

@treigerm: Providing a gradient function in the interface should be easy enough, but we will need it to be expressed in terms of JAX primitives which kind of defeats the purpose, or at least its utility will be much more limited than what you envision. The reason is that grad in JAX is a program transformation and has support at the level of individual numpy ops and control flow primitives. This makes it easy to compose it with other transformations like vmap/pmap (for running parallel chains) or jit for lowering all the operations to XLA primitives. That makes it a closed ecosystem by design unfortunately. Would love to hear if there are any undergoing efforts for better integration between JAX and Julia, that would be pretty cool!

Would love to hear if there are any undergoing efforts for better integration between JAX and Julia, that would be pretty cool!

I'm aware that there has been some work in this direction (see for example: https://github.com/PhilipVinc/Jax.jl) but I don't think there is anything that will be sufficiently performant so that it would actually make sense to use a JAX based sampler in Turing.jl or the other way around. I'm also not entirely sure what you would gain from integrating JAX with Julia apart from using software that is written in JAX.

One application this could potentially enable is using algorithms implemented in blackjax with Turing! In principle it is possible to call Julia functions from Python and vice versa. Because it is quite straightforward to add new sampling algorithms to Turing it shouldn't be too much work to add compatibility with blackjax.

I assume this would be possible with several tweaks, but then the AD backend would be dependent on the inference algorithm (which is currently not the case in Turing) and one would have to translate the model function to a JAX function and you would probably introduce an overhead due to the bridge.

Thanks everyone for your replies!
@neerajprad: I hadn't considered that you would use transformations like vmap with the transition kernel but that makes a lot of sense!
@trappmartin: I was kind of hoping that in the future there would be a low overhead Julia<->JAX bridge.

I'm also not entirely sure what you would gain from integrating JAX with Julia apart from using software that is written in JAX.

That was indeed my main motivation. So for example if someone implements Riemannian Manifold HMC in JAX then I would be able to easily call it from Julia. There just seems to be a lot of cool stuff being developed in JAX and it would be nice to have that available in Julia.
But that's an entirely different conversation, my initial question has been resolved and I don't want to sidetrack the discussion further. 🙂

Great discussions that will be useful for future reference! Closing this draft PR, the action is now happening in #2.

Great discussions that will be useful for future reference! Closing this draft PR, the action is now happening in #2.


Implement secure cookie

This PR resolves #33.  By default the secure cookie option is set when the NewAuthorizer() is called.  To turn it off a special function called AllowInsecureCookie() will need to be called to set it back to false.  Error messages are generated if the secure cookie is on and it the site is served over http.
The example is updated so that it will work by default on non-https sites but it has been appropriately commented to not do such in production.
The httpauth version should be incremented since it changes default behavior.

Changes Unknown when pulling 1b0e4055a8b2ea8bc7ca4dfc42033f2d0d7f1107 on turnkey-commerce:secure-cookie into ** on apexskier:master**.


[Java] genearate class leak on openj9 jdk

Search before asking

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

Version
Fury: 0.5.0-SNAPSHOT
OS:linux
JDK:openj9 17
Component(s)
Java
Minimal reproduce step
Fury will cache generated classes using weak/soft reference, so the generate serializer classes will be eligable for GC. But it doesn't work for openj9 on linux. Openj9 on windows17 works fine.
This is fine mostly, if we are not int a environment which hot swap/load classes. But for dynamic load classes cases, this will cause class leak.
Reproduction: mvn test -Dtest=org.apache.fury.FuryTest#testClassGC
What did you expect to see?
class be gc
What did you see instead?
test timeout
Anything Else?
#1437 #1433
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

I cannot reproduce this problem on openjdk17.0.2, how can I reproduce it?


Create github workflow to run test for web_app

Read our Contributor Guidelines and README.
Create new github workflow for running test for web_app
Here is the example how it was done for data_handler

I would like to take this task, I love orange.
My ETA is 48hr from the start ODHack but i will make first PR in the next 12hrs.

@lukaspetrasek
I would like to take this task, I love orange.
Even though I am a first time contributorI am familiar with Python programming and problem solving. I am ready to begin as soon as the task is assigned and aim to complete it within a reasonable timeframe, depending on its complexity.

I  would like to take this task, I love orange. I can get this done within 10 Hours.
To actualise this task I'll leverage my knowlegde of GitHub Action and workflow, and Docker basic.

Hey @lukaspetrasek I will like to work on this issue

I would like to take this task, I love orange


HMR module.hot.accept strange behavior?

Hi everyone !
Description
I encountered a strange behavior when developing my app today. Bored to continually having to reload my application when modifying my Redux Store, I wanted to switch to HMR to avoid painful work. HMR is perfectly working for most of the app but not for Redux.
I ended up following tutorials and doing something like this:
// store/index.js
import { createStore, applyMiddleware, combineReducers } from 'redux'
import thunk from 'redux-thunk'
import { settingsReducer } from './reducers/settings'
import { duelsReducer } from './reducers/duels'
import { profilesReducer } from './reducers/profiles'
import { chatReducer } from './reducers/chat'

export default () => {
  const rootReducer = combineReducers({
    settings: settingsReducer,
    duels: duelsReducer,
    profiles: profilesReducer,
    chat: chatReducer,
  })

  const store = createStore(rootReducer, applyMiddleware(thunk))

  if (module.hot) {
    module.hot.accept(() => {
      console.log('[HMR]: Redux')
      const rootReducer = combineReducers({
        settings: require('./reducers/settings').settingsReducer,
        duels: require('./reducers/duels').duelsReducer,
        profiles: require('./reducers/profiles').profilesReducer,
        chat: require('./reducers/chat').chatReducer,
      })
      store.replaceReducer(rootReducer)
    })
  }
})

// App.js
import React, { useRef } from 'react'
import { StatusBar } from 'react-native'
import { Provider } from 'react-redux'
import configureStore from './store'

const store = configureStore()

const App = () =>  (
  <Provider store={store}>
    <RestOfTheApp />
  </Provider>
)

export default App

Strangely, that was not working, module.hot.accept was never called. After trying different things, I ended up with a working solution by removing the configureStore function and using the store directly exposed in App.js:
import { createStore, applyMiddleware, combineReducers } from 'redux'
import thunk from 'redux-thunk'
import { settingsReducer } from './reducers/settings'
import { duelsReducer } from './reducers/duels'
import { profilesReducer } from './reducers/profiles'
import { chatReducer } from './reducers/chat'

const rootReducer = combineReducers({
  settings: settingsReducer,
  duels: duelsReducer,
  profiles: profilesReducer,
  chat: chatReducer,
})

const store = createStore(rootReducer, applyMiddleware(thunk))

if (module.hot) {
  module.hot.accept(() => {
    console.log('[HMR]: Redux')
    const rootReducer = combineReducers({
      settings: require('./reducers/settings').settingsReducer,
      duels: require('./reducers/duels').duelsReducer,
      profiles: require('./reducers/profiles').profilesReducer,
      chat: require('./reducers/chat').chatReducer,
    })
    store.replaceReducer(rootReducer)
  })
}

export default store

The second is working as expected, but it’s never documented anywhere, and the console.log is displaying in Metro bundler. Is it normal behavior or an unexpected bug? I can try to provide a MVCE if needed. 🙂
React Native version:

System:
    OS: macOS 11.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 2.15 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 12.19.0 - ~/.nvm/versions/node/v12.19.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.8 - ~/.nvm/versions/node/v12.19.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.0 - /Users/doctor/.rbenv/shims/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
    Android SDK: Not Found
  IDEs:
    Android Studio: 4.0 AI-193.69<IP_ADDRESS>26763
    Xcode: 12.4/12D4e - /usr/bin/xcodebuild
  Languages:
    Java: 14.0.2 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1
    react-native: 0.63.4 => 0.63.4
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

Create new project with  react-native
Import redux and react-redux
Try HMR with store

Closing as stale


Broken help links

Not essential this one but nice for continuity of business I guess. On my help screen there are some links which are broken:

https://documentation.teacommerce.net/ doesn't exist
https://teacommerce.net/en/documentation/revision-history/ throws an error

Easy to fix with some redirects I guess.

@PeteDuncanson ahhh, good call. I think we updated these in newer releases, but of course, people on older versions will be wrong. Will implement some redirects accordingly 👍

Rewrites have been setup. Thanks for the heads up 👍


Add new feature of SafeLoRA

The pull request was closed due to syncing with the latest version of PEFT, so I have requested the pull request again.
I have made all the necessary changes based on our previous conversations in this version.
If there are any issues, please let me know.
Thank you.

@chiayi-hsu Once you're finished with your changes and want me to give another review, please ping me.

@BenjaminBossan I have completed the modifications. Please help review them. Thanks!

Yes, it still needs to be addressed.
github-actions[bot] @.***>於 2024年12月27日 週五，16:04寫道：

This issue has been automatically marked as stale because it has not had
recent activity. If you think this still needs to be addressed please
comment on this thread.
—
Reply to this email directly, view it on GitHub
https://github.com/huggingface/peft/pull/2201#issuecomment-2563782198,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AS67YGQHUBZIJ5BAKWVLSET2HVT6XAVCNFSM6AAAAABRJLCTH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRTG44DEMJZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>


suggestion: redo "Using Docker to Deploy to any VPS" section

This section can be re-written to be much leaner by referencing already existing documentation:

[ ] Deno Deploy via a GitHub Action
[ ] Deploying to Digital Ocean with Docker
[ ] Deploying to Amazon Lightsail with Docker

Closing in favour of #460.


Suffix does not work

Adding a suffix prop is not displayed in the input field.
prefix works.

Hi, what suffix are you adding? Could you post a code snippet?

Closing issue as I don't have enough information to re-produce.
Feel free to re-open if this comes up again.


legacy PB pages to be ported to PB-Jekyll

Many pages in legacy PB are linked from the tools panel of PB-Jekyll dev site. Some of these need to be ported to the jekyll site as  HTML pages.
(Links have to be individually checked and decided as to how it should be handled)

The Peanut Genome:  https://peanutbase.org/peanut_genome
NIFA PCCGP Project: https://peanutbase.org/germplasm/nifa_pccgp
Germplasm: https://dev.peanutbase.org/germplasm/

These may wait until we decide:

Marker-Assisted Selection: https://peanutbase.org/mas
Maps: https://peanutbase.org/chado/featuremap  (Tripal/Chado dependent)
https://peanutbase.org/search/protein_domains (Tripal/Chado dependent)
QTL Search: https://peanutbase.org/search/qtl  (Tripal/Chado dependent)

May not need be touched for now:

Gigwa2.5 and  GCViT (not dependent on legacy site, so can stay as such for now)
ArachisPheno(its own VM)

NIFA PCCGP Project
https://dev.peanutbase.org/germplasm/nifa_pccgp
Issue:
The Gigwa link is still under peanutbase.org. Are we planning to run Gigwa here? (The link would change to 'germplasm/gigwa' or something similar)

Marker-Assisted Selection
https://dev.peanutbase.org/mas
Issues:

Trait pages: work in progress. I am thinking about whether these should go in a template, the trait managers could add information to a YAML file or something.
Still lots of peanutbase.org links.
Should the PDF files go in the repository? (Same question for dot plots in 'Changes between genome assemblies v1 and v2')

On gigwa let us wait until Thu PB meeting and will decide with Andrew's
input, then we can change the link url. Somewhere in the issue or in a
separate issue, you may list these as reminders lest they get invisible.

Gigwa2.5 and GCViT (not dependent on legacy site, so can stay as
such for now)

On 3/27/23 4:07 PM, svengato wrote:

NIFA PCCGP Project
https://dev.peanutbase.org/germplasm/nifa_pccgp
Issue:
The Gigwa link is still under peanutbase.org. Are we planning to run
Gigwa here? (The link would change to 'germplasm/gigwa' or something
similar)
—
Reply to this email directly, view it on GitHub
https://github.com/PeanutBase/jekyll-peanutbase/issues/26#issuecomment-1485863558,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4A465VKNHCYEI5D3N4FX3W6H6R7ANCNFSM6AAAAAAWFQLGTA.
You are receiving this because you were assigned.Message ID:
@.***>

May be we should create an issue for for each page I can comment on them
as we go forward one by one.  Right now I don't have firm idea about MAS
page and more traits with markers can be queried from  ArachisMine.
Sudhansu
On 3/27/23 4:14 PM, svengato wrote:

Marker-Assisted Selection
https://dev.peanutbase.org/mas
Issues:

Trait pages: work in progress. I am thinking about whether these
should go in a template, the trait managers could add information
to a YAML file or something.
Still lots of peanutbase.org links.
Should the PDF files go in the repository? (Same question for dot
plots in 'Changes between genome assemblies v1 and v2')

—
Reply to this email directly, view it on GitHub
https://github.com/PeanutBase/jekyll-peanutbase/issues/26#issuecomment-1485871413,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4A4677MMHU7RTSEAZP6MLW6H7LXANCNFSM6AAAAAAWFQLGTA.
You are receiving this because you were assigned.Message ID:
@.***>

Germplasm
https://dev.peanutbase.org/germplasm
Issues:

The Gigwa link is still under peanutbase.org (see above)
NIFA-PCCGP link is under Germplasm, is that correct?
What is aradu1_araip1_gnm1.div.HK28.sub10k.vcf? I see other diversity files in the data store, but not that one.
Interactive pedigree chart has gone missing.
Image Collection: work in progress.

Good idea, I will create separate issues. I have not yet looked at Maps, Protein Domains, QTL Search, and there may be others.

Another question is which links should appear in a new window/tab.

For convenience, I have temporarily added a red * by content that still needs updating, and a red # by links to pages created on the fly. These tags will disappear as each item gets fixed.

Committed first cuts at most of these on 9 May 2023. Maps and QTL Search are not yet ported.


Convert to using m3x packages for common code

R: @xichen2020 @robskillington

Think it might be missing the submodule, try perhaps:
mkdir -p vendor/github.com/m3db && git submodule add https://github.com/m3db/m3x vendor/github.com/m3db/m3x

Ah didn't realize we were committing the actual submodules.  Fixed.

Coverage increased (+1.7%) to 81.143% when pulling cf2328942833a9c7ee77920f62af3cd96f073a24 on mmihic-use-m3x into 6115ea35f4ccac563bfb3371421fab345095d99b on master.

LGTM


[Feature] Multithreads enhancement request

Search before asking

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

Description
There are a number of ways to implement multithread programming in java. I did a simple test: using new Thread() inside a controller to generate multiple threads, then query and write database in each thread. When I call the test controller, SW can only capture each pointcut like mysql driver, controller call, but cannot line them up like an entire trace.
Therefore, I believe, currently, the tracing is not working at multithread scenario. This feature is a significant one since multithread is common, and support the tracing in new threads, synchronized methods as well as reused threads created by thread pool during the biz logic are needed.
Use case
new Thread();
ThreadPoolExecutor.submit();
CompletableFuture.doSomething();
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

This is wrong asking from a tech perspective. This is an open-source community, not a commercial service.
We have provided full documents to explain how the plugin works in x-thread cases, what are x-thread APIs in agent kernel. You didn't read it, and your questions don't make any sense.


Discussion log/level-min

@avelino changing how we log stuff.
this pr is not ready, still need to config https://stackoverflow.com/questions/14544991/how-to-configure-slf4j-simple
min-level to remove org.jetty info log from pedestal.
fixed: #133

I like the solution, but the [main] logs is not needed, we need to remove it
[main] INFO org.eclipse.jetty.util.log - Logging initialized @4095ms to org.eclipse.jetty.util.log.Slf4jLog
2023-07-14T18:03:27.227Z Avelinos-Buser-MacBook-Pro.local ERROR [moclojer.io-utils:11] - :open-config :not-found file not found
2023-07-14T18:03:27.235Z Avelinos-Buser-MacBook-Pro.local INFO [moclojer.router:20] - :spec-mode :mode :moclojer
2023-07-14T18:03:27.239Z Avelinos-Buser-MacBook-Pro.local INFO [moclojer.server:40] - :moclojer-start -> moclojer :start-server :host <IP_ADDRESS> :port 8000 :url http://<IP_ADDRESS>:8000 :version dev :config-path /Users/avelino/.config/moclojer.yml :mocks-path nil
[main] INFO org.eclipse.jetty.server.Server - jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 20.0.1
[main] INFO org.eclipse.jetty.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@397c53e7{/,null,AVAILABLE}
[main] INFO org.eclipse.jetty.server.AbstractConnector - Started<EMAIL_ADDRESS>(http/1.1, h2c)}{<IP_ADDRESS>:8000}
[main] INFO org.eclipse.jetty.server.Server - Started @4638ms

remove this:
[main] INFO org.eclipse.jetty.util.log - Logging initialized @4095ms to org.eclipse.jetty.util.log.Slf4jLog
...
[main] INFO org.eclipse.jetty.server.Server - jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git: 8da83308eeca865e495e53ef315a249d63ba9332; jvm 20.0.1
[main] INFO org.eclipse.jetty.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@397c53e7{/,null,AVAILABLE}
[main] INFO org.eclipse.jetty.server.AbstractConnector - Started<EMAIL_ADDRESS>(http/1.1, h2c)}{<IP_ADDRESS>:8000}
[main] INFO org.eclipse.jetty.server.Server - Started @4638ms

I created a branch where I switch from slf4j-simple, that prints direct to stdout, to slf4j-jdk14  that "forward" from slf4j into JUL
https://github.com/moclojer/moclojer/compare/main...souenzzo:moclojer:feat/filter-logs-jul
Things that I like in this PR:

Small and simple change
No extra deps
Filter via clojure code

Things that I don't like in this PR:

A custom formatter is required

Given this chart

I will try to:

reuse the slf4j-simple formatter inside my solution
try (again) to use filters with slf4j-simple

Logback seems to be "too big" for our use-case
If you like this current state, feel free to merge, use and customize it :)

@avelino @matheusfrancisco  TIL:
We could add this property
-Dorg.slf4j.simpleLogger.log.org.eclipse.jetty.server=error
To the build properties
instead of switch away from slf4j-simple and implement a custom logger
SimpleLogger configuration is more powerful than I expect
https://www.slf4j.org/api/org/slf4j/simple/SimpleLogger.html

sorry, didn't get it what is the main difference between what we have know to this approach?

get back to this comment:

https://github.com/moclojer/moclojer/pull/135#issuecomment-1645720997

At that time, I was unable to solve the issue using this:

try (again) to use filters with slf4j-simple

And now I discovered that it is possible to do.


Added Intros for Rest APIs

Why:
Closes #6974

What's being changed:

Added Intro for "Codes of conduct"
Added Intro for "Code scanning"
Added Intro for "Emojis"
Added Intro for "GitHub Enterprise administration"
Added Intro for "Gists"

Check off the following:

[x] I have reviewed my changes in staging (look for the latest deployment event in your pull request's timeline, then click View deployment).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@codewithdev Thanks so much for opening a PR! I'll get this triaged for review :zap:


WIP eureka

Don't think this is ready yet, as there are some gaps
@minwoox can you help champion this one?
Fixes #1870

This MR seems dormant, is anyone still working on it?

Are you up to taking it over?
On Mon, Feb 21, 2022, 10:17 agilis allievo @.***> wrote:

This MR seems dormant, is anyone still working on it?
—
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/pull/3316#issuecomment-1046640238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXOYAXQ5XK34M4ULD44HELU4H7LTANCNFSM4T7D6F4Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

https://github.com/openzipkin/zipkin/pull/3671 finishes this

the problems here were mostly test lifecycle in nature (properties read at the wrong time), so https://github.com/openzipkin/zipkin/pull/3671 walked around them by using testcontainers+dynamic properties instead of nested initialization. https://github.com/openzipkin/zipkin/blob/master/zipkin-server/src/test/java/zipkin2/server/internal/eureka/ITZipkinEureka.java


Aniwave extension not working

Source information
Aniwave 14.69
Source language
English
Steps to reproduce

First step; open aniwave extension
Second: open any anime series
Issue : it reloads for a sec then it shows -

Expected behavior
Should show all listed episodes
Actual behavior

Aniyomi version
I'm using a fork of aniyomi (eg. Kuukiyomi v0. 3.2)
Android version
Android 13
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

I have the same issue :(
For now i am using KickAssAnime extension as the alternative.


INTELLIGENCE

I made changes in section "INTELLIGENCE" under about us.

You are trying to merge this into the MAIN branch.  All changes need to go to the gh-pages branch.


Use ISO from Archive.org for ut1999 instead of buying GOG release

The OldUnreal team now has the permission to distribute the original UT1999 ISO via archive.org, eliminating the need to buy it from GOG and pushing that into the nix store. I changed the source to that ISO file and adapted the package. I also added a nice icon.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Can you add a comment providing a source for the permission to redistribute, as right now it makes it look a bit like we’re just downloading warez in the distribution?

Sure I'll put something there.


OverflowError: bad numeric conversion: positive overflow in dispatchEventQueue

Try to request .SSEA
File "/export/scratch/devel/FlaskRFA/src/service.py", line 15, in procResponse
for u in p.dispatchEventQueue():
OverflowError: bad numeric conversion: positive overflow
<IP_ADDRESS> - - [15/Sep/2017 10:33:13] "GET /?ric=.SSEA HTTP/1.1" 500 -
Everything else seems to work...
I'm using Flask, python 2.7.3 and
pyrfa        8.2.1

It may be safer to dispatch updates just like consumer.py. Second, it is possible that you didn't dispatch events fast enough. If you can send pyrfa.log to<EMAIL_ADDRESS>I will take a look.

Looks like I didn't explain myself well enough:
application works for everything except for this symbol:  .SSEA
Timeout in dispatch doesn't change a thing.
Overflow - it is one item request (snapshot) - not even subscription.

Log:
[MarketPriceHandler::processResponse] MarketPrice Refresh: .SSEA.hEDD
[2017-10-06 09:42:54,218] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
File "/export/scratch/software/python/flaskrfa/lib/python2.7/site-packages/flask/app.py", line 1982, in wsgi_app
response = self.full_dispatch_request()
File "/export/scratch/software/python/flaskrfa/lib/python2.7/site-packages/flask/app.py", line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/export/scratch/software/python/flaskrfa/lib/python2.7/site-packages/flask_cors/extension.py", line 161, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/export/scratch/software/python/flaskrfa/lib/python2.7/site-packages/flask/app.py", line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/export/scratch/software/python/flaskrfa/lib/python2.7/site-packages/flask/app.py", line 1612, in full_dispatch_request
rv = self.dispatch_request()
File "/export/scratch/software/python/flaskrfa/lib/python2.7/site-packages/flask/app.py", line 1598, in dispatch_request
return self.view_functionsrule.endpoint
File "src/service.py", line 55, in home
res = fullRequest(p, ric)
File "src/service.py", line 26, in fullRequest
result = procResponse(p)
File "src/service.py", line 15, in procResponse
for u in p.dispatchEventQueue():
OverflowError: bad numeric conversion: positive overflow

Looks like it could be a data decoding issue for this .SSEA RIC. We don't have this symbol in our lab. Are you able to turn on traceMsg in pyrfa.cfg, e.g.:
\Connections\Connection_RSSL1\traceMsg = true
\Connections\Connection_RSSL1\traceMsgFileName = "./out.txt"

This will enable PyRFA to log incoming data into a file. Then we can investigate which data format that causes this issue.

I have the same issue of this, the ric is "/600085.SS".
The platform is docker offical python 3.7.3 image and pyrfa 8.5.3.
But there is one strange thing. If the develop platform is windows. Everything is ok.
If the platform is linux.  It will throw overflow exception.
The others rics are OK, except the rics of china.
Thanks

Hi, we believe it could be some decoding issue. Can you try simple consumer app just to get this RIC  and set \pyrfa\debug = true just to see when the exception occurs.

issue.txt
Please reference the log file
 updates = p.dispatchEventQueue(100) OverflowError: bad numeric conversion: positive overflow
Thanks

Dear Wiwat:
Is there any plan of this issue?
What kind of information that i can collect?
Thank you.

@Chen-Yi-Cheng is it possible for us to access your IDN_SELECTFEED so we can consume .SS symbols? If so, please contact our<EMAIL_ADDRESS>for access information.


Add support for TcpStream#peek

Method: TcpStream#peek
I have run into an issue that requires the use of this method. I would be happy to get started on a fix, but I'm uncertain on the approach to take. The issue I'm running across is (1) that self is immutably referenced:
pub async fn peek(&self, buf: &mut [u8]) -> io::Result<usize>

This was previously mutable and relied on poll_peek.
The other issue (2) is that turmoil currently implements the ReadHalf and WriteHalf using a tokio::mpsc channel. However, it doesn't look like the Receiver has an option to immutably read the internal lock-free list.
So my question is whether we should paper over the ReadHalf with an internal data structure, try to get this implemented in tokio/chan or some other potential solution I'm missing?

I used interior mutability with a simplified queue/Notify channel for the listener: https://github.com/tokio-rs/turmoil/blob/main/src/net/tcp/listener.rs#L50
Something like this would probably be lowest friction.

I'm closing this as #64 is handling it, and this issue was used to asked questions about how to implement it.


test: Fix node taint test

Previously the test did not correctly check prefixes of pod names, so it always passed. And after finishing, it left the cluster in an inconsistent state, so other tests could fail.
This change adds an Eventually() to AfterEach() to wait until all deployments that were running on the tainted node are ready.

What this PR does
Before this PR:
After this PR:

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

/test all


[Storage] Split concatenated words in the help message

Description
I found some words are concatenated by mistake.
"accessedusing" vs. "accessed using":

az storage blob generate-sas & az storage container generate-sas
Optional Parameters
--cache-control
Response header value for Cache-Control when resource is accessedusing this shared access signature.
--content-disposition
Response header value for Content-Disposition when resource is accessedusing this shared access signature.
--content-encoding
Response header value for Content-Encoding when resource is accessedusing this shared access signature.
--content-language
Response header value for Content-Language when resource is accessedusing this shared access signature.
--content-type
Response header value for Content-Type when resource is accessedusing this shared access signature.

"ofthis" vs. "of this":

az storage blob url
Optional Parameters
--snapshot
An string value that uniquely identifies the snapshot. The value ofthis query parameter indicates the snapshot version.

I fixed them.
History Notes
[Storage] az storage blob generate-sas: Add spaces to split the concatenated words in the help message of the arguments --cache-control, --content-disposition, --content-encoding, --content-language and --content-type.
[Storage] az storage blob url: Add a space to split the concatenated words in the help message of the argument --snapshot.
[Storage] az storage container generate-sas: Add spaces to split the concatenated words in the help message of the arguments --cache-control, --content-disposition, --content-encoding, --content-language and --content-type.

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Storage


Electrolyser fluid output hatch does not show fluid.

Actually has produced, but did not show.
Minecraft version: 1.11.2
Mod version: 1.2.2-22
Forge version: <IP_ADDRESS>3

Confirmed, appears to be network sync issue.


Maintenance: V2 updates - review interface & propose improvements for Validation module

Summary
We should use the V2 release as an opportunity to reflect upon the interfaces of our existing modules and identify areas of improvement. This work has been done as part of rewrites for some modules, and in isolation for others - check out #1283 for details.
Why is this needed?

Minimize the likelihood that we need to make more breaking changes to PT-Java again soon in the future
Double-down on the quality of the project by forcing large-scale code review
Increase knowledge of the modules around the contributor team

Which area does this relate to?
Validation
Solution

A review of the current module, its public interface and structure, and potential areas for improvement documented on this ticket for discussion
A draft PR against the v2 branch showing the high level impact of proposed changes
PR completed and merged into v2

Acknowledgment

[X] This request meets Powertools for AWS Lambda (Java) Tenets
[ ] Should this be considered in other Powertools for AWS Lambda (Java) languages? i.e. Python, TypeScript

We should resolve this and #1298 at the same time.

Happy to take that one


Breakpoint not work with lastest version(1.21.0) of vscode

Issue
In vscode-1.21.0, the breakpoint of editor doesn't work.
vscode info:

Version 1.21.0
Commit 9a199d77c82fcb82f39c68bb33c614af01c111ba
Date 2018-03-07T11:04:09.969Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

node version

v8.9.4

npm version

5.6.0

If I set a breakpoint, it turns grey and never be hit. Then the test fnish executing.

If I use a debugger, it stop perfectly and I could inspect all the information and step into the definition.

Expected behavior
It hit the breakpoint without using debugger.
Output from your debug log
[
  "Reading tsconfig file from path <absolute_path>/ts-jest-vscode-1.21.0/tsconfig.json/tsconfig.json"
]
[
  "Original typescript config before modifications: ",
  {
    "module": 1,
    "removeComments": true,
    "sourceMap": true,
    "downlevelIteration": true,
    "target": 1,
    "lib": [
      "lib.es2015.d.ts"
    ],
    "outDir": "<absolute_path>/ts-jest-vscode-1.21.0/dist"
  }
]
[
  "Reading tsconfig file from path <absolute_path>/ts-jest-vscode-1.21.0/tsconfig.json"
]
[
  "final compilerOptions:",
  {
    "module": 1,
    "removeComments": true,
    "downlevelIteration": true,
    "target": 1,
    "lib": [
      "lib.es2015.d.ts"
    ],
    "inlineSourceMap": true,
    "inlineSources": true,
    "jsx": 2
  }
]
[
  "tsJestConfig: ",
  {}
]
[
  "Using babel with options:",
  {
    "babelrc": false,
    "plugins": [],
    "presets": []
  }
]

Link to a minimal repo that reproduces this issue
Here is the repo.
A command of npm install should be enough for setup.

Just reported this against VS Code instead. See https://github.com/Microsoft/vscode/issues/45448

Adding a reference - https://github.com/Microsoft/vscode/issues/45657#issuecomment-373556464

I'm observing a strange behavior when every other run hits the breakpoint in the fixed 1.22.0-insider VSCode version, while the other runs still don't hit. This seems Jest-specific as I see this progress bar every other run – with this, the breakpoint is not hit.

Also posted in the VSCode issue: https://github.com/Microsoft/vscode/issues/45657#issuecomment-373809426

@borekb does the minimal repo posted above by @Jostar1024 replicate the issue you're seeing?

Yes, actually I reproduce the problem on the minimal repo in 1.22.0-insiders (today's build, i.e., 17 March). I didn't try before because I though that the issue is fixed in this insiders version. So probably there is still some deeper issue than what I reported above.

@Jostar1024 I just tried this and it seemed to work fine. All I did was git clone, cd, and yarn
I'm using vscode version 1.21.1

I'm experiencing the same issue only in certain scenarios so maybe this will help us debug what the issue is. Hopefully, y'all are experiencing similarly.

For vscode 1.21.1 on my mac, the breakpoint does gets hit with the test file with file extension .ts.
For vscode 1.21.1 on my windows 10, the breakpoint does NOT get hit with the test file with file extension .ts.
For vscode 1.21.1 on my windows 10, the breakpoint does get hit with the test file with file extension .js with tsconfig's compiler option of allowJs: true.

Also having the same issue.
Version 1.21.1
Commit 79b44aa704ce542d8ca4a3cc44cfca566e7720f1
Date 2018-03-14T14:46:47.128Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64


VRchat controls are wrong when using the Quest.

the stick are gestures controls not moving.
i have to click in to move. is there a fix for this?

For Oculus Quest you can try JackD83's fork.
It works only with Quest, and it has several Quest specific improvements.

thanks


⚠ Bofrost.be has degraded performance

In bebc76d, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 977 ms

Resolved: Bofrost.be performance has improved in 7cee29b.


macOS keep screen awake seems backwards

It looks like the code for keeping the screen awake is backwards. See the details for caffinate:
-d      Create an assertion to prevent the display from sleeping
And the code (ARGS is -d -u):
    if keep_screen_awake:
        global _process
        _process = Popen([COMMAND], stdin=PIPE, stdout=PIPE)
    else:
        _process = Popen([COMMAND] + ARGS, stdin=PIPE, stdout=PIPE)

It's sending -d -u if we do NOT want to keep the screen awake. I'll send a PR.

Yeah I think it looks like it is backwards as you said. One thing I also consider from
   -u      Create an assertion to declare that user is active.
           If the display is off, this option turns the display on and prevents the display from going
           into idle sleep. If a timeout is not specified with '-t' option, then this assertion is
           taken with a default of 5 second timeout.

Is says that the -u flag has by default timeout of 5 seconds. Perhaps there should be something like -t 999999 added? (~11.5days)

Released as part of wakepy 0.4.4 on PyPI. Thanks for reporting and providing PR!

very nice, thanks!
Best,
Michael
Sent via Superhuman @.***>
On Mon, Aug 30, 2021 at 10:48 AM, Niko Pasanen @.***>
wrote:

Released as part of wakepy 0.4.4 on PyPI. Thanks for reporting and
providing PR!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/np-8/wakepy/issues/13#issuecomment-908553682, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPQ62IIIIQIP4ONEUSM4G3T7O76ZANCNFSM5DCHVY2Q
.


fix Fix static type dispatch by mistake due to typo (#42260)

What problem does this PR solve?
Problem Summary:
DeletePredicatePB should be DeleteSubPredicatePB.
Test case is too ambiguous to add, since this bug is triggered by a huge random test and failed to find the minimal case. However, this fix is verified under the wild test that it does works.
Note that this problem may be triggered by another bug, cuz schema in delete predicate rowset should contain column referred in delete condition. Even if we don't have this fix, this error should never happend.
But this error occurred under wild tests, means that schema in delete predicate rowset is not adaptable with delete condition. I think it is under some status that delete operation use BE tablet schema rather than schema from FE, and the former rename operation result in that status. But I failed to add a test case to reproduce, and think that by no way will it happend occurding to the related code.
(1105, 'errCode = 2, detailMessage = ([<IP_ADDRESS>](http://<IP_ADDRESS>/))[INTERNAL_ERROR]failed to initialize storage reader. tablet=78026, res=[INTERNAL_ERROR]column not found, name=loc1, table_id=-1, schema_version=2

\t0#  doris::TabletSchema::column(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:375
\t1#  doris::Status doris::DeleteHandler::_parse_column_pred<doris::DeleteSubPredicatePB>(std::shared_ptr<doris::TabletSchema>, std::shared_ptr<doris::TabletSchema>, google::protobuf::RepeatedPtrField<doris::DeleteSubPredicatePB> const&, doris::DeleteConditions*) at /home/zcp/repo_center/doris_master/doris/be/src/util/expected.hpp:1986
\t2#  doris::DeleteHandler::init(std::shared_ptr<doris::TabletSchema>, std::vector<std::shared_ptr<doris::RowsetMeta>, std::allocator<std::shared_ptr<doris::RowsetMeta> > > const&, long) at /var/local/ldb-toolchain/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:701
\t3#  doris::TabletReader::_init_delete_condition(doris::TabletReader::ReaderParams const&) at /var/local/ldb-toolchain/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:701
\t4#  doris::TabletReader::_init_params(doris::TabletReader::ReaderParams const&) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t5#  doris::TabletReader::init(doris::TabletReader::ReaderParams const&) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t6#  doris::vectorized::BlockReader::init(doris::TabletReader::ReaderParams const&) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t7#  doris::vectorized::NewOlapScanner::open(doris::RuntimeState*) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t8#  doris::vectorized::ScannerScheduler::_scanner_scan(std::shared_ptr<doris::vectorized::ScannerContext>, std::shared_ptr<doris::vectorized::ScanTask>) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:388
\t9#  std::_Function_handler<void (), doris::vectorized::ScannerScheduler::submit(std::shared_ptr<doris::vectorized::ScannerContext>, std::shared_ptr<doris::vectorized::ScanTask>)::$_1::operator()() const::{lambda()#1}>::_M_invoke(std::_Any_data const&) at /var/local/ldb-toolchain/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:701
\t10# doris::ThreadPool::dispatch_thread() at /home/zcp/repo_center/doris_master/doris/be/src/util/threadpool.cpp:0
\t11# doris::Thread::supervise_thread(void*) at /var/local/ldb-toolchain/bin/../usr/include/pthread.h:562
\t12# ?
\t13# ?
, backend=[<IP_ADDRESS>](http://<IP_ADDRESS>/)')

auto tablet_schema = std::make_shared<TabletSchema>();
    tablet_schema->copy_from(*tablet->tablet_schema());
    if (!request.columns_desc.empty() && request.columns_desc[0].col_unique_id >= 0) {
        tablet_schema->clear_columns();
        // TODO(lhy) handle variant
        for (const auto& column_desc : request.columns_desc) {
            tablet_schema->append_column(TabletColumn(column_desc));
        }
    }
    RowsetSharedPtr rowset_to_add;
    // writes
    res = _convert_v2(tablet, &rowset_to_add, tablet_schema, push_type);
    if (!res.ok()) {
        LOG(WARNING) << "fail to convert tmp file when realtime push. res=" << res
                     << ", failed to process realtime push."
                     << ", tablet=" << tablet->tablet_id()
                     << ", transaction_id=" << request.transaction_id;

        Status rollback_status = _engine.txn_manager()->rollback_txn(request.partition_id, *tablet,
                                                                     request.transaction_id);
        // has to check rollback status to ensure not delete a committed rowset
        if (rollback_status.ok()) {
            _engine.add_unused_rowset(rowset_to_add);
        }
        return res;
    }

    // add pending data to tablet

    if (push_type == PushType::PUSH_FOR_DELETE) {
        rowset_to_add->rowset_meta()->set_delete_predicate(std::move(del_preds.front()));
        del_preds.pop();
    }

Release note
Make delete predicate work with column uid correctly.
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[x] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[x] No.
[ ] Yes.

Does this need documentation?

[x] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall

run buildall


Wifi client

Hi, I can not connect to my Wifi, after save and reboot he is still in AP mode.
version 0.5.3

Hello,
the problem is that you have to connect PIN 16 with logical 1, so that means 3v3 or 5V, I am using the ESP12 and i have 5V connected there.

Thank you it works :)

hey, same problem with the new version 0.6.1 he will stay in ap mode.
is there another solution?

Are you sure D0 is high enough? Because i did not reproduce this issue.

No idea where the problem was, now it works again.


New stuff to get rid of on profile pages

Just noticed this on this profile today https://twitter.com/DudespostingWs

Looks like this feature was recently killed by Twitter


Allow setting channel, icon_emoji, usage of app-icon, bot name, and username.

Allow setting channel, icon_emoji, bot name, usage of app-icon, and username by app.
Use android-versions node module for getting android semver.

If you're cool with these changes can we do a merge?
I apparently can't use my own branch 😞  because when I try to install it there is an error with linking the binary:
> mkdir reviewmetest
> cd reviewmetest
> npm init
> npm install --save git://github.com/dvoiss/ReviewMe
npm WARN deprecated<EMAIL_ADDRESS>ReDoS vulnerability parsing Set-Cookie https://nodesecurity.io/advisories/130
npm WARN deprecated<EMAIL_ADDRESS>Use uuid module instead
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.

npm ERR! path<EMAIL_ADDRESS>npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod
npm ERR! enoent ENOENT: no such file or directory, chmod<EMAIL_ADDRESS>npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

I've just published 1.0.4 with these changes. Thanks for your contribution!


improving pages in profile dropdown

Related Issue
None
Fixes:  #4610
Description
I have enhanced the appearance of edit profile and my profile pages and corrected the links in profile page.
Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
before and after:
https://github.com/user-attachments/assets/9fa46046-1610-4877-88b9-1e54ad062480
Checklist:

[x] I have made this change from my own.
[x] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

should i work on the help page in profile dropdown?

nice , just fix the home button on top right corner of the page . and its [My Profile]

remove this footer , just keep the part below the horizontal line .

nice , just fix the home button on top right corner of the page . and its [My Profile]

what do you want me to change there? i didnt quite get it

https://github.com/user-attachments/assets/250f6ff8-d209-4145-b5ad-4fadce4b7c31


URL not found on server

Running slexil on new machine (Mac Book Pro), the "display web page" button triggers an error "URL not found on this server". But the text.html file is there and works fine, and I didn't have this problem before, on the other machine (iMac). I don't see why the computer would matter though, the directory structure is the same on both (slexil > PROJECTS > Inferno, with slexil as the current working directory).

Sorry for the trouble, David.  Please open the javascript console, then paste all you can grab from the error message into this issue.  The URL will be re-presented there.  What happnens if you paste that into another brower?   Please add all the detail you can, including browser version and OS.

Paul

On Feb 18, 2019, at 6:48 AM, David Beck<EMAIL_ADDRESS>wrote:
Running slexil on new machine (Mac Book Pro), the "display web page" button triggers an error "URL not found on this server". But the text.html file is there and works fine, and I didn't have this problem before, on the other machine (iMac). I don't see why the computer would matter though, the directory structure is the same on both (slexil > PROJECTS > Inferno, with slexil as the current working directory).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I just tried to recreate the error and it is working now. Just one of those many things, I guess


Added book 6 - The graduate

Added Book 6 - the graduate
Contains 3 chapters with various resources for students to refer to after graduating.
Let me know what you think! @stevebrownlee @JoeShep @jisie @askingalot

@askingalot Thanks for the comments! I've updated based on your suggestions.

@JoeShep no worries! I removed that line :)

@kimberly-bird I'd still be happy to contribute to this in some way. So let's talk

Closing this ticket as it was decided to create a separate repository to hold this information
https://github.com/nashville-software-school/the-graduate


[exec] add a timeout option

It would be super useful to be able to have a timeout on the exec node. If the execution takes more than X time, then kill the process for example.

Hi,
in general we prefer to raise and discuss ideas on the Google group unless there is an actual issue, but this does seem like a sensible thing to consider.

This has been added to the 0.14.0 branch by this commit: bd59398cab675f9d750b734f95294e986fbbb92d


Add Central side SensorEvent hash

Description
Add the same sensor event hash that is on the sensor side to Central, which will help when Sensor restarts. For backwards compatibility, this will be computed on Central if it does not exist from an older Sensor.
There is a bug in sensor for roles and role bindings so those aren't adequately deduped, but I'll clean that up in a follow up
Diff between what Central has processed before and after a sensor bounce. Lower change is good
sensor_event_queue Operation=Add Type=ClusterStatusUpdate (old: 6.00, new 8.00): change: 33.3333%
sensor_event_queue Operation=Add Type=ImageIntegration (old: 3.00, new 4.00): change: 33.3333%
sensor_event_queue Operation=Add Type=Deployment (old: 175.00, new 217.00): change: 24.0000%
sensor_event_queue Operation=Add Type=Event (old: 2394.00, new 2932.00): change: 22.4728%
sensor_event_queue Operation=Add Type=NetworkFlowUpdate (old: 13.00, new 14.00): change: 7.6923%
sensor_event_queue Operation=Add Type=ClusterHealthInfo (old: 43.00, new 46.00): change: 6.9767%
sensor_event_queue Operation=Add Type=Pod (old: 71.00, new 74.00): change: 4.2254%
sensor_event_queue Operation=Add Type=ProcessIndicator (old: 537.00, new 538.00): change: 0.1862%
sensor_event_queue Operation=Add Type=ServiceAccount (old: 60.00, new 60.00): change: 0.0000%
sensor_event_queue Operation=Add Type=Secret (old: 18.00, new 18.00): change: 0.0000%
sensor_event_queue Operation=Add Type=Role (old: 137.00, new 137.00): change: 0.0000%
sensor_event_queue Operation=Add Type=Node (old: 3.00, new 3.00): change: 0.0000%
sensor_event_queue Operation=Add Type=NetworkPolicy (old: 10.00, new 10.00): change: 0.0000%
sensor_event_queue Operation=Add Type=Namespace (old: 5.00, new 5.00): change: 0.0000%
sensor_event_queue Operation=Add Type=ClusterMetrics (old: 4.00, new 4.00): change: 0.0000%
sensor_event_queue Operation=Add Type=Binding (old: 513.00, new 513.00): change: 0.0000%
sensor_event_queue Operation=Add Type=AlertResults (old: 49.00, new 49.00): change: 0.0000%

Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Will post the stats here once I get it built and deployed. Also, going to add some metrics from scale testing

@mtodor I think I answered your concerns. See slack for more in-depth breakdown of the scale concerns

@fredrb @lvalerom I added you guys as this has a couple of changes that have sensor<->central implications. Let me know what you think

@fredrb Good call, note everything in central proto should not be serialized using jsonpb and is just serialized proto, but the compatibility tests are good :)


Runtime Error while roslaunch

Hello. While I study your github, i met an issue.
When roslaunch openpcdet 3d_object_detector.launch, I met this error
[ERROR] [1704847291.653335]: bad callback: <function rslidar_callback at 0x7f4c0023ba60>
Traceback (most recent call last):
File "/opt/ros/noetic/lib/python3/dist-packages/rospy/topics.py", line 750, in _invoke_callback
cb(msg)
File "/home/park/catkin_ws/src/OpenPCDet_ros/src/inference.py", line 95, in rslidar_callback
scores, dt_box_lidar, types, pred_dict = proc_1.run(np_p, frame)
File "/home/park/catkin_ws/src/OpenPCDet_ros/src/inference.py", line 220, in run
pred_dicts, _ = self.net.forward(data_dict)
File "/home/park/catkin_ws/src/OpenPCDet/pcdet/models/detectors/pv_rcnn.py", line 11, in forward
batch_dict = cur_module(batch_dict)
File "/home/park/.local/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1130, in _call_impl
return forward_call(*input, **kwargs)
File "/home/park/catkin_ws/src/OpenPCDet/pcdet/models/backbones_2d/base_bev_backbone.py", line 103, in forward
x = torch.cat(ups, dim=1)
RuntimeError: Sizes of tensors must match except in dimension 1. Expected size 225 but got size 226 for tensor number 1 in the list.
How can i solve it?

Hello. Before I solve this problem.
But I change the computer environment and met this issue.
I forgot method to solve this problem. Can you help me?

@pkbeen Hello! how can you fix this problem?


Random-Color-Generator

Develop a Javascript {Random-Color-Generator} app.
Description 📜
Add description for your project here...
Requirements 🛠

Add requirements for your project.
Example:
What the app must-haves.
What the app can-haves.
What additional can be added.

Bonuses ✨

Add tasks that are challenging.
App can have this thing.
Developers can also add this to the app.
It will be great if App has this.

Any number of people can work on a single issue 👨💻👨💻
This issue is open to all.🌍

Project location 👉🏻 {Random-Color-Generator}/Username/
👨🏻💻 Happy Coding 👩🏻💻

Please assign me this issue

Could you please assign it to me, I have worked on this before

could you please  assign this issue to me I've worked on it before

can i work on this issue


(3.7.0) Pressing next on pre-raid screen takes you to same screen

pressing next a second time take you to correct screen

Originally written by chomp

fixed with https://dev.sp-tarkov.com/SPT-AKI/Modules/commit/d4d489f329d811557ce04ab6552ab6350dc67c0d

Originally written by CWX


calcpy_cli.py: fix deprecation error on threading.current_thread()

Hi again,
Your fix 42f9c166e26df216a94aa110c4477ef41c2a832c causes a deprecation warning:
/home/dogeystamp/.local/bin/calcpy/calcpy_cli.py:70: DeprecationWarning: currentThread() is deprecated, use current_thread() instead

When vim-mode is activated, this warning is produced every time the prompt is shown.
This patch uses the updated name for the method.
I am using Python 3.11.4.

Looks good, thank you!
I see that DeprecationWarning is ignored by default, but this fix is good anyway.


E2E Tests

Thanks a lot for this work @hsouf, it will make our E2E tests way more stable. I think we can merge this PR on main, no need to add it to the audit branch since it does not edit the contracts.


ci: Fixed actions order for 'SonarCloud and Mutation Tests'

Description
copilot:summary
Related Issue

Explanation of Changes
copilot:walkthrough
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] Implemented tests for new features.
[ ] I tested the features already implemented.
[ ] Added usage examples in the readme.

:tada: This PR is included in version 1.8.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Rename tx.blocking_early to tx.early_blocking

Motivation
The feature is called early blocking, yet the variable is called blocking_early. We should keep both in sync and given we have not released this yet, we can change so immediately.

Fixed in #2414.


LineEdit's cursor sometimes disappears when set scale.X < 1

Godot version:
3.2.4 beta3
OS/device including version:
win10 / rx5700 GLES3
Issue description:
LineEdit's cursor sometimes disappears when set scale.X < 1
using custom font:  .fnt + .png

Duplicate of https://github.com/godotengine/godot/issues/24207 ?

I can confirm this issue on MacOS but my case is when scale is setted to < 0.9

Duplicate of https://github.com/godotengine/godot/issues/24207 (same cause).


Projected file size

Is it 'possible/too difficult' to put an extra information on Staxrip log window displaying projected file size?
I mean beside eta captions, at that point:

This is important because when encoding large files, I could preview if size is acceptable or I have to abort encoding and start it again after change video quality by crf value.
As you might know, Virtualdub has that:

This status line is the output of the encoder without modification. Parsing this decreases impacts performance so it's a bit problematic, furthermore staxrip would need to read the file size which also is problematic. You could ask in the x265 thread if anybody else would find it useful.
https://forum.doom9.org/showthread.php?t=168814&page=267

Got it.
Fair enough.
Thanks.


AutoTVM: selecting tuning templates when extracting task

Make the procedure of trying new templates easier.
Would you please have a look at this @eqy @merrymercy @tmoreau89 @vinx13

Thank you for the review @comaniac @tmoreau89 @vinx13 , really good points to have a dict holding the op to key mapping! I will update correspondingly.

Thank you for the quick look @comaniac ! Now updated.

Thanks. LGTM.
btw, would you update the tutorial as well?

Thank you @comaniac ! I will update the tutorials in another PR.
@tmoreau89 @vinx13 Would you like to have a look please :)

Thanks @jackwish @comaniac @tmoreau89 this is merged


Implement ES6 Promise support

Work in progress.
Implement support for ES6+ Promises.  Promises allow async code to be written in a linear fashion like sync code.
Checklist:

[ ] Implement Promise, all ES7 bindings
[ ] C API for promises?
[ ] Promise.prototype.done()?  Investigate pros and cons, as many devs dislike it
[ ] If async resolve implemented here, need an API to dispatch Jobs, e.g. duk_perform_jobs()
[ ] Testcases
[ ] RELEASES entry

Cool stuff :)

One feature I'm considering beyond the core ES6 functionality is Promise#done() support.  Normally if an exception is thrown within a promise chain and it is not handled by a .catch() then it gets eaten.  Putting .done() at the end of the chain ensures any uncaught error will propagate out of the promise.  It's useful enough to be a de facto standard feature in third-party promise libraries, despite not appearing in any formal specification.

Hmm, at least Bluebird recommends against using .done():

Like .then, but any unhandled rejection that ends up here will crash the process (in node) or be thrown as an error (in browsers). The use of this method is heavily discouraged and it only exists for historical reasons.

Not sure why, at first glance it seems like a useful feature for making "oops" situations more apparent.

I personally have had to debug situations in C# using async/await where thrown errors have gotten eaten by the async harness.    I'd rather have the process crash than not see the effects of the bug until it's too late to trace the cause.

I don't disagree about that, but I wonder why it's not recommended in Bluebird - has it maybe been replaced by something newer?

Found this after a bit of Googling:
https://github.com/domenic/promises-unwrapping/issues/19
It seems that .done() was going to be in ES6, but was ultimately left out.  The expectation is that dev tools will add functionality to report and/or intercept rejected promises so that .done() is not needed.

Seems to be there are several issues with .done(), and I'd need to dig deeper to understand them. One issue seems to be that "no one handled an error" is not known reliably at any point in time because handlers may be attached at any point, even after the Promise has been resolved.
There is one point where that is reasonably well defined, and that is at GC time: if an error hasn't been handled by then, it never will (modulo rescuing etc).
The idea that promises are debugged via a debug console doesn't work all that well for embedded environments. So if any promise diagnostics are implemented they should probably be e.g. custom callbacks which are called when interesting events (like unhandled errors) occur.

I assume that hypothetical GC check is the reason why ES7 (but not ES6, interestingly) specifies a [[PromiseIsHandled]] internal slot (= whether anyone ever called .then()).

I'm going to have to go back to the drawing board on this one.  While Promises can readily be implemented within the constraints of an ES5 engine, it will need some thought as to the best way to do so in practice.
The main issue is that Promises rely pretty heavily on closures (conceptually at least), which is difficult to mimic with the value stack mechanism.  It's clear that the monolithic design currently used in this pull is not going to work.
What might work better is use the specification primitives as a starting point - only combining them later on if that makes sense.

Hmm, so what is the concrete problem with closures - aren't Promise function arguments ordinary function instances, and those reference can be stored for later calling?

Right, the functions have to refer back to the promise object so that calling them resolves it.  For .then() you also need to link the two promises so that the resolution of the first one ultimately resolves the second.  In JS with real closures all that is implicit.  But in C, you end up doing a lot of manual value stack balancing and you don't want to inline all that or else footprint starts going up quickly.

If it helps to illustrate, this is a fairly typical Promises/A+ implementation in JS:
https://github.com/fatcerberus/minisphere/blob/master/assets/system/polyfills.js#L5-L164

I don't understand what you mean by "it is implicit" - for example, if .then() is called it gets a this binding and arguments. The .then() implementation isn't aware of the scope where the call occurs and cannot see variables there.

Or do you mean that an Ecmascript .then() implementation itself can take advantage of closures?

If the latter, I think a natural implementation in C would be quite different. For example, the connections between promises would be handled as internal properties rather than variables in a scope.

Right, JS natively has closures so then() can take advantage of it.

For example, the connections between promises would be handled as internal properties rather than variables in a scope.

Indeed, which is what I meant above that constantly inlining all those internal property accesses, with associated stack balancing, was bad for footprint.
All I was getting at above was that I wanted to start over and reevaluate the best way to divide up the helpers so that redundant code is eliminated.  I started out with a very monolithic design that got way out of hand very quickly.
To be clear I wasn't soliciting advice - just giving a progress update :)

Fair enough :) I'm quite interested in getting the promises integrated as well as possible (especially for footprint, as you might imagine). It only really makes sense to write promise support in C if it's significantly faster and/or smaller.

Also interesting is how the C API should support promises (if at all). That might have some impact on the implementation. But we can merge an initial implementation and then rework if it turns out to be necessary.

I know this is work in progress but just a quick comment on the internal duk__promise struct: duk_tval values in structs are not visible to GC so if they're used, they must be borrowed references (not reference counted) and their lifeycle must be exactly correct (= shorter than the strongly reachable counterparts). Internal properties are a bit easier because they're visible to GC.
It's of course possible to make the GC understand the structure. So far I've tried to avoid this (opting to use internal properties instead) but it may be that the GC needs some modularity to more flexibly adapt to structs like this.

I was indeed aware the tvals are borrowed.  They are stored as internal properties on the promise object to keep them reachable, I just keep a copy of the duk_tval around to avoid having to duk_push_this() + duk_get_prop_string() all the time.
That said, it would be convenient if one could "pin" a duk_tval without having to actually store it as a property... :)

I'd be a bit hesitant in using borrowed references like that: if the internal properties are edited from C code it may cause a segfault. There are some other cases like this in the current code base too (e.g. type assumptions) but I'd like to avoid making more and fixing the existing assumptions too. It'd be fine to misbehave in a memory safe manner if the properties are edited though.

Pinning is also very dangerous because unless the unpinning is automatic and intuitive, it's then very easy to leak memory. Which is not as bad as a straight segfault, but close especially on low memory targets. Leaking is even more difficult to figure out in the field. That's why I'm not very excited about pinning as an API design because: it will get misused.
But there are various solutions besides borrowed references and pinning, e.g. some form of GC interaction which allows you to extend the reachability graph in a modular fashion. Or requiring that when something is pinned, the "pinning" must be associated with an object and unpinning is then handled automatically (which is not far from GC interaction but implemented in a different way).

I'll probably get rid of the borrowed references in the rewrite, mostly it was done to reduce a lot of repeated property accesses, but helpers are probably a much better solution for that.
Regarding this:

Pinning is also very dangerous because unless the unpinning is automatic and intuitive, it's then very easy to leak memory.

That's true, but then again the stash(es) have this issue as well - if an app stashed something for later use and then forgets to remove it, it will be leaked.  And manipulating stashed properties requires some value stack movement that a simple pin/unpin API wouldn't... :)

I agree about the stashes - though it is a bit more simple to ask (and answer) "do you have a reference in the stash?" vs. "have you pinned an object and potentially failed to unpin it at some point?". For example, if you do a debug dump of stash keys you can easily see if a reference exists. How do you dump "active pins"? That might need another API, and so on... :)
But yes, there are no easy alternatives I'm afraid. "Automatic unpinning" is an odd concept because if it could be automated, why would pinning be needed in the first place. Doing automatic unpinning when a base reference is released is essentially doing weak references so it's better to implement them rather than some form of clever pinning.
Note that I'm not at all trying to argue something shouldn't be added to make things easier to manage. It's just that the most obvious easy solutions are not actually easy :)

Speaking of weak references, that reminds me that WeakMap was another ES6 thing I wanted to look into.

Maps and sets are not an easy change because they have GC interactions, and there's also some potential to reuse some code between maps, sets, and plain objects (or not, depending on what works best). I've done some prototyping on these but so far no approach has been the obviously right one; for example, there are designs which work well when there are relatively few maps and sets (minimizes footprint) but don't work well when there are a lot of them (non-optimal RAM usage).
It'd also be good to get some of the pending work merged before taking on more ES6 stuff.

It'd also be good to get some of the pending work merged before taking on more ES6 stuff.

Agreed.  For my part I should try to get at least #1025 polished off, that'll save me from having to write a Reflect polyfill for minisphere. :)

Now that my attention is not divided between this and Reflect, maybe I'll see if I can draft up a cleaner solution for this tonight.

I revisited the pull and cleaned some things up.  Now that I have some more experience implementing built-ins, this is going much more smoothly. :)
It's still buggy though.  For example here only the first .then() will execute:
Promise.resolve("It's 8:12, do you know where your existence is? *munch*")
	.then(function(value) { console.log(value); return "STUPID PIG!"; })
	.then(function(value) { console.log(value); });

But it's a start.

Hm, it seems that ES6/7 is defined in terms of the implementation being fully async.  Not only Promise settlement but script execution is assumed to be handled in the event loop, see:
http://www.ecma-international.org/ecma-262/7.0/#sec-jobs-and-job-queues
Implementing these semantics requires some architectural changes that I don't think I'm prepared to take on at this point.  I'll close this pull; I believe it'd be best to wait until some other ES6 reworks have been done first.

@svaarala I'll keep hacking on this in my spare time, but I don't want there to be any pressure to merge, so I closed the pull until I have something more substantial to show.
I might open a separate issue to discuss implementation options and such for Promises, though.

Ok, sounds good.
Re: that eventloop thing, it'd be interesting to figure out if the need for an event queue could be generalized to some extent so that it would handle Promises but would also make it easy to integrate timers and maybe user custom events into the same mechanism. The event queue model is also used by browsers so while it's not a part of the core Ecmascript model, it's still fairly common.
For the C API there's maybe be an API call to handle one queued event or indicate all events are done. There would also need to be a way to push events-to-be-handled into the queue, preferably from C code (which would be exercised by the Promise implementation).


Remove cache files

Delete the two cache directories and add them to .gitignore
.jekyll-cache/
.sass-cache/

Here is my template file
https://github.com/MichaelCurrin/jekyll-blog-demo/blob/master/.gitignore
It includes ignoring the vendor and bundler directories relating to installing gems with bundler.

I was thinking I could drop those! thanks for the confirmation!

The update looks good.


Update tournament hud

I'm going to update this based on a the #base method as I imagine there will be many more changes in the future come matchmaking.


SOL_NO_MEMORY_ALIGNMENT is SOL_ON by default!

Documentation on SOL_NO_MEMORY_ALIGNMENT says

Not turned on by default under any settings: this MUST be turned on manually

However, //include/sol/version.hpp has it SOL_ON by default:
#if defined (SOL_NO_MEMORY_ALIGNMENT)
	#if (SOL_NO_MEMORY_ALIGNMENT != 0)
		#define SOL_ALIGN_MEMORY_I_ SOL_OFF
	#else
		#define SOL_ALIGN_MEMORY_I_ SOL_ON
	#endif
#else
	#define SOL_ALIGN_MEMORY_I_ SOL_DEFAULT_ON
#endif

Oh. That's hella wrong: my bad.

I think there is no error.
SOL_ALIGN_MEMORY_I_ is on by default, not a SOL_NO_MEMORY_ALIGNMENT that is opposite.

I was looking at the branch inside #if defined(SOL_NO_MEMORY_ALIGNMENT), but looking it over again I think that's right too.
I guess we'll all okay then!

@Smertig / @ThePhD In that case should the documentation be updated to reflect the fact that SOL_NO_MEMORY_ALIGNMENT is not ON by default?

Ah, sorry. We're not being very clear here. The config you define, as a user, is SOL_NO_MEMORY_ALIGNMENT. That is, "please turn off memory alignment". Memory alignment is on by default: the configuration parameter inside is "Please USE memory alignment". It's the opposite of what the user defines. That's why it shows up like it does: the internal one is SOL_ALIGN_MEMORY_I_, which is why it defaults to SOL_DEFAULT_ON.

Thanks for the explanation @ThePhD!


Qt platform plugin is not found even though i already install it

For some reason I keep getting this message saying Qt platform plugin is not found I'm not sure why even though I just installed it today. I'm not sure if I deleted something I was not supposed to delete yesterday because I was clearing out my storage. I'm not sure if I downloaded the wrong Qt platform too or it is simply just a bug

Can you provide some additional details?

Please provide the terminal output
Windows or Linux?
Do you notice any problems outside of the message?

Terminal output: qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
I use window
and no I do not notice any problems outside the message

I suspect either of the following could be the problem:

You are running the application without unzipping
You moved/removed required files

To fix the problem, do one of the following:

Download the .msi installer to install/reinstall the application
Download the Windows zip file and extract the entire contents to its own directory. Leave the contents of that directory alone, and do not move/remove any files.

If the application behaves as normal, you can ignore the message.

I downloaded the msi and it worked thanks while we are here there one more bug i forgot to mention. for some reason the track location does not work and this happened before i clear my storage. I checked the location setting in my pc and it said supercellwx was using my location but it just wont appear on the map

And the REF wont show up too the VEL also don't work

I downloaded the msi and it worked thanks while we are here there one more bug i forgot to mention. for some reason the track location does not work and this happened before i clear my storage. I checked the location setting in my pc and it said supercellwx was using my location but it just wont appear on the map

If you zoom way out, you may see an icon in an unexpected location. Windows location services can be pretty inaccurate. The development snapshot allows you to connect to an external GPS device for higher accuracy.

And the REF wont show up too the VEL also don't work

REF and VEL should be functional. I need additional information from the terminal (preferably a full dump). Radar site and date/time are helpful.

When I zoom out I don't even see it
Im using level 3

When I zoom out I don't even see it

In this case, Windows is not providing an accurate location.

Im using level 3

I need the additional requested information to investigate further. Level 3 works for me.

I fixed the REF and VEl problem the color files was broken so everything just stayed blank I will redownload the color files tomorrow thanks for the help!

Also for the track location it used to work but now it don't so I will just have to find a way to fix it somehow