Whoops, looks like something went wrong.

After fresh/new install the landing page gives
Whoops, looks like something went wrong.

2.6.32-504.23.4.el6.x86_64 #1 SMP Tue Jun 9 20:57:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
CentOS release 6.7 (Final)
PHP 5.5.30 (cli) (built: Dec  2 2015 10:28:41)
Server version: Apache/2.4.16 (Unix)
No error_logs reported.

This doesn't help much really. Please set APP_DEBUG to true in .env and see what the error is.

@phanan Sorry, check out this gist.
https://gist.github.com/cPlevey/ce58acff913b3d56fbc0

I ran into this issue a bunch while trying to get the project set up. It turned out there were issues while running 'npm install' (even though they weren't reported). My troubleshooting for that was rather barbaric though and consisted of blowing away the repo, recloning it, and reattempting the npm install...

@bplower I've tried redoing it a few different times now, all same results.

What does gulp --production give?

@phanan Nice call.
# gulp --production
module.js:329
    throw err;
    ^

Error: Cannot find module 'clone-stats'
    at Function.Module._resolveFilename (module.js:327:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:355:17)
    at require (internal/module.js:13:17)
    at Object.<anonymous> (/usr/local/lib/node_modules/gulp/node_modules/vinyl/index.js:3:18)
    at Module._compile (module.js:399:26)
    at Object.Module._extensions..js (module.js:406:10)
    at Module.load (module.js:345:32)
    at Function.Module._load (module.js:302:12)
    at Module.require (module.js:355:17)

I'd suggest to start from there then. Google is your friend ;)

What are your outputs for npm -v and node -v?


make twisted test dep optional

Would it be possible to make the test dep on twisted optional? I am a packager for a Linux distro, and twisted is quite a large, complicated dependency.
Running the unit tests via python -m unittest discover works perfectly without twisted. It appears that it is really just used for the FilePath object and SynchronousTestCase. These seem pretty minor, and should be relatively easy to change.

Hi. You mean for the test suite it sounds like? Twisted isn't a runtime dependency.
I'd hope any Linux distro should have Twisted packaged, it's a fairly important and also old in age library at this point, but I can certainly understand if that isn't the case for a newer distro or something -- but if you want to send a PR changing FilePath to use pathlib(2) and SynchronousTestCase to use some other implementation of assertWarns I'm happy to accept that PR, though I can't guarantee that there won't be other dependencies added, including use of other trial features if they turn out to be useful. I can say though that the plan is to stay unittest compliant yeah, so you would in theory be mostly safe with just the stdlib unittest runner.
Let me know if so and would be happy to review.

Closing this for cleanliness, but happy to review a PR if you're interested in the above.


stack_overflow using puppeteer

Error

Code Snippit

Steps to reproduce:

Use puppeteer to launch browser and visit page as shown in code above.
Compile files via bytenode
Run code and observe overflow.

Environment:
Win10 x64
Node v14.15.5
"puppeteer": "^5.5.0",
"puppeteer-extra": "^3.1.17",
"puppeteer-extra-plugin-stealth": "^2.7.5", // I disabled this and error still occurs.
"puppeteer-extra-plugin-user-data-dir": "^2.2.11"
I did find some similar issues such as #57
I'll do some more digging with puppeteer to see if it is using the Function prototype anywhere, but I'm not sure yet if that's the case here.
Great project btw.

Can confirm it is occurring either on the goto function call, or the subsequent delay call
static delay = ms => new Promise(res => setTimeout(res, ms));

Check this comment.
Let me know if it solves your issue.

Check this comment.
Let me know if it solves your issue.

I had looked into that issue as well, but nowhere am I using the evaluate function. I look into a few of the puppeteer functions but I couldn't find any usage there either.

Further research indicating that this is happening on request interception. Trying to narrow it down if its from request continue/abort or that I'm handling the function asynchronously.

Ok, last update here I think. I assume this is related to the known asyncarrow function issue. Although in the docs it was only mentioned in the context of electron, which is not the case here.
This causes stack overflow:

This, however, functions properly.

The README file should be updated to reflect this issue.
Closing now as there is nothing that we can do to fix puppeteer (or electron too). It seems that the async arrow functions cause a crash whenever two contexts come into contact (node.js with electron, or node.js with puppeteer). This is definitely a C++ bug that most likely should be fixed in v8 itself.


Create injectStyle function with plugins and middlewares

Basically replaces the whole styletron-utils package with the ability to provide plugins to manipulate styles before the declarations injects through middlewares.
Note that I took a little bit of a chance and did a change that might cause a major release. The major change is that you pass the styletron instance as only argument to injectStyle which returns a new function that accepts the other three (style, media and pseudo). The reason I made that choice:

injectStyle is now a required prop for <StyletronProvider /> otherwise we force it to bundle even when it's not used
It felt unnecessary to pass both styletron and injectStyle as prop to <StyletronProvider /> when the instance provides injectStyle with a single method and nothing else.
I believe it also feels more natural to reuse the function for other use cases: module export injectStyle(styletron)

I understand that there may be other than React users to take in consideration but if this may cause any trouble or you don't agree, just let me know.
Here's an example of a basic implementation:
import StyletronClient from 'styletron-client';
import {StyletronProvider} from 'styletron-react';
import {injectStyle} from 'styletron-utils';

const styletron = new StyletronClient();
<StyletronProvider injectStyle={injectStyle(styletron)}>{...}</StyletronProvider>

To make a custom injectStyle you simply pass a plugin or multiple composed plugins as first argument to createInjectStyle:
import StyletronClient from 'styletron-client';
import {StyletronProvider} from 'styletron-react';
import {createInjectStyle} from 'styletron-utils';
import prefixAll from 'inline-style-prefixer';
import otherStylePlugin from 'third-party-style-plugin';

const compose = (...fns) => initial => fns.reduceRight((result, fn) => fn(result), initial);

const styletron = new StyletronClient();
const injectStyle = createInjectStyle(compose(prefixAll, otherStylePlugin));
<StyletronProvider injectStyle={injectStyle(styletron)}>{...}</StyletronProvider>

This term middleware in this case are functions that handles array values and media- and psuedo properties. These are also overridable for customization. But if you define a middleware, the default ones won't be included and you will have to add those you want manually:
const injectStyle = createInjectStyle(
  compose(prefixAll, otherStylePlugin),
  customMiddleware,
  fallbackValueMiddleware,
  mediaMiddleware,
  pseudoMiddleware
);

Fixes #39
EDIT
A featured "old" <StyletronProvider /> with styletron instance as prop and injectStylePrefixed as default is now accessible by importing styletron-react/featured. So that will be the tiniest effort styletron-react users will have to change after an upgrade. If someone doesn't change the import path or provide an injetStyle prop, it will throw.
The reason I choose this solution and not the contrary (a injectStyle provider from styletron-react/custom) is because you would in that case have to import styletron-react/custom everywhere if your bundler doesn't provide tree-shaking.

One idea to prevent a major change could be to move this <StyletronProvider /> to <CustomStyletronProvider /> and revert <StyletronProvider /> to accept the styletron prop which will use the new injectStylePrefixed as default. In that way bundlers will at least have a chance to tree-shake injectStylePrefixed if it's not used.

Nice! Middleware is definitely a nice feature.
Is there a use case for having different middlewares in different parts of your app?
If the instance and injectStyle remained decoupled, you could do do something like:
<StyletronProvider instance={styletron} injectStyle={baseInject}>
  <Stuff/>
  <OtherStuff>
    <StyletronProvider injectStyle={specialInject}>
      <MoreStuff/>
    </StyletronProvider>
  </OtherStuff>
</StyletronProvider>

I also feel like if the core instance is provided, this leaves more room for flexibility as more core API features get added. Indeed, as it stands everything goes through injectStyle. However, I can imagine additional methods being added for example:

prefetchFontFace

Don't inject the font face into the critical CSS, but mark the font to be asynchronously loaded (unless already injected)

There's a lot I want to do with font loading and declarative performance optimization. I'm not sure if that'll end up in Styletron or something else that uses/composes Styletron, but there's definitely the possibility of more methods beyond just injectStyle.

Decoupled the instance and injectStyle. See edit in description.

The injectStyle function is now overridable by the <StyletronProvider />.

@faddee do you understand #97 enough to comment on whether this PR would cover our use?

It's been two months. What's your thoughts? Is there any intention of merging this?

Merge conflicts solved. Also reverted the part where there was two entry points for importing styletron-react since my gut feeling tells it's where the shoe pinches.

Thanks for your feedback. Your alternative approach is better. Letting the user create it's own styled-functions. Closing this PR in favor for a new one.


Serving and debugging a web app prints unactionable survey errors

I'm not sure where this should be resolved (dds/dwds/webdev), so opening the issue here.
But when I try running and debugging a web app with webdev serve --debug, I get repeated survey errors that are unactionable and aren't relevant to developers:
[INFO] Serving DevTools at http://<IP_ADDRESS>:56627
[INFO] Serving `web` on http://<IP_ADDRESS>:8080
[INFO] Running build completed, took 54ms
[INFO] Caching finalized dependency graph completed, took 90ms
[INFO] Succeeded after 146ms with 0 outputs (0 actions)
[INFO] Debug service listening on sse://<IP_ADDRESS>:56677/ecP-qts8hmU=/$debugHandler

ERROR: setActiveSurvey not called. - api/getSurveyShownCount
ERROR: setActiveSurvey not called. - api/getSurveyActionTaken
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Reproduction steps:

dart create -t web web_app
dart pub add dev:webdev
dart run webdev serve --debug
Open DevTools, either through the output link or the debug extension.

Closing in favor of the DevTool issue https://github.com/flutter/devtools/issues/8405.


battery: Initial dedicated API

Recreation of https://github.com/zephyrproject-rtos/zephyr/pull/44846 due to deletion of Fork. See https://github.com/zephyrproject-rtos/zephyr/pull/44846#issuecomment-1163672797

Just fyi, folks. I'm including tests and other work with this pull-request. I have this set as a draft for now for that reason. There's more to come!

hi @aaronemassey  will you be addressing comments and feedback raised in the original PR here? :)

