Santiy Checking the Boundary Seeking ICCEA

The MTQ benchmark problem will act as the first step. To run the benchmark problem simply run the following command:
python3 run_iccea_mtq.py
To modify the search parameters you can change them in benchmark/mtq/search_config.py.
To modify the boundary, you can change the value at the end of the joint_fitness_mtq() function located in benchmark/mtq/problem.py. Kindly note that the joint fitness function does not return the actual joint fitness value in the updated version of the ICCEA, rather it returns the value of the safety_req_value attribute of the complete solution.

What I did
So, I found three different issues, addressed in the following commits:
4af1f3b33ed3875b7d504260e12c5fc10aaf85dd
This is to fix a bug in calculating the safety_req_value value of each complete solution. Previously, the value was zero for all complete solutions since the map() function you used did not properly save the results in the corresponding field.
698f59565f10d749a0d1b7b5aa8878c310c53727
This is to reduce the "radius" (i.e., max_dist) of a cs_region; since 0.5 was too large, the search does not make fine-grained movements and is easily stuck in some regions.
eebc72f9ff57df4a77e39e0e291849e5d2a6352f
This is to make the MTQ problem "solvable". Previously, use used h2= 150 but s_2 = 1.0/32.0, meaning that it is very challenging to find the peak of h2 on a very small surface (1/32). So, I simply swapped h1 and h2 to make the problem easier to solve.
New result and its interpretation
This is the full log: 20220609_160328_CCEA_MTQ.log
As you can see, we have reached the fitness score of 0.9735897570338863.
Using the final solution x, y = [0.5853844653731718], [0.894080760273642], the function compute_safety_req_value() returns -21.786309582260785, which is quite close to 0.
In fact, on different runs, I found x, y = [0.6182038195955862], [0.8721837981696042], resulting the return value of compute_safety_req_value() only 1.5513294434849598.
Since the positive return value of compute_safety_req_value() indicates "safe" and the negative one indicates "unsafe", the return value of zero indicates the "boundary". Therefore, we can say that the algorithm successfully found a complete solution (x, y) that lies near the boundary.
To conclude, the sanity check is passed, but it turned out that max_dist should be carefully tuned for a given problem

