Closure factories compile ok but get tagged with errors by Xcode

So I have the following code where I'm using Factory to return a closure instead of a type:

public func factory() -> Container {
    Container.shared
}

public typealias DateProviding = () -> Date

public extension Container {
    var dateProvider: Factory<DateProviding> { self { { Date() } } }
}

// And later in some code...
factory().dateProvider()()

This compiles successfully however Xcode then goes an tags it with an error even though there isn't one:

It looks likes Xcode is miss-interpreting this code even though it compiles fine. I've tried
(factory().dateProvider)()()
(factory().dateProvider())()
let x = factory().dateProvider()
x()

But they all trigger the error. So far it looks like the only thing that removes it is if I do this:
let x:() -> Date = factory().dateProvider()
x()

Any thoughts on how to get Xcode to behave?

I dropped this into the factory demo and ran it with no issues.
public func factory() -> Container {
    Container.shared
}

public typealias DateProviding = () -> Date

public extension Container {
    var dateProvider: Factory<DateProviding> { self { { Date() } } }
}

func test() {
    // And later in some code...
    let date = factory().dateProvider()()
    print(date)
}

The problem is probably somewhere in the code you didn't post. You're masking factory or Container with some locally defined name.

Hmm. Ok. Let me dig into that bit more :-)

Ok, my bad. Looks like some subtle missing imports and missing dependency references in a package file. The compiler was still able to find everything through transient dependencies and the likes, but XCode was flagging the errors when it was compiling for code completion. Which explains why it would compile and run fine, then a few seconds later Xcode would flag an error. Anyway, adding the imports and missing dependencies and it all appears to be good now.
Thanks for taking the time to double check :-)


First prototype for European market

First draft to enable submitting orders for the European market.
Currently work in progress. Hints are always welcome.

The market concept in LEAN is to reflect that an asset is fungible across multiple exchanges. E.g. NASDAQ and NYSE share listings and people are able to trade freely between them. I can buy AAPL then decide to route it to NYSE or NASDAQ to sell.
Since the assets are different securities in different markets; they have different prices (or even denominating currencies) so they are stored in separate data folders. E.g. Is there an "A" ticker in LSE and MD? Should they be stored in different data folders?
I may be wrong but I don't think a Madrid listed stock can trade on the LSE ETF exchange?  I'm not sure there is a central market the same way there is in the US? We might need different markets for each major exchange.

If keen to work on European support with LEAN please join our discord, it would be great to brainstorm it with you and make a plan for how it could be implemented. There are many pieces of this PR that would be a good start. https://www.quantconnect.com/discord


[Bug] VueDevTool not working in dev mode

Version
2.0.0
Reproduction link
https://www.creative-tim.com/product/vue-argon-dashboard#
Operating System
Ubunutu
Device
Laptop
Browser & Version
Chrome Version 87.0.4280.141 (Official Build) (64-bit)
Steps to reproduce
Download the template
npm install
npm run serve
What is expected?
VueDevTools showing on browser
What is actually happening?
VueDevTools not showing on browser

Solution
Additional comments

Hi, @chourabieure! Thanks for using our products. This is an issue with Vue 3: https://github.com/vuejs/vue-next/issues/750
Regards,
Dragos

Hello, iam dont really understand your answer since iam using Vue 2

Hi @chourabieure! You put version 2.0.0 in your issue template and that version is the Vue 3.
Regards,
Dragos

Hey! Still no support?


add osprintf to OSAL

JSC has developed a known and understood version of printf that has been code reviewed and unit tested.  It can be used on platforms that do not provide a printf (such as ARCIN653) or as a known, trusted implementation of the printf function on other OSs.  Currently, versions (there are small variations in the implementation between OSs) for the posix, VxWorks6, and ARINC653 OSALs are available.
Need to add branch with OSAL/src/os/posix, vxworks6, ARCIN653/osprintf.c and OSAL/src/os/inc/psprintf_priv.h, osprintf.h

Imported from trac issue 34.  Created by sduran on 2015-04-07T15:21:54, last modified: 2016-01-19T13:29:37

Trac comment by jphickey on 2015-04-08 11:50:04:
I have reviewed this printf implementation and I have a few concerns about it:

It seems that this comes from code that was originally released under the LGPL.  If this is the case then it is my understanding that in order to comply with the LGPL we would have to preserve this as being a separate LGPL library blob.  (The LGPL permits linking, but I don't think it permits copying the source file into your own tree).  This is OK for a single mission to do but may not be OK for the CCB to do as we are redistributing this...  Of course I am not a lawyer so confirmation would be needed here from someone who is.
Although va_start and va_end macros are used, the implementation does not seem to use va_arg to extract the arguments, but rather casts it as an "int *" and advances this pointer depending on the type.  This calling convention ABI-specific behavior that va_arg is intended to abstract.

A more general question: While I can certainly see the value of having a known, stable implementation of printf() and friends, why has this call been singled out from all the other calls in the C library?  If we don't trust the C library to supply a valid printf() implementation, why do we trust it for memcpy, memset, string functions, file open/close/read/write, and the whole lot of other stuff?
Have we considered looking at one of the alternate C libraries such as newlib [https://sourceware.org/newlib] or uclibc [http://uclibc.org] as a possible source for an entire C library that can be used?  We could select a version of it, review the source for the key functions that CFE uses, and then preserve that exact version as long as it is needed.
Note: I edited this comment from my original -- at first I had some concerns about ignoring the "l" designation but after some googling to satisfy my own curiosity, C rules for variadic functions will indeed promote all floating point values to doubles.  So this is OK.  I still have some reservations about how mixed integer and floating-point parameters will be packed on the stack, however - with my (limited) experience with variadic functions in C I have noticed some weirdness here.

Trac comment by sduran on 2015-04-07 15:39:42:
Only updating existing posix and vxworks6 OSALs.  The ARINC653 OSAL is not yet a released OSAL.

Trac comment by glimes on 2015-06-11 15:16:46:
Just the licensing issue alone means we need to go carefully here.
I'm not a lawyer but I've been playing in the GPL world for decades,
and doing a copy-paste of LGPL code into your project is very much
not allowed, unless you license your code with a compatible license.
So before we can use this, we have to make sure that the resulting OSAL
is licensed using a compatible license. Don't get me wrong, I would really
like to see OSAL released under a GPL or LGPL license. Someone would
need to step into the ring with the laywers.
Until the licensing issues are resolved, I'm not looking at the source,
sorry, very very old self protection habit.
On varargs ... USAGE OF "va_arg" IS NOT OPTIONAL. If the code is mucking
around with pointer casts to try to fetch arguments, toss it in the garbage.
Moving this ticket to the review stage, and recommending that we do not
fight through licensing issues just to adopt unportable implementations.

Trac comment by jphickey on 2015-11-05 14:52:41:
Extracted this change out of the trac #22 changeset.
commit [changeset:7b1f2c2] available for CCB review - branch trac-34-add-local-osprintf

Trac comment by jphickey on 2015-11-05 14:55:00:
I have reviewed this change and recommend DO NOT ACCEPT due to LGPL licensing issues, unless it is cleared by the legal team.
My expectation is that this would need to be distributed as a separate library from OSAL due to the fact that it is LGPL code and OSAL is not.

Trac comment by glimes on 2015-11-09 20:19:49:

License issue is still unresolved.
Code is still broken.

Probably easier to find a version of vsnprintf that is correct
and has appropriate licensing, than to get permission to redistribute
this LGPL code under the NOSA and then to fix the bad code.
I would recommend REJECT independently for each of the two points.

Trac comment by acudmore on 2015-11-10 11:30:06:
I agree with the others.. Not sure what to do about the license issue.
Is this something we can pitch in on and create a new implementation of?  I guess that has testing and code review implications.
Perhaps we can contact the original authors and see if they will allow us to re-license the code? ( it may be derived from other LGPL code, so it may not be possible )
Edit: I did find this small C library that has a liberal public domain license
https://bitbucket.org/pdclib/pdclib/overview

Trac comment by jphickey on 2015-11-10 12:35:53:
Out of curiosity, does the ARINC653 platform provide //any// of the printf() functions?  Specifically snprintf() is used quite a bit around CFE, and I don't see how they can even call themselves a C library if they do not provide these functions (they are specified by ISO C).
My recommendation to get around licensing issues would be add a new osconfig.h option to leave out the OS_printf() function entirely.  This way, anyone can enable that option and then LINK with any 3rd party library of their choice to provide OS_printf().

Trac comment by sduran on 2015-11-10 12:28:28:
I think it is best to leave this out of a release due to potential licensing issues.  It does not impact code for Orion.
It was really put in place for dealing with the ARINC653 platform and was carried forward as a known tested version of the potentially problematic printf function, however, VxWorks, RTEMS, and Linux include printf, so it is really not really needed for these platforms.

Trac comment by sstrege on 2015-11-23 18:30:26:
Ticket #120 created to address the need for implementing a generic solution to integrate third party libraries into the OSAL

Trac comment by sduran on 2015-11-10 12:42:21:
ARINC653 does not provide snprintf either.  That function is included in the osprintf.c file.  One reason why we went to a solution like this, otherwise we would have been rewriting a lot of cfe and apps to replace xxxprintf functions with something else.


Cannot add two WebSocketServerProtocolHandler at different URIs

I'm trying to setup Netty to implement a web server which serves a few HTTP web pages and two separate WebSocket services all tree differentiated by the URI pattern:

/websocket1 handle request to WebSocket service 1
/websocket2 handle request to WebSocket service 2
/docs handle HTTP request, respond HTML pages

I almost get it working, simple HTTP service and one WebSocket service con coexist, but I'm failing at making the second WebSocket service work nicely together with the first one.
initChannel method in my ChannelInitializer looks like:
    pipeline.addLast(new HttpServerCodec());
    pipeline.addLast(new HttpObjectAggregator(65536));
    pipeline.addLast(new WebSocketServerProtocolHandler("/websocket1"));
    pipeline.addLast(new WebSocketFrameHandler1());
    pipeline.addLast(new WebSocketServerProtocolHandler("/websocket2"));
    pipeline.addLast(new WebSocketFrameHandler2());
    pipeline.addLast(new DocsHandler(docs));

With this setup the docs (HTTP) and the first WebSocket service are working great, but when I try to open a connection the the second WebSocket service the client hangs forever and the connection never gets established.
In my case, I'm using separate URIs for the WebSocket services just to use different message formats, maybe I'm doing something wrong and that should be done in a different way.
Any ideas?
Thank you.

I think this was fixed. Please reopen if you still think there is a problem

you know which PR? so I can take a look.

@ktonga Maybe, seperated websocket service is a better choice.


Add model version to test output

Describe the feature
Right now, we report the model name for any rule violation. This can lead to misleading results if it's a specific version of a model that violates the rule in question, or if multiple versions of a model both violate a rule and we only report the name.  We should

pull in version from the graph in stg_nodes
add it to any model that uses name in the output and explicitly checks model nodes

Who will this benefit?
What kind of use case will this feature be useful for? Please be specific and provide examples, this will help us prioritize properly.
Are you interested in contributing this feature?

@epapineau relevant to our convo!

@dave-connors-3 is this complete?


Ionic/Capacitor Support?

Hi @MomenSherif ! Thank you for this amazing package!
We have a website built with Next.js and an app running on Ionic/Capacitor from the same repo. We implemented Sign in with Google button using this package, and it works like a charm on the website.
Unfortunately, with Ionic builds it's a little bit different - nothing happens after clicking the button. Neither onSuccess nor onError is being triggered. Do you know what might be causing this? Is there any chance we can make it work for Ionic?
React v16.8
Ionic v5.4.1
Capacitor v2.1.0

Hey,
the package is just a wrapper around google native JS SDK, it should be used to work on the browser.
IDK how to make it work with ionic for mobile apps (you will need different implementation)

Hi, @rayjackson13. Did you find any solution to handle this login flow on capacitor app?


Initial API Design

Init go project
Initial API design documentation
Code Generation
Initial API struct

The document to review is docs/design/device-configuration-api.md.
I took the hack/update-codegen.sh code from the Gateway-API project and adapted it to this project.
This is the initial API, it will be extended later. For now we can use it to invoke the CNI ADD and DEL.

@s1061123 @dougbtv can you please take a look?

@LionelJouin looking forward to reviewing this tomorrow!

/cc


404 Not Found<EMAIL_ADDRESS>

Category

[ ] Question
[ ] Typo
[X] Bug
[ ] Additional article idea

npm ERR! code E404
npm ERR! 404 Not Found<EMAIL_ADDRESS>steps to replicate in VS-code:
[yo version 6.4.1]
yo

(a)microsoft/sharepoint
SharePoint Online only (latest)
WebPart
No JavaScript Framework

npm install
npm ERR! code E404
npm ERR! 404 Not Found<EMAIL_ADDRESS>0 info it worked if it ends with ok
1 verbose cli [ 'C:\Program Files\nodejs\node.exe',
1 verbose cli   'C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js',
1 verbose cli   'install',
1 verbose cli   '<EMAIL_ADDRESS>]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose npm-session e1b19b4e29b67172
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 404 https://registry.npmjs.org/@microsoft%2Fsp-search-extensibility 266ms
8 silly fetchPackageMetaData error for<EMAIL_ADDRESS>404 Not Found<EMAIL_ADDRESS>

Thanks Scheevel.  Ran into an issue with the new package.  We're getting the package perms sorted out and should have it published shortly.

Same here....

Although a heads up, the search package will only be available in the 'preview' 1.10.0-plusbeta
version, not the 'standard' 1.10.0 version, as it is still in preview.

Just curious if I did htis right...
I installed, then did info and it looks like a really old modified date.  Is that the problem or is it that I am not checking version correctly?

@mikezimm - your npm info was against the non-@microsoft package.  You'll want to run npm info @microsoft/generator-sharepoint

@patmill, Thanks for pointing that out... I was trying different things because of the @microsoft/sp-search-extensibility error and must have had that in the clipboard.
Upon running the right command I see the latest info.
I was able to roll back my generator to 1.9.1 and scaffold a new project with that for now.
Thanks!

Dupe of #5083


fix reading files

testFutureProofing and testMultiPartFileMixingBasic both use fread(&length,4,f) to get a 4 byte
integer value from input file. The value read is not converted from the little endian format to
the machine format causing problems (eg. test didn't finish after 24 hours).
fixes issue #81

I confirm, that #432 fixes the problem and builds on all Fedora arches (armv7, aarch64, ppc64le, s390x, i686 and x86_64).

Thanks!


Issue when calling session.Position() while video playing in the background.

Hi,
I recently started to use this wonderful library, specifically the Media lib. Thank you very much for the library.
While the video is playing in the background, the value retrieved with session.Position() does not change, until the video is paused.
So my current workaround is to pause the video for 1 mil second, then get the current position, and set the next position, then resume playing. Example pasted below.
session := Media.GetCurrentSession()
session.Pause()
Sleep(1)
session.ChangePlaybackPosition(Min(session.Position+5, session.MaxSeekTime))
session.Play()
one way to reproduce the issue, have a YT video playing in the background untouched, then do session.Position() multiple times, you should see it return same value every time.

I finally had time to look into it and it appears that YouTube in particular doesn't update timeline properties. I tested in Spotify and also Spotify inside Chrome, and there Session.Position updated roughly every 5 seconds and TimelinePropertiesChangedEvent was also called about as often. Unfortunately I don't see a way to force the timeline properties to change other than the method you are currently using.
During testing I also discovered that I had omitted a way to update timeline properties without getting the session again with Media.GetCurrentSession(). I've now fixed that mistake by adding Session.UpdateTimelineProperties() (although it doesn't fix the bug described here.


Offline delete execution after orphan block scan

Refactor select_gc_bucket and offline_delete scripts to calculate vnode IDs
in offline_delete side
Use offline_delete for output files from block_audit and ensure_orphan_blocks
Add test for select_gc_bucket
Misc refactoring

If you can fix nitpicks above today, I'll wait .

... wait +1ing.

I pushed the update, master.

Output of manual test said:
$ riak_cs/rel/riak-cs/bin/riak-cs escript ~/cs-2.1/riak_cs/priv/tools/internal/block_audit.erl -h localhost -o /tmp/select_gc.txt
15:09:56.477 [info] Application lager started on node nonode@nohost
15:09:56.512 [info] Retrieved bucket list. There are 1 buckets, including tombstones.
15:09:56.512 [info] Searching for orphaned blocks. This may take a while...
15:09:56.512 [info] Finding Orphaned blocks for Bucket "test"
15:09:56.537 [info] Logged 2465 block keys to test
15:09:56.736 [info] handle_manifest_fold done for bucket: "test"

I thought the code
    info("Total number of UUIDs that has any orphaned blocks: ~p [count]", [UUIDs]),
    info("Total number of orphaned blocks: ~p [count]", [Blocks]),
    info("Orphaned Blocks written to ~p", [filename:absname(Filename)]).

shows the file to use next, but it didn't appear. Any idea what was wrong?

I just removed whole data in LevelDB.

Ah, that's because I deleted bucket record. mmmm.....

fmm, failing again
$ riak_ee/rel/riak/bin/riak escript ~/cs-2.1/riak_cs/priv/tools/internal/offline_delete.erl  -r 8 --dry-run ~/cs-2.1/riak_ee/rel/riak/data/bitcask /tmp/select2_gc.txt/test
[Warning]
Make sure any Riak process using '/Users/kuenishi/cs-2.1/riak_ee/rel/riak/data/bitcask' is not running or your data may corrupt.
Accept the terms of conditions? [y/N] y
64 bitcask directories at /Users/kuenishi/cs-2.1/riak_ee/rel/riak/data/bitcask opened.
Using bitcask key version: 1.
escript: exception error: no function clause matching mochihex:dehex(116) (src/mochihex.erl, line 32)
  in function  mochihex:to_bin/2 (src/mochihex.erl, line 61)
  in call from offline_delete:for_each_line/6 (/Users/kuenishi/cs-2.1/riak_cs/priv/tools/internal/offline_delete.erl, line 133)
  in call from offline_delete:offline_delete/3 (/Users/kuenishi/cs-2.1/riak_cs/priv/tools/internal/offline_delete.erl, line 108)
  in call from escript:run/2 (escript.erl, line 747)
  in call from escript:start/1 (escript.erl, line 277)
  in call from init:start_it/1
  in call from init:start_em/1

(??)

oh, I need to run ensure script before.

Hey @borshop

Merging as @borshop is temporarily unavailable, manually tested at laptop.


update navigation

close #6120
I updated both header and footer as per issue description

CR @xavijam

retest this, please
@xavijam the rest of sites have already updated the navigation (header and footer), can you review or pass it along? thanks!

Working properly in Safari then :)

Staging?

indeed, also applied the changes in the comments
staging is in http://matataded04.cartodb-staging.com/data-library

http://matataded04.cartodb-staging.com/data-library

A good PR is a closed one.

For me perfect, just the comments I made and good to go.

retest this, please


About changing accessories

Hello, I am creating a SpanAccessory according to the mainConfig.selectedMode value in the Setup function.
When I change mainConfig.selectedMode, the other one naturally goes to "No response" in the home application.
When I want to add an accessory, I cannot see any accessory.
When changing mainConfig.selectedMode, I can delete the existing paired device and give the opportunity to pair again.
The question I want to ask is;
Is it possible to see the new accessory without pairing it again?
Code:
if (mainConfig.selectedMode == "Led")
  {
    homeSpan.begin(Category::Lighting, "LightBulb", HOSTNAME.c_str());

    new SpanAccessory();
    new Service::AccessoryInformation();
    new Characteristic::Identify();

    new Characteristic::Manufacturer(HOSTNAME.c_str());

    new Characteristic::FirmwareRevision("1.0.6");

    new DEV_LED("LED1", relay_1, switch_1);
    new DEV_LED("LED2", relay_2, switch_2);
  }
  else if (mainConfig.selectedMode == "Garaj")
  {
    homeSpan.begin(Category::GarageDoorOpeners, "Garage", HOSTNAME.c_str());

    new SpanAccessory();
    new Service::AccessoryInformation();
    new Characteristic::Identify();

    new Characteristic::Manufacturer(HOSTNAME.c_str());

    new Characteristic::FirmwareRevision("1.0.6");

    new DEV_GarageDoor();
  }

HomeSpan Ver. 1.9.1

In general you can't change Accessory definitions in HomeKit without un-pairing and re-pairing unless you ensure that you preserve the AID for each Accessory and you don't change the order of any Characteristics.  This makes it possible to add/delete multiple copies of the same Accessory (for example, a bridge with an arbitrary number of dimmable light Accessories).
It is possible to do this without even re-booting your HomeSpan device.  See the Programmable Hub example for details.


Missing projects and contributors

It's a great list but it's missing some major contributors from Austria like @nikgraf and @mxstbr.

https://github.com/mxstbr/react-boilerplate
https://github.com/carteb/carte-blanche/
https://github.com/nikgraf/belle
https://github.com/draft-js-plugins/draft-js-plugins

coming to mind but there are much more! Would be great to have them listed as well.

This entire org is basically missing. I moved them out of my account a while back: http://github.com/pallets

@okonet @mitsuhiko Currently these made-in-* lists are fetched using individual accounts. You can add new repositories via pull requests. 😁

@pa7 create PR and heatmap as well? https://github.com/pa7/heatmap.js/tree/master

Sure!
On Sun, Sep 18, 2016 at 4:22 PM, Nik Graf<EMAIL_ADDRESS>wrote:

@pa7 https://github.com/pa7 create PR and heatmap as well?
https://github.com/pa7/heatmap.js/tree/master
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/IonicaBizau/made-in-austria/issues/2#issuecomment-247847396,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACu080eOm3alpQwt7yxr0-TP8GeoMSgzks5qrTr-gaJpZM4J4Tlw
.


Wrong offsets for KPCR::Prcb and others

And possibly others.
Take this example: https://github.com/ntdiff/headers/blob/master/Win10_1909_19H2/x64/System32/ntoskrnl.exe/Standalone/_KPCR.h#L1331
For all major compilers , the calculated offset is 0x178, not 0x180: https://godbolt.org/z/ZJ-DfV
Edit: And if I use #pragma pack, the size is 0x174.

Apparently the reason is:
Curiously, PcrAlign1 does not by itself align the Prcb that follows. That Prcb is meant to be cache-aligned
is certain: cache  alignment is plainly a recurring concern within the KPRCB and is obviously simpler to
arrange if the KPRCB is itself cache aligned (which it isn’t for 32-bit Windows).

Source

This is also wrong https://github.com/ntdiff/headers/blob/master/Win10_1909_19H2/x64/System32/ntoskrnl.exe/Standalone/_KPRCB.h#L915
It should be at offset 0xFA. Same for the following struct, since said struct has an alignment because of 2 because of the short in there.

This is also wrong https://github.com/ntdiff/headers/blob/master/Win10_1909_19H2/x64/System32/ntoskrnl.exe/Standalone/_KPRCB.h#L915
It should be at offset 0xFA. Same for the following struct, since said struct has an alignment because of 2 because of the short in there.

You're probably missing #pragma pack(1) - which is recommended to use with any structs on ntdiff.

You're probably missing #pragma pack(1) - which is recommended to use with any structs on ntdiff.

@wbenny If I do this, it works in this case, but most other structs break.
For example _EPROCESS size is calculated as 0x868 instead of 0x880 as it says in the ntdiff headers.

@wbenny If I do this, it works in this case, but most other structs break.
For example _EPROCESS size is calculated as 0x868 instead of 0x880 as it says in the ntdiff headers.

Yup, I've seen that some of the structures in newer Win10 builds are somewhat broken :/ I'll have to look into this.

Yup, I've seen that some of the structures in newer Win10 builds are somewhat broken :/ I'll have to look into this.

any update on this issue?


Added QuarkNet's NSF award number

Description
Please include a summary of the change and (optionally) which issue is fixed. Please also include
relevant motivation and context.
Fixes # (issue)
Type of change
Choose which options apply, and delete the ones which do not apply.

Bug fix (non-breaking change that fixes an issue)
New feature (non-breaking change that adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation update
Code maintentance/cleanup

Hi @JG-QuarkNet - the award number is actually 1550476
And you also need to add
.. |NSF-1550476 | image:: https://img.shields.io/badge/NSF-1550476-blue.svg
   :target: https://nsf.gov/awardsearch/showAward?AWD_ID= 1550476
   :alt: NSF award info

further down in the readme

Did it wrong

no problem - for the future, you can continue to make changes to an existing PR, you don't need to delete it and then create a new one, but it doesn't matter too much at this point


LoginView

Task form 'React Revolution'

add the view for login (https://github.com/CodeForPoznan/pah-fm/blob/master/frontend/src/views/LoginView.vue)
use formium/formik (https://github.com/formium/formik)
use yup for schema validation (https://github.com/jquense/yup)

https://github.com/CodeForPoznan/pah-fm/tree/react-revolution

It's been done


Fixes menu issues...

Newer STEAM Demeo downloads only have 1 folder for both PC and VR
Fixes a bug with HouseRules and RoomFinder menus not appearing for that combined version

Tested and as this only affects when the menu is displayed it really can't (and seemingly doesn't) cause any issues checking for both possible Lobby Scene Indexes.


Specifying log level for webviz build does not work as expected

Specifying the wanted log level on the command line when doing webviz build does not have any effect.
The following command line should set log level to INFO but currently this does not happen:
webviz build ../webviz-subsurface-testdata/webviz_examples/webviz-full-demo.yml --loglevel INFO

Note that fixing this issue will most likely trigger a new need for filtering of log messages from underlying modules since once we're able to set the global log level to INFO or DEBUG, the log will most likely be flooded with messages.

Some initial experiments indicate that the core issue may be resolved by making sure that something like this gets called before any other logging calls in our jinja2 templates
logging.basicConfig(level=logging.{{ loglevel }})

Possible syntax for logger specific levels:
ros2 run logging_demo logging_demo_main --ros-args --log-level debug
ros2 run logging_demo logging_demo_main --ros-args --log-level logger_usage_demo:=debug
(from https://docs.ros.org/en/foxy/Tutorials/Logging-and-logger-configuration.html#logger-level-configuration-command-line)

An easy alternative to how ros does it could perhaps be --log-level accepting a user provided YAML config for logging configuration (if more detailed instructions are needed).
There is an example of YAML input config in the Python std.docs (bottom part of section https://docs.python.org/3/howto/logging.html#configuring-logging).

Will concentrate this issue on fixing the bug.
Enhancing logging granularity split into new issue: https://github.com/equinor/webviz-config/issues/439


'package:flutter/src/widgets/framework.dart': Failed assertion: line 5356 pos 14

 log

The relevant error-causing widget was:
  ScreenUtilInit ScreenUtilInit:file:///Users/admin/Desktop/testapp/lib/main.dart:22:16
When the exception was thrown, this was the stack:
#2      InheritedElement.notifyClients (package:flutter/src/widgets/framework.dart:5356:14)
#3      ProxyElement.updated (package:flutter/src/widgets/framework.dart:5118:5)
#4      InheritedElement.updated (package:flutter/src/widgets/framework.dart:5338:13)
#5      ProxyElement.update (package:flutter/src/widgets/framework.dart:5106:5)
#6      Element.updateChild (package:flutter/src/widgets/framework.dart:3501:15)
#7      ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4780:16)
#8      StatefulElement.performRebuild (package:flutter/src/widgets/framework.dart:4928:11)
#9      Element.rebuild (package:flutter/src/widgets/framework.dart:4477:5)
#10     BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:2659:19)
#11     WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:882:21)
#12     RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:363:5)
#13     SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1144:15)
#14     SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1081:9)
#15     SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:995:5)
#19     _invoke (dart:ui/hooks.dart:151:10)
#20     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:308:5)
#21     _drawFrame (dart:ui/hooks.dart:115:31)
(elided 5 frames from class _AssertionError and dart:async)
====================================================================================================
Application finished.

Code:
class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ScreenUtilInit(
      designSize: Size(460,790),
      builder: (context) => MultiProvider(
          providers: [
            ChangeNotifierProvider(create: (context) => TestApp()),
            ChangeNotifierProvider(create: (context) => PageControllerProvider()),
            ChangeNotifierProvider(create: (context) => RequestProvider()),
            ChangeNotifierProvider(create: (context) => HistoryProvider()),
            ChangeNotifierProvider(create: (context) => ThemeProvider()),
          ],
          child: App()
      ),
    );
  }
}

@thisistorsten
From the code sample you shared, you seem to be using third party plugin code. In order to verify this issue properly, we'll need complete minimal reproducible code sample without third party plugin code.
Also, the red screen error you showed seems to be similar to https://github.com/flutter/flutter/issues/102803, so I suggest you to follow-up in that issue for further updates, or provide the code sample requested in that issue for better tracking.
Closing this as a duplicate.

I am also using screen utils packages. one of my team members getting the same error. may it is due to the screen utils package


Add ProvisionQL to Tools

Project URL
https://github.com/ealeksandrov/ProvisionQL
Category
Tools
Description
ProvisionQL - macOS Quick Look plugin for apps and provisioning profile files. It provides thumbnails and previews for:

.ipa - iOS packaged application
.xcarchive - Xcode archive
.appex - iOS/OSX application extension
.mobileprovision - iOS provisioning profile
.provisionprofile - OSX provisioning profile

Be sure to check out screenshots page to get whole idea of what it capable of.
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 2 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

1684
Dupe
https://github.com/DanisFabric/RainbowNavigation

2868
302
http://www.ios-blog.co.uk/ redirects tohttp://www.ios-blog.co.uk/cgi-sys/suspendedpage.cgi

  Generated by :no_entry_sign: Danger

Thank you.


Cannot run Unpackaged C# Winui3 app

Describe the bug
Cannot run Unpackaged c# app.

NuGet package version: Windows App SDK 1.0.0 (stable)
VisualStudio 2022. 17.0.1
x64
Win 11 22000.348

Steps to reproduce the bug
Create "Blank App, Packaged (WinUI 3 in Desktop)" project.
Delete "Package.appxmanifest".
Add <WindowsPackageType>None</WindowsPackageType> to the property group in the project.
Try to debug.
Expected behavior
No response
Screenshots
Here's a video showing what's happening to me.
https://imgur.com/hDJkpQi
NuGet package version
No response
Windows app type

[ ] UWP
[X] Win32

Device form factor
Desktop
Windows version
No response
Additional context
No response

Why did you close this? Is there any solution?

@AkiraVoid Are you having similar issues? Please open a separate issue with a min repro if that is the case.


[v15.0.0 regression] Google set incorrectly displays 🏴 Scotland flag as 🇸🇨 Seychelles flag

As of commit d5c6684a5573c26432f4bbd5a84645c7b477ef65 (#223) in v15.0.0, the Google set incorrectly displays 🏴 Scotland flag (1f3f4-e0067-e0062-e0073-e0063-e0074-e007f) as if it were 🇸🇨 Seychelles flag:
✔ v14.0.0, img-google-64:
✔ v14.0.0, img-google-136
❌ v15.0.0, img-google-64:
❌ v15.0.0, img-google-136:
All sets other than Google are unaffected:
✔ v15.0.0, img-apple-160:
✔ v15.0.0, img-apple-64:
✔ v15.0.0, img-facebook-64:
✔ v15.0.0, img-facebook-96:
✔ v15.0.0, img-twitter-64:
✔ v15.0.0, img-twitter-72:
The upstream image in Noto Emoji is unaffected:

The related 🏴 England flag (1f3f4-e0067-e0062-e0065-e006e-e0067-e007f) and 🏴 Wales flag (1f3f4-e0067-e0062-e0077-e006c-e0073-e007f) are unaffected:
✔ v15.0.0, img-google-64:
✔ v15.0.0, img-google-136:
✔ v15.0.0, img-google-64:
✔ v15.0.0, img-google-136:

black_bird is missing for the Google images and it breaks all the emojis listed after it. According to the JSON, it should be at [11, 25] on the sheet.
Data
{
  "name": "BLACK BIRD",
  "unified": "1F426-200D-2B1B",
  "non_qualified": null,
  "docomo": null,
  "au": null,
  "softbank": null,
  "google": null,
  "image": "1f426-200d-2b1b.png",
  "sheet_x": 11,
  "sheet_y": 25,
  "short_name": "black_bird",
  "short_names": [
      "black_bird"
  ],
  "text": null,
  "texts": null,
  "category": "Animals & Nature",
  "subcategory": "animal-bird",
  "sort_order": 620,
  "added_in": "15.0",
  "has_img_apple": true,
  "has_img_google": true,
  "has_img_twitter": false,
  "has_img_facebook": false
},

But if we compare the Apple vs. Google sheets, we can see the black bird is missing on Google:
Apple

<EMAIL_ADDRESS>
Google

<EMAIL_ADDRESS>

Ah wait, sorry, it was fixed in v15.0.1; make sure you use the latest version.

I am using the latest version—I just reported it for the version in which it regressed. There have been no commits to the images since v15.0.0; my issue was not fixed in v15.0.1.
❌ v15.0.1, img-google-64:
❌ v15.0.1, img-google-136:

Thanks for reporting this (and in so much detail). This broken when Google changed how they laid out their repo and specifically the calculated/composed flags. I'm landing a fix now that addresses this.

You’re welcome! If you don’t mind my drawing some attention to a separate issue, can you please also take a look at this very easy PR?

#217

This is now fixed on master. I'll wait a few days before cutting a new release, while other bug reports come in.

Just to let you know that I've now updated IRCCloud emoji to 15.1 and all looks fine. Thanks for your efforts.


Estimated transaction fee isn't calculated on create offer screen

Estimated transaction fee isn't calculated  on create offer screen

fixed at rev # 546708e8b3693ee4dbeb28a856e334b1b1b67aaa

checked


can not auto calibrate cell diameter

When I click 'calibrate' button, or using  --diameter 0.  , previous version worked, but this version comes out with :
TypeError: expected dtype object, got 'numpy.dtype[float32]'

I'm not sure why there would be a difference with the current version compared to before but please try pip install numba --upgrade. autocalibrate is working on windows and ubuntu with numba==0.55.0. if this doesn't work I'll reopen this issue.

Thank you for your reply, under your guidance, the bug was properly solved!
Hope cellpose gets better and better!
在 2022年5月1日，07:16，carsen-stringer @.***> 写道：

I'm not sure why there would be a difference with the current version compared to before but please try pip install numba --upgrade. autocalibrate is working on windows and ubuntu with numba==0.55.0. if this doesn't work I'll reopen this issue.
—
Reply to this email directly, view it on GitHubhttps://github.com/MouseLand/cellpose/issues/506#issuecomment-1114070441, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2GDMRNYAMENNJCKPOTJCTVHW5MZANCNFSM5UUHJ4AQ.
You are receiving this because you authored the thread.Message ID: @.***>


Backgroung color wor write function

I think backgound color for the write function does not work
Here is the code I wrote to illustrate, coming for the hello.py example.

import random
from utime import sleep_ms
import rm67162
import tft_config
import fonts.large as font_var
import fonts.vga2_bold_16x32 as font_mono
tft = tft_config.config()
def main():
text = "Hello!"
tft.reset()
tft.init()
tft.rotation(1)
tft.fill(rm67162.RED)
#Ok filled in red
tft.write(font_var, text, (tft.width() - tft.write_len(font_var,text)) // 2,
(tft.height() - font_var.HEIGHT ) // 2, rm67162.WHITE, rm67162.RED)
#KO background is black
sleep_ms(2000)
tft.fill_rect(0,0,tft.width(),tft.height(),rm67162.BLUE)
#Ok filled in blue
tft.text(font_mono, text, (tft.width() - len(text) * font_mono.WIDTH) // 2,
(tft.height() - font_mono.HEIGHT ) // 2, rm67162.WHITE, rm67162.BLUE)
#OK background is blue
sleep_ms(2000)

Can you try and confirm, I send below an appropriate variable bitmap font I used.
large.zip

Hi,
I can confirm this issue! It's now fixed. Thank you again for testing out!

All right, I was wondering why the grey looked like grey and vice-versa. That seems better and background is working.
However, you suppressed the polygon and filled polygon function ?

All right, I was wondering why the grey looked like grey and vice-versa. That seems better and background is working.

This is due to the color byte swapping. I forgot to take out of the code. Hence the color is different than what it should be.

However, you suppressed the polygon and filled polygon function ?

Ops.. was unintentional, sorry. Was editing the code on another PC and I hurried a little. Going to bring that back asap. Aka, a few minutes.

Done.

Thank you.
I'll dig a little bit more since I always face some trouble with the fill_rectangle. I definitely don't understand where it's comming from and I can't reproduce from a short piece of code...
By the way, I've been testing my program on two different hadware / libs.
1st one is a Pi Pico, overclocked to 240Mhz, single thread, with an SPI ST7789 screen
2nd one is an ESP32S3, clocked to 240MHz, single thead with a QSPI RM67169 screen
As the program is gathering info from a bosh BNO085 (9axis) + BME280 (env sensor) but also BLE, acting like a display (i mean representing information gathered), I expected the QSPI setup to be much faster than the SPI one.
What I found :
Pico + ST7789 = 12 to 14 FPS
ESP32S3 + RM67169 = 8 to 10 FPS
Assuming that the SPI display is 320x240 whereas the QSPI is 536x240 on one side, and on the other side QSPI = 4xSPI lines, I would have expected the QSPI setup to be twice faster as SPI one, instead of being 50% slower.
What's your opinion ?

Hi,

I'll dig a little bit more since I always face some trouble with the fill_rectangle. I definitely don't understand where it's comming from and I can't reproduce from a short piece of code...

Well, some of the functions are not very safe since they parse a int to uint16_t, which is an unsigned int type and it's easy to make an overflow mistake. That's a design issue of mine. But feel free to contact if you got some reproduce-able codes, I'll try to solve these issues.

Assuming that the SPI display is 320x240 whereas the QSPI is 536x240 on one side, and on the other side QSPI = 4xSPI lines, I would have expected the QSPI setup to be twice faster as SPI one, instead of being 50% slower.

What's your opinion ?
The esp32 port differs from the rp2 ports. You can only compare an apple to an apple. Which normally, esp32 ports tends to be slower than rp2 and stm32 due to freeRTOS  overheads. One way used to make the situation better is to allocate a huge chunk of heap RAM as buffer. Besides, your rm67169 display has actually 0.675 times more pixels, so the qspi actually works.
Plus, if you were actually trying to bench the driver/displays fastest refreshing rate, you should be only running graphical tasks. As there also could be some overhead lying in the sensors. Also, just for reference, if you are using this driver,  the fill() function can be executed over 50 times per seconds, which means, the max FPS is over 50.
And btw, if you do not overlock the rp2, that is run it at 125MHz, you can get 62.5MHz for the spi line, so, faster than clocks above any cpu clock over  125MHz.

Well, Thank you for your answer.
My main concern wasn't to benchmark the two solutions but from scratch, I expecter the EPS32 to go ahead the Pico.
 AMOLED is perfect for outside purposes. Of course le display is very small compared to the Washare 2.8" but the quality has nothing to compare.
I'm working on an app since last year in order to put on a motorbike. I've been improving it a lot (it can discuss with calculator, by wire or by BLE, get roll/pan/tilt, acceleration and what ever, store datas, be contacted by wifi...). I'm having much fun doing this even if lack the years I was student since I have so less time to developp.
For now, everything works on Pico, but I'd like to improve a bit performance, i think I'll focus on dual threading Sensors calculation vs display. It runs at 15 FPS, let's try to gain +25%
On the ESP32, everything works too, but I still face this rect_fill bug I'm working on. I also miss the JPG
functions (I've tried to import the slow JPG that's farely sufficent for my purpose : Displaying the bike picture during startup...) and the bad point is that is reaches hardly more than 10 FPS. Maybe the second thread could also increase a bit.
Well, I'd like once more to say Thank you, You've been a nice help and reactive as a Cobra to correct small bugs. If you find the time, don't forget about JPG :-)

Hi,
If the jpeg file is small, you can just convert all the pixel data into color565 raw data first, then use the bitmap function to display it. It should be very fast.
If all you need is the 25% increase over the pi pico. Please try my suggestions above. Do not - overclock the pico and set the spi baudrate to 62500000.

The new version

As you can see, even if a wrote a rect_fill on parts of the previous areas, a still have background glitches from the first screen displayed (see below)

:( actually, I can give two days on the jpeg.
But it will be slower than raw color565 data, and uses more RAM than raw data. The only advantage is, that you save some flash space. That's something you should keep in mind. And that is also the only reason why I have not prioritized it.

As you can see, even if a wrote a rect_fill on parts of the previous areas, a still have background glitches from the first screen displayed (see below)

That's strange, if you meant the text "sprint RS 955i". Have you tried to write the area with a fill_rect() function? Are you certain, that the function which will write the text is never called somewhere unexpected?
To simply test the fill_rect function, you can just fill an area with color 1, delay 2 seconds, and fill the area with color 2. It passed this test on my end.
Btw: really good looking project! That's something you definitely should be proud of!

 Jpeg was more convinient for the ease of use (common format everybody knows) but that must make it !
Concerning the background, of course I've been investigation my code but that's impossible I get a write function of the text in  the main loop, it's called only once.
My hypothesis were :
1/As I use subroutines, I transmit display as a Global variable, So I checked I didn't forget anything (OK)
2/I "clean the display" every time I change the type of screen, maybe I forgot smthg => I checked, it's
impossible since the tittle (on top) comes from the same subroutine and is working
3/hardaware related issues : The one I believe on the most :
On Pico version, screen is handled via I2C
On ESP32, screen is handle via QSPI (the main difference)
On both Touch screen, Gyro and Env are handled on I2C
Touch screen is handled via interrupt gesture
Normally, there should't be any relation (the bug appears before any screen touch) but I suspect some kind of interraction. The Gyro sensor requires I/O operation to handles chips reports every 50ms.

1/As I use subroutines, I transmit display as a Global variable, So I checked I didn't forget anything (OK)
2/I "clean the display" every time I change the type of screen, maybe I forgot smthg => I checked, it's
impossible since the tittle (on top) comes from the same subroutine and is working
3/hardaware related issues : The one I believe on the most :

On Pico version, screen is handled via I2C
On ESP32, screen is handle via QSPI (the main difference)
On both Touch screen, Gyro and Env are handled on I2C
Touch screen is handled via interrupt gesture
Also, maybe 4, but I can not think how it could happen. Both write() and  fill_rect() functions use the same buffer, which is a 240x536x2 bytes buffer. Both functions use the same RAM area if their size is the same. However, when you call fill_rect(), a "refilling" of that area should occur and the font data should be overwritten. But if it somehow (which I do not get why) could not, the same font data will be displayed again.

Well,
Both case (fill or rect_fill) give the same result...
confirming that same buffer = same result.
It's annoying I can't reproduce this on a small part of code.

I managed to get the issue on a small part of code
I send you the micro bug-tracking project ;-)

Actually.. ugh... If you do not mind, you can add me on QQ: 630874937 and send me the code privately. I kinda want to know how this could happen.

Well, I'll appreciate some help, this thing is driving me crazy...

QQ:630874937

You mentioned Chinese earlier, so I assumed that you are from mainland China. If that weren't the case, ugh... You can contact me via<EMAIL_ADDRESS>

Ugh, hi,
Since I am not comfortable having my personal information exposed to the internet for a long period of time and we could not establish a connection during that time period, I suggest you to open a private github repo and add me to the contributor, later you can delete that repo whenever we are done.
best regards.

Hi, sorry we were outside while it was not raining. Uou're right, keep our emails away from exposition.
I've made some progression :-)
I join you the bud_tracking .PY file I made, from far it's simpliest than digging in my code (I should reorganize a bit, definitely)
bug_track.zip
So, it seem to be a 3 player affair, Wifi and Bluetooth on one side, my own library on the other side and the display driver in the middle. More comments are in the main file I send you.
The ODBBLE library I made is public access on my github so no matter who can see it !
By the way, I'm french (maybe the reason my english is too bad), glad to have a friend in China (am I right ?)

Ugh, what I see in your code is.. Or the expected behavior should be:
You see "You should see me alone" always displayed on the display, flickering once every seconds.
Here is how I see it is being executed:

in line 10, you enter a infinite loop.
in line 11, you call clear display(), this jumps to line 1
in line 2, you clears the display with black
in line 3, you put the text immediately on the middle of the display
in line 5, you pause for 1 second
in line 6, you clears the display with black
after line 6, clear_display() returns, and you continue at line 12
in line 12, you again puts the text on the display immediately
in line 14, you pause for another second and
after line 14, you jump back to line 11, and the process loops

If the display refreshes too fast, which it does, you won't see any difference in displayed text with this piece of code.
To me, I would change the function as follow to exam whether the texts are  "erased" correctly:
change:
text = "You should see me alone"

to something like
text1 = "First text"
text2 = "Second text"

Then call them respectively in the while True loop and clear_display() function like so:

(Sorry if I were providing too many details, maybe this is just a mistake caused by carelessness, we all make these :D)

By the way, I'm french (maybe the reason my english is too bad), glad to have a friend in China (am I right ?)

Partially :D, am actually living in EU as well. But I do speak Chinese and definitively looks Asian.

For sure I could have made 2 different texts,
But that looked funny to have two "you should see me alone" at the same time when the bug appears.
The code structure may seem strangle but I firstly wanted to keep my main program structure (clear display is called by an interruption handler).
PS : so we share the same time zone 😁

Oh, sorry, I was not care enough to note the starting point's different. (80 and 120). My bad!
PS: yes, exactly.

https://github.com/nspsck/RM67162_Micropython_QSPI/assets/86347287/1558d7ee-94a3-418e-8a8e-77fac8c78e7f
Ugh, so, it basically works fine on my device.
I removed the cst8x module, because I don't have it. Other than that, very thing runs as expected.

I have also changed the WIFI accordingly. And also, I removed the line which set IO38 to high, because mine works fine without that.

Right, IO38 is only for the T-display S3.
I forgot to remove the cst38 import line, at the beginning I suspected to interfer but I can reproduce the bug without the library
(I wrote TS support driver myself). Here it comes if you want.
cst8x.zip
The bug appears when Wifi + Bluetooth + ODB are working together.  Also when only Wifi + BT are setup, it works but as soon as you reboot I got an OSError...

https://github.com/nspsck/RM67162_Micropython_QSPI/assets/8106589/c188f763-edaa-48cb-b849-51cb63fcbad6

I spent some time on the schematics on v1 and v2. These looks almost identical in terms of IOs. (besides IO38 is called OL_EN, and enables the AMOLED display).
Could you please make the text print a changing number indicating the display is still being updated and it is not hanging?

https://github.com/nspsck/RM67162_Micropython_QSPI/assets/8106589/b5bedeb2-0e28-426c-ba81-2448bdfb833b
No, it's not handling.
On my program, I can even change the screen that is displayed but the display clean-up (like clear display) does the same bug.
On my side I've add and interrupt flag within the obdble library, without real expectation... Well as expected doesn't change anything.
On your side do you activate WiFi & Bluetooth?

https://github.com/nspsck/RM67162_Micropython_QSPI/assets/8106589/874faa61-b872-4c27-a9c3-a07061b4c54c
See what happens on my prog. Everything works, I can change the screen but no clean-up occurs...

Hi
Ye, kinda, not so sure if they were running tho.
Btw. I meant to actually print some numbers on the display like:
count += 1
text = ('hello world %d', count)
tft.text(text, x, y, fg, bg)

See what happens on my prog. Everything works, I can change the screen but no clean-up occurs...

Have you uploaded the wrong video?

See what happens on my prog. Everything works, I can change the screen but no clean-up occurs...

Oh, wait, sorry, are you using the latest firmware? Because for the older version, if you were using the fill_rect() function, it only goes up to 239x535, anything over that will do nothing... That must be it..

As, the pixels goes from 0 to 239, total 240 pixels.. Then I uniformed this in #7 . To check if that was the cause, please try using the fill(rm67162.BLACK) function instead.

On the video the console is outputting a tick_ms output from the program.
The second file (image) show what is happening when I change the display calling the cleaning procedure. It's working, I mean values that are shown get updated on the display. Only the fill of the entire area (fill_rect or fill function) doesn't seem to do her job.
I've shut down the computer for tonight. See if I can dream of a solution. I might try to print a buffer filled with 0 in order to see if bitmap function has more luck.
PS : the fact that it is happening only when WiFi is activated frighten me to be something out of your library behaviour.

Only the fill of the entire area (fill_rect or fill function) doesn't seem to do her job.

Hmmm, if both functions can not do the job, and the bus is not broken..... Then the next thing in my head is when will the sun explode.... (like for real, this is just a big HOW for me) The fill function is a pointer-based filling function and the freeRTOS does not necessarily ensure memory safety, which means, that fill  function will indeed fill whatever there are (from the device memory) into the display memory. So, even if the buffer is corrupted, it will show random color pixels to the display (like an old TV without signals).
Maybe try to initialize the WIFI, BLE, and other stuff first, and see if the display can be created?

Oh, wait, sorry, are you using the latest firmware? Because for the older version, if you were using the fill_rect() function, it only goes up to 239x535, anything over that will do nothing... That must be it...

Have you tried this already? Like, this is the last logical reason that I can think of.

On the video the console is outputting a tick_ms output from the program.
The second file (image) show what is happening when I change the display calling the cleaning procedure. It's working, I mean values that are shown get updated on the display. Only the fill of the entire area (fill_rect or fill function) doesn't seem to do her job.
I've shut down the computer for tonight. See if I can dream of a solution. I might try to print a buffer filled with 0 in order to see if bitmap function has more luck.
Added : I missed your post concerning 239x539 limitations. I've pulled github 2 or 3 days ago. I'll upgrade once more tonight. (that might be it, as my display clean-up was 536x190).
PS : the fact that it is happening only when WiFi is activated frighten me to be something out of your library behaviour.

Well
I checked I use the latest firmware
I checked both 239x535 and 236x536
I added a number to the main loop...
https://github.com/nspsck/RM67162_Micropython_QSPI/assets/8106589/18d3cbaf-b857-419a-906e-d0d872e7d074
I got a WiFi error everytime I try te run a second time the program...

I've uploaded everything to the last version (Micropython code, libraries....), reorganized my code for readability (nothing to do with our trouble) rebuild everything and guess what... ?
Still not working :-(
The only thing I am shure :
When I activate Wifi  ==> The bug appears and remains after stop/start.
When I do not activate WiFi ==> The bug isn't there even stop/start.

Funny enough, I finnally was able to reproduce the bug after I reduced the framebuffer size... like, after dropping the framebuffer completely I was able to reproduce the bug... WTF?

Strange, very strange M. Holmes !
Do you think I should to use a specific buffer in order to get around that bug ?
After all, we got sufficient memory on the ESP32 to create a display buffer.
Maybe I could make screen opération directly in this buffer (I don't know if I can use
your library graphic function on this one) and copy the entire buffer to the screen at one time ?

something like
import framebuf
buffer = bytearray(TFT_WIDTH * TFT_HEIGHT * 2)
fbuf = framebuf.FrameBuffer(buffer, TFT_WIDTH, TFT_HEIGHT, framebuf.RGB565)

then you call
tft.bitmap(x_start, y_start, x_end, y_end, fbuf)

This could work

Well, I replaced
tft.fill_rect(0,0,tft.width(),tft.height(),rm67162.BLACK)
by
tft.bitmap(0,0,tft.width(),tft.height(),fbuf)
with the parameter to create the frame buffer
buffer = bytearray(TFT_WIDTH * TFT_HEIGHT * 2)
fbuf = framebuf.FrameBuffer(buffer, TFT_WIDTH, TFT_HEIGHT, 0)
and it gives me another strange behaviour

https://github.com/nspsck/RM67162_Micropython_QSPI/assets/8106589/7c1b3191-e99d-41e8-b516-bc4c973f01fb

I give up for tonight.
However thank you for help !

Ok, the problem I had was a different bug. Also a weird one but should not be related to yours.
So, I tried to implement a RAM-saving thing for you. All functions that do not require tons RAM work just fine. The fill_rect only works for a maximum of 536*8 pixels area.   If this works for you, I'll then add gc, or optimize the code.
If you want the old behavior, (i.e. the massive buffer) add use_frame_buffer=True to the RM67162 constructor. Not the panel constructor.

Just a question,
Why do you use a frame buffer for the fill purpose.? Can't you write straight the two color bytes directly to the screen buffer?

Hi
I just did it with the bias that esp32s are filling faster if you give them a full chunk of buffer. (10-20% back then) And it's for the simplicity on the development side.
This driver uses DMA, and the way DMA works: It requires a internal DMA-able RAM to pull data from and some time to initialize, and the CPU must set the pointer and parameters for the DMA. So if you were just using 2 color bytes (if I understood your suggestion correctly), you are totally defeating the purpose of using DMA, that is taking load off of the CPU. The CPU must initialize the DMA over and over and over again.
But it makes sense to not use the whole buffer. But that requires me to manage the memory from every individual function that I create. And in case I forgot, I'd be having a bug that hunts me badly. rust is so much better than C just for this purpose only, btw. But the C compiler won't warn me at all.
Also, the current solution requires the temporary buffer to be freeed immediately after the filling is done, otherwise it will go into PSRAM, which is not DMA-able, causing a system reboot.
Also, I had some ideas back then, that is creating a mode which the DMA just polls whatever is available in the RAM and transmit these into the display. This causes a little tearing but it allow the CPU to run freely, which is great for game development, which is also another dead project of mine, which I was horrified by the behavior on each port then I killed that project.
PS. Did this change solver your problem?

Hi,
Well, I digged a little bit more modifying the bugtracker.py to elimate my library relation.
The bug is still present, meaning that it's a deal between bluetooth library and the display driver.
I believe the bluetooth driver might be something wrong... or the library itself...
All test are commented inside the next file
bug_track.zip

Hi,
I just implemented the fill_color_buffer_slow() correctly. (at least to be my believes). This uses at max 536 x 8 x 2 bytes for buffering. fill_rect() and fill() can now be used like usual.
Your program runs perfectly on my device. The v1 one. So.. I hope the update could fixe your issue, otherwise it also might just be hardware related.
Best Regards.

And I've also tried the solution you provide... Guess what: It works !
bug_solution_test.zip
We made a serious progress !
Moreover, if I check the frame per second, I reaches now the same results as on a Pico.
It went from 8/9 FPS to 13/14 FPS. That's not why we expected...

It went from 8/9 FPS to 13/14 FPS. That's not why we expected...

:O wow, that s actually not what I was expecting! nice!

Also, am going to close this issue, but you can still comment on this!

Well, I pulled the latest code in order to be shure I got the latest code.
It still works !
But FPS has gone down to 7 FPS !
Nevermind, I now have both lilygo / pico working on the same code !
I've rarely seen someone giving such time for supporting a maker !
Thank you so much !

Hi,
Just a post to mention that apparently with the latest ESP-IDF chaintool (5.2.2), the bug seems to have disappeared.

Ugh... Which bug? Haven't we already got it fixed?

Sorry I was not readable in the last post :
I updraded ESP32 IDF chaintool to 5.2.2 to see if there was differences :
The use_frame_buffer=False bugfix initialisation method works fine (and provides 14.5 FPS to my program)
The use_frame_buffer=True initialisation method still have the bug (and provides 17.5 FPS to my program)
Thus, 5.2.2 IDF doesn't change anything.


Remove ContentWindowPersistentData and possibly ProjectSettingsManager

This is no longer needed once everything using it has been transferred over to the new preferences manager

ProjectSettingsManager might need some refactoring. It would benefit from a better name and it seems like there might be a race condition when set() is called before loadInstance has finished running.


Project: A chatbot game

Project name
who am i
Description
A chatbot game to find out who is the person the bot has generated in its mind. This game is built for MS Teams Chat application and this bot can be deployed to Azure Cloud to roll out to the entire organization. This game utilizes generative Chat OpenAI model to get a famous personality and to compare and verify the answer provided by the user during the game.
Game Intents

Personality Generation - Upon typing the words "new game" the game will be started. The bot will communicate with OpenAI using the Langchain framework and generates the name of a random famous personality and stores the name in a variable.
Comparison Check - User can guess and ask upto 10 questions to figure out who is the person that bot has thought about. The question will be compared with the person using the LLM chain call and the bot responses with one word by Yes or No without revealing the answer to the quiz.
Condition Check - If the user cannot find within 10 questions, the bot logic will reveal the answer and completes the game to end. Or if the user found the answer then the bot will Congratulate and complets the game to end.
Other Questions handling - Since the bot is consuming the generative AI if the user asks any other question apart from the game is politely handled and motivates to revert to the game.

Project Repository URL
https://github.com/cswesh/who-am-i
Project video
https://github.com/cswesh/who-am-i/blob/main/game-sample.mp4
Team members
https://github.com/cswesh

https://github.com/microsoft/hack-together-teams/assets/3072845/8608fdc9-d77f-4319-92e1-b4ceb3204665

Thank you for your project submission @cswesh, I'm excited to check out your project! Meanwhile, would you be willing to fill in a feedback survey? It would help us improve next time and we'd appreciate it very much: https://aka.ms/hack-together-teams/survey.

@aycabas completed the survey 👌


Correction of tests on ellipsis/cram

Tests are not passing on my computer:
Indeed, the new tests using "echo" does not specify the flag -e which, AFAIK, are needed for the command to interpret most of the backslash escapes.
Did the tests pass on your computer @trefis ? I thought the "-e" option was common to every implementation of echo

That test wasn't passing for me, but it worked on travis so I assumed the problem was on my side.

Ok, so apparently, the implementation of echo on travis is not the same as mine (and I suppose yours).
I'm trying to remove it for printf, which, from what I rapidly checked, follows a more strict implementation according to POSIX standard

ex: https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo

Thanks!


Improvement: How to bind a layer modal to a button

The layers doc does not have any mention of how a layer/modal can be activated through a button or a list item.
Since,(like most) I've been in the react scene only for a short while, a quick 'how-to' would really be appreciated.
If required, I wouldn't mind contributing to the docs once I have an overview.
btw, really loving grommet.
Thanks,
<EMAIL_ADDRESS>

Quick how-to for anyone looking into this.

Place a variable that will render your layer inside your   .
e.g.:
<App> {activeLayer} </App>

maintain the state of the layer (initially false/undefined, so that the layer is not active)
e.g.:

constructor() {
    super();
    this._activate = this._activate.bind(this); //bind the correct `this`
    this._onClose = this._onClose.bind(this);
    this.state = { active: undefined }; //initial state is undefined, so the layer is not open
  }
//activation function
  _activate (){
    this.setState({active: true});
  }

The layer.

let activeLayer = null;
    if (this.state.active) {
      activeLayer = (
        <Layer onClose={this._onClose} closer={true}
        align="right">
        <Box>example</Box>
      </Layer>
      );
    }

The button (that activates your layer)

<Button plain={true} onClick={this._activate} />


ocamlPackages.js_of_ocaml-tyxml: init at 3.1.0

Motivation for this change
Needed to update eliom.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build ocamlPackages.js_of_ocaml-tyxml

Success on x86_64-linux (full log)
Attempted: ocamlPackages.js_of_ocaml-tyxml
Partial log (click to expand)
_build/install/default/doc/js_of_ocaml-tyxml/CHANGES => /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0/doc/js_of_ocaml-tyxml/CHANGES
post-installation fixup
moving /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0/doc to /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0/share/doc
shrinking RPATHs of ELF executables and libraries in /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0
shrinking /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0/lib/ocaml/4.05.0/site-lib/js_of_ocaml-tyxml/js_of_ocaml_tyxml.cmxs
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0/lib
patching script interpreter paths in /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0
checking for references to /tmp/nix-build-js_of_ocaml-tyxml-3.1.0.drv-0 in /nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0...
/nix/store/gk78r55cdpnbdygxbcbkdwmvhlc0i7p0-js_of_ocaml-tyxml-3.1.0

Failure on aarch64-linux (full log)
Attempted: ocamlPackages.js_of_ocaml-tyxml
Partial log (click to expand)
cannot build derivation '/nix/store/iq1ibing1scpfsaw7j2zh92whslk9b4f-js_of_ocaml-compiler-3.1.0.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/wwdj1k33qhfr9xx67c8zdmwp7lsn58ak-ocaml4.05.0-lwt-3.3.0.drv': 9 dependencies couldn't be built
cannot build derivation '/nix/store/nbwsi8sqpjn44pfm4skh2m7cmyv2d05d-ocaml4.05.0-reactiveData-0.2.1.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/f2plwch9wpsji8v1fj003y861i7jl2r4-ocaml4.05.0-uutf-1.0.1.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/h32vrfmam1dak3iy5qsq8lhn4qskkcih-js_of_ocaml-3.1.0.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/0zf3qp344vh50dxnx4500x9aj49yxw8w-ocaml4.05.0-markup-0.7.5.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/ka1h5fjwx8591kmr5ck5ivh6r73n6wa6-js_of_ocaml-ppx-3.1.0.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/fyn6hvfkmbjy774a7i346in87b6fa2m5-ocaml4.05.0-tyxml-4.2.0.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/j5ayf33kykaibyzqkw1kfw5vy463dlsv-js_of_ocaml-tyxml-3.1.0.drv': 10 dependencies couldn't be built
error: build of '/nix/store/j5ayf33kykaibyzqkw1kfw5vy463dlsv-js_of_ocaml-tyxml-3.1.0.drv' failed


Spike: Miners outsmarting our scoring process

This spike was created from the pre-mortem for going to mainnet.  We have already addressed this concern with our v1 scoring logic, which incorporates the concept of a "source of truth", instead of just checking JSON properties.  This PR implements an even better scoring logic, scoring miner responses specifically on how similar they are to said source of truth.  From my point of view, nothing more needs to be done w/ this spike, and we will constantly be monitoring the network for malicious behavior.

@grantdfoster agreed on this - @Luka-Loncar this can be closed

@grantdfoster agreed on this - @Luka-Loncar this can be closed


Training time

I couldn't find the training time in your paper.
From your training script, it seems you use 1 and 4 GPU for Llama 7b and 70b, respectively. May I ask what is the training time for Llama 7b and 70b on c4? What is your GPU type, A100 80G or 40G version?

Hi,
This is dependent on the task, but all experiments should fit within one A100 (80GB) GPU. I remember something like half a day for 7B models, and 5-6 days for 70B models. 7B models and (some?) 70B models (with small enough bits) could also fit within one A6000 (~48-49GB). I suspect 40GB should be fine especially for 7B models, though I don't think I have tried it.
We do support multi-GPU training, but that's mostly if you want to speed up the training.

Thank you for he details!


Validation: Duplicated alt text

This PR addresses the build validation issue - duplicate image alt text descriptions

Global effort to fix build validation errors
@Rick-Anderson
The Content & Learning team is fixing build validation errors on docs.microsoft.com for the rest of H2. This will eliminate potential accessibility, security, and usability issues. This PR includes only build validation fixes and does not change other content. Please review within five business days and merge or comment in the PR with any changes you'd like to see. Thank you!


Update Helm Chart: Refactored CI/CD and VCS Configurations

Dependencies Updated:

Updated the digest for prometheus dependency in Chart.lock.
Updated artemisVersion to 7.5.0 in values.yaml.

Template Updates:

Corrected casing for continuous integration values in _helpers.tpl.
Updated artemis-ci-configmap.yml with new continuous integration parameters.
Updated artemis-configmap.yml to include JWT for registry security.
Updated artemis-vcs-configmap.yml to support a more generic version control configurations.

Deployment Changes

Added resource definitions to activemq-broker, artemis-mysql.yml, and jhipster-registry configurable via values.yaml (Introduced resource requests and limits for artemis, database, registry, and broker.)
Removed redundant secret references in _artemis-deployment.yml and artemis-statefulset.yaml.

These changes incorporate configuration values of newer Artemis releases coming from the artemis ansible collection.

Also added the helm oci release


applyAutoTaggingRules.sh fails right after creating first rule

The script applyAutoTaggingRules.sh fails each time it is executed in the first if statement.
The problem is that the variable that is checked is indeed not 0 but in fact set to the tenant id.
Expected behaviour
It has to be checked if the curl is successful or not. The bug fix should also check if the rules are already created and should update them if already present.

First fix proposed here https://github.com/keptn/keptn/commit/0827aa0d51c2b537d2545e5693fe5fbff4adf76c does successfully create both rules but does not stop the installation if the rules are already there (won't be updated) or another issue occurs (e.g., the API token is not valid)


Add erb formatter support

Couldn't find any guidelines to contributing so my apologies if something is not handled properly.

Added matcher to match files ending in .erb to the _Erb language (which was unsupported before).
Adds support for erb-formatter to format _Erb files.

I decided to use _Erb as the language-id as Github does not seem to have an official title for the language, instead identifying it as HTML+ERB.

We could add all of these to language-id. It seems possible to tell them apart by filename extension. What Emacs modes do people use to edit ERB? I can't find an erb-mode. Does web-mode support it?

ERB is indeed supported by web-mode (which is also the major mode I am using when editing .html.erb files). As far as I am aware, erb-formatter only handles HTML files. Because of this I would suggest we only add support for HTML+ERB.  I'll update the matcher to be more selective based on the filename (.html.erb instead of just .erb) and update the language-id.

I've left two fixups (to make it clear what I've changed).  If you are okay with these changes I can rebase the PR to clean them up before we merge.

Format-all uses a separate library called language-id.el to determine what language is used in the buffer to be formatted. Only languages for which there isn't an official GitHub Linguist ID are special-cased in format-all.el as a necessary hack.
Since both HTML+ERB and JavaScript+ERB are official LInguist IDs, I added them directly to language-id.el and we don't have to add any special-case code to detect them in format-all itself.
Hence, the PR looks fine as it is, but can you remove the special-case (and (string-match-p ".erb\\'" buffer-file-name) "HTML+ERB")?

Hmm. We should probably refer to the formatter as erb-format since that's the name of the shell command used to run it. Seems clearer to me than erb-formatter which is the name of the Ruby module and gem. What do you think?

Agree, also seems more in line with the other formatters.  I've made the changes

Perfect. Thanks a lot for sticking with it!


Release Branch without git tag pushed

Just to keep it here to show the release process.
The branch will be rebased and pushed with git tag after all release target got in.

The release of 0.2.0 will happen on release branch, including bump version and tito tag(git tag).
The release branch will be merged back to master after the release is out.


Cache direction selection (horizontal/vertical radio buttons)

It would be awesome if you would cache these the same way you do it with the distance values. It's a huge time-saver, especially if you do multiple identical operations one after another.
(BTW this plugin is really amazing — I use it almost every day and it is my far my most used plugin in Sketch. Thanks!)

Thanks for that kind feedback! Of course the plugin should remember the direction between runs too. Now fixed!

Thanks! Amazing! :+1:

I just added so that you can repeat a distribution using the last settings for direction and spacing without bringing up the dialog. To not clutter peoples plugin menus too much the two ways to invoke distribution are now submenus to Distributor. While that puts it one more click away I have also added keyboard shortcuts. Shift + Control + D for bringing the dialog up, and Shift + Control + A for Distribute again. I hope it can save you some clicking. =)

Excellent! Thanks again! :)

The current version tries to improve the workflow some more by adding keyboard shortcuts for horizontal and vertical distribution, respectively. It also autofocuses on the spacing field. FYI. 😀


Game pauses for ~4 seconds when selecting mode

After the new customer graphics in #62, game load times increased significantly from about 1-2 seconds to about 4-5 seconds, and that's on my computer. On other computers this might be even slower.
This is most likely to adding all of the new textures. This problem will only get worse over time if we add more and more graphics for the different bugs. We should pursue different options for speeding this up:

Cache textures in a singleton so that they only load once on startup -- not every time a game starts
Or the other direction, load textures in the background instead of loading them all up-front
Make the textures faster to load; maybe instead of 1024x1024 images, we can scale them down to 256x256.
Maybe using a tool like "PNG crush" to shrink the PNGs could help. It's doubtful, but there's a chance that if they become indexed PNGs it'll clue Godot in that it can be more efficient with them.
Maybe GLES2 loads textures faster?
This is a pretty simple problem so others may have suggestions online. These people think disabling etc2comp could improve performance. These people wrote some sort of custom 'texture caching' thing. These people think having too many unique shaders takes time to compile.
Maybe tweaking some of our texture filtering options could improve performance too, such as mipmaps or 'lossy quality'. I'm not certain whether we rely on mipmaps.

Fixed in #65 , resources are now loaded in the background.


[storage] define statistics object

Signed-off-by: Boris Glimcher<EMAIL_ADDRESS>

@ekaley FYI

Not sure I understand why there are VolumeStats in the NVMe subsystem, controller and namespace objects. Are the stats for the subsystem an aggregate for all volumes/namespaces currently (or ever) attached to that subsystem, versus the namespace stats which are for this volume only ?

Not sure I understand why there are VolumeStats in the NVMe subsystem, controller and namespace objects. Are the stats for the subsystem an aggregate for all volumes/namespaces currently (or ever) attached to that subsystem, versus the namespace stats which are for this volume only ?

exactly, aggregate

I like this approach, where stats are associated clearly with the object itself at a given point in time i.e. it is clear and works for not so heavy stats users. I am commenting in context of OTEL as the method of exporting/streaming the stats.
To @llabordehpe's point it would good to document the desired behavior on the Volume stats in various objects where the object is embeded.

I like this approach, where stats are associated clearly with the object itself at a given point in time i.e. it is clear and works for not so heavy stats users. I am commenting vis-a-vis OTEL as the method of exporting/streaming the stats.

Good topic to discuss, how exactly we want to stream telems from OTEL perspective. I would imagine we should compile DPU SDK with OTEL SDK and stream directly. So what we can do in OPI is to define the OTEL format and telems needed streaming...

To @llabordehpe's point it would good to document the desired behavior on the Volume stats in various objects where the object is embeded.

Agree 100%, documentation is lacking.


Travis nighly releases

The goal of this PR is to use travis to create nightly builds.

The tar.bz2 and deb packages are now uploaded:
https://github.com/omichel/webots/releases/tag/untagged-8b21df2afa53a2c1053a
And the dmg too:
https://github.com/omichel/webots/releases/tag/untagged-c244afc1af1c014ff764
The main remaining problem is to group them in the same release.

Apparently to group the mac and ubuntu release we have to use stages: https://github.com/travis-ci/travis-ci/issues/10230#issuecomment-442197942

The release is now working fine from travis (I can create a release and upload the package from different jobs in the same release). But the creation of the package on mac is still failing very often:
# creating webots.mac version R2019b: done
# done for darwin
/dev/disk2          	GUID_partition_scheme
/dev/disk2s1        	EFI
/dev/disk2s2        	Apple_HFS                      	/Volumes/Webots
created: /Users/travis/build/omichel/webots/distribution/webots.dmg
81:130: execution error: Finder got an error: AppleEvent timed out. (-1712)
hdiutil: detach: timeout for DiskArbitration expired
hdiutil: detach: drive not detached
hdiutil: convert failed - Resource temporarily unavailable
# distribution compiled in 0:33:01

I will try to check if I can reproduce this locally in a docker.

Migrate to fork to not overload tests.


feat: introduce CacheClient.cache function to curry cache name across API calls

This commit introduces a new function, CacheClient.cache. If you call
it, you will get back an instance of a new type, MomentoCache. This
object has all of the same APIs that are available on the CacheClient,
but it curries the cacheName so that you no longer have to specify that
on every API call.

Going to try to add another commit to this to do the reflection-based unit test validation that the cache interface is in sync with the CacheClient, but this is ready for review.


Vite support?

Hello!
I'm having a lot of problems getting this to run in Vue3 and Vite. This is the error message:

Any help would be greatly appreciated!

Hi, thank you for your message.
Vite + Vue3 plus our plugin works fine as you can see here in the default vite app:

Maybe you can provide more information about your setup, so we can investigate further.
Thanks!

Thanks for the response!
I am using microfrontends (single SPA) specifically this plugin:
https://github.com/single-spa/single-spa-vue
systemjs is also loaded which might interfere, especially this systemjs plugin (which I also use): https://github.com/systemjs/systemjs/blob/main/dist/extras/amd.js

Would it be possible to get access to your repo so we can run it locally? Or a stripped down version of it? This would make reproducing the error much easier

https://stackblitz.com/edit/vitejs-vite-p6wcgi?file=src%2Fmain.ts

We confirm that systemjs is the issue. We will update Smart Pixel to support systemjs, this is planned to happen this month. Once the update is live I will let you know here, so you can update your node modules. Our Vue plugin is basically just a wrapper for Smart Pixel you have to know, and it installs it as a dependency.
Until the update release here is a hack that you can use in your dev environment, so you can continue before the fix arrives.
In your node_modules folder, you edit the following files:
<EMAIL_ADDRESS><EMAIL_ADDRESS>search for
"function"===typeof define&&define.amd
and replace it with
false
Then rebuild.
Of course that won't be the exact fix we will apply, but it should work for your dev environment.


AppMan: Updated Solarized theme to 1.1 (matches FD 5.1).

You didn't update the MD5, the install will fail if it doesn't match.

My bad, updated the MD5 now.


[Suggestion] Add the newest animations or anything new in the files

I saw new animations in other peoples videos, and the new anims actually look cool so can you add, just a suggestion.

Here

not that


Revert protobuf compilation changes

Revert back to 4.24.3 compilations.
Addressed massive headaches with the RuntimeVersion checks includes in compilations from protobuf 5.27 onwards.  Will address https://github.com/home-assistant/core/pull/124936#issuecomment-2379040337

coverage: 79.595% (-0.3%) from 79.915%
when pulling d10a9b3334f35e786c20767f41233df1169d9a4a on fix/revert_protobuf
into 2a643dc378798c13ad70d3177266cc052a36964c on main.


i Would love to have the function to open webpages in side of Fenrus.

I think you may be looking for causefx/Organizr.

done


[release-v1.5.1][BACKPORT]: fix: Can not specify custom Packer directory #559

What problem does this PR solve?:
Backports https://github.com/mesosphere/konvoy-image-builder/pull/559 to release-v1.5.1

@dkoshkin , @faiq please verify if the release branch is correct. Also should we need to bump the patch version manually for old release branch?

The base branch should be release-1.5 which is the convention for all of the other release branches

checked that the failed builds builds are not related with the fix (GCP, azure, vsphere were not implemented).
The related builds passed successfully.

The base branch should be release-1.5 which is the convention for all of the other release branches

[release-v1.5.1](https://github.com/mesosphere/konvoy-image-builder/tree/release-v1.5.1) existed from before (idk why)
@supershal please create a release-1.5 branched from current release-v1.5.1 branch and change the base branch.


Adjust Vulkan queue selection and creation logic

The queue selection logic rewrite addresses a bug in the old
implementation where the code would pass an invalid queue index when
selecting any queues other than number 0.
The queue priority has been changed to the lowest value as it doesn't
make sense to prioritize this workload over e.g. graphics workload.
The new implementation will attempt to use compute-only queues which
are common on AMD GPUs. It's not clear how much difference will this
make but hopefully it would lead to better scheduling.

The priority changes were primary made due to that the old
implementation causing my system to hang, stutter or otherwise become
unstable and crash. After the change I'm able to run autotvm tuning
inside a desktop environment. While it might be good to minimize the
variance of execution time for autotvm, it doesn't worth it when it causes
system instability as described above.
r? @tqchen

Thanks @ishitatsuyuki .
I think it would be good to flesh out the queue priority further, since on certain desktops (e.g. Nvidia) having a high queue priority works fine. It would be great to confirm the impact of different queue priority on the performance, and whether we should set something between 0 and 1. Ideally, we want good amount of compute without starving graphics.
I would recommend do some experiment of values between 0 and 1, we can further enable making the TVM_VK_QUEUE_PRIORITY as an env variable to adjust the value. Let us focus on other changes
cc @tmoreau89 @ajtulloch

Digging a bit further on the information, I could not find a lot of useful infos about the queue priority assignment,
Here is one guideline for adreno. Stating that
On Adreno, there are 3 values that are internally used (0.0,0.5,1.0). It’s important to note that these priorities are relative to all processes running on the device. In general, you should use a 1.0 priority, except with VR applications where you should choose a 0.5 value so that VR services running on the device needed for predicable display purposes can have higher priority
```.

My reading of the statement seems to be 1.0 should be encouraged until a point where graphics is affected. I would encourage us to do a bit more experiments, and enable ```TVM_VK_QUEUE_PRIORITY``` as a part of env variable, but keep the default in 1.0 for now.

Also https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkQueueGlobalPriorityEXT.html might be more relevant, since our main goal is to set the queue priority to be the same as the system default.

After a bit of research it seems that no implementation in Mesa actually respects pQueuePriorities; therefore I have reverted that part of the change. We might want to revisit this in the future.
As for VkQueueGlobalPriorityEXT, it's mostly meant for real-time use cases that requires GPU preemption, e.g. compositors, and requires process privileges for any higher-than-normal priority settings. Since most TVM workload is non-interactive, it's better to just not use it, or even if we use it, we would set the priority to LOW.

@tqchen I think I've addressed all comments for now, can you remove the "need update" label?

Thanks @ishitatsuyuki , I made some followup comments

I have restored the previous behavior where the device was created with all queue families we could discover (I don't think this behavior is necessary nor correct though).
Also I've opted for vector<uint32_t> return type for GetComputeQueueFamilies, as VkDeviceQueueCreateInfo contains pointers that could cause lifetime complications when used in return type.

Thanks @ishitatsuyuki !


Link ComputeStatistics method to WdStatistic enum

Method articles are more useful with quick links to parameter enumerations. Please add more links to the documentation.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

VBA/Word-VBA/articles/range-computestatistics-method-word.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.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

VBA/Word-VBA/articles/range-computestatistics-method-word.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.