Absolutely. I just had to recreate the pull-request as I wanted folks to know I'm still actively working on this.

Hello @aaronemassey,
This is a pretty exciting addition to Zephyr.
Some basic additions to the proposed framework to support charging ICs could be:
/*
 * Charging power converters can operate in the ‘charging’ mode (charging
 * and/or supplying the system), idle (converter idle), or ‘output’ mode (sending
 * power from the battery to a connected accessory).
 */
enum battery_opmode {
	BATTERY_OPMODE_IDLE = 0,
	BATTERY_OPMODE_CHARGING,
	BATTERY_OPMODE_OUTPUT,
};

/*
 * Charging systems are supplied by attached sources and can supply
 * attached sinks.
 */
enum battery_extconn_attached {
	BATTERY_NO_ATTACHMENT = 0,
	BATTERY_FIXED_SOURCE,
	BATTERY_PROG_SOURCE,
	BATTERY_FIXED_SINK,
};

enum battery_property_type {
	…
	/** Desired CC charging target in mA, 0 disables charging */
	BATTERY_DESIRED_CHARGING_CURRENT,
	/** Desired CV charging target in mV */
	BATTERY_DESIRED_CHARGING_VOLTAGE,
	/** Rising input current regulation target in mA, 0 disables regulation, -1 opens INFET */
	BATTERY_INPUT_CURRENT_REGULATION,
	/** Falling input voltage regulation target in mV, 0 disables regulation */
	BATTERY_INPUT_VOLTAGE_REGULATION
	/** Reverse mode output current limit */
	BATTERY_OUTPUT_SUPPLY_CURRENT,
	/** Reverse mode output voltage limit */
	BATTERY_OUTPUT_SUPPLY_VOLTAGE,
	/** Device operating mode */
	BATTERY_OPMODE,
	/** External connection status */
	BATTERY_EXTCONN_ATTACHED,
	…
};