#Hi, I managed to get the new setup working on Pylot+Carla. As you mentioned, the size of the region for joint fitness evaluations is important. The general behavior of the algorithm seems to be reasonable and it follows the general fitness improvement behavior.
What I did
To make the algorithm work with Pylot, aside from mirroring the changes in MTQ to Pylot's problem files, the returned values from the simulation had to be modified in the following manner: previously the values varied between 0 and 1, where 1 corresponded to no deviation, whereas 0 meant violation of the safety limit. To ensure the sign changes in case of violation, -1 will be returned instead of 1, but the rest remains the same. For instance, it does not matter how close to violation the complete solution is, as long as it has not violated the safety limit, it would have a positive value. In case of violation, we do not measure how much violation occurs and the value of -1 is returned. The reason for this decision is due to nature of the safety violation. In rough terms, if a safety violation occurs, it is game over and measuring how much violation has happened is not reasonable. However, violations can be differentiated based on their severity, for instance, crashing into a person is much more severe than crashing into a lamp post. However, for a single safety requirement, all violations can be seen as equal. Nevertheless, to improve our search algorithm, we might want to use a threshold to count a value as a violation rather than only focusing on 0.
Here is a log of a test run: 20220613_171322_CCEA.log
The attached log is for the test run No. 5. In this test run, interestingly, a bug with the mutate_mlco() was discovered. After breeding, the following mlco was created:
mlco=[[[0, 0, 0, 0.0, 50.0, 0.0, 50.0, 0.0, 50.0, 0.0, 50.0], [1, 0, 0, 0.0, 50.0, 0.0, 50.0, 0.0, 50.0, 0.101, 50.101]]. Such an mlco would lead to a ZeroDivisionError, since the start and end times are 0. Hopefully, commit e8b3ef43f54d829cfabc7f8eae76712ca6c879f9 addresses this issue at ln.201 of problem_utils.py. Related to this issue, I realized that the test_mutate_mlco() unit test is flakey, for which issue #40 is opened.
Conclusion
We can conclude the setup is reasonably working. However, due to the importance of the effort, your review of the updated code is much appreciated. To review the code, pull the latest commit and run python3 run_iccea.py. Kindly note that you can modify the search parameters in ./search_config.py.
If your review is satisfactory, then the last step before focusing on evaluations would be to parallelize the simulations, please see issue #39 .

In case of violation, we do not measure how much violation occurs and the value of -1 is returned. The reason for this decision is due to nature of the safety violation. In rough terms, if a safety violation occurs, it is game over and measuring how much violation has happened is not reasonable.

Okay, sounds reasonable. Also, since our current fitness evaluation only counts for the number of safe and unsafe complete solutions, it is enough to distinguish between safe and unsafe complete solutions without considering the degree of safety violations.

We can conclude the setup is reasonably working. However, due to the importance of the effort, your review of the updated code is much appreciated.

Okay, I will review the commits now. Thanks.

I made some improvements in mutate_time() and test_mutate_time()` in this commit: 66fa7881c12eb2212f4e514e4a41be3eebf82fed.
I couldn't look at the other code, but I can do it tomorrow morning if you want. Otherwise, feel free to go ahead if you already feel it's good to try to run. :-)

Hi, I ran an MTQ for 100 generations.  I will think about it more and write my thoughts on it in later comments. But in short, it seems the algorithm is going towards the higher fitness value. Nevertheless, I am not sure why the maximum fitness drops even a bit given our update archive strategy. I will try this with the alternative strategies that always keep the best individual and report the results here.

Before moving on to evaluations, I ran a test run for multiple hours and discovered inconsistent behavior in the progress of fitness values. In that run, the fitness values were decreasing as opposed to increasing.
To address understand the reason for the unexpected behavior of the search, I ran numerous benchmark tests with different population sizes and number of generations with multiple strategies to update the population archives (iCCEA vs. elitist or best+random approaches).
After our discussing the results, we reached the following conclusions:

The lower the populations' size is, the higher the chances of observing a falling or oscillatory trend in max or average fitness of the populations are. 5 turned out to be a number that would not work. Whereas, with a size of 15, undesirable behaviors were rarely observed.

By increasing the weight of the term related to the confidence interval in the fitness function, the behavior improved. A rough explanation for why such behavior exists can be contributed to the heavy reliance of the fitness function on the number of observations per region. If the number of samples per region are too low, there is a higher chance that their fitness would change drastically given new samples. Thus, there is a higher chance that the search algorithm might move towards regions that it perceives to have a high fitness value while it is moving towards a lower fitness landscape (which becomes apparent after the new samples in the future generations are observed).

Conclusion (1): our search algorithm would most likely not work with a population size of 5 in 10 generations of search. We would have to bring the population size as close to 15 as possible in the least.

Conclusion (2): due to the population size increase, and the cost of simulations, the iCCEA version of updating population archives will not be feasible given our resource constraints since it forces the simulation of every possible complete solution per generation. Instead, other conventional strategies of updating population archives are suggested to be used, such as elitist or best+random strategies.

Conclusion (3): again, due to the increased population size, parallelization has become necessary for running the evaluations.

I was debugging the code using the MTQ problem.
I found two observations.
Observation: redundant individuals in a population due to lack of mutation
There are several redundant individuals in a population, mainly because mutation_rate was not 1 and we simply append the archived individuals to the next population. Since we already maintain the same individuals for the next generation using the population archive, the remaining seats should be filled with mutated individuals, meaning that we should use mutation_rate = 1.
So, I used the following parameter values:
# Search hyperparameters
scenario_population_size = 5  # Size of the scenario population
mlco_population_size = 5  # Size of the MLC output population
min_distance = 0.5  # Minimum distance between members of an archive
region_radius = 0.05  # The radius of the region for fitness evaluations
number_of_generations = 40
random_seed = None
max_num_evals = 51200

# Evolution hyperparameters
tournament_selection = 2
crossover_probability = 0.5
guassian_mutation_mean = 0
guassian_mutation_std = 0.1
guassian_mutation_probability = 1
integer_mutation_probability = 1
bitflip_mutation_probability = 1

After this, we either stuck at a certain fitness score or find a good solution. The fitness score does not significantly decrease even when the population size is 5.
For the stuck, I think I know the reason. It's simply because, for each individual in a population, the number of collaborations is too small (i.e., only 5 since there are at most 5 individuals in the collaboration population), and therefore it does not result in a good individual. Furthermore, since the two populations evolve together based on insufficient collaboration, any of the individuals does not evolve stably. I think this is an inherent limitation of CCEAs.
To conclude, using this commit 4bd1086600ebca47ab2aaf5a3eeba3c46f282932, we can at least overcome the problem of significantly decreasing fitness values.


Add Planet Generation using Terraforge

make planet objects generate in the database. generate terrain that wraps around the planetSpheres currently being made by TerraForge. If modified, this terrain structure will save only the modified piece for save file optimization.

We are getting closer after swapping to an IcoSphere based generation and rendering model.


Added oeedger8r tests for unsigned char, unsigned short, unsigned into & unsigned long

This is for Issue #978

bors try

bors try

@anakrish - Incorporated your feedback. Please review.


How to refer local packages in angular-cli?

🐞 Bug report
Command (mark with an x)

[ ] new
[ ] build
[x] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[ ] update
[ ] lint
[ ] xi18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Description
I want refer my local packages which has placed one directory in my computer and i want to refer this packages  in angular application
I have referred like below:
package directory - D:\today\dist
"dependencies": {
    "@syncfusion/ej2-angular-buttons": "file:../dist"
  },

angular-cli application directory - D:\today\asdf
When i try to givenpm i packages get installed and also duplicate node_modules get installed inside my local packages. and throws below compilation error:

🔬 Minimal Reproduction

download below sample

sample.zip

paste below packages outside sample
package.zip

map this packages path  in angular application

"dependencies": {
    "@syncfusion/ej2-angular-buttons": "file:../package"
  },

then give ng serve command

🌍 Your Environment

    "@angular/animations": "~8.2.14",
    "@angular/common": "~8.2.14",
    "@angular/compiler": "~8.2.14",
    "@angular/core": "~8.2.14",
    "@angular/forms": "~8.2.14",
    "@angular/platform-browser": "~8.2.14",
    "@angular/platform-browser-dynamic": "~8.2.14",
    "@angular/router": "~8.2.14",

when use npm pack for my package and  give that path application works fine
"dependencies": {
    "@syncfusion/ej2-angular-buttons": "file:../package/syncfusion-ej2-angular-buttons-17.2.48.tgz"
  },

https://stackoverflow.com/questions/14381898/local-dependency-in-package-json

Kindly see: https://angular.io/guide/creating-libraries#linked-libraries

@alan-agius4 , still i didn't get it. Can you please explain it...!

@alan-agius4 , Can you update on this?


Missing PyPI package info

If you go to https://pypi.org/pypi/django-pdf-view/json, there are some basic info that is missing (author, bugtrack_url, maintainer, etc.)

Check whether https://github.com/roknicmilos/django-pdf-view/pull/70 solves this issue (after it's published as a part of the next release)

This issue is solved with https://github.com/roknicmilos/django-pdf-view/pull/70


Player multipleChoice, previous button response still shows as "selected" state

For example: A player selects option A on question 1. Then when the host displays question 2, option A will be of "selected" style for the player, before they even make their selection.

Seems like the buttons remain "pressed" until the user physically presses on any other part of the screen.

Hacky solution made in App.js GlobalStyle, but should be changed for next release.


90/270º TerminalMode rotation docs

Replaces #61, closes #28
Rotation in terminalmode requires adding unwanted complexity,
which isn't good for TerminalMode which should stay pretty lightweight.
This PR adds some docs telling the user that particular rotations don't
work for TerminalMode.
I'm on the fence about making set_rotation() return an Err() if the
user tries to set 90/270º rotations. Thoughts?

I'm on the fence about making set_rotation() return an Err() if the user tries to set 90/270º rotations. Thoughts?

That makes sense, let's do that.


Document writing custom shaders on the website

When the APIs are stable, we should add documentation or a tutorial to the website on writing custom shaders.
In particular:

What input formats are supported
How to add one to an app
How to obtain a FragmentProgram
How to use a FragmentProgram to obtain a Shader
How to use that shader in a scene/widget
Best practices for structuring this code efficiently

From https://github.com/flutter/flutter/issues/108307 : also include information on premultiplied outputs, conversion helpers, et cetera

We also need to update https://master-api.flutter.dev/flutter/dart-ui/FragmentProgram-class.html to point to this documentation. Since its not updated yet this is a likely CP candidate to update the link


It seems the file counting is cumulative?

Each of the tasks matches exactly one file, but the "files created" counter keeps increasing.
The output should have "1 file created" each time (and it does only create one file).
configuration sample:
'string-replace': {
    [moduleName]: {
        files: {
            [baseIntDir + moduleName + '/tsconfig.json']: moduleName + '/tsconfig.json'
        },
        options: {
            replacements: [
                {
                    pattern: /\"\.\./gi,
                    replacement: '"../../..'
                }
            ]
        }
    },
    [moduleName + "-package"]: {
        files: {
            [baseOutDir + moduleName + '/package.json']: moduleName + '/package.json'
        },
        options: {
            replacements: [
                {
                    pattern: /0\.0\.0-PLACEHOLDER/gi,
                    replacement: pkg.version
                }
            ]
        }
    }
}

@albangicquel I have added a commit to fix the issue.
Waiting for fix to get merged.


deprecate inject and Provider

TL;DR: I would LOVE to break inject and Provider out into an independent library.
Mobx has been lifechanging for me. Among other reasons, it's freed me from having to worry about hidden context and store:props mapping. I can import stores and reference them in observers, and it's very clear where state is coming from.
So I hope you can understand how confused I feel when I see that half of the docs and issues of this project are devoted to supporting inject and Provider. These utilities aren't necessary to use mobx-react -- in fact, I believe that they are harmful! They introduce the store:props mapping that makes other libraries so heinous, and they make dependencies and types way less apparent and easier to break.
Is there some advantage to these utilities that I'm not getting? Because if it's just to avoid having to write a few import statements, it seems to come at a very high cost.
Example:
// 1.
import counterStore from '../stores/counterStore'
const Counter = observer(() => {
    const { count } = counterStore
    return
{count}

})

// 2.
import { inject } from 'mobx-react'
const Counter = inject('counterStore')(observer((props) => {
    const { count } = props.counterStore
    return
{count}

}))

In example 2, you have to load the whole "idea" of Provider/injector into your head to understand where your state is coming from. Maybe it will save you a few lines, but is that worth it?
Just to add to my point, I've introduced two people to Mobx who were completely thrown off by Provider and inject until I explained that they are completely optional and unnecessary.
Maybe there's some sort of history behind the two that justifies keeping them as part of mobx-react?
Regardless, thank you so much for your work.

Using import is easy, but not clean design wise. It's the same as putting things into globals (with better namespace handling) or making everything static. Once you make one thing static, everything it depens on must be static as well. So you will end up with very rigid architecture, where everything is hardwired, imposible to compose and hard to test.
However I agree that Provider/@inject should be in seperate package.

@8balloon There are tasks where contexts are more convenient than global store or regular props
e.g. in html editor you have some selected element at moment
Until you have one selection at the time:

You can store it globally, and import in every component. It's comfortable
You can store it in root Provider, and inject in every component . It's also comfortable
You can pass it to root comonent, and re-pass to props on every level. It's some painful(you need pass selection-prop to every child), but it works

But, when you have a more complex selection
e.g. when you selected some element, and want  edit his color, and color of his parent
Or you selected some complex element(CommentForm e.g), and want editable his sub-elements(textarea, button, ...)

You can not store selection globally, because you have more than one selection
You can store base selection in root Provider, and create additional Providers(with changed selection), where you want work with another elements(parents/childs/...). Imho, it's best variant
You can still use direct selection prop at every level, and change where you need.

@Gvozd You can avoid the need to pass props transitively through multiple levels by using render callbacks (actually you won't avoid this pattern if you want to make your components individually testable see #315 #366).
@inject shares some problems with import, but there are two differences:

The problems are not app wide, but isolated in specific subtree of components.
The dependency is not hardwired - you can still pass the depedency by prop, which makes the component itself (without the inject part) reusable and easier to test.

@urugator @Gvozd Thank you both for your thoughtful replies.
The points about dependency injection make a lot of sense to me. And it seems like it would work great for complex setups like @Gvozd described.
So far this all seems to support the case for breaking out inject into its own library... Doing so would make the delineation of use-cases very clear, and it would also  make onboarding easier, since users wouldn't have to figure out inject at the same time as the rest of Mobx.
Does @mweststrate have any input on this? Is there any reason not to break this feature out into its own library as part of Mobx 5?

@8balloon I think dependency injection is invaluable in complex project setups. Without it (when using global imports), it is not possible to do something as trivial as running unit tests in parallel.
Beyond that you are right that Provider / inject in essence has nothing to do with MobX. In fact, the original blog post describing the pattern AFAIK inspired the development of libraries like react-broadcast, addressing the same issue.
And there is good news, the new context mechanism in React solves the root problem that caused Provider / inject to be added to this library: the incompabitility of Context in combination with shouldComponentUpdate. That means that as far as I am concerned Provider / inject could be removed in a next major. Not yet, because the new api is not ironed out completely (e.g. injecting multiple stores would be tricky). But I assume that at some point a library will emerge that follows the exact same pattern as Provider / inject in mobx-react.

@mweststrate Awesome :)
Please let me know if you'd like help with this.

@mweststrate

problem that caused Provider / inject to be added to this library: the incompabitility of Context in combination with shouldComponentUpdate

I tried to solve this problem in #411 , and it looks like I did it
May you look my PR?

For now, figured to not deprecate the Provider/ inject api in the foreseeable future, because in quite some aspects that api is still more ergonomic then the React.createContext api, and forcing all consumers to upgrade would be quite painful

@mweststrate I've given this some more thought, especially with regards to writing testable code.
Testing frameworks like Jest allow mocking at the module level. Wouldn't this grant you the capacity for full-featured testing without having to access dependencies through a context/provider?
I feel like I'm in the minority on this one, but it's important to me, because I think that code becomes vastly less intelligible when module-level dependencies aren't explicitly declared. (For the record, I feel like the createContext API is a step backward.)
I think it could hugely benefit the community to move away from contexts/providers and towards module-level mocking...
If you think I'm wrong on this, I would really appreciate an explanation :)

@8balloon You're missing the point ... nobody claims that testing is imposible, but more complicated. But that isn't the problem itself, just it's consequence.
As mentioned the problem is that everything is statically bound to module loader, so you can't control the "lifecycle" of objects and it's dependencies programatically.
It greatly reduces the reusability/composability of your code. It is a problem in general, which you may not care about from the perspective of the application logic itself, but in practice there are two consequences:

You can't run your code in paralell
Therefore can't run multiple tests in paralell on single VM.
Therefore you can't do SSR, because you can't serve multiple requests at the same time (module loader is shared by requests).
You have to modify module loader logic to provide different dependencies or to re-set the state of the depedencies.
Afaik this is what test libs do. They modifies the implementation of require function.
Note that this solution won't work when you start using native import impl, without transpiling import statements into require statements.
And because native import statements are not resolved dynamically like require, but statically, chances are that each individual test would have to start new VM instance, passing custom module loader hook as exec option in order to mock the module dependencies.

Also I would like to point out that context/providers (or any DI solution in general) is not an alternative to module imports, but an alternative to passing dependencies to constructor functions.

@urugator Thank you so much for your detailed explanation.
The solution you described with multiple VM instances is what I was personally looking for. The SSR use case you described explains why it wouldn't work as a universal solution. So I am satisfied :)
I'm sorry if I've been frustrating anyone with this. Hopefully this conversation thread helps others.
Thanks for the awesome library! I appreciate you guys.

So is it better to use the React context api or the Provider/ inject from react/mobx? What are the pro/cons?

Wouldn't it be trivial to build Provider/ Inject from the new context api?
@inject would look something like this:
const inject = (propNames) => (Component) => {
   return (<Context.Consumer>{(contextValue) => <Component
  {...Object.keys(contextValue).map(propName => propNames.includes(propName))}/>}
 </Context.Consumer>
}

}

If anything breaking it out would be nice because it's a handy helper function that I believe can be used for things that aren't stores/mobx related.

@melbourne2991 The provider would overwrite previously provided context value, you would have to wrap it into consumer and merge the value.
The inject should return component (and merge props with injected props), you're returning element...
Note that all consumers will be invoked whenever any Provider is invoked, this allows changing context dynamically, but could cause some perfomance degradation.
Why not to stick with one static context per value, what's the benefit of merging them into one and referencing them via strings? Note that you can implement helper function to merge multiple consumers like
const ComponentWithStores = Consumer({
  store1: Store1Context,
  sotre2: Store2Context,
})(Component)

Obviously the same can be done for providers...

Something to note is that on server-side rendering, importing the store (a singleton) can cause race conditions (ie: different "requests" hitting the same store), hence returning incorrect data.

I use the new context of the react. No problems, everything is well predicted.


Installing kubernetes on Mesosphere

Trying to install kubernetes but getting the following error, and it is not included in the packages installed.
PS C:\dcos\time-series-demo> dcos config prepend package.sources https://github.com/mesosphere/multiverse/archive/version-1.x.zip
Command not recognized
You can close this issue, I figured it  out.

what was the work around?

Hit this myself, ended up trying to just set the config instead of 'prepend', and got this:
$ dcos config set package.sources https://github.com/mesosphere/multiverse/archive/version-1.x.zip
This config property has been deprecated. Please add your repositories with `dcos package repo add`

@jedi132000 please include your solution instead of just saying "I figured it out" next time. :)


Issue with suggested port 5002

TL;DR: I'm having issues in using the suggested port in the examples 5002, so it may make sense changing the port number to a less used one.
I'm on OSX, and if I curl -I localhost:5002 I get
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache, no-store, must-revalidate
Date: Thu, 20 Jun 2019 09:21:47 GMT
Content-Length: 23
Content-Type: text/plain; charset=utf-8

It seems there's some service already running on that port:
$ lsof -i TCP:5002
COMMAND   PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
agent   10172 andrea   11u  IPv4 0x4b127be231ef2135      0t0  TCP localhost:rfe (LISTEN)

Doing a google search, port 5002 seems to be related to radio free ethernet, and this is documented in the IANA port list:
rfe                5002        tcp    radio free ethernet
rfe                5002        udp    radio free ethernet

Any suggested port? We're open to a PR to change the default. This is where the default is set:
https://github.com/shakacode/cypress-on-rails/blob/49f1f7b2a912a15142baf137b0ea31a0378c9e92/lib/generators/cypress_on_rails/templates/spec/cypress.json#L2
{
  "baseUrl": "http://localhost:5002",
  "defaultCommandTimeout": 10000
}

According to this list there are a few ranges of ports that are not assigned, the closest to the current setting is 5016-5019, and this wikipedia page seems to confirm it.


Fix answer creation/deletion

Caught by the tests in #305

Glad to see tests doing their job

Glad to see tests doing their job


Update index.html

Proposed Changes

Added some amazing features in calculator
Improved the CSS of index.html
Corrected the typos
Made the calculator more interactive

The main aim of landing page enhancement is to make it easier for everyone to add new projects. Consider moving CSS and js codes in a separate file. Try to make it like a small snippet for each new project, so that new contributors can understand and add new snippets for their project to get onto the landing page.
Could you do that?

Yes, I will try to move CSS and js codes in separate files and make it like a small snippet for each new project.

@YashAryanTheCoder Go Ahead! Make sure to squash all commits into 1 PR. Take your time.

Yes, I will try to move CSS and js codes in separate files and make it like a small snippet for each new project.

Are you working on this? or I can assign someone else

I am working on it


Please use the OSM testing server to test OSM write API

From Grant Slater:

Yes, there are: https://apis.dev.openstreetmap.org/
They are completely free standing and you need to sign up to them independently. The main one has some limited sample data, but you'd likely need to upload your own test data.

Please can you get a unit testing workflow in place with the key CRUD operations across OSM API that performs the operation against the testing server and then uses the test server API to confirm the operation result.
Regards
Tim

hi @myarjunar
could you handle this, maybe also with unit test from create/update API
i think we don't have utilities to read/delete, please check this ticket (https://github.com/healthsites/healthsites/issues/1171) to work on read/delete


Active Checkin Endpoint Help

I see that there is a way to create checkins and delete them, as well as seeing checkin items in the user history, but is there a way to view an active checkin? More specifically, is there an endpoint that would allow me to check what a user (authed or non-authed) is currently checked into and what their progress is?

I somehow completely missed the users/id/watching endpoint. Closing this question.


Get rid of optparse-applicative dependency.

Attempt to fix #23

Hi Facundo,
I've tired to keep the output and formatting like it was before with optparse-applicative. I'm putting output to stderr for all except --help options/possibilities.
Thanks in advance for any review!

Btw as a note, the base library contains some implementation of argument parsing - https://hackage.haskell.org/package/base-<IP_ADDRESS>/docs/System-Console-GetOpt.html.
I personally haven't tried it, but it seems usable. Although it might be overkill for this case.

I personally haven't tried it, but it seems usable. Although it might be overkill for this case.

It could be helpful if it avoids reimplementing some of the formatting and error handling. But otherwise, the contributions here look good.

I wish I knew how to get the CI workflows running when you make PRs from your fork like this.

@aherrmann, maybe you know how to setup this?

I personally haven't tried it, but it seems usable. Although it might be overkill for this case.

It could be helpful if it avoids reimplementing some of the formatting and error handling. But otherwise, the contributions here look good.

I'm fine with it. I think it's better to use some structurized way of obtaining cmd args than whatever I did here. However, before we go this way I'd like to propose the following path: let's merge this PR and then I'll introduce Console.GetOpt under the next PR.
Maybe that's because of my inexperience with Console.GetOpt and Haskell in general, but I'm wondering how much it will improve composition of cmd args parsing and the validation of filepath existence? While reading the API of Console.GetOpt it's not straightforward to me. I mean at the first glance obtaining cmd args is still going to be a two step process (parsing args with Console.GetOpt + validating them [without the help from Console.GetOpt]).

I wish I knew how to get the CI workflows running when you make PRs from your fork like this.

Ah yes.. I've spotted that the creation of PR didn't trigger CI pipeline. But later on, probably because of the one of the next commits I've done here, CI pipeline has been started.
Moreover, couple days ago I've assigned #23 to myself and that action has triggered the CI pipeline (I was notified that the gazelle_cabal build failed but the only thing I did that day was the assignment of the bug...)

I wish I knew how to get the CI workflows running when you make PRs from your fork like this.

@aherrmann, maybe you know how to setup this?

You can push the PR branch to the tweag repo to start a CI run. Alternatively, you can add on: [..., pull_request] to the workflow config. However, beware that this can trigger duplicate CI runs, see https://github.com/tweag/capability/pull/95#pullrequestreview-688155185.

I am facing issues with BES during the build.
It turns out that bazel_5 may help to get rid of them: https://githubhot.com/repo/buildbuddy-io/buildbuddy/issues/992

Merged, thanks @kczulko!
I updated the nix configuration to use bazel 5.


Add security task related apply/destroy script

Modified apply-security.sh to make sure everything came up.
Added associated destroy-security.sh to make sure I can tear down
everything afterwards.
Signed-off-by: Soe San Win<EMAIL_ADDRESS>

Hello Rob,
Updated with latest developments as I was working on it.
~SS


rv64g_instr_launcher_tb

Testbench Needed

waiting completion of reg_gnt_ckr

ready for tb

On it, respectfully

For this RTL, does it store the instruction when the output is invalid or source registers are locked? What happens to the instructions that don't make it through?? I feel like there's quite a few details I am not aware of :). Please help!!!

Sure, the RTL does hold up to 8 instructions before getting stalled just to locked registers. Invalid instruction shall not enter this RTL. When the instruction finds and invalid instruction, the input valid to this module must be set low at upper levels, an expection flag must be raised. Let discuss in sync-up

I am extremely sorry in advance as I declare that I will not be able to
attend the sync-up today. I am on my phone and am still outside for a
family emergency. One of my really close uncles is sick and I went to the
hospital to visit him. To top that off, I have an exam tomorrow for which I
haven't prepared yet.
I'll try to do some more digging on how I can approach the issue in the
meantime and prepare for the next sync-up. Thank you. And apologies.
On Fri, 29 Nov 2024 at 20:52, Foez Ahmed @.***> wrote:

Sure, the RTL does hold up to 8 instructions before getting stalled just
to locked registers. Invalid instruction shall not enter this RTL. When the
instruction finds and invalid instruction, the input valid to this module
must be set low at upper levels, an expection flag must be raised. Let
discuss in sync-up
—
Reply to this email directly, view it on GitHub
https://github.com/DSi-DV/rv64g-core/issues/28#issuecomment-2507965485,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BM5UBIGCHMAGZBOU43PSHQT2DB5T7AVCNFSM6AAAAABSMBUINKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBXHE3DKNBYGU
.
You are receiving this because you were assigned.Message ID:
@.***>


[Comms] Görli Testnet Contributors Call #2 will be GÖRLICON

GörliCon
Save the date: January 31, 2019
Location: Berlin, Germany @ Factory Görlitzer Park
Agenda: TBA - please let me know if you want to host a talk or workshop
GörliCon Pariticipation Form https://docs.google.com/forms/d/e/1FAIpQLSeO8TD70L_KkW4Ont4tx1w_imvYisdbwl0u4fjx8hpfb3d2Aw/viewform

That was fun :tada:

All videos: https://www.youtube.com/watch?v=d961TWOSnBU&list=PLjOcf_IVqERknYTwN0k1d5cwOd_LGhn3E

yes it was fun,
nice to see so many goerlians :+1:


Workflow & Backend changes to re-open a request(#832)

The system should allow reopening of request
Scenario #1 : Closed to Intake In Progress

[x] Workflow changes to allow reopen request from navigation (Intake In Progress to Closed)
[x] Service changes to allow reopen of request.
[x] Re-opened request to be assigned to team & member (if member don't exist then assign only to team)
[x] Request greater than 365 days of time can be closed permanently.

Scenario #2 : Closed to stage (Open)

[x] Workflow changes to allow reopen request from navigation (Open to Closed)
[x] Service changes to allow reopen of request.
[x] Re-opened request to be assigned to team & member (if member don't exist then assign only to team)
[x] Request greater than 365 days of time can be closed permanently.

Scenario #3 : Closed to stage (Call For Records)

[x] Workflow changes to allow reopen request from navigation (stage (Call For Records) to Closed)
[x] Service changes to allow reopen of request.
[x] Re-opened request to be assigned to team & member (if member don't exist then assign only to team)
[x] Request greater than 365 days of time can be closed permanently.


Why SDK version "2.1.0-dev.9.4.flutter-f9ebf21297" dosen't match required ">=2.1.0 <3.0.0"

Steps to Reproduce

run flutter packages get in the flutter\examples\flutter_gallery .

Logs

Running "flutter packages get" in flutter_gallery...
The current Dart SDK version is 2.1.0-dev.9.4.flutter-f9ebf21297.

Because flutter_gallery depends on test_core >=0.2.1 which requires SDK version >=2.1.0 <3.0.0, version solving failed.

Why the SDK version "2.1.0-dev.9.4.flutter-f9ebf21297" dosent match the required ">=2.1.0 <3.0.0", since they are both some kind of 2.1.0?

I happened too!
I tried flutter upgrade
 flutter channel master  flutter upgrade
flutter version is 'Flutter 1.1.10-pre.197'
I can flutter run

Yes I tried, it worked for me


Publishing protobuf Messages in ros

Hello,
I am not sure if I have understood this library correctly.
I have a Ros node that receives protobuf messages. These messages contain a lot of deserialized messages. I want to put these messages into ros space. This means that each proto message needs to be converted into a ros message.
Is this the use case for this library?

The goal of this library is serialize ROS messages with protobuf.
In ROS2, the ROS library / API itself doesn't define a data transport or a data serialization (even though it ships with a default one). The RMW (Ros Middleware Layer) needs to serialize the Ros Messages to a format that they can transmit. This is done via rosidl_typesupport packages. There are many of those packages. This one uses protobuf for serialization. It was initially developed for the rmw_ecal. eCAL doesn't really care about the data serialization, as it only transports binary blobs. However, as eCAL and Protobuf work well together, we developed the rosidl_typesupport_protobuf, which can serialize the ros messages to a binary buffer via protobuf.
If you have a serialized protobuf message in an std::string, etc. , you don't need this typesupport. You rather need to obtain the original .proto file for that message and use protoc to generate the cpp / python etc. class structure for that that message. You can then call DeserializeFromString to parse your binary blob and make if fill your class.
You can now copy the data to your ROS messages. Usually it's faster to do that by hand (maybe some AI tools like ChatGPT can help here, too). However if you really have a lot of messages, you can check the code in this repo, as the typesupport also generated some glue code converting from protobuf classes to the ROS message API.


Live log sub-process (pip and more) output?

FACTS:

Current output (STDOUT/STDERR) from sub-processes is logged in an "all-at-once" approach when the sub-process ends.
Also, STDOUT is logged at DEBUG level.
Some such runs may be somewhat long-ish (many seconds, few minutes).

IDEA:

Given that we prefer not to let sub-processes "just" output to STDOUT/STDERR directly...
...maybe we could live log such output as it is produced, prefixing it with something like 'pip stdout/stderr'?

THOUGHTS:

Given that subprocess.run seems to block, not sure how to achieve that.
Maybe a thread or two are in order? :-)

RESCHEDULED:

Giving this priority as it will simplify diagnostics during the development process.

Closing. Addressed in PR #46.


Port "Move Group Python Interface" tutorial

Port tutorial to ROS2.

Hello, I'd like to port this Tutorial.

Hello.

Traceback (most recent call last):
File "/usr/bin/roslaunch", line 34, in
import roslaunch
File "/usr/lib/python3/dist-packages/roslaunch/init.py", line 62, in
from .scriptapi import ROSLaunch
File "/usr/lib/python3/dist-packages/roslaunch/scriptapi.py", line 42, in
import roslaunch.parent
File "/usr/lib/python3/dist-packages/roslaunch/parent.py", line 54, in
import roslaunch.server
File "/usr/lib/python3/dist-packages/roslaunch/server.py", line 79, in
from rosgraph_msgs.msg import Log
ImportError: cannot import name 'Log' from 'rosgraph_msgs.msg' (/opt/ros/foxy/lib/python3.8/site-packages/rosgraph_msgs/msg/init.py)

Hey Nikorose, yes it need to be ported from moveit1 to moveit2 which include porting from ROS to ROS2.
You'll need to take a look all over the code and see the parts which need to be translated. I was interested in porting this one also but I had no answer from the participants so...

Thank you for the info!

@JonatasVT Do you have any sample to transform those scripts into the ROS2 environment? Especially from catkin to colcon. Thank you

@nikorose87
I don't but you can take a look on the "Move Group Interface". I was ported to Moveit2 already.

Hello @JonatasVT,
Great to hear that you are interested in porting to tutorial.
Unfortunately the Python Interface that this tutorial uses is not ported to ROS2. See https://github.com/ros-planning/moveit2/tree/main/moveit_commander being COLCON_IGNOREd. This needs to be ported before the tutorial to expose the move_group interface through python. moveit_commander uses bunch of other Python interfaces that hasn't been ported as well under moveit_ros. If you are willing to contribute to port Python interfaces please let me know and at least I (or a maintainer) can help guiding you on what needs to be ported to get this done.

@vatanaksoytezer Is there an ETA or an issue tracking when the python interfaces will be ported?

https://github.com/ros-planning/moveit2/issues/314 is the relevant issue for porting python bindings. As far as I know there is no work in progress right now, so no ETAs.

Hi @vatanaksoytezer, am I understanding this correct that Moveit2 can - at least for now- not be used with the python movegroup interface? Are there any alternatives for easily setting target poses etc. through python? Thanks in advance for your reply!

@tlpss that is correct. We don't have any official way of interfacing with MoveIt 2 through Python as of now, though the C++ interface should be fairly straightforward and robust to use.
On another note, technically speaking you can always interface with MoveIt 2 through services and topics by using any language or interface you would like (command line, cpp, python). But this might take more effort than just using C++ interfaces.

@vatanaksoytezer  Thanks for your reply! I understand that we could indeed directly connect to the topics/services, but that is indeed slightly less convenient as you already mentioned.
Is there by any chance a roadmap for the python interface?

Is there by any chance a roadmap for the python interface?

So the situation is same as above comment of mine:

ros-planning/moveit2#314 is the relevant issue for porting python bindings. As far as I know there is no work in progress right now, so no ETAs.

@peterdavidfagan we can call this done by you, right?

@peterdavidfagan: would porting this tutorial also require moveit_py to wrap the moveit::planning_interface::MoveGroupInterface?
My current understanding is that if a node wants to use MoveItPy it must have all the moveit-related parameters set on it whereas the MoveGroupInterface uses an already configured and running /move_group node.

Hi @m-elwin,
Are you looking for an API similar to moveit_commander?
It should be possible to launch the move_group node and interact with it via ROS as this is the intended interface for this node? Is there something that is stopping you from doing this?
If you have particular functionalities you need that aren't already in moveit_py I'd be happy to potentially add these. Are you having issues setting parameters for moveit_py? I'd be happy to provide guidance on ensuring parameters are set correctly for your robot. As for usability, a goal of moveit_py is to ensure a user friendly API is exposed, there is clearly room for improvement, if there are areas that are lacking feel free to provide feedback on these as we can update the library code accordingly.

Hi @peterdavidfagan, thanks for the quick reply and offer to help. I'm also happy to help as well.
The overall missing functionality that I would want (and believe is generally needed) is the ability to use moveit_py without requiring the user to configure any moveit parameters. Instead they would rely on the robot-vendor provided setup. Workflow would be:

Run vendor-launchfile that launches and configures move_group node
Run your node that uses moveit_py API to move the robot (possible to do with a simple ros2 run command).

The above workflow matches that of the ROS 1 version of the tutorial this issue refers to and the Your First C++ MoveIt Project ROS 2 tutorial but I do not know how to achieve an equivalent workflow with moveit_py right now.
It's not so much a difference of what can be accomplished with MoveIt from python (which I think moveit_py covers pretty well at this point so a big thank you for your work on that!) but more of programmer experience (particularly for beginners). You are right that using the ROS API of /move_group can accomplish these goals, but in my experience that ultimately leads to creating a custom python wrapper around that ROS API, which is essentially something that ROS 1 provided with the python MoveGroup API.

Hi @m-elwin,

The overall missing functionality that I would want (and believe is generally needed) is the ability to use moveit_py without requiring the user to configure any moveit parameters. Instead they would rely on the robot-vendor provided setup. Workflow would be:

Managing robot configuration can be painful, there is now a nice guide on setting up robot parameters here. In general, somewhere the parameters need to be configured, I think this is somewhat separate to the moveit_py API but it is still a very important discussion. moveit_py nodes accept parameters through launch files in the same manner as moveit_cpp. I'd be happy answer any questions relating to this here.

It's not so much a difference of what can be accomplished with MoveIt from python (which I think moveit_py covers pretty well at this point so a big thank you for your work on that!)

Thanks so much, still looking forward to improving and adding further features to the Python API, your feedback is welcomed.

but in my experience that ultimately leads to creating a custom python wrapper around that ROS API, which is essentially something that ROS 1 provided with the python MoveGroup API.

This is very true, I am considering creating a video tutorial for moveit_py set up. What robot are you trying to work with right now?

Thanks @peterdavidfagan,

In general, somewhere the parameters need to be configured, I think this is somewhat separate to the moveit_py API but it is still a very important discussion.

I think that makes sense. I guess what I'm trying to figure out is how the C++ MoveGroupInterface handles moveit configuration parameters and whether the python version of that functionality belongs in moveit_py or somewhere else.
Here's an example of what I mean in more detail:
In the Your First C++ MoveIt Tutorial  the workflow is:

ros2 launch moveit2_tutorials demo.launch.py. This launches a /move_group node with a full moveit configuration. The equivalent of this launchfile is usually provided by robot vendors (at least it is for Franka arms and interbotix arms).
ros2 run hello_moveit hello_moveit.  The key feature of this command is that we do not specify any parameters.  The code that the user writes in the node also does not set moveit options (at least directly).  The user just creates a Node object and passes it and the name of a move group to a MoveGroupInterface object.
Right now (I think and please correct me if I'm wrong) there is currently no way to use moveit_py to write a direct python equivalent of hello_moveit.cpp because the user would need to explicitly set parameters for that node.

My initial thought was that the best way to achieve this "configurationless" functionality is to wrap MoveGroupInterface (from the moveit-ros-planning-interface package) as part of moveit_py. Do you think wrapping that class that is within scope of moveit_py?  If so I'd be happy to work on a pull request.

Hi @m-elwin,
Thanks for following up on this.
The parameters are passed to the move_group node here within the launch file.
The same pattern is used to pass parameters to the moveit_py node, here is an example.

Fixed by #810


Mesa 21.3.x resulting in flickering on Intel GPUs

Describe the bug
Mesa 21.3.2 present in nixos-unstable is causing flickering in nheko, and they point to upstream bug, not yet fixed as of now. Reverting to nixos-unstable  to Mesa 21.2.6 updates fixes the issue.
Steps To Reproduce
Steps to reproduce the behavior:
0. Make sure you're using Intel GPU

Switch nixos channel to 59bfda72480
Install nheko
Start nheko

Expected behavior
No flickering should happen on the application screen. Mesa bug report has a video demonstrating the issue.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context

upstream bug in Mesa

Notify maintainers
cc: @vcunat @primeos
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
- system: `"x86_64-linux"`
- host os: `Linux 5.10.89, NixOS, 22.05 (Quokka)`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.5.1`
- channels(root): `"home-manager, nixos-22.05pre342525.59bfda72480"`
- channels(user): `"home-manager"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

According to the bug report this seems to affect at least Blender as well. Anyway, we can leave this issue open for a while (in case it helps users to figure this out) but I don't think there's anything actionable for Nixpkgs (it's an upstream bug and we simply have to wait until a fix is released via a new version).
It looks like the patch from https://gitlab.freedesktop.org/mesa/mesa/-/issues/5731#note_1205469 should be submitted formally via a PR so that it might get included in Mesa 21.3.4.

This is also happening on qutebrowser for me, but only on the wayland backend. I have a temporary fix to just launch with MESA_LOADER_DRIVER_OVERRIDE=llvmpipe, but this obviously disables the hardware. Works fine though so far for just browsing and work stuff, at least until a proper fix is merged.

It's unlikely that the patch will be applied for 21.3.4 (as no one filed a MR for it so far), should we apply it downstream?

I'm seeing this in qutebrowser as well

I'd prefer to avoid applying a patch that hasn't been reviewed upstream.

+1 for what @vcunat said. Luckily a developer from Intel started looking into this so let's see how things will develop: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5731#note_1208981
Ideally a patch will be ready for 21.3.4 but the release might happen in two days (unless it gets delayed) so it'll indeed be close (but we'll of course re-evaluate our options once the release is out).

Unfortunately it was indeed too close for the patch to land in Mesa 21.3.4.
However, now there's at least an alternative patch from Paulo Zanoni (the Intel developer) and Giuseppe Ghibò (author of the other patch) and others confirmed that it's working: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5731#note_1214181
I've included that patch in https://github.com/NixOS/nixpkgs/pull/154926. Does someone have time to test it (https://nixos.wiki/wiki/OpenGL#Testing_Mesa_updates) and report if it indeed fixes the issues?

@primeos I'm happy to test.
Could you confirm I understood the instructions correctly?

integrate the code from the above PR into my nixpkgs tree.
put the following into my nixos config:

system.replaceRuntimeDependencies = [
  ({ original = pkgs.mesa; replacement = (import /srv/nixpkgs-mesa { }).pkgs.mesa; })
  ({ original = pkgs.mesa.drivers; replacement = (import /srv/nixpkgs-mesa { }).pkgs.mesa.drivers; })
];

replace /srv/nixpkgs-mesa with the path to my nixpkgs tree.
run nixos-rebuild test

Did I get that right?

integrate the code from the above PR into my nixpkgs tree.

It's the easiest if you use a separate/dedicated Nixpkgs tree for Mesa (/srv/nixpkgs-mesa in the example). That way you don't have to rebuild a lot of other packages (which would most likely still take way too long). You can also cherry-pick the patches to nixos-unstable (I'd recommend doing that) which saves additional rebuilds.
The rest looks fine. And thanks in advance :)

I've included that patch in #154926. Does someone have time to test it (https://nixos.wiki/wiki/OpenGL#Testing_Mesa_updates) and report if it indeed fixes the issues?

It works like a charm. Thanks @primeos!

Seems like this wasn't closed automatically once https://github.com/NixOS/nixpkgs/pull/154926 landed in master. Should be fixed now. And upstream merged the required patches in the meantime (s. note in https://github.com/NixOS/nixpkgs/pull/160494).
And thanks for testing the fix @magnetophon and @phenax! :)


font-weight isn't set in scss/forms/_select.scss

If you change the $input-font-weight, there is no effect in select fields, because the font-weight isn't set:
It's missing  font-weight: $input-font-weight;

input-font-weight is in https://github.com/zurb/foundation-sites/blob/develop/scss/forms/_text.scss
Not _select.scss. This is not intended to work on Select(till date).

It's working ( tested in Chrome, Firefox and Safari)

I think the select form element should have its font-weight property applied according to input-font-weight value, since it is technically a form element and to have the font properties be applied across form elements.
Not just this specific property, any font declaration that are not present in a particular form element, but present on the other should get applied throughout.
Let me know what you guys think.

I believe this was fixed in https://github.com/zurb/foundation-sites/pull/9681.
This was a part of a broader change, and so not likely to be backported to 6.3 series, but is in 6.4 (in fact, if you want to try it out early, we just packaged up the first release candidate. Check it out: https://github.com/zurb/foundation-sites/releases/tag/v6.4.0-rc1


Revive the "fat interface files" GHC patch

https://gitlab.haskell.org/ghc/ghc/issues/10871
This would give us a more principled way of getting unfoldings from our dependencies, rather than requiring things to be manually marked INLINEABLE.

@input-output-hk/tools

@michaelpj, @luite: we should outline the expectations (usecases) we hope this would solve just to make sure we keep this focused and on track. Also to cut this short if we learn it would not yield the expected results and a different approach is needed.

https://github.com/ghc-proposals/ghc-proposals/pull/262


Waves for Radio / checkbox elements

Hello,
I tried to attach waves to radio buttons but it din worked. any ideas ?!
Thanks

Sorry, it's seems not possible. The only way to do this might be by creating a custom checkbox element with <div> tag.

You don't add the Waves effect directly onto the <input type="radio">, instead you add it to a wrapper or the label:
<label for="r1" class="waves-effect">
    <input id="r1" type="radio" value="value1" name="r">
    Radio box 1
</label>

<label for="r2" class="waves-effect">
    <input id="r2" type="radio" value="value2" name="r">
    Radio box 2
</label>

Codepen: http://codepen.io/anon/pen/Pqjrax
The labels are required to allow the user to click on the text, which then selects the radio/input button.

@hoxxep  No dear it won't. it will give waves effect for the whole label n input , which isn't what I want to achieve.
what i want to do for checkboxes n radio like the following demo:
http://fezvrasta.github.io/bootstrap-material-design/#checkbox
I will close this issue, and will re open it if i could get it done with waves.js
Thanks.


WIP: Improve definition of supervisor (DO NOT IMPLEMENT)

We now have Fiber.onComplete, which looks like this:
def onComplete(k: ExitResult[E, A] => IO[Nothing, Unit]): IO[Nothing, Unit]

This looks like a type of "supervisor", because anyone who calls this method can now see if and how the fiber exits (including all errors).
Currently, when a fiber is forked, an unhandled error handler may be specified, in the form List[Throwable] => IO[Nothing, Unit]. If this is not specified, then the uncaught error handler is used from the fiber that forks the fiber (all the way up to the root uncaught error handler).
These two methods of "supervising" a fiber look very similar, and suggest the two notions of "supervising" could be unified in some fashion.
Meanwhile, we have a separate supervise combinator:
IO.supervise {
  for {
    ...
  } ...
}

The supervise combinator allows collection of forked fibers into a weak set, so that cleanup may be performed upon exit of the specified IO.
This notion is similar to the other in the sense that it's a way of supervising the activity of child fibers.
It's possible all three notions of "supervising" can be unified somehow.

@regiskuckaertz We can play around with ideas here.
The main problem with the obvious unification:
def onComplete(k: (Set[Fiber[_, _]], ExitResult[E, A]) => IO[Nothing, Unit]): IO[Nothing, Unit]

Is that it would require you collect the child fibers on every fiber. Currently this is a flag turned on / off with the supervise combinator, which means you pay the cost only when you need it.
One can view the building of the weak set as being a sort of state update, suggesting a way to generalize the supervise combinator. Perhaps if it were generalized, onComplete and error handling could be built on top of that.

Do we want to introduce a Supervisor abstract data type to represent the varying degrees of supervision?

one to deal with unhandled exceptions
one to deal with the fiber's exit result
one to deal with the fiber's exit result and children

A user could even "change their mind" for some reason and move from one degree to another.
Also the IO.supervisor combinator could be updated likewise. I'm not sure whether it makes sense to keep these in IO instead of Fiber?

I think using an sum type for supervisor could be one way to solve the issue. Another thing I thought of: perhaps your supervisor always gets passed Set[Fiber[_, _]], but in some cases it's empty because children are not being observed? In this case, you get a more uniform type signature and more reuse across supervisors.
Finally another thing I thought about:
trait Supervisor[+A] {
  type State
  def initial: IO[Nothing, State]
  def onFork[E, A](state: State, child: Fiber[E, A]): IO[Nothing, State]
  def onComplete[E, A](result: ExitResult[E, A]): IO[Nothing, State]
  def finish(state: State): IO[Nothing, A]
}
object Supervisor {
  def forks: Supervisor[Set[Fiber[_, _]]] = ???
}

Now maybe you could write:
trait IO[E, A] {
  def superviseWith(s: Supervisor[A])(f: A => IO[Nothing, Unit]) = ???
}

And hence:
io.superviseWith(Supervisor.forks)(Fiber.interruptAll(_))

I know this is not well thought out, but more food for thought...

It looks like the supervision model in Erlang, at least if you squint your eyes 😅
It would be interesting to see how this idea can be reconciled with the declarative API of a ZIO. Perhaps fork0 can be updated to accept an optional supervision strategy, in which case the fiber would automatically become a supervisor for its descendants.

Another interesting discussion is how would an event-based API (onFork, onComplete) weave itself into the current evaluation model? It’s almost as if each action should run into its own fiber and then State becomes a piece of shared state, implying some Ref around it at least.


feat: add additional filesystems to the blacklist

I believe that overlayfs is vastly used.

It might be a good idea to actually break this up a bit on the reason to disable

It might be a good idea to actually break this up a bit on the reason to disable. Which one is actually uncommon for SecureBlue's usecase, which one is known bad, and which one is because its a network fs.
I will make a PR later today.

Thanks, yeah the comments could be improved substantially.


Pre-trained models' link broken

It seems the link to pre-trained models is broken. Would it be possible for you to share it again?

@kampta It's strange cause I never change the path in my Amazon Drive. Fixed now ... .

Thanks!


Layout Ideas

I feel like given the way some of these types of apps function there are a few design patterns that could be used. Here are some ideas:

The left side nav could be a user defined set of pages (maybe there is a default as well) ... Basically, a set of pages that are 'most important' to the user.
When in the page view mode, have it be broken into two columns. The left would be the page, and the right would be the table of contents nav. I also moved the edit button into this 'sticky' column. I think it makes more sense to have the edit button encapsulated inside the page rather than part of the nav. See 1st screenshot. (sidenote: this same principal could be applied to the save/preview buttons when in edit view)
Since the Markdown Syntax Guide only applies when editing a document, have it be a reference tab at the bottom. See 2nd/3rd screenshot.

Let me know how you like these changes and I will issue a PR

Maybe I've taken it a step too far, but I'm finding it a slight pain point to access attachments of a page. Maybe this could be a first class citizen of the page view (like TOC). See screenshot

1.) User defined set of pages in the sidebar
I like this idea, currently the sidebar is too empty. To clarify: Do you want a) an admin to be able to  would suggest to let either an admin choose which links should be placed there or b) each user can pick their own favored wiki pages?
2.) Adding additional columns
Multiple wikis do these, I'm not a very big fan of that -- maybe because I never use a wiki on full screen ... I would not oppose a change like this if alle the information will still be available on smaller screens without strechting the content too far.
3.) Markdown Syntax Guide under the editor
This is a fantastic idea. I would really like to have this feature.

1.) User defined set of pages in the sidebar
I like this idea, currently the sidebar is too empty. To clarify: Do you want a) an admin to be able to would suggest to let either an admin choose which links should be placed there or b) each user can pick their own favored wiki pages?

Hmm... Well... I guess I'm not sure yet. Maybe as an incremental improvement it could display a contextually relevant TOC for the give page you are viewing. So like... The sidebar will show all sibling page (at the same level) + maybe 1-2 levels of it's h1/h2 anchors For each page. I can clarify if this is confusing.

2.) Adding additional columns
Multiple wikis do these, I'm not a very big fan of that -- maybe because I never use a wiki on full screen ... I would not oppose a change like this if alle the information will still be available on smaller screens without stretching the content too far.

Yeah fair enough. That totally makes sense. Maybe that sidebar will just hide on a smaller screen? The bootstrap/halfmoon classes will do this automatically.

3.) Markdown Syntax Guide under the editor
This is a fantastic idea. I would really like to have this feature.

Awesome! Question - I cant figure out the css class to specify a light/dark mode aware background color. What is it?
Thanks for the feedback! I'll wrap 2 and 3 into a PR.

Awesome! Question - I cant figure out the css class to specify a light/dark mode aware background color. What is it?

The dark-mode toggle in the gethalfmoon framework add the class "dark-mode" to the <body> and as far as I unterstood (I'm not a CSS, not even an UI guy) everything inherits this. I've used it e.g. to change the layout of the <pre> and <code> tags:
First the layout stuf is define for .code:
https://github.com/redimp/otterwiki/blob/98ec1d8646f5b28b1b374b4f5d43b4b6cd8747f6/otterwiki/static/css/otterwiki.css#L69
When dark mode is enable the .dark-mode .code comes on top (and changes only the background color):
https://github.com/redimp/otterwiki/blob/98ec1d8646f5b28b1b374b4f5d43b4b6cd8747f6/otterwiki/static/css/otterwiki.css#L79

Awesome. Thanks for those samples. I am still having a hell of a time getting the light/dark modes to work for the markdown syntax reference box. I suspect I need to better utilize one of their canned classes (like .card)

Finally got it working. Pull request here: https://github.com/redimp/otterwiki/pull/22

I looked into the pull request and I like the changes! Well done.
Page View: The right sidebar with the table of contents and the attachments is nice!
Editor: The Markdown Syntax looks nice! The Attachment list on the right, with the copy button is a great idea.
I would like to tweak a few things, will look into it tomorrow:
1.) with a small (x-axis) browser there is still the sidebar on the left, but the sidebar on the right is already hidden, so that there is no table of contents at all. I would like to letthe TOC appear on the left, in that case.
2.) Page View: The "Edit Page" Button on the sidebar on the left is imho too dominant (and the small button in the upper right very close to it, that looks like an unecessary duplication.
3.) Editor: I'm thinking about the large "Edit Attachment" Button, even more than the "Edit Page" Button it dominates the right side, where the more important buttons Save/Preview/Cancel are much smaller.
Thanks for the work, I apprecicate that!

1.) with a small (x-axis) browser there is still the sidebar on the left, but the sidebar on the right is already hidden, so that there is no table of contents at all. I would like to letthe TOC appear on the left, in that case.

Oh thats a good point. Another option would be to have a little tab-like button on the right to access that TOC column when the right column is collapsed (it would fly out overtop or something)

2.) Page View: The "Edit Page" Button on the sidebar on the left is imho too dominant (and the small button in the upper right very close to it, that looks like an unecessary duplication.

 Editor: I'm thinking about the large "Edit Attachment" Button, even more than the "Edit Page" Button it dominates the right side, where the more important buttons Save/Preview/Cancel are much smaller.

The "Edit Attachments" button could be a simple link, something like this:

I was thinking about this new sidebar I added and boiled down why it could be helpful and may be able to inform a future design

I noticed that both "nav bars" (left and top) were both very dynamic. Depending on what view you were in, the contents changed.
For some reason, this was making brain work a little hard to figure out how to get around as typical nav bars contain more high-level options - less contextual to the page you're on.
By adding the right-hand column, that would provide the "localize" contextual information for the given view you were in (edit/view)

Given what I wrote above, I don't think I got the design perfect in my PR, but maybe this helps better convey what I was noodling on 😊

After looking through your code and getting fond of the idea of an extra sidebar, I spent some time and tried to solve the right-hand-bar in the "gethalfmoon-way".

You find my approach in the branch feature-extra-nav.
I will cherry pick the features you've implemented on the weekend (if you aren't faster ;) ):

Attachments on the page view
Attachment in the editor
Markdown Syntax Popup

I reworked how the attachments are displayed in the sidebar, see feature-extra-nav. Will merge this into the main branch tomorrow.
But I'm still struggeling with the Markdown Syntax popup.

Awesome! I'll have a look!

Continued the work on the right sidebar, I guess this is ready to be merged. Will push the branch tomorrow.
Worked on the markdown help Popup and found a solution that fits right in. Will push that tomorrow, too.

After testing the feature-extra-nav for a few days, I must say, I like it. What to put in the exra-nav on the right is another discussion.
The attachments on the normal page view are more a distraction then useful:

If you want to make them useful, you have to name the properly. But, when you write a page, and copy and paste an image into it, it will be ranmed randomly, but the link in markdown is already alright, so you have to rename the image and then re-edit the page.

Markdown Help Popup added in: 5517bfa
extra-nav-bar added for xl screens in: 210e1bf


Feature/Enhance Server with custom InputUnion Validation

support Input Union
Enhance GraphQL server so that it recognises input object,  but does not break client Libraries

data Cat = Cat { catName :: Text }

data Dog = Dog { dogName :: Text }

type instance Kind Pet = INPUT_UNION

data Pet = CAT Cat | DOG Dog deriving (Generic, GQLType)

or Just
type instance Kind Pet = INPUT_UNION

data Pet = Cat { catName :: Text }  | Dog { dogName :: Text } deriving (Generic, GQLType)

union types like Pet , can be automatically derived as GraphQL enum for possible type names and input that contains actual types as fields
enum PetTags {
  Cat
  Dog
}

input Pet {
    typeTag: PetTags!
    typeCat: Cat
    typeDog: Dog
}

so server decodes input:
{
  "__typename": "Dog",
  "Dog" : {
     "dogName" : "Milo"
   }
}

to
Dog { dogName = "Milo" }

and input:
{
  "typeTag": "Cat",
  "typeDog" : {
     "dogName" : "Milo"
   }
}

will throw Validation Error
so we don't break client libraries because we use Standart GraphQL types and validate them differently in Server. and we don't modify GraphQL Schema

Besides that, I wonder if we could have custom names for each of these fields:
data DogType = Barky | Mildy | Eatty
data Dog = { dogName :: Text, typ :: DogType } -- avoid the "type" keyword

The example above would require something named typ when used as input argument.
Maybe it's better to give everyone a chance to override?

@horus i don't get what do you mean?  can you explain it with an concrete Example?
and thank you for your contributing.

Sorry I didn't make it more clear.
Simply put, in my example, I want to freely decide the actually parameter name of the field, i.e., I might call it type instead of typ. But in current implementation, the name of the parameter, if I read it correctly, is derived from its definition, resulting in an unchangeable one.
Compare to other implementation (haskell-graphql/graphql-api in question):
type Hello = Object "Hello" '[]
  '[ Argument "who" Text :> Field "greeting" Text ]

...here you can name the argument who, even type. It won't be conflict with the language keyword type.
Anyways, I'm not judging which one is superior, just bike-shedding. :-)

hi, i got now, but it is wrong topic for it. we could open pull request for it.
at the time only reserved name type is converted to type' so we can extend it and support all reserved names. there are  convertToJSONName and convertToHaskellName functions responsible for it.

i opened issue for it #207


Improve non-functional requirements

Improve non-functional requirements and research to detail more.

Added formalized non-functional requirements to requirements page.

Requirements wiki looks good to me. Closing this issue? @MericKeskin @enesYildiz69

Requirements wiki looks good to me. Closing this issue? @MericKeskin @enesYildiz69

Let's wait for the weekly meeting to talk over the issue and then close it if it is ok. @enesYildiz69 @orkunkilic

Issue completed, but not closed. Closing now.


Change syntax error handling to print in cli

Building off @schneems work in #3015 this moves the error handling higher in priority (to fix the handling) and then rather than re-raising uses the detailed_message as part of our exception printing producing:
bundle exec rspec spec/syntax_spec.rb

While loading ./spec/syntax_spec.rb a `raise SyntaxError` occurred, RSpec will now quit.
Failure/Error: require './spec/syntax.rb'

SyntaxError:
  --> /Users/jon/Code/Scratch/RSpecSandbox/spec/syntax.rb
  Unmatched keyword, missing `end' ?
    1  module Cutlass
    2    class LocalBuildpack
  > 3      private
  > 4      attr_reader :image_name
  > 5      def initialize(directory:)
    8    end
    9  end
  /Users/jon/Code/Scratch/RSpecSandbox/spec/syntax.rb:9: syntax error, unexpected end-of-input (SyntaxError)
# ./spec/syntax_spec.rb:1:in `require'
# ./spec/syntax_spec.rb:1:in `<top (required)>'
# ./.bundle/gems/ruby/3.2.0/gems/bundler-2.3.7/exe/bundler:4:in `load'
# ./.bundle/gems/ruby/3.2.0/gems/bundler-2.3.7/exe/bundler:4:in `<top (required)>'

Finished in 0.00011 seconds (files took 0.04363 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

Thanks!

Released in 3.13.0, apologies it has taken so long.


undef: false is ignored in strict mode

Checking
/*jshint undef: false */
function b() {
    "use strict";
    a();
}

Result:
Line 4: a();
'a' is not defined.

Expected result:
No errors.
Why is it annoying:
https://github.com/jshint/jshint/issues/347
Currently the only way to avoid errors when functions are defined out of order in an anonymous function (for example:
(function () {
     a();
     function a () {}
})();

) is not to use strict mode at all, and add an /* undef: false */ flag. The flag alone should suffice.

Related #349 #133 #347
I'll check to see if this is fixed with pull #349

This is working:
/*jshint undef: false */
function b() {
    "use strict";
    a();
}
function a() { }

Looks like in strict mode undef is set to true: https://github.com/jshint/jshint/blob/master/jshint.js#L2460

This was fixed in ce7626aca06fb202f20d3850961fc162a1c1db4c. I have also added a regression test for this issue. Keep in mind that it use strict still enables undef so the following code (without definition of a) will still fail:
function b() {
  "use strict";
  a();
}


Elasticbf: DirectIO

implement DirectIO without losing mmap and buffer IO

ReadHalf failed because of bug in LevelDB, just see  https://github.com/google/leveldb/issues/803


feat: improve loader to handle complex types

📦 Published PR as canary version: 0.3.0-canary.14.ffdd10e.0

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

:rocket: PR was released in v0.3.0 :rocket:


ltcube and gtlike / ltcube for stacking

Can anybody please explain why gtlike needs ltcube? In fermitools, expcube parameter is required for gtlike although I tried different ones with no difference. Also, in the python interface, a BinnedObs object is created like
obs = BinnedObs(srcMaps=srcmaps_file, expCube=ltcube_file, binnedExpMap=expcube_file, irfs='CALDB')
i.e. ltcube is needed. I thought gtlike only needs binned expmap because it contains exposures already weighted by cos(theta). So why ltcube in gtlike?
I'm asking because I want to do stacking. I understand I should sum individual count maps and binned exposure maps but what do I do with ltcubes?

The Fermitools are available in github. You can actually trace how the livetime cubes are used in the likelihood fit following the code directly:
https://github.com/fermi-lat/pyLikelihood/blob/master/python/BinnedAnalysis.py
https://github.com/fermi-lat/pyLikelihood/blob/master/python/SummedLikelihood.py
When needed, livetime cubes can always be added as needed. In the Fermitools this can be done with gtltsum as explained in
https://fermi.gsfc.nasa.gov/ssc/data/analysis/documentation/Cicerone/Cicerone_Data_Exploration/livetime_and_exposure.html


clean up obsolete branches

Since branches created with git-review have a common prefix, it should be relatively easy to clean up obsolete ones. We just have to determine when they are no longer needed. An additional command "clean" or "sweep" should delete all local and remote branches whose commits have already been merged.

"git review clean ID" should ...

remove the local and the remote branch that is connected to the specified request
always check whether there are unmerged changes, if so stop execution.
have a "--force" flag to delete the branches anyway
have the option "--all" (without the ID) to delete all of the branches (local and remote) that were created for review (with the matching prefix)
have the option "--mine" that works just like "--all" but only for branches that are connected to one of the user's reviews

Added in version 1.0.0


Do not filter __* fields

Originally posted by @michael-golfi in https://github.com/comigor/artemis/issues/31
I use __typename/id as a key for client side caching.
It's currently, on purpose, filtering any field that starts with __.

@comigor any leading _ could be changed to $ in Dart as names cannot contain $ in GraphQL.
https://graphql.github.io/graphql-spec/June2018/#sec-Names

I have the same issue as @michael-golfi. I plan to use __typename (with id) for client side caching. @klavs's suggestion of converting __ to $ makes sense to me.
@comigor what are your thoughts on this?
@michael-golfi, have you already built your caching layer? I need a normalized, offline-first cache and I'd love to collaborate on an existing project if one exists.

Yes, it seems a good aproach as (of course) underscore fields would be privatized in Dart.

Hi @michael-golfi
Could you try this branch while it awaits the review?
artemis:
    git:
      url: https://github.com/comigor/artemis.git
      ref: bugfix/underscored-items-another-solution

Hi @vasilich6107
I see the following property now on query:
  @override
  @JsonKey(name: '__typename')
  String $$typename;

It looks good so far and I would have to let you know when I start using the classes in my project.

Closed by #142


[flutter_tools] Don't crash when analytics fails to initialize

Description
The AnalyticsIO constructor can throw exceptions. Instead of letting that crash the tool, this change logs the error and continues without analytics.
Related Issues
https://github.com/flutter/flutter/issues/4674
Tests
I added the following tests:
Added a test to analytics_test.dart.
Breaking Change
Did any tests fail when you ran them? Please read [Handling breaking changes].

[x] No, no existing tests failed, so this is not a breaking change.

NB: The new parameter to the Usage constructor is non-@required.

ptal


supabase db reset doesnt reset supabase_functions.hooks and so

Describe the bug
supabase db reset doesnt reset supabase_functions.hooks and so
To Reproduce
Run supabase db reset targetting a db-url
Expected behavior

All db should be reset to clean state, and then restore should work.

Doing this:
DELETE FROM supabase_functions.hooks;
and then performing restore as per docs worked.


fix: type error in readme

peek should be called with a function returning the signal value

Thanks for the PR! The old example seems correct, peek accepts a function, calls it, and returns the value. A signal is a function. The example in this PR will return the signal itself and not the value.

You're totally right.
I missed that the function is not called and my fix for it is also wrong.
Sorry for bothering you 😀


More OTP18 stuff from ESL

According to Elvis:

Dependency 'riak_pb' is not using appropriate protocol, please change this to something like 'https://.*'


Trace messages should respect the TraceFilter if assigned

I was using this library to help debug binding issues in a WPF application and noticed you can't filter out trace messages based upon the ID. This PR adds a simple ShouldLog() check to the various TraceData methods.

Thanks, Michael! 👍


Update hosted library link on Getting Started page with each new version

The current insturctions on http://p5js.org/get-started/#your-first-sketch are confusing because they ask you to update the URL yourself. It would be easier for beginners if the link was functional and linked to the latest version so they can just copy and paste and get on to making a thing :)
Currently it should be replaced with: https://cdnjs.cloudflare.com/ajax/libs/p5.js/0.4.4/p5.min.js

closed with https://github.com/processing/p5.js-website/commit/1bff9babf1a57bd6813ab24186059ad3ef60ff1f


APIM cannot set managed certificate without internal error

Bicep version
Bicep CLI version 0.12.40 (41892bd0fb)
Describe the bug
When trying to deploy Azure API Management using bicep templates you cannot set a custom domain using the hostNameConfiguration when using a managed certificate. This was previously possible using 2022-04-01-preview but appears to have stopped working.
To Reproduce
Steps to reproduce the behavior:

deploy APIM without a host name configuration
Go into the Azure portal and setup a custom domain for your APIM instance
deploy the APIM using the template below, you will get an internal error.

Additional context
example bicep template
// Deploy Api Manager instance
param location string = resourceGroup().location

@description('Resource name prefix')
param envResourceNamePrefix string
param apimHostname string
param functionAppUrl string
param tier string = 'consumption'
param capacity int = 0

resource apiManagementInstance 'Microsoft.ApiManagement/service@2022-04-01-preview' = {
  name: '${envResourceNamePrefix}-apim'
  location: location
  sku: {
    capacity: capacity
    name: tier
  }
  properties: {
    virtualNetworkType: 'None'
    publisherEmail: 'support@email'
    publisherName: 'company name'
    hostnameConfigurations: [
      {
        hostName: apimHostname
        type: 'Proxy'
        defaultSslBinding: true
        certificateSource: 'Managed'
      }
    ]
  }
}

resource tfApi 'Microsoft.ApiManagement/service/apis@2021-08-01' = {
  name: 'MyApi'
  parent: apiManagementInstance
  properties: {
    format: 'swagger-json'
    value: loadTextContent('../apiDefinition.swagger.json')
    path: ''
    serviceUrl: functionAppUrl
    subscriptionRequired: false
  }
}

Can you share the complete error message that you are seeing? If you are getting an internal error, it is most likely an issue with the error handling logic in the APIM resource provider. Are you able to open a support ticket so this can be routed to the APIM team?

No response so closing.


TO API 2.0 - Retrieve current logged in user

Need a way to retrieve "current logged in user". This can be achieved a couple of ways:

Create an api endpoint like GET /api/2.0/tm_user/current or

The response of /api/2.0/login could look like this { Token: 'blahblah', userId: 50 } and then a call to /api/2.0/tm_user/50 would pull "current user"

The userid is encoded in the JWT Token. You should be able to get it from that?

Actually not 100% sure if that is available on the client, let me do some digging.

@knutsel - sounds good. thx

Looks like you can. https://thinkster.io/angularjs-jwt-auth sez so. Currently there's 2 claims in the token:
		token.Claims["userid"] = u.Id 		token.Claims["role"] = u.Links.RoleLink.ID 		token.Claims["exp"] = time.Now().Add(time.Hour * 72).Unix()
(which also answers your expire question from yesterday, it's 72 hours, not 24.

insert semicolons ;-)

yep, jwt is where it's at. no need for an apiendpoint to pull current user.


feat(plugins SDK):  implement go-plugin framework

Adds support to fanOut integrations to become actual plugins #195
Plugins SDK
I've chosen Hashicorp go-plugin and its gRPC variant over Go plugin package because

go-plugin has been used since 2016 in production in many Hashicorp tools (Vault, Packer, Terraform, ...)
Each plugin gets sandboxed in their own process and the communication happens through a gRPC API. This in turn has its own side benefits:

It force us to write the plugin SDK operating on serializable data, not shared structs, connections or similar.
The instability of a plugin does not affect the host (control plane in our case)
Supports plugin-reloading or re-attachment.
It will make it easy for us to offer a plugins development environment since no controlplane dependencies are injected.

Unlike stdlib plugins package. Hashicorp plugins don't require to be compiled with the exact same toolchain and it has a versioning / handshake mechanism.

Internal SDK changes
In practice, adopting go-plugin meant implementing the red boxes shown in the following diagram, which in short:

gRPC client implementation of the FanOut interface
gRPC server that calls the actual FanOut implementation (plugin logic)
Client/Server handshake mechanism with mutual TLS.
Dynamic loading of plugins on a configurable pluginsDir

Note that these are just implementation details of the SDK, from the plugin author or even controlplane point of view, nothing has changed, they are both interacting with the FanOut interface.
User-facing changes
To convert an existing extension to use this mechanism the user just needs to

Add cmd/main.go calling the Serve function. See Discord example
Compile the binary, no special flags required. I've added a Makefile in place already that can be used as template placeholder.
To enable it, place it in pluginsDir, directory configurable at boot.

Discord as plugin

discord has been implement as actual plugin which now contains a main.go with a plugins.Serve
The discord plugin is now built and packaged in the container image using go-releaser. In a following patch, our Helm Chart will get configured to load plugins from /plugins directory in the container image.

Plugin discovery
Currently, we have two ways of loading extensions, a) built-in and b) plugins (what this patch enables). The former are just initialization of extensions in the host memory, the latter are actual gRPC plugin connections.
The current code allows the co-existence of both methods and this is how the loading mechanism works at boot.
1 - Compiled plugins, named chainloop-plugin-[name], placed in the configurable pluginsDir will get loaded.
2 - built-in plugins will get initialized unless there is already a plugin registered with the same name.
This mechanism allow us to soft launch this feature and roll-out the migration of new plugins safely. For now, only discord has been translated.
Demo
See below a demo where I:

First load the controlplane with the regular built-in plugins.
Then I drop a compiled plugin to the plugins directory and restart the control-plane
You can see how the plugin is found and loaded
Now we have an additional plugin in the output that can be used

That new plugin is running in another process, and does not require re-compiling the controlplane :)

Caveats

Our implementation doesn't put an upper limit on payload size. But this new mode has an impact in memory usage. Until we enable streaming in the API, data chunking is not allowed, and hence transporting a 100MB artifact to the plugin will have a 2x tax on memory. That's why I'd suggest to roll-out for now plugins that don't operate on big artifacts

go-plugin uses hclog while we use zap, we need to do some work on standardizing logging formats.

@migmartri Is hot reloading plugin a thing or the control plane needs to be stopped for the plugins to load? 🤔

@migmartri Is hot reloading plugin a thing or the control plane needs to be stopped for the plugins to load? thinking
Awesome job btw, it's looking really really good mate! fire

Thanks!
hot-reloading is not implemented yet, the controlplane needs to be restarted. That an evolution of this feature indeed. My comment in the description is that go-plugin as it stands supports hot-reloading by keeping the plugin processes running and re-attaching to a known configuration.
Thanks for the feedback, very good points indeed! I'll add them as new issues :)

LGTM. I would merge it sooner than later and give it a try for a discord webhook plugin.

