Treating constants like state objects

As mentioned in this Twitter thread (https://twitter.com/Elttob_/status/1432242081368530949):

[The downside of state objects] is that, when dealing with state objects, you still need to make a case for constants. In some Fusion prototypes I experimented with a Statify() or makeState() function to help with this. If you give it a state object, it just returns that state object. Otherwise, it'll wrap the value in a state-like API. This means you can write your code once for state objects, then just pass your inputs through makeState() to have it work for constant inputs too.

Hypothetical usage:
local function printValue(x)
    x = makeState(x)
    print(x:get())
end

local constant = "I am constant"
local state = State("I am state")

printValue(constant) --> I am constant
printValue(state) --> I am state

This is one of the first things that I made a utility function for when starting with Fusion, and would be a great addition.
Being part of the public namespace / main module exports is something I wouldn't be a fan of, however. I like how rocket.rs does it, splitting main functionality and utility into rocket and rocket_contrib, with the latter containing utilities that most if not all large scale projects would use. This would also give users the choice to implement those said utilities themselves, or simply use a different variant of them, without polluting the main modules namespace.
Another useful utility function that I've been using with Fusion, which functions similar to the proposed makeState, could be something like unwrapState:
local function unwrapState(stateOrValue, registerAsDependency)
	if stateOrValue is a state then
		return stateOrValue:get(registerAsDependency)
	end
	return stateOrValue
end

Still a bit confused on how we want this implemented. Do we want this to be Fusion.Statify(state | constant) or do you want to add something like what @filiptibell said and create something like fusion_contrib separate from Fusion?
If we want the latter, do we want:
a) To implement it into the main fusion program (i.e. do Fusion.contrib.XYZ where "XYZ" is just some utility that most people would use.
b) To implement it into a separate organization, and users can add them manually or via wally by doing something like ``XYZ = "fusion_contrib/xyz@VERSION"
Once I get some feedback on how we want this implemented I'll work on getting it added.

I would argue that it's better to separate them for optimization sake.

Do you have benchmarks to show that a function like this poses any performance issue? Optimisation shoukd not a primary concern until it's proven to be a problem with data.
In my mind it's much more important that developers have a good experience with Fusion than it is to always run the most optimal code path theoretically possible, though of course this is not an excuse to write horribly slow code.

