[FR]: Migrate Vertex to use GULLogger

Description
Currently logs from Vertex are tagged with [GoogleGenerativeAI] and appear out of sync with other Firebase related logs. E.g. in the simulator I was able to get a server response before 10.26.0 - [FirebaseCore][I-COR000001] Configuring the default app. appeared.
API Proposal
No response
Firebase Product(s)
Vertex AI

Just fyi we changed the tags to [FirebaseVertexAI] in https://github.com/firebase/firebase-ios-sdk/pull/12933 (haven't migrated to Firebase/GULLogger yet though).

This migration is now merged into main (https://github.com/firebase/firebase-ios-sdk/commit/7bb68adb8532a07901209820c7e0955a8469980b).


Add support for all org.apache.shardingsphere:shardingsphere-db-protocol:5.3.1 submodule

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

No.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Add support for org.apache.shardingsphere:shardingsphere-db-protocol-core:5.3.1.
Add support for org.apache.shardingsphere:shardingsphere-mysql-protocol:5.3.1.
Add support for org.apache.shardingsphere:shardingsphere-postgresql-protocol:5.3.1.
Add support for org.apache.shardingsphere:shardingsphere-opengauss-protocol:5.3.1.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Null.

Additional context
Add any other context or screenshots about the feature request here.

Metadata generated at https://github.com/linghengqian/graalvm-trace-metadata-smoketest/issues/1 .

Linkes to https://github.com/apache/shardingsphere/issues/21347 .

I'm working on this issue.

Fixed by https://github.com/apache/shardingsphere/pull/29000.


Exceptions coming from Futures with 'weird' chars are breaking JS response

Closed via https://github.com/joescii/lift-ng/pull/21


Change default port for udp tracing

For udp tracing, by default Trippy uses a fixed src port which is set from the process id and a variable dest port which is set from the sequence number, starting from 33000 and incremented for each probe, eventually wrapping at 64511 (which is u16::MAX - 2x the maximum sequence per round, gives 65535 - (512 * 2) = 64511).
By convention, many devices on the internet allow probes to ports in the range (33434..=33534) and will return an DestinationUnreachable ICMP error which can be used by traceroute to confirm that the target has ben reached.
Therefore, given Trippy does not by default use dest ports in this range for udp probes, they do not respond with any ICMP error and so Trippy cannot see that the target was reached and must therefore show the hop as unknown.
The options here are:

Do nothing.  Users can change the udp port direction and/or the initial sequence number if they wish, but this assumes that users are aware of the situation and understand how and why to correct it.  This typically makes Trippy look "broken" as compared to the default behaviour of other traceroute tools.
Change the default udp behaviour to be a fixed dest port (in the range above) and a variable src port.  Note that this is the current default behaviour for tcp.  This differs from the behaviour of other traceroute implementation for udp and is a breaking change for Trippy.
Change the initial sequence (for udp, or perhaps for everything) to be 33434 and ensure the sequence number wraps at 33534.  This is problematic as the "window" is only 100 ports wide, which is less than the theoretically max ttl (255) and also invalidates several constraints the tracing strategy currently upholds, such as ensuring that (i) 2x the number of sequence numbers can be used per-round to account for probe re-issues and (ii) sequence numbers will not be reused within two round to avoid long delayed-packets being incorrectly associated with the wrong round.

Note: a probe "re-issue" occurs when a probe cannot be dispatched as the socket cannot be bound to a given local socket address, typically as the port is already in use.  In such cases Trippy will "skip" the problematic port and "re-issue" the probe with the next sequence number.  In reality this is only an issue for tcp probes (which use variable src ports that must be bound to the socket) but may also effect udp for non-raw mode.

This causes another long standing issue, where the trace can be seen to "jump" suddenly to a large ttl and then revert to a lower ttl with (greyed out) higher ttl responses.
For example, a trace trip <IP_ADDRESS> --udp may initially show:
Hops─────────────────────────────────────────────────────────────────────────╮
│#    Host                                             Snd     Sts     Dprt   │
│1    <IP_ADDRESS>                                      5       🟢      33112  │
│2    <IP_ADDRESS>                                   5       🟢      33113  │
│3    <IP_ADDRESS>                                   5       🟢      33114  │
│4    <IP_ADDRESS>                                     5       🟢      33115  │
│5    <IP_ADDRESS>                                   5       🟢      33116  │
│6    No response                                      5       🔴      33117  │

The target <IP_ADDRESS> initially ignores all probes as the dest port (set from the sequence number) is out side the range 33434..=33534 and show Trippy shows "No response" for hop 6.
As the trace progresses, the sequence number (and therefore dest port) will eventually enter the range 33434..=33534 and so the target <IP_ADDRESS> will return DestinationUnreachable ICMP responses.
The result is output such as the following:
╭Hops─────────────────────────────────────────────────────────────────────────╮
│#    Host                                             Snd     Sts     Dprt   │
│1    <IP_ADDRESS>                                      16      🟢      33420  │
│2    <IP_ADDRESS>                                   16      🟢      33421  │
│3    <IP_ADDRESS>                                   16      🔵      33422  │
│4    <IP_ADDRESS>                                     16      🟢      33423  │
│5    <IP_ADDRESS>                                   16      🟢      33424  │
│6    No response                                      16      🟤      33425  │
│7    No response                                      16      🟤      33426  │
│8    No response                                      16      🟤      33427  │
│9    No response                                      16      🟤      33428  │
│10   No response                                      16      🟤      33429  │
│11   No response                                      16      🟤      33430  │
│12   No response                                      16      🟤      33431  │
│13   No response                                      16      🟤      33432  │
│14   No response                                      16      🟤      33433  │
│15   <IP_ADDRESS>                                          16      🟡      33434  │

Whilst we would expect the DestinationUnreachable ICMP response to come for the probe with ttl=6, it actually comes from the probe with ttl=15 as that is the first probe with a dest port (33434) in the range that will trigger an DestinationUnreachable ICMP response from the target.  Note that Trippy operates a sliding windows probing protocol and sends multiple probes in parallel (with increasing ttl values) up to a configured miximim window size.
Eventually the sequence number (and therefore dest port) will move beyond the range and therefore the output becomes (with hops 7 though 15 are greyed out):
╭Hops─────────────────────────────────────────────────────────────────────────╮
│#    Host                                             Snd     Sts     Dprt   │
│1    <IP_ADDRESS>                                      17      🟢      33435  │
│2    <IP_ADDRESS>                                   17      🟢      33436  │
│3    <IP_ADDRESS>                                   17      🟢      33437  │
│4    <IP_ADDRESS>                                     17      🟢      33438  │
│5    <IP_ADDRESS>                                   17      🟢      33439  │
│6    <IP_ADDRESS>                                          17      🔵      33440  │
│7    <IP_ADDRESS>                                          17      🔵      33441  │
│8    No response                                      16      🟤      33427  │
│9    No response                                      16      🟤      33428  │
│10   No response                                      16      🟤      33429  │
│11   No response                                      16      🟤      33430  │
│12   No response                                      16      🟤      33431  │
│13   No response                                      16      🟤      33432  │
│14   No response                                      16      🟤      33433  │
│15   <IP_ADDRESS>                                          16      🟡      33434  │

This is highly confusing to users.

The simple solution is to change the initial sequence to be 33434, which in turn means the dest port for UDP tracing will be 33434.  Note that there is no change in the wrapping behaviour.
This solution in not perfect but is an improvement on the current situation in that:

UDP tracing will discover the target hop from the first round more often
UDP tracing will more often avoid the "jump" behaviour describe above which only occurs when tracing begins out of range and then enter the range not the other way around.

The sole downside is that, once the sequence number (dest port) moves beyond the range (33534 or greater) then the target hop will show "fake" packet loss.  Technically this is not wrong, as the target does stop responding to probes, but it may confuse users into believing there is a problem when there is not.


Android-Kotlin : 16.02 Coroutines vs Thread in android.

Description :scroll:

Give a step-by-step tutorial in Kotlin along with a brief and clear explanation.
Required Documentation or Video or Audio.

Domain of Contribution :bar_chart:

[x] Android Dev (kotlin)

References :

https://piotrminkowski.com/2020/06/23/kotlin-coroutines-vs-java-threads/

Please Read it Carefully Before Contributing

The file structure should look like Android_Development_With_Kotlin  -> 16 Threading -> <file name>.
You have to push your PR to the Android_Development_With_Kotlin branch only.
You can take help to the references but don't simply try to copy it. Just explain in your own word.
Your code should be written only in Kotlin.
This issue is for GWOC'21 contributors only.
You need to push in a single commit. If there exists more than one commit then you need to squash your commits into one commit.
Will assign you on a first come first serve basis.
Please try to complete your assigned task within 7 days. If you need some more time then, please inform mentors and supervisors.
If you have two previously assigned issues on Android-Kotlin pending then please first complete them.

Supervisor @rahulsain

Happy Contributing. Best of Luck.:sparkling_heart:

/assign

Any update? @amaan118921

yes, making pr today, for all of my pending issues..

yes, making pr today, for all of my pending issues..

Ok just make PR for each issue and mentioned that issue, no need to ask me for reaasign for those issues. I will simply check your PR


Allow selection of PIDs/Objects to migrate with to new selectors

ResumePidList

Allows resuming the migration from the point of the last successfully migration F3 object

UserProvidedPidList

Allows for user to provide a list of PIDs to migrate

Resolves:
https://jira.duraspace.org/browse/FCREPO-3111 , and
https://jira.duraspace.org/browse/FCREPO-3112
What's new?
Two new "PidListManagers" have been created. They can be configured in the spring.xml as follows:
    <bean id="migrator" class="org.fcrepo.migration.Migrator">
        <property name="source" ref="${migration.layout:exported}" />
        <property name="handler" ref="objectAbstraction" />
        <property name="limit" value="${migration.limit:2}" />
        <!--PID List Managers help in selecting which source objects to migration, default is ALL-->
        <property name="pidListManagers">
            <list>
                <bean class="org.fcrepo.migration.pidlist.UserProvidedPidListManager">
                    <constructor-arg name="pidListFile" value="${migration.pid.list.file:#{null}}"/>
                </bean>
                <bean class="org.fcrepo.migration.pidlist.ResumePidListManager">
                    <constructor-arg name="pidDir" value="${migration.pid.resume.dir:target/test/pid}"/>
                    <constructor-arg name="acceptAll" value="${migration.pid.resume.all:true}"/>
                </bean>
            </list>
        </property>
    </bean>

The idea is that these two "PidListManagers" will be executed in order, each being asked if they "accept" the provided PID. If either of the managers do not "accept" the PID, the PID will not be processed.
The UserProvidedPidListManager takes a file of line-separated PIDs to process. If no file is provided, all PIDs are accepted.
The ResumePidListManager keeps track of the PID and index of the last processed object. If acceptAll is true, this state of "last processed object" is maintained, but all PIDs are "accepted". However, if acceptAll is false, any PIDs that come before the PID/index found in the state file, will not be processed. Note, this assumes a deterministic, repeatable order of source PIDs.
How should this be tested?
Besides the unit and integration tests provided in this pull-request, testing should involve:

Configuring the spring.xml with one, both or none of the "PidListManagers"
Run, kill and re-run the tool, to test the "resume" functionality
Create a pid-list to test the pid-list functionality

Interested parties
@fcrepo4/committers

@pwinckles : what do you mean by "stable"?

@pwinckles : what do you mean by "stable"?

In order for the resume functionality to work the input PID list for each attempt needs to be the same. How likely is this to be the case?

@pwinckles : The idea of the PID-list is for users to migrate specific sets of F3 objects. This is a somewhat surgical, hands-on approach. Resume is technically possible with PID-lists, but also depends on the order of the PIDs in the list being the same order as the source iteration. My suspicion is that Resume over PID-list is an edge-case, and one that a hands-on user will be able to navigate.


how to train sinet?

thank you for your contribution. can you upload your sinet train code or would you tell me how to train SINet

Please refer the original repository: https://github.com/clovaai/ext_portrait_segmentation

The model effect obtained by the training according to the sinet source code is very poor. Do you have any tricks?


Fix ++spin/++spun

Currently, you can't get the changed state out of these, which was a major oversight. This changes ++spin so that it returns a {(list _-:(b)) _c} (that is, a list of returned values and the new state) and ++spun so that it just results a (list _-:(b)), for when you only need a stateful accumulator.
(I don't know if there is procedure for changing stdlib functions, but these are relatively unused...)

It is that way on purpose, making this more of a new function. I don't think the value needs to be produced with the sort of things this was meant for, but maybe I'm wrong.

They look like they're supposed to be a special case of roll for mutating
elements, yeah.
(Also I'm curious what the platonically correct form of line 476 is; the
commented out type assert is a bit obscure, especially since in this case
the assert seems to be going the wrong way, but I'm pretty sure I get the
author's documentational intent. Ideally we could just have "$- except with
a readable sample", and then all then list, parser, etc higher-order
gate samples could be a lot clearer?)
(in particular it would be super clarifying to be able to phrase wet gates
as "use the wet sample to compute a monomorphized dry inner gate, and
invoke that", beyond just using |- because there's no good way to phrase
"cast to gate bivariant on only its +>")
On Wednesday, 17 May 2017, Raymond Pasco<EMAIL_ADDRESS>wrote:

It is that way on purpose, making this more of a new function. I don't
think the value needs to be produced with the sort of things this was meant
for, but maybe I'm wrong.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302036694, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhoe5NAS2fjXsHvZRrbuzW5yeo4lCks5r6r2fgaJpZM4M5XpO
.

Spin/spun were designed as a "stateful turn" - you give it a piece of data that it forwards through the turn. Reel/roll, but instead of returning the accumulator it returns the elements. One of the usecases I had for this when I first wrote it was to forward an ++og instance, to generate a list of random numbers. Hand-rolling code to repeatably call a state machine is pretty annoying otherwise. Currently, you can do this, but then you can't continue to use the rng afterwards since it is still in the state before you called spin/spun. I consider that it's only a problem with ++spin, since that is the one that you provide an explicit instance for.
I have used these functions a few times myself (and am the original author, but I don't think that should actually matter), but I think it makes more sense for spin to also return the bookkeeping data for continuation of data after the function call.
The type hint is bad, yeah. It actually crashes urbit if you try to uncomment it, iirc, but I'm not sure how to do it otherwise unless you use currying so you can use the type of a and c - if you want to write something like |*  {a/* b/(list _a)} ... for example, then you're kinda screwed. Gates just make it worse, since you can't cast them correctly afterwards (could you use ?^, actually?)

"Crashes urbit"?  You mean, the compile fails?
Yes, I think the right way to do this kind of wet gate involves more
currying.  Ultimately I think we'd like a list core that works more like
++in and ++by.  It is hard to look at Hoon today and realize that the
reason ++turn and ++by are so different is that the former is considerably
older than the latter.  Prehistory shouldn't matter this much.
I think my only objection to this patch is that it should come with a lot
more documentation.  It's in an old, poorly documented part of hoon.hoon,
so clear, well-documented code would stick out like a sore thumb.  All the
better... it's the rest of the hand that's sore.
On Wed, May 17, 2017 at 10:26 AM, chc4<EMAIL_ADDRESS>wrote:

Spin/spun were designed as a "stateful turn" - you give it a piece of data
that it forwards through the turn. Reel/roll, but instead of returning the
accumulator it returns the elements. One of the usecases I had for this
when I first wrote it was to forward an ++og instance, to generate a list
of random numbers. Hand-rolling code to repeatably call a state machine is
pretty annoying otherwise. Currently, you can do this, but then you can't
continue to use the rng afterwards since it is still in the state before
you called spin/spun. I consider that it's only a problem with ++spin,
since that is the one that you provide an explicit instance for.
I have used these functions a few times myself (and am the original
author, but I don't think that should actually matter), but I think it
makes more sense for spin to also return the bookkeeping data for
continuation of data after the function call.
The type hint is bad, yeah. It actually crashes urbit if you try to
uncomment it, iirc, but I'm not sure how to do it otherwise unless you use
currying so you can use the type of a and c - if you want to write
something like |* {a/* b/(list _a)} ... for example, then you're kinda
screwed. Gates just make it worse, since you can't cast them correctly
afterwards (could you use ?^, actually?)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302164675, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALyASEOv63pMjd2Py3J2gTZHQOVeMH2ks5r6y2rgaJpZM4M5XpO
.

The code is also older because lists are considerably more frequent than
maps, and it's obvious which of (roll (turn "abc" dec) add) and ((~(rep ly (~(run ly "abc") dec)) add) is easier to write, read, and follow.
On Wed, May 17, 2017 at 12:53 PM, cgyarvin<EMAIL_ADDRESS>wrote:

"Crashes urbit"? You mean, the compile fails?
Yes, I think the right way to do this kind of wet gate involves more
currying. Ultimately I think we'd like a list core that works more like
++in and ++by. It is hard to look at Hoon today and realize that the
reason ++turn and ++by are so different is that the former is considerably
older than the latter. Prehistory shouldn't matter this much.
I think my only objection to this patch is that it should come with a lot
more documentation. It's in an old, poorly documented part of hoon.hoon,
so clear, well-documented code would stick out like a sore thumb. All the
better... it's the rest of the hand that's sore.
On Wed, May 17, 2017 at 10:26 AM, chc4<EMAIL_ADDRESS>wrote:

Spin/spun were designed as a "stateful turn" - you give it a piece of
data
that it forwards through the turn. Reel/roll, but instead of returning
the
accumulator it returns the elements. One of the usecases I had for this
when I first wrote it was to forward an ++og instance, to generate a list
of random numbers. Hand-rolling code to repeatably call a state machine
is
pretty annoying otherwise. Currently, you can do this, but then you can't
continue to use the rng afterwards since it is still in the state before
you called spin/spun. I consider that it's only a problem with ++spin,
since that is the one that you provide an explicit instance for.
I have used these functions a few times myself (and am the original
author, but I don't think that should actually matter), but I think it
makes more sense for spin to also return the bookkeeping data for
continuation of data after the function call.
The type hint is bad, yeah. It actually crashes urbit if you try to
uncomment it, iirc, but I'm not sure how to do it otherwise unless you
use
currying so you can use the type of a and c - if you want to write
something like |* {a/* b/(list _a)} ... for example, then you're kinda
screwed. Gates just make it worse, since you can't cast them correctly
afterwards (could you use ?^, actually?)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302164675, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALyASEOv63pMjd2Py3J2gTZHQOVeMH2ks5r6y2rgaJpZM4M5XpO>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302213455, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhoLqI_SHoVZqGlYyYxyJp_u2vCWNks5r61BGgaJpZM4M5XpO
.

All this is true, Anton.  I'm still not satisfied with it though.
On Wed, May 17, 2017 at 1:05 PM, Anton Dyudin<EMAIL_ADDRESS>wrote:

The code is also older because lists are considerably more frequent than
maps, and it's obvious which of (roll (turn "abc" dec) add) and ((~(rep ly (~(run ly "abc") dec)) add) is easier to write, read, and follow.
On Wed, May 17, 2017 at 12:53 PM, cgyarvin<EMAIL_ADDRESS>wrote:

"Crashes urbit"? You mean, the compile fails?
Yes, I think the right way to do this kind of wet gate involves more
currying. Ultimately I think we'd like a list core that works more like
++in and ++by. It is hard to look at Hoon today and realize that the
reason ++turn and ++by are so different is that the former is
considerably
older than the latter. Prehistory shouldn't matter this much.
I think my only objection to this patch is that it should come with a lot
more documentation. It's in an old, poorly documented part of hoon.hoon,
so clear, well-documented code would stick out like a sore thumb. All the
better... it's the rest of the hand that's sore.
On Wed, May 17, 2017 at 10:26 AM, chc4<EMAIL_ADDRESS>wrote:

Spin/spun were designed as a "stateful turn" - you give it a piece of
data
that it forwards through the turn. Reel/roll, but instead of returning
the
accumulator it returns the elements. One of the usecases I had for this
when I first wrote it was to forward an ++og instance, to generate a
list
of random numbers. Hand-rolling code to repeatably call a state machine
is
pretty annoying otherwise. Currently, you can do this, but then you
can't
continue to use the rng afterwards since it is still in the state
before
you called spin/spun. I consider that it's only a problem with ++spin,
since that is the one that you provide an explicit instance for.
I have used these functions a few times myself (and am the original
author, but I don't think that should actually matter), but I think it
makes more sense for spin to also return the bookkeeping data for
continuation of data after the function call.
The type hint is bad, yeah. It actually crashes urbit if you try to
uncomment it, iirc, but I'm not sure how to do it otherwise unless you
use
currying so you can use the type of a and c - if you want to write
something like |* {a/* b/(list _a)} ... for example, then you're kinda
screwed. Gates just make it worse, since you can't cast them correctly
afterwards (could you use ?^, actually?)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302164675, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALyASEOv63pMjd2Py3J2gTZHQOVeMH2ks5r6y2rgaJpZM4M5XpO>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302213455, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABxXhoLqI_
SHoVZqGlYyYxyJp_u2vCWNks5r61BGgaJpZM4M5XpO>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302216421, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALyAXZ1B9K-xmaxAME57Xje3AzNJLXIks5r61McgaJpZM4M5XpO
.

I think the syntax I proposed last time this came up was something like (run~ly "abc" dec), though having ~foo appear outside of a coin literal seems iffy

No, I'm it actually crashes vere with the type hint. I don't remember the actual error code, however. The same thing happened a week ago when I tried to fish a gate type, so I assume it's still a problem.
It's a shame cores are a bit unwieldy, or else you could do something like abet:(roll add):(turn dec):(toly "abc") - which would probably have terrible performance and you can't store the raw ++ly in app state or a map without the kernel going out of date.
By add docs, do you mean adding a section to the docs repo for this? None of the stdlib uses the vane-style headers, so it would look extremely odd...

Can you put together a reproduction case?  I could but it sounds like it'd
be easier for you.  I don't like to let crashes fall through the cracks.
Yes, I mean documenting it inline using the latest fashions.  I don't care
if it looks extremely odd.
On Wed, May 17, 2017 at 6:07 PM, chc4<EMAIL_ADDRESS>wrote:

No, I'm it actually crashes vere with the type hint. I don't remember the
actual error code, however. The same thing happened a week ago when I tried
to fish a gate type, so I assume it's still a problem.
It's a shame cores are a bit unwieldy, or else you could do something like abet:(roll
add):(turn dec):(toly "abc") - which would probably have terrible
performance and you can't store the raw ++ly in app state or a map without
the kernel going out of date.
By add docs, do you mean adding a section to the docs repo for this? None
of the stdlib uses the vane-style headers, so it would look extremely odd...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/385#issuecomment-302272441, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALyAf9zg2e0R2_txsnl8YXfL3aP-U8tks5r65nPgaJpZM4M5XpO
.

This needs to be looked at again with the new repainting model.  Postponing it once more, sadly.

Do we still want this in? If yes, this needs to be looked at again as mentioned above.

Status?

Oops, nevermind, didn't see #649 above.


✅enable to run unit tests in .NET 472

This enables to run unit test in .Net 472.
It also fixes one issue when using .Net472 - we found it when following the steps from the Readme.MD

Notice that build on linux only run for net80

While for windows, you would see:
Failed!  - Failed:    29, Passed:   160, Skipped:     2, Total:   191, Duration: 734 ms - Wasmtime.Tests.dll (net472)
Failed!  - Failed:    19, Passed:    80, Skipped:     0, Total:    99, Duration: 278 ms - Wasmtime.Tests.dll (net8.0)

@fforjan could you rebase this PR? I will take a closer look afterwards

@jsturtevant should be good now

@jsturtevant  let me know if you would like me to do anything


bug - dragging activating when using file element outside of draggable div, despite disabled being set to true dynamically in the draggable div

I have a div that contains an input element of type file:

I trigger a click event on that "addimg" input element to allow the user to load an image from device.
The "addimg" input element  is located outside a draggable large div, like this:
<Draggable onDrag={handleDrag} {...activeDrag} {...dragHandlers} >...</Draggable>

<input id="addImg" type="file" onChange={onFileChange} />

So the input element is outside the draggable large div
the problem is that when addImg is triggered, and the devices's dialogue opens to load an image, whatever you do, load or not load an image, when returning from that dialogue, the large div begins to drag automatically
Even setting its disable to true programmatically at the beginning of the click trigger event doesnt help,
it just comes alive when returning from the load file dialogue of the OS
how can I prevent this, as it interferes completely with the functionality I need
thank you :)

interestingly:

if i set draggable div with disabled:true from the beginning, then of course the problem doesnt happen, but I cannot drag the div either
if at the beginning the draggable div has disabled:false, and when user double clicks on background, I set disabled:true in draggable div right before I trigger the click event on input element, the problem happens! it is as if there was something in the actual device file select dialogue that brings to life the dragging behaviour despite me setting disabled to true right before the dialogue opens

I have verified that I am switching disabled to true right through the process before and during the file dialog and yet the draggable component still becomes draggable somehow

Important update:
the problem happens when triggering a click on the input file element:
document.getElementById('addImg').click()
If i click directly on the input file element, the problem doesnt happen, the large div doesnt become draggable
Somehow it is the use of the remote dynamic triggering with document.getElementById('addImg').click() in combination with an input file element that creates the problem
The thing is that I need to activate it remotely programmatically in my app

I have just verified that the "drag" event is indeed activated in the draggable component when triggering dynamically programmatically an input file element, seems like a bug to me

the problem also happens with mouse events, not with touch events, somehow with the mouse after returning from the input file dialog, the dragging event just keeps firing

cant manage to prevent it, somehow entering into the file type dialog makes the draggable component believe that the signal to start dragging has been given

For anyone get this bug, you should stop event propagation when click the element stackoverflow


Remove Stapler dependency on Prototype or jQuery

This PR eliminates Stapler's dependencies on any JavaScript frameworks in favor of the Fetch API. Previously it supported either jQuery or Prototype, although the jQuery code path was dead code and would never have worked with Jenkins anyway. This PR rips out all this code in favor of native JavaScript. Core will require a very minor adaptation to deal with this change; see https://github.com/jenkinsci/jenkins/pull/7805.
To test this I ran this repository's test and core's tests. I also did manual interactive testing of the Configure Project page and the Build History page, which exercised both of the use cases of bind.js: the JSON use case and the HTML use case. In each use case I stepped through the code before and after in the debugger to verify it was working the same way with this PR. More detail in the self-review. Once I get an incremental I plan on running this through BOM as well.

Causes JENKINS-71236.


[IOS] [Android] three way Dark mode button

Add an option for a three Way dark mode button!

Dark mode forced to turn on
2.(middle button) Will get the automatic dark mode from the system settings
Dark mode forced to turn off

This feature would be an great improvement!

Sure, I need to check wether we can get this information from the system!

I want to try this out myself but currently im not able to start this project in IntelliJ without any problems.
Can you recommend an IDE for .dart and flutter?

I use IntelliJ IDEA Ultimate! But I needed Android Studio for Android development. XCode is required for iOS development

I use IntelliJ IDEA Ultimate! But I needed Android Studio for Android development. XCode is required for iOS development

Oh perfect thanks so now I know that i’m on the right way with IntelliJ

I think it would be easier to initially load the system theme instead of changing the UI.
@iMonZ Are you currently working on this, otherwise I will plan this for the next release (v0.3.0).

I think it would be easier to initially load the system theme instead of changing the UI.
@iMonZ Are you currently working on this, otherwise I will plan this for the next release (v0.3.0).

I’m sorry but I'm not working on it!
Currently I'm into a few dart books to understand it better.

No problem! Then I will plan it for 0.3.0!


improve ui header

Pull Request Template

Please provide all of the details below. Pull requests missing any of the information below will be closed!

Sumarise what this PR fixes: < this PR is to improve the header UI of Keiko Corp >

Fixes #: < #107 >
Checklist:
(Add an x between the brackets to check the items)

[x] I have sumarised what this PR fixes above
[x] I have provided the issue ID/URL above
[x] This PR fixes only the issue mentioned above (create seperate PRs for seperate issues)
[x] I was the first one to claim the issue or I created the issue

Looks much better!


Gardevoir Hunt Quest Text Error

After Finding the statue in Kuanti the dialogue from the statue tells you to head to Skadi, when it's meant to be Ione. Meanwhile after finding the statue in Ione the dialogue tells you to head to Ione.
The Quest book has the correct locations, but the statues dialogue is messed around.

This issue has been fixed.


Re-name the 'Upcoming Enrolment' Tab within Institution Account

Description of Task

Rename the tab called 'upcoming enrolment'
Add wording beneath the 'upcoming enrolment' tab header explaining what is reflected within this tab
Possibly revise the logic of whether a COE request gets overwritten or not

Acceptance Criteria:

[ ] Revise the tab name from "Upcoming Enrolment" to: "Upcoming and Previous Enrolments"
[ ] Within the 'upcoming and previous enrolment' tab, add wording beneath the header which reads: "This page contains two types of records:

disbursements requests which are upcoming and will be required at a later date. These are indicated by a 'Required' status

previously actioned Confirmation of Enrolment Requests which can no longer be actioned.  These are indicated by a 'Completed' status.

@CarlyCotton @Joshua-Lakusta Are the below bullet points ok?

@sh16011993 Can you please capitalize them?

Yes, will do. Thanks @CarlyCotton

@CarlyCotton  @Joshua-Lakusta @HRAGANBC Another quick question:

We follow bold instead of quotes in other places in the application like below:

Should I change it from quotes to bold?


Warning: No plugin was found for the platform "SoundTouchPlatform" in your config.json

Latest version (1.4.2-beta) seems to generally not work. This warning is shown on startup of Homebridge. Is there any way to get it to work?
No plugin was found for the platform "SoundTouchPlatform" in your config.json. Please make sure the corresponding plugin is installed correctly.

@mensa84 were you able to get it to work?
@bbriatte any plans to update it? 🥺🙏

No :(


fix: replaced logger unformatted strings with template literals

Which problem is this PR solving?

Good First issue bug-fix for OpenTelemetry-JS.
Logger was using printf style formatting, which was resulting into unformatted strings (%s, %d).

Short description of the changes

All instances of such unformatted strings were searched and were replaced with Template Literals to resolve the issue.

Codecov Report

Merging #9 (efec01a) into main (bebd82a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #9   +/-   ##
=======================================
  Coverage   90.57%   90.57%
=======================================
  Files          51       51
  Lines        1868     1868
  Branches      367      367
=======================================
  Hits         1692     1692
  Misses        176      176

Created PR in Upstream

PR merged to upstream.


Make reaction storage and outbox storage with sqlite

Create default implementations of outbox storage and reaction storage based on using sqlite to generate application data to store instead of memory to ensure better performance

Ready. Kalypso create a sqlite database in program data folder in both windows and linux special folder


Netty Connector chunks request bodies into separate messages

When the Netty connector is configured in HTTP mode, messages longer than 1024 bytes are produced as separate messages.
I've double checked with ngrep: one HTTP POST results in multiple messages. I'm using a topic with a JSON schema and it errors when trying to consume a message because the message content is not a fully formed JSON message as it is cut off, with the remainder of the JSON string in the next message.
In my opinion, this should be a high priority issue because it makes the Netty connector unusable in real world scenarios.

Closed as stale and no one works on it. Please create a new issue if it's still relevant to the maintained versions.


Automatically apply patch upgrades

[ ] ES: https://github.com/kubedb/project/issues/191
[ ] PG: https://github.com/kubedb/project/issues/374

https://github.com/openkruise/kruise/blob/master/docs/concepts/astatefulset/README.md


feat(client): migrate to ureq

reqwest::blocking client builder attempts to clone(), which does not
work within Enarx keeps, migrate to simpler ureq, which works.
Blocked by #113

Filed https://github.com/profianinc/drawbridge/issues/120 for some follow-up cleanup


feat: 🎨 add console icon for nushell

A very simple PR to add nushell's nu files to the console family

Before:

After:

@melMass, @lucas-labs, and @PKief
I have Fish and Nushell files without the extensions fish and nu, but with the comment #/usr/bin/env fish or ``#/usr/bin/env nu`. VSCode can detect it and switch to the correct language mode.
I tried to apply the file icon association, but it seemed to fail. Here is the small code:
{
  "material-icon-theme.files.associations":
  {
    "**/fish/*": "console",
    "**/nu/*": "console",
  },
}

Is there any solution for this?

@gusbemacbe could you please use the language associations instead of the file icon associations? With that it might work:
https://github.com/material-extensions/vscode-material-icon-theme#language-associations
"material-icon-theme.languages.associations": {
    "fish": "console",
    "nu": "console"
}

I'm not 100% about the language IDs, if they are called "fish" or "nu". Maybe you have to replace that with the right IDs.


in*Range predicate with RBMBackedTimestampSet property

My schema has an element with a property "time" that is specified as a RBMBackedTImestampSet. I would like to perform a postAggregationFilterFunction that selects all elements with a "time" in a certain range. I'm using the REST v2 interface to gaffer and I've specified the selection as:
"postAggregationFilterFunctions": [
{
"predicate": {
"start": {
"java.time.Instant": 0
},
"end": {
"java.time.Instant":<PHONE_NUMBER>
},
"class": "uk.gov.gchq.koryphe.impl.predicate.range.InRange"
},
"selection": [
"time"
]
}
This results in:
<Response [400]>
org.apache.accumulo.core.client.impl.AccumuloServerException: Error on server xx.xx.xx.xx:yyyy
How do I go about doing this selection?
Also allowing the inDateRange() or inTImeRange() predicates would be most helpful.

Hi @gregm-tnw,
The InRange predicate only works on Comparables. So unfortunately you can't apply the InRange predicate directly on RBMBackedTimestampSet. We/You would need to create a specific predicate that behaves like InTimeRange but checks if any of the timestamps within RBMBackedTimestampSet are within the provided range.

Thanks for the clarification, the Swagger ineterface reports that InRange was a valid predicate for RBMBackedTimestampSet which is what led to my confusion. As RBMBackedTimestampSet is part of the time library adding support for the time based predicates/transforms/functions would be good for consistency.

Just to note that:

Yes, an in range predicate would be useful for the timestamp sets
But these could have various meanings, e.g. at least one of the timestamps is in the range, or all of the timestamps are in the range. We'd need to allow the predicate to be configured with these different meanings.

Merged into develop


Input type text onChange that fires an action is slow

I have a reducer where the state object is big ( > 200 entries). I have an action that fires off whenever I change an input text component. To update the state I am doing an extend/assign on the state object with the new value inputed. This is very costly because the operation that operation is o(n) and I can feel it lagging whenever I type inside the input component. It seems like whenever there are many items in the state object this will happen. What are some ways to resolve this?
This is the reducer:
function timecardWeekItems(state, action){
  state = _.isUndefined(state) ? {} : state;
  switch (action.type){
    case TimecardAdminConstants.HOURS_ENTERED:
      var newState = _.assign({}, state);
      newState[action.uuid] = action.value;
      return newState;
    default:
      return state;
  }
}

I am using ES5 and underscore because we don't have babel yet.

Have you considered using Immutable.js? It might help with performance in the case when you often update objects with many keys.

Also are you convinced the perf problem is in the reducer?
See Advanced Performance.

It would also be immensely helpful if you could share a tiny project reproducing the issue.

I think it might be react rerendering when it doesn't need to.
I have a datastructure like this:
cart = {
  items: [0,1,2]
}

items = {
  0 : { date: "1/24", hours: ["1","2","3"] }
  1 : { date: "1/25", hours: ["1","2","3"] }
  2 : { date: "1/26" hours: ["1","2","3"] }
}

Each index of hours array are mapped to input text components. Whenever I type something to update the datastructure, this connect or mapStateToProps function gets called

function(state, ownProps){
  var items = _.map(ownProps.items, function(i){
    return state.items[i]
  })

  return {
    items: items
  }
}

Since _.map returns a new array, I think react will update every item. Correct me if I'm wrong. If I have 200 items, each has ~7 input text components, 1400 input components are updating.
Am I supposed to join the data in the mapStateToProps?
Should I restructure the data or would reselect help?

Can you please publish a tiny project demonstrating the issue?

The link in https://github.com/rackt/redux/issues/1244#issuecomment-172125612, to advanced performance is broken.
One way is to debounce the action dispatch in the text inputs onChange.

@tryggvigy Thanks, link is fixed now.

The problem to my issue is not related to redux being slow but react rendering. I have fixed it by using immutablejs. Closing issue.

Hi, @azin634. Do you mind elaborating on the finalized version of solution that you used to resolve your issue?

+1 slower than a turtle and a sloth

I have a similar problem. And it seems to be a rendering issue as well. However, isn't React, especially when used with Redux, supposed to solve this kind of rendering issue - by not calling the render function when the state doesn't change and by using the virtual dom?

@ConAntonakos wow sorry for the really late reply. I fixed it by using immutableJS and adding logic in shouldComponentUpdate.
@carpben it depends on the data structure you designed. If the component thinks its new data it will rerender. My problem was related to nesting data.


ui::Button not displaying text of certain colors

axmol version: Branch 1.x
devices test on: Windows 10
developing environments

NDK version: r23c
Xcode version: 14.2
Visual Studio:

VS version: 2022 (17.6+)
MSVC version: 1929, 1934, 19.35, 19.36, 19.37
Windows SDK version: 10.0.22621.0

cmake version:
Steps to Reproduce:

Modify HelloWorld.cpp of a new project with the following code:
Add the following to the end of the HelloWorld::init() method (before the return statement):
auto* layout = ui::Layout::create();
layout->setContentSize(visibleSize);
layout->setAnchorPoint(Vec2::ANCHOR_MIDDLE_TOP);
layout->setPosition(Vec2(visibleSize.width / 2, visibleSize.height));
layout->setLayoutType(ui::Layout::Type::VERTICAL);
layout->setClippingEnabled(true);
this->addChild(layout);

layout->addChild(CreateButton("Button 1", Color3B::WHITE, Color4B::BLACK));
layout->addChild(CreateButton("Button 2", Color3B(100, 100, 200), Color4B::WHITE));
layout->addChild(CreateButton("Button 3", Color3B(197, 197, 197), Color4B::BLACK));
layout->addChild(CreateButton("Button 4", Color3B(255, 0, 0), Color4B::YELLOW));

Also add this method to the HelloWorld class:
ui::Button* HelloWorld::CreateButton(const std::string& text, const Color3B& btnColor, const Color4B& textColor)
{
    auto* button = ui::Button::create({}, {}, {}, ax::ui::Widget::TextureResType::LOCAL);

    // Explicitly create the label and assign to button
    //auto* label = Label::createWithTTF(text, "fonts/Marker Felt.ttf", 36, ax::Size::ZERO, TextHAlignment::CENTER, TextVAlignment::CENTER);
    //label->setIgnoreAnchorPointForPosition(false);
    //label->setAnchorPoint(Vec2::ANCHOR_MIDDLE);
    //label->setTextColor(textColor);
    //button->setTitleLabel(label);

    // Or just use the button title text
    button->setTitleText(text);
    button->setTitleColor(Color3B(textColor));
    button->setTitleFontName("fonts/Marker Felt.ttf");
    button->setTitleFontSize(36);
    button->setTitleAlignment(TextHAlignment::CENTER, TextVAlignment::CENTER);

    button->setColor(btnColor);
    auto* lp1 = ax::ui::LinearLayoutParameter::create();
    button->setLayoutParameter(lp1);
    lp1->setGravity(ax::ui::LinearLayoutParameter::LinearGravity::CENTER_HORIZONTAL);
    lp1->setMargin(ax::ui::Margin(0.0f, 15, 0.0f, 15));
    return button;
}

This is the incorrect resulting output (note that the white and yellow text isn't being displayed for buttons 2 and 4):

Is there something I'm missing in my code, or is this a bug?
Full project is attached (with the button.png image used in the above example):
HelloCpp.zip
EDIT: Just to clarify, can even do auto* button = ui::Button::create({}, {}, {}, ax::ui::Widget::TextureResType::LOCAL); without a button image, ~and the text will still not be visible.~ and the text will be the incorrect color.

So, it turns out the problem is with Button::setColor().
With a call to Button::setColor (incorrect text colors):

Without the call to Button::setColor (correct text colors):

What was confusing is that Node::_cascadeColorEnabled is false, so the color of the parent (being the button) should not affect the label child node on the button, but then I finally noticed this code:
void ProtectedNode::updateDisplayedColor(const Color3B& parentColor)
{
    _displayedColor.r = _realColor.r * parentColor.r / 255.0;
    _displayedColor.g = _realColor.g * parentColor.g / 255.0;
    _displayedColor.b = _realColor.b * parentColor.b / 255.0;
    updateColor();

    if (_cascadeColorEnabled)
    {
        for (const auto& child : _children)
        {
            child->updateDisplayedColor(_displayedColor);
        }
    }
    for (const auto& child : _protectedChildren)
    {
        child->updateDisplayedColor(_displayedColor); <= this is the problem, since it's completely ignoring _cascadeColorEnabled
    }
}

I don't really understand why the _protectedChildren have forced cascading of the colors.  If someone knows why, then please explain the reasoning behind this.

Note that void ProtectedNode::updateDisplayedOpacity(uint8_t parentOpacity) has the same issue, which forces opacity on protected nodes (ignoring _cascadeOpacityEnabled).  There is also a matching void ProtectedNode::disableCascadeOpacity() to go with it that also needs to be called at the right time in order to work.

Would anyone know why protected child nodes have different treatment to child nodes of a ProtectedNode when it comes to opacity and color?
If there is no reason for the difference, then why not enabled cascading of color and opacity by default for ProtectedNode so it affects both types of child nodes? That would remove the need for disableCascadeColor and disableCascadeOpacity.

Things are even weirder, since ProtectedNode::addProtectedChild checks if _cascadeColorEnabled and _cascadeOpacityEnabled are enabled before calling the respective code, yet those methods end up ignoring those 2 flags anyway.
void ProtectedNode::addProtectedChild(Node* child, int zOrder, int tag)
{
   ...

    if (_cascadeColorEnabled)
    {
        updateCascadeColor();
    }

    if (_cascadeOpacityEnabled)
    {
        updateCascadeOpacity();
    }
}

I'm going to submit a PR to re-work this.  If anyone uses this functionality, then please test it out and let me know what issues you have.

Never mind, I think this may end up breaking things, so leave it as-is for the time being.  To work around this issue I'll simply change the color of the renderers used for the button background images (_buttonNormalRenderer, _buttonClickedRenderer and _buttonDisabledRenderer).


Unnecessary shouldComponentUpdate override?

Component class implements shouldComponentUpdate. Cart component extends Component and overrides shouldComponentUpdate with exact same code.
https://github.com/RisingStack/react-way-immutable-flux/blob/f0c1a79bf8afa690da04e47d3d18e42df2cd9624/src/app/components/Cart.js#L19-21

Good catch. I removed these in this pr.
https://github.com/RisingStack/react-way-immutable-flux/pull/4


Data Library - Convert raw data to parquet

This should take result of #499 and convert it to parquet. This will obviously depend on file type, as defined in source section of yml template. For shapefiles, geodatabases, etc. it might still make sense to use gdal, though geopandas is an option as well. In my opinion, code simplicity is most important, so even if gpd is less performant (not sure it is, just speculating), I would prefer it to gdal.
This should output a parquet file locally that can feed into the preprocessing steps of the extraction

Edge cases:

geodatabase with multiple layers where we only need one of them

Adding on requirements for this task:

Reading in the following formats:

csv
geodabase (with 1 or multiple layers)
shapefile
zipped version of any of the formats above
json
geojson
excel?

Correct geometry in output (parquet stores geometry in wkb format)

Unchanged column names in output

Unchanged data in output

Update: implemented 1st iteration of convert_raw_to_parquet fn in #658. The fn currently converts csv, geodatabase, and shapefile formats to parquet.
TODO:

[ ] implement json
[ ] geojson
[ ] zipped format
[ ] for csv files, implement point geom made out of Longitude & Latitude columns
[ ] geoparquet (as an export format)
[ ] name geometry column as geom in output parquet file
[ ] break up transform_to_parquet fn into 2 parts: 1) read raw data into a geopandas df and 2) save the df to parquet
[ ] simplify tests (perhaps by using complete, not partial, fake templates)

For raw json, it'd make sense to have an optional field that takes input in form of jq query to parse a slightly nested structure into something tabular

All data formats have been implemented.


Feature request: stop stern when log stream is closed

Note: this issue was imported from https://github.com/wercker/stern/issues/118, but it was originally created by lihaiswu...
Currently, we need to use a pid to record the stern and kill it when the job/pod is complete. It'd be great if there's an option to terminate stern automatically once it detects the log stream in all pods are complete. For example, pod status is changed to Completed, DeadlineExceeded, Error, etc.

It'd be great if there's an option to terminate stern automatically once it detects the log stream in all pods are complete

Since stern is constantly watching the creation of Pods, it cannot determine if all Pods have been completed or not. For example, if you want stern to exit when it has logged all pods that exist only at the time of command execution, we can consider adding --no-follow option.
If there is a demand for that, please let me know in the comments.


Make the WAM-V configurable

VRX (Gazebo classic) supported the notion of selecting different thruster configuration, as well, as component options. The components include sensors and actuators such as the ball shooter. We need to port this functionality to Gazebo.

See #526 .


Model resolvers for Sequelize must NOT include all associated records

Fetching all associated models can easily generate fatal out of memory errors,
especially when both sides of a relationship are implemented.
Remove the default option
let options = {
    include: [{
       all: true
    }]
};

and use
let options = {}

Consider the following example
{
  "model" : "individual",
  "storageType" : "SQL",
  "attributes" : {
    "name" : "String"
  },
  "associations": {
    "transcript_counts": {
      "type" : "sql_hasMany",
      "target" : "transcript_count",
      "targetKey" : "individual_id",
      "targetStorageType" : "sql"
    }
  }
}
{
  "model" : "transcript_count",
  "storageType" : "SQL",
  "attributes" : {
    "gene" : "String",
    "variable" : "String",
    "count" : "Float",
    "tissue_or_condition": "String",
    "individual_id": "Int"
  },
  "associations": {
    "individual": {
      "type" : "sql_belongsTo",
      "target" : "individual",
      "targetKey" : "individual_id",
      "targetStorageType" : "sql"
    }
  }
}

When querying for individuals all associated transcript_counts are fetched, too. Those in turn have associated individuals, which have associated transcript_counts, which have ...
Such a query generates the following output and error
> Executing (default): SELECT "individual"."id", "individual"."name", "individual"."createdAt", "individual"."updatedAt", "transcript_c[1/18106]
d" AS "transcript_counts.id", "transcript_counts"."gene" AS "transcript_counts.gene", "transcript_counts"."variable" AS "transcript_counts.variable", "transcript_counts"."count" AS "transcript_counts.count", "transcript_counts"."tissue_or_condition" AS "transcript_counts.tissue_or_condit
ion", "transcript_counts"."individual_id" AS "transcript_counts.individual_id", "transcript_counts"."createdAt" AS "transcript_counts.createdAt"
, "transcript_counts"."updatedAt" AS "transcript_counts.updatedAt" FROM "individuals" AS "individual" LEFT OUTER JOIN "transcript_counts" AS "tr
anscript_counts" ON "individual"."id" = "transcript_counts"."individual_id";

>
>
<--- Last few GCs --->

[8:0x3fa58d0]   831587 ms: Mark-sweep 1053.7 (1757.4) -> 1053.7 (1757.4) MB, 2397.0 / 0.0 ms  allocation failure GC in old space requested
[8:0x3fa58d0]   834099 ms: Mark-sweep 1053.7 (1757.4) -> 1053.7 (1626.4) MB, 2511.5 / 0.0 ms  last resort GC in old space requested
[8:0x3fa58d0]   836572 ms: Mark-sweep 1053.7 (1626.4) -> 1053.7 (1578.9) MB, 2473.2 / 0.0 ms  last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x1afcde8a55e9 <JSObject>
    1: /* anonymous */(aka /* anonymous */) [/usr/src/app/node_modules/sequelize/lib/model.js:~1657] [pc=0xfbec30b7b8a](this=0x3f6397f822d1 <und
efined>,memo=0x32306c7fe159 <JSArray[50855]>,result=0x2de0e1b82371 <Model map = 0x29cd0bf10e29>)
    2: arguments adaptor frame: 4->2
    3: reduce(this=0x12c703182729 <JSArray[240]>)
    4: /* anonymous */(aka /* anonymous */) [/usr/src/app/node_modules...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x8d04bc [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewUninitializedFixedArray(int) [node]
 6: 0xd8c113 [node]
 7: v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) [node]
 8: 0xfbec2f842fd
Aborted (core dumped)

Fixed 892cbe

It is fixed and thus can be closed


Develop

Implemented the transfer of completed survey data to the back-end API

Looks good to me! :rocket:


Add new parameter -P for matc

This new matc parameter -P or --material-parameter allows users to set material properties to the specified value.
Values passed through this matc parameters have the highest priorities. I.e., they overwrite material properties specified in the material file.

Instead of duplicating every processing function, wouldn't it be easier to have the existing ParametersProcessor::process function substitute a different value before invoking the JSON callback?

Instead of duplicating every processing function, wouldn't it be easier to have the existing ParametersProcessor::process function substitute a different value before invoking the JSON callback?

Yeah I tried reusing the existing JSON callbacks, but the problem was that array types cannot be

Instead of duplicating every processing function, wouldn't it be easier to have the existing ParametersProcessor::process function substitute a different value before invoking the JSON callback?

Yeah I could use JsonishValue instead of std::variant. Let me update that way.


Added backers and sponsors from OpenCollective

Now backers and sponsors from opencollective appear in your readme.
PS: Are you seeing the badges correctly? most of yours look broken to me, so I don't know if it's an issue with the opencollective badges or something else.

Hey, thanks for the PR! It seems badges.io is down at the moment, so I'll come back to this tomorrow morning :grin:

hey @yoshuawuyts we should probably finish this so X-team's support also shows up here.

Merged in 1236550 :tada:


repository name

Not sure if compomics is an appropriate name for this repository, given this is also Lennarts's group name.

@lgatto we can change but a lot of people starred already the repo. and I can find a shorted name for computational proteomics trends, challenges 2019 ;)

Still not a good fit and confusing. And by the way, github manager repository renaming quite well.

@lgatto I can change it. What do you think about computational-proteomics-paper?

What about CompProtTrends2019?

Do you like this CompProt2019-paper?

:+1:

The repo has been renamed to CompProt2019-paper


MH-13191 Improve performance of retrieving groups

When groups have a large number of group members, the performance of the requests

GET /admin-ng/groups
GET /admin-ng/groups/ {group_identifier}

gets quite bad.
This is because of three reasons:

For each group and for each user in that group, an SQL query of its own is run. So there’s lots of queries, and apparently there are a number of caches involved to mitigate this already. However, as the
number of users in each group grows bigger, the caches don’t help anymore.
For each group, along with the actual users in that group, the users roles are retrieved. However, the roles aren’t actually used in the JSON output of the request. So all that work is for nothing.
When deserializing the group output from the search index, the XML unmarshaller isn’t shared between runs.

Consequently, this PR does the following:

Add a function to retrieve a list of users (by their names) from the data base in bulk. This is used per-group. Currently supported backends for this are the JPA user provider and the JPA user reference
provider. The other backends behave as before.
Don’t retrieve the users roles anymore.
Share the unmarshaller between deserialization runs for the group query.

We saw a performance increase from about 40s (!) to about 1s for a group with 1000 members.
This work is sponsored by SWITCH.

The description and method names that refer to finding users by "names" is ambiguous and could be understand to mean by full name rather than description.
I would prefer to see "username" used (in appropriate case) in comments, javadoc and method names rather than "name". Username could be omitted from the method name if the parameter type is clear, e.g. change method signatures like this:
default Iterator<User> findUsersByNames(Collection<String> names) {

to:
default Iterator<User> findUsers(Collection<String> usernames) {

@smarquard Thanks for the suggestion, you're right. I've changed all of the names to use "userName" or "username" where appropriate.


Return union types

Hello!
One aspect of Zod which works well with TypeScript is the union types returned from parsing/validating a schema:
const input = z.string().safeParse(123);

console.log(input.data) // type error!

if (!input.success) {
  console.log(input.message);
  return;
}

console.log(input.data) // ok!

Based on the readme, at the moment the result doesn't handle this scenario which makes things less type safe. Using freezed unions, you could internally return a Validation union, something like:
final result = l.string().validate('hello');

result.when(
  success: (String value) => print(value),
  error: (String message) => throw Exception(message),
)

Thanks @Ehesp for the suggestion :)


remove cucumber

replaced by rake tasks.
just runs rspec over all the examples cookbooks and all their spec files.
Signed-off-by: Lamont Granquist<EMAIL_ADDRESS>

@tas50 no more using cucumber as an rspec dispatcher

looks like this pulls builds down to 17 minutes from 25 minutes or so as well


WIP: test/test.make: add test/ to gofmt checking path set

test/ was left out of gofmt checking and some formatting
errors have been slipped in there.

ATM there are 2 files failing gofmt check, I can create another commit here fixing those.
Presence of format issues means CI should fail on with current commit alone, right.

Fixed two files that failed  using gofmt, force pushed, so this PR should become OK in CI now

CI ok, removing WIP


fix: missing new_str field in create command output

Description

This PR is to:

Add missing new_str field in create command output. The current missing new_str field causes the action to be mapped to FileReadAction instead of FileEditAction in OH.
Add error message into formatted output.
Bump to 0.1.4.

No, it's just for fixing on the pending PR: https://github.com/All-Hands-AI/OpenHands/pull/5508


Debugging failing when stoponentry=true

Issue Type: Bug
In Launch.Json file , StoponEntry=true is this not working., when ever user has pressed PF5 the program isn't stopped in first line of code. previously it was working fine.
reference : #68630 in gitHub
Extension version: 2019.1.0
VS Code version: Code 1.31.1 (1b8e8302e405050205e69b59abb3559592bb9e60, 2019-02-12T02:20:54.427Z)
OS version: Windows_NT x64 6.1.7601

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz (4 x 2494)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
7.91GB (5.45GB free)

Process Argv

Screen Reader
no

VM
0%

Dup of https://github.com/Microsoft/vscode-python/issues/4223


App name as env var

Description
Adds an env variable "APP_NAME" to enable someone to change the appName.
This might require to run "tsc" to compile both util files as changes are in these 2.
Type of change
Please delete options that are not relevant.

User Interface
New feature (non-breaking change which adds functionality)
This change requires a documentation update (new feature)

Checklist

[ x] My code follows the style guidelines of this project
[ x] I ran ESLint and other linters for modified files
[x ] I have performed a self-review of my own code and test it
[ x] I have commented my code, particularly in hard-to-understand areas
[ x] My changes generate no new warnings
[ -] My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

Sorry, but app name is not allowed to be changed.


api idea: useStateBox

const useStateBox = (fn)

const $user = useStateBox(() => {
  return {
    a, b, c
  }
}, [a, b, c]);

And It's will be interesting to combine it with the "local" module.

const logic = useLocal(() => new Logic(a,b, $user), [a, b, $user])

on hold


lint and format

lint and format codebase with ruff / black.
I was just wanting to test out ruff last night. and got a bit carried away.
Take it or leave it. but all the tests are still passing and I did a test run with some data and prez ui and navigating around and everything is still working.

That's fine - do you want to update the versions in the pre commit hook/add ruff to it? https://github.com/RDFLib/prez/blob/main/.pre-commit-config.yaml . I was using this but need to reinstall it


New cta 0922

Need to update CTA file regularly.

Need to update the file with companies taking action manually.


feat(alloy): use full flag and optimize flag use

Motivation

See: https://github.com/alloy-rs/alloy/pull/877
Solution

Uses the new full flag and the WsConnect and IpcConnect exports now available in the provider namespace.
PR Checklist

[ ] Added Documentation
[ ] Breaking changes

Merging as is due to it being uncontroversial


macOS build in here [1.04]

loose:

1.04 lite.zip

lite.app+plugins:

1.04 lite.app.zip
currently needs to be force quit

note:

supports macOS 10.8 upwards
requires SDL2 to be installed
see other issues for outstanding problems on macOS

I'm happy to do a new build with every release, if that helps the project.

dyld: Library not loaded: /usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib

@wq163 please make sure SDL2 is installed on your Mac, you may want to use brew install SDL2

I'm happy to do a new build with every release, if that helps the project.

Please consider providing a Homebrew cask if you can find the time.

Please consider providing a Homebrew cask if you can find the time.

Sorry, I do not support the homebrew project due to a past instance of them bullying users (including me).

Lovely to see a lightweight editor that may replace TextWrangler for me. Two obvious things I'm still missing (not implying anyone should implement this):

Use Cmd instead Ctrl of for shortcuts on Mac
An application package so it can be started from Spotlight/Alfred

@brechtm Regarding your first bullet point there's a macmodkeys plugin in the plugins repo which remaps ctrl/alt to command/option. In another issue I suggested someone could maintain a "mac fork" for better integration with macOS (high DPI support, application packaging, macmodkeys plugin by default, up-to-date builds etc.), given I have no way to test on that platform myself and it seems to be a little more involved to accommodate for in contrast to other platforms.
Happy for this issue to remain open indefinitely if these builds are useful to people!

I had a quick go at building an application bundle, but I'm not getting anywhere. I'm not sure, but I think the issue has is related to signing the app bundle, which I'm not familiar with.

(unsigned) lite.app bundle above, but note that you have to force quit it.
Open it using right click menu to avoid some nags.

(unsigned) lite.app bundle above, includes macmodkeys and some other plugins, but note that you will have to force quit it.

This has the same issue as the App bundle I created: You have macOS 10.13.6. The application requires macOS 10.14 or later.
Running lite from the command line works fine however. A message in Console.app triggered by launching lite.app made me believe this was related to the bundle missing a signature.

Hmm, min version is set in the app plist to 10.8.0 so the message must be coming from somewhere else. When does it appear? Try changing the app plist?
I am on 10.14 and built on there so the requirement may come from that.

I am on 10.14 and built on there so the requirement may come from that.

I suspect this is the reason. This requirement must be encoded in the lite executable somehow, but it's only being checked when running it from an application bundle?

The otool -l lite output might indicate this:
  platform macos
       sdk 10.14
     minos 10.14

Right, in that case I need to figure out how to build against older SDK as part of a modified build.sh

OK, builds updated to support macOS 10.8 upwards

just updated the builds again
doing otool -l ./lite shows
Load command 9
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.8
      sdk 10.14

@gingerbeardman Thanks! The app bundle is working on macOS 10.13.6 now. Including the macmodkeys plugins is a welcome addition as well.

Excellent!

Can the macOS version be built from source in this repo, or is that version closed source?

Can the macOS version be built from source in this repo, or is that version closed source?

It builds from source; I use some slightly modified build script to get 10.8_ compatibility and bundle more plugins.

@gingerbeardman hey, can you please add 10.12 support for the lite.app+plugins? It currently requires 10.13 to run (the loose version works fine from the command line). Thank you!

done! I left a wrong version number in the app Info.plist

done! I left a wrong version number in the app Info.plist

Awesome! Thank you!

Updated for 1.05, app now quits with Cmd+Q

Another thing I noticed: Cmd+W will close the Lite windows instead of just the active tab. I think this requires removing the default Window>Close menu item. I haven't found a way to do this with SDL2, so we might need custom macOS code for this.

Another thing I noticed: Cmd+W will close the Lite windows instead of just the active tab. I think this requires removing the default Window>Close menu item. I haven't found a way to do this with SDL2, so we might need custom macOS code for this.

I have a macos fork for lite that also has some context and app menu extensions. Currently I set the app menu empty on init just to avoid Cmd+W closing the app. Haven't pushed these changes since I'm in the middle of other stuff, need to clean it up but I can share it once I do?

I'm not sure of the best way to proceed

I'm not sure of the best way to proceed
Let's try my fork... for now.

I’m not saying to switch fork, just that I have code on my branch that you could take to fix the Cmd+W/menu issue.

Thanks @andsve I'll take a look!

@gingerbeardman @andsve If either one of you (or anyone else) wants to take on the role of maintaining an "official" mac fork, let me know! I'd be happy to link to it from the main repo's readme -- it'd be good to establish a home for the mac-specific changes as they seem somewhat fragmented at the moment.
To clarify why I don't want the mac specific code integrated in the main project: it's code I can't run, can't test and can't build -- if someone submits a change I have no way of properly gauging the repercussions of it (does it break something else? does it even fix the issue?), it puts me in a position where I have to blindly merge pull requests of questionable quality. Alternatively those pull requests aren't even made, in which case there are lingering bugs in the parts of the codebase I can't run, and thus can't fix.

I need to figure out if I have the time to maintain a fork more than just building quickly once evert so often.

To clarify why I don't want the mac specific code integrated in the main project: it's code I can't run, can't test and can't build -- if someone submits a change I have no way of properly gauging the repercussions of it (does it break something else? does it even fix the issue?)

CircleCI, at least, offers CI builds on macOS, which means you get unit tests as well. Whether that's something lite currently has or can add, I don't know.

it puts me in a position where I have to blindly merge pull requests of questionable quality.

What if you adopted an official policy that PRs specific to a platform you can't build or test yourself need to be approved by at least one of a set of maintainers who can build or test on that platform? For instance, @gingerbeardman and @andsve appear to be both qualified and interested in macOS support for lite.
I would volunteer for that task myself, but I haven't downloaded or run lite yet since it's not clear to me that macOS is going to be supported by lite in the future. Sort of a catch-22, I realize.

What if you adopted an official policy that PRs specific to a platform you can't build or test yourself need to be approved by at least one of a set of maintainers who can build or test on that platform? For instance, @gingerbeardman and @andsve appear to be both qualified and interested in macOS support for lite.

This unfortunately results in the same problem: if the mac maintainer on the main repo no longer has time to contribute to the project it leaves me again in the position of having code I can't fix, run or test. In that case I'm stuck between the two bad choices of either leaving broken code in the project indefinitely, or stripping out all the macos stuff which puts us back at square one.
Additionally this stalls things like releases on the main repo as it now requires the cooperation of several people before one can happen.

To clarify why I don't want the mac specific code integrated in the main project: it's code I can't run, can't test and can't build -- if someone submits a change I have no way of properly gauging the repercussions of it (does it break something else? does it even fix the issue?)

CircleCI, at least, offers CI builds on macOS, which means you get unit tests as well. Whether that's something lite currently has or can add, I don't know.

Good idea! I have GH workflows building a macos binary on my branch now, feels like it should be sufficient.
@rxi Totally understand, I also feels like the best way forward is to have a separate macos fork. The changes to the rendering isn't very nice, but sadly I haven't found a prettier workaround, maybe someone more familiar with SDL could give it a stab.

updated to 1.06
not yet had time to look at @andsve code

FYI.  the build from @andsve has sharper text than the build from @gingerbeardman

@wallabyway

see other issues for outstanding problems on macOS

updated for 1.07 (same caveats apply)

updated for 1.08 (same caveats apply)

updated for 1.09 (same caveats apply)

I noticed GitHub offers macOS runners through it's Action feature.

1.10 updated, same outstanding macOS issues

I noticed GitHub offers macOS runners through it's Action feature.

Yes, as I said above this is what I use on my fork+branch to get these builds: https://github.com/andsve/lite-macos/actions/runs/151367501

@andsve - any chance you could add the following changes to your build?

add plugins/macmodkeys.lua (https://raw.githubusercontent.com/rxi/lite-plugins/master/plugins/macmodkeys.lua)
change core/init.lua
line 473 ...  system.sleep(0.025);
line 476 ...  system.sleep(math.max(0.001, 1 / config.fps - elapsed))
change core/view.lua,  lines 127 & 128
self:move_towards(self.scroll, "x", self.scroll.to.x, 0.1)
self:move_towards(self.scroll, "y", self.scroll.to.y, 0.1)

(this helps CPU idle, smoother wheel-scroll, and Mac keys )

@wallabyway why not put those changes in a PR?

1.11 updated

Did you try an iOS build?. Would be interesting.

@rxi @andsve @gingerbeardman.
I'm interested in a mac build too. I would love to see the changes upstream but I do understand the point @rxi made.

The changes to the rendering isn't very nice, but sadly I haven't found a prettier workaround, maybe someone more familiar with SDL could give it a stab.

Not familiar at all with the render here, but sdl should take care of everything if NSHighResolutionCapable is set in Info.plist.
To create an app bundle the code in @gingerbeardman branch is fine. If any I would like to build SDL as part of the program to avoid xcode commandline tools & brew dependencies.

I've only just got a retina display, so now I can see what's wrong here.
With NSHighResolutionCapable = YES in the Info.plist I do not see any changes, the fonts sizing is OK, but the text is rendered in low-resolution.
Contrast with the window title:

Please consider providing a Homebrew cask if you can find the time.

Sorry, I do not support the homebrew project due to a past instance of them bullying users (myself included).

Rather sad. This would help with smooth updates along with other packages instead of having disparate installation methods.
I just tried v1.11 and it won't install on macOS catalina.

@dubesoftware what's sad? those guys bullying me or my refusal to deal with them because of it? Either way, YMMV.

Just to say there are no hard feelings here. I think the Mac version of lite is at an impasse, and I have found a new native editor on Mac (www.Nova.app) so this is the end of this issue for me.
Stay safe and have fun!

@dubesoftware what's sad? those guys bullying me or my refusal to deal with them because of it? Either way, good luck with this.

I just saw this. I meant it was sad we can't have nice things because of "politics". Thanks for your hard work.

Just to say there are no hard feelings here. I think the Mac version of lite is at an impasse, and I have found a new, fast, native editor on Mac (www.nova.app) so this issue has run its course for me.
Stay safe and have fun!

Thanks for this plug! Thsi is definitely worth a look. I've been using TextMate (I find I work best in a simple editor that provides basics and "gets out of the way").
Stay safe and happy coding to you too!


net: buf: Fix debug level setting

Some of the net_buf related tests failed if they enabled
CONFIG_NET_BUF_LOG setting.
Signed-off-by: Jukka Rissanen<EMAIL_ADDRESS>

The fix is in #10763


Push master to live. Includes a number of patches.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/docs-conceptual/exchange-online/connect-to-exchange-online-powershell/connect-to-exchange-online-powershell.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/docs-conceptual/exchange-server/connect-to-exchange-servers-using-remote-powershell.md
:white_check_mark:Succeeded
View (exchange-ps)

officewebapps/officewebapps-ps/officewebapps/Get-OfficeWebAppsExcelBIServer.md
:white_check_mark:Succeeded
View (officewebapps-ps)

sharepoint/sharepoint-ps/sharepoint-server/Get-SPAccessServicesDatabaseServerGroup.md
:white_check_mark:Succeeded
View (sharepoint-ps)

skype/skype-ps/skype/Add-CsSlaDelegates.md
:white_check_mark:Succeeded
View (skype-ps)

skype/skype-ps/skype/Enable-CsMeetingRoom.md
:white_check_mark:Succeeded
View (skype-ps)

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.


Error calling from signal paste_nodes_request in VisualShaderEditor

Godot version:
4.0.dev.custom_build. 4a0e99f19
Issue description:
 Error calling from signal 'paste_nodes_request' to callable: VisualShaderEditor::_paste_nodes : Method expected 2 arguments, but called with 0.

https://github.com/godotengine/godot/blob/058a0afdeca83145d58a95c426dd01216c397ea9/editor/plugins/visual_shader_editor_plugin.cpp#L2345

Looks that is fixed in master


Can't install toltec-dev on <IP_ADDRESS>6 (reMarkable 2)

I'm try to install tool by bootstrap file but found error, please check photo below:
wget http://toltec-dev.org/bootstrap
echo "04a28483286f88c5c7f39e352afb62adc57f6162a29fd7e124d832205bb0980e  bootstrap" | sha256sum -c && bash bootstrap

It seems that you had installed toltec previously. Usually the script would tell you, that you have toltec already installed, but it would not in a few cases:

toltecctl is missing (located at /home/root/.local/bin/toltecctl). Could mean a super old installation
/opt was cleaned but the mount wasn't removed (also checked /home/root/.entware but that would probably bind mounted together anyways)

Please run the following commands to make figuring this out more easy:

ls -la --full-time /home/root/.local/bin/toltecctl /home/root/.entware /opt to check what files exist and if, how old they are
df -h to confirm that /opt actually has no bind mount (as well as whether super low free space could be a potential issue as well)
ls -la --full-time /lib/systemd/system/opt.mount && systemctl status opt.mount --no-pager to check whether the service was already cleaned up

It seems someone also had this same issue a while back at https://github.com/toltec-dev/toltec/discussions/551. If you can run toltecctl, you can probably do a toltecctl reenable or toltecctl uninstall (backup any important config files in /opt first) to fix it. There was no real reason stated though, so this still needs to be investigated.


Add Double Life by Pharrell Williams

Song Name
Double Life
Artist Name
Pharrell Williams
Source
Youtube
Youtube Link
https://www.youtube.com/watch?v=fWtn6RMNiok
Direct File Link
No response
Song ID
76743
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 110662000
Downloaded: No

ok


fix(port): Port can be made optional for non-routable apps

fixes #1015
If the app is non-routable then don't throw error if port can't be found.

Current coverage is 87.80% (diff: 60.00%)

Merging #1136 into master will decrease coverage by 0.01%

@@             master      #1136   diff @@
==========================================
  Files            42         42
  Lines          3672       3675     +3
  Methods           0          0
  Messages          0          0
  Branches        630        632     +2
==========================================
+ Hits           3225       3227     +2
  Misses          294        294
- Partials        153        154     +1

Powered by Codecov. Last update 836c285...828c13b


[Feature Request] Search API access delay between requests

Prerequisites

[x] Did you read FAQ section in readme.md?
[x] Did you test with the latest releases or commit ?
[x] Did you search for existing issues in Issues?

Description
Hi,
I'd like to request a short break between search API requests that return 0 images while processing on tag lists. While surfing on Pixiv, I've observed that the site is temp banning the IP if there are too many API requests at once which may be caused by long tag lists and a narrow start and end date time frame.
Same happens if I run a second instance, and the first instance processes empty search API returns. If I don't intervene and pause the script, it's possible to have the IP temp banned.
I think it would suffice to reuse the downloadDelay value in the config.ini.
Steps to Reproduce

[First Step]
[Second Step]
[and so on...]

Expected behavior:
Just a short timeout before the next request, either download or next search API request.
Actual behavior:
PU continues with zero delay.
Log file: [Attach the pixivutil.log file in the application folder, recommended to delete the old file, reproduce the issue, and upload the newly generated file here]
Versions
20221029

Hi,
sorry, I couldn't test it earlier. Works perfectly for me with the current code.
Thank you.


Ensemble Mono repo

We have a number of packages and growing. In order to properly maintain them, I suggest converting following packages multiple repo into single mono repo.

https://github.com/EnsembleUI/ensemble_location
https://github.com/EnsembleUI/ensemble_camera
https://github.com/EnsembleUI/ensemble_module_auth
https://github.com/EnsembleUI/ensemble_file_manager
https://github.com/EnsembleUI/ensemble_notification
https://github.com/EnsembleUI/ensemble_contacts

Reference: https://github.com/firebase/flutterfire

I completely agree with this. There are too many repos everywhere.
Also add https://github.com/snehmehta/table_calendar to it. That should be under EnsembleUI org and does not need to be a separate repo. Something like that can just be part of the core package

same as #865


Add workflow to build, test, and check formatting/artifacts on PR

This workflow should be fairly workflow-agnostic in terms of whether your dependencies should be checked in; if you .gitignore lib it won't enforce build output. If artifacts are being checked into lib, this workflow will ensure they're in sync with the source.
Husky has been removed since this will enforce at the PR level and we're adopting a .gitignore and doing production modules in a branch.

Ding!


Cannot add only one value for input_folder in abap_transpile.json

The following single value is not supported
{
  "input_folder": "{src/abap}",
  "input_filter": [],
  "output_folder": "dist/abap",
  "libs": [
    {
      "url": "https://github.com/open-abap/open-abap-core"
    },
    {
      "files": "/**/*.*",
      "folder": "/../../../../../root/registry/public/kronos/src/abap"
    }
  ],
  "write_unit_tests": true,
  "write_source_map": true,
  "options": {
    "ignoreSyntaxCheck": false,
    "addFilenames": true,
    "addCommonJS": true,
    "unknownTypes": "runtimeError",
    "skip": []
  }
}

2024-06-24 15:33:32.962 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - > rm -rf output && abap_transpile abap_transpile.json
2024-06-24 15:33:32.962 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService -
2024-06-24 15:33:33.218 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - Transpiler CLI
2024-06-24 15:33:33.219 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - Using config: abap_transpile.json
2024-06-24 15:33:33.219 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - Clone: https://github.com/open-abap/open-abap-core
2024-06-24 15:33:34.698 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - 	515 files added from lib
2024-06-24 15:33:34.954 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - From folder: /../../../../../root/registry/public/kronos/src/abap
2024-06-24 15:33:34.955 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - 	1 files added from lib
2024-06-24 15:33:34.957 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - 0 files added from source
2024-06-24 15:33:34.957 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService - 0 files skipped in source
2024-06-24 15:33:34.957 [INFO ] [Thread-1469] [background] o.e.d.c.i.w.service.ActionsService -

If I change input_folder to {src/abap,test/src} it works
2024-06-24 15:35:30.661 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - > rm -rf output && abap_transpile abap_transpile.json
2024-06-24 15:35:30.661 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService -
2024-06-24 15:35:31.112 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - Transpiler CLI
2024-06-24 15:35:31.113 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - Using config: abap_transpile.json
2024-06-24 15:35:31.113 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - Clone: https://github.com/open-abap/open-abap-core
2024-06-24 15:35:32.428 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - 	515 files added from lib
2024-06-24 15:35:32.474 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - From folder: /../../../../../root/registry/public/kronos/src/abap
2024-06-24 15:35:32.476 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - 	1 files added from lib
2024-06-24 15:35:32.477 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - 1 files added from source
2024-06-24 15:35:32.477 [INFO ] [Thread-1601] [background] o.e.d.c.i.w.service.ActionsService - 0 files skipped in source

Of course I can use just src/abap but I would expect that {src/abap} will work as well.
Also, in my opinion will be better if you use array for specifying more than one value, or use array always.
{
  "input_folder": ["src/abap", "test/src"]
}

good idea 👍

#1472

@iliyan-velichkov try again, latest version


More generic composite key escape method (e.g. for jj/jk/kj etc)

The problem
Currently the composite key system is a little strange. In order to handle the case where the two letters are the same (eg jj), the first composite key has to trigger an escape if it sees its bound key again. This means handling the case where they are different (eg kj) will always also handle the case where they are the same (i.e. kk as well as kj). Also, it only allows for one combination, so would not allow order-independent mapping of the kj chord (i.e. trigger on both kj and jk
Proposed solution (WIP)
Have a single function to be mapped to, something like compositeEscNotifyKeyPressed. All keys within the chord, whether just j or both k and j should be mapped to this individually, so you might end up with something like:
{
    "key": "j",
    "args": "j",
    "command": "vscode-neovim.compositeEscNotifyKeyPressed",
    "when": "neovim.mode == insert && editorTextFocus"
},
{
    "key": "k",
    "args": "k",
    "command": "vscode-neovim.compositeEscNotifyKeyPressed",
    "when": "neovim.mode == insert && editorTextFocus"
}

This would be accompanied with a separate option (say, "compositeEscKeyChords"), a dictionary holding each chord you want to bind, for example:
{
    "k": "v",
    "v": "k",
    "j": "j"
    // Not supported with this algorithm because of the duplicate key:
    // "v": "k"
}

Then the callback function should store as a variable the pressed key (passed as an arg) if it is in compositeEscKeyChords as a key. If that variable already has something in it, and the current press is within the timeout, check to see if the current press is a value in the map for the stored previous key. If so, do the backspace and esc. If not, send the character.
What do you think about this setup? As far as I can see it would solve the problems above, and do so in a more elegant way than the current solution.
(I think the timeout should also be provided as an option, because people can get quite sensitive about their timeoutlen in vim.)

#892 My stab at this; works for me but could be more robust.

Ok I implemented a version of this, updated tests, etc. It's general enough to map any key, or just one if you include escOnDoubleTap: true in the args list in keybindings.json. Also added timeoutLen arg!

https://github.com/vscode-neovim/vscode-neovim/pull/886#issuecomment-1175189763

I believe #886 being merged is sufficient to resolve this issue. Big thanks to theol0403

Sorry, I don't think it is. I think in the final released version, the native jk functionality was scrapped because it caused problems.

@BlueDrink9 thanks for your comments, but I think the alternate method is fundamentally broken.
It is possible that some of the more recent prs fixed it.
But I think the problem is with lag. If you type a sentence rapidly with j or k in it, the j and k might be typed in the wrong location.

Ah, I see what you mean. In the tests I had been using it for, I hadn't needed to type those keys so I didn't notice the delay :/
Bother

Is this the same feature as e.g. composites for surround like
gza (I'm using LazyVim which remaps mini.surround prefix to gz (but doesn't seem to document this very well....) ?
A minor gripe I have is that the code as written gives you (I think) 1/5th of a second to complete each key in the sequence, which means if you have to think about it (as you do when learning), you lose the "thread".
In contrast LazyVim gives you all the time in the world and a nice helper too (see below).
You have to get as far as gza quite rapidly ; I  often do gz then stall for a moment while I try to remember which of the seven choices you have for this plugin is next. The help sheet would be LOVELY (but probably out of scope for this thread), but the time to think or look away at a cheat sheet would be even lovelier ; which would presumably mean changing this to a purely state-driven sequence and not having the composite timestamp checks in typing_manager.ts (which is my best guess at what causes this behaviour ..?)

g - goto

z - surround

a - add

(text object pending)
iw - inner word

(and finish with the surround you want - this help text actually shows up in the status bar in VSCode as well)


v1.6 unknown bug

I tested v1.6 in another language (Japanese), very strange to get unknown error.

I was just messing with the site, it might be fixed now. Can you try Ctrl-F5?

I was just messing with the site, it might be fixed now. Can you try Ctrl-F5?

OK


Fixed header and footer

Hi, is there way to make fixed headers and footers?
Like in ng-grid:

Thanks!

Can you give me a perspective, if or when you will re-visit this feature/enhancement.
Currently we use you're grid with server side request, sorting, filtering and paging. We tweaked a lot on style but I don't want to do this tweak, too. If there is no plan for fixed header/footer on your side, we will build the grid without table html self, with angular or react.

Sorry I don't plan on revisiting this feature.

Allright, thanks for the fast response and this good module.
It helped me a lot while starting with angular / SPA.


🎨 Changed post/page date picker format to 'YYYY-MM-DD'

refs TryGhost/Ghost#10767
The use of the date format 'MM/DD/YYYY' is confusing to those not in American English locations. In the absence of being able to dynamically determine full locale data, using 'YYYY-MM-DD' seems to the least ambiguous date format which would be intuitive to most users.

+1 for ISO 8601. As a user not from the US, I would very much appreciate this change.

Great stuff, thanks @kevinansfield and @paulperkins !

Thanks, @kevinansfield! And thanks to @seanhamlin for the supportive words :)

Thanks both of you for this change! ISO 8601 definitely feels correct and what we should be using for an international audience :)


Folder and file names mangled with (1)

I am using google-drive-ocamlfuse, version 0.5.22 to keep a backup of a google drive shared amongst several users.
The drive is mounted read only using:
google-drive-ocamlfuse -label example 	$HOME/example 	-o ro,allow_root
Some files and folders are presented with "(1)" or "(2)" appended to the names. The "appendages" are not present on the www version of the drive. e.g:
"Folder/Filename.pdf" is presented ocamlfuse mound point as "Folder (1)/Filename(1).pdf"
This does mean my backup can not be restored to an original state.
config:
async_upload=false
client_id=
client_secret=
conflict_resolution=server
connect_timeout_ms=5000
curl_debug_off=false
debug=false
delete_forever_in_trash_folder=false
docs_file_extension=true
document_format=odt
document_icon=
download_docs=true
drawing_format=png
drawing_icon=
force_docs_export=true
form_format=ods
form_icon=
keep_duplicates=false
large_file_threshold_mb=16
low_speed_limit=0
low_speed_time=0
map_format=desktop
map_icon=
max_cache_size_mb=5120
max_download_speed=0
max_retries=10
max_upload_speed=0
metadata_cache_time=600
new_revision=true
presentation_format=pdf
presentation_icon=
read_only=false
spreadsheet_format=ods
spreadsheet_icon=
sqlite3_busy_timeout=50000
stream_large_files=false
umask=0o002
verification_code=

Files are renamed appending a suffix like "(1)", "(2)", if there is more than one file with the same name in the same folder. As there is no way to keep two files with the same name in the same directory on a UNIX file-system (while Google Drive permits), I have to disambiguate them. If you don't want to have those suffixes, be sure to rename the files so that are no duplicates (in the same folder).

Much appreciated. However,  in these cases there are no duplicate versions showing on the google drive listing at https://drive.google.com. e.g. I will struggle to fix by renaming because they are not actually ambiguous. :-)

Just to add there may well have duplicates at some stage in the past. However, not now.  Is there some kind of extra meta data update needed? -cc does not fix.

No, -cc should do. But you can try removing ~/gdfuse/default/cache with rm -r. If it doesn't work yet, please activate debugging output (with -debug), do an ls -R of your mount point, and send gdfuse.log and curl.log to my email (alessandro.strada@gmail.com). Thanks

Doh.  Yes -cc fixed. Sorry, I had omitted to use the -label option to point to the correct cache.

OK, no problem.


Update Two Old Links

thanks @thegreatfatzby for the fix. btw our source of truth is the "main" branch. if you have some time to kill it'd be helpful to send PR to that branch. otherwise we can do it internally

This is fixed on main