Awesome, let's go! 🚀


I26

For Issue #26
Please forgive the messy commit history, didn't realize I was working on Master the entire time. This commit only updates the README and adds an animated gif.

I came here, looking to add this in, found out you'd already made a PR. Much obliged!

Looks great, thanks!


Support for lookup into a multi-value dimension

Hi,
Lookups currently support a 1x1 and Nx1 mapping. Often there's a need to do a lookup against 1xN mapping. A common example is a lookup that maps userid to user-groups where a user may belong to more than one user groups. Denormalizing at ETL may not be desirable if user to user-group mapping changes over time.

Just FYI, this is not easy in the current way lookups are handled. I'm not sure if @b-slim has considered this case for https://github.com/druid-io/druid/pull/2291 and other LookupExtractor stuff

@sandeep217 i am currently working on this, will send a proposal soon!

We are evaluating Druid for our use-case and this is the one thing I believe we are lacking. @sandeep217 's example is very similar to our case since our mapping changes fairly regularly, so I would like to :+1: this feature.

@b-slim do you have the proposal ready? sirpkt's proposal looks like is for a different feature.

#7009


[Mobile] System.DllNotFoundException "onnxruntime-genai" when debugging on Android

Describe the issue
I am writting an app using MAUI Blazor and I'm trying to load a mocal locally on my phone. However, everytime it hits the line var model = new Model(modelPath);, it throws the exception System.DllNotFoundException "onnxruntime-genai".
I have tried copying dll files multiple times, using them, installing the package on multiple projects but nothing worked.
To reproduce
To reproduce, you may try to load a local model by copying it to your phone and using
       string modelPath = "/storage/emulated/0/onnx/cpu_and_mobile/cpu-int4-rtn-block-32";
