Bar chart stacking options not being applied

When I try to create stacked bar charts using
New-ChartBarOptions -Type barStacked or New-ChartBarOptions -Type barStacked100Percent the resulting charts are not stacked.
This happens both in my own code as well as in your examples, such as https://github.com/EvotecIT/PSWriteHTML/blob/master/Examples/Example23-Charts/Example-ChartsBar.ps1
It does not matter whether I use Firefox, Chrome, IE, or Edge.
I'm using PSWriteHTML 0.0.54 and PowerShell 5.1
Thanks,
Colin

Fix will be available in 0.0.55. Probably released over the weekend.


Getbuild update failure

ATTENTION: DO NOT USE THIS FIELD TO ASK SUPPORT QUESTIONS. USE THE PLATFORM CHANNELS FOR THIS.
Fill in the template. Issues that do not respect the model will be closed.
Describe the bug
A clear and concise description of what the bug is.
When I try update, it sometimes succeeds and sometimes fails
**Reproduction code
String onlineStatus = '';
// 更新在线状态
updateOnlineStatus(String status) {
onlineStatus = status;
print(status);
update();
}
To Reproduce
Steps to reproduce the behavior:

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.
Flutter Version:
Enter the version of the Flutter you are using
Getx Version:
Enter the version of the Getx you are using
Describe on which device you found the bug:
ex: Moto z2 - Android.
Minimal reproduce code
Provide a minimum reproduction code for the problem

It works if I go directly to the Home page, but if I go from the login page, offAllNamed (home), it fails responsively


feat: allow waiting for X renders of a component

Pull request description
This is an attempt to handle cases where a test does not get CPU time before a waitfor times out.
The idea is that instead of specifying a timeout, you specify how many render cycles your component can max perform before the waiting fails, with a fallback to a very long wait time (1 min). That should ensure that components that MUST render X number of times before a desired state is visible become more stable.
PR meta checklist

[x] Pull request is targeted at main branch for code
or targeted at stable branch for documentation that is live on bunit.dev.
[x] Pull request is linked to all related issues, if any.
[ ] I have read the CONTRIBUTING.md document.

Code PR specific checklist

[x] My code follows the code style of this project and AspNetCore coding guidelines.
[x] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[ ] I have updated the appropriate sub section in the CHANGELOG.md.
[x] I have added, updated or removed tests to according to my changes.

[x] All tests passed.

Let's go over this on Friday. Want to rubber duck it. It's a bit rushed so not sure all bases are covered.


Move issue from mdr/scalariform here

I think we should copy open issue from orginal scalariform repository here and inform submitters about it.

There is a tool called github issue mover that could do this if you have perms upstream.

no longer needed since we own upstream repo now.

great stuff! That seemed like a load of work!


@Builder.Default fails for init expressions using super or this

Using a @Builder on a class with @Builder.Default on a instance variable fails if the initializing expression refers to this or uses the keyword super.
Example:
class Superclass {
	int number = 1;
}

@Builder
class Subclass extends Superclass {
	@Builder.Default
	int number = super.number + 1;
}

Expected result: Compiles, and the initializing expression refers to number of Superclass.
Actual result: Compiler error: Cannot use super in a static context
The problem is caused by @Builder moving the initializing expression to a private static int $default$number() method, which changes the applicability of this and super.

This is by design and cannot be fixed. To wit:
The way Builder.Default works is that the builder 'gathers' all the required fields, and once its done that, invokes the all-args constructor. During the 'gather' phase, we don't have an instance.
The only way to fix it is to generate a combinatorial explosion of constructors, to generate a constructor with a boolean for EVERY field in addition to the field value, or to have a sentinel 'I have no value, go with the default' option so that the constructor itself chooses whether to invoke the 'produce default value for this field' method; that's the only way we can make those methods non-static.
All possible options to address this cause more harm than this problem, therefore, they're all a bad idea.
In other words, your concern is valid but addressing it breaks more stuff.


Cli#debug folder discovery

Describe the bug
Running yarn mikro-orm debug reports the entities array incorrectly.
Stack trace
See picture (notice the console.log paths :>>  [ './src/database/entity/main/*', './src/database/entity/ci/*' ] is within MetaDiscovery#findEntities)
Note that there are is no dist folder and entities are found so am confident that debug is erroneous
To Reproduce
Steps to reproduce the behavior:

mikro-orm.config.ts - https://hastebin.com/cobukalufo
package.json:

{
  scripts: {
     "mikro": "mikro-orm"
  },
  "devDependencies": {
    "@mikro-orm/cli": "^4.3.2",
    "ts-node": "^9.0.0",
    "typescript": "4.0.2"
  },
  "dependencies": {
    "@mikro-orm/core": "4.3.2",
    "@mikro-orm/reflection": "4.3.2",
    "@mikro-orm/sqlite": "4.3.2",
    "tslib": "^1.13.0"
  },
  ...
  "mikro-orm": {
    "useTsNode": true,
    "configPaths": [
      "./src/database/mikro-orm.config.ts"
    ]
  }

Expected behavior
expect the debug command to report will use the 'entitiesTs' array
Additional context

Versions

Dependency
Version

node
14.15.0

typescript
4.0.2

mikro-orm
4.3.2

your-driver
?

Nope, you have it wrong. Dont use __dirname in the baseDir option, that is almost never what you want, that variable has different value when you run via ts-node.

I tried it without also. This ticket isn't about mis configuration - just
that the debug cli command reports the entity path differently to what's in
use under the hood. 🙃
On Sat, 28 Nov 2020 at 13:28, Martin Adámek<EMAIL_ADDRESS>wrote:

Nope, you have it wrong. Dont use __dirname in the baseDir option, that is
almost never what you want, that variable has different value when you run
via ts-node.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mikro-orm/mikro-orm/issues/1139#issuecomment-735225418,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTCZAWZRHNHGIGN5JWA2TSSDUG5ANCNFSM4UFXSPUQ
.

I see, it always reports the entities paths (so the ones for compiled JS files) - but the paths are correct, you just expect the entitiesTs paths to TS files, right? It should report both ideally.
Note that you should not set tsNode: true in most cases, that is meant for development and tests, it needs to be set to false when running compiled code (it could have performance implications, other than that it should be technically ok).

yeah, exactly as you mention. This debug was initially a nice help (spent days over the years on this with TypeORM).

Will change it so it will print both sets of paths, and encode the tsNode value to the sentence too (will vs could):
 - will use `entities` array (contains 0 references and 1 paths)
   - /.../dist/entities (found)
 - could use `entitiesTs` array (contains 0 references and 1 paths)
   - /.../src/entities (found)

(the value should be dynamic, ts-node is detected automatically)

But when ran with ts-node it would output:

will use entitiesTs array (contains 0 references and 1 paths)

/.../src/entities (found)

could use entities array (contains 0 references and 1 paths)

/.../dist/entities (found)

Yes, when you run the app. But this is not dependent on how CLI is executed (it uses ts-node based on the config from package.json). So it will be different only if you manually specify the value (usually it should be dynamic as I mentioned before).
Feel free to suggest better wording, maybe we should drop the will/could altogether.

Ah ok - this is the context i've been missing - i was using the cli to prove my setup which i think would not be uncommon.
Only thing to add from my pov would then be to preface that text. e.g.
useTsNode found (true)

will use entitiesTs array (contains 0 references and 1 paths)
/.../src/entities (found)
could use entities array (contains 0 references and 1 paths)
/.../dist/entities (found)

Thanks!


Generic inference fails when adding bogus optional generics

TypeScript Version:  2.9.0-dev.20180420
Code
    let id = <T>(b: Test<T>) => 0;
    type Test<T> = (b: T) => any;

    let t = (b: { a: number }) => 0;
    let u = <U>(b: { a: number }) => 0;

    id(t);
    id(u); // Fails on `u`
    let v: Test<{a: number}> = u; // But this passes

    let id2 = <T>(b: Test2<T>) => 0;
    type Test2<T> = <U>(b: T) => any;

    id2(t);
    id2(u); // Now it passes

Expected behavior: I don't even know what the intent here is
Actual behavior: As noted in code comments
Here's the error I get on u:
Argument of type '<U>(b: { a: number; }) => number' is not assignable to parameter of type 'Test<{}>'.
  Types of parameters 'b' and 'b' are incompatible.
    Type '{}' is not assignable to type '{ a: number; }'.
      Property 'a' is missing in type '{}'.

I ran into this problem while writing some complex code, after reducing and reducing forever, I managed to track it down to this very abstract example. My apologies if it's a bit hard to follow. I feel like this is a bug? At the very least it's very unexpected behavior and the error messages surrounding this issue tend to be very cryptic.

Here's a repro that is a bit easier to read:
declare function id<T>(x: (b: T) => any): number;
declare function test<U>(b: string): number;

id(test); // Error because T inferred as {}

We fail to infer string for T because, upon seeing an argument of a type that has a generic signature (in this case <U>(b: string) => number) being passed to a parameter of a type with a non-generic signature (in this case (b: T) => any), we assume that the argument function uses its type parameter (in this case U) in a parameter position. Therefore, we first need to infer for U, and to do that we need to fix any inferences we have made for T so that we can infer to the type involving U. However, the type doesn't actually use U, so it ends up being a fruitless exercise that just causes T to become fixed with no inferences. Hence the {}.
So, it's behaving as intended and is effectively a design limitation of our inference algorithm.

@ahejlsberg So it's another instance of Microsoft/TypeScript#22617?
I would really love to eventually get that one, as it's basically required for lifted type constructors, which is where I ran into this bug twice now. There's a lot of situations where you have something like
<U>(a: T) => Array<T>

The only way to properly type anything that passes through such lifting functions is by inferring the return type, but this issue is blocking it. I thought I found a workaround, but apparently, I just moved the issue elsewhere :)


Replace assertions used to signal error with exceptions with better messages

At some point, I'm hoping to make a pass through all of the code fixing as many of these as I can.

From #54:

Currently a formula like 'y ~ a * b' will throw an assertion error during code generation. Maybe we can recognize * as a valid Op but throw an NotImplementedError if we see it being used in the formula.
File "/Users/npradhan/workspace/pyro_dev/brmp/brmp/formula.py", line 208, in rpn2ast
    assert len(out) == 1
AssertionError


allow running setupFiles before nuxt environment

I am using FormKit in some of my components, and formkit is throwing a ResizeObserver is not defined error when I'm running my tests with the jsdom environment instead of the happy-dom environment

In the latest nightly release of @nuxt/test-utils we now implement the environment with a setup file, meaning it should be possible to allow users to specify setup files to run before the nuxt environment is made ready. Any PR would be welcome on this if I don't get a chance first. 🙏

In the latest nightly release of @nuxt/test-utils we now implement the environment with a setup file, meaning it should be possible to allow users to specify setup files to run before the nuxt environment is made ready. Any PR would be welcome on this if I don't get a chance first. 🙏

Hey @danielroe, in my experience, I see that this is now the default behaviour. But is there still a way to run the setup files after the nuxt environment is set-up?


[WIP] try out tox-travis

:+1:

Thanks! I had a quick look around the travis logs, and it looks like tox-travis works as advertised.


Input textarea

This PR adds a new InputTextarea component.

In addition it adds three sub components to inputs InputLabel, HelperText, ErrorMessage and some shared styles and behavior in InputShared
InputText was also refactored to use these new sub components

I noticed here that I can click on the label expecting it to fade out but it does not. See video for interaction. However, it works as expected in the kitchen sink.
https://user-images.githubusercontent.com/347490/164580279-999239bf-1306-4342-ba3d-382b7b203009.mov


COMP: Locally ignore Clang -Wmismatched-tags warnings in ImageRegion

After pull request https://github.com/InsightSoftwareConsortium/ITK/pull/4367 commit 72aa9a602bd92b665acc915d8df4bd00a27c98f0 (ENH: ImageRegion support C++17 structured binding), a few unimportant -Wmismatched-tags warnings appeared from Mac10.13-AppleClang-rel-x86_64, at
https://open.cdash.org/build/9256915 as was reported to me by mail, from Dženan Zukić (@dzenanz) and Sean McBride (@seanm).
This commit locally disables those warnings, following https://github.com/Naios/continuable/blob/121265df7123cf672ea8db917eaca2d0fbd9aef5/include/continuable/continuable-result.hpp#L291-L308 by Denis Blank (@Naios).

@seanm does this take care of the warnings?

Ah, just saw this now. I suppose it's unnecessary when changing the bots to use ITK_CXX_WARNING_FLAGS instead.
But merging it too would be harmless.  Up to you.

I suppose it's unnecessary when changing the bots to use ITK_CXX_WARNING_FLAGS instead.

Thanks @seanm, but if this PR is entirely unnecessary, I'd rather just abandon it. Could it possibly still be useful to other ITK users?

Could it possibly still be useful to other ITK users?

I suppose it could. After all, it's ITK itself turning on -Wall (of which -Wmismatched-tags is part).

/azp run ITK.Windows


If 458 equipment efficiency link status to factorymanager

Task linked: IF-458 Equipment Efficiency dashboard: Realtime Status should have link to Factory Manager - Assets table with respective Filter


Could not resolve ***/vite.content.config.ts

Could not resolve "/vite.content.config.ts"
Could not resolve entry module "index.html".
 ELIFECYCLE  Command failed with exit code 1.
error during build:
RollupError: Could not resolve entry module "index.html".

之前改过的源代码可能忘记提交了，而且找不到了，我刚刚补了一下应该可以了。
改了一点点东西，可以看下readme


Introduce a form/button/endpoint to automate content submission

Use the development version of the website to login (via VS Code), commit (via git) and push (via git) new content to GitHub.

The new scripts added in recent updates have already addressed this issue in a different manner. Closing.


Create landing page for new Catalogue Search

Description
The new Catalogue Search functionality will start with a landing page that does not initiate any search, but provides all the necessary options to start. Below are some mockups of what it may look like:

Features

The landing page is full width across the page - it does not split between two views like the Browse pages do.
Initially only a wide search bar will be present. An expandable/collapsable section will allow the user to toggle viewing the more advanced filter options
The existing search filters will be present in the advanced section, but will use a better UI layout.
Only when the Search button is clicked will a new search start, which will navigate to the new CatalogueSearchListingComponent

Addition: default label only search. option for full search, currently the opposite but now prohibitive due to load


adding all yishuves polygons

Codecov Report
Patch and project coverage have no change.

Comparison is base (5f3c929) 53.23% compared to head (b0806ea) 53.23%.
Report is 3 commits behind head on dev.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##              dev    #2457   +/-   ##
=======================================
  Coverage   53.23%   53.23%
=======================================
  Files         117      117
  Lines        9633     9633
=======================================
  Hits         5128     5128
  Misses       4505     4505

Flag
Coverage Δ

unittests
53.23% <ø> (ø)

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

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


cargo build & run don't create a fresh build in WSL

I decided to give Windows Subsystem for Linux (w/ Ubuntu) a shot and after installing rust via rustup I have this strange issue:
cargo build and cargo run will create a binary once, but subsequent code changes will not be detected by build and run (they immediately finish and run uses the old binary). A workaround is to delete the binary from the target directory, which will cause a fresh one to be built.
cargo check does cause a fresh compilation every time, however using check does not assist build and run in generating a new binary (the problem persists).
Happy to provide additional details upon request
cargo --version: cargo 0.25.0 (96d8071da 2018-02-26)
uname -a: Linux DESKTOP-E7Q7M5A 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux

I believe it's lxfs? This is what df -Th gives me:
rootfs         lxfs   465G  107G  358G  23% /
none           tmpfs  465G  107G  358G  23% /dev
none           tmpfs  465G  107G  358G  23% /run
none           tmpfs  465G  107G  358G  23% /run/lock
none           tmpfs  465G  107G  358G  23% /run/shm
none           tmpfs  465G  107G  358G  23% /run/user
C:             drvfs  465G  107G  358G  23% /mnt/c
D:             drvfs  1.9T  985G  879G  53% /mnt/d

Though oddly enough cat /etc/fstab suggests ext4: LABEL=cloudimg-rootfs   /        ext4   defaults        0 0

How odd :(
Unfortunately I'm away from my Windows computer right now but I'll try again next and see if I can reproduce this locally

Sounds good, thanks!
Could you maybe point me to where cargo checks timestamps or any other areas you might suspect? If I find some free time I can try and poke around with a local cargo build as well.


Fix XSS Vulnerability in almost all pages

The frontend is not defended against XSS.
Possible solutions:

Escape all input
Escape all output
Add security headers

potential fix found using
web_server.jinja_options["autoescape"] = lambda _: True```
not sure if this 100% safe but i will look into the api responses and escape any user input


Fixing csharp multi profiles

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-node

Automation for azure-sdk-for-js

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java

Addressing https://github.com/Azure/azure-sdk-for-net/issues/4844

Hey @dsgouda can you please close this, or merge it if required?

@salameer will get to this today, thanks

@lmazuel could you take a look at the python failures

@salameer I don not have merge permissions here and not sure why the python build is failing.
The net sdk build failures can be disregarded since we won't be generating any sdk for these tags anyway

@lmazuel can you kindly take a look on these

Python Side is good with it, I would say lets go forward here

@dsgouda this is good to go


Move Tye to .NET 6

Moves the Tye CLI and related components (like the container proxy) to .NET 6.  Updates test asset projects to .NET 6 as well.  These changes mean development machines must have .NET 6 installed in order to use Tye in addition to the .NET SDK/runtime used by the projects built/started by Tye.  For example, if your application still targets .NET Core 3.1, you will need to have both the .NET 6 runtime and the .NET Core 3.1 SDK/runtime installed.
Existing .NET Standard libraries (e.g. the configuration library) will continue to target .NET Standard.

NOTE: Samples are not planned to be updated with this PR.  This work will be done in a follow-up PR.

Related to #1213
Resolves #1216

Should this https://github.com/dotnet/tye/blob/main/docs/getting_started.md be updated as well?

Yes, thanks for thinking of that.  I made a quick pass through the docs and updated outdated references to .NET Core.

Too late, but this is missing:
In order for Tye to work on a Mac that has both the arm64 and x64 SDKs you need to supply the  -a x64parameter when installing the tool. That is because Tye is dependant on .NET Core 3.1 which is x64.
Example:
dotnet tool install -a x64 -g Microsoft.Tye --version "0.10.0-alpha.21420.1"


Add Nong Song: Karakara

Song Name
Karakara
Artist Name
Kessoku Band
Source
Youtube
Youtube Link
https://www.youtube.com/watch?v=MTPiaDzacSI
Direct File Link
No response
Song ID
522306
Start Offset [ms]
No response
Extra
No response

reject


feat(naming): rename DigInc to Digsec

Description
Comments/issues/screenshots:

Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] The PR includes a closes #issueID
[x] The PR includes a picture showing visual changes

Uff vi må gjøre om slik at du henter dataen fra backend as


SetIfAbsent: Support Lazy value

Sometime get value is cost too many cpu. So we cache the value on a map.
So I want to change the SetIfAbsent like that:
func (m *ConcurrentMap) SetIfAbsent(key string, fn func() interface{}) bool {
	// Get map shard.
	shard := m.GetShard(key)
	shard.Lock()
	_, ok := shard.items[key]
	if !ok {
		shard.items[key] = fn()
	}
	shard.Unlock()
	return !ok
}

Would you mind give suggestions for me?

Hi @JadenTeng, your example looks good to me.
You can easily implement this function in your code, this is why GetShard() function is public.
Or, even better,
If you want, you can create a pull request with a new function LazySetIfAbsent(...) and we will merge it to our project.
good luck,
let us know if you need any assitance.

Hi @eranchetz
Please Review pull request.


allow optimization of single multi-value column input expr with repeated identifier

Fixes #9414.
Description
An oversight from #8957, I forgot to remove this check, which was preventing single multi-valued column input expressions from using an optimized single column expression selector.

This PR has:

[x] been self-reviewed.
[x] added unit tests or modified existing tests to cover new code paths.

Key changed/added classes in this PR

ExpressionSelectors

Can you think of a way to add a test? (The results don't change, we were just missing a performance optimization. We don't have a perf test framework yet, but even without one, any ideas?)

It is pretty ugly, but I added a test to confirm that SingleStringInputDimensionSelector is chosen over MultiValueExpressionDimensionSelector for selectors with capabilities that are compatible with the optimization.


Revert "Rework recovery"

Reverts ElementsProject/peerswap#192
190d3238 swap/fsm.go (kon           2021-07-13 17:45:44 +0200  19) // ErrFsmConfig is the error returned when the fsm configuartion is invalid
190d3238 swap/fsm.go (kon           2021-07-13 17:45:44 +0200  20) // i.e. the fsm does not contain the next state
e7bda7fa fsm/fsm.go  (kon           2021-06-26 08:45:21 +0200  21) var ErrFsmConfig = errors.New("fsm config invalid")

This codepath was triggered on a node running PR #192 attempting to do a lbtc swap-out.
Investigating if reversion is necessary. This might actually be an unrelated race condition!

Reverting due to issue #200. Needs more investigation.


Created query function for client

Created a query function for the client, and changed the timeline to
use that instead of the server’s.

I'm not entirely certain I've done this properly (I'm particularly unsure about TOTAL_QUERIES), but I thought I'd give it a shot since I'm the one that needs it.  It does seem to work this way.

Can you explain what was broken before?  I am a bit unfamiliar with timeline in general.

It was to fix what I was seeing in my comment here - Timeline seems to be a function of the client, not the server - before your fix to handle timeout in the connection, it was using the proper URL, but your fix had it (at least with my setup) trying to connect to the server with a URL that exists only in the client interface.

I did a lot of cleanup in this area in the last few days.  The changes this merge request was solving should also be working. Specifically, I changes the default client actions to talk directly to the client and not proxy through the server. A test for timeline has also been added to ensure this wont regress.


ToolBox Addition: InteractiveBrokersDataDownloader

I noticed that  Interactive Brokers historical  data is not an option for Backtesting. Is that correct?.  I wonder if there is any technical / licence / agreement  constraint that prevented this feature or it's just pending to implement.  Thanks.

benjamin did you manage to find the problem?

@michaelsrew  no I didn't . This test is for Interactive Broker's GetHistory method. The logic makes multiple calls to the API in order to download the complete history.  For minute resolution, the calls are for one day of data at a time.  Duration = 1 D ( check  method  ConvertResolutionToDuration() ), but if one of this calls comes back  empty,  the loop exists with no  error.  I'm not sure, but I  think weekends days might come back empty an  exist the loop?.

hm i tried to implement an ib downloader for minute data long time ago. but downloading data for sp500 would take long time so i decided to use the terminal at quantconnect.  this approach i found better so i could download stock prices and test it multiple times on the harddrive.
so first you set the date where you want to start and the end date. it loops through from start to end and thats it you have the data on your drive. IB does not provide any data info or error i think want it is weekend because the request goes OK but returns nothing....so no error as i can remember. simply looping over the days and thats it. the advantage over a downloader is that you have the data localy. the historyprovider is i think for warming up and that stuff. but warming up can also work localy from harddrive i thought at least at the beginning.

@jaredbroad  approach was to reuse IB history provider for the  downloaded. And It can be done as long as the history provider does what it's supposed to do. But in my test case is not doing that due to the problem I described. Maybe someone else can take a look and confirm whether or not this is a problem on IB history provider.

aaahhh ok you want to use the history provider for the download now i get it. i will take a look at your test file in an hour when i get home.

but to be clear...what i wanted to say.....the api of IB will not give you minute data for 10 days.....
due to limitations you get one day:
https://interactivebrokers.github.io/tws-api/historical_limitations.html#gsc.tab=0
so maybe the request is send for 10 days and IB returns only one day(the last day)
that is perhaps the problem.....thats why the while loop....loop through the days because API sends only one day minute data per request.

@benjaminthedonkey @michaelsrew
The IB History method had a couple of bugs (#1637) when requiring more than one API call to complete the request and a fix (#1669) has been submitted.

Sounds good, thanks. I'll try to complete this by next week.


Icon Pack Submission - Blinded - Beta

** Name of the icon pack**
Blinded - Dark
** Version **
0.1.0 (Beta)
** Author of the icon pack **
TheRealGriind
** Description of the icon pack **
A Dark version of the Blinded Icon Pack made by TheReal Griind Icon ideas? Please tag @Griind#9039 on the official MD Discord.
** GitHub repository ** (Optional)
Don't have a github repository for it
yet, and since I can't upload iconpack files, Imma send the picture files hope this is fine...
Blinded v0.1.0.zip

Please use the export icon pack function of Macro Deck and send the exported file.

Not able to directly upload the iconpack file here, so You'll have to download it from the directory.. https://github.com/TheRealGriind/Blinded-Iconpack


Pipeline crashes when single record has no incremental cursor path

dlt version
0.5.1
Describe the problem
The following data crashes when trying to load it incrementally with the cursor_path="created_at"
    data = [
        {"id": 1, "created_at": 1},
        {"id": 2, "created_at": None},
        {"id": 3, "created_at": 2},
    ]

I could not isolate it yet, but in version 0.4.12 the second row where the created_at is None was skipped and not loaded into the destination.
Expected behavior
Issue a warning instead of an error.
Allow the user to set a default cursor_path in case the value is None.
Steps to reproduce
todo
Operating system
macOS
Runtime environment
Local
Python version
3.11
dlt data source
No response
dlt destination
No response
Other deployment details
No response
Additional information
No response

@willi-mueller how dlt should behave in this case? We cannot really say if this record is in range or not if cursor column is not provided.
IMO we need nice exception message here explaining what happen, now I bet max function is simply failing on some Python internals

@willi-mueller OK so it seems we need another setting in the incremental:
on_none_cursor_value: raise, include, exclude to govern such behavior
also should work on object and arrow tables
WDYT?

@willi-mueller idea of the callable is also good but I'm not sure if add_map is not enough?
https://dlthub.com/docs/general-usage/resource#filter-transform-and-pivot-data
it does exactly what the user wants

@willi-mueller OK so it seems we need another setting in the incremental: on_none_cursor_value: raise, include, exclude
so it is user's conscious decision what to do with such values. btw. this is possible even now by defining own max (last_value_func) that accepts nones.
also should work on object and arrow tables WDYT?

from what I observed, it crashes in find_cursor_value() which is executed even before the last_value_func(), such as max().
This, a custom last_value_func does not seem to solve this problem.

@rudolfix I am afraid that neither the add_map() nor a custom last_value_func solve this issue because both are executed only after the incremental.__call__() calls the find_cursor_value() where the exception is raised.
I am afraid that we need to touch the incremental object.
I like the idea of the parameter on_none_cursor_value={"raise", "include", "exclude"}.
I am not sure if the add_map() could eliminate the need to pass in a callable that sets default values because the callable would be executed before the last_value_func whereas the transformer is executed afterward.

Another problem with the add_map() is that it is not supported yet for arrow-table and arrow-batch.
dlt.extract.exceptions.ResourceExtractionError: In processing pipe some_data: extraction of resource some_data in transform MapItem caused an exception: 'pyarrow.lib.RecordBatch' object has no attribute 'get'

@rudolfix @sh-rp Yes, you are right: add_map(my_func, insert_at=1) is sufficient to set default values because with insert_at=1 it is executed before the incremental.__call__(). Thank you for the pointer!
However, this issue is still open because of two reasons:

if users want to ingest data as it is then we still need to adjust the incremental implementation. Importing data as it is in the source is an important feature especially for SQL sources because users might want to run the same queries they have on the source system also on the destination system.
The currently thrown exception IncrementalCursorPathMissing can be misleading because it is thrown when the path is present but the value at the path is None. Thus, we propose to use this exception only if the path is missing and the exception IncrementalCursorPathHasValueNone in case the cursor path exists but the value is None.


[BUG] Black pixel border on right side of image when in 2028x1520 / 2028*1080 modes

Describe the bug
when setting above resolutions in the e.g. sample app a black border is added to the image, both video or still
To Reproduce
run sample app_complete, set resolution, be amazed
Expected behaviour
no black border
Console Output, Screenshots
border

no border

Hardware :
4b and hq cam

Indeed, it's strange. Even this trivial example seems to do it:
from PyQt5.QtWidgets import QApplication
from picamera2 import Picamera2
from picamera2.previews.qt import QGlPicamera2

app = QApplication([])
picam2 = Picamera2()
config = picam2.create_preview_configuration({'size': (2028, 1520)})
picam2.configure(config)
qpicamera2 = QGlPicamera2(picam2, width=640, height=480)

picam2.start()
qpicamera2.show()
app.exec()

I found that in the file q_ql_picamera2.py where it calls glViewport, if I replace w by w + 1 then it seems to work. A bit baffling. If anyone can explain that to me then I would be delighted...

I originally stumbled over it in an app without any qt dependencies or preview if that helps in any way

Oh you're right, it's a camera mode thing. So I guess the simplest test case is
libcamera-still -o test.jpg -r --width 2028 --height 1520

Yes, we'll need to investigate that - thanks for reporting it!

There does seem to be a problem in the kernel driver. It'll be "a couple of weeks" or so before a fix will available via rpi-update.


istiod:2021-03-13T05:22:55.376108Z	info	validationController	Reconcile(enter): retry dry-run creation of invalid config 2021-03-13T05:22:55.403467Z	info	validationController	Not ready to switch validation to fail-closed: dummy invalid config not rejected 2021-03-13T05:22:55.404014Z	info	validationController	validatingwebhookconfiguration istiod-istio-system (failurePolicy=Ignore, resourceVersion=2269995) is up-to-date. No change required.

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
There are some invalid logs in the istiod pod.
2021-03-13T05:22:54.376409Z	info	validationController	validatingwebhookconfiguration istiod-istio-system (failurePolicy=Ignore, resourceVersion=2269995) is up-to-date. No change required.
2021-03-13T05:22:54.856554Z	info	validationController	Reconcile(enter): retry dry-run creation of invalid config
2021-03-13T05:22:54.860603Z	info	validationController	Not ready to switch validation to fail-closed: dummy invalid config not rejected
2021-03-13T05:22:54.861114Z	info	validationController	validatingwebhookconfiguration istiod-istio-system (failurePolicy=Ignore, resourceVersion=2269995) is up-to-date. No change required.
2021-03-13T05:22:54.866141Z	info	validationController	Reconcile(enter): retry dry-run creation of invalid config
2021-03-13T05:22:54.869997Z	info	validationController	Not ready to switch validation to fail-closed: dummy invalid config not rejected
2021-03-13T05:22:54.870481Z	info	validationController	validatingwebhookconfiguration istiod-istio-system (failurePolicy=Ignore, resourceVersion=2269995) is up-to-date. No change required.
2021-03-13T05:22:55.376108Z	info	validationController	Reconcile(enter): retry dry-run creation of invalid config
2021-03-13T05:22:55.403467Z	info	validationController	Not ready to switch validation to fail-closed: dummy invalid config not rejected
2021-03-13T05:22:55.404014Z	info	validationController	validatingwebhookconfiguration istiod-istio-system (failurePolicy=Ignore, resourceVersion=2269995) is up-to-date. No change required.
2021-03-13T05:22:55.860861Z	info	validationController	Reconcile(enter): retry dry-run creation of invalid config
2021-03-13T05:22:55.983999Z

[ ] Docs
[X] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[X] User Experience
[X] Developer Infrastructure
[ ] Upgrade
Expected behavior
No Invalid print in the command
Steps to reproduce the bug

install the istio-operator
istio-1.8.1/bin/istioctl operator init --revision 1-8-1

2.install the istio cluster
kubectl apply -f example-istiocontrolplane-1-8-1.yaml -n istio-system
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: example-istiocontrolplane-1-8-1
spec:
  revision: 1-8-1

see the istiod log
kubectl logs -f istiod-1-8-1-5bdfc9d958-mgslt    -n istio-system

Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
[root@mesh-10-20-11-190 ~]# istioctl version --remote
client version: 1.8.1
control plane version: 1.8.1
data plane version: 1.8.1 (1 proxies)

How was Istio installed?
istio operator
Environment where the bug was observed (cloud vendor, OS, etc)
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

This is a known issue documented in https://istio.io/latest/docs/setup/upgrade/canary/#control-plane. Please see the linked issue there

ok.thanks


NodeToolInstaller does not satisfy npm demand

Environment
Azure DevOps Server (including 2019 RTW), any agent version.
Issue Description

Create a build pipeline with a job that contains "Node Tool installer" task and "NPM" task.
Schedule the build on a queue that has no agent "npm" capability

Because "Node Tool installer" task is not marked to satisfy "npm" capability, the build fails to be assigned to an agent.
Error logs
No agent found in pool default which satisfies the specified demands:
npm
Agent.Version -gtVersion 1.91.0

I added a comment to your PR. This goes along with a larger issue which is that currently when we install node we don't install the corresponding npm version which seems to be the expectation from most users (I was surprised when I realized that's not happening). As we major version this task, I think it would probably be good to do that by default, or at least have an option to do it.

@damccorm - the corresponding npm should be getting installed.  The node targz / zip should contain both.  But it does not "satisfy" npm but probably should

It does except for node <5 on Windows. I have a repro where its definitely not getting npm. That makes sense because we're using the fallback and getting the exe/lib files instead of the zip.

Sounds good, lets merge the PR then. I'd still like to make that behavior consistent after we have our full Use Node POC though. Its weird behavior to install npm for almost all cases, but not some especially if we're saying we satisfy an npm demand.

I'm using on-premise version of azure dev ops server, and it looks like I don't have this fix. Is there any workaround I can do (without adding the npm capability to every agent)?

You can upload/pin to the newest version of the task - https://github.com/microsoft/azure-pipelines-tasks/blob/master/docs/pinToTaskVersion/pinToTaskVersion.md


Support lambdas

Hello.  It's me again. :)
I have an implementation of lambdas locally.  Are you interested in adding lambda support to this library?
If so, how can they be properly tested in mustache_spec_test?  The ~lambdas.yml file seems to include code for various languages as strings, which I take to mean it implicitly relies on the existence of an "eval" function in the language.  AFAIK Dart doesn't have eval, so...
Any advice on how to make the tests work?  My current thought is to:

Add 'dart' entries under each 'lambda' section in ~lambdas.yml.
In mustache_spec_test.dart, add something like this at the top of the runTest function:

// Special case: the lambda tests contain source code for various languages.
// Extract out this code and run it in a new isolate.  Then, replace that
// entry with a map with a function that talks to the isolate.
if (data.containsKey('lambda') && data['lambda'].containsKey['dart']) {
    String lambdaSource = data['lambda']['dart'];
    String lambdaUri = 'tmp/lambda.dart';
    File lambdaFile = new File('tmp/lambda.dart');
    IOSink lambdaSink = lambdaFile.openWrite();
    lambdaSink.add(lambdaSource.codeUnits);
    isolate.SendPort port = isolate.spawnUri(lambdaUri);
    data['lambda'] = ??? // I reached the limit of my Dart skills
}

Friendly ping. Does this library support lambdas?

Lambdas are not yet supported.
I'll see if I can find time over the next week or two to come up with some solutions to the various issues.
I'm still not 100% sure how I want to exposed the API for lambda's and partials. I'll put something up in another branch. Feedback would be appreciated.

I've cooked up a simple implementation for lambdas. The following works - is this what you were expecting?
  var template = '<{{#markdown}}{{content}}{{/markdown}}>';
  var values = {'markdown': (s) => s.toLowerCase(), 'content': 'OI YOU!'};
  var output = '<oi you!>';
  expect(parse(template).renderString(values), equals(output));

Note this is actually not correct as per the mustache spec, which says:
Lambdas
When the value is a callable object, such as a function or lambda, the object will be invoked
and passed the block of text. The text passed is the literal block, unrendered. {{tags}} will not
have been expanded - the lambda should do that on its own. In this way you can implement
filters or caching.

However many popular mustache libraries implement this differently, and I think generally the simpler behaviour, as I have currently implemented is better. I have ideas about how I could variable expansion later in a backwards compatible way.
The code is in the partials branch:
https://github.com/xxgreg/mustache/tree/partials

FWIW I don't have a problem with managing the mustache conversion inside the lambda.
Otherwise, looks good!

One benefit of your solution (and a problem with the "official" way mustache specs this behavior): lambdas inside of loops will get an implicitly relative context.
With the "official" way, there's no way to understand that your lambda is executing inside of a nested context. The current context isn't passed to the lambda.

I've implemented lambdas like this now - see below. Hopefully the best of both worlds. The String returned from the lambda isn't evaluated, but you can do that yourself in the lambda by calling renderSource(source).
typedef Object LambdaFunction(LambdaContext context);

/// Passed as an argument to a mustache lambda function.
abstract class LambdaContext {

  /// Render the current section tag in the current context and return the
  /// result as a string.
  String renderString();

  /// Get the unevaluated template source for the current section tag.
  String get source;

  /// Evaluate the string as a mustache template using the current context.
  String renderSource(String source);

 /// Lookup the value of a variable in the current context.
 Object lookup(String variableName);
}

Now on pub version 0.2.


Saidatta/top bar

remove all storybook build files

Chips and Tabs is pending. also need to add varriants


UI: Differenciate metadata from content in preview

Right now it's hard to know what belongs to the metadata and what belongs to content.

Interesting, and makes sense. More abstractly, we need a subset of fields that do not preview, and are probably expandable. Slug handling could happen here too. One of the design concepts showed something like this I believe.

Shawn, I'd love to explicitly visualize the different between metadata inputs and visible inputs; going to assign myself here to make a mockup of how this would be visualized

@DirtyF What type of metadata you are referring to? The metadata which is entered in the front-matter?


Add hazelcast::new_client() and hazelcast::new_client(client_config) to create new clients - Make hazelcast_client constructor private

Added the free functions hazelcast::new_client() and hazelcast::new_client(client_config) to create new clients without using the constructor. The hazelcast_client constructor is made as private so that the users will be forced to use the free factory functions to create and start new clients.

Linux test PASSed.

Linux test PASSed.

Windows test FAILed.

Windows test FAILed.

Linux test PASSed.

Linux test PASSed.

Windows test PASSed.

Windows test PASSed.

Linux test FAILed.

Linux test FAILed.

Windows test FAILed.

Windows test FAILed.

verify-linux

verify-linux

Linux test FAILed.

Linux test FAILed.

Windows test PASSed.

Windows test PASSed.

Linux test FAILed.

Linux test FAILed.

verify-linux

verify-linux

Linux test PASSed.

Linux test PASSed.

A question: Now that the client creation is also asynchronous, would it ever make sense to set client_connection_strategy_config::set_async_start(true)?

A question: Now that the client creation is also asynchronous, would it ever make sense to set client_connection_strategy_config::set_async_start(true)?

A question: Now that the client creation is also asynchronous, would it ever make sense to do client_connection_strategy_config::set_async_start(true)?

There is a slight difference, in start_async mode, the new_client(std::move(config)).get() may return without any connection to cluster(if any invocation during the time it connects e.g. get_map, it will throw client_offline_exception), while in the other mode it will wait to connect to the cluster. This will work similar also during reconnections. Hence, there is a slight difference. May not be a very useful feature but this is a PM (@burakcelebi ) decision to remove it or not i guess.

A question: Now that the client creation is also asynchronous, would it ever make sense to do client_connection_strategy_config::set_async_start(true)?

There is a slight difference, in start_async mode, the new_client(std::move(config)).get() may return without any connection to cluster(if any invocation during the time it connects e.g. get_map, it will throw client_offline_exception), while in the other mode it will wait to connect to the cluster. This will work similar also during reconnections. Hence, there is a slight difference. May not be a very useful feature but this is a PM (@burakcelebi ) decision to remove it or not i guess.

Linux test PASSed.

Linux test PASSed.

Linux test PASSed.

Linux test PASSed.

Windows test PASSed.

Windows test PASSed.

Windows test PASSed.

Windows test PASSed.

Windows test FAILed.

Windows test FAILed.

verify-windows

verify-windows

Linux test FAILed.

Linux test FAILed.

Linux test FAILed.

Linux test FAILed.

Windows test PASSed.

Windows test PASSed.

Windows test PASSed.

Windows test PASSed.

verify-linux

verify-linux

Linux test PASSed.

Linux test PASSed.


No makecode menu in RetroPie on GPi

I have installed this to a gpi 2 and there is no make code on the emulator menu.
I verified the files are all there and I can see it's entry in the config file.

?

Ok, could you please provide me with:

Exact hardware (RPi0 v 1 or 2)?
What distribution(RetroPie, Recalbox or Batocera) and versjon?
Printout of «uname -a»?

Just tested successfull install on latest Batocera and Recalbox on RPi, but encountered a regression on my side, or a breaking update for game menu/theme on latest RetroPie, which I am looking at right now.

One thing worth into g I never could get it to install using Burke as shown in the instructions. It gave a error about the site having a ssl issue or something. I had to upload it all over FTP and then make the install script executable and then run it.

hmm It seems like i should really switch to batocera then on the gpi2. I had others recoment that os also. I just was used to running retropie from past use so i used that. After i get it working on the cm4 in a  gpi2 case i plan to install this McAirpos on a gpi with a raspbery pi zero 2 w thats also currently using retropie. Unless i just change them both over to batocera since its currently working there you say.

Not sure what you mean by «Burke»… curl? ;-)
The certificate/ssl issue used to be possible to solve with something like this:
wget --no-check-certificate https://raw.githubusercontent.com/Vegz78/McAirpos/master/install.sh&&chmod +x ./install.sh&&./install.sh
Does that work for you on cm4?
Sorry about broken RetroPie install script, trying to fix as fast as I can. Do you remember approximately around what version they changed their carbon theme?

…i plan to install this McAirpos on a gpi with a raspbery pi zero 2 w thats also currently using retropie. Unless i just change them both over to batocera since its currently working there you say.

Please wait until the installer bug is fixed, unless you know the manual steps.

sorry that was i typo. i want i could never get it to install with curl like the instructions said to do.
i was able to run the installer fine once i just manually uploaded all the files to it. though i have this menu issue.
i am sorry no i do not remember when they changed it, its been a few years since i last used retropie. to see it on the menu do i have to use the carbon theme (i noticed that the carbon theme was mentioned in your scripts so i did try it and it was not visible in that theme eaither.)

ya ill wait for you to fix it and will do any testing you want. it will be less work to do that than re-image these things and set them up haha.

this is a new setup. i just got these things a couple of days ago. it has never worked for me. everything else works. i can tell it to update if that will help it work with this makecode thing.

ok ya thats right its 4.7.2

oh an its just that the makecode option is not on the menu. the menu itself works fine otherwise.

the installation of McAirpos did not break anything it just did not work to add makecode to the menu to launch the makecode games even though far as i can tell the install did all the things it was supposed to.

this is the image/ build i installed.
https://www.patreon.com/m/supremeretrogaming/posts

the installation of McAirpos did not break anything it just did not work to add makecode to the menu to launch the makecode games even though far as i can tell the install did all the things it was supposed to.

That's very good hear, since on my side, on RetroPie v4.8 fresh image, my installer suddenly broke the whole theme...
Could you try a cat /etc/emulationstation/es_systems.cfg to check if MakeCode is added as a system at the end of this file?

should i update it or should i just reflash it to Batocera? its starting to sound like Batocera is just a better all-around build? these are for my 2 kids is that build more kid-friendly? one of my kids is learning to code with makecode arcade so i got this to run her games on it. much better solution it seems that than meowbit.

I would be hard pressed to recommend any of them above the other. They are all great in their own way.
But the main reason I stick with RetroPie on most of my RPis (apart from laziness and not wanting to break things by updating too much) is that I have an "on-top" installation with a full Raspberry Pi OS with the PiXeL desktop environment beneath and besides the RetroPie installation. This because they are mainly used as various servers, game streaming clients, nomachine/rdesktop workstations, and not mainly as a retro gaming/arcade machine. Also my son and I learning to program Python, C++ and C. So RetroPie is the most flexible in this way, having a full Debian/Raspberry Pi OS installation included.
As for Recalbox and Batocera, they are much more restricted(to serve a more smooth user experience and harder to break), based on a minimal buildroot/busybox custom distro with locked down file system.
They really both excel as gaming machines/arcades, but not as free(to e.g. break things). Just started playing around with Batocera, and they might seem to embrace homebrew/independent game development more out of the box; Pixel8, pygame etc., but I could not say for sure.
They are all very open to new game systems and with mostly friendly and helpful communities and staff.

this is the image/ build i installed.
https://www.patreon.com/m/supremeretrogaming/posts

Never heard of. Why use these supreme retro gaming images and not the official images?

Hmmm, the new carbon-2021 theme seems to have entered into production on v4.7.19 in october 2021...:
https://github.com/RetroPie/RetroPie-Setup/commit/3ce642043a347620b534cfd87888bda9b01620e9

the installation of McAirpos did not break anything it just did not work to add makecode to the menu to launch the makecode games even though far as i can tell the install did all the things it was supposed to.

That's very good hear, since on my side, on RetroPie v4.8 fresh image, my installer suddenly broke the whole theme...
Could you try a cat /etc/emulationstation/es_systems.cfg to check if MakeCode is added as a system at the end of this file?

should i update it or should i just reflash it to Batocera? its starting to sound like Batocera is just a better all-around build? these are for my 2 kids is that build more kid-friendly? one of my kids is learning to code with makecode arcade so i got this to run her games on it. much better solution it seems that than meowbit.

I would be hard pressed to recommend any of them above the other. They are all great in their own way.
But the main reason I stick with RetroPie on most of my RPis (apart from laziness and not wanting to break things by updating too much) is that I have an "on-top" installation with a full Raspberry Pi OS with the PiXeL desktop environment beneath and besides the RetroPie installation. This because they are mainly used as various servers, game streaming clients, nomachine/rdesktop workstations, and not mainly as a retro gaming/arcade machine. Also my son and I learning to program Python, C++ and C. So RetroPie is the most flexible in this way, having a full Debian/Raspberry Pi OS installation included.
As for Recalbox and Batocera, they are much more restricted(to serve a more smooth user experience and harder to break), based on a minimal buildroot/busybox custom distro with locked down file system.
They really both excel as gaming machines/arcades, but not as free(to e.g. break things). Just started playing around with Batocera, and they might seem to embrace homebrew/independent game development more out of the box; Pixel8, pygame etc., but I could not say for sure.
They are all very open to new game systems and with mostly friendly and helpful communities and staff.

this is the image/ build i installed.
https://www.patreon.com/m/supremeretrogaming/posts

Never heard of. Why use these supreme retro gaming images and not the official images?

Hmm these are arcade machines that they will also play their make code games in as well as retro games. I also heard that biticera runs faster. I did not even know there were other non reteopie choices before I installed this image haha. I learned after that new options have came out since I made my first reteopie handheld like 6 years ago haha.
I used that image cause it was one of the recommended ones on the gpi case site. It had a build specifically for this case and model of pi. It's got the needed software for the device pre installed. Where if I go with botacera id have to installed some stuff on it and I imagined it would maybe be less stable and need more tweaking to get working.
Yea tomorrow morning ill get the output of that for you.

Hmm these are arcade machines that they will also play their make code games in as well as retro games. I also heard that biticera runs faster. I did not even know there were other non reteopie choices before I installed this image haha. I learned after that new options have came out since I made my first reteopie handheld like 6 years ago haha.

That same use case is actually the same that triggered this whole project for me; I was looking for a learning project for coding, and wanted that my son could show and play his MakeCode Arcade game creations on the big screen and in RetroPie together with the rest of his games. Strange that Microsoft ignores this huge market for MakeCode by not sorting out the current compilation issues for Raspberry Pi/arm native executables(and maybe native executables for x86_x64 as well), and standardize the gamepad interface, instead of just focusing on the hand-held microcontroller devices and the web simulator. That would remove the need for my kludgy hack, and mutually boost both the MakeCode and RetroPie arcade communities, and lower the entrance threshold into other coding languages and projects.
Wouldn't know for certain about the speed, but since Recalbox and Batocera are both stripped down solutions running only strictly necessary services and tweaking for a smooth experience, I can imagine that they maybe run a bit more nimbly. Personally, I switch to game streaming with Moonlight, Parsec or Steam link etc. from our gaming rig/server to the Raspberrys whenever we want to play anything newer than PS1 (N64 and above), instead of using time to tweak the last CPU/GPU cycles out of these relatively small and weak computer boards. But we are different; some people like to get the last couple of mph out of their mopeds, while others just switch to a motorcycle or car instead. But there are still many reasons for or use cases where the moped is more practical or accessible than a car or motorbike, or the only option.
Yeah, there are a lot of options; the most famous being RetroPie, Recalbox, Batocera and Lakka, all good in their own ways.

I used that image cause it was one of the recommended ones on the gpi case site. It had a build specifically for this case and model of pi. It's got the needed software for the device pre installed. Where if I go with botacera id have to installed some stuff on it and I imagined it would maybe be less stable and need more tweaking to get working.

Ok, I see that Retroflag themselves recommend the supreme retro gaming images for their GPi cases, so they are probably good: https://support.retroflag.com//#:~:text=System made for
But I believe most support the GPi out of the box, too:
https://www.recalbox.com/download/stable/rpi/rpizero2gpicase/
https://wiki.recalbox.com/en/basic-usage/preparation-and-installation/retroflag-gpi-case
https://batocera.org/download
RetroPie looks like more fiddling, so why tinker and risk running into hours of trouble when you can just flash instead?

Yea tomorrow morning ill get the output of that for you. I had looked my self beforehand since I saw it mentioned in the manual install and I saw it there but il show the exact output of it for you to see.

Now back to your problem, sorry for the delay, but it took me some time to figure out why and how to fix mye failing install script for RetroPie v>4.7.19...
The good news are that since your theme is not broken, you could probably just try to run the updated install script:
wget --no-check-certificate https://raw.githubusercontent.com/Vegz78/McAirpos/master/install.sh&&chmod +x ./install.sh&&./install.sh
To manually figure this out, I can for now think of 3 things that might be wrong and should be checked before going deeper into the matter:

The /etc/emulationstation/es_systems.cfg is responsible for loading the system into the main menu, and must look exactly like this at the end of the file:

  <system>
    <name>MakeCode</name>
    <fullname>MakeCode Arcade</fullname>
    <path>/home/pi/RetroPie/roms/makecode</path>
    <extension>.elf .ELF</extension>
    <command>/home/pi/McAirpos/McAirpos/launCharc/launCharc %ROM%</command>
    <platform>makecode</platform>
    <theme>makecode</theme>
  </system>
</systemList>

Also check that the  is correct for where you store your MCA games.

Also make sure that you have MCA games, as .elf executable files(not .uf2 files), in the same roms folder as in  above.

Ensure executable permissions for your MCA games; chmod -R 755 /home/pi/RetroPie/roms/makecode/*, or same chmod for whatever roms folder you have for MCA games.

Good luck, hope that this works for you soon and that you return with a feedback of the results.

Now back to your problem, sorry for the delay, but it took me some time to figure out why and how to fix mye failing install script for RetroPie v>4.7.19...
The good news are that since your theme is not broken, you could probably just try to run the updated install script: wget --no-check-certificate https://raw.githubusercontent.com/Vegz78/McAirpos/master/install.sh&&chmod +x ./install.sh&&./install.sh
Good luck, hope that this works for you soon and that you return with a feedback of the results.

I tried the new script first. here was the output.
pi@retropie:~ $ wget --no-check-certificate https://raw.githubusercontent.com/Vegz78/McAirpos/master/install.sh&&chmod +x ./install.sh&&./install.sh
--2022-06-16 18:21:34--  https://raw.githubusercontent.com/Vegz78/McAirpos/master/install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3095 (3.0K) [text/plain]
Saving to: ‘install.sh.1’
install.sh.1        100%[===================>]   3.02K  --.-KB/s    in 0.002s
2022-06-16 18:21:35 (1.20 MB/s) - ‘install.sh.1’ saved [3095/3095]
Working direcory ok!: /home/pi
McAirpos repository present, continuing...
MakeCode Arcade games folder already present, continuing...
make: Nothing to be done for 'default'.
ln: failed to create symbolic link '/usr/bin/launCharc': File exists
McAirpos finished installing!
Please add a .elf game to the MakeCode roms folder and reboot RetroPie for the changes to take effect.
Download MakeCode Arcade .elf game files from https://vegz78.github.io/McAirpos
Run MakeCode Arcade games from the RetroPie menu or from the Linux console/CLI:
./install.sh: line 69: /usr/bin/launCharc: Permission denied
For more details, please visit https://github.com/Vegz78/McAirpos
I checked the game i have in the folder was still there and has 755 perms for the game and the makecode folder also. and so i restarted and see no makecode menu option. i even changed the theme to carbon just in case and still no make code menu.

the installation of McAirpos did not break anything it just did not work to add makecode to the menu to launch the makecode games even though far as i can tell the install did all the things it was supposed to.

That's very good hear, since on my side, on RetroPie v4.8 fresh image, my installer suddenly broke the whole theme...
Could you try a cat /etc/emulationstation/es_systems.cfg to check if MakeCode is added as a system at the end of this file?

here it is.

wine
Wine
/home/pi/RetroPie/roms/wine
.sh .conf .exe .SH .CONF .EXE
/opt/retropie/supplementary/runcommand/runcommand.sh 0 _SYS_ wine %ROM%
    wine
wine

MakeCode
MakeCode Arcade
/home/pi/RetroPie/roms/makecode
.elf .ELF
/home/pi/McAirpos/McAirpos/launCharc/launCharc %ROM%
    makecode
makecode

some other stuff that may help.
`
pi@retropie:~ $ ls
Config     install.sh    NVRAM     RetroPie-BGM-Player  Templates
Desktop    install.sh.1  Pictures  RetroPie-Extra       Videos
Documents  McAirpos      Public    RetroPie-Setup       wine
Downloads  Music         RetroPie  scripts
pi@retropie:~/McAirpos $ ls
ansible              install_recalbox_v7.sh                 LICENSE
docs                 install_recalbox_v8_HDMI-Audio-Fix.sh  McAirpos
HDMI-Audio-Fix.sh    install_recalbox_v8.sh                 README.md
install_batocera.sh  install.sh
pi@retropie:~/RetroPie/roms $ ls
3do          'dreamcast off'    msx          saturn
amiga         famicom           msx2        'scummvm off'
amigacd32     fba               mugens       sega32x
amstradcpc    fds               music        segacd
'apple2 off'   gameandwatch      n64          sfc
arcade        gamegear          naomi        sg-1000
arcadia       gb                nds          snes
astrocade     gba               neogeo       snesh
atari2600     gbah              nes          steam
atari5200     gbc               nesh         supergrafx
atari7800     gbh               ngp          tg16
atari800      genesis           ngpc         tg-cd
atarijaguar   genh              openbor      ti99
atarilynx     ggh               oric         tic80
atarist       intellivision     pc98         unifiedsnaps
atomiswave   'kodi off'         pce-cd       vectrex
bbcmicro     'macintosh off'    pcengine     videopac
BIOS          makecode          pcfx         virtualboy
c64           mame-advmame     'pc off'      wine
channelf      mame-libretro     pico8        wonderswan
coco          mame-mame4all    'pixel off'   wonderswancolor
coleco        markiii           pokemini     x1
commercial    mastersystem      ports        x68000
crvision      megadrive         psp          zmachine
daphne        megadrive-japan   psx          zx81
dragon32      model3            residualvm   zxspectrum
pi@retropie:~/RetroPie/roms $
pi@retropie:~/RetroPie/roms/makecode $ ls
arcade-Chase-the-Pizza.elf
pi@retropie:~/RetroPie/roms/makecode $ chmod -R 755 /home/pi/RetroPie/roms/makecode/*
`

is this part of the issue?

i also tried just deleting the application and then re-install it with the script i got this output.
`pi@retropie:~ $ wget --no-check-certificate https://raw.githubusercontent.com/Ve                                                                                gz78/McAirpos/master/install.sh&&chmod +x ./install.sh&&./install.sh
--2022-06-16 18:52:34--  https://raw.githubusercontent.com/Vegz78/McAirpos/maste                                                                                r/install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... <IP_ADDRESS>                                                                                33, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.                                                                                133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3095 (3.0K) [text/plain]
Saving to: ‘install.sh.2’
install.sh.2        100%[===================>]   3.02K  --.-KB/s    in 0.004s
2022-06-16 18:52:34 (854 KB/s) - ‘install.sh.2’ saved [3095/3095]
Working direcory ok!: /home/pi
Git already installed...
Cloning into 'McAirpos'...
remote: Enumerating objects: 937, done.
remote: Counting objects: 100% (219/219), done.
remote: Compressing objects: 100% (127/127), done.
remote: Total 937 (delta 169), reused 106 (delta 90), pack-reused 718
Receiving objects: 100% (937/937), 23.06 MiB | 5.92 MiB/s, done.
Resolving deltas: 100% (486/486), done.
MakeCode Arcade games folder already present, continuing...
make: Nothing to be done for 'default'.
McAirpos finished installing!
Please add a .elf game to the MakeCode roms folder and reboot RetroPie for the c                                                                                hanges to take effect.
Download MakeCode Arcade .elf game files from https://vegz78.github.io/McAirpos
Run MakeCode Arcade games from the RetroPie menu or from the Linux console/CLI:
usage: launCharc [nomap / keybswap / verbose] [/path/to/arcadegame.elf]
For more details, please visit https://github.com/Vegz78/McAirpos
`

If you notice this line
“install.sh.2” from your last run of wget and “install.sh.1” from the previous, it seems not to overwrite the original install.sh in the same folder.
Please delete all install.sh, before you try again, or try from another folder.
however, it does not explain why the system does not show up in the RetroPie menu. I cannot think of any other reasons right now other than the above 3 points…
Basically a  entry in es_systems.cfg and a game in the corresponding folder should be everything needed for, at least, a themeless folder name to appear in RetroPie.
Very strange!

And:
sudo rm -rf /home/pi/McAirpos before….

Think also you could delete/move to other location /etc/emulationstation/themes/carbon, which I don’t think is needed on v. >= 4.7.19…

i tried that. still not showing in menue. here was the output.

Think also you could delete/move to other location /etc/emulationstation/themes/carbon, which I don’t think is needed on v. >= 4.7.19…

i dont understand what you are referring to here.

so before i went and tried updating i got into the collections menu and i went to make a custom collection based on theme. makecode was in there and i selected it. it then opened a screen to select what games to put in it and there were none. however, i do have a .elf game in the makecode directory and it is set to 755 perms.

Well done so far!

ok i tried running it from ssh
pi@retropie:/usr/bin$ launCharc /home/pi/RetroPie/roms/makecode/arcade-Chase-the-Pizza.elf

Means that the launcher and game works, at least, though not yet showing correctly or launching as it should from EmulationStation...

i see the install with A number. but there are no install files there with a number.

That might be because you are looking inside the /home/pi/McAirpos folder, which is downloaded by the installation script, while the numbered _install.sh_s from wget you will probably find in the folder you run wget from. So you have probable been running an old version of install.sh, maybe in the folder /home/pi. But it does not matter anymore, since you have solved the theme/menu entry issue manually now.

I FIGURED IT OUT!!! haha so when i was updating it i noticed it said this
Very good and interesting! I have never heard of crvision, and is this something especially for the GPi mod of RetroPie? It will probably be too complex for me to support out-of-the box, but great to have in the issue/knowledge base for others with GPi cases(rather popular, I have noticed).

now there are 2 new issues. 1 the theme background music continues to play when the game opens and 2 the screen is not fit well.

MakeCode Arcade games operate on the lowest level in all aspects, and are totally unaware and inconsiderate of everything surrounding them, espeially EmulationStation;

for graphics it tries to hijack the framebuffer on the active tty, fails if framebuffer/VT switch is busy, succeeds otherwise
for audio it demands direct access to Alsa driver on the first card/deveice number _hw:0,0. No access, and the game fails. Acsess means the game succeeds and sound plays regardless of other streams.
The controller interface is RAW Linux Input Substystem events(/dev/input/eventX), and though the game does not crash if it does not get hold of an event device, you get no controller input, and if it captures an input event device, it will hijack this, meaning that if other apps(like EmulationStation) runs in the background, they will also recieve these controller button presses, if they operate on the same eventX(Which they will do, since every controller has exectly one eventX each).

Normally and historically, EmulationStation quits or gracefully enters the background every time a launch command from the  entry fields in es_systems.cfg is executed(You press button on game in menu, EmulationStation issues the system(sh -c "") inside its C++ code. The game then is free to launc, and when its process dies, EmulationStation is relaunched.
Luckily, this seems also to be the case for your system, since you get both game graphics and sound, albeit wrong aspect ratio and mixed audio streams.
Graphics/Aspect ratio
You can see in the /tmp/McAirpos.log, which graphics "mode"(screen resolution, color depth and refresh rate) that the MakeCode game has found and chosen, which will give you some information. On most systems, you will have resolution 1920x1080, or at least the same aspect ratio, and MCA games will find a way to display its 160x120 game screen correctly.
Therefore, I suspect you have to play around with screen settings for the frame buffer before launch. I cannot remember if others who have played around with this on GPi have encountered this problem, like @rdmueller here on GitHub, or @Neslou on the MakeCode Forum, though they both did it with Recalbox on the GPi;
https://forum.makecode.com/t/makecode-arcade-on-recalbox/5914/6?
https://forum.makecode.com/t/makecode-arcade-on-recalbox/5914/20 (RetroPie, but other handheld with other screen aspect ratio)
This is hard for me to support you on, since I do not have a GPi with its special quirks myself to test on, sorry.
Audio
I have encountered 3 ways audio is handled on different (EmulationStation) systems, in order of appearance;
-Alsa audio, normally freed when EmulationStation quits/enters background on launch
-PulseAudio, often hijacks Alsa so MCA games crashes. launCharc therefore kills all pulseaudio instances on launch, so that Alsa is freed. PulsAudio is then relaunched with EmulationStation, or by itself, when it gets access to hw:0,0 again.
-pipewire puts itself inbetween the system and the Alsa driver in a rather nice way, and this is the only time(on Batocera so far, but this is coming on other systems soon) where I have experienced mixed audio streams. On Batocera  solved itself when I had to switch tty to get the graphics displayed on screen, but if pipewire is present on and can be solved the same way on your RetroPie on the GPi, I unfortunately don't know.
On the latest RetroPie on my RPi4 I did not experience mixed sound, though I did not have any background music on in the EmulationStation menu, and I have seen now that EmulationStation is implemented in different ways between different images, which complicates matters. For instance, McAirpos runs well on Batocera for RPi4, but EmulationStation for RPi3 is a whole other beast I am still fighting with.
So there is much work coming in the future for McAirpos to support updated versions on RPi4 and RPi3, which is my main focus(since RPi0s basically are stripped down RPi3s), and I am afraid there will be many installers in the future, both to support different versions of the different Retro systems, and for different hardware implementations. I will certainly not be able to support every combination, and need the community to help eachother and maybe pull request successfull installation scripts which I can categorize somehow. I am only able to test at home on vanilla RPi4 and RPi3 attached to a 1920x1080 screen via HDMI, and I can test audio via HDMI and jack.

I am also contemplating introducing versioned releases for McAirpos, to keep in pace with the rapid development of the different systems, and to keep the number of checks and ifs down in launCharc. Meaning that backwards compatibility for older retro systems will be found exclusively in older releases, and support for newer retro systems in newer releases, where I also will prioritize my support efforts, unless I get som help from the community. I never imagined this number of combinations when I started out, hehe.

Well done so far!

ok i tried running it from ssh
pi@retropie:/usr/bin$ launCharc /home/pi/RetroPie/roms/makecode/arcade-Chase-the-Pizza.elf

Means that the launcher and game works, at least, though not yet showing correctly or launching as it should from EmulationStation...

i see the install with A number. but there are no install files there with a number.

That might be because you are looking inside the /home/pi/McAirpos folder, which is downloaded by the installation script, while the numbered _install.sh_s from wget you will probably find in the folder you run wget from. So you have probable been running an old version of install.sh, maybe in the folder /home/pi. But it does not matter anymore, since you have solved the theme/menu entry issue manually now.

I FIGURED IT OUT!!! haha so when i was updating it i noticed it said this
Very good and interesting! I have never heard of crvision, and is this something especially for the GPi mod of RetroPie? It will probably be too complex for me to support out-of-the box, but great to have in the issue/knowledge base for others with GPi cases(rather popular, I have noticed).

now there are 2 new issues. 1 the theme background music continues to play when the game opens and 2 the screen is not fit well.

MakeCode Arcade games operate on the lowest hardware level in all aspects, and are totally unaware and inconsiderate of everything surrounding them, espeially EmulationStation;

for graphics it tries to hijack the framebuffer on the active tty, fails if framebuffer/VT switch is busy, succeeds otherwise
for audio it demands direct access to Alsa driver on the first card/deveice number _hw:0,0. No access, and the game fails. Acsess means the game succeeds and sound plays regardless of other streams.
The controller interface is RAW Linux Input Substystem events(/dev/input/eventX), and though the game does not crash if it does not get hold of an event device, you get no controller input, and if it captures an input event device, it will hijack this, meaning that if other apps(like EmulationStation) runs in the background, they will also recieve these controller button presses, if they operate on the same eventX(Which they will do, since every controller has exectly one eventX each).

Normally and historically, EmulationStation quits or gracefully enters the background every time a launch command from the entry fields in es_systems.cfg is executed(You press button on game in menu, EmulationStation issues the system(sh -c "") inside its C++ code. The game then is free to launc, and when its process dies, EmulationStation is relaunched.
Luckily, this seems also to be the case for your system, since you get both game graphics and sound, albeit wrong aspect ratio and mixed audio streams.
Graphics/Aspect ratio
You can see in the /tmp/McAirpos.log, which graphics "mode"(screen resolution, color depth and refresh rate) that the MakeCode game has found and chosen, which will give you some information. On most systems, you will have resolution 1920x1080, or at least the same aspect ratio, and MCA games will find a way to display its 160x120 game screen correctly.
Therefore, I suspect you have to play around with screen settings for the frame buffer before launch. I cannot remember if others who have played around with this on GPi have encountered this problem, like @rdmueller here on GitHub, or @Neslou on the MakeCode Forum, though they both did it with Recalbox on the GPi; https://forum.makecode.com/t/makecode-arcade-on-recalbox/5914/6? https://forum.makecode.com/t/makecode-arcade-on-recalbox/5914/20 (RetroPie, but other handheld with other screen aspect ratio)
This is hard for me to support you on, since I do not have a GPi with its special quirks myself to test on, sorry.
Audio
I have encountered 3 ways audio is handled on different (EmulationStation) systems, in order of appearance; -Alsa audio, normally freed when EmulationStation quits/enters background on launch, if not, the game usually crashes instead of mixed streams. -PulseAudio, often hijacks Alsa so MCA games crashes. launCharc therefore kills all pulseaudio instances on launch, so that Alsa is freed. PulsAudio is then relaunched with EmulationStation, or by itself, when it gets access to hw:0,0 again. -pipewire puts itself inbetween the system and the Alsa driver in a rather nice way, and this is the only time(on Batocera so far, but this is coming on other systems soon) where I have experienced mixed audio streams. On Batocera solved itself when I had to switch tty to get the graphics displayed on screen, but if pipewire is present on and can be solved the same way on your RetroPie on the GPi, I unfortunately don't know.
On the latest RetroPie on my RPi4 I did not experience mixed sound, though I did not have any background music on in the EmulationStation menu, and I have seen now that EmulationStation is implemented in different ways between different images, which complicates matters. For instance, McAirpos runs well on Batocera for RPi4, but EmulationStation for RPi3 is a whole other beast I am still fighting with.
So there is much work coming in the future for McAirpos to support updated retro system versions on RPi4 and RPi3, which is my main focus(since RPi0s basically are stripped down RPi3s), and I am afraid there will be many installers in the future, both to support different versions of the different Retro systems, and for different hardware implementations. I will certainly not be able to support every combination, and need the community to help eachother and maybe pull request successfull installation scripts which I can categorize somehow. I am only able to test at home on vanilla RPi4 and RPi3 attached to a 1920x1080 screen via HDMI, and I can test audio via HDMI and jack.

Hmm I read that who thread you linked me to on the firm and I never saw any mention of them changing anything with the display or having issues with resolution etc to begin with.
So changing the screen settings before launch where would I do that?
The background audio issue I can see an easy solution for. I will just disable it haha. the image came with it already enabled.

Oh so that screen shot I showed you that mentioned crvision. The crvision part was not what was important. What was important was the fact it said that the configuration of it would need to be copied in op/retropie/configs/all/emulationstation/es_systems.cfg so I wondered if that would be the case for makecide alsi. So I went to that file and it's just like the other cfg one we were change except that it did not have the entry for makecode in it. So I added it there also and then it showed up in the menu.

Hmm I read that whole thread you linked me to on the forum and I never saw any mention or them changing anything with the display settings or then saying they had issues with resolution etc to begin with. Is it the correct post?

It is the right post, and @rdmueller and @Neslou are the only ones I know who have tried this on a GPi, albeit on vanilla Recalbox images, not RetroPie. My point was, that I don't know if they have encountered screen issues, but maybe they could help you.

So changing the screen settings before launch where would I do that?

I don't know for certain, I am only deducing what may be the problem. I am unfortunately unable to test on a GPi myself. Have you tried checking the /tmp/McAirpos log entry or with different screen resolutions to see if there's a difference?

The background audio issue I can see an easy solution for. I will just disable it haha. the image came with it already enabled.

That is the solution I would recommend as well... ;-)

Did you get an output from:

/tmp/McAirpos.log after running a game with the broken display, and
the command fbset? (without any options fbset will display the mode settings of your framebuffer)?

Any progress, @deepdivered? Would be nice if you got it to play well, eventually!

It is the right post, and @rdmueller and @Neslou are the only ones I know who have tried this on a GPi, albeit on vanilla Recalbox images, not RetroPie. My point was, that I don't know if they have encountered screen issues, but maybe they could help you.

yes, I used Recalbox and I can't remember that I had screen issues.

Any progress, @deepdivered? Would be nice if you got it to play well, eventually!

ill have to try that out in a bit. they are able to use it as is now its just not optimal. also I have no idea how to play with screen resolution as you are suggesting. any tips?

First I would try posting here /tmp/McAirpos.log right after you have run and exited a working game, but with the wrong aspect ratio that you are experiencing.
Then, if you can connect a keyboard directly, I would exit RetroPie and go into the local Linux console. Is the GPi screen filled out fully here, while in text mode?
If yes, I would try to launch a game manually from the local Linux console, with launCharc /home/pi/RetroPie/roms/makecode/some-game-file.elf. Any difference? And please also post a _/tmp/McAirpos.log" file here after this operation, to see if there's a difference.
Then I would start playing with the fbset command; check and your current settings here by just typing in fbset without any options. Take note of this setting(    ) to be able to revert.
Then check out the predefined/allowed modes in the file /etc/fb.modes, by issuing cat /etc/fb.modes.
Then see if changing to any of the other modes, like e.g. fbset -g 1920 1080 1920 1080 32 (not a relevant mode for your screen size, but use relevant combinations of      for your device).
Launch game again and see if it changes/works better.
If you find a setting that works from the console, you can include the setting before launch and revert back to original in your es_systems.cfg file by separating multiple commands in the <command> field;
<command>fbset -g blah blah blah ... ; launCharc /home/pi/Retro.....elf ; fbset -g blah blah blah ...</command>
Alternatively, if not affecting other games/emulators, it might be set somehow at boot time, or by other means.
I am not entirely sure, but we will figure it out together!

There is also a framebuffer terminal program, fbterm, that you can install and test how your framebuffer is set up from the Linux console(local command line, not ssh), exit via exit command or CTRL+C.

Closing this issue, as the initial problem is solved. Please open a new issue about the screen problems, if there is anything I can do to help.

I will give that a try tomorrow and report what it says. I don't know how
or where to mess with resolution settings.
On Sat, Jun 18, 2022, 12:30 AM Vegz78 @.***> wrote:

Did you get an output from:

/tmp/McAirpos.log after running a game with the broken display, and
the command fbset? (without any options fbset will display the mode
settings of your framebuffer)?

—
Reply to this email directly, view it on GitHub
https://github.com/Vegz78/McAirpos/issues/41#issuecomment-1159385110,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHWS4P5XG3JKAGKYLIKH73VPV3ILANCNFSM5YXBOTTQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

I opened the remaining screen resolution challenges as a new issue here, @deepdivered:
https://github.com/Vegz78/McAirpos/issues/42

I will give that a try tomorrow and report what it says. I don't know how or where to mess with resolution settings.


11/02/2018 05:59 : Create Pull Request for branch master -> prTesting1_2018110205

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

split/updateTestRef1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


3.0 iOS Framework

I’ve refactored the project to support frameworks (the project is now simply an iOS framework), along with Carthage.
A few notes:

CocoaPods support is tanked, but should be pretty easy to regain.
Deployment target is now 8.0, the lowest supported by iOS dynamic frameworks.
The project is now flattened. All of the gitmodules have been integrated directly into this project.
It shouldn’t be too hard to return back to the gitmodules state of affairs, however it didn’t seem to be worth the trouble because as far as I could tell the only project to use those git modules is this project.

I’ve also converted ABFRealmMapView (will send a separate PR) and have tested that both work using Carthage.

Also, the readme docs might need some updating.
If you do end up accepting the PR, make sure that in the Carthage installation instructions, you change the github project from my fork to your root project.

Woops, that's embarrassing.
I had incorrectly thought that this project and ABFRealmMapView were by the same guy.
Everything I said above still applies, however the fact that this project is flattened might prove more problematic than I had realized...
Nevertheless, I still think it's a good idea to move on to an iOS framework + introduce Carthage support.
It may be easiest to do the same to the git submodules (turn them into iOS frameworks), and then simply add them as dependencies in Carthage + CocoaPods.
Let me know if I can help somehow, I hope that at the very least this skeleton would prove useful in converting the project to an iOS framework (even if in a different way).

Thanks for this! I am behind this and ABFRealmMapView. We will need to make sure Cocoapods works though to introduce these changes.

Oh, good to know that's the case after all!
I'll see if I can re-introduce the git submodules while keeping the project an iOS framework
(might not be able to do that today though..).
I've never done it before, but I presume CocoaPods support should be pretty easy to re-introduce.
May be good to hold on until the submodules are addressed.
(Supposing it is important for you to keep them separate from this project?)

Ok, I put all the modules back. No changes were needed to the modules themselves.
Everything should be fully backwards compatible, but I only tested it with the RealmMapView project.
CocoaPods support is still unimplemented, but shouldn't be any different from usual to implement.
(I'm not sure since I've never done this, but I believe only the owner of the CocoaPod [you] can do this?)

Why can't the Cocoapods stuff just be added back? What has changed that makes that not functioning?

Perhaps nothing?
I've never created a pod before. I was just assuming that when switching the architecture to a framework, there'd need to be some changes to the podspec reflecting that.
But again, I'd never done this before, so if you think otherwise maybe it's worth it to just give it a go?

The pod spec just includes the files and Cocoapods creates the library/framework when you compile so I think it should be fine. Can you just put the pod spec stuff back?
—
Sent from Mailbox
On Fri, Jan 15, 2016 at 11:06 AM, Atai Barkai<EMAIL_ADDRESS>wrote:

Perhaps nothing?
I've never created a pod before. I was just assuming that when switching the architecture to a framework, there'd need to be some changes to the podspec reflecting that.
But again, I'd never done this before, so if you think otherwise maybe it's worth it to just give it a go?
Reply to this email directly or view it on GitHub:
https://github.com/Roobiq/RBQFetchedResultsController/pull/57#issuecomment-172055526

@ataibarkai I am going to work on merging this over the weekend. Sorry it has taken so long, just been swamped with work. Really appreciate your work!

Great. I completely understand, work has been spiking over here too.
On Fri, Jan 22, 2016 at 11:55 AM, Adam Fish<EMAIL_ADDRESS>wrote:

@ataibarkai https://github.com/ataibarkai I am going to work on merging
this over the weekend. Sorry it has taken so long, just been swamped with
work. Really appreciate your work!
—
Reply to this email directly or view it on GitHub
https://github.com/Roobiq/RBQFetchedResultsController/pull/57#issuecomment-174027051
.

This PR supersedes this one: https://github.com/Roobiq/RBQFetchedResultsController/pull/61


SPIKE: deployment

Set up meeting with Jay regarding deployment.
Talk about RIT auth
Mention what we need to install and if they have any questions about what we're doing
What can we do ourselves and how we would do it

Also includes:

verifying webpack build builds correctly
prepping the app to use correct URLs and not localhost

Also includes verifying what things we need to do to deploy the backend:

https://expressjs.com/en/advanced/pm.html
https://expressjs.com/en/advanced/best-practice-security.html
https://expressjs.com/en/advanced/best-practice-performance.html
https://expressjs.com/en/advanced/healthcheck-graceful-shutdown.html
GraphQL specific deployment practices

Do we need to run our Node API in a cluster: https://nodejs.org/api/cluster.html?


fix problems that arise when not root

according to [https://docs.newrelic.com/docs/servers/new-relic-servers-linux/installation-configuration/servers-installation-other-linux#user], the newrelic user should be created with shell /sbin/nologin.  the init script cannot run without a shell, so by providing -s /bin/bash, it can.
additionally, the newrelic user cannot install system gems, so the gems should be vendored.

Yes! The -s /bin/bash option is exactly what got me un-stuck too.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


authz: added SubjectClaim to JWT settings

Coverage decreased (-0.05%) to 87.02% when pulling a6e2c3b285f3646c23bd238f4296168301c05173 on dissoupov into f290d97b484bb2e98a5c4084393131c701a3ff37 on main.


-bnot operator returns signed datatype when unsigned datatype is supplied.

Steps to reproduce
$operand = [byte]0xFF
$result = -bnot $operand
$result

Expected behavior
I would expect the return value to be 0x00

Actual behavior
-256

Which when casts into a [byte] results in an error, because it is signed.
I would like to request an unsigned version of the bitwise operator, if this is in fact the expected behavior. I spoke with Tyler Leonhardt about this at Microsoft Ignite conference.
Environment data

Name                           Value
----                           -----
PSVersion                      6.2.3
PSEdition                      Core
GitCommitId                    6.2.3
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

:thinking: yep, this should definitely preserve the input data type (as long as it is one of the integer data types; not sure what it would do if the data type is double, float, or decimal, though.
Also not sure if we should have provision for [bigint] here? A -bnot on bigint would be rather inherently unpredictable due to its arbitrary size.

It's worth noting that C# behaves the same way (SharpLab example).
This behavior is defined by the EMCA spec, the not CIL opcode is defined to work with only operands valid in "Integer Operations" which only accepts int, long and IntPtr (EMCA III.1.5 Table III.5).
Note: I'm not arguing for or against any proposed changes, just providing context.

That seems kinda strange to me, especially since I would think one of the primary use cases for a binary NOT operator would be the lower integer types like byte and short.

I can't find a source for this specific instance but typically the reason you see instructions defined for 32 bit integers but not smaller is due to processors being much better optimized to handle them.  So behind the scenes C# would probably have to promote the byte to 32bits anyway, this way it's obvious that that's being done.
The bigger problem is that there's no real way to do an unchecked explicit conversion between int and byte in PowerShell the same way you can in C#.  PowerShell uses the IConvertible interface methods, C# uses the conv.u1 CIL instruction.  The latter more or less reinterprets the same bits as said type, instead of trying to convert/validate it.  So (byte)(~(byte)0xff) returns 0 where [byte](-bnot ([byte]0xff)) throws because the value -256 isn't valid for a byte.

So a possible fix would be to check the input type and do an explicit cast in the -bnot operator itself back to the input type, I suppose? 🤔

If it's determined to be something that has to change, yeah.  It'd be a bit of a pain to do that arbitrarily for all possible input types, but not impossible.  It would be a breaking change though, and would not exactly be expected behavior for C# folks (who would be the folks most likely to use one's complement).
Personally I'd rather see an easy way to do an unchecked explicit conversion.

$value -to [byte] perhaps? A more "forceful" version of -as? 😁

To clarify my use case, I am only working with [byte] and [uint16].  The behavior to me is strange because this method which uses -bnot works as expected:
[void]clearBit([byte]$position)  { $this.value = $this.value -band -bnot (0x01 -shl $position) }

as this is my current workaround for -bnot (these are class method snippets)
[void]not(){
        for ([byte]$i=0;$i -lt 8; $i++) { $this.toggleBit($i)}
    }
[void]toggleBit([byte]$position) { $this.value = ($this.value -bxor (0x01 -shl $position))    }

Still a problem on :
Name                           Value
----                           -----
PSVersion                      7.3.9
PSEdition                      Core
GitCommitId                    7.3.9
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0