struct battery_get_property {
	…
	union {
		…
		/** BATTERY_DESIRED_CHARGING_CURRENT */
		int desired_charging_current;
		/** BATTERY_DESIRED_CHARGING_VOLTAGE */
		int desired_charging_voltage;
		/** BATTERY_INPUT_CURRENT_REGULATION */
		int input_current_regulation;
		/** BATTERY_INPUT_VOLTAGE_REGULATION */
		int input_voltage_regulation;
		/** BATTERY_OUTPUT_SUPPLY_CURRENT */
		int output_supply_current;
		/** BATTERY_OUTPUT_SUPPLY_VOLTAGE */
		int output_supply_voltage;
		/** BATTERY_OPMODE */
		enum battery_opmode op_mode;
		/** BATTERY_EXTCONN_ATTACHED */
		enum battery_extconn_attached extconn_attached;
	};
};

Additionally charging ICs require changing settings at runtime, so a corresponding battery_set_property_t type would need to be added.
Finally, it may be a good idea to support private properties like the sensor subsystem does with the ’SENSOR_CHAN_PRIV_START’ member, but this is a ’nice-to-have’ feature.
Let me know if you have any thoughts or questions on this!
Ricardo

@rriveramcrus  I think these are great ideas! Once I have coverage for the API as it stands, I'll add these with stubbed tests, let me know if you're interested in collaborating on a driver/emulator that will leverage these functions.

An unwanted opinion from an inexperienced nobody.
This was also the opinion of another fellow user fabiobaltier in the previous PR.
In my opinion this API should take more inspiration from the Linux's power_supply subsystem. Also power_supply is not only used for implementing batteries, but also charges, adapters, etc. The Linux's API is mature, a lot of use cases and chargers/battery/coulomb counter ICs are implemented, even SBS. It is similar to Zephyr OS sensors API. It may need some rework, like event notifications, but I think it is still good enough.
power_supply.h

An unwanted opinion from an inexperienced nobody. This was also the opinion of another fellow user fabiobaltier in the previous PR.
In my opinion this API should take more inspiration from the Linux's power_supply subsystem. Also power_supply is not only used for implementing batteries, but also charges, adapters, etc. The Linux's API is mature, a lot of use cases and chargers/battery/coulomb counter ICs are implemented, even SBS. It is similar to Zephyr OS sensors API. It may need some rework, like event notifications, but I think it is still good enough.
power_supply.h

This really does seem like a great match, and honestly isn't that far away from what is being proposed here from all appearances.
It's kind of a neat idea though, to make this more than a battery centric API but a power supply API (where am I getting power from, how much current, whats the voltage, whats the source, battery? outlet? solar? if its a battery, which battery?).
Thanks for pointing this out!

Codecov Report

Merging #46817 (33e583b) into main (278120a) will increase coverage by 0.22%.
The diff coverage is 81.70%.

:exclamation: Current head 33e583b differs from pull request most recent head eb143a1. Consider uploading reports for the commit eb143a1 to get more accurate results

@@            Coverage Diff             @@
##             main   #46817      +/-   ##
==========================================
+ Coverage   50.13%   50.36%   +0.22%
==========================================
  Files         690      702      +12
  Lines       86406    89167    +2761
  Branches    20378    21047     +669
==========================================
+ Hits        43318    44906    +1588
- Misses      35780    36637     +857
- Partials     7308     7624     +316

Impacted Files
Coverage Δ

include/zephyr/net/net_ip.h
70.42% <ø> (ø)

include/zephyr/posix/pthread.h
100.00% <ø> (ø)

include/zephyr/sys/fdtable.h
100.00% <ø> (ø)

include/zephyr/rtio/rtio.h
69.04% <72.00%> (-0.72%)
:arrow_down:

lib/posix/pthread.c
91.05% <94.11%> (-0.11%)
:arrow_down:

include/zephyr/net/net_pkt.h
90.66% <100.00%> (+0.37%)
:arrow_up:

kernel/init.c
88.60% <100.00%> (ø)

subsys/mgmt/mcumgr/smp.c
47.76% <0.00%> (-20.33%)
:arrow_down:

subsys/net/ip/nbr.c
77.90% <0.00%> (-4.81%)
:arrow_down:

... and 57 more

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 278120a...eb143a1. Read the comment docs.

@fabiobaltieri @pacodinev @teburd The direction I'd like to go with this work is to keep this PR small and focused to fuel-gauge ICs then we build on top of this a power supply API that's in userspace. Making an RFC with an image showing its long-term development. Part of this should also include a device driver API for charger-IC.

Blocked by https://github.com/zephyrproject-rtos/zephyr/pull/52180

Removed the test for failing registers as I'll add that in its own tiny PR as it introduces some test mockable.

RFC Updated https://github.com/zephyrproject-rtos/zephyr/issues/44847

Tried adding this API as "experimental" but looks like that's done at release time?

Minor things I caught here, but this looks great otherwise. The units are probably different than SBS, but Zephyr is used in a broad spectrum of devices and 32bit values in micro voltage/amps still can represent kilovolts and kiloamps which is far higher than a fuel gauge is likely to ever support, unless you are talking about fast car DC chargers... and even then, kilo's is enough.

And of course in reviewing there's a new sensor PR for a new gauge :-) #52349

Tried adding this API as "experimental" but looks like that's done at release time?

Add it to the API docs page and the status of it in the PR with the next release in mind

Minor things I caught here, but this looks great otherwise. The units are probably different than SBS, but Zephyr is used in a broad spectrum of devices and 32bit values in micro voltage/amps still can represent kilovolts and kiloamps which is far higher than a fuel gauge is likely to ever support, unless you are talking about fast car DC chargers and batteries... and even then, kilo's is probably enough.

Thanks!Moved to uA/uV.

Don't forget "Also add this API to the doc/develop/api/overview.rst as experimental as of the next release."

@teburd

Don't forget "Also add this API to the doc/develop/api/overview.rst as experimental as of the next release."

Where's a good location to add this? In fuel_gauge.rst?

@teburd

Don't forget "Also add this API to the doc/develop/api/overview.rst as experimental as of the next release."

Where's a good location to add this? In fuel_gauge.rst?

Added to the table in the file
https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/develop/api/overview.rst

@teburd

Don't forget "Also add this API to the doc/develop/api/overview.rst as experimental as of the next release."

Where's a good location to add this? In fuel_gauge.rst?

Added to the table in the file https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/develop/api/overview.rst

Oh. Somehow I opened this file up in read-only mode so I thought I wasn't to make changes against it. Thanks!

Disclaimer: I am very inexperienced, so you should probably not waste your time with me! :)
This is based on my opinion and I am sorry for being this long.
From what I am seeing, I might be late to the party. :(
Last time, I didn't saw the RFC, but now I understand it.
My biggest issue with that RFC (and that PR) is the rarity of separate charger IC and fuel gauge IC in the embedded world. Most boards that feature some kind of battery related IC have either fuel gauge IC, charger IC or an IC that combines them both. Example is MAX77818.
This device has to have two separate drivers, because it is both a fuel gauge and a charger. This isn't impossible (Linux's MFD), but I think it is unneeded complication, at least compared to Linux's power_supply.
Yes, I know, SBS is an example of separate charger and fuel gauge (SBS battery), but firstly rarely embedded device uses SBS, and secondly if you want to change charging parameters (at least in the case you can), (most of the time) you need to communicate the change to the SBS battery, and then the SBS battery will communicate the changes to the charger.
As a last example, the very integrated AXP202 from X-Powers.
Linux gets away with using 3 instances of power_supply driver: battery, ac-power, usb-power. (I am not counting the regulator interface and etc.)
With this RFC, you will need to use 4 instances of 3 drivers: 1 - battery, 1 - charger and 2 of something else for usb and ac power monitoring, for the same functionality. And they all will have some very similar APIs.
And in both cases, you will need to have some userspace driver for more advanced processing.


Sliding markers is missleading

I checked in GRSISort <IP_ADDRESS> that if you click and drag one of the red markers, you can move it to a different bin. That is a nice feature, if it worked as (I guess) intended. When you press 'f' to perform a fit, the fit is done in the original position of the markers, not at the slid new ones.
Silly image trying to explain what I mean.

I can confirm that the same things happens in older versions of GRSISort. I think we don't have anything in our code to check if the markers have been moved. I will check if that can easily be changed.

The problem seems to be that the object that is drawn on the canvas is a line whose pointer is stored in the GMarker class alongside with a x/y values. If you move the line you only change it, not the values stored in the GMarker (which are used as ranges for fitting and so on).
There seem to be two options to me:

We change TCanvas to always check if the line is different from the stored x/y (or local x/y) of the GMarker and use it's values instead (or simply just use the lines values instead of the markers).
We can change GMarker to inherit from TLine (instead of TObject) so that we change the marker itself on the canvas.

The latter seems the more elegant version, the former is most likely easier to implement (but also more likely to introduce bugs).


Ignoring invalid device info Beta 2023.8.b0

Please provide as much detail as possible. It's helpful to include Home Assistant debug logs from this integration. Instructions for enabling debugging are available at https://github.com/pyalarmdotcom/alarmdotcom/wiki/How-to-Test-&-Debug#enable-code-debugging. (Alarmdotcom debug logs are verbose, so don't forget to disable debug logging when you're done!)
Describe the bug
Ignoring invalid device info: Invalid device info {'default_manufacturer': 'Alarm.com', 'default_name': 'Bedroom Window', 'identifiers': {('alarmdotcom', 'XXXXXXXX-15')}, 'via_device': ('alarmdotcom', 'XXXXXXXX-127')} for 'alarmdotcom' config entry: device info needs to either describe a device, link to existing device or provide extra information.
All devices go unavailable
To Reproduce
Steps to reproduce the behavior: Install Beta

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Home Assistant Version:
Additional context
Add any other context about the problem here.

V2.2.3 fixed it.  Thank you !!!

closed as fixed

Fixed in v0.3.5, as well.


BusinessUnit doesn't work

Hi, I am using the dev-master of oro platform. I found an error when I tried to create a new user, I cannot pick the business unit. Could you please check

Hi,
Do you have business units created?

I have Main business unit default. And I think the bug related to auto complete search. Event if I re-index the Business Unit Entity, it still cannot search in auto complete form field

Okie, I just run this command
app/console oro:message-queue:consume -vvv --env=prod
and it solved my problem.


Make sure that not all whitespaces are removed

I couldn't find a reference to this, but if you have the following HTML it will not show the spacing correctly between the nodes:
Some bold text.

It will end up like visually like Some boldtext.
This fix will allow at least one space, adding an additional Text component, in favor of showing the layout correctly.

There is an issue though with an example as such:
Some bold  text

The new behavior will make it look like Some bold  text instead of Some bold text (two spaces). I'll implement some text to figure this out.

This PR has been reverted because it introduces new issues while not solving the whitespace problem. The commit 53b8679ddc74badb486348a7404fc835527cb7f4 contains a number of tests that prove this assessment.


checkbox selection link subform

allow linking of multiple records in one hit with a data entry subform that allows multiple lookup fields to make it easier to choose
allow filtering to limit list
auto insert/delete records in the link table on checklist update

done
refer to https://github.com/crutchy-/webdb/commit/93ad55af4ac9ecb4f138ec2ff3ea4ceb96da7b03


Adding raw as optional parameter to expose faraday object

Faraday object exposes status, body and headers
Explanation

Currently json_post only gives you the body as json and not access to the response object.
raw parameter is not passed to LLM provider
raw parameter determines whether to return Faraday object and convert only the body to json

Resolves https://github.com/alexrudall/ruby-openai/issues/255
All Submissions:

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?

@alexrudall passing rubocop requires breaking down the json_post method which is a much larger PR to parse. If the direction looks good then I'll go about it.

The latest version v6 raises HTTP errors as exceptions - I believe catching these errors was the main use-case for this. Closing with that in mind - we can reopen if there is still a usecase for this


Add a getStream method to PlatformFile which allows reading files a few chunks at a time instead of putting the whole file in memory at once

Possible implementation for https://github.com/vinceglb/FileKit/issues/54.
Implementations:

[x] Android
[x] JVM
[x] iOS/macOS
[x] Update Sample Code
[ ] Test:

[x] Android
[x] JVM
[ ] iOS

Notes:
No implementation for JS/Wasm

cool！
Due to equipment limitations, I cannot make sure that the IOS code which I programming right.
thks!


Follow up with Director of BPMO

post PPRC presentation

meeting scheduled dec 3rd

reasoning and approach for analysis
difference from other efforts (e.g. independent study and gartner anual diagnostics)


Node path string does not work

Doing the following:
NodePath path(mystring)
String path_string = path;

Does not seem to work. path_string will be empty. When looking into path it is properly set.
The problem is that this also means copying the NodePath variable to another NodePath does not work because internally that re-passes the string.
Note sure yet why.

If you're just trying to convert a NodePath to a string, you can do
var string_val = str(node_path_value)

Closing this, can't remember what we did but I'm pretty sure we fixed this ages ago :)


How to use The OST dataset ?

The OST dataset Readme said We use the training set only, but the OST dataset has OutdoorSceneTrain_v2 and OutdoorSeg dataset, which one do we use in trianing or we use both?

Should be OutdoorSceneTrain_v2 with 7 classes.


Blackjack issues

There are a few issues with the blackjack game that need fixing:

if user splits then busts on their second hand, dealer will never hit no matter their hand total

Daily tokens are also broken, the flag seems to not be resetting. Need to tell if this is just because some other database operation is breaking or if it’s an issue with that specific Cronjob. Purge is also breaking because the date field is missing if no purge is activated, that might be the issue but I doubt it.
song on the day seems to not be working due to database disruptions

When an insurance bet is won, the wrong total is displayed for the winnings. The actual payout is correct. Make sure the same does not apply for insurance losses

Need to make sure to set “game.splitAces” to false at the end of every turn

Blackjack issues are fixed. Database error TBD but did find a fix with purge. Blackjack will time out after 15 minutes but that might be unavoidable. Not a priority for now

UPDATE: all issues with the blackjack game that have been identified to this point are fixed. The database error requires code refactoring that I won’t be doing on vacation, it will get resolved the 29th/30th

fixed database issues and added check to ensure user can cover their bet at the start of each turn


if expressions returned incorrectly

I noticed parsing this sbml model: BIOMD0000000429_url.xml
that Basico returns expressions containing if statements incorrectly:
In the model there is an expression for  global quantity "Turgor" which Basico currently returns as:
if ( Compartments[V].Volume Values[VP_0] Values[eps] * log ( Compartments[V].Volume / Values[VP_0] ) ,0 )
instead of the correct string:
if( Compartments[V].Volume gt Values[VP_0] , Values[eps] * log( Compartments[V].Volume / Values[VP_0] ) , 0 )
notice that the string returned does not contain the gt and , needed in the if statement

this is fixed in the release from this morning.


[NEW ICON] Postman

Skill Name
Postman
Why?
Probably the best, most popular tool for testing your APIs!
Reference Image

Shall we close this? Postman has already been added 😄


be able to re-trigger PRs through the pipeline without an empty commit

I've gotten this feature request a lot.
This is something the CI system should support, not the resource. It's job is only to return new versions, not frankenstein those version numbers.
Please comment on the issue for concourse support.
Thanks

Concourse team is working on this as of the spaces feature. No need to comments on this anymore.


XA transactions fail with JMS

Description:
See gist.
If I change connectionFactoryName to "ConnectionFactory", the message is still not sent, but at least I get it back in Q1 when the service is killed.
I can change acknowledgementMode to "AUTO_ACKNOWLEDGE" and the message is delivered to Q2, but I need cross-broker XA support in production.
Steps to reproduce:

Run Apache Artemis broker, create one user and anycast queues Q1 and Q2
Update user credentials in bridge.bal from the gist
Run ballerina run -e b7a.log.level=TRACE bridge.bal
Insert one message into Q1
Observe no "Message sent" trace
Kill ballerina service
Observe in Artemis console that the message is neither in Q1 nor Q2

Affected Versions:
Ballerina 0.983.0
OS, DB, other environment details and versions:

Win 10 x64
Apache ActiveMQ Artemis 2.6.2

Currently the Ballerina JMS module doesn't support XA transactions. We have added it to our roadmap hoping to support that by Q1 next year.

Ah, I see, thank you. Then this page is incorrect: https://ballerina.io/learn/by-example/xa-transactions.html

One more note: your current approach to creating JMS connections cannot obtain an XA connection from IBM MQXAConnectionFactory, as it returns an MQConnection from createConnection() and returns an MQXAConnection only from createXAConnection().

Created https://github.com/ballerina-platform/ballerina-lang/issues/12712 to track the documentation issue.

I am closing this issue. Since we moved JMS module to https://github.com/wso2-ballerina/module-jms repository.
Please refer wso2-ballerina/module-jms#20 to get latest updates of this issue


TileMap/GridMap breaks UndoRedo and makes the editor unusable

Godot version:

4c0b077 and 3.2.2
Issue description:

This is related to #24970 #21528 and likely #39393
When you draw on TileMap or GridMap and Alt+Tab while holding mouse button, you will not be able to undo anymore when you refocus editor and click. Also any action that uses UndoRedo (including changing scenes) will fail and throw these errors
 core/undo_redo.cpp:373 - Condition "action_level > 0" is true. Returned: ""
 core/undo_redo.cpp:346 - Condition "action_level > 0" is true. Returned: false

Minimal reproduction project:

ReproductionProject.zip

This is fixed for TileMap in #42489.

I'm currently still having the issue, version 3.2.3. I was alt-tabbing between Aseprite and Godot. Perhaps I clicked an Aseprite hotkey in Aseprite that caused some kind of weird mode? No visual queue popped up that I could tell, and a mode where you can't "undo" seems important to flag to the user.


./waf configure is currently broken

ubuntu 14.04
git bisect points to e9ad8e48a4fb0
root@atsqa4-104:~/cquery# ./waf configure
Waf: The wscript in '/root/cquery' is unreadable
Traceback (most recent call last):
  File "/root/cquery/.waf-2.0.2-b8fa647d13364cbe0c1c8ec06042b54d/waflib/Scripting.py", line 101, in waf_entry_point
    set_main_module(os.path.normpath(os.path.join(Context.run_dir,Context.WSCRIPT_FILE)))
  File "/root/cquery/.waf-2.0.2-b8fa647d13364cbe0c1c8ec06042b54d/waflib/Scripting.py", line 141, in set_main_module
    Context.g_module=Context.load_module(file_path)
  File "/root/cquery/.waf-2.0.2-b8fa647d13364cbe0c1c8ec06042b54d/waflib/Context.py", line 360, in load_module
    exec(compile(code,path,'exec'),module.__dict__)
  File "/root/cquery/wscript", line 360
    defines=[
          ^
SyntaxError: invalid syntax

My bad, seems I forgot some comma's. Fixing right now.

We strongly recommend switching to CMake as Waf will be removed at some point.

Thank you!
on CMake/waf subject, current instructions at getting started offer waf as default. Also, default CMake version that comes with Ubuntu 14.04 is 2.8, same is the one with RHEL 7.4. There might be friction for adoption.
waf builds faster (using my 32 cores), too.


Not able to make nested struct optional

[x] I have looked at the documentation here first?
[x] I have looked at the examples provided that may showcase my question here?

Package version eg. v9, v10: v10
Issue, Question or Enhancement:
I'm trying to make a nested struct optional and run some validations on the nested fields when its presents. But I can't seem to find the right config.

I've tried the omitempty in InvitationPayload.Invitation field but it doesn't seem to work. If the key invitation is not present, then the validator complains about the missing fields in the InvitationEvent.
I've also tried to use required_with_all in the required fields of the InvitationEvent struct and no luck either.

I've found the error. I forgot to use the pointer at Invitation field 😊