Then simply load the model with the line var model = new Model(modelPath);, all this while debugging with your phone via USB.
Visual Studio Community Version 17.10.0
Urgency
This is a personal project so not of much urgency but I would really appreciate if I could have any help.
Platform
Android
OS Version
14
ONNX Runtime Installation
Built from Source
Compiler Version (if 'Built from Source')
Debug / Any CPU
Package Name (if 'Released Package')
Microsoft.ML.OnnxRuntime
ONNX Runtime Version or Commit ID
Newest
ONNX Runtime API
C#
Architecture
Other / Unknown
Execution Provider
Default CPU
Execution Provider Library Version
No response

GuiOliv The nuget package is not currently setup for mobile. I'll add this to our internal planning document, and we will decide when we would be able to add support for this.

Since this is a duplicate of https://github.com/microsoft/onnxruntime-genai/issues/496, I'll close this one. We can continue discussion on the other issue.


Mode for colorblind people

One solution for colorblind mode is to make everything black and white, and then have "T/F" markings for the blocks

Take a look at what I did at https://hodl.camp/, there is a low-vision icon on the top that toggles between different palettes. The palettes come from https://colorbrewer2.org/, which are built in into chroma-js.


Dimmer issue/problem?

Hi there, I'm looking (as I can't find that in the documentation) for a possibility to "code" (somehow?) functionality which will give an option to use single/double/triple/quadruple press and long press together to exposed via Homebridge Philips hue dimmer switch. Is it possible?. I'm asking because via Homekit I can fully control multiple vendors Hue, Ikea and the cheapest Milight bulbs. None of known to me 3rd parties tools like iConnectHue or others can't do that. So I will repeat my question is it possible to achieve that via hue plugin to expose more actions than single/long press for buttons 1,4 and single press for the rest of them?

