'peers' event on on SignalingConn emits 'added' peer from peer's close event

Checklist

[X] Are you reporting a bug? Use github issues for bug reports and feature requests. For general questions, please use https://discuss.yjs.dev/
[X] Try to report your issue in the correct repository. Yjs consists of many modules. When in doubt, report it to https://github.com/yjs/yjs/issues/

Describe the bug
class WebrtcConn {
   ...
   peer.on('close' => ... announceSignalingInfo(room))
}

generates an announcement which triggers remote peers:
class SignalingConn {
             ...
             case 'publish':
             ...
             room.provider.emit('peers', [{
                removed: [],
                added: [data.from],
                webrtcPeers: Array.from(room.webrtcConns.keys()),
                bcPeers: Array.from(room.bcConns)
              }])

message peers then says this peer was added which is not what's happening, as peer is closing.
To Reproduce
Steps to reproduce the behavior:
Open two browsers with peers connected. Listen to room.provider.peers for 'peers' and you'll see the event.removed shows the peerId, but then another events.added shows the peer added again
Expected behavior
When a peer closes, it should not generate a peers event that has the peer added.
 Are you sure that the client is disconnected when added:webrtc:[98ee6477-5037-49ee-bd20-b8f69928dade]  is fired?

Yes.
When I review y-webrtc for the close, (this.peer.on('close', () =>...) the last line is announceSignalingInfo(room) which triggerS:
const announceSignalingInfo = room => {
  signalingConns.forEach(conn => {
    // only subcribe if connection is established, otherwise the conn automatically subscribes to all rooms
    if (conn.connected) {
      conn.send({ type: 'subscribe', topics: [room.name] })
      if (room.webrtcConns.size < room.provider.maxConns) {
        publishSignalingMessage(conn, room, { type: 'announce', from: room.peerId })
      }
    }
  })
}

there's the debugs you're seeing. 'true' is conn.connected. So on close, it's announcing signically messages, even though it's closing.
My naive understanding suggests it shouldn't be announcing or, this shouldn't say 'added' from the message :
            const emitPeerChange = webrtcConns.has(data.from) ? () => {} : () =>
              room.provider.emit('peers', [{
                removed: [],
                added: [data.from],
                webrtcPeers: Array.from(room.webrtcConns.keys()),
                bcPeers: Array.from(room.bcConns)
              }])

There are three types of connections. 1. There are WebRTC connections. The line you mentioned this.peer.on('close', () =>...) is referring to a webrtc conenction. 2. There are BroadcastChannel connections (connections to other peers in the same browser are not handled via WebRTC). 3. There are Websocket connections to a signaling server. announceSignalingInfo sends a message to the websocket/signaling server.  When a WebRTC connection closes unexpectedly, we announce ourselves over the signaling server again to reconnect to the closed connection. After a time, the remote client reconnects (either using 1. WebRTC or via 2. BroadcastChannel) and the peers: {added: [..]} event is fired.

alright, what I'm seeing:
    this.peer.on('close', () => {
      this.connected = false
      this.closed = true
      if (room.webrtcConns.has(this.remotePeerId)) {
        room.webrtcConns.delete(this.remotePeerId)
        room.provider.emit('peers', [{
          removed: [this.remotePeerId],
          added: [],
          webrtcPeers: Array.from(room.webrtcConns.keys()),
          bcPeers: Array.from(room.bcConns)
        }])
      }
      checkIsSynced(room)
      this.peer.destroy() ***// should this just be 'this.destroy'***
      log('closed connection to ', logging.BOLD, remotePeerId)
      announceSignalingInfo(room)
    })

the announceSignalingInfo call triggers the announcement and the second client gets a 'peers' notification as the peer being added.
It's possible it's a race condition since I'm just doing it locally between two browsers or it's something stranger with the devserver updating.

How do you close the connection to the remote client?

refresh the browser -> close is triggered
If it was re-logging in, we'd have a different peerId, but the same peer ID shows up on the second client.  WebrtcProvider {…}

It's possible it's a race condition since I'm just doing it locally between two browsers or it's something stranger with the devserver updating.

This is probably the reason. A devserver often duplicates created objects. Sorry, it is impossible for me to debug this issue. Unless you provide a step-by-step example for how I can reproduce this (without some react dev-server setup) I can't help you.
Can you maybe create a simple project (maybe fork https://github.com/yjs/yjs-demos) and describe the steps to reproduce this issue?

it appears to be chrome specific. I upgraded the demo here:
https://github.com/disarticulate/y-webrtc/tree/master/demo
Reproduce:

open 2 chrome threads (not in same window):

/usr/bin/chromium-browser --user-data-dir=$root/chrome1 --password-store=basic http://localhost:8080/demo/ &
/usr/bin/chromium-browser --user-data-dir=$root/chrome2 --password-store=basic http://localhost:8080/demo/ &

open a firefox browser (just to double check)

wait till added:webrtc:[peerId]

close chrome or refresh chrome

observe console:

removed:webrtc:[fb8ba1ec-759c-4b57-a6d5-fb5f9a19b780] index.js:13:12
synced!
Object { synced: false }
index.js:25:10
Object { _readableState: {…}, readable: true, _events: {…}, _eventsCount: 2, _maxListeners: undefined, _writableState: {…}, writable: true, allowHalfOpen: false, _id: "f240014", channelName: "7a260e731074938719ec8719f2e19adf96eb1458", … }
SimplePeerExtended.js:44:12
added:webrtc:[fb8ba1ec-759c-4b57-a6d5-fb5f9a19b780]

You may want to use the standard SimplePeer if you think I did something untoward to it.
I'll comment on the rest of that code in the other issue I've got open https://github.com/yjs/y-webrtc/issues/20


Popovers are overridden by the sheet

Let's look at the diagram first

Popovers are overridden by the sheet, and the rendering is below the layer of the sheet
The popovers used are version 1.3.0

Interesting. Are you running iPadOS 15? This might be because of some new multitasking sheet behaviors that Apple added. I'll look into it.

yes

the problem is the popover is over the window, not over just the view, I think


Adopt new make targets from OpenStack cloud provider

Since we changed our makefile in kubernetes/cloud-provider-openstack [1]
We need to update tests accordingly.
This also correct [2] to use consist image names as previously have.
(So we still will have one same old docker image name)
[1] https://github.com/kubernetes/cloud-provider-openstack/pull/910
[2] https://github.com/theopenlab/openlab-zuul-jobs/commit/95ca894d4ffa44a4f6a8389eb317003cbe0d3c5c

@ramineni please help to review this, thanks

relate to https://github.com/kubernetes/cloud-provider-openstack/issues/883

@ricolin looks good to me, could be improved again once dependencies are merged, Thanks for the work on this.

@ricolin looks good to me, could be improved again once dependencies are merged, Thanks for the work on this.

@ramineni that's what I should do :)

Will keep an eye on http://status.openlabtesting.org/builds?project=kubernetes%2Fcloud-provider-openstack&pipeline=periodic-14	 to see if everything works for stable branches


Hello world sample does not run

Hello! I'm new to the whole idea of DI and figured I'd give the examples a shot, see if I could figure it out on my own. However, when pasting the "hello world" example from the documentation and validating it, I get the following error:
ZenjectException: Assert hit! Scope must be set for the previous binding!  Please either specify AsTransient, AsCached, or AsSingle. Last binding: Contract: Greeter, Identifier: NULL  Rethrow as ZenjectException: Scene 'Scene' Failed Validation!
I can see that those who already know how Zenject works will be able to fix it, but a newbie like me has no idea. An amendment to the documentation might be necessary?

Thanks - This was a bug in the hello world example  :)   Fixed now

Cheers to the incredibly rapid response and fix 👍


Added pinups and homepage to Sinner Comics ripper

Category
This change is exactly one of the following (please change [ ] to [x]) to indicate which:

[ ] a bug fix (Fix #...)
[x] a new Ripper
[ ] a refactoring
[ ] a style change/fix
[ ] a new feature

Description
I added two new rip modes to the Sinnercomics ripper: pinup ripping (for a single image) and homepage ripping to rip all pinups.
Testing
Required verification:

[x] I've verified that there are no regressions in mvn test (there are no new failures or errors).
[x] I've verified that this change works as intended.

[x] Downloads all relevant content.
[x] Downloads content from multiple pages (as necessary or appropriate).
[x] Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.

[x] I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

[x] I've added a unit test to cover my change.
(I modified the relevant test)

Please note the test failure is entirely due to another Ripper I did not touch, it also fails on the current master branch.

Looks good to me


wip toggle anon zaps

getting close on ui / logic but the zaps don't seem to be happening @benthecarman

Fixed the zaps, was a problem with https://github.com/MutinyWallet/cloudflare-lnurl

When I was testing, noticied some weirdness with the confirm send button not being enabled when it should

Is this good to merge?

yeah just retested it looking good gonna merge


Need support on how to implement custom theme for material

Bug, feature request, or proposal:
This is more a cry for help, can I see an example of how to implement setup my project to use a different material theme other than the default one ? No sure how to make this work across all my components
What is the expected behavior?
n/a
What is the current behavior?
n/a
What are the steps to reproduce?
n/a
Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: http://plnkr.co/edit/o077B6uEiiIgkC0S06dd
n/a
What is the use-case or motivation for changing an existing behavior?
n/a
Which versions of Angular, Material, OS, browsers are affected?
n/a
Is there anything else we should know?
n/a

there's not any way at the moment, what you could do is modify these https://github.com/angular/material2/blob/master/src/core/style/_default-theme.scss#L9 and create your own build

See #123


hideWhenNothingPlaying

Hi,
I try to add some configuration options but it don't work
Ca you help me?
Thanks

It looks like you're missing a common after the 'xPlexToken' value, which causes the file to be invalid JavaScript.

thanks you very much and sorry for the noobs error.
Have a nice day
PS : have you a command to hide the mail of the plex account?
Thanks

To hide the email address they would actually need to make an account name vs using their email as there account name. This can be found under the account tab in plex. https://app.plex.tv/desktop#!/settings/account

I don't know if you understand my question.
I don't want see my account email here

Thanks

Yep I know exactly what you want. Also try logging in with your username vs the email.

Hi @sly83910, this module currently supports two ways to accomplish what you want.
First, you can hide the user information (which includes both the avatar image and account name) with the showUser which can be set to false.  Here is an example with your config:
config: {
    serverProtocol: "http",
    serverAddress: "<IP_ADDRESS>",
    serverPort: 32400,
    xPlexToken: "<your_token>",
    hideWhenNothingPlaying: true,
    showUser: false
}

The second option is to override the username with the userNameFilter option.  Which, I guess could be used to replace it with an empty string.  Here is an example:
config: {
    serverProtocol: "http",
    serverAddress: "<IP_ADDRESS>",
    serverPort: 32400,
    xPlexToken: "<your_token>",
    hideWhenNothingPlaying: true,
    userNameFilter: {
        "<account_email>": "<display_value>"
    }
}

In this example, the <account_email> value will be replaced with the <display_value> when the module renders the content.  The down-side of this method is that a filter is required for every email address or username that you want to hide.  Also note: any number of filters can be added to the userNameFilter list.

Hi glitch 452,
The command showuser don't work but usernamefilter yes, juste avatar show up, it's ok for me !!
Thanks you both you can close this issue


Parsing of quotes in url values for fonts/imported styles

YSLOW.peeler.findImportedStyleSheets returns components with URL values still containing ending quotes causing YQL request to fail.
Test case:
Use the Bookmarklet in Firefox 10 on https://developer.mozilla.org/
Run the test. Test fails because of URLs containing ending quotes for fonts.

Apologies for the duplicate issue. Closing this.


Add "x-ob-url" header dynamically in IG

The x-ob-url header must be provided to the resource server. This URL will be added by the resource server on the "Self" claims on the response. Currently this header is hardcoded in postman.
To Reproduce
Send a valid resource access request without the header from postman (for example /accounts). The error thrown by the resource server is:
{"Code":"OBRI.Request.Invalid","Id":"4ff9f7f5-eda2-44ba-b98d-57ee15fce891","Message":"An error happened when parsing the request arguments","Errors":[{"ErrorCode":"UK.OBIE.Header.Missing","Message":"Missing request header 'x-ob-url' for method parameter of type String","Path":null,"Url":null}]}
Expected behaviour
IG should build the header formed with the following rule:
request.getHeaders().get("X-Forwarded-Host") + request.path
Current behaviour
The requests fail if the header is not manually added on the request from postman or any other tool.

@BohoCode, @jorgesanchezperez  need your opinion on this. Would it be better to build the links by using the rs.fqdn, or an incoming request header?

@mariantiris Alternatively could the X-Forwarded-Host be used in the RS instead of the x-ob-uri?

I think it would be better to avoid relying on any headers not documented in the OB spec where possible.
Even though X-Forwarded-Host is a defacto standard, it is not documented in the spec, also the x-ob-url  header appears to be something we have invented. Any deviations from the spec would need to be documented and maintained by us, which I think we would rather avoid.
Therefore I think the configuration based approach is better.

This is causing the FAPI test suite to fail, as the test suite implements the OB spec and therefore does not pass the x-ob-url

So the x-ob-uri is required by the RS and is used to build the self links required in the response.
In old projects it was provided by the gateway using;
new ServletServerHttpRequest(request).getURI().toString()
This would

Return the URI of the request (including a query string if any, but only if it is well-formed for a URI representation).
Which I take to mean it would return the full URI including path.

I've raised a separate issue to unblock the FAPI suite, this will set the header within IG.
https://github.com/SecureBankingAccessToolkit/SecureBankingAccessToolkit/issues/672
This issue can remain open in order to figure out and implement the best solution to the issue.

Fixed in #1035
Controllers in the RS now use Spring HATEOAS to create self links, the x-ob-url header can now be removed from the IG routes.


Adding a template to refactored note [enhancement]

Currently I write notes on a subtopic in my topic note and refactor them when I have enough for a subtopic note. Now I have to manually add a template and a link to the topic in the subtopic note.
It would be great if the refactoring could add a template automatically to the refactored note.
In the template I would like to include a placeholder. This placeholder should then be transformed to a link to the note from which I performed the refactoring action. (So more functionality than the standard Obsididan templates.)
Would this be possible?

So, the template for the content replacing the refactored note content in the original note could be something like this?
**Related Idea**
[[{{new_note_title}}]] #refactored

OR
#### See also

![[{{new_note_title}}]]

# {{title}} <!-- this functionality is already implemented with the "first line of selected text as heading -->

<here is where the refactored text goes in the new note>

---

**↑:**
[[<link to note from which I performed the refactor>]]
**vgl.:**

**Verweis:**

**Status:**
#
**Datum:**
{{date}}
**Links zu dieser Seite:**

This is my template for creating new notes . Under the arrow I always link to the note that is above it in the hierarchy, so in this case where I performed the note refactor. Currently I do this by hand.
In fact I don't want to add a template to the original note.
The current behaviour of inserting a link to the refactored note is not my optimal workflow, I mostly move it to the end of my original note (that's how I link downwards in the hierarchy).
I'm not sure whether it would be a lot of work to make a toggle for it to either insert the link to where the refactoring happened or to the end of the original note.
@mrjackphil's plugin (https://github.com/mrjackphil/obsidian-crosslink-between-notes) has this behaviour when linking a note up in the hierarchy by pressing a hotkey, that is what I would like to happen when I refactor a note.

Got it, thanks for the additional details. I think I have all I need to implement.

Available in version 1.5.0.


note about location/file type of AcceptanceCase

@keathley ping

Not sure, it needs the note as the sample path already says .ex and if you are in a Phoenix project already there's also model_case/conn_case and friends lying around there :)

I think I agree with @PragTob. I'm not sure that we need to explicitly state this. Really, I would rather automate the generation of an acceptance_case.ex for people so we can simply avoid these types of issues. I'm going to close this for now. @Ch4s3 if you wanna help with automating this task via. a mix task let me know and we can discuss how that might be implemented.

I'm a little fuzzy about why I wanted this in the readme. I'll take a look at automating it.


Mechanically prevent AME sabotage

About the PR
Mechanically prevent the AME from exploding to assist in removing the rule on station sabotage.

When the AME is put in to a state in which it would overload prior to 30min the injection status will display a safety alert and revert back to the safe level of operation for the amount of cores.
Post 30min the AME will behave as normal and explode on overloads. Will also show an overload message on the injection status.
Fixed initial status not showing not in 'Not Injecting'
Colorized injection status so my smooth brain knows green good, red bad. Will help with new players mistakenly turning too high too.
Added audio alarm to overloading state that is on the AME controller
Added engineering radio alert to warn of the overload.

Why / Balance
From the chats and movement for less rules and more mechanical solutions: #20064
Technical details
When AME calculations are done for power/ overload, it will reset the injection level for next cycle and flag the UI update message to know to give overload or warning message if below defined sabotage timeout.
Media
Prevention:
https://github.com/space-wizards/space-station-14/assets/47093363/3cbded34-7324-49d6-8725-38e56568ce39
Alerting:
https://github.com/space-wizards/space-station-14/assets/47093363/c6087c34-8d13-4f85-b8d6-31d0deb51d4b

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes
No breaking changes.
Changelog
Add lockout for AME so can't be detonated prior to 30min, also has some new injection statuses.
:cl:Repo

tweak: AME now has safety features to prevent its overload prior to 30min.

The time should be a cvar rather than being hardcoded.

maybe made alert sound quieter and send message about overloading in emgi channel like in admin

The time should be a cvar rather than being hardcoded.

Thanks, I didn't know what they were called in here, added it in now.

maybe made alert sound quieter and send message about overloading in emgi channel like in admin

Dropped the sound a bit and put some contextual messages based on how unstable it is.

Depending on how it is detonated it could show many messages if it was just over the safe injection or maybe just one or none if someone dumps 50-100 injection on to it.

Won't it be much better if you removed all hardcode of "nuh-uh can't explode till 30 minutes for reasons" and just left AME with an in-built alarm for Engi channel?
Either for overloading and risk detonations or just in general:
[Engineering] AME controller says, "AME injection levels have been modified"

that wouldnt account for welding a part but leaving injection alone

that wouldnt account for welding a part but leaving injection alone

then make it always scream over radio once it detects injection as dangerous

Won't it be much better if you removed all hardcode of "nuh-uh can't explode till 30 minutes for reasons" and just left AME with an in-built alarm for Engi channel?
Either for overloading and risk detonations or just in general: [Engineering] AME controller says, "AME injection levels have been modified"

The main issue is not that it needed more alerting but to try and mechanically prevent the overload in the first 30min, Either a troll/shitter/Newbie will overload the AME in the first 30min effectively ruining the round. There is already a rule here to try and prevent this and an admin notification but it still happens...often.

that wouldnt account for welding a part but leaving injection alone

So i had a quick test on it and if you un-weld and knock a 3 core down to a 1 core and the injection stays the same.

The first safety one will reduce injection back to safe level 2x core injection rate, so no risk at all of overload.
The post 30min overload time will trigger the overload/stability system but with how it works depending on the cores and injection it will have plenty of warning 2min+.

Here are some nerd graphs because I was interested. These didn't include random instability factors, but generally it will give a good idea.
I have different engi radio warnings at the warning lines:

TLDR: Fastest you can overload is 50seconds, roughly.

How will this work on nuclear operatives, where detonating AMEs is common practice?  Especially during a hidden game.
Don't you think 30 minutes is too much?

In addition, we have mentor roles - who must monitor and train newcomers, explaining how AME works and what happens when it is rebooted.

How will this work on nuclear operatives, where detonating AME is common practice? Especially during a hidden game. Don't you think 30 minutes is too much?

Most likely outcome is the current Nukie gameplay is unchanged maybe with a slight delay for the ones that really want to destroy AME for some reason.
Anecdotally, most Nukie games I've seen never make it to the station prior to 30min.

Stealth-ops, a later time might even have a better effect as people are more unaware.
War-ops, up to 5min to decide 15min timeout, 5-10min get all the cats on to the shuttle and FTL to station. You're pretty much at 30min give or take a little.
Normal-ops, generally i would say AME is low priority, Order of priory in this style for me would be: Armory, Grav, Cargo, Telecoms. Beside the actual objective nuke disk and nuke. Even when the AME goes the SMEs are going to keep it going for a while so low benefit to active targeting.
A exception for Nukie would not work either as soon as someone sees AME blow prior to 30min everyone would scream nukie.
Benefit of not having the round ruined often because some shitter blew the AME vs nukies having to wait 5-10min extra to blow the AME seems like a good trade off.

In addition, we have mentor roles - who must monitor and train newcomers, explaining how AME works and what happens when it is rebooted.

This sounds like a non-issue, why cant the Senior just tell them, this change doesn't prevent them from talking about it? Example: Senior Engineer: "This is the AME Controller, Set it to inject at 2x the amount of cores. If you set it higher it will overload and explode once it has warmed up."
Technical assistant: "How long does it take to warm up?"
Senior engineer: "30 minutes."

I'm against artificially limiting the amount to safe levels for the simple reason of retaining player agency.
A lightly overloaded AME (like 1-core 6-fuel) can be a conscious choice of the engineering department to boost power production with the drawback of higher fuel consumption and really having to pay attention to prevent explosions. Taking this choice from the available options will further degrade the possibilities of what one can do with an AME - and most discussions on the topic that I've heard are about how to make the AME MORE interesting, not even less interesting.
A compromise from my perspective would be a setting where the AME can't be overloaded beyond the "semi-stable" levels (max. of core-count + 5). At those levels, it will take a long time to degrade (16+ minutes, more likely 20+) which in turn already is more or less in line with the rules since the AME will likely not get overloaded at round start.
I would also scale down on the chat-warnings. One or two are a nice addition, but just putting everything that happens into a chat message would shift the focus from a world-based RPG to a text-based RPG. Engineering should have some clue on what is happening at their department without getting everything presented in the chat.

I'll bring it back in to draft for now as it seems like there is still some decent discussion to be had.

I'm against artificially limiting the amount to safe levels for the simple reason of retaining player agency.
...how to make the AME MORE interesting, not even less interesting.

I'm also aligned to this and you made some good points.

A compromise from my perspective would be a setting where the AME can't be overloaded beyond the "semi-stable" levels (max. of core-count + 5). At those levels, it will take a long time to degrade (16+ minutes, more likely 20+) which in turn already is more or less in line with the rules since the AME will likely not get overloaded at round start.

I'll put the conditions here because this is what is going to determine it the alerts, overload and safety switch.
        // The AME is being overloaded.
        // Note about these maths: I would assume the general idea here is to make larger engines less safe to overload.
        // In other words, yes, those are supposed to be CoreCount, not safeFuelLimit.
        var instability = 0;
        var overloadVsSizeResult = fuel - CoreCount;

        // fuel > safeFuelLimit: Slow damage. Can safely run at this level for burst periods if the engine is small and someone is keeping an eye on it.
        if (_random.Prob(0.5f))
            instability = 1;
        // overloadVsSizeResult > 5:
        if (overloadVsSizeResult > 5)
            instability = 5;
        // overloadVsSizeResult > 10: This will explode in at most 5 injections.
        if (overloadVsSizeResult > 10)
            instability = 20;

With this are we talking about still having the safety switch go on in these situations, for reference instability is removed per injection from 100 for simplicity:

1 instability-16min(Fails every coinflip on every injection) to Never overload) = Alert to engi radio/ No audio warning/ No safety override.
5 instability(3min overload) = Alert to engi radio/ No audio warning/ Safety override before 30min.
20 instability(50s overload) = Alert to engi radio/ Audio warning/ Safety override before 30min.

The 16min and 3min overloads, im pretty sure an engi would see and be able to travel respond to the overload within the time frame. The 50s there is little chance to get there in time unless you were already in engineering and you immediately saw the warning.

I would also scale down on the chat-warnings. One or two are a nice addition, but just putting everything that happens into a chat message would shift the focus from a world-based RPG to a text-based RPG. Engineering should have some clue on what is happening at their department without getting everything presented in the chat.

Yeah I'd agree with you here too, the alerts are going out every injection. Probably reducing them down to one alert when it has passed the threshold would be better so with the current instability levels of 10,30,60,90 triggering alert levels it would only have one alert per passing threshold. So on the 3 trajectory's of overloads, 4 alerts per overload cycle:

16min overload - about every 4min
3min overload - about every 45sec
50s overload - about every 13sec

I'm going to close this for now, It feels like its moved in another direction with just preventing by making the overload take longer rather than alerting engi.


Fix mount configuration change check for bind mounts

docker_mount_for() returns Path for bind mounts, which resulted in a type mismatch even when configuration did not change, and users would get spurious warnings.
I modified two tests so that they would catch the bug.
CC @csadorf this is the bug I mentioned in #132.

The CI fail is just Codecov failing to upload, re-running will hopefully fix it.

Yes, let's wait for #132, thanks!
Dne st 22. 6. 2022 8:22 dop. uživatel Carl Simon Adorf <
@.***> napsal:

@danielhollas https://github.com/danielhollas I suggest that we wait
with a release until after #132
https://github.com/aiidalab/aiidalab-launch/pull/132 is merged, but
please let me know if you would prefer for me to make a release right away.
—
Reply to this email directly, view it on GitHub
https://github.com/aiidalab/aiidalab-launch/pull/134#issuecomment-1162743205,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIY64MKHHSXVDEBUEOCWMDVQK5LXANCNFSM5ZNMKK5A
.
You are receiving this because you were mentioned.Message ID:
@.***>


Protection Disabled but still getting STATUS_SEC_AUTH_FILE_NEEDED

MT8167S variant, mt8167 payload seemingly works but SP Tool still reporting STATUS_SEC_AUTH_FILE_NEEDED on readback.
Any thoughts?
bootrom_8167.bin.zip

Was the device rebooted in between?
What DA are you using?
Please run the bypass a second time, providing the initially detected port via the --serial_port option and post the results.

Device wasn't rebooted - but it didn't stay sat in brom, went back to fastboot before I could run it a second time.

Also the -t dump doesn't seem to work, incomplete file of varying sizes - but always <2kb.

Sounds like there may be an issue with the USB connection.
Maybe try different cables, ports, PC.

I suspect you're right re PC.
(Was running under virtual environment).
Need to dig the brick laptop out of the garage to try.
Will mark as closed. Thanks.


Certain variables not being loaded

For some reason when Laravel calls Dotenv::load(), the skip on the following line is being called for just four of my .env variables: DB_HOST, DB_USERNAME, DB_PASSWORD, DB_NAME
This is the skip stopping the variable being loaded into $_ENV
https://github.com/vlucas/phpdotenv/blob/1.1/src/Dotenv.php#L83
After calling the load method, if I call print_r( $_ENV ) these four values aren't present.
This only happens intermittently, for most requests there is no issue.
The host contains dots and the password contains a quote (not at the beginning or end), I doubt this is causing the issue but I thought I'd mention it.
BEFORE calling load, I can get these values using getenv() even though they aren't present in $_ENV or $_SERVER.
I'm using PHP 5.6.8 on windows through XAMPP 3.2.1

I'm also having a very similar issue.

Same issue here, Windows 8, EasyPHP with PHP 5.6.4. Doesn't appear to be happening on Mac OS X.

+1
Any idea on what might cause the issue?

+1
Experiencing intermittent loading of environment variables on Windows 10, WAMP, PHP 5.4. Works probably 99% of the time, then fails on the 1%. Am using $_ENV.

https://github.com/vlucas/phpdotenv/issues/76#issuecomment-167806230


Edits for the weeks of April 1 and 8

got rid of "latest" in requests, use ?setlatestversionid=vID for all cases

becomes "read-only" in the model

"latest" is now sticky, set vid=null to unstick
s/latest/default/g - attribute is now "isdefault" not "latest"
add "setdefault" attribute to Resources
When deleting old versions, skip sticky one
no longer use arrays, everything is a map

allows us to use output from GET on POSTs and DELETEs

got rid of server-side generation of IDs
added ?inline to PUT/POST requests to indicate if we should import collections
got rid of "immutable" in model as something people can set on extensions

just FYI for core/server-managed attributes

Must use ?meta when doing a POST to create more than one entity
when the createdon/modifiedon features is turned on, after entities have been created, then createdon will remain empty
Resource docs are blobs of bytes, if they can be put into a response "as is" w/o any escpaing then do so, else use RESOURCEbase64
almost any change is allowed to the model

provide some guidance for how to deal with non-conformant entities

allow extension attributes to the model definitions
tons of rewriting
added a simple spell checker to CI/CD script

Approved on the 4/11 call


fix(persisted-scope): Save asset protocol patterns

https://discord.com/channels/616186924390023171/1124318735809904710

actually, we're never reading these paths so this pr is still useless, gonna update it...


Implement generateInvoice2goInvoice() Appwrite Function ⚡

Introduction
Appwrite Functions allow you to extend and customize your Appwrite server functionality by executing your custom code 🤩 You can learn more at our official Appwrite Functions docs.
Your task is to implement generateInvoice2goInvoice function. You can look at the existing Appwrite Functions demo in the coding language you prefer to see how it works.
This function should trigger on database.documents.create event, get content of the document and use it to generate Invoice2go invoice. Finally, save the invoice to Appwrite Storage.

Please make sure to store all configurable parameters as environment variables, so others can start using your script without having to edit it. If some data is different for each execution, make sure to use APPWRITE_FUNCTION_EVENT_DATA or APPWRITE_FUNCTION_DATA environment variable.

Tasks summary:

[ ] Fork & clone this repository
[ ] Create feat-implement-generage-invoice2go-invoice-X branch where X is programming language you used
[ ] Write code for the function
[ ] Test the function using Appwrite
[ ] Write a README.md explaining what function does, how to use and customize it. Here is an example.
[ ] Submit pull request

If you need any help, reach out to us on our Discord server.
Are you ready to work on this issue? 🤔 Let us know, and we will assign it to you 😊 There are 9 languages in which you can implement this function. When requesting to be assigned, please mention which language would you like to use.
Assignees table
✅ = Done - This language has already been finished
⚒ = In progress - Someone is already working on this language
❌ = Unassigned yet - This language can be assigned to you

Function / Language
Deno
NodeJS
PHP
Python
Ruby
Dart
.NET
Java
Kotlin

generateInvoice2goInvoice
❌
❌
⚒ niyoj
❌
❌
❌
❌
❌
❌

Happy Appwriting!

Can you assign this task to me? I will be  very happy to contribute. I would like to work with PHP language,

@niyoj Assigned it to you! All the best 🚀

@Meldiron Will be sending a PR soon.

Can I get some hints regarding how to generate invoice2go invoice? I looked over the documentation in invoice2go but there is nothing I found that can be used to generate the invoice by giving the data from documents. May be I got wrong. So can you give me a little hint or reference that can be used.

@niyoj Hmm I just checked with them and it looks like they don't support API communication yet. I am sorry for the complications, but we will need to wait for their implementation before continuing this issue.

@Meldiron So, I think I will be working on another issue till then.


Use Quartz for job scheduling to support cluster deployment

@jeeyi Moving job scheduling to use Quartz instead of spring basic support. This to be able to deploy a mojito cluster. It also makes some of or scheduling smoother. This is a relatively big change so heads up!

@aurambaj If this is a big change, I'd like to create a release tag before you merge with the latest UI fixes from Edwin and async TM export.

@jeeyi sure!

@aurambaj FYI, I used V27. Now you have to rename V27__Quartz.sql to V28__Quartz.sql.

@jeeyi @ehoogerbeets maybe this PR will help with plural support since it is re-enables PluralFormUpdater as one time job to run.
Let me know if you want to cut the release before it or if i should push now.
@jeeyi  If you don't want this included, can you do the release soon so that I can push that?


Update role for setup to other systems: Debian

90% of the functionality is HAProxy specific and it would be easy to make the role work on CentOS and Ubuntu;
This is not needed right now, but might be useful in the future if we need loadbalancing on Docker based hosts (perhaps use Docker?)

Looking at the package situation in RHEL for HAProxy it makes most sense to support Debian for now


Align components of side and navbar

Description
There an icons that's in a wrong position and need to aligned.

I am not able to reproduce this error of the position of the logout button. Has this bug already been fixed?

This has been fixed already :D


Improve OrthographicCamera consistency and usability

Objective

Terminology used in field names and docs aren't accurate
window_origin doesn't have any effect when scaling_mode is ScalingMode::None
left, right, bottom, and top are set automatically unless scaling_mode is None. Fields that only sometimes give feedback are confusing.
ScalingMode::WindowSize has no arguments, which is inconsistent with other ScalingModes. 1 pixel = 1 world unit is also typically way too wide.
OrthographicProjection feels generally less streamlined than its PerspectiveProjection counterpart
Fixes #5818
Fixes #6190

Solution

Improve consistency in OrthographicProjection's public fields (they should either always give feedback or never give feedback).
Improve consistency in ScalingMode's arguments
General usability improvements
Improve accuracy of terminology:

"Window" should refer to the physical window on the desktop
"Viewport" should refer to the component in the window that images are drawn on (typically all of it)
"View frustum" should refer to the volume captured by the projection

Changelog
Added

Added argument to ScalingMode::WindowSize that specifies the number of pixels that equals one world unit.
Added documentation for fields and enums

Changed

Renamed window_origin to viewport_origin, which now:

Affects all ScalingModes
Takes a fraction of the viewport's width and height instead of an enum

Removed WindowOrigin enum as it's obsolete

Renamed ScalingMode::None to ScalingMode::Fixed, which now:

Takes arguments to specify the projection size

Replaced left, right, bottom, and top fields with a single area: Rect
scale is now applied before updating area. Reading from it will take scale into account.
Documentation changes to make terminology more accurate and consistent

Migration Guide

Change window_origin to viewport_origin; replace WindowOrigin::Center with Vec2::new(0.5, 0.5) and WindowOrigin::BottomLeft with Vec2::new(0.0, 0.0)
For shadow projections and such, replace left, right, bottom, and top with area: Rect::new(left, bottom, right, top)
For camera projections, remove l/r/b/t values from OrthographicProjection instantiations, as they no longer have any effect in any ScalingMode
Change ScalingMode::None to ScalingMode::Fixed

Replace manual changes of l/r/b/t with:

Arguments in ScalingMode::Fixed to specify size
viewport_origin to specify offset

Change ScalingMode::WindowSize to ScalingMode::WindowSize(1.0)

Ping @bzm3r for review.

@alice-i-cecile shouldn't this be tagged with "breaking change"?

Yep, thank you!

I have a few minor suggestions but I like the changes! Worth noting this breaks the current 2d examples as is - they all appear way more zoomed in than they should be. But that's just a matter of adjusting the defaults to be closer to how it was before.

Oh, I didn't notice that. That's probably because I made the default for WindowSize 10 since the camera is usually way too zoomed out by default, but I can change it back.

Not sure how I managed to screw up the commit message this much

I'm trying to add a separate "config" struct, but it's a bit of a mess (and might be unnecessarily complicated). Maybe using a builder or just a simple constructor would work better?

Unfortunately no; you can't use struct update syntax unless the fields are pub. I think a builder pattern or an elaborate constructor is the way to go.

Thanks for the change! I salute the documenting part which is much welcome ♥ But I'm more skeptical about the builder pattern refactoring. For one, it feels those two changes are unrelated and should maybe be done in separate PRs. I also personally don't like the pattern so much, mostly as it increases inconsistency with the rest of the Bevy codebase.

I sort of agree with this. Do you have any suggestions for alternatives? Every other method I've looked at has had some other downside. I could also just leave the fields public.

I sort of agree with this. Do you have any suggestions for alternatives? Every other method I've looked at has had some other downside. I could also just leave the fields public.

Because this is the recommended and promoted pattern in the rest of the codebase, yes I would just leave those as public fields for now. We can discuss whether this is the right pattern or not (I doubt we can convince anyone of a change at this point though), but I wouldn't make this object inconsistent unless there's an overwhelming benefit to the builder pattern, which I don't think we showed here.

I sort of agree with this. Do you have any suggestions for alternatives? Every other method I've looked at has had some other downside. I could also just leave the fields public.

Because this is the recommended and promoted pattern in the rest of the codebase, yes I would just leave those as public fields for now. We can discuss whether this is the right pattern or not (I doubt we can convince anyone of a change at this point though), but I wouldn't make this object inconsistent unless there's an overwhelming benefit to the builder pattern, which I don't think we showed here.

That's fair. Clearly documenting that l/r/b/t should be for reading only should be fine for now.

I've been kind of busy lately but I have some time this week for some minor fixes and to test examples. This should be ready for review after that.

@xgbwei once this is rebased I'd like to merge it.

Did I do that right?

Rebase looks almost correct: you have an empty scene_viewer file :)

bors r+


Yet another modification to the addWaypoint function

Since the addWaypoint function deals with waypoints, it makes more sens to pass it a waypoint as an argument, not the click event.
IMO, this makes the code more cleaner.

Thanks. 👍


⚠ Samsung has degraded performance

In 6fe6050, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2899 ms

Resolved: Samsung performance has improved in 3af5d6e.


Get Hyper-Express to feature parity with Express

Hi Kartik,
I hope I'm not to intrusive with this issue. But, pursuant to  our short discussion, I'd like to start this issue to get the ball rolling and to offer a focal point for any other devs and the Hyper-Express community in general, who wish to help you in the endeavor.
The goal is to get feature parity to Express, so that its ecosystem can also be used with Hyper-Express. This also includes the Nest ecosystem (and my personal interest tbh), which just happened to pass Express in Github stars. Both have over 63k stars.
I'll leave it up to the more knowledgeable of you to work out this list. But, this is a start.
Feature parity work with Express:

[ ] Middleware

[ ] Task 1
[ ] Task 2

[ ] Routing

[ ] Task 1
[ ] Task 2

[ ] Other minot/ associated features

[ ] Minor feature 1
[ ] Minor feature 2

It might even be better to work them into their own issues, if the work can be broken down into smaller tasks. I'd be glad to help with that kind of project work, if desired. Just let me know. :grin:
Scott

Hey, so the next major hurdle for achieving feature parity with Express would be the routes / middlewares system.
Currently, HyperExpress takes a different approach from Express.js where Middlewares are executed in a hierarchical manner (Most shallow path to most deep) and Handlers are not middlewares and cannot be yielded. This system can be re-written to match Express.js but would be a major breaking change and likely make existing applications built on top of hyper-express ineligible for uprade unless major work to validate all routes of an existing application were done since the fundamental execution order changes.
Furthermore, there are other minor / associated features which would need to be added although those are not a big issue and not major blockers.
I initially wrote and actively use hyper-express within my own products and a lot of our earlier user and adopters have been around since v4 since which most major changes have not been extremely breaking but rather property renames, removals, schematic changes etc etc.
With the above in mind, the project has attained its identity as "similar" / "familiar" to Express rather than drop-in replacement.
I have also just been extremely busy with my business hence have not had too much time to put towards the next major version.
I think the first step would be to create a discussion which is strictly maintained to contain missing features or incompatibilities between hyper-express and express as mentioned in https://github.com/kartikk221/hyper-express/discussions/218#discussioncomment-8438438
From here onwards, the community can gradually begin to plan and make PRs which can reduce the gap while ideally prioritizing less / non-breaking features first and lower difficulty vs. the more breaking and relatively complex changes such as re-writing the routing system.
I am not sure If you already have a discussion for the above or would like me to make one but I would be glad to provide as much support as I can within limited available time.

You can move this issue to discussions if you like. That would be great.
Would be nice too, if you could at least break down the list of tasks roughly to the best of your knowledge to get the ball rolling. I've enhanced the list from what you wrote above.
Thanks.
Scott


[BUG] Unable to execute macrotext in Dragonflight

🔵 Describe the bug:
GSE currently programs a button and sets the macrotext attribute for the macro to be executed.  This is not functioning in Dragonflight

this is being followed up on via https://github.com/Stanzilla/WoWUIBugs/issues/268

/click behaviour has changed in DragonFlight.  The stub macro now needs to explicitly say LeftButton


deadlock

hey,
I believe there is a deadlock in your code.
I was running benchmarks to measure and compare your code with mine.
I was hit with
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: test/concur
BenchmarkMe-4     	    4653	    234443 ns/op	   10216 B/op	     205 allocs/op
BenchmarkOrig-4   	fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
testing.(*B).doBench(0xc000126480, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:277 +0x73
testing.(*benchContext).processBench(0xc00000c0e0, 0xc000126480)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:570 +0x218
testing.(*B).run(0xc000126480)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:268 +0x65
testing.(*B).Run(0xc000126000, 0x548ce9, 0xd, 0x551778, 0x4c4300)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:655 +0x41b
testing.runBenchmarks.func1(0xc000126000)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:534 +0x78
testing.(*B).runN(0xc000126000, 0x1)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:191 +0xeb
testing.runBenchmarks(0x548814, 0xb, 0xc00000c0c0, 0x623060, 0x2, 0x2, 0x62aa60)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:540 +0x3b5
testing.(*M).Run(0xc000114000, 0x0)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/testing.go:1363 +0x56a
main.main()
	_testmain.go:45 +0x138

goroutine 66550 [chan receive]:
test/concur.runOrig()
	/home/mh-cbon/gow/src/test/concur/main_test.go:59 +0x195
test/concur.BenchmarkOrig(0xc000126480)
	/home/mh-cbon/gow/src/test/concur/main_test.go:73 +0x2b
testing.(*B).runN(0xc000126480, 0x64)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:191 +0xeb
testing.(*B).launch(0xc000126480)
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:321 +0xea
created by testing.(*B).doBench
	/home/mh-cbon/.gvm/gos/go1.15.2/src/testing/benchmark.go:276 +0x55

goroutine 66622 [chan receive]:
test/concur.runOrig.func1(0xc0002b2060, 0xc0000284e0)
	/home/mh-cbon/gow/src/test/concur/main_test.go:44 +0x45
created by test/concur.runOrig
	/home/mh-cbon/gow/src/test/concur/main_test.go:41 +0xdc

goroutine 66621 [chan send]:
test/concur/orig.Process.func1(0xc000016160, 0xc0002b2060, 0x551790, 0xc0001d0018)
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:112 +0x285
created by test/concur/orig.Process
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:36 +0xaf

goroutine 66610 [select (no cases)]:
test/concur/orig.Process.func1.1(0xc0001d0010, 0xc0002b2000, 0xc0000283c0)
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:52 +0x2cf
created by test/concur/orig.Process.func1
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:47 +0x14c

goroutine 66549 [chan send]:
test/concur.runOrig.func1(0xc00013c000, 0xc000028240)
	/home/mh-cbon/gow/src/test/concur/main_test.go:49 +0x66
created by test/concur.runOrig
	/home/mh-cbon/gow/src/test/concur/main_test.go:41 +0xdc

goroutine 66623 [chan receive]:
test/concur/orig.Process.func1.1(0xc0001d0020, 0xc0002b2060, 0xc000028600)
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:52 +0x1c5
created by test/concur/orig.Process.func1
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:47 +0x14c

goroutine 66609 [chan send]:
test/concur.runOrig.func1(0xc0002b2000, 0xc0000282a0)
	/home/mh-cbon/gow/src/test/concur/main_test.go:49 +0x66
created by test/concur.runOrig
	/home/mh-cbon/gow/src/test/concur/main_test.go:41 +0xdc

goroutine 66574 [select (no cases)]:
test/concur/orig.Process.func1.1(0xc0001d0000, 0xc00013c000, 0xc0001ce0c0)
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:52 +0x2cf
created by test/concur/orig.Process.func1
	/home/mh-cbon/gow/src/test/concur/orig/lib.go:47 +0x14c
exit status 2
FAIL	test/concur	2.887s

My test code is
package main

import (
	"math/rand"
	"test/concur/me"
	"test/concur/orig"
	"testing"
	"time"
)

var max = 100
var poolSize = 10
var outputLen = 10

var _ = time.Millisecond
var _ = rand.Intn

func runMe() {
	input := make(chan func() interface{})
	output := me.Process(input, me.Options{PoolSize: poolSize, OutChannelBuffer: outputLen})
	go func() {
		for work := 0; work < max; work++ {
			value := work
			input <- func() interface{} {
				// time.Sleep(time.Millisecond * time.Duration(rand.Intn(1000)))
				return value * 2
			}
		}
		close(input)
	}()
	for val := range output {
		// fmt.Println(val)
		_ = val
	}
}

func runOrig() {
	inputChan := make(chan *orig.OrderedInput)
	doneChan := make(chan bool)
	outChan := orig.Process(inputChan, workFn, &orig.Options{PoolSize: poolSize, OutChannelBuffer: outputLen})
	go func() {
		for {
			select {
			case out, chok := <-outChan:
				if chok {
					// log.Println(out.Value)
					_ = out
				} else {
					doneChan <- true
				}
			}
		}
	}()
	for work := 0; work < max; work++ {
		input := &orig.OrderedInput{Value: work}
		inputChan <- input
	}
	close(inputChan)
	<-doneChan
}
func workFn(val interface{}) interface{} {
	// time.Sleep(time.Millisecond * time.Duration(rand.Intn(1000)))
	return val.(int)
}

func BenchmarkMe(b *testing.B) {
	for i := 0; i < b.N; i++ {
		runMe()
	}
}
func BenchmarkOrig(b *testing.B) {
	for i := 0; i < b.N; i++ {
		runOrig()
	}
}

As you can see runOrig is very much like the main you have demonstrated at stackoverflow.
consider i commented sleep and print instructions to improve the measurements, they were polluting.
The package orig is a copy paste of https://github.com/tejzpr/ordered-concurrently/blob/master/main.go in my local, i only renamed the package name for my tests.
Though, i did not try to debug it, it lacks clarity imho, and that is the reason i did that test to begin with.
I also tried to run the test with the race detector, bad news, it appears your code also contains a datarace
$ go test -race -bench=. -benchmem
goos: linux
goarch: amd64
pkg: test/concur
BenchmarkMe-4     	     382	   3095423 ns/op	    8830 B/op	     204 allocs/op
BenchmarkOrig-4   	==================
WARNING: DATA RACE
Read at 0x00c0003fe020 by goroutine 84:
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:87 +0x138

Previous write at 0x00c0003fe020 by goroutine 49:
  test/concur/orig.Process.func1.1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:69 +0x3b2

Goroutine 84 (running) created at:
  test/concur/orig.Process.func1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:82 +0x234

Goroutine 49 (running) created at:
  test/concur/orig.Process.func1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:47 +0x1ba
==================
==================
WARNING: DATA RACE
Read at 0x00c000018108 by goroutine 34:
  internal/race.Read()
      /home/mh-cbon/.gvm/gos/go1.15.2/src/internal/race/race.go:37 +0x206
  sync.(*WaitGroup).Add()
      /home/mh-cbon/.gvm/gos/go1.15.2/src/sync/waitgroup.go:71 +0x219
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:84 +0x84

Previous write at 0x00c000018108 by goroutine 109:
  internal/race.Write()
      /home/mh-cbon/.gvm/gos/go1.15.2/src/internal/race/race.go:41 +0x125
  sync.(*WaitGroup).Wait()
      /home/mh-cbon/.gvm/gos/go1.15.2/src/sync/waitgroup.go:128 +0x126
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:90 +0x186

Goroutine 34 (running) created at:
  test/concur/orig.Process.func1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:82 +0x234

Goroutine 109 (running) created at:
  test/concur/orig.Process.func1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:82 +0x234
==================
^Csignal: interrupt
FAIL	test/concur	172.097s

Maybe that has to do with the fact i commented the sleep instructions, idk.
for completeness,

i run go1.15.something/probably latest
the code i compared with is available at https://play.golang.org/p/2o4W_BgaC4t though, not really tested, i was just experiencing.

Thanks for this, I did indeed test with load only, the deadlock occurs when there is no load. The safer implementation would be to use Workgroups. I have updated the Readme and the Stack overflow answer.

Closing the issue, since deadlock is not occurring with the updated implementation.

@mh-cbon We can continue the discussion here. I am unable to reproduce the Race conditions on my machine with the current test cases.

even if you cant reproduce the race on your side, reading at the stack trace, it is clear what are the problems here.
see
Read at 0x00c000018108 by goroutine 34:
...
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:84 +0x84

Previous write at 0x00c000018108 by goroutine 109:
...
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:90 +0x186

I removed useless stuff, it corresponds to https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L90 and https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L84
If you check the documentation, https://golang.org/pkg/sync/#WaitGroup If a WaitGroup is reused to wait for several independent sets of events, new Add calls must happen after all previous Wait calls have returned.
This is a clear warning about what to care about when using waitgroups.
For the second race, see,
Read at 0x00c0003fe020 by goroutine 84:
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:87 +0x138

Previous write at 0x00c0003fe020 by goroutine 49:
  test/concur/orig.Process.func1.1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:69 +0x3b2

https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L87
https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L69
two routines are modifying a shared value without synchonization. data race.
Concerning the deadlock, this is tighly related to your logic, to me it is obvious it has problems, hough to prove it i should fully understand it and tbh i was pretty lazy on that aspect of the work.
So anyways, by experience i kew another, cleaner, more idiomatic solution existed.
... it is more resource intensive than the current implementation.
The question is can you prove it ? That basically the question i was about to answer when i hit those issues.

Ah got it. I'll try to fix the code to and remove the race conditions.
Regarding your code, I see there are sort calls in process, which I would like to avoid. If you would like to optimize the implementation you are welcome to create a PR.

cpus are fast, memories are slow, most of the time. Consider that using a map is allocating on the heap. Plus i am not entirely sure it does free up the underlying data, it might be more subtle than that https://github.com/golang/go/issues/20135
In any case a simple win in your implementation is to pre allocate that map to give it an initial capacity greater than 0, outputMap := make(map[uint64]*processInput, 20) or outputMap := make(map[uint64]*processInput, 0, 20). not sure, but the later seems weird.

The initial requirement while implementing this package was that the input size to the worker function is unknown (e.g. A kafka queue) . Which puts predefining the map size out of the scope of the implementation.

you dont get it. It does fix the size of the map. It pre allocates its element to prevent allocating on the fly for the first 20 items. Its a big win in many scenarios. As it is a limitless worker it is even more important to care about that aspect of the implementation as maps does not shrin automatically after a call to delete. anyways. maybe its good enough like this..https://www.youtube.com/watch?v=rLSFy23HAPQ

:) No need to be so sarcastic. This package was made to address a common issue that people face. I agree there are short comings which can be sorted out with civil discussions.

I'll take your recommendations and update it for the next version.

even if you cant reproduce the race on your side, reading at the stack trace, it is clear what are the problems here.
see
Read at 0x00c000018108 by goroutine 34:
...
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:84 +0x84

Previous write at 0x00c000018108 by goroutine 109:
...
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:90 +0x186

I removed useless stuff, it corresponds to https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L90 and https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L84
If you check the documentation, https://golang.org/pkg/sync/#WaitGroup If a WaitGroup is reused to wait for several independent sets of events, new Add calls must happen after all previous Wait calls have returned.
This is a clear warning about what to care about when using waitgroups.
For the second race, see,
Read at 0x00c0003fe020 by goroutine 84:
  test/concur/orig.Process.func1.2()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:87 +0x138

Previous write at 0x00c0003fe020 by goroutine 49:
  test/concur/orig.Process.func1.1()
      /home/mh-cbon/gow/src/test/concur/orig/lib.go:69 +0x3b2

https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L87
https://github.com/tejzpr/ordered-concurrently/blob/master/main.go#L69
two routines are modifying a shared value without synchonization. data race.
Concerning the deadlock, this is tighly related to your logic, to me it is obvious it has problems, hough to prove it i should fully understand it and tbh i was pretty lazy on that aspect of the work.
So anyways, by experience i kew another, cleaner, more idiomatic solution existed.
... it is more resource intensive than the current implementation.
The question is can you prove it ? That basically the question i was about to answer when i hit those issues.

Regarding your points
1
If you check the documentation, https://golang.org/pkg/sync/#WaitGroup If a WaitGroup is reused to wait for several independent sets of events, new Add calls must happen after all previous Wait calls have returned.
This is a clear warning about what to care about when using waitgroups.
The wg.Wait is called only once when inputClosedSemaphoreChan is triggered.

I have fixed the possible race conditions / deadlocks that you helped to identify with this commit https://github.com/tejzpr/ordered-concurrently/commit/a8addfe3a5577c5ed2495fd614112f3ba8e881a2 Thank you! 😊

neat, i have been able to complete my testing, thanks.
$ go test -race -bench=. -benchmem
goos: linux
goarch: amd64
pkg: test/concur
BenchmarkMe-4     	      84	  14206521 ns/op	   60227 B/op	    1976 allocs/op
BenchmarkOrig-4   	      74	  17267334 ns/op	   77919 B/op	    4501 allocs/op
PASS
ok  	test/concur	3.258s

Closing, changes released in v1.0.12

this test suite is even more intersting, it executes only one op, but it does it over a big max value.
https://play.golang.org/p/vHVEtzXsil9
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: test/concur
BenchmarkMe-4     	      73	  14600672 ns/op	 1246658 B/op	   31568 allocs/op
BenchmarkOrig-4   	       1<PHONE_NUMBER> ns/op	80040736 B/op	 4999532 allocs/op
PASS
ok  	test/concur	15.660s

to wrap this up and after some more digging it is possible to improve further the code
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: test/concur
BenchmarkMeManyOps-4     	    4918	    225078 ns/op	    5765 B/op	      45 allocs/op
BenchmarkMe2ManyOps-4    	    4902	    234386 ns/op	   10203 B/op	     205 allocs/op
BenchmarkOrigManyOps-4   	    4677	    265062 ns/op	    7911 B/op	     313 allocs/op
BenchmarkMeOneOp-4       	       1<PHONE_NUMBER> ns/op	50869008 B/op	 2606393 allocs/op
BenchmarkMe2OneOp-4      	       1<PHONE_NUMBER> ns/op	99596640 B/op	 3005669 allocs/op
BenchmarkOrigOneOp-4     	       1<PHONE_NUMBER> ns/op	80024624 B/op	 4999531 allocs/op
PASS
ok  	test/concur	10.856s

The modified lib is https://play.golang.org/p/QKNVE3XEfrF and the test is https://play.golang.org/p/5nwbDiUF6q8
It does avoid to allocate when pushing to the input chan. Previsouly a function was created for each handler, in the new version is takes advantage of struct and interface to reduces allocations.
The internal channels are unbuffered, i noticed it allocates less, and it is also faster, but this is not grounded on science, just facts, it might be subject to changes if the runtime is modified.

Reopening this again :)
I did try out your implementation also created another implementation using golang's container/heap both are available here
Your implementation: https://github.com/tejzpr/ordered-concurrently/tree/workfunction-implementation-mh-cbon
go test -bench=. -benchmem
goos: darwin
goarch: amd64
pkg: github.com/tejzpr/ordered-concurrently
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkOC-12                 1<PHONE_NUMBER> ns/op        112458480 B/op   4008232 allocs/op
PASS
ok      github.com/tejzpr/ordered-concurrently  1.852s

Implementation using heap: https://github.com/tejzpr/ordered-concurrently/tree/heap-workfunction-implementation
╰─ go test -bench=. -benchmem
goos: darwin
goarch: amd64
pkg: github.com/tejzpr/ordered-concurrently
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkOC-12                 1<PHONE_NUMBER> ns/op        85212040 B/op    2999656 allocs/op
PASS
ok      github.com/tejzpr/ordered-concurrently  1.950s

Map based implementation: https://github.com/tejzpr/ordered-concurrently/tree/workfunction-implementation
go test -bench=. -benchmem
goos: darwin
goarch: amd64
pkg: github.com/tejzpr/ordered-concurrently
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkOC-12                 1<PHONE_NUMBER> ns/op        40010344 B/op    2999549 allocs/op
PASS
ok      github.com/tejzpr/ordered-concurrently  1.953s

I am not sure why I am unable to reproduce your numbers, it might be due to OS specific optimizations.
I have also tried the reduced allocation runner with and it does reduce allocations significantly.
 Though, i can not really explain it.

on a pure code review aspect, i dont understand what does this channel des https://github.com/tejzpr/ordered-concurrently/blob/workfunction-implementation/main.go#L104
This definition is problematic, to me: https://github.com/tejzpr/ordered-concurrently/blob/workfunction-implementation-mh-cbon/main.go#L9
Reason is hvng a struct containing a null func member forces the caller to instantiatee a function, allocate. This is the last optimizations i added, the process takes in a chan of Producers (type Producer interface { Produce() interface{} }), thus the caller can instantiate struct value implementing that interface.
Because of map not shrinking automatically, this version must include a control of the map capacity in order to re create it the differrence with len exceeds some ratio.
https://github.com/tejzpr/ordered-concurrently/blob/workfunction-implementation-allocs/main.go#L50
Otherwise, with enough time and usage, you will end up in oom.
While using an Heap seems a good idea, in practice it behaves badly imho. Maybe it is possible to generate an heap implentation of []processInput, which, i believe, will greatly improve its performance. Though, i must say that using a slice is simple, efficient, with a good behavior of memory reuse, and idiomatic.

The channel at https://github.com/tejzpr/ordered-concurrently/blob/workfunction-implementation/main.go#L104 is an artifact from a previous implementation, i'll remove it in v2.
Already removed it in the Workerfunc interface implementation, still the benchmark difference doesn't seem large enough.
I'll spend some time in the weekend and come to a conclusion.

still reviewing, i figured the test were not testing that the output was sorted as expected.
Here is what you could add

func TestSortedData(t *testing.T) {
	t.Run("Test without workgroup", func(t *testing.T) {
		max := 10
		inputChan := make(chan Producer)
		output := Process(inputChan, &Options{PoolSize: 10, OutChannelBuffer: 10})
		go func() {
			for work := 0; work < max; work++ {
				inputChan <- producer(work)
			}
			close(inputChan)
		}()
		var res []int
		for out := range output {
			res = append(res, out.(int))
		}
		if !sort.IsSorted(sort.IntSlice(res)) {
			t.Error("output is not sorted")
		}
		t.Log("Test without workgroup Completed")
	})
}

you can also make use of this error t.Errorf("Invalid output %T", out) (i had some problems with this : / )

For the benchmark, i work two ways, over many instances of the job to complete, over one jpb with zillion entries to see the behavior over a long run.

func BenchmarkOC(b *testing.B) {
	max := 1000000
	inputChan := make(chan Producer)
	output := Process(inputChan, &Options{PoolSize: 10, OutChannelBuffer: 10})
	go func() {
		for work := 0; work < max; work++ {
			inputChan <- producer(work)
		}
		close(inputChan)
	}()
	for out := range output {
		_ = out
	}
}

func BenchmarkOC2(b *testing.B) {
	for i := 0; i < b.N; i++ {
		max := 100
		inputChan := make(chan Producer)
		output := Process(inputChan, &Options{PoolSize: 10, OutChannelBuffer: 10})
		go func() {
			for work := 0; work < max; work++ {
				inputChan <- producer(work)
			}
			close(inputChan)
		}()
		for out := range output {
			_ = out
		}
	}
}

I sligthly updated my version you have checked in, https://play.golang.org/p/YSouN6gLm4H and its tests https://play.golang.org/p/WW0AK9nJNTG
the results are similar here
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: github.com/tejzpr/ordered-concurrently
BenchmarkOC-4    	       1<PHONE_NUMBER> ns/op	80066160 B/op	 3238932 allocs/op
BenchmarkOC2-4   	   12121	     98117 ns/op	    5890 B/op	      49 allocs/op
PASS
ok  	github.com/tejzpr/ordered-concurrently	3.813s

Using a specialized heap implementation the performance are even better.
heap https://play.golang.org/p/vkdGmHKIeIC
main https://play.golang.org/p/0HjGGS7SezU
test https://play.golang.org/p/-lLdrpXxOjz
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: github.com/tejzpr/ordered-concurrently
BenchmarkOC-4    	      57	  18867772 ns/op	  281087 B/op	   35081 allocs/op
BenchmarkOC2-4   	   12655	     97105 ns/op	     401 B/op	       5 allocs/op
PASS
ok  	github.com/tejzpr/ordered-concurrently	22.107s

you can check that version with a specialized heap implementation
not a nice api, added complexity, but it does the job
test https://play.golang.org/p/H09V9f2DvU2
main https://play.golang.org/p/ZE4pLLMo69O
heap https://play.golang.org/p/vkdGmHKIeIC
It is a neat improvement
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: github.com/tejzpr/ordered-concurrently
BenchmarkOC-4    	       2	 954328398 ns/op	16032504 B/op	 1999642 allocs/op
BenchmarkOC2-4   	   12920	     93354 ns/op	     404 B/op	       5 allocs/op
PASS
ok  	github.com/tejzpr/ordered-concurrently	5.568s

Release v2.0.0 I am favoring the heap implementation because of better memory utilization for larger / long running use cases of the library due to https://github.com/golang/go/issues/20135.


Increase the number of results for method feed_tag

Please follow the guide below

Issues submitted without this template format will be ignored.
Rlease read them carefully and answer completely.
Do not post screenshots of error messages or code.
Put an x into all the boxes [ ] relevant to your issue (==> [x] no spaces).
Use the Preview tab to see how your issue will actually look like.
Issues about reverse engineering is out of scope and will be closed without response.
Any mention of spam-like actions or spam-related tools/libs/etc is strictly not allowed.

Before submitting an issue, make sure you have:

[x] Updated to the lastest version v1.6.0
[x] Read the README and docs
[x] Searched the bugtracker for similar issues including closed ones
[x] Reviewed the sample code in tests and examples

Which client are you using?

[x] app (instagram_private_api/)
[ ] web (instagram_web_api/)

Describe your Question/Issue:
I'm trying to extract a set of posts under a certain hashtag.
In order to do so I'm using the following function "feed_tag", but I do not find a way to specify HOW MANY posts I want to get.
I tried with the variable "count" as per other functions, but it doesn't seems to work.
Can you tell me if there is a way?

Paste the output of python -V here:
Code:
api = Client(user_name, password)
api.feed_tag(hashtag, rank_token)

I found a way thanks to @MaximBoyarskiy within issue number #297.
The solution is to use max_id=results['next_max_id'] within the feed_tag parameters.
    while has_more and len(items) < posts_number:
        if "results" in locals():
            results = api.feed_tag(hashtag, rank_token, max_id=results['next_max_id'])
        else:
            results = api.feed_tag(hashtag, rank_token)
        items.extend(results.get('items', []))
        has_more = results.get('more_available')


add badge pointing to latest checkpoint archive and its reference / DOI

What changes does this PR introduce?
(Bug fix, feature, docs update, ...)
Adds a zenodo badge pointing to latest checkpoint archive and its reference / DOI
What is the current behaviour?
(You can also link to an open issue here)
DOI is not evident
What is the new behaviour
(if this is a feature change)?
DOI is shown when entering the repo with a zenodo badge that forwards to the
latest latest checkpoint archive and its reference / DOI
Does this PR introduce a breaking change?
(What changes might users need to make in their application due to this PR?)
no
Other information:
Could be useful to add some text to the effect of "Latest checkpoint: " in front of the badge maybe?

LGTM - Nice work putting in the DOI that always redirects to the latest version.

LGTM


Consider adding lists

Pijama doesn't have a way to store collections of values, limiting what we can write in it. A quick win for this would be to add lists to the language. There are two paths we can take here

Implement lists as a native type: Just as integers and booleans, We'd have a new type List<T> or List[T] to represent lists and all the operations over list would be built-in operations.
Wait until we get algebraic data types: If we implement ADTs first, we can implement lists as a library instead of as a language built-in construct.

The advantages of the first path are:

We can do it now.
It will have a better performance than the ADT approach.
The disadvantages are:
This increases the complexity of the evaluator, type checker and IRs just to add lists.
This might open the path to implementing all the collections as built-in constructs and having no chance of implementing performant collections in the language itself.

Who doesn't love algebraic data types? 😄
That being said, performance is definitely an important consideration for a language like this; I'm sure we'd want lists to be as performant/light weight as possible.
I think I still lean slightly towards ADTs, but that's just me.

I also like ADTs because they let you encode a lot of information in the type system and I want to get there eventually. I was checking what other languages do here and here is the result:

Python: Lists are implemented as arrays inC.
Elixir: Uses Erlang's lists which are linked lists implemented in C.
Haskell: Lists are regular datatypes.
OCaml: I couldn't find anything but I'm under the impression that they are also regular datatypes.

Haskell and OCaml implementing lists as regular datatypes are interesting data points. Does that add some points in favor of implementing them as regular datatypes in Pijama for you?

After discussing it with my pillow, I think ASTs are a better idea in general.
This is just a personal opinion but langauges should feel open and powerful even if there are some performance compromises here and there. And this openness including being able to write your own alternative implementation of a list if you don't like the one the language currently has and be able to match its performance.
There are great languages with top performance out there and we aren't competing with those.

Is there anything blocking us from implementing algebraic data types at this point?

Mmm... I wouldn't say there is anything blocking it really. We just need to figure out how ADTs look in each compilation stage. After we close the other features we have dangling. We can start thinking how they should look.
I think I'm closing this one as it seems it is a better idea to wait for ADTs.


How to use the saved model without retraining?

I am trying to use the model but VGGNet_Model requires the VGGNet function which are the layers itself. Can you provide me the steps to use the pretrained model?

Hi mohammed;
I need  "lenet.config" file to use  "Tensorflow Object Detection API"
How can I write? or where can I find it?
example
SSD with Mobilenet v1, configured for Oxford-IIIT Pets Dataset.
Users should configure the fine_tune_checkpoint field in the train config as
well as the label_map_path and input_path fields in the train_input_reader and
eval_input_reader. Search for "PATH_TO_BE_CONFIGURED" to find the fields that
should be configured.
model {
ssd {
num_classes: 2
box_coder {
faster_rcnn_box_coder {
y_scale: 10.0
x_scale: 10.0
height_scale: 5.0
width_scale: 5.0
}
}
matcher {
argmax_matcher {
matched_threshold: 0.5
unmatched_threshold: 0.5
ignore_thresholds: false
negatives_lower_than_unmatched: true
force_match_for_each_row: true
}
}
similarity_calculator {
iou_similarity {
}
}
...

Same issue.
Trying to use pre-trained graph but keep getting errors and program requires VGGNet class.
Any updates?

Sorry guys I didn't have much time to look into the issue, and unfortunately I don't think I'd be able to check it in the foreseeable future.


squid:S00115 - Constant names should comply with a naming convention

This pull request is focused on resolving occurrences of Sonar rule squid:S00115 - Constant names should comply with a naming convention
You can find more information about the issue here:
https://dev.eclipse.org/sonar/coding_rules#q=squid:S00115
Please let me know if you have any questions.
M-Ezzat

Your change breaks backwards compatibility, e.g. Version.version to Version.VERSION breaks code that uses this. Also, changing public enums also breaks client code.
I'm not following the Java coding conventions, only where it makes sense. I don't think uppercase constants increase readability when everyone uses an IDE nowadays with coloring of constants.
And - yes - I use my_var underscore variable, so don't even think about changing them to myVar... :-)


[Script]: Parking Space Detection

Aim
To Build a parking space detection system using deep learning.
Details
Finding parking space for your vehicle is a major problem in big cities. The rise of car ownership has created an imbalance between parking demand and supply. In the current situation, a parking management system that can track parking spots has become a necessity for all major cities. The system has to be scalable, efficient, reliable, and affordable at the same time. In recent years, the advances in deep learning powered computer vision algorithms have shown very promising results in a variety of tasks. Similar techniques can be used to address the problem of parking space detection.
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSoC'23 contributor
[X] I want to work on this issue

@Yashbhadiyadra Can you please assign me this issue.


zli-6.6.1

Auto generated PR via bzero-deploy for Zli version: 6.6.1

Closing because we already released 6.6.1 in brew in #84


Add Code of Conduct

We recommend that every repo has a code of conduct. If you don’t feel comfortable creating your own Code of Conduct from scratch we highly recommend using one of the templates provided by GitHub. If you do use a template, please read through the template and ensure that you can and will abide by the Code of Conduct.
Please follow these instructions on how to add a Code of Conduct.
Sample: https://github.com/Recode-Hive/Stackoverflow-Analysis/blob/main/CODE_OF_CONDUCT.md

I would like to work on this issue. Please assign me this task.

Please assign this issue to me

@suhanipaliwal You can add code of conduct.
Use this template: https://github.com/Recode-Hive/Stackoverflow-Analysis/blob/main/CODE_OF_CONDUCT.md
Put my email there<EMAIL_ADDRESS>


Chart Update - Trivy v0.6.0

Helm 2 Chart - Trivy v0.6.0
Located in the dev branch of https://github.com/rancher/charts
Note: I couldn't figure out an endpoint to test this API directly after deployment. So I deployed the latest Harbor chart through a custom catalog (You need it to add custom scanners) and added the scanner(Trivy) using their instructions. This way you can test the scanner's health through Harbor directly. If you need more information on this, let me know.

Validated in v2.4-head and master-head using dev catalog branch

Able to deploy multi-cluster apps with trivy using default values and non-default values
Able to deploy normal app with trivy using default values and non-default values
Able to deploy into different namespaces

In all cases, app workloads come up successfully and appear functional


Multiple resources

Fixes [#7721 ]

This PR is used to debug the codegen issue of another PR. Close as it is.

Duplicate of #7811


Fix max transferable for Avail Bridge

Describe problem: Users bridge AVAIL fail from Avail -> Ethereum (https://avail.subscan.io/extrinsic/0x0308a6cbf8ce78fec3016e5658ffd3380e758a1673e8913b46a4d080b7fe3cac)
Check result: Almost all extrinsics fail in case users transfer max using wallet.
Solution: Set max_transferable = transferable balance - 1 AVAIL (reference: https://bridge.availproject.org/)

Version test: http://<IP_ADDRESS>:8900/s/aRxrwkFSwQBHQHp

[ ] Error when bridge avail(Ethereum sepolia -> avail turing)

Version test: http://<IP_ADDRESS>:8900/s/aRxrwkFSwQBHQHp
Validation passed.
Checklist for issue: https://www.notion.so/subwallet/Checklist-theo-issue-13c9e3215ec24762973dc680aec67198?pvs=4#01cc4594e10446368c76142264bcd604


Can't use OKX sub-accounts due to available balance check

Describe the bug
When using a sub-account API key on OKX, orders cannot be placed because they are quantized down to amount 0, likely because the check for available balance reduces amount down to 0. However, this does not occur when using the API key for a primary account
Steps to reproduce
1 - Create sub-account keys for an OKX account
2 - Run Simple PMM with OKX sub-account API key
Config
script_file_name: simple_pmm.py
exchange: okx
trading_pair: ETH-USDT
order_amount: 0.01
bid_spread: 0.005
ask_spread: 0.005
order_refresh_time: 15
price_type: mid

Logs
2024-05-15 10:35:28,002 - 76243 - hummingbot.strategy.script_strategy_base - INFO - Creating ETH-USDT buy order: price: 2967.552675 amount: 0E-29.
2024-05-15 10:35:28,003 - 76243 - hummingbot.strategy.script_strategy_base - INFO - Creating ETH-USDT sell order: price: 2997.377325 amount: 0E-11.
2024-05-15 10:35:28,004 - 76243 - hummingbot.connector.exchange.okx.okx_exchange.OkxExchange - WARNING - Buy order amount 0E-29 is lower than the minimum order size 0.0001. The order will not be created, increase the amount to be higher than the minimum order size.
2024-05-15 10:35:28,005 - 76243 - hummingbot.connector.exchange.okx.okx_exchange.OkxExchange - WARNING - Sell order amount 0E-11 is lower than the minimum order size 0.0001. The order will not be created, increase the amount to be higher than the minimum order size.

Run Simple PMM or Simple VWAP with OKX  main account API key

Config
script_file_name: simple_pmm.py
exchange: okx
trading_pair: BTC-USDT
order_amount: 0.001
bid_spread: 0.005
ask_spread: 0.005
order_refresh_time: 15
price_type: mid

Logs
2024-05-15 11:01:24,001 - 83479 - hummingbot.strategy.script_strategy_base - INFO - Creating BTC-USDT buy order: price: 64727.28725 amount: 0.001.
2024-05-15 11:01:24,001 - 83479 - hummingbot.strategy.script_strategy_base - INFO - Creating BTC-USDT sell order: price: 65377.81275 amount: 0.001.
2024-05-15 11:01:24,206 - 83479 - hummingbot.connector.client_order_tracker - INFO - Created LIMIT BUY order 93027a12dac34fBCBBCUT5cb76a726eb for 0.00100000 BTC-USDT.
2024-05-15 11:01:24,206 - 83479 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "type": "OrderType.LIMIT", "trading_pair": "BTC-USDT", "amount": "0.00100000", "price": "64727.2", "order_id": "93027a12dac34fBCBBCUT5cb76a726eb", "creation_timestamp":<PHONE_NUMBER>.0, "exchange_order_id": "1452694980166041600", "leverage": 1, "position": "NIL", "event_name": "BuyOrderCreatedEvent", "event_source": "okx"}
2024-05-15 11:01:24,219 - 83479 - hummingbot.connector.client_order_tracker - INFO - Created LIMIT SELL order 93027a12dac34fBCSBCUT09b948bdf00 for 0.00100000 BTC-USDT.
2024-05-15 11:01:24,219 - 83479 - hummingbot.core.event.event_reporter - EVENT_LOG - {"timestamp":<PHONE_NUMBER>.0, "type": "OrderType.LIMIT", "trading_pair": "BTC-USDT", "amount": "0.00100000", "price": "65377.8", "order_id": "93027a12dac34fBCSBCUT09b948bdf00", "creation_timestamp":<PHONE_NUMBER>.0, "exchange_order_id": "1452694980166041601", "leverage": 1, "position": "NIL", "event_name": "SellOrderCreatedEvent", "event_source": "okx"}

Release version
dev-1.28
Type of installation
Source
Attach required files
logs_conf_simple_pmm_1.log

@tomasgaudino Could you please review?

@fengtality @nikspz I already talked with Mike in private since is there is an issue with the connector, should be affecting the main account and the subaccount (there is no specific code for it).
The problem was that the config provided has an order amount of 0.01 ETH (around 300 USDT) and the total balance of the subaccount was 200 USDT.

The Simple PMM script uses the budget checker to adjust the order to the budget, and if you don't have enough balance to send the order will reduce the amount to 0, so the behavior was expected.
I reduced the order amount to 0.001 (around 30 USDT) and I was able to place orders with the subaccount.


Added .pck PLSQL extension

Added the .pck file extension to PLSQL. Fixes issue #2645.
In-the-wild usage of the file extension:
https://github.com/search?l=&q=create+extension%3Apck&ref=advsearch&type=Code&utf8=✓

On examination of the TravisCI logs, it looks like the file extensions are supposed to be alphabetically sorted, which I didn't see mentioned in the "Adding an extension to a language" section of the contributing guidelines. I will fix this error and submit a new pull request.


fixing issue #2072:Fix default license selector in Settings

Fixes #2072 Fix default license selector in Settings
What changes did you make and why?
Added getDefaultLicense() method in UploadModel.java class that return default license to updateLicenses() method in UploadPresenter.java class which sets the list of licences and the default license
Tested on Motorola Moto G(5) plus with API level 24

Hi @maskaravivek, @misaochan , I submitted a pull request for this very issue 10 days ago that has been overlooked.  see: https://github.com/commons-app/apps-android-commons/pull/2084
Whats more is that it appears obvious on the issue tracker (link https://github.com/commons-app/apps-android-commons/issues/2072) that I volunteered for this and submitted the fix! Perhaps I did not follow the process correctly.
@sp2710 Why did you do this when it was clear it has already been done? I feel a bit cheated to be honest...this was my first open source submission.

@briancollins-92 I am new to open source
I saw that your request was not merged and also there was no assigned label to that issue. So i thought to give it a try.

Codecov Report

Merging #2124 into master will decrease coverage by <.01%.
The diff coverage is 33.33%.

@@            Coverage Diff            @@
##           master   #2124      +/-   ##
=========================================
- Coverage    5.69%   5.69%   -0.01%
=========================================
  Files         233     233
  Lines       11596   11597       +1
  Branches     1076    1076
=========================================
  Hits          660     660
- Misses      10881   10882       +1
  Partials       55      55

Impacted Files
Coverage Δ

...va/fr/free/nrw/commons/upload/UploadPresenter.java
9.04% <0%> (ø)
:arrow_up:

...n/java/fr/free/nrw/commons/upload/UploadModel.java
59.22% <50%> (-0.29%)
:arrow_down:

Continue to review full report at Codecov.

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

Hi @maskaravivek, @misaochan. This may sound trivial, but can you please at least look at my pull request.
Like @sp2710 I am new to open source, but unlike him I maticulously followed the guidence and communicated what i was doing clearly. He has taken what i had finished and presented it as his own with some differences. As a fellow first timer, I am especially unimpressed by his feeble excuse. I had clearly staked out this issue and submitted my pull request before sp got involved and therefor deserve the credit of a merge - if it is good enough quality of couse, which i think it is.

@briancollins-92 Sorry about that, developers are often contributing as a hobby when they have 5 minutes, and they might choose a PR rather than another randomly.
Also, we all have a common goal of seeing the app being improved, so copying ideas or code or patches is not seen as "stealing", but rather seen as the normal way open source works.
I hope this will not deter you from contributing further, there are so many open issues that need people :-)
Cheers!

Hi all, firstly sorry for our  late review time, we are at one of rush times. I do agree about the importance of communication under issues because we don't want two people spend their energy for same task. On the other hand, I agree to @nicolas about random and fast picking issues. This coincidence should be considered as an accident, unintentional situation. Overall, we are happy you both are new to open source and trying to contribute, thanks for your time and help

Hi guys, sorry about the confusion. As @neslihanturan says, this was an accident, and I don't think anyone is truly "at fault" here, mistakes happen.
I do agree that we should give #2084 priority as it was submitted far in advance, and @briancollins-92 had posted on the issue requesting to take it up. In situations where the person taking it up is unresponsive, we can and do re-assign the issue, but that is not currently the case here.
We can still leave this PR up for now, but @neslihanturan will be testing #2084 when she has time next. If @briancollins-92 is responsive to code changes requested, we will merge that one and close this.
Sorry about that @sp2710 , but we need to follow the sequence usually. Please feel free to try your hand at another one of the issues that are open, thanks!

@misaochan
As I am new here so i thought that there is no assign label and the PR was also not approved so i can try my hands on it. Was not at all intentional
And I also agree that #2084 should be given priority. I will try my hands on other issues :)

Thank you all for your responses. May I offer my apologies to the mods as I very much appreciate the effort you make in volunteering. I was more frustrated at sp because it seemed obvious to me how it works. Thank you for taking time to look at this.

Closing #2124 now that #2084 is merged.
I've written up some clearer contributor documentation on the wiki which I hope should help reduce the chances of this happening in the future. Would love any feedback you have on it.


Code Cleanup

added final keyword to variables in Activity class methods

http://programmers.stackexchange.com/a/48414
http://stackoverflow.com/a/15655032
https://en.wikipedia.org/wiki/Final_(Java)#Final_variables

removed getResources() builder for getString() methods (cleaner)

Better exceptions handling for the possible mismatch with the arrays.

Effective Java 65: Don't ignore exceptions.


Loading Issue for SpongeForge 7.1.0

Hello Monsieur Meronat!
I have my bug report for you. Latch seems to be providing a couple of error during the server loading process. I don't mean to bother you, I would just be happy if you get to it when you have some spare time. ^^
Full Server Log - https://pastebin.com/BPMCPKTy
Stack Trace - https://pastebin.com/F8YasxZd
Just to note, I run this on custom modpack server with a number of mods, so I'm not sure if the problem is relevant to that or not. Either way, thank you for your time!

Thanks for the report. I didn't think this was still an issue, I'll have a fix out by tomorrow.

@CastorEst Would you mind trying with this build of Latch? No guarantees on its stability, but would appreciate a test with your modpack!
https://github.com/ichorpowered/latch/releases/tag/v0.5.0-SNAPSHOT

Once you confirm this fix I'll make an official release on Ore.

Ah, forgive me. I hadn't thought you reply so soon after I posted the problem.
As for the error, sadly the new release has simply provided me with a different error. ^^"
Server Log - https://pastebin.com/Zusy9E66
Stack Trace - https://pastebin.com/RmhpN002
If you have any questions regarding the server set-up and such, I would be happy to answer them. If the problem is irremediable, then I will also understand.
Thank you for you for your time no matter the outcome!

@parlough It might be a good idea to grab all of the blocks and items from the registry like you've done for the trap door, since mods may unpredictably remove them from the registry invalidating some of them from the BlockTypes list. Kind of annoying but, I guess that's that.

I love this plugin.Using even now.
I found a bug. if you are already know this bug, sorry.
This plugin using lock the door, if door is other user locked even can we unlock by any signal.
Example:Pressure plate, Lever, other output signals.

@n0pj Unfortunately redstone tracking is a bit tricky especially with mods. Your best bet is to set the protect_from_redstone setting in the configuration to true.
I will look into improving redstone protection more soon though as Sponge has improved its tracking a lot since it has been implemented and I now have a better understanding of Sponge's systems.

@CastorEst Sorry for the wait, please try this release - https://github.com/ichorpowered/latch/releases/tag/v0.5.0-SNAPSHOT
If it doesn't work, more information about your setup and a clear modlist would be fantastic.

I'm sorry to say another error and stacktrace are being posted up. ^^"
Server Log - https://pastebin.com/fZ5rbXkY
Stack Trace - https://pastebin.com/vR1iGXCz
Mod List - https://pastebin.com/3mW7WUZN
At this point, I imagine it has started to get frustrating so I would like to point how that I honestly wouldn't blame you if gave up on this bug. If it's too much of hassle, don't put yourself through it.
Thanks for all your help so far, it's great to know that there's such an active developer who cares about solving bugs and other problems with their plugin. I really do appreciate it. ^^

@CastorEst Actually this time it was my mistake, I'm sorry. I will handle it the long way and get a new build out soon.
It's a problem with MalisisDoors and/or MalisisCore. I have a messy way to handle it though, and I'll look into MalisisDoors to see if I can fix the root of the problem there.

I set up an instance with MalisisCore and MalisisDoors to test before and after the change and we have liftoff. I'll make the 0.5.0 release now. Sorry for the long wait..

You can find the 0.5.0 release here - https://github.com/ichorpowered/latch/releases/tag/v0.5.0 which should include the fix for the issue you're having - I will release it on Ore tomorrow if all goes well.

Hurrah! It works! \o/
It loaded without any errors, and I've managed to lock a door successfully. After all these tries, it finally works. Thank you so much for your help. ^^
It should be ready for release as you mentioned, no further errors have been spotted on my end.
I would like to make a request in terms of eventually, and when you have spare time, adding support for Conquest doors since they take up a considerable portion of doors on my server and none of them seem to be lockable blocks, but of course, that part's only a personal suggestion, I'm still overjoyed to finally be able to use the plugin!
Anyway, thanks again!

@CastorEst I'm happy that it's finally working. I'm not 100% sure how Conquest doors work and I'm assuming there's a lot of them, but for now you should be able to do /latch lockable add with each door type in your hand to add it to the lockable blocks list.
Next release or soon after I hope to add a mode(which you can enable in config) where all blocks are lockable by default and instead you choose blocks to not make lockable.

Ah, right. That works as well. I hadn't realized you could make the COnquest doors lockable. Thank you ever so much! If you need me for anything, feel free to ask. I'd be happy to help!

Hello, I'm having a similar error as @CastorEst.
Here's the server log: https://pastebin.com/GbWx5RHM
List of mods: https://i.imgur.com/T9avQlF.png
Thank you for your assistance :)