This is completely unnecessary for constants, and would just result in us creating a lot of unnecessary objects. (Think creating an Observer object for every single property in the entirety of someone's UI code). For that reason I don't think this is viable long-term.

This would not be used in such a fashion. For one, this is a user-facing utility, not something for use inside Fusion itself. Secondly, it's not mandated to be used, so where performance is needed you cna manually handle both cases. Thirdly, most uses for statify would be when components are processing custom props - which is largely limited to one-offs - and not used for every state object. Fourthly, the overhead is entirely at create time - constant-value state objects are completely weightless in terms of run time performance due to the push nature of the reactive graph.

The optimization basis was specifically in reference to memory usage, rather than speed.
That being said, I misunderstood what you meant by this, and thought you were specifically referring to what we were doing internally. As a result all I can say is disregard what I said... totally my fault.

I've so far identified three different solutions to this problem, which may not necessarily be the same as the solution proposed here.

a function that transforms constants into state, but leaves state alone - meaning you can operate on constants just like they're state (this is what makeState is proposed to do)
a function that, given a constant, returns it; but given a state, returns the value of the state
a function that wraps your component functions, automatically turning constants in your props into states

Some pseudocode examples:
local const = "const"
local state = Value("state")

-- option 1
local function makeState(x)
    return if x is state then x else { get = function() return x end }
end

local function process(x)
    print(x:get())
end

process(state) -- prints "state"
process(makeState(const)) -- prints "const"

-- option 2
local function get(x)
    return if x is state then x:get() else x
end

local function process(x)
    print(get(x))
end

process(state) -- prints "state"
process(const) -- prints "const"

-- option 3
local function wrap(component)
    return function(props)
        local realProps = {}
        for key, value in pairs(props) do
            realProps[key] = makeState(value)
        end
        return component(realProps)
    end
end

local component = wrap(function(props)
    print(props.value:get())
end)

-- prints "state"
component {
    value = state
}

-- prints "const"
component {
    value = const
}

Option 4: if we want to solve a more narrow version of this problem, and also tackle the issue of choosing which dependencies should be registered as dependencies, we could introduce a use() function for Computed callbacks:
local function use(x)
    if x is state then
        useDependency(x)
        return x:get()
    else
        return x
    end
end

local function Computed(callback)
    -- super duper simplified
    local self = {}
    function self:update()
        self.value = captureDependencies(callback, use)
    end
    function self:get()
        return self.value
    end
    return self
end

local state = Value("state")
local const = "const"

local computed = Computed(function(use)
    -- because we used use() on `state`, the computed will update when `state` changes
    return use(state) .. const
end)

local computed2 = Computed(function(use)
    -- because we didn't use use() here, the computed will *not* update when `state` changes
    return state:get() .. const
end)

So I came up with this stupid idea. (But I'm still going to say it 🙂)
What if all data has a :get function. This doesn't mean it's a state object, more like a prop object. The prop object won't update. In the new function will prop just behave like some data.

This has been formalised as the unwrap() function, which is currently slated for Fusion v0.3, so deferring to the Fusion v0.3 project board as such.


Docker-compose not working

When building the Docker images on OS X (with latest version of Docker), the Mongo image starts fine, but the Tribeca image fails:
warn:    --minUptime not set. Defaulting to: 1000ms
warn:    --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
error:   Cannot start forever
error:   script /tribeca/tribeca/service/main.js does not exist.

I just did an install using docker-compose and that worked fine out of the box. You could try to remove all images and retry with docker-compose.

@magicdude4eva I've run into this issue too and it drove me insane. I can't remember specifically what had caused it, but I think it might be due to running grunt compile and then running docker-compose up -d --build. grunt compile creates a /tribeca folder in the root of the app which gets built into the docker image which (I think) is throwing things off. In any case, cloning the repo into a new location and immediately running docker-compose up -d --build fixed this issue for me.


Improved change-detection for existing environments and install python when using env file

This PR has various improvements for the handling of conda env and spec files:

Tox will now detect changes to env and spec files and recreate the environment when changes are detected.
Python will be installed in the conda env if a env file is used. Previously python was only being installed when no env file is used. This is done by first creating the env using the env file, then installing python to it.
This does not detect conflicts between env file and python version. Detecting conflicts, like it is done when not using an env file would require adding python to a temporary copy of the env file, which would require adding a yaml parser as a dependency to tox-conda, which is why I decided against it.

I'll look into it. It could take some time though, as I first need to work on something else.

Sounds good, also please have a look to the tests that fail.

Codecov Report

Merging #137 (70ea3ac) into main (dd56190) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #137      +/-   ##
==========================================
+ Coverage   99.27%   99.30%   +0.02%
==========================================
  Files           4        4
  Lines         276      286      +10
  Branches       14       14
==========================================
+ Hits          274      284      +10
  Partials        2        2

Flag
Coverage Δ

tests
98.60% <100.00%> (+0.05%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

tests/test_conda_env.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dd56190...70ea3ac. Read the comment docs.

I decided to use a yaml parser after all, because the result is a lot cleaner.
The parser I used (ruamel.yaml) is the same one used by conda itself, although conda currently uses their own fork of it, with plans to migrate back to upstream.
I hope adding this as a dependency is acceptable. If not I can still revert this to the old solution, but that one has some drawbacks. It for example won't detect it the python version in the conda_env.yaml conflict with the python version set by tox, but just overwrite it.
Installing python into tox envs created with a conda_env.yml is already tested by the adjusted tests. I still need to add tests for the change detection.

Sorry for the ping @AntoineD, but is there an ETA, when this might get reviewed (and released)?

Hi @AdrianFreundQC, sorry for the tardy answer and thank you for taking the time to create this PR!
I will review it at the end of September, it will be release right after.
Cheers.

Any updates?

Hello @AdrianFreundQC,
I'm really sorry, I've been more busy than expected lately.
I'll have a look ASAP.

Hi @AdrianFreundQC,
I had a first look at your PR: I am wondering why you add python to an environment yaml file.
Shouldn't an environment yaml file be self contained and usable without tox, thus already contain python if the target env requires it? What is the use case that requires this explicit addition?

The explicit addition is required to enable testing against multiple python versions. A user might have a environment.yaml containing the dependency python>=3.7 and a tox.ini with tox environments py37, py38, py39 and py310. Tox should then make sure that the correct python version is installed in each environment.
If in this example the tox.ini contains py36 conda (called by tox) will complain about unresolvable dependencies, pointing the user to fix either his tox.ini or environment.yaml.
Of course the disadvantage to this approach is that it will still install python, even if it's missing from the environment.yaml, which might hide errors there.
I think that this is a smaller drawback compared to not supporting py3X envs, but if you want I can try implementing a manual check for this case.

I do not think that tox-conda should handle this, this adds python whereas in some context you may need an alternative implementation (pypy, ...) or not need any python at all since anaconda is language agnostic and tox v3 can be used without python too (AFAICT tox v4 usage will be even more independent of python).
Also some may want to pin the dependencies for improving the reproducibility of the test environments, but the higher bound of the dependencies versions often depend on the python version itself which makes it difficult to have a single environment file.
The usual way to deal with this situation that I have seen and used is to create as many environment files as necessary (like conda-env-py39.yml, ...) with a tox.ini like:
[testenv]
...
conda_env = conda-env-{basepython}.yml
...

When possible, symbolic links could be used if the environment files are identical.

I think the current behavior is very unintuitive.
When specifying your dependencies using conda_deps tox will install a python according to basepython for you (This currently only seems to work for cpython, but shouldn't be difficult to extend to pypy and possibly others).
When specifying your dependencies using conda_env tox will just ignore basepython, possibly silently using a python version that's different from basepython.
If you specify both a conda_env and at least one dependency using conda_deps tox will install python for you again.
To sum up: Currently tox installed python to the conda env if conda_env is not given or conda_deps is given
In my opinion the optimal behavior would be to always install python when an basepython is given in the tox env name, independent of if conda_env, conda_deps or both are used, and not install python when the tox environment has no explicit basepython.
The problem with this is that it might break existing tox.inis, as currently python is also installed if no explicit basepython is given (as long as either conda_deps is given or conda_env is not given).
Because I didn't want to cause this kind of breakage I decided to just always install a python in this PR.
None of this should stop people who want to use multiple conda envs with pinned dependencies from doing that. Conda will just unify the pinned requirement from the yaml with the generated requirement generated by tox, which should be no problem as long as the env file has a sane name (pinning 3.10.1 in environment-py310.yaml should work; pinning 3.9.5 in environment-py310.yaml will fail to unify with the generated requirement python 3.10.*)

On second thought I agree with you, this is better than the current state.

Thank you very much @AdrianFreundQC!


SNS Commit 1

Original SNS implementation. Added SNSListener and EventParser

Also make sure you run build to make sure there is no checkstyle or errorprone issues. I will enable CI after we have some stable code here.


Read Long Characteristic

Hi,
as graduation project, i'm developing an hybrid application for the monitoring of vital parameter, which requires Bluetooth Low Energy.
I'm using ng-cordova-bluetoothle plugin and all the methods that I have used so far are working.
Now I want to read the frame from the BLE card to plot charts, but I have a problem, the frame length is 100bytes and I found that the maximum that can be read is 22bytes. have you any idea how I can use the read() to read this frame? is that even possible ?
thank you,

What platform are you on?

Also, this is most likely not an issue with ng-cordova-bluetoothle. I'd close this bug and open one on the plugin's repository.

ok, thank you.

Closing due to previous comments


Make params an optional argument in all methods

@moddular code review if you get a moment?

looks fine to me.


Error in logs after enable push notifications

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version): 0.59.2
Python release (python3 --version): Python 3.4.2
**Component/platform:**notify
Description of problem:
After update when enable/disable notifications exception is raised. Notifications are send to old devices, but not to new
Expected:
No errors.
Problem-relevant configuration.yaml entries and steps to reproduce:
notify:
  - name: google
    platform: html5
    gcm_api_key: !secret gcm_api_key
    gcm_sender_id: !secret gcm_sender_id

Traceback (if applicable):
2017-12-08 11:38:06 ERROR (MainThread) [homeassistant.util.json] Failed to serialize to JSON: /home/pi/.homeassistant/html5_push_registrations.conf
Traceback (most recent call last):
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/util/json.py", line 38, in save_json
    data = json.dumps(config, sort_keys=True, indent=4)
  File "/usr/lib/python3.4/json/__init__.py", line 237, in dumps
    **kw).encode(obj)
  File "/usr/lib/python3.4/json/encoder.py", line 194, in encode
    chunks = list(chunks)
  File "/usr/lib/python3.4/json/encoder.py", line 422, in _iterencode
    yield from _iterencode_dict(o, _current_indent_level)
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 429, in _iterencode
    o = _default(o)
  File "/usr/lib/python3.4/json/encoder.py", line 173, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: b'lJ9UpNjRI6S3Gp514vKBQ==' is not JSON serializable
2017-12-08 11:38:06 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/util/json.py", line 38, in save_json
    data = json.dumps(config, sort_keys=True, indent=4)
  File "/usr/lib/python3.4/json/__init__.py", line 237, in dumps
    **kw).encode(obj)
  File "/usr/lib/python3.4/json/encoder.py", line 194, in encode
    chunks = list(chunks)
  File "/usr/lib/python3.4/json/encoder.py", line 422, in _iterencode
    yield from _iterencode_dict(o, _current_indent_level)
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 396, in _iterencode_dict
    yield from chunks
  File "/usr/lib/python3.4/json/encoder.py", line 429, in _iterencode
    o = _default(o)
  File "/usr/lib/python3.4/json/encoder.py", line 173, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: b'lJ9UpNjRI6S3Gp514vKBQ==' is not JSON serializable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/aiohttp/web_protocol.py", line 410, in start
    resp = yield from self._request_handler(request)
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/aiohttp/web.py", line 326, in _handle
    resp = yield from handler(request)
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/aiohttp/web_middlewares.py", line 93, in impl
    return (yield from handler(request))
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/components/http/ban.py", line 58, in ban_middleware
    return (yield from handler(request))
  File "/usr/lib/python3.4/asyncio/coroutines.py", line 143, in coro
    res = yield from res
  File "/usr/lib/python3.4/asyncio/coroutines.py", line 143, in coro
    res = yield from res
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/components/http/__init__.py", line 430, in handle
    result = yield from result
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/components/notify/html5.py", line 176, in post
    if not save_json(self.json_path, self.registrations):
  File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/util/json.py", line 45, in save_json
    raise HomeAssistantError(error)
homeassistant.exceptions.HomeAssistantError: b'lJ9UpNjRI6S3Gp514vKBQ==' is not JSON serializable

Additional info:

I have also had issues with the notify.html5 platform as well with 'is not JSON serializable' exceptions.  Happens when trying to turn off notifications on a browser that was previous subscribed.
Home Assistant version: 0.59.2
Python version: 3.5.3

I am also getting these messages and have not tried to enable it or disable on any additional devices

Same here - unable to unsubscribe from push notifications with the following error in log
17:16 util/json.py (ERROR)```

Seems to be related to #10751

It looks like this is now causing me not to get notifications consistently if at all anymore.  Have tried to re-register my devices but same thing.

Have you edited the file to set a proper device name?
Check my comment in #10751

Yes, I have and the issue still persists.
On Tue, Dec 26, 2017, 14:43 Mikael Bergemalm<EMAIL_ADDRESS>wrote:

Have you edited the file to set a proper device name?
Check my comment in #10751
https://github.com/home-assistant/home-assistant/issues/10751
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/11024#issuecomment-354005652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC3RiHrB1JK0QFWDtBGKqPy4OGmYcjwxks5tEUxMgaJpZM4Q618y
.

--
Tony Hammond

@tonyh220 Did you check my comment in linked issue?
The problem seems to be added newline at end of file if edited with editor adding it. Removing the newline solves both notify and errorlog messages for me.


Dashboard connection refused with Calico CNI Plugin

If using fixed dind-cluster-v1.10.sh script  with Calico CNI Plugin (calico or calico_kdd)
Then Dashboard is not accessible :
Error: 'dial tcp <IP_ADDRESS>:9090: getsockopt: connection refused'
Trying to reach: 'https://<IP_ADDRESS>:9090/'%  ```

I am not expert about CNI & Kubernetes network but adding
dind::setup_external_access_on_host  after calico setup solved the issue.

A dind-cluster-v1.10.sh clean was needed ! (to reinitialize the network I presume ..)
Now it works out of the box ..


feat!: Rework the client

BREAKING CHANGE: Rework the client
The main changes are:

Add an OrderTrackingClient which is a subclass of a Client but will track all limit orders
Remove the need to add pairs to the client. Now this is handled automatically
Split out building and executing transactions. This allows a user to build a transaction and then take decisions on if they should execute it based on gas cost, etc. Additionally, if gas is not provided to the build transaction methods it will simulate if they will succeed on chain.
Add a transaction handler. Now we can interpret events for all contracts we care about, which is much better in my opinion.
Added the ability to interact with ERC20's easily using the client (adding approve and transfer methods as transaction builders).
Consolidated so we only need to manage 1 set of abis in the network_config/abis/ folder and tweaked some other network config.
Instantiated all contracts on the Network. I think this makes things cleaner. So e.g a network will now have a RubiconMarket instance.
Added a token Dict to the Network object. This dict maps from both the address and the symbol to the ERC20 object.
Removed unneeded code, abis etc.

Additionally updated all tests and docs accordingly.
What type of change was this

[ ] none - deployment should be skipped
[ ] fix - fixing bugs and adding small changes (X.X.X+1)
[ ] feat - introducing a new feature (X.X+1.X)
[X] breaking - a breaking API change (X+1.X.X)

@adamamsmith this is a great PR that does a meaningful rework of the repo, i have to step out but will continue with this review when i can.
from my first pass, i think the biggest takeaway that i have is that we should attempt, wherever possible, to avoid deprecating existing functionality, and instead begin issuing DeprecationWarnings indicating users should migrate to the newer functionality. to achieve this, there seems to be two paths we can take:

including past structure/functionality as it was: this may be the easiest path forward, but would introduce a lot of unnecessary overhead code
updating past functionality to pass through parameters to the new functions: i think this is probably the best path forward. it will require us to keep some outdated classes to do so (Transaction) for example, but should be more manageable in the long-term.

lets discuss this more, happy to help lead efforts on option 2, will a good process to do for a thorough code review

@denverbaumgartner I think we should hop on a call about your comments, specifically: https://github.com/RubiconDeFi/rubi-py/pull/90#issuecomment-1675484127
I have read through all of them and I agree that following some kind of path to deprecating methods gracefully is a good practice. I had actually started out down this route however the changes became quite substantial and I wasn't sure it made sense to keep trying to support old functionality. But let's have this discussion on a call 👍

In line with our conversation today @adamamsmith, here is a list of all current interface changes that are proposed in this pr. this list can serve as our guide for: 1) knowing what would cause a breaking change, and 2) presenting a list of functions that we can adapt to be composable with new functionality/patterns
client.py
class Client:
reworks:

[ ] reworks self.key -> self._key
[ ] reworks @classmethod - def from_http_node_url param structure
[ ] reworks _start_orderbook_poller param structure (Pair class removed)
[ ] reworks cancel_limit_order param structure (Transaction class removed)
[ ] reworks batch_update_limit_orders param structure (Transaction class removed)
[ ] reworks batch_cancel_limit_orders param structure (Transaction class removed)
[ ] reworks get_offers param structure & return types
[ ] reworks get_trades param structure & return types
[ ] reworks _handle_transaction_receipt_raw_events param structure

moves:

[ ] moves self.market -> self.network.rubicon_market
[ ] moves self.router -> self.network.rubicon_router
[ ] moves self.tokens -> self.network.tokens
[ ] moves _update_active_limit_orders -> OrderTrackingClient
[ ] moves _delete_active_limit_order -> OrderTrackingClient

removes:

[ ] removes self._pairs
[ ] removes self.active_limit_orders (handled in OrderTrackingClient)
[ ] removes add_pair
[ ] removes get_pairs_list
[ ] removes update_pair_allowance
[ ] removes get_pair
[ ] removes place_market_order (Transaction class removed)
[ ] removes place_limit_order (Transaction class removed)
[ ] removes batch_place_limit_orders (Transaction class removed)
[ ] removes get_network_tokens (handled in self.network.tokens now)
[ ] removes _update_asset_allowance
[ ] removes _check_allowance

contracts/market.py
class RubiconMarket:
reworks:

[ ] reworks RubiconMarket param structure (abstracts wallet & key to the TransactionHandler, removes contract_type)
[ ] reworks offer param structure & return type
[ ] reworks cancel param structure & return type
[ ] reworks batch_offer param structure & return type
[ ] reworks batch_cancel param structure & return type
[ ] reworks batch_requote param structure & return type
[ ] reworks sell_all_amount param structure & return type
[ ] reworks buy_all_amount param structure & return type

moves:

[ ] n/a

removes:

[ ] removes @classmethod - def from_network

contracts/router.py
class RubiconRouter:
reworks:

[ ] reworks RubiconRouter param structure (abstracts wallet & key to the TransactionHandler, removes contract_type)
[ ] reworks multiswap param structure & return type
[ ] reworks swap param structure & return type

moves:

[ ] n/a

removes:

[ ] removes @classmethod - def from_network

contracts/erc20.py
class ERC20:
reworks:

[ ] reworks ERC20 param structure (abstracts wallet & key to the TransactionHandler, removes contract_type)
[ ] reworks approve param structure & return type
[ ] reworks transfer param structure & return type
[ ] reworks transfer_from param structure & return type

moves:

[ ] moves @classmethod - def from_address -> BaseContract

removes:

[ ] removes @classmethod - def from_network
[ ] removes increase_allowance
[ ] removes decrease_allowance

network/network.py
class Network:
reworks:

[ ] reworks Network param structure

moves:

[ ] n/a

removes:

[ ] removes @classmethod - def from_config

class RubiconContracts - removed
class ContractRepr - removed
contracts/contract_types/events.py
class BaseEvent:
reworks:

[ ] n/a

moves:

[ ] n/a

removes:

[ ] removes @staticmethod - def builder -> from_raw (param structure unchanged)

contracts/contract_types/transaction_reciept.py
class TransactionReceipt:
reworks:

[ ] reworks TransactionReceipt class variables

[ ] contract_address -> created_contract_at_address
[ ] (effective_gas_price, gas_used, l1_fee, l1_gas_price, l1_gas_used, l1_fee_scalar) -> transaction_cost_in_eth
[ ] transaction_index -> position_in_block

[ ] reworks @classmethod - from_tx_receipt (raw_events param List[BaseEvent | EventData] -> List[Union[BaseEvent, EventData]]

moves:

[ ] n/a

removes:

[ ] n/a

contracts/base_contract.py
class ContractType - removed
class: BaseContract
reworks:

[ ] reworks reworks BaseContract param structure (abstracts wallet & key to the TransactionHandler, removes contract_type)
[ ] reworks @classmethod - def from_address_and_abi param structure (abstracts wallet & key to the TransactionHandler, removes contract_type)
[ ] reworks _transaction_params (adds wallet to constructor)

moves:

[ ] n/a

removes:

[ ] removes get_transaction_receipt
[ ] removes _default_transaction_handler -> execution handled in transaction_handler
[ ] removes _wait_for_transaction_receipt
[ ] removes _process_receipt_logs_into_raw_events

data/market.py
class: MarketData
reworks:

[ ] reworks MarketData param structure (removes subgrounds, network) & (renames subgraph_url -> url, subgraph_fallback_url -> fallback_url, network_tokens -> tokens
[ ] reworks MarketData class variables (self.sg -> self.subgrounds, self.subgraph_url -> removed, self.subgraph_fallback_url -> removed, self.network -> removed, self.offer_query -> self.offer, self.trade_query -> self.trade)
[ ] reworks get_offers param structure & return type
[ ] reworks get_trades param structure & return type

moves:

[ ] n/a

removes:

[ ] n/a

rubicon_types
rubicon_types/order_query.py - removed & moved functionality to MarketData
rubicon_types/trade_query.py - removed & moved functionality to MarketData
rubicon_types/pair.py - removed
data/rubicon_types/order.py
class: ActiveLimitOrder - renamed LimitOrder
reworks:

[ ] reworks ActiveLimitOrder params to include open

moves:

[ ] n/a

removes:

[ ] n/a

class: Transaction - removed
class: OrderEvent
reworks:

[ ] reworks @classmethod - from_event param structure
[ ] reworks @classmethod - _build_order param structure
[ ] reworks @classmethod - from_event param structure

moves:

[ ] n/a

removes:

[ ] n/a

Change Overview
the largest structural changes are as follows:

[ ] abstracts transaction execution to the TransactionHandler, major classes now build transaction parameters to be executed by the handler
[ ] reworks data functionality to be more modular and contained within the data folder
[ ] removes the idea of pairs throughout the repo, transitioning to an ERC20-ERC20 approach

Approaches to maintain composability

[ ] in general, our goal should be to avoid forcing breaking changes whenever possible. we can achieve this by supporting many of the old functions & their types, and routing those functions through their replacement interfaces
[ ] where needed, have breaking changes that throw DeprecationWarnings when a user attempts to utilize the now deprecated functions

TODO

[ ] decide which, if any, functions/types should result in breaking changes
[ ] for all other functions/types that are currently slotted to be deprecated, ensure they are still useable while throwing soon-to-be deprecated warnings


Ci workflow

Implemented CI workflow with Github Actions: Setup environment, run example scripts, build documentation (analog to sfs-python).
Also includes changes from the 'enhance_doc' branch and I also tried to work in the comments from the pull request.
Examples are moved to ./doc/examples with a symbolic link from ./examples (same as in sfs-python).

Since there are no objections so far, I merge to master.


avoid re-generating meta examples on make

Currently, typing make (with meta examples enabled) generated output like
[  1%] Generating example gaussian_processes-gaussian_process_classifier
[  2%] Generating example binary_classifier-lda
[  2%] Generating example binary_classifier-linear_svm
[  2%] Generating example binary_classifier-kernel_svm
[  2%] Generating example regression-kernel_ridge_regression
[  2%] Generating example regression-krr_nystrom
[  2%] Generating example regression-linear_ridge_regression
[  2%] Generating example regression-multiple_kernel_learn

And then typing make again after the first one has finished, all meta examples are generated (and compiled) again. This issue is to stop that happening. This used to be working, so part of the solution will be to investigate why it does not work anymore. Note this will also affect all the other compiled target langauges.

fixed in #3659


update mfem 4.3 (3.2RC)

Description
Resolves #5579 and  #4983
TODO:

[x] Need to update FMS
[ ]  Add baselines for new tests

Type of change

[ ] Bug fix
[ ] New feature
[ ] Documentation update
[x] Other (TPL UPDATE)

How Has This Been Tested?

Checklist:

[x] I have followed the style guidelines of this project.~~
[x] I have performed a self-review of my own code.~~
[x] I have commented my code where applicable.~~
[ ] I have updated the release notes.~~
[x] I have made corresponding changes to the documentation.~~
[x] I have added debugging support to my changes.~~
[x] I have added tests that prove my fix is effective or that my feature works.~~
[x] I have confirmed new and existing unit tests pass locally with my changes.~~
[ ] I have added new baselines for any new tests to the repo.~~
[x] I have NOT made any changes to protocol or public interfaces in an RC branch.~~
[x] I have assigned reviewers (see VisIt's PR procedures for more information).~~

@cyrush, FMS v0.2 is now released: https://github.com/CEED/FMS/releases/tag/v0.2
Let me know if there's anything I can do to help with this PR.

I installed the new libraries on quartz. I'm in the process of building the branch and generating new baseline images for mfem and fms.

@cyrush I updated the quartz config site file, added new baselines and re-baselined one changed result.


Calling getPolicyDocument in AuthPolicy.java causing multiple statement duplicates

Calling getPolicyDocument in AuthPolicy.java causing multiple statement duplicates in the returned map. If I call it more than one time (e.g. to log some of policyDocument info or to make multiple assertions in tests) the returned Map (and list of statements of PolicyDocument) contains multiple entries of same statements. This is because getStatement() doesn't just get, it actually adds allow and deny statements on every get call.

Thanks for the bug report, care to submit a PR for this? Should be simple I hope.

@jackrk done.


Configurable Product Image Gallery Sort Order

Issue: When we set the sort order from the admin panel then that sort order does not affect at frontend
Analysis and Finding:
1: This issue does not exist in the Luma theme
2: In the Hyva theme this issue exists only for configurable products
So this is the issue of Hyva theme

Thanks for reaching out, but this is the wrong repository. please check the list of issues and open a new one if there is none already in the appropriate repository on the Hyvä gitlab.


Update zio, zio-test-sbt to 2.0.21

About this PR
📦 Updates

dev.zio:zio
dev.zio:zio-test-sbt

from 2.0.19 to 2.0.21
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #610.


Circuit construction from higher-order objects

We should be able to construct circuits lazily from objects before they are synthesized. The synthesis happens later, and it may fail if a physical synthesis is not known. This already exists for some things, but this is an issue to keep track of future additions.
It would be good for the circuit constructor to have a whitelist of things that can be legally added (currently it's just anything that implements a to_instruction() method).
Start of a list:
[ ] Operator (matrix op) --> remove UnitaryGate
[ ] Clifford
[ ] Pauli
[ ] Isometry --> remove Isometry instruction and consolidate under quantum_info
[ ] State (treated as state preparation)
[ ] DiagonalOp --> remove DiagonalGate and represent as an operator
[ ] SparseCircuitOp (better name?) --> can be used for QuantumError, Linear Combination of Unitaries, Expectation values,
[ ] Oracles (done in #4522 )

I like the idea to make the synthesis happen later and have abstract blocks inside the circuit, however I think it's also quite a nice feature to be able to just give an object a to_instruction and then being able to append it to the circuit.
Especially in times of separated Qiskit elements this might even be a necessary feature, otherwise we cannot append objects only existing in Aer/Ignis/Aqua. For example the Aqua operators should be appendable to a circuit to make phase estimation work nicely.
So I think it would be great to add this feature but maybe we should keep the flexibility of just needing to_instruction in parallel. (At least as long as we didn't merge the elements 😉 )

@ajavadia I think that quantum circuit white listing should eventually be based on the Operation class, i.e. QuantumCircuit can only append objects of classes derived from Operation


Force HDR has stopped working.

It used to work just fine, but for the last few weeks I cannot force HDR on any of the programs I try. Again this used to work for me so it's not me misunderstanding how to find the correct exe or how to adjust the intensity slider, it only recently stopped forcing HDR. I'm wondering if perhaps W11 has broken the functionality with a recent update, or if I altered something that broke it.

Looking further, I realized it is making the necessary registry edit to force HDR in Computer\HKEY_CURRENT_USER\Software\Microsoft\Direct3D
but it is naming programs incorrectly, I do not know if it has always named the exe files incorrectly or if it just started.

What game are you trying to enable AutoHDR for?

Well, first I tried with brothers in arms hell's highway. When I saw it didn't work, I tried enabling it on Firefox as a test. Firefox also didn't work and misspelled in the registry, then I tried to test it again on the league client and once again it didn't work.
I also know that it used to work on Firefox in the past because it was the exe I was using to test it before, and it did enable.

Found the bug and was able to replicate when adding Firefox.
It is caused by inbuilt python function rstrip.
exe_name.rstrip('.exe')

It's an easy fix will release a new version soon stay tuned and thanks for reporting it.

It's an old game I played when I was younger and recently just played through it again. I do not know if the game was misspelled in the registry or not, but the HDR did not enable for this game. I tried both windowed and full screen to try and fix the issue. Unfortunately, I cannot check the registry value because I already uninstalled the game and cleared it from the registry.

Okay no problem.
I just released a fix for the incorrect name entries check it out here v<IP_ADDRESS>
I will close this issue now. Feel free to open a new one if you find a new issue.


Fix author info

Summary
Fix the author info in the Dapr book state management chapter.

@nishanil Here's the PR for the author fix


LS: Proc macro state better migration on swap

@Draggu commented on 12.11.2024, 16:34:56:

We should NOT migrate whole state on db swap, but it leads to fresh diagnostics calculation every 5 minutes, also sending requests again and that is not acceptable

@Arcticae commented on 20.11.2024, 12:28:06:

Might be solvable by starkware-libs/cairols-issues#48


v11 Actor module-sub-types are not compatible with pf2e 5.14.4

v11 introduced a way for modules to create their own document sub types. https://foundryvtt.com/article/module-sub-types/
https://discord.com/channels/880968862240239708/880969304365994034/1220904695854399488
(drentalBot)
"The pf2e system doesn't use one actor class, but one class per actor type and has a Proxy setup to actually get those classes for NP,ActorPf2e, FamilairActorPf2e, etc. So when you add a new type of actor you also have to supply a new actor class and register it in
CONFIG.PF2E.Actor.documentClasses[type]"
but that proves to be problematic.
I've only tried it with Actors, but if there are other documentTypes that behave the same could be more prevalent.

Hey, no pointing at me!
Can you sow what you tried and how it failed?

Haha that’s what you get for helping newbs. Yea I’ll upload some failures.
(And code that works in other systems)
On Sat 23. Mar 2024 at 23:36, Drental @.***> wrote:

Hey, no pointing at me!
Can you show what you tried and how it failed?
—
Reply to this email directly, view it on GitHub
https://github.com/foundryvtt/pf2e/issues/14282#issuecomment-2016620603,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVHG6QA7CB3IGUPIDZINMLYZX7VPAVCNFSM6AAAAABFE7LODSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGYZDANRQGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

Screen shot of the current state in not-pathfinder2e.  Scum and Villainy in this case.
Here is the repo if anyone wants to take a look. https://github.com/MarkPearce/ore-companies
I have a some conditional logic there to check for pathfinder and try workarounds.
A few folks on the discord channel been suggesting ways to fix it.
I've tried:

extending the actor class, but get "you may only push instances of actor to the actorsPF2e collection"
extending the ActorPF2e class, by getting the prototype of existing actors but the data models don't match
Tried overriding the preparedata methods, but that just kills the actors data, and removes them all from sidebar.

error with extending ActorPF2e (currently in code)
foundry.js:753 TypeError: Failed data preparation for Actor.TxTCzNXRxDgK7KNO. Cannot set properties of undefined (setting 'flanking')
at CompanyActor.prepareBaseData (pf2e.mjs:1649:53368)
at CompanyActor.prepareData (foundry.js:14209:12)
at CompanyActor.prepareData (pf2e.mjs:1649:52446)
at CompanyActor._safePrepareData (foundry.js:14187:14)
at Game.initializeDocuments (foundry.js:8796:18)
at Game.setupGame (foundry.js:8706:10)
at async Game._initializeGameView (foundry.js:9990:5)

error when trying to extend Actor

disabling prepdata methods.
foundry.js:753 TypeError: Failed to render Sidebar tab actors. Cannot read properties of undefined (reading 'level')

Anyone more clever than I have suggested workaround?

Personally I kinda want to wait till v12 before taking a look at this, given its such a minor underlying. Its very likely we'll have to do something to support it.

If anything breaks, please feel free to report so that this behavior can be finetuned.


Add logic to turn Sveltekit-App into Webstone App

As we're moving away from a monorepo approach, this might get much easier,
Logic idea:
graph TD;
1{Directory contains Sveltekit app?}
1-->|yes| 2{replace readme?}
1-->|no| 3[create-svelte-app]
2-->|yes| 7[replace readme]
2-->|no| 8[kepp existing readme]
7-->5
8-->5
3-->4[replace readme]
4-->5[install webstone-cli]
5-->6[ready]

We maybe should also keep the following two things in mind:

what if people aren't using playwright for tests, will we configure it with a codemod?
what if people aren't using typescript, will we enforce typescript, or will we also add js support?


[misc] Add wheels for Python3.9.

For now, it is impossible to support Python 3.9, since it relies on Pillow <= 7.2.0, which is not compatible ( >=  8.0 is the minimum version compatible) and numb, for which no version compatible exists at all.

numba 0.53 will support Python3.9 and should be released anytime soon (rc3 is already available).


{Packaging} Drop support for Python 2.7

Fix https://github.com/Azure/azure-cli/issues/11362
Fix https://github.com/Azure/azure-cli/issues/11206

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

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[ ] I adhere to the Command Guidelines.

@rodrigc can you merge the latest dev branch and help resolve the conflicts? we're ready to merge this PR.


[hotfix][table] remove @PublicEvolving annotation from AbstractCatalog

What is the purpose of the change
This PR removes @PublicEvolving annotation from AbstractCatalog. @PublicEvolving should be on the Catalog interface (which it already is), and marking AbstractCatalog as @PublicEvolving brings us extra burden on maintaining its compatibility.
Brief change log

removes @PublicEvolving annotation from AbstractCatalog

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

cc @xuefuz @lirui-apache @zjuwangg


IPAM for service LB in WC

This pr:

adds a way to auto-assign an IP for service LB running in WC (kube-vip).

Kube-vip cloud provider watches for services of type LB and assigns a new ip for them from a range. This range is configured in WC using a configmap called kubevip@kube-system.
However, we need to populate the content of the configmap upfront during the cluster creation (we currently ship kube-vip and kubevip-cloud-provider as sub-chart in our "CPI bundle") and more importantly we need to somewhere keep track of what IPs have been used. Each WC requires at least 1 IP to work properly, because the ingress of nginx controller needs to be exposed using this mechanism.
This PR in short, creates the IPClaim resource similarly as for CP's IP if the .networking.loadBalancers.ipPoolName helm option is not empty, waits for this claim to be served by the ipam controller, updates the value for CPI bundle helm chart and only then resumes the Cluster CR so that the reconciliation can actually start.

/run cluster-test-suites


implement PGI regularisation

Any plans to implement the Petrophysical Guided Inversion regularisation as an option?
e.g.
https://docs.simpeg.xyz/content/examples/10-pgi/plot_inv_0_PGI_Linear_1D.html#sphx-glr-content-examples-10-pgi-plot-inv-0-pgi-linear-1d-py

hi @craigmillernz , sorry for the late reply.
The answer is yes, and will likely by bumped up the priority list as requested by the steering committee. TBD


Conduits crashing server

Is there an existing issue for this?

[X] I did not find any existing issues.

Current Behavior
When working with ender io conduits on ver 6.1.6-beta
Expected Behavior
To not crash
How to Test
Open conduit grey square on machine atc.
Local Environment
- **Operating System**: Ubuntu 22.04.4 LTS
- **Java version**: probably 17.0.8
- **Minecraft Version**: 1.20.1 forge
- **Version**: 6.1.6-beta

Any Additional Information?

It's a client class being loaded on the server somewhere

Any guess what to try? We didnt experience this behavior earlier, and we played on older version until recently, is this any hint what could be wrong?

This will need to be looked into and fixed on our side unfortunately

I have fixed this bug and it'll be released as version 6.1.7-beta in the next 30 minutes or so :) Thanks again for the report!


Checked for null before printing output values

Signed-off-by: Lesan Tudor<EMAIL_ADDRESS>

@meirwah @orius123 could you review please? Fixes #171


Upgrade perfetto to v0.47

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.91%. Comparing base (d7c369e) to head (f9e966f).
Report is 1 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

:exclamation:  There is a different number of reports uploaded between BASE (d7c369e) and HEAD (f9e966f). Click for more details.
HEAD has 18 uploads less than BASE

Flag
BASE (d7c369e)
HEAD (f9e966f)

19
1

Additional details and impacted files
@@             Coverage Diff             @@
##            master     #477      +/-   ##
===========================================
- Coverage   100.00%   93.91%   -6.09%
===========================================
  Files           21       21
  Lines         2300     2300
===========================================
- Hits          2300     2160     -140
- Misses           0      140     +140

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update float parsing patterns

Previously, the regex matcher intended to match floats, but would
instead match any character between two numbers as opposed to a
period. For example, the numbers '1965 1966' would be parsed as a
single string ('1965 1966') instead of two strings ('1965' '1966').
This update now properly parses both floats and integers.
Signed-Off-By: Robert Clark<EMAIL_ADDRESS>

@roclark I just noticed this commit and have some late feedback if you don't mind:

FWIW: The Go package govalidator offers validators and sanitizers for strings, structs and collections. There's e.g. an IsFloat() function which uses this regex:Float          string = "^(?:[-+]?(?:[0-9]+))?(?:\\.[0-9]*)?(?:[eE][\\+\\-]?(?:[0-9]+))?$"

If you use raw string literals (with back quotes) for the regular expression you don't need to escape the backslash.
Wouldn't it be safer and more readable to define the float regex only once and use this single definition in the test case, too?
Then you could also regexp.MustCompile() it once as a constant. Right now you (re-)compile every regular expressions in each call to regexCaptureStrings(). This compilation is a rather expensive operation (and maybe even involves a memory allocation).

Thanks for the feedback! I'm always open to performance improvements and other optimizations. I might incorporate this one after #82 gets pulled in as I move common functions/statements into a separate file. That way, we can cleanly define the number regex globally.

@roclark To give you a number: I see ~4600 mallocs per second from the lustre-exporter on our OSSes according to the go_memstats_mallocs_total metric. And ~780 mallocs per second on the MDS.


CompleteDone fires before listener_add callback when completion is finished

Describe the bug
When a keystroke causes a completion to "end" (which, depending on the state might cause the currently selected candidate to be inserted), the CompleteDone event fires before the insertion of the candidate (if applicable) or the character corresponding to the keystroke (if applicable).
To Reproduce
Using repro.vim:
set nocp
set noswapfile
set completeopt=menu,popup
set bs=2

function DoComplete(findstart, base)
  if a:findstart == 1
    return 0
  else
    return [{"abbr":"apple","word":"apple","info":""},{"abbr":"banana","word":"banana","info":"Type"}]
  endif
endfunction

set omnifunc=DoComplete

function s:EchoEvent(msg)
  redir >> /tmp/listener.log | echo a:msg | redir END
endfunction

function HandleDelta(bufnr, start, end, added, changes)
  call s:EchoEvent("HandleDelta")
endfunction

call listener_add("HandleDelta")

au CompleteDone * call s:EchoEvent("CompleteDone")

Then:
vim -u repro.vim

Then:
i<C-X><C-O>

will produce the following output in /tmp/listener.log:
HandleDelta
HandleDelta

and leave the buffer in the following state:
apple_

with the cursor at the position _ and the popup menu showing.
Now type ). Notice the order of the events in /tmp/listener.log:
CompleteDone
HandleDelta

A consequence of this is that any remote plugin (that relies on listener_add deltas to update the plugin's buffer state) that attempts to perform an action in response to CompleteDone (e.g. handling additional text edits received from a language server) will do so with a dirty buffer.
Expected behavior
The CompleteDone event to fire after the listener_add callback.
Screenshots
n/a
Environment (please complete the following information):

Vim version

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 28 2020 14:13:18)
Included patches: 1-397
Compiled by myitcv@myitcv
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       -tcl
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
+balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            -netbeans_intg     +termresponse
+browse            +gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     -perl              +title
+cindent           +job               +persistent_undo   +toolbar
+clientserver      +jumplist          +popupwin          +user_commands
+clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           +python/dyn        +visual
+comments          +linebreak         +python3/dyn       +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        +lua               -ruby              +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con_gui    +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       +X11
+digraphs          +mouse             -sound             -xfontset
+dnd               +mouseshape        +spell             +xim
-ebcdic            +mouse_dec         +startuptime       +xpm
+emacs_tags        -mouse_gpm         +statusline        +xsmp_interact
+eval              -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/home/myitcv/usr/vim/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16   -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl    -ldl  -L/usr/lib/x86_64-linux-gnu -lluajit-5.1

OS: Ubuntu 19.10
Terminal: XTerm(348)

Additional context
Add any other context about the problem here.
cc @leitzler

Paul Jolly wrote:

Describe the bug
When a keystroke causes a completion to "end" (which, depending on the state might cause the currently selected candidate to be inserted), the CompleteDone event fires before the insertion of the candidate (if applicable) or the character corresponding to the keystroke (if applicable).
To Reproduce
Using repro.vim:
set nocp
set noswapfile
set completeopt=menu,popup
set bs=2

function DoComplete(findstart, base)
  if a:findstart == 1
    return 0
  else
    return [{"abbr":"apple","word":"apple","info":""},{"abbr":"banana","word":"banana","info":"Type"}]
  endif
endfunction

set omnifunc=DoComplete

function s:EchoEvent(msg)
  redir >> /tmp/listener.log | echo a:msg | redir END
endfunction

function HandleDelta(bufnr, start, end, added, changes)
  call s:EchoEvent("HandleDelta")
endfunction

call listener_add("HandleDelta")

au CompleteDone * call s:EchoEvent("CompleteDone")

Then:
vim -u repro.vim

Then:
i<C-X><C-O>

will produce the following output in /tmp/listener.log:
HandleDelta
HandleDelta

and leave the buffer in the following state:
apple_

with the cursor at the position _ and the popup menu showing.
Now type ). Notice the order of the events in /tmp/listener.log:
CompleteDone
HandleDelta

A consequence of this is that any remote plugin (that relies on listener_add deltas to update the plugin's buffer state) that attempts to perform an action in response to CompleteDone (e.g. handling additional text edits received from a language server) will do so with a dirty buffer.
Expected behavior
The CompleteDone event to fire after the listener_add callback.

That is not expected.  The listner callback is called later, before the
screen is redrawn.
CompleteDone is invoked when the completion has been done.  When typing
")" this ends the completion, then it adds the ")".
As far as I can see this works as intended.  You can perhaps call
listener_flush() somewhere to have the callback invoked earlier.
--
We learn from our mistakes.  Politicians don't make mistakes.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

That is not expected.  The listner callback is called later, before the screen is redrawn.

I think this has important implications for remote plugins. Because a "native" VimScript plugin would see the buffer as updated on receiving CompleteDone, a remote plugin relying on deltas via listener_add callbacks would not.
 Or does that not make sense?

You can perhaps call listener_flush() somewhere to have the callback invoked earlier.

This works for now, thank you.

That is not expected.  The listner callback is called later, before
the screen is redrawn.

I think this has important implications for remote plugins. Because a
"native" VimScript plugin would see the buffer as updated on receiving
CompleteDone, a remote plugin relying on deltas via listener_add
callbacks would not.
 Or does that not make sense?

I don't see why there would be any relation between triggering an
autocommand and the listener mechanism.  They are completely separate
things.  The listeners only depend on changes in the buffer text, not
how how those changes are made.

You can perhaps call listener_flush() somewhere to have the callback
invoked earlier.

This works for now, thank you.

If a plugin depends on listener callbacks to be invoked before something
else happens, the flushing is the right way.
--
There are 10 kinds of people: Those who understand binary and those who don't.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

With my limited understanding of the Vim internals it feels like Vim
should be calling listener_flush before any autocommand events are
fired. Or does that not make sense?

I don't see why there would be any relation between triggering an
autocommand and the listener mechanism. They are completely separate
things. The listeners only depend on changes in the buffer text, not
how how those changes are made.

There isn't a relationship per se, but for remote plugins, as I described
in this issue, if there are pending deltas when an autocommand is fired (or
a function called for that matter) where there is a remote plugin handling
the autocommand (or function) then there is a chance, as we discovered, for
effectively performing a "dirty write" back to Vim.
We can, however, put such a call into our VimScript shim (
https://github.com/govim/govim/blob/db2f5323507e94805d5d9f2bc4771f29a1e3f8e0/plugin/govim.vim)
for now and experiment there.

You can perhaps call listener_flush() somewhere to have the callback

invoked earlier.

This works for now, thank you.

If a plugin depends on listener callbacks to be invoked before something
else happens, the flushing is the right way.

The plugin relies on events being in the right order. i.e. that the edits
happened before the CompleteDone event was triggered (more explicitly, the
buffer contents at the time of the event reflect the changes but a
listener_add callback does not, at this point know about them)
But as I said above, we can experiment with a workaround in our shim for
now.

FWIW our workaround appears to be working in this case:
https://github.com/govim/govim/blob/80f0949c0a467c2f899d7aa43ff09ed0c2fd2b2d/plugin/govim.vim#L66-L73
Before making any call to govim from Vim (which we usefully have happening through a single function) we call listener_flush unless the call itself is the handling of listener_add callbacks.
@brammool - would you like to keep this issue open, or do you think this workaround is the right approach and hence this can be closed?

I think that calling listener_flush() for an autocommand event is a normal way to make things work.  It is intentional that flushing to listeners is postponed until a series of related changes is done, which usually means when the screen gets updated.  If it is required to have it happen earlier, calling the function to initiate the flush is correct.


Create an LSP testing and assertion framework

Currently, testing the LSP is tricky to test which presents an obvious gap in testing and quality. Therefore, we need to create/identify some functions, patterns, or existing tools that will vastly improve the ability to test the LSP features.
AC:

[ ] The testing framework is capable of easily creating and managing virtual/temporary documents
[ ] The testing framework provides a clear, simplified API for triggering events as the LSP client
[ ] The testing framework provides common assertion functions

[ ] Abstract away the need to dig through LSP responses

[ ] Create a unit test class that handles the setup/tear down associated with LSP tests

This is for Haskell, but could be a good reference for ideas: https://hackage.haskell.org/package/lsp-test

Rolling to sprint 4


[HOLD Expensify #227234] Hitting "cmd +R" when an attachment was taking longer to upload, multiple attachments are loading

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

Action Performed:

Login
Open any chat
Upload an attachment with bigger size
When uploading takes longer and stays in "uploading attachment " hit "Cmd+R"

Expected Result:
Either should still show "uploading attachment" or once it gets uploaded.
Actual Result:
Multiple times images are being uploaded message appears
Workaround:
unknown
Platform:

Where is this issue occurring?

Desktop App

Version Number: 1.2.21-4
Reproducible in staging?: Need reproduction
Reproducible in production?: Need reproduction
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: @rafecolton
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1667414010939499
View all open jobs on GitHub

Will review today

I haven't been able to reproduce this 🤔 I tried uploading an attachment just under the 24mb size limit and refreshing the desktop app didn't cause the repetition shown in the screenshot in the OP

Agreed, this is linked to sequence numbers. Taking it over as part of the tracking issue.

Still on hold for sequence numbers.

On hold for sequence numbers, though that initiative is hopefully wrapping up before EOY.

Still on hold for sequence numbers.

Hold means hold Melvin.

Still on hold for sequence numbers.

Removed the hold and re-running through the testing steps.

No longer an issue! Works like a charm now that sequence numbers are deprecated. Adding the reproduction label and closing.


Move purify transforms

/cc @IgorMinar

Please rebase. This looks good to me, just want to run the latest lint and tests.


How to extract time and date from GPS data

1. SDK version（SDK 版本）
{
}

2. In what kind of operation problems appear, and how to reproduce the problem ?（什么样的操作步骤问题会出现，是否是稳定复现，如何复现问题？）
{
I am trying to extract the time and date from the RMC sentence that is being received by the GPS receiver.    I am using a slightly modified version of the GPS demo  provided in GPRS_SDK_C.  The data is being properly recorded on the TF card as follows once GPS lock has been achieved, as shown in the following line:
$GNRMC,091835.000,A,2804.6123,N,08035.0009,W,1.828,204.06,110419,,,A*54
However when I try to display the time on an OLED display, I am getting RMCTime  displayed as 9 instead of the expected value of 091835.000 . I am using the following code to try and do this;
snprintf(buffer4,sizeof(buffer4),"RMCTime: %c",gpsInfo->rmc.time);
OLED_ShowStr(5,7,buffer4,1);
I am by no means an experienced programmer, so I am asking for some help with this request. Thank you.
}

Not sure what your display device is but that snprintf format is not correct.
Looking at the rmc structure we have ....
struct minmea_time {
int hours;
int minutes;
int seconds;
int microseconds;
};
struct minmea_sentence_rmc {
struct minmea_time time;
So the time is a structure, so you're either going to have to write some code to convert those hours,minutes,seconds,microsecnods to the string you want or at a pinch, this might work ...
snprintf(buffer4,sizeof(buffer4),"RMCTime: %d:%d:%d:%d",gpsInfo->rmc.time.hours,gpsInfo->rmc.time.minutes,gpsInfo->rmc.time.seconds,gpsInfo->rmc.time.microseconds);
At the moment the format character you have %c is a single character, probably not what you want. %d is the format character for an integer. So the time fields should be interpreted as integers.

%s


feat: :sparkles: Added miniforge3 manifest

Added Miniforge3 app manifest

Added Miniforge3 app manifest, witch is identical to Mambaforge manifest except some URL and filename changes to point to appropriate installer and uninstaller.

Closes #11983

[X] I have read the Contributing Guide.

/verify

/verify


Adopt Cosign 2.0 and use the keyless verification?

https://blog.sigstore.dev/cosign-2-0-released/

Fixed by #404 and #436.


upgrade webpack codestart devDependencies

Describe your changes
upgrade webpack codestart devDependencies

Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.

I am watching the build.

I am watching the build.

Yeah. I too


Vertical line component

Proposed Changes
Simple vertical line component since we want to use it in multiple section of the admin (right now its a span in source for example)
added style according to separator class and UTs
Potential Breaking Changes

Acceptance Criteria

[x] The proposed changes are covered by unit tests
[ ] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

Codecov Report

Merging #1507 into master will decrease coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #1507     +/-   ##
=========================================
- Coverage   98.74%   98.65%   -0.1%
=========================================
  Files         502      504      +2
  Lines       10354    10400     +46
  Branches     2392     2404     +12
=========================================
+ Hits        10224    10260     +36
- Misses        130      140     +10

Impacted Files
Coverage Δ

...vapor/src/components/verticalLine/VerticalLine.tsx
100% <100%> (ø)

packages/react-vapor/src/components/index.ts
100% <100%> (ø)
:arrow_up:

...s/react-vapor/src/components/verticalLine/index.ts
100% <100%> (ø)

...src/components/loading/components/TableLoading.tsx
74.28% <0%> (-15.72%)
:arrow_down:

...nents/sideNavigation/SideNavigationMenuSection.tsx
64.58% <0%> (-1.38%)
:arrow_down:

...ckages/react-vapor/src/components/drop/DropPod.tsx
97.02% <0%> (-0.91%)
:arrow_down:

.../react-vapor/src/components/table-hoc/TableHOC.tsx
100% <0%> (ø)
:arrow_up:

...por/src/components/table-hoc/TableRowConnected.tsx
98.85% <0%> (+0.07%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0bca82e...79230a1. Read the comment docs.


Added a simple Settings Menu

This menu currently controls node highlighting
This is mainly for people that have reported color blind issues. We could also turn this into a proper settings menu.
This may not be the correct implementation of it, but I hope it is.
@SpaceOgre @l0g0sys @brather1ng
![Menu] (http://i.imgur.com/PSbZjIi.png)

Looks good to me, but I'm not able to test it since my computer is in a closet (painting the computer room). Maybe just re-size the window to fit the content better.
And I think we should consider what else we could move here, but that can be done after this is merged.

With future changes in mind, I would not place Settings under File menu. File menu should contain only build related functions. In the future there should be also Properties... menu item which will allow to edit current build properties. Global application Settings should be under Tools or Edit.

Yeah, I wasn't sure where I was going to put it. The edit menu was the
second option. I will go ahead and update that.
On Dec 10, 2015 1:20 AM, "l0g0sys"<EMAIL_ADDRESS>wrote:

With future changes in mind, I would not place Settings under File menu.
File menu should contain only build related functions. In the future there
should be also Properties... menu item which will allow to edit current
build properties. Global application Settings should be under Tools or Edit.
—
Reply to this email directly or view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/228#issuecomment-163542147.


add java env variables. Closes #272

not sure if cleaning properties is required
assumed loading properties file should be on user-side

Closing as the Java plugin changed.


Add STM tests for Bytes

Testing function from Bytes module - sequential and parallel tests

Looks good and the CI is happy (the failure is unrelated) :+1:
I propose to squash the commits into just one (if you need help with this I can show you how)

I realized I can easily squash and merge the commits here in the GitHub web-UI - so I just did that.
Thanks! :smiley:


Can't remove border radius on previewBuilder widget

Hi, I'm looking a way to change the border radius of the previewBuilder.
What I have:
ContextMenuWidget(
              previewBuilder: (context, child) {
                return Container(
                  color: Colors.blue,
                  height: 100,
                  width: 100,
                );
              },

What I get:

We can see a border radius, but in my container there no borderRadius. This is a bug or a default radius that I can change ?

Which platform is this on?

iOS platform

On iOS the border radius is enforced by the iOS menu system and cannot be adjusted.


refactor(yaml): remove tag property

Changes
This PR removes the tag property in DumperState.
Reasoning
tag is only used in writeBlockMapping(), so it can be passed as an argument instead.

Can you please only include changes that directly pertain to removing the tag property? We can handle any other refactors in a separate PR.

Alright, I undo the detectType changes


Having trouble with showing validation with a hydrated contact form component

Hi, for some reason my validation messages aren't being rendered when there are errors, I'm using an object to keep track of my form errors and when I change that object, the html is not being updated
the object looks like this
  let errors = {
    name: null,
    email: null,
    description: null,
  };

and the template looks like this

    <input placeholder="Your Name" bind:value={contactForm.name} name="name" type="text" id="name" />
    Name
    {#if errors.name}

{errors.name}

    {/if}

I can see from the console log output that the value is being set to true when there is an error but it is not being reflected in the html.
I'm using the component like this

<Banner title="Get in touch" />

<Container />
<Container isNarrow={true}>
  <ContactForm  hydrate-client={{}} hydrate-options={{ preload: true, loading: 'eager' }} />
</Container>

the component code is here in this svelte repl link It's working in the svelte repl
If you need more context then this is the actual file in my project
If you have an example or some guidelines on using elderjs for form validation then that would be helpful.

@NK-WebDev this is a svelte issue. I know it works in the repl but it comes down to the way you are mutating object keys and Svelte is not detecting the change. https://svelte.dev/tutorial/updating-arrays-and-objects

Thanks for the quick reply and the link to the correct docs, I tried just using variables like nameError = null, instead of an errors object but it didn't work that time, I guess because the server didn't update for some reason but now it works if I just use a primitive variable instead of an object or make another extra assignment or a new copy. It's weird that in the repl we don't have to do this. :confused:
If anyone else is stuck with a similar problem any one of this will work
nameError = null;

// validation
nameError = 'name is not valid'

errors = {
	name: null
	.
	.
	.
}

//validation
errors = {
	...errors
	name: 'name is invalid'
}

errors = {
	name: null
	.
	.
	.
}

// validation

errors.name = 'name is unvalid'

// other validation
.
.
.

// finally an extra assignment
errors = errors

thanks for the quick reply and sharing the correct documentation link, I got it to work by creating a new copy of the object like this
errors = {
	...errors
	name: 'name is invalid'
}

I thought it might be because I was mutating the object property so I had previously tried to do it this way and it didn't work, now I know that it didn't work because for some reason the compiled code hadn't updated properly so I manually deleted the ELDER folder, made my changes and restarted rollup and nodemon server.
I tried my previous code on a brand new svelte app and it is working fine there, the svelte tempplate uses svelte 3.0.0 and my elder.js app is using svelte 3.24.0, idk if it is because of this or something else, @nickreese do you know why it's working with a new svelte app but not with elder.js?

@NK-WebDev Elder.js is just a wrapper around Svelte’s mount code. If you’re really curious about the root cause look into the differences in output that Elder and the new svelte template generate.


Freewallet Dark Mode & Custom Themes

Enable a "dark mode" button for Freewallet - I know there is a "theme" portion already being worked on.
PLZ HELP MY EYES bleeds from eyes
Custom images for different sections or nodes or tabs of freewallet would be really fun and people would definitely show them off on social media when they customize them. That would be good for new users to be attracted to use Freewallet imo. Custom is fun.

Please move to discussions section as an idea.


32bit x86 arch compiling ends with type error

While compiling OSL <IP_ADDRESS> on a 32bit x86 architecture, the compilation ends up with error about a size_t not being able to be overloaded with a uint32_t, e.g:
src/include/OSL/llvm_util.h:706:21: error: 'llvm::Constant* OSL_v1_13::pvt::LLVM_Util::constant(size_t)' cannot be overloaded with 'llvm::Constant* OSL_v1_13::pvt::LLVM_Util::constant(uint32_t)'

e.g. of the whole offending command:
/usr/bin/g++ -DOIIO_DISABLE_DEPRECATED=1 -DOIIO_HIDE_FORMAT=1 -DOSL_FAST_MATH=1 -DOSL_INTERNAL=1 -DOSL_LLVM_FULL_VERSION=\"17.0.6\" -DOSL_LLVM_NEW_PASS_MANAGER -DOSL_LLVM_OPAQUE_POINTERS -DOSL_LLVM_VERSION=170 -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -Doslquery_EXPORTS -Dosoparse=OSL_v1_13_osoparse -I/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/build/include -I/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/build/src/include -I/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include -I/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/ext/dist/include -I/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/liboslquery -I/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/liboslquery/../liboslexec -isystem /usr/include/opencv4 -isystem /usr/include/Imath -O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -fomit-frame-pointer -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG -std=c++17 -fPIC -fvisibility=hidden -Wall -Wno-error=strict-overflow -Wno-unused-local-typedefs -Wno-unused-result -Wno-error=misleading-indentation -fno-math-errno -MD -MT src/liboslquery/CMakeFiles/oslquery.dir/__/liboslexec/typespec.cpp.o -MF src/liboslquery/CMakeFiles/oslquery.dir/__/liboslexec/typespec.cpp.o.d -o src/liboslquery/CMakeFiles/oslquery.dir/__/liboslexec/typespec.cpp.o -c /disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/liboslexec/typespec.cpp
In file included from /disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/liboslexec/oslexec_pvt.h:40,
                 from /disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/liboslexec/typespec.cpp:13:
/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include/OSL/llvm_util.h:706:21: error: 'llvm::Constant* OSL_v1_13::pvt::LLVM_Util::constant(size_t)' cannot be overloaded with 'llvm::Constant* OSL_v1_13::pvt::LLVM_Util::constant(uint32_t)'
  706 |     llvm::Constant* constant(size_t i);
      |                     ^~~~~~~~
/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include/OSL/llvm_util.h:691:21: note: previous declaration 'llvm::Constant* OSL_v1_13::pvt::LLVM_Util::constant(uint32_t)'
  691 |     llvm::Constant* constant(uint32_t i);
      |                     ^~~~~~~~
In file included from /disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include/OSL/rendererservices.h:8,
                 from /disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/liboslexec/oslexec_pvt.h:44:
/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include/OSL/encodedtypes.h:61:47: error: static assertion failed: unexpected
   61 |     static_assert(size_of_encoded_type(value) == sizeof(DataType),
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include/OSL/encodedtypes.h:61:47: note: the comparison reduces to '(8 == 4)'
/disk/devel/OpenShadingLanguage-<IP_ADDRESS>/src/include/OSL/encodedtypes.h:69:47: error: static assertion failed: unexpected
   69 |     static_assert(size_of_encoded_type(value) == sizeof(DataType),
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

OSL branch/version: <IP_ADDRESS>
OS: Mageia Linux (cauldron or 9)
C++ compiler: gcc 14 (snapshot 2024-03-17) or gcc-12.3.0
LLVM version: 17.0.6 or 15.0.6
OIIO version: <IP_ADDRESS> or <IP_ADDRESS>

I don't believe OSL has tried to support 32 bit architectures for some time now.
That said, if you want to make a PR that would make it build cleanly for 32 bit -- and it doesn't disadvantage 64 bit performance or make code too cluttered -- we would be happy to accept and merge it.

OK, thanks for your answer. Just to know it's not officially supported anymore. Maybe a note in the README or a test in the code, just to inform it's not supported anymore could help. I thought the 1.13 branch was still supporting 32bit arch  (as 1.11.x was still compiling on it). I tried a quick fix forcing a casting, but things are much more complicated than that.

I'll make it more clear in the docs.
I don't remember at what point exactly we stopped supporting 32 bit builds, but I know we've discussed it in several PRs over the last few years ("does this patch work on 32 bits?" "Do we even claim to support 32 bits?" "No, we already decided that" conversation has already happened a few times, by my recollection).

Closing since our current development no longer officially supports 32 bit platforms.


Strip FINAL, CONST and ABSTRACT annotations from Dart output

They pollute Dart code. Example:
This:
import {
  CONST, FINAL, ABSTRACT
} from 'angular2/src/facade/lang';

@ABSTRACT()
class Blah {
  @FINAL()
  i;

  @CONST()
  constructor(a) {
    this.i = a;
  }
}

Transpiles to this:
library angular2.blah_dart;
import 'package:angular2/src/facade/lang.dart' show CONST, FINAL, ABSTRACT;

@ABSTRACT()
class Blah {
  final i;
  @CONST()
  const Blah( a): i = a;
}

(@FINAL is removed but still imported unnecessarily)

/sub

Mhpf. Done already, but now this causes dartanalyzer warnings for unused imports :-(

@mprobst Now you need to strip the imports. :smile:

Actually handling the unused imports is not feasible at the moment as we don't have precise type information available to detect used and unused imports. So let's just include these in the output for now, and revisit this once we're fully migrated to TypeScript.
Maybe it's easiest to just ignore warnings from the dart analyzer - after all, this is just generated code, and the imports will be dropped by later stages during compilation.


OIP-draft Gateway UX Composer

@Ben can you please update pull request title from "OIP-draft Gateway UX Composer" to "OIP-draft Gateway Composer"? I don't have permission to update.


ViewportTexture not rendering SubViewport in 3D game in simplest possible scene.

Godot version
v4.1.1.stable.official [bd6af8e0e]
System information
macOS Ventura 13.0
Issue description
ViewportTexture is not rendering SubViewport in game.
Only blue color rendered.
No errors in console.
Setting light_projector = viewport.get_texture() does not help. Same behaviour.
WORKAROUND (hacky):
light.light_projector = ImageTexture.create_from_image(viewport.get_texture().get_image())
It spawns A LOT OF ERRORS and reduces FPS but it works.
Steps to reproduce

Create SubViewport
Add simple animated box into it
Create SpotLight3D
Set ViewportTexture, specify SubViewport
See that it's not rendered. Instead solid color rendered (in reproduction project it's blue, in

Minimal reproduction project
viewport_texture_reproduction.zip

Thanks for the report! This seems to be a duplicate of https://github.com/godotengine/godot/issues/74352, so closing.
This is a technical limitation, same with decals. For more info, see this post by clayjohn: https://github.com/godotengine/godot/issues/73400#issuecomment-1433609221

@bitsawer hey, thanks for the reply! I'm kind of confused, I saw a lot of videos online with Godot and security cameras, aren't they done with ViewportTexture? I mean it seems this feature worked for some time at least. So now it seems making some kind of interactive Doom 3 screen appears impossible with inbuilt features?

Yes, you should be able to use ViewportTexture for example to render a security camera viewport into a 3D plane "monitor" or do something similar with real-time viewport updates. You can use an interactive, constantly updating ViewportTexture with normal materials just fine.
The limitation I mentioned should only applies to light projectors textures and mesh decal textures, which are special cases.

Thank you very much for clarification!


Completely disable sound on eco / comfort?

Hi! I warted to try to make this by myself but I have no idea how to load hex to 010 editor I don't know why. And I wonder if there is possibility to make sound (Gen2 RS4 sound) go completely off on some drive profiles to make drive more comfortable.
Thanks! :)

Yes, that's possible. If you use 010 Editor, and paste the hex data in there, run the template, you will see the following:

On the right, in the Variables section, you will find Car[0], with Charisma_09_Eco_driving_profile and a value next to it. Thi svalue is the profile it uses in Eco mode. In the case of this screenshot, Profile 7 is selected in Eco and Offroad, and in this firmware Profile 7 seems to be quiet:

Thank you - I managed to customise it in the way that I wanted - if I put car on eco / comfort sounds disables!


Sign Windows Setup with Certificate

Could you please also sign Windows Setup with certificate so there would be no security warnings.

Duplicate of #684
// CC: @tassoevan


About real semi-supervised scene

Hi, thank you for the README update and congratulations to the acceptance!
What is the different between real semi-supervised scene and changing label ratios?
To make sure, when changing label ratios, the model didn't use the label to compute segmentation loss, isn't this the same as real semi-supervised scene?
A follow up question:
Will there be precision change (drop) when switching to real semi-supervised scene compared to the results reported on the paper?
Many Thanks.

Hi @YuxuanWen-Code ,
Thanks for your interest in our research. Actually, the difference between real semi-supervised scenarios and changing label ratios is that all of the training data in the later case is labeled (but some of them are treated as unlabeled data, where their labels are ignored and never used for training).
The reason that we split these two scenarios is that, when building up datasets using our TrainValDataPipeline class, the input images should be either all labeled or all unlabeled (this is determined by whether you pass mode=labeled or mode=unlabeled). If your data is partly labeled (real semi-supervised scenario), you cannot pass mode=labeled as in this case the data pipeline will require every data to be labeled, and raise errors when labels are absent. For simplicity (without modifying the IO code), discussing these two cases separately is an easier idea with less cost.
To be brief, these two cases are split just for simplicity, and serve different purposes.

In the latter case (changing ratios), you could test the effectiveness of the semi-supervised algorithm and check its performance when changing the ratio of unlabeled data.
In the former case (real semi-supervised scenario), you could use the algorithm to enhance the segmentation performance compared with using merely labeled data.

But these two scenarios do NOT alter model effectiveness. Imagine these two cases:

100 labeled images (labeled ratio is set to 10%)
10 labeled images with 90 unlabeled ones

The model should yield very close performance in these two scenarios, as essentially they are identical. But you should treat these two cases differently as our code is designed to do so :)

Thank you for such detailed and timely explanation, it makes perfect sense.
*I will mark this issue close now since my confusion is resolved.
Best regards, and thank you again for the patient and effort.


Typo in 'Showcase'

It should probably say 'OpenStreetMap' instead of 'OpenStreetMaps'

Also, "Let's start" instead of "Let''s start"

Also, "Let's start" instead of "Let''s start"

Didn't see that one ;)

I've tried to submit a PR to try and help...


emp run could take a release argument

Sometimes a full deploy is overkill when you just want to run a little snippet of code via rails c or something. By specifying a release, one could avoid having to deploy everywhere.
It would be especially useful in shared development/staging environments.

Even more generally, it should take a SHA. That way you can run scripts that have not been merged (e.g. test code that hasn't been been merged yet without taking over the whole environment). Probably need to be able to disable the SHA support because you may not want to allow this on production.


Add support for writing additional file types beyond parquet

Some more file types: JSON, Avro, CSV

Can you point to where I should start looking to explore this issue?

Definitely!
All the file io is in this file: https://github.com/launchflow/buildflow/blob/main/buildflow/runtime/ray_io/file_io.py
The enum here has the list of file types we support: https://github.com/launchflow/buildflow/blob/main/buildflow/runtime/ray_io/file_io.py#L18
And in the _write method defines each file format is written: https://github.com/launchflow/buildflow/blob/main/buildflow/runtime/ray_io/file_io.py#L50
You should be able to mimic the tests here with any additional file types also: https://github.com/launchflow/buildflow/blob/main/buildflow/runtime/ray_io/file_io_test.py
If you have any other questions let me know!

Thanks, I an trying to test my changes and found that the existing tests are using unittest module. Is their any specific reason to use this in place of pytest?
And also, are there any specific commands to run all the existing tests ?

We mostly just did that from preference. Previous it was nice to use to setup ray specifics in the setUpClass methods, but we moved that to a pytest fixture, but it should play well with pytest I believe.
My typical workflow for a fresh install is (running from the root directory):
# install all dev deps
pip install .[dev]
pytest

Hmm interesting probably an issue with our permission set up. Let me try and update those

Alright turns out it was an issue with when the workflow runs. I updated it in https://github.com/launchflow/buildflow/pull/138 to run on PRs. So I think if you pull down the latest changes it should work.
(also added a CODEOWNERS to auto assign reviews)

With #142 , filesink now supports CSV and JSON


clip-video-encode: shift to open_clip

https://github.com/iejMac/clip-video-encode/blob/open_clip/tests/test_modules.py#L60

@rom1504 is there some easy way of getting the 'best' open_clip model for a given architecture?
or do we just allow selection of both model_name and pertained

Also I'm assuming ViT-B-32, laion2b_s34b_b79k is the best B/32 config, correct me if I'm wrong


How do I turn off colours?

How do I turn off the colours?
How to make it assume white background, not dark background on terminal.

P. S. Multiple Rust tools that use coloured terminal output seem to assume black background by default and look poor in my setup. Maybe there is a cross-app way (e.g. a environment variable) to notify all the programs that the background is white?

regarding point 1, for now I think a good setup would be to introduce a cli option that turns off the colors, I will have to see how I will work this out,
I suggest this workaround for your case: pipe into sed like the following intentrace ls | sed 's/\x1B\[[0-9;]\{1,\}[A-Za-z]//g'   it also works when the background is whitish
for point 2 and the rest, I agree there's a general assumption that everyone uses dark mode terminals, however I think any thing in the vicinity of "working around a light/dark mode" of sorts for a terminal application will require intentionality in design to remedy, I don't believe there's a generalizable way of working around a white background terminal, however I'm interested in making this work so I'll prioritize this (most likely this will also be a cli option)

Try running with NO_COLOR=1. Most likely the library used for coloring understands that. See https://no-color.org/.

Yes, it does remove the colours.
Maybe there is another magical environment variable to map lighter colours to darker ones for light backgrounds?

Maybe there is another magical environment variable to map lighter colours to darker ones for light backgrounds?

I am not aware of any such consensus. There's NO_COLOR which explicitly disables usage of colors and CLICOLOR{,_FORCE} which control automatic detection of whether colors should be used. These three are semantically equivalent to --color={never,auto,always} some programs have.
You should consider changing your terminal color palette so that "bright" colors are actually darker, that would work for all programs using 3/4-bit colors.

How to make it assume white background, not dark background on terminal.

I agree with this point. I definitely prefer the colorized output but for light background terminals it would be more readable if white was black:

Thanks for the crate recommendation @chapmanjacobd
for now we'll simply switch the main text color depending on what termbg detects
artifacts like file descriptors and others seem like they'll only benefit from handpicked colors, to be addressed in the future
current updates pushed to 0.4.2 (tested on ayu_light, AtomOneLight, and 1984_light)


Benchmark overflows

Benchmark (as published on medium.com) has several issues:

int32 overflows: 48th fibonacci number is larger than 2^31
plpgsql version uses decimal, which is a different datatype (infinite length and precision numeric) and does not overflow, i.e. benchmark is comparing apples to oranges
Apparently no correctness checks were performed for the returned value, allowing the function to be quick by returning incorrect values and not catching errors

Instead of the current plpgsql implementation like this could (should) be used
with recursive r(a, b, c) as (   select 0::int, 1::int, 1::int   union all   select b, a + b, c+1::int from r where c < 46 ) select a from r where c = 45;

Thanks, I'll try!