No, the Hue dimmer switch only reports press, hold, release, and release after hold.

Ah, so it is stateless. Hmm, any possibilities to control the state, even temporary let's say for the 30seconds, the status could be sored locally (posix file) or in any key-value storage memcached/consul/etc? Did you try to investigate how it works over iConnectHue where it is possible to program more sophisticated action mentioned by me?

In theory, I could, I could check whether a second, third, fourth click happens within a given time period and issue a Double Click to HomeKit.  I’m not going to do that, because it won’t work reliably with a Hue bridge that needs to be polled, since it doesn’t send notifications.  Because of this polling, button events in brief succession will go unnoticed.

Understood. In theory, iConnectHue register new "service" in Hue API, which is treated as a separate device?. That is my theory about how iConnectHue developers achieve that. So the reliability raises if we concern this type/method. Every other press for every button is registered as another device? Maybe that is the clue for achieving that via Homebridge. This functionality programmed over iConnectHue works well if you understand how it works, but iConnectHue can't control bulbs which are not connected via Hue Bride so it could be a nice upgrade for this plugin. It could be enabled on-demand Attaching a screenshot with the mentioned registered new devices if it helps you somehow?:

iConnectHue register new "service" in Hue API, which is treated as a separate device?. That is my theory about how iConnectHue developers achieve that.

If they do that, it should be visible in the debug dump file, as some CLIP sensors and associated rules.

I can see only events which are associated with predefined rules/events like:
`homekit button single press
homekit button long press'
Double/Tripple pressing aren't visible in log file, so that theory fallen down now :-)
Other options? Can you help me with that?

The dump file, see https://github.com/ebaauw/homebridge-hue#debug-dump-file.

This one, ok. These xfiredesigns devices appear after re-editing dimmer actions in their app. I'm not sure are them responsible for double/triple presses.
"name":"Press state XFDHueTap2Btn1","type":"CLIPGenericStatus","modelid":"ButtonState","manufacturername":"xfiredesigns","swversion":"1.0","uniqueid":"A718F3E1-8D11-45FA-8B1B-768973AC","recycle":false},"17":{"state":{"status":0,"lastupdated":"2020-01-06T17:26:52"},"config":{"on":true,"reachable":true},"name":"Press state XFDHueTap2Btn2","type":"CLIPGenericStatus","modelid":"ButtonState","manufacturername":"xfiredesigns","swversion":"1.0","uniqueid":"B5D78CD8-6F5D-4D6A-841D-23BC6D9D","recycle":false},"20":{"state":{"status":0,"lastupdated":"none"},"config":{"on":true,"reachable":true},"name":"Press state XFDHueDim3Btn1000","type":"CLIPGenericStatus","modelid":"ButtonState","manufacturername":"xfiredesigns","swversion":"1.0","uniqueid":"CD13BFC0-1412-49DF-8908-4967A029","recycle":false}},"resourcelinks":{"28080":{"name":"przełącznik Salon","description":"Resources of przełącznik Salon","type":"Link","classid":10011,"owner":"***********************************6","recycle":false,"links":["/sensors/3","/rules/9","/rules/10","/rules/8","/rules/7","/rules/6","/rules/5","/sensors/20","/scenes/0VflTppTdr465t3","/scenes/utZEnL8hEm6ZfwW","/scenes/J5a4yFIWGFYDN5K","/scenes/bBvJnQl5JhZD17H"]},"55694":{"name":"przełącznik","description":"Resources of przełącznik","type":"Link","classid":10011,"owner":"***********************************6","recycle":false,"links":["/sensors/2","/rules/3","/sensors/17","/rules/2","/sensors/16","/rules/20","/rules/1","/rules/4","/rules/21"]}}}]}

Looks like.  If you can attach the file, I'll have a detailed look.

homebridge-hue.json.gz

OK, they do not expose button events for double press, etc; they simply activate scenes from the rules on the Hue bridge.  The CLIPGenericStatus sensor counts how many times the button on the Hue dimmer has been pressed recently.  This count is reset automatically after 10 seconds.  They bluntly recall a (different) scene on each press, hoping the last scene recalled will take precedence (which in my estimation could be challenging on larger networks).  I think they'll miss two consecutive presses within a second.
Homebridge-hue exposes Hue bridge resources to HomeKit; it's not a full-blown Hue client.  It won't be maintaining Hue bridge rules (not groups, scenes, CLIP sensors, ...), like iConnectHue.
I suppose in theory, you could create a similar set of rules to drive a CLIPSwitch sensor.  I would be willing to support that sensor in homebridge-hue, so you'd be able to expose that to HomeKit, supporting Single Press, Double Press, and Long Press.  Creating the sensors and corresponding rules, however, is beyond homebridge-hue.

From my point of view, I'm interested in achieving only the mentioned feature like double/triple/.. press. I've tested this it via iConnectHue again, and obviously, you are right, it works sequentially. So there is no point in implementing this questionable function. Thank you for your time, I appreciate that.


How do i style the control buttons on the plugin ?

Not support yet.
You can overwrite the style by #someID .btn-left { ... }.

okay thank you as that works well


Advanced Filtering

Rather than just matching channels that contain a specified string, I'd like to be able to exclude channels that contain a string, or start/end with a string.
(I tried using negative lookarounds, but go doesn't support them)

If there's an exclude option added, it would make sense to implement #64 for it as well.

Implemented in v1.0.0!