text:
Collate all notifications and controls into a notification mailbox

Collate all notifications and controls into a notification mailbox
UX feature suggestion.
Rationale
The current notification system of Source Academy includes notifications for:

new assessments released (students only)
assessments near their deadlines (students only)
new submissions, either by auto-submission at the assessment deadline or from a finalised submission (staff only)
auto-graded submissions (students only)
fully graded submissions (students only)
un-submitted submissions (students only)

Currently, all student notifications are rendered beside the corresponding assessment, and the staff notifications are rendered beside the corresponding submission in the datagrid on the Grading page.
I propose we can collate all the notifications into a central mailbox to make it easier to manage. The mailbox would allow users to access the corresponding assessment or submission in a new tab by clicking on the notification (similar to how each assessment card rendered in the current Profile links to the assessment itself). This should also acknowledge the notification.
There are a couple additional benefits of the change:

we can add controls for users to manage their notifications, e.g. filter by notification type/date, acknowledge all notifications of the same type (see PR #1267)
we can consider removing the notification bubbles from the navigation bar, reducing visual clutter
we can remove the notification bubbles from the submissions table on the Grading page - this significantly reduces the number of rendered elements in the datagrid and avoids the datagrid re-rendering each time a notification is acknowledged

Since a public Profile page for students is being worked on, I propose re-purposing the current Profile component into a notifications mailbox instead. As with the current Profile component, it will render above the Academy as a drawer component. The old Profile component will be left for reference for the Profile page.
If a UI mockup is required, I can add a wireframe for consideration.
Last updated 30 Jun 2020, 6:30PM

notifications have been removed. issue gone.

authors: Aulud martin-henz

repo: source-academy/frontend


text:
bug: Autocomplete does not display an warning/error status when the users access token is no longer valid

Version
v1.1.3
Describe the bug
When an access token is invalidated the following happens:

The user attempts to chat or uses a chat based command, an error message is displayed "Invalid access token"
The user attempts an inline edit command like "Document Code" and error message is present "Applying edits failed" which shows the invalid access token error
Autocomplete - there is no indicator that it is now disabled.  The icon does not spin but also doesn't show the warning color that would be present if the token was invalid when the ide was opened.

Expected behavior
The cody icon should update to the warning color when the access token is no longer valid.
Additional context
No response

@kalanchan Can you check if this bug is either resolved or handled already on the Clients team?

source: gharchive/issue

authors: aramaraju chwarwick

repo: sourcegraph/cody

license_type: permissive

license_source: github-api


text:
term.refresh problems

Executing a term.refresh doesn't seem to be actually refreshing.    I've had to modify the resize method with a custom method for a few reasons, and that's working well.   But after a resize I'm calling:
    term.refresh(0, term.rows - 1);

And I would expect it to redraw the existing contents to fit the resized screen.   But it doesn't appear to be happening at all.   If the screen is set to smaller, the text is just cut off.   If it's set wider, there is just a bunch of dead space.    Any new lines added fill the space properly.   I've been trying to add some breakpoints in to figure out if it's being called, but no success thus far.
EDIT: Even inspecting the this._terminal.rowContainer() element before its' being appended on the refresh shows each line being cut off instead of being put on to the next line.   Further researching this shows that as it's working through the number of lines, when it calculates the width of the terminal, it is just cutting off the content at that width and it's just disappearing from the dom instead of being put onto the next terminal line.
Details

Browser and browser version: electron 1.7.8
OS version: mac os 10.12.6
xterm.js version: 2.9.2

I think you're after this feature which we don't support yet: https://github.com/sourcelair/xterm.js/issues/622

authors: Tyriar ricktbaker

license: mit

license_source: bigquery


text:
Compiling issue - multiple definition of 'loop'

Hi,
I'm a frequent user of Arduinos and thought I followed your directions correctly but when I load up the BasicExample sketch and try to compile it, I get the errors below. Any suggestions to get past this? Thanks.
C:\Users\jeffi\AppData\Local\arduino\sketches\ABDCDAB6D167A5B4E2E2942CA9F11832\libraries\G35Arduino-master\ValentinesDay.cpp.o (symbol from plugin): In function loop': (.text+0x0): multiple definition of loop'
C:\Users\jeffi\AppData\Local\arduino\sketches\ABDCDAB6D167A5B4E2E2942CA9F11832\sketch\BasicExample.ino.cpp.o (symbol from plugin):(.text+0x0): first defined here
C:\Users\jeffi\AppData\Local\arduino\sketches\ABDCDAB6D167A5B4E2E2942CA9F11832\libraries\G35Arduino-master\ValentinesDay.cpp.o (symbol from plugin): In function loop': (.text+0x0): multiple definition of setup'
C:\Users\jeffi\AppData\Local\arduino\sketches\ABDCDAB6D167A5B4E2E2942CA9F11832\sketch\BasicExample.ino.cpp.o (symbol from plugin):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
exit status 1
Compilation error: exit status 1

@alexvirodov I wonder whether this issue was introduced with https://github.com/sowbug/G35Arduino/pull/32, as that new file is meant to be another top-level setup()/loop(). Do you think the ValentinesDay.cpp should have been an example sketch instead?
@MapleLaneJeff try deleting ValentinesDay.cpp (which I see is the file giving the trouble) and trying again.

That was it. It now compiles, downloads and runs with no issue. Thanks for this and for all you've done with the GE lights. They go up every year on my house at Christmas time and around our Tiki Bar once the pool is open for summer. My friends are always amazed by the show!

Sounds great! I moved on to WS2812-based lights and WLED years ago, but I still miss the gorgeously bright and vivid colors of the G35 bulbs. I'm glad to hear you're still enjoying them and this project!

It's nice to know that this code is still being used.  2012 was my first year using RBG LEDs and this code really helped me at the time. I even contributed a little bit. Thanks sowbug.

Yes!! Your code also got me started! I still have two working sets of GE35
lights running.,one set has been outside for a decade, the other inside a
bay window. The out side set has a new power supply, but the faceted "bulb"
housings are remarkably clear.
Mobile Response - Please excuse my clumsy thumbs
On Tue, Dec 10, 2024, 03:51 Mark @.***> wrote:

It's nice to know that this code is still being used. 2012 was my first
year using RBG LEDs and this code really helped me at the time. I even
contributed a little bit. Thanks sowbug.
—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2530846449,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAX33BQGTUBQIINHBEURBC32E2TR7AVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZQHA2DMNBUHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I'm not quite sure, but I think the DIN (data input) and DOUT (data output)
might be like the WS2812, i.e. not interchangeable.
So, from the factory, the string has one direction. Cutting out a single
bulb might then be 50/50 to install it correctly.
Also, for the one that was burned-out - did the bulbs downstream work
normally - or were they dark?
One way to test would be to connect a single bulb to the arduino and see if
it works one-way - but not the other way around.
Lastly, watch the polarity of the connection, because one wire is 6v, one
is ground (neutral), and the third is the data line.
I learned to setup mine from these videos:
http://www.toddfun.com/2011/11/27/g35-led-christmas-light-review-and-teardown/
https://www.youtube.com/watch?v=q7znaoj-0xA
On Tue, Dec 10, 2024 at 9:19 AM MapleLaneJeff @.***>
wrote:

My current string has a couple lights not working anymore. I have some
spare lights from another set I cut up but when I installed two in place
of
the failed lights they don't work. I'm assuming the individual lights come
from the factory with a unique address assignment and that's why they
aren't working. Does that sound right or did I do something wrong on the
install? I'm pretty sure I have the connections in the correct order. It
would be a shame to have to trash the string after we've enjoyed them all
these years. Thoughts?
On Tue, Dec 10, 2024, 6:37 AM medpixman @.***> wrote:

Yes!! Your code also got me started! I still have two working sets of
GE35
lights running.,one set has been outside for a decade, the other inside
a
bay window. The out side set has a new power supply, but the faceted
"bulb"
housings are remarkably clear.
Mobile Response - Please excuse my clumsy thumbs
On Tue, Dec 10, 2024, 03:51 Mark @.***> wrote:

It's nice to know that this code is still being used. 2012 was my
first
year using RBG LEDs and this code really helped me at the time. I even
contributed a little bit. Thanks sowbug.
—
Reply to this email directly, view it on GitHub
<
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2530846449>,

or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/AAX33BQGTUBQIINHBEURBC32E2TR7AVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZQHA2DMNBUHE>

.
You are receiving this because you are subscribed to this
thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531322091,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/BGNCCGW5D4RZEU77WQA2KUD2E3G7NAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRGMZDEMBZGE>

.
You are receiving this because you were mentioned.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531766530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAX33BXUVZGG3FOVWOS4A6D2E3Z7HAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRG43DMNJTGA
.
You are receiving this because you commented.Message ID:
@.***>

Also this is another resource:
https://mevans77.wordpress.com/2011/11/07/hacking-g-35-ge-christmas-lights/
On Tue, Dec 10, 2024 at 9:19 AM MapleLaneJeff @.***>
wrote:

My current string has a couple lights not working anymore. I have some
spare lights from another set I cut up but when I installed two in place
of
the failed lights they don't work. I'm assuming the individual lights come
from the factory with a unique address assignment and that's why they
aren't working. Does that sound right or did I do something wrong on the
install? I'm pretty sure I have the connections in the correct order. It
would be a shame to have to trash the string after we've enjoyed them all
these years. Thoughts?
On Tue, Dec 10, 2024, 6:37 AM medpixman @.***> wrote:

Yes!! Your code also got me started! I still have two working sets of
GE35
lights running.,one set has been outside for a decade, the other inside
a
bay window. The out side set has a new power supply, but the faceted
"bulb"
housings are remarkably clear.
Mobile Response - Please excuse my clumsy thumbs
On Tue, Dec 10, 2024, 03:51 Mark @.***> wrote:

It's nice to know that this code is still being used. 2012 was my
first
year using RBG LEDs and this code really helped me at the time. I even
contributed a little bit. Thanks sowbug.
—
Reply to this email directly, view it on GitHub
<
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2530846449>,

or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/AAX33BQGTUBQIINHBEURBC32E2TR7AVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZQHA2DMNBUHE>

.
You are receiving this because you are subscribed to this
thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531322091,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/BGNCCGW5D4RZEU77WQA2KUD2E3G7NAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRGMZDEMBZGE>

.
You are receiving this because you were mentioned.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531766530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAX33BXUVZGG3FOVWOS4A6D2E3Z7HAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRG43DMNJTGA
.
You are receiving this because you commented.Message ID:
@.***>

Thanks, I'll check it out!
On Tue, Dec 10, 2024, 10:01 AM medpixman @.***> wrote:

Also this is another resource:
https://mevans77.wordpress.com/2011/11/07/hacking-g-35-ge-christmas-lights/
On Tue, Dec 10, 2024 at 9:19 AM MapleLaneJeff @.***>
wrote:

My current string has a couple lights not working anymore. I have some
spare lights from another set I cut up but when I installed two in place
of
the failed lights they don't work. I'm assuming the individual lights
come
from the factory with a unique address assignment and that's why they
aren't working. Does that sound right or did I do something wrong on the
install? I'm pretty sure I have the connections in the correct order. It
would be a shame to have to trash the string after we've enjoyed them
all
these years. Thoughts?
On Tue, Dec 10, 2024, 6:37 AM medpixman @.***> wrote:

Yes!! Your code also got me started! I still have two working sets of
GE35
lights running.,one set has been outside for a decade, the other
inside
a
bay window. The out side set has a new power supply, but the faceted
"bulb"
housings are remarkably clear.
Mobile Response - Please excuse my clumsy thumbs
On Tue, Dec 10, 2024, 03:51 Mark @.***> wrote:

It's nice to know that this code is still being used. 2012 was my
first
year using RBG LEDs and this code really helped me at the time. I
even
contributed a little bit. Thanks sowbug.
—
Reply to this email directly, view it on GitHub
<
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2530846449>,

or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/AAX33BQGTUBQIINHBEURBC32E2TR7AVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZQHA2DMNBUHE>

.
You are receiving this because you are subscribed to this
thread.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
<
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531322091>,

or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/BGNCCGW5D4RZEU77WQA2KUD2E3G7NAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRGMZDEMBZGE>

.
You are receiving this because you were mentioned.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531766530,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAX33BXUVZGG3FOVWOS4A6D2E3Z7HAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRG43DMNJTGA>

.
You are receiving this because you commented.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2531926000,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BGNCCGROWZ5IHAFELCA4FWD2E3653AVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRHEZDMMBQGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

The bulbs don't have hardcoded addresses. If memory serves, they maintain counters, a little like in kindergarten when you asked a group of kids to count itself, so the first kid would say "1" and the second kid would say "2" because he or she mentally added one to the number he or she just heard the prior kid say. This happens when the lights first get turned on, and after that each light responds to that number.
I am guessing you'd have mentioned it if all the bulbs past the bad one were also dead. Having a single dead bulb in the middle of a string, whose replacements are also dead, is very strange. Either the power being supplied to that bulb is bad (test with a multimeter), or you're having extremely bad luck and your replacements are also bad.
I don't see how reversing DIN/DOUT could have happened here (as @medpixman suggested), because that would have ended the data transmission to subsequent bulbs on the string.
I'd put my money on a frayed power connection. And if you really want to go down a rabbit hole, you can also verify the data line with a logic probe.
Please let us know what happened (but maybe open a new issue because this no longer has anything to do with Valentine's Day. :)

I love these lights also. Sowbug, have you considered writing the timing sequence into WLED list of compatable light protocols? I know G35 has limited colors, but it would be very nice to control G35 with WLED. Other G35 users have asked same question on DISCORD - WLED

Yes, bulbs past the bad one continued to work properly so that tells me the
5VDC, common and data line connections are good since power and
communications passed through to the next bulb. IMHO, that leave two
possibilities, the replacement bulb (which came from a string that was
never used) was failed or I got the connections reversed. There are some
embedded lines on one of the wires from both strings so I assumed they
should be connected. The original string had 50 bulbs and the replacement
bulb came from a string of 25. Would that make a difference?
On Tue, Dec 10, 2024, 1:47 PM Mike Tsao @.***> wrote:

The bulbs don't have hardcoded addresses. If memory serves, they maintain
counters, a little like in kindergarten when you asked a group of kids to
count itself, so the first kid would say "1" and the second kid would say
"2" because he or she mentally added one to the number he or she just heard
the prior kid say. This happens when the lights first get turned on, and
after that each light responds to that number.
I am guessing you'd have mentioned it if all the bulbs past the bad one
were also dead. Having a single dead bulb in the middle of a string, whose
replacements are also dead, is very strange. Either the power being
supplied to that bulb is bad (test with a multimeter), or you're having
extremely bad luck and your replacements are also bad.
I don't see how reversing DIN/DOUT could have happened here (as @medpixman
https://github.com/medpixman suggested), because that would have ended
the data transmission to subsequent bulbs on the string.
I'd put my money on a frayed power connection. And if you really want to
go down a rabbit hole, you can also verify the data line with a logic probe.
Please let us know what happened (but maybe open a new issue because this
no longer has anything to do with Valentine's Day. :)
—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2532602420,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BGNCCGX37CTUYQEXD6VQAR32E4ZKRAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZSGYYDENBSGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I think sowbug is correct, the nodes are enumerated when you startup. I
can't prove that, but it would make sense based on how other 3-wire RGB are
controlled.
ToddFun.com » Blog Archive » G35 LED Christmas Light Review and Teardown
http://www.toddfun.com/2011/11/27/g35-led-christmas-light-review-and-teardown/
On Tue, Dec 10, 2024 at 3:44 PM MapleLaneJeff @.***>
wrote:

Yes, bulbs past the bad one continued to work properly so that tells me
the
5VDC, common and data line connections are good since power and
communications passed through to the next bulb. IMHO, that leave two
possibilities, the replacement bulb (which came from a string that was
never used) was failed or I got the connections reversed. There are some
embedded lines on one of the wires from both strings so I assumed they
should be connected. The original string had 50 bulbs and the replacement
bulb came from a string of 25. Would that make a difference?
On Tue, Dec 10, 2024, 1:47 PM Mike Tsao @.***> wrote:

The bulbs don't have hardcoded addresses. If memory serves, they
maintain
counters, a little like in kindergarten when you asked a group of kids
to
count itself, so the first kid would say "1" and the second kid would
say
"2" because he or she mentally added one to the number he or she just
heard
the prior kid say. This happens when the lights first get turned on, and
after that each light responds to that number.
I am guessing you'd have mentioned it if all the bulbs past the bad one
were also dead. Having a single dead bulb in the middle of a string,
whose
replacements are also dead, is very strange. Either the power being
supplied to that bulb is bad (test with a multimeter), or you're having
extremely bad luck and your replacements are also bad.
I don't see how reversing DIN/DOUT could have happened here (as
@medpixman
https://github.com/medpixman suggested), because that would have
ended
the data transmission to subsequent bulbs on the string.
I'd put my money on a frayed power connection. And if you really want to
go down a rabbit hole, you can also verify the data line with a logic
probe.
Please let us know what happened (but maybe open a new issue because
this
no longer has anything to do with Valentine's Day. :)
—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2532602420,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/BGNCCGX37CTUYQEXD6VQAR32E4ZKRAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZSGYYDENBSGA>

.
You are receiving this because you were mentioned.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2532847497,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAX33BROWRCHNZFAY5F32PD2E5HDZAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZSHA2DONBZG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Good news. Everything is working now. After some more investigation, I figured out the string works fine when the programming cable is still plugged in along with the power supply and doesn't when it is not plugged in. My power supply failed last year and it was a 6V, 1.2A supply. I replaced it this year with a 6V, 1A supply. My theory is the 1.2A supply was just enough to keep the voltage stable at all times but the 1A supply was not. Another issue I noticed was the string would frequently get hung up on an all white display which draws the most power. I monitored the 3.3V pin on the Arduino at that point and it was less than 3.3V. I suspect that, when I ran the string with the programming cable plugged in, the computer provided enough additional power to keep the 3.3V line stable and allowed all the bulbs to work with all the displays. All the details point to an under-sized power supply so I ordered a 6V, 2A supply tonight which will arrive in a couple days. Thanks again gents for all your help!

We should have known! 95% of hardware problems are bad power supplies. 95% of the remaining 5% are bad wiring. Enjoy the holidays.

First rule of trouble-shooting: Don't trust the power-supply.
2nd Rule: Check what you think are the most reliable components early if
not first.
Mobile Response - Please excuse my clumsy thumbs
On Tue, Dec 10, 2024, 23:07 Mike Tsao @.***> wrote:

We should have known! 95% of hardware problems are bad power supplies. 95%
of the remaining 5% are bad wiring. Enjoy the holidays.
—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2533583283,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAX33BUJDMPMRPTSKOADRZD2E626PAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZTGU4DGMRYGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Awesome, thanks for the update!
Mobile Response - Please excuse my clumsy thumbs
On Tue, Dec 10, 2024, 23:01 MapleLaneJeff @.***> wrote:

Good news. Everything is working now. After some more investigation, I
figured out the string works fine when the programming cable is still
plugged in along with the power supply and doesn't when it is not plugged
in. My power supply failed last year and it was a 6V, 1.2A supply. I
replaced it this year with a 6V, 1A supply. My theory is the 1.2A supply
was just enough to keep the voltage stable at all times but the 1A supply
was not. Another issue I noticed was the string would frequently get hung
up on an all white display which draws the most power. I monitored the 3.3V
pin on the Arduino at that point and it was less than 3.3V. I suspect that,
when I ran the string with the programming cable plugged in, the computer
provided enough additional power to keep the 3.3V line stable and allowed
all the bulbs to work with all the displays. All the details point to an
under-sized power supply so I ordered a 6V, 2A supply tonight which will
arrive in a couple days. Thanks again gents for all your help!
—
Reply to this email directly, view it on GitHub
https://github.com/sowbug/G35Arduino/issues/33#issuecomment-2533578181,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAX33BSNUVYWHSJ5NB7RI5L2E62LLAVCNFSM6AAAAABTKDCZZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZTGU3TQMJYGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

authors: MapleLaneJeff MarkEMarkEMark gregcrago medpixman sowbug


text:
Latest BE build 7z archive contains two seperate 'plugins' directories

General information
Project issue is for:
Modules
This breaks out-of-the-box support on case-sensitive filesystems.
How to reproduce

Open SPT-BLEEDINGMODS-3.8.0-29197-xxx.7z archive
Go to BepInEx directory
See two separate plugins directories

Screenshots

Attachments

grafik.png (4 KiB)

Originally written by MadByte

Where did you download this 7z from dev-core channel?

Originally written by Kaeno

Where did you download this 7z from dev-core channel?

correct 👍

Originally written by MadByte

this is what my zip looks like from Dev-core everything looks normal

Attachments

image.png (7 KiB)

Originally written by Kaeno

i would delete both existing plugins folder and reinstall.

Originally written by Kaeno

well that's weird. I re-downloaded the archive from dev-core just now, and checked on both Windows 11 (virtual machine) and Linux (Mint) - both do have two plugins directories on my end. Might be some weird edge case with the changed archive format..
I also believe that all directories in BepInEx are supposed to be lowercase by default - as it is for me on 3.7.6 stable files. But with the new version Patchers and Plugins begin with an uppercase letter as seen on your screenshot.

Originally written by MadByte

In build.ps1, dir names for Plugins and Patchers begin with a uppercase letter
In Release-Packager.csproj dir names begin with a lowercase letter.

That might be the issue here.

Attachments

bepinex_configmanager.png (11 KiB)

Originally written by MadByte

repo: sp-tarkov/server

license: NCSA


text:
Reputation gain isn't shown in post-raid statistics

General information
Project issue is for:
BE Server (but affects 3.7.6 too)
Expected result:
Reputation is shown in post-raid statistics
Actual result:
Reputation gain isn't shown in post-raid statistics.
Actual reputation gain (for a car extract as tested) seems to continue working as expected.
How to reproduce

Start a raid as a PMC
Move to the car extraction
Pay for the extraction
Extract successfully
Observe the lack of reputation gain in the post-raid summary

This may affect other SCAV reputation gains that are not car-extract related
Log files
Server: Uploaded
BepinEx: Uploaded
Client: Uploaded
Profile
Attached 65e1b03c000156507fc65870
Screenshots
Added

Attachments

2024.03.01_10-39-06_0.14.1.1.28965 traces.log (99 KiB)
server-2024-03-01.log (364 KiB)
LogOutput.log (64 KiB)
Screenshot 2024-03-01 104306.png (1020 KiB)

Originally written by denoik

Can confirm that this does not show in previous versions as well. PMC as well as Scav does not show rep gain/loss.

Originally written by bandit

This is the behaviour in Live too, so it's likely that custom implementation would be required to bring statistics to the end-raid statistics screen.

Originally written by denoik

Updated: https://dev.sp-tarkov.com/SPT-AKI/Server/commit/ae3b8e07bd00c8e5f55bcd8a2dfdae1395e154cb
Wrong issue lmao.

Originally written by chomp

@chomp is reducing it to 0.2 not the incorrect base value, considering it should start at 0.4 and halves for every successful exfil until it reaches 0.01 as a floor value?

BSG dropped the base rep to 0.2, I thought there was an issue for that but I can't find it, Chomp probably thought this was the issue about the incorrect base value.
Wiki change indicating the lowered value: https://escapefromtarkov.fandom.com/wiki/Scavs?diff=268391&oldid=267890

Originally written by DrakiaXYZ

This can be patched in the TransferItemRequirement class. Most likely you'd want the value to be retrieved from the server through a request first?
A small example that works:
internal class TransferExitItem_Patch : ModulePatch
{
    protected override MethodBase GetTargetMethod() => typeof(TransferItemRequirement).GetMethod(nameof(TransferItemRequirement.TransferExitItem));

    [PatchPostfix]
    public static void PostFix(Player player)
    {
        if (player.IsYourPlayer)
        {
            SessionCountersClass sessionCounters = player.Profile.EftStats.SessionCounters;
            sessionCounters.AddDouble(0.2,
            [
                CounterTag.FenceStanding,
                    EFenceStandingSource.ExitStanding
            ]);
        }
    }
}

Which results in:
Patch can be tweaked to your liking. Most likely you'd want to get the __result as well to verify that it actually succeded before applying the rep.

Originally written by Lacyway

My thinking here is to move the handling of standing change to the client-side, using the profile.FenceInfo.AddStanding() method instead. It can be done in the existing OfflineSaveProfilePatch PatchPrefix which occurs before the stats screen is displayed so reading from the session counter should work and display correctly.
Not sure if the profile data will contain the information required to determine the multiplier for a successful car exfil, but the session stats will contain enough information on the kills to determine negative/positive rep additions for PMC/traitor kills.

Originally written by denoik

My thinking here is to move the handling of standing change to the client-side, using the profile.FenceInfo.AddStanding() method instead. It can be done in the existing OfflineSaveProfilePatch PatchPrefix which occurs before the stats screen is displayed so reading from the session counter should work and display correctly.
Not sure if the profile data will contain the information required to determine the multiplier for a successful car exfil, but the session stats will contain enough information on the kills to determine negative/positive rep additions for PMC/traitor kills.

Client side rep calculation would probably be cleaner than doing it server side, i imagine

Originally written by chomp

Client side rep calculation would probably be cleaner than doing it server side, i imagine

I'm going to take a crack at the code change this week.

Originally written by denoik

Added with: https://dev.sp-tarkov.com/SPT-AKI/Modules/commit/c29589768dcb877290ea3970547b350343b2059a

Originally written by chomp


text:
На бриг таймерах не работает кириллица

Описание
title
Шаги воспроизведения
No response
Скриншоты
No response

Логично

license: MIT


text:
do_after for actions

Basically, we need a way to make certain actions take a specified amount of time before being completed. This action would also be cancelled if the player were to move or interact with something else.
This would also show a cooldown bar to the players.

@Zumorica Mind assigning me? I'll give it a crack.

Assigned @metalgearsloth

Nice. My only request is that you can await this for convenience :pray:

Closing since it got merged today.

authors: ShadowCommander SweptWasTaken Zumorica metalgearsloth


text:
Some mapped melee weapons unusable due to saving the 'nextAttack' field

Description

If this is high enough it can make you unable to use the weapon as the in-game time hasn't caught up yet.

https://github.com/space-wizards/RobustToolbox/pull/3507 should fix it but I only verified it for the serialized door statechanges.

This can be easily replicated by mapping in an item, (I used screwdriver, mechanical toolbox, and air tank,) Pick it up and move it to another location, save. It will now have the next attack node.

I wouldn't recommend mappers pick things up, ideally their hands would just be disabled entirely.

It's definitely a new issue though. Sometimes you move things. Sometimes you need to use a tool, multitool, screwdriver, etc to configure objects and then when you're done, place the tool in a random location. Or when editing a map with new additions, maybe just move something over to make space.
I'll avoid it for now but it's worth noting that it wasn't a problem until recently.

but it's worth noting that it wasn't a problem until recently.

aghosts having hands is a massive hack and has lead to code quality issues. These should be done via transform setting (pending mapping mode or otherwise).

but it's worth noting that it wasn't a problem until recently.

disagree.

disagree.

Ok but it's clear from the image linked above it's a common tactic by most mappers. There's 4 maps there that have this and I counted 6 downstream. Why would that not be worth taking notice?

We shouldn't have to add in a bunch of pause checks around event handlers because offsets started being serialized correctly so I'd rather just wait for mapping UI.

but it's worth noting that it wasn't a problem until recently.

disagree.

How? It literally wasn't a problem until recently, you can't will it to be an "opinion".
Now that current mappers know this is the issue they can work around it in the time before it's properly fixed(you say mapping UI), because mappers do interact with it as described, and it is worth making note and notice of.

probably fixed by #15123, will need testing

authors: ChilbroBaggins Elijahrane OldDanceJacket ZoldorfTheWizard metalgearsloth


text:
RMB fails to load an monkey

Description
finded out (on the dev server) that by clicling RMB on any entity spawns an error "Failed to load RSI /Textures/Mobs/Animals/monkey.rsi"
Reproduction

Get on the test server
Press ~ (or look into the terminal if you on linux)
RMB on PDA/other thing
error

Video
https://user-images.githubusercontent.com/71643624/234047546-8e81d9b3-e031-4fb4-a32f-9f3f9d5a1551.mp4

monkey spawns normally tho (and still fails to load monkey rsi)

BOTY?

someone put a bracket here.

so problem lies somewhere in #15674. I returned all files changed by it and it fixed RMB.


text:
Anomalies spam console

Description
So far I've only seen the pyroclastic and flesh anomalies do this.
Reproduction
No idea what causes this beyond the anomaly just being there.
Screenshots

Electro added logs but forgot to make them server-only, it seems.


text:
Eaten Bodies Cannot Be Recovered From Space Dragon

Description

Round 33913. A space dragon was butchered, leaving no bodies to recover. Players affected blackscreened and had to reconnect to see again.
Reproduction

Butcher a space dragon with a player's body inside.

This happens in every round with a dragon, often removing syndicate objective items along with the bodies


text:
Ninjas spawn with jetpack internals on instead of oxygen/nitrogen tank

Description
whenever you spawn in as ninja, it turns on your jetpack internals instead of using the gas tank on your back. not a big deal but if you don't catch it you can run your jetpack dry faster
Reproduction
spawn as ninja
look at action bar
jetpack internals on

`This also applies to the nukie medic, whos magboot internals start on

authors: BramvanZijp baddiePRO


text:
Make all popups send a chat message.

Description
The idea is simply that popups should be logged in chat.
However, since the chat has multiple filters, it should have a filter for popup messages, and have it be disabled by default.
This way, if you need to re-read old popup messages for whatever reason, you can do so by simply enabling the popup filter.

The fact that popups aren't logged anywhere right now has always bothered me, specially for popups such as the dice roll popup, which would be really nice to log for certain situations (tabletop games, roleplay reasons, etc)
While I do agree that cluttering the chat is bad and that popups are a good way to prevent this, I feel like implementing this feature would have the best of both worlds, with none of the disadvantages: If you want your chat cluttered by popups, you can. But by default, it won't. If you want to see past popups to remember what your dice rolled before, you can enable the filter to see and then disable it again. I feel like doing this has no disadvantages at all, only advantages.

I think I'll give this one a try next. Also seems related to #190.

In Content.Shared > Chat > ChatChannel.cs there seems to be a chat channel for "Visual" (comment reads: "Visual events the player can see. Basically like visual_message in SS13")
From what I can tell, this Visual channel seems unused currently. Would this overlap with what I'm doing? I'm currently going to ignore it and try to create a new channel "Popup." I imagine that visual_message would be used for important stuff that we wouldn't want the player to filter out.

After taking it to the Discord it seems like the chat portion of #5438 is needed first. If I understand it correctly, Speech and other In-Character chat needs an ECS refactor ("SpeechSystem" or the like) whereas Out-of-Character chat would go through IChatManager interface.
Either way I've stopped work on this one for now.

dupe of  #190

authors: AJCM-git Willhelm53 Zumorica


text:
Swapping hands doesn't update the inventory drop ghost icon

I have to mouseover the slot again for it to update.

duplicate of #3961

authors: ElectroJr metalgearsloth


text:
infiltrator update

looks better, cute, skub

source: gharchive/pull-request


text:
Chief Engineer's Turtleneck

About the PR

Added a Chief Engineer's Turtleneck, similiar to the Quartermaster's one.
The description reads: "A yellow turtleneck specifically designed for work in conditions of the engineering department."
Turtleneck itself includes two versions: with pants, and with a skirt. Both of these versions will spawn in the Chief Engineer's locker. It's also printable at the Uniform Printer. Both versions require 3 sheets of cloth to be sewed.
Design is approved by @Flareguy.
Media

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

Changelog

:cl:

add: Added Chief Engineer's Turtleneck. You can find it in their locker or sew it at the Uniform Printer!

This probably shouldn’t be in the locker, if someone really wants it they can ask the HoP to print it and we don’t need to start with head lockers being full of clothing variants again

This probably shouldn’t be in the locker, if someone really wants it they can ask the HoP to print it and we don’t need to start with head lockers being full of clothing variants again

I'm aware of this problem, and I was wondering of making prototypes of dressers, filled with specific clothes for each head. But at this point, I think, it's better to make more clothes for heads at the first place, else dressers would be pretty much empty for some of them. And, honestly, it kinda sucks to ask hop to make you a clothing every shift.

ideally when loadout becomes a thing we will remove all clothes from lockers and put it in loadout

And if someone else wants it they can realistically just use the printer

authors: Eden077 Emisse KingFroozy LankLTE


text:
SMES QoL

About the PR
I have added some QoL for SMES.
SMES now has some damage overlays, and an aftermath of it's destruction as well as an ability to repair it.
A bit more details:
When SMES reaches it's critical state, it spills 100u of licoxide. If it keeps being damaged, it explodes, and releases 64 moles of flaming plasma.
Why / Balance
SMESes are a fairly important part of the station, and their "repairablity" and damage indication is very important, in my opinion.
Media
https://youtu.be/KkeKjtaWm9c?si=8JODvBOg99JzXFrm

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

Breaking changes

Changelog

:cl:

add: SMES has a damage overlay now.
tweak: SMES can now be repaired with a welding tool.
tweak: SMESes now explode when destroyed and cause a small plasmafire as well as spill licoxide.

flaming plasma is too much

test fails are not erroneous btw

Spilling 100u of licoxide for just putting into a critical state? Isnt it seems a bit of... usefull for whom that doing it?
Licoxide by the way, were nerfed from being easy earnable and powerfull reagent cause you just grinding batteries.
But then it got a change, that you need grind steel and batteries(also chemmaster) to get even one unit of it.
Giving free 100u of licoxide, by just beating SMES to critical state feels not okay
Thats my opinion

if only we had standing fires from 13 instead of having to use plasmafires

Spilling 100u of licoxide for just putting into a critical state? Isnt it seems a bit of... usefull for whom that doing it?
Licoxide by the way, were nerfed from being easy earnable and powerfull reagent cause you just grinding batteries.
But then it got a change, that you need grind steel and batteries(also chemmaster) to get even one unit of it.
Giving free 100u of licoxide, by just beating SMES to critical state feels not okay
Thats my opinion

Agreed, 100u of licoxide is a bit too much. Maybe 30u is much more viable?

if only we had standing fires from 13 instead of having to use plasmafires

Yeah...

I'll do some changes as soon as I get back home.

Spilling 100u of licoxide for just putting into a critical state? Isnt it seems a bit of... usefull for whom that doing it?
Licoxide by the way, were nerfed from being easy earnable and powerfull reagent cause you just grinding batteries.
But then it got a change, that you need grind steel and batteries(also chemmaster) to get even one unit of it.
Giving free 100u of licoxide, by just beating SMES to critical state feels not okay
Thats my opinion

Agreed, 100u of licoxide is a bit too much. Maybe 30u is much more viable?
Licoxide is powerfull even in 5 units. But.
I see that you still to want to add it, so what about to add licoxide smoke on critical state?It will turn mes actually dangerous device to work with.

Spilling 100u of licoxide for just putting into a critical state? Isnt it seems a bit of... usefull for whom that doing it?
Licoxide by the way, were nerfed from being easy earnable and powerfull reagent cause you just grinding batteries.
But then it got a change, that you need grind steel and batteries(also chemmaster) to get even one unit of it.
Giving free 100u of licoxide, by just beating SMES to critical state feels not okay
Thats my opinion

Agreed, 100u of licoxide is a bit too much. Maybe 30u is much more viable?

Licoxide is powerfull even in 5 units. But.
I see that you still to want to add it, so what about to add licoxide smoke on critical state?It will turn smes actually dangerous device to work with.
Indeed! Great idea, you mean like foam that dissipates over time?

Spilling 100u of licoxide for just putting into a critical state? Isnt it seems a bit of... usefull for whom that doing it?
Licoxide by the way, were nerfed from being easy earnable and powerfull reagent cause you just grinding batteries.
But then it got a change, that you need grind steel and batteries(also chemmaster) to get even one unit of it.
Giving free 100u of licoxide, by just beating SMES to critical state feels not okay
Thats my opinion

Agreed, 100u of licoxide is a bit too much. Maybe 30u is much more viable?

Licoxide is powerfull even in 5 units. But.
I see that you still to want to add it, so what about to add licoxide smoke on critical state?It will turn smes actually dangerous device to work with.

Indeed! Great idea, you mean like foam that dissipates over time?

I mean mostly smoke reaction, water-like foam coming from device doesnt logicaly okay.
In other hand, smoking devices pretty common.
Also thinking of it, people would use smes as pushing stun bombs, putting things into disaster.
But will understand that a pep  whom bringing half-broken  smes to a public place, will indeed have bad intentions. Yeap.

I've tweaked the SMES again, added the foam effect. I think it acts pretty well, makes for some more robust traps you can do in engineering / solars.
I will also do some playtesting with people on friday.
Here''s the new media:
https://youtu.be/IxvHtJKW-ME
(for some reason OBS changed the size of the SS14's window, but I think you can still see all you need.)

@VelonacepsCalyxEggs you coming back to this?

No, going through some troubles currently. I will continue this later. Closing it for now.


text:
Fixed shuttle movements on some systems

About the PR
Fixed shuttle movements in southern and northern coordinates
Why / Balance
The shuttle couldn't move north and south.
Technical details
The Dot system function was not functioning properly on some Vector2 system library, so the Dot function was copied to the MoverController.
Media
None needed.

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

Breaking changes
None.
Changelog
No cl.

Is there a linked dotnet issue

This is straight up "this needs an upstream bug in the .NET runtime" tier if this fixes it. This really demands further investigation.
Can you send me the top of your server log when it starts (or at least enough for the intrinsics):
[INFO] root: Server -> Starting
[INFO] cfg: Configuration loaded from file
[DEBG] root: OS: Microsoft Windows 10.0.22631 X64
[DEBG] root: .NET Runtime: .NET 8.0.0 win-x64
[DEBG] root: Server GC: True
[DEBG] root: Processor: 24x AMD Ryzen 9 5900X 12-Core Processor
[DEBG] root: Architecture: X64
[DEBG] root: Robust Version: 205.0.0.0
[DEBG] root: Compile Options: DEVELOPMENT;TOOLS;DEBUG;CLIENT_SCRIPTING
[DEBG] root: Intrinsics: X86Aes;Avx;Avx2;Bmi1;Bmi2;Fma;Lzcnt;Pclmulqdq;Popcnt;Sse;Sse2;Sse3;Ssse3;Sse41;Sse42;X86Base

Also for reference if Vector2.Dot didn't work then the entirety of physics would break.

For another sanity check can you add the following code in your Vector2Dot function:
if (!float.IsFinite(value1.X) || !float.IsFinite(value1.Y) || !float.IsFinite(value2.X) || !float.IsFinite(value2.Y))
    throw new InvalidOperationException();

Also for reference if Vector2.Dot didn't work then the entirety of physics would break.

If nothing else it's possible it's some cursed codegen issue that only manifests in this one method.
@devkoks can you try if you move the code calling Vector2.Dot into a smaller function? Heck I'd be willing to see the result if you make Vector2Dot this:
        [MethodImpl(MethodImplOptions.NoInlining)]
        // Copied from "System.Numerics.Vector2.Dot", because it's working unstable on some systems.
        public float Vector2Dot(Vector2 value1, Vector2 value2)
        {
            return (value1.X * value2.X)
                 + (value1.Y * value2.Y);
        }

Another thing to try: [MethodImpl(MethodImplOptions.NoOptimization)] on HandleShuttleMovement

This is straight up "this needs an upstream bug in the .NET runtime" tier if this fixes it. This really demands further investigation.
Can you send me the top of your server log when it starts (or at least enough for the intrinsics):
[INFO] root: Server -> Starting
[INFO] cfg: Configuration loaded from file
[DEBG] root: OS: Microsoft Windows 10.0.22631 X64
[DEBG] root: .NET Runtime: .NET 8.0.0 win-x64
[DEBG] root: Server GC: True
[DEBG] root: Processor: 24x AMD Ryzen 9 5900X 12-Core Processor
[DEBG] root: Architecture: X64
[DEBG] root: Robust Version: 205.0.0.0
[DEBG] root: Compile Options: DEVELOPMENT;TOOLS;DEBUG;CLIENT_SCRIPTING
[DEBG] root: Intrinsics: X86Aes;Avx;Avx2;Bmi1;Bmi2;Fma;Lzcnt;Pclmulqdq;Popcnt;Sse;Sse2;Sse3;Ssse3;Sse41;Sse42;X86Base

[INFO] root: Server -> Starting
[INFO] cfg: Configuration loaded from file
[DEBG] root: OS: Debian GNU/Linux 12 (bookworm) X64
[DEBG] root: .NET Runtime: .NET 8.0.1 linux-x64
[DEBG] root: Server GC: True
[DEBG] root: Processor: 12x Common KVM processor
[DEBG] root: Architecture: X64
[DEBG] root: Robust Version: 204.0.0.0
[DEBG] root: Compile Options: DEVELOPMENT;RELEASE;EXCEPTION_TOLERANCE
[DEBG] root: Intrinsics: Sse;Sse2;Sse3;X86Base

Issue reproduces locally for me by setting DOTNET_enableSSSE3=0 via env variable and running the server on release. I'll see about getting a repro to dotnet/runtime. In the mean time I'll merge this workaround.

By the way @devkoks are you actually running the game on a 17 year old CPU? Intel CPUs with SSSE3 started shipping in 2006. If you aren't you should double check your hypervisor configuration or something as it may be misconfigured.

By the way @devkoks are you actually running the game on a 17 year old CPU? Intel CPUs with SSSE3 started shipping in 2006. If you aren't you should double check your hypervisor configuration or something as it may be misconfigured.

No, CPU installed on server: Intel Xeon E5-2620

Yeah then your hypervisor config is messed up and reporting a significantly older CPU to the VM. If nothing else, fixing this will slightly improve server perf. I also think some newer distros like RHEL 9 can't boot in this state.

authors: PJB3005 devkoks metalgearsloth


text:
add Healium and BZ gas

About the PR
Adds two new atmospheric gases, Healium, and it's precursor BZ. (Primarily restored from whateverusername0's lost BZ pull request)
BZ is created by mixing plasma and nitrous oxide in an explosive exothermic reaction. It's primary use is as a precursor in the generation of more complex gases, though for those seeking enlightenment, it is often used as a cheap substitute to frezon, albeit far more dangerous to consume.
Healium is created in an exothermic reaction by mixing BZ and frezon at below room temperatures, though highest efficiency is achieved at lower temperatures. Healium is an expensive gas that has healing properties when inhaled, however, will also make you tired and slow.
Why / Balance
The addition of these gases is intended to add more variance to the atmos gameplay loop, as well as increase cross department cooperation as Healium generation is most efficient at temperatures achievable by hellfire freezers, and the gas can be used by medical to treat patients. At higher efficiencies, it is economical to sell the gas to cargo as it is worth more than it's parts, though those profits greatly diminish and disappear when generated at higher temperatures.
Technical details
Mainly follows the specifications laid out here for generation

healium-production.webm
bz-effects.webm
bz-slime-effects.webm
healium-effects.webm
Requirements

[ X] I have read and am following the Pull Request and Changelog Guidelines.
[ X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes
No breaking changes are made
Changelog
:cl:

add: Added BZ - a slime person sleeping agent and overall a toxic gas, which is made by mixing N2O and plasma under low pressures.
add: Added Healium - a powerful sleeping agent with healing properties when inhaled. Made by mixing BZ and Frezon at low temperatures.

I'll need a lot of input on balancing them, but figured I would get something workable up that can be played with. Currently also lacking good sprites, particularly on the Healium side.

anything but this please

atmos needs actual gameplay not just copying TG slop, this changes absolutely nothing about atmos

atmos needs actual gameplay not just copying TG slop, this changes absolutely nothing about atmos

It would hopefully increase the need for atmos to interact with more of the station and give atmos and the station a reason to hold onto the gases they create rather than sell them all.  I'm definitely not against other mechanics to add variety to atmos gameplay, but I feel like there are a lot of people enjoy atmos as it is now.

Helium flood the station for infinite regen

atmos needs actual gameplay not just copying TG slop, this changes absolutely nothing about atmos

Some of the most interesting tried and true atmos content we could add is "TG slop." I don't want to fall into the fallacy of tradition, but they've been doing this longer than most of us, so I wouldn't dismiss their content as "slop."

atmos needs actual gameplay

such as?
Atmos is pretty barebones with the gutting of frezon use now. After distro and waste is setup all atmos can really do is teg. Sure they can do engie stuff but if they wanted to focus on station power and repairs they would have joined the round as an engie...
Adding more gasses with neat effects IS adding atmos gameplay. Especially when these gasses have interplay between departments.

this changes absolutely nothing about atmos

does every atmos change need to be so large that it changes the way atmos plays? Why cant we add more stuff to atmos?

atmos is already kinda annoying to work with, so i'm not sure people would be able to make any real use of those gases
i believe tg has RPD and pipe stacking, which make atmos actually okay to work with

Those would definitely be helpful, but I was thinking these would be late game gases anyway, as healium would have some pretty strong uses. It would also give atmos techs more of a reason to work together by setting up different parts simultaneously to get healium earlier in a round.

It looks like it heals too slowly, cryo does it much better and easier

It looks like it heals too slowly, cryo does it much better and easier

So at the moment, it's just tied to how much you're breathing in. If you lower the temperature, increase tank kpa, and breathe close to pure healium, it heals incredibly fast. Maybe too quickly. I might need to add some sort of cap for it.

Give us actual helium so we can make the station people squeaky!

Similar to what mirrorcult said- currently we feel that the actual gameplay of making gasses is rather subpar. It largely boils down to just following a setup you found online or made in a previous round and then waiting. We'd rather see atmos' core gameplay improved before (further) encouraging them to spend their entire round inside of atmosia to occasionally give med / other departments some gas.

atmos needs actual gameplay not just copying TG slop, this changes absolutely nothing about atmos

Similar to what mirrorcult said- currently we feel that the actual gameplay of making gasses is rather subpar. It largely boils down to just following a setup you found online or made in a previous round and then waiting. We'd rather see atmos' core gameplay improved before (further) encouraging them to spend their entire round inside of atmosia to occasionally give med / other departments some gas.

maintainer refuses to play on an LRP server and discover round to round external environment consequences, covering live on honk tv

authors: BasedUser CBozo Ilya246 LankLTE Sarahon WhiteGorila cohanna marc-pelletier mirrorcult saga3152


text:
ECS APCs

About the PR

APC state update only happens when the battery charge actually changes as opposed to every tick always
Removes the IActivate interface from it in favor of ActivatableUI

Requires space-wizards/RobustToolbox#2426
old power code is stinky

now requires space-wizards/RobustToolbox#2426 for proper point-light-visualizer


text:
tortoise, sync: required data for tortoise when syncing a new node

In the current tortoise version expected weight is computed based on the difference from the last layer with the layer that we want to verify (target layer). Currently last layer is just a last layer that was ever received by the tortoise. But the last layer must be set according to the clock as defined in https://github.com/spacemeshos/go-spacemesh/issues/2921.
It brings up two additional requirements on sync:

[x]  all atxs must be added to the database before tortoise will start verification, otherwise, it won't be able to compute the expected weight
[ ] in order to use verifying tortoise we need to get input vectors from peers. previously it was mistakenly assumed that input vector means hare output, in fact it means actual local peer opinion from layers before hdist, and hare output for layers in the hdist distance.

Basically we will have to implement this issue before https://github.com/spacemeshos/go-spacemesh/issues/2921 is implemented.
cc @countvonzero

the second part of this issue is currently blocked by #3283

authors: countvonzero dshulyak

repo: spacemeshos/go-spacemesh


text:
Epic: Implement New App Flows

See the journeys documented here: https://product.spacemesh.io/#/smapp_wallets_flows
There's an interactive prototype for each flow that needs to be implemented.
New first time user-experience interactive prototype: https://www.figma.com/proto/6bbFkIAzVu36bIpUNnMqoy/Smapp-Designs?node-id=4847%3A8399&viewport=872%2C486%2C0.07435446232557297&scaling=min-zoom

There are 2 open issues to finish this epic: gpu-post integration and transactions integration.

repo: spacemeshos/smapp


text:
WIP: No distortion mode

I think I have the distortionless mode working. My first test for a series of point sources separated by a constant RA across the detector produced data with the sources separated by a constant number of pixels. I still want to test using a non-zero telescope roll, to make sure that my fake WCS is correct.
To get distortionless output, set the distortion reference file input field to None. This brings up a related topic: the names in the input yaml file are confusing. Currently the astrometric entry contains the name of the distortion reference file (and should be set to None for distortionless mode), while the distortion_coeffs entry contains the name of the SIAF, which is still needed. These names should be changed, but this will break earlier versions of the code, and necessitate changes in the simulator code and yaml generator function. Maybe these changes should be saved for a separate pull request, in order to get distortionless mode implemented in the master branch now?

It is true that the naming is a little confusing but I suggest to hold off breaking changes for 'cosmetic' reasons until a later time. There are other similar issues (e.g. #67, and other items that are coming as we implement NIRISS and FGS support) which we could possible clean up alltogether.

Makes sense to me. I'll open a separate issue about the yaml entry names. My distortionless test using a non-zero telescope roll looks ok as well. I think this is now ok to merge.


text:
working with macos

Use .so instead of .dylib on macos.

@devvit
Merged. Thank you!

authors: devvit spacewander


text:
Question about Hyphen Tokenization

In previous versions of spaCy, there were some inconsistencies with hyphen tokenization:
e.g. next   -   of-kin.
These have now been fixed and all hyphenated words get tokenized as follows:
e.g. next  -  of  -  kin.
This is a lot better than before, but I'd still be interested to know why spaCy tokenises hyphens in this way when most other well-known NLP libraries choose to keep everything together:
e.g. next-of-kin.
Even though you can fairly easily trick other libraries with strings such as "This-is-a-sentence", it still seems preferable to treat "next-of-kin" as a simple NN, rather than a JJ-HYPH-IN-HYPH-NN sequence.
I would also have thought most training data for POS taggers etc. usually keeps such sequences together, so it also seems unusual that everything is split by default.

It really comes down to the fact that we train and evaluate on OntoNotes 5, where most NLP tools evaluate on the older Penn Treebank 3 data, specifically the WSJ section.
If you want next-of-kin to be kept together, you could add a rule to the tokenizer. This is now exposed in the API:

tokenizer.add_special_rule(u'next-of-kin', [{'F': 'next-of-kin', 'L': 'next-of-kin', 'P': 'NN'}])

authors: Terrilocks honnibal

repo: spacy-io/spaCy


text:
Broken XML feed in bottom corner of calendar page

On the calendar page, there is a broken link. The link is to:
https://www.google.com/calendar/feeds/nlkc39jt4p0nbc4pk9pj7p5fh0%40group.calendar.google.com/public/basic
Visiting this link gives you 403 forbidden.
The image source is: http://www.google.com/calendar/images/xml.gif . That is a broken image as well.
I am not sure what this link was for. Was it supposed to be an RSS feed? Now that it is broken what should we do? Just delete it? Replace it with something else? Why would there have been two separate RSS feeds?

It looks like that was the original Google Calendar RSS feed, which Google helpfully discontinued in 2015: https://www.404techsupport.com/2015/10/google-discontinue-feed-google-calendars/ . Ugh.
It may be possible to use the API to regenerate a feed, but I do not know how intensive this will be. As an RSS zealot I am loathe to see the feed disappear entirely.

This is the same issue as #6 . I am closing this issue and just using the other one instead.


text:
[bug] java gems package C extension code

Please describe the bug
The java platform gems contain the C extension code. This is unnecessary and should be removed to make the gem file as small as possible.
Help us reproduce what you're seeing
$ gem fetch nokogiri --platform jruby -v 1.10.10
Downloaded nokogiri-1.10.10-java

$ tar -xvf nokogiri-1.10.10-java.gem
metadata.gz
data.tar.gz
checksums.yaml.gz

$ tar -ztvf data.tar.gz | egrep "\.[ch]$"
-rw-r--r-- wheel/wheel    4500 2020-07-06 09:18 ext/nokogiri/html_document.c
-rw-r--r-- wheel/wheel     159 2020-07-06 09:18 ext/nokogiri/html_document.h
-rw-r--r-- wheel/wheel    5990 2020-07-06 09:18 ext/nokogiri/html_element_description.c
-rw-r--r-- wheel/wheel     202 2020-07-06 09:18 ext/nokogiri/html_element_description.h
-rw-r--r-- wheel/wheel     813 2020-07-06 09:18 ext/nokogiri/html_entity_lookup.c
-rw-r--r-- wheel/wheel     136 2020-07-06 09:18 ext/nokogiri/html_entity_lookup.h
-rw-r--r-- wheel/wheel    3079 2020-07-06 09:18 ext/nokogiri/html_sax_parser_context.c
-rw-r--r-- wheel/wheel     197 2020-07-06 09:18 ext/nokogiri/html_sax_parser_context.h
-rw-r--r-- wheel/wheel    2175 2020-07-06 09:18 ext/nokogiri/html_sax_push_parser.c
-rw-r--r-- wheel/wheel     184 2020-07-06 09:18 ext/nokogiri/html_sax_push_parser.h
-rw-r--r-- wheel/wheel    4302 2020-07-06 09:18 ext/nokogiri/nokogiri.c
-rw-r--r-- wheel/wheel    3094 2020-07-06 09:18 ext/nokogiri/nokogiri.h
-rw-r--r-- wheel/wheel    2281 2020-07-06 09:18 ext/nokogiri/xml_attr.c
-rw-r--r-- wheel/wheel     137 2020-07-06 09:18 ext/nokogiri/xml_attr.h
-rw-r--r-- wheel/wheel    1428 2020-07-06 09:18 ext/nokogiri/xml_attribute_decl.c
-rw-r--r-- wheel/wheel     176 2020-07-06 09:18 ext/nokogiri/xml_attribute_decl.h
-rw-r--r-- wheel/wheel    1516 2020-07-06 09:18 ext/nokogiri/xml_cdata.c
-rw-r--r-- wheel/wheel     141 2020-07-06 09:18 ext/nokogiri/xml_cdata.h
-rw-r--r-- wheel/wheel    1703 2020-07-06 09:18 ext/nokogiri/xml_comment.c
-rw-r--r-- wheel/wheel     149 2020-07-06 09:18 ext/nokogiri/xml_comment.h
-rw-r--r-- wheel/wheel   15713 2020-07-06 09:18 ext/nokogiri/xml_document.c
-rw-r--r-- wheel/wheel     705 2020-07-06 09:18 ext/nokogiri/xml_document.h
-rw-r--r-- wheel/wheel    1105 2020-07-06 09:18 ext/nokogiri/xml_document_fragment.c
-rw-r--r-- wheel/wheel     189 2020-07-06 09:18 ext/nokogiri/xml_document_fragment.h
-rw-r--r-- wheel/wheel    4133 2020-07-06 09:18 ext/nokogiri/xml_dtd.c
-rw-r--r-- wheel/wheel     134 2020-07-06 09:18 ext/nokogiri/xml_dtd.h
-rw-r--r-- wheel/wheel    2595 2020-07-06 09:18 ext/nokogiri/xml_element_content.c
-rw-r--r-- wheel/wheel     218 2020-07-06 09:18 ext/nokogiri/xml_element_content.h
-rw-r--r-- wheel/wheel    1373 2020-07-06 09:18 ext/nokogiri/xml_element_decl.c
-rw-r--r-- wheel/wheel     168 2020-07-06 09:18 ext/nokogiri/xml_element_decl.h
-rw-r--r-- wheel/wheel    1740 2020-07-06 09:18 ext/nokogiri/xml_encoding_handler.c
-rw-r--r-- wheel/wheel     142 2020-07-06 09:18 ext/nokogiri/xml_encoding_handler.h
-rw-r--r-- wheel/wheel    2660 2020-07-06 09:18 ext/nokogiri/xml_entity_decl.c
-rw-r--r-- wheel/wheel     165 2020-07-06 09:18 ext/nokogiri/xml_entity_decl.h
-rw-r--r-- wheel/wheel    1189 2020-07-06 09:18 ext/nokogiri/xml_entity_reference.c
-rw-r--r-- wheel/wheel     184 2020-07-06 09:18 ext/nokogiri/xml_entity_reference.h
-rw-r--r-- wheel/wheel    1255 2020-07-06 09:18 ext/nokogiri/xml_io.c
-rw-r--r-- wheel/wheel     257 2020-07-06 09:18 ext/nokogiri/xml_io.h
-rw-r--r-- wheel/wheel    2971 2020-07-06 09:18 ext/nokogiri/xml_libxml2_hacks.c
-rw-r--r-- wheel/wheel     258 2020-07-06 09:18 ext/nokogiri/xml_libxml2_hacks.h
-rw-r--r-- wheel/wheel    2516 2020-07-06 09:18 ext/nokogiri/xml_namespace.c
-rw-r--r-- wheel/wheel     299 2020-07-06 09:18 ext/nokogiri/xml_namespace.h
-rw-r--r-- wheel/wheel   43736 2020-07-06 09:18 ext/nokogiri/xml_node.c
-rw-r--r-- wheel/wheel     305 2020-07-06 09:18 ext/nokogiri/xml_node.h
-rw-r--r-- wheel/wheel   12120 2020-07-06 09:18 ext/nokogiri/xml_node_set.c
-rw-r--r-- wheel/wheel     377 2020-07-06 09:18 ext/nokogiri/xml_node_set.h
-rw-r--r-- wheel/wheel    1336 2020-07-06 09:18 ext/nokogiri/xml_processing_instruction.c
-rw-r--r-- wheel/wheel     208 2020-07-06 09:18 ext/nokogiri/xml_processing_instruction.h
-rw-r--r-- wheel/wheel   14471 2020-07-06 09:18 ext/nokogiri/xml_reader.c
-rw-r--r-- wheel/wheel     146 2020-07-06 09:18 ext/nokogiri/xml_reader.h
-rw-r--r-- wheel/wheel    3660 2020-07-06 09:18 ext/nokogiri/xml_relax_ng.c
-rw-r--r-- wheel/wheel     152 2020-07-06 09:18 ext/nokogiri/xml_relax_ng.h
-rw-r--r-- wheel/wheel    8544 2020-07-06 09:18 ext/nokogiri/xml_sax_parser.c
-rw-r--r-- wheel/wheel     841 2020-07-06 09:18 ext/nokogiri/xml_sax_parser.h
-rw-r--r-- wheel/wheel    5736 2020-07-06 09:18 ext/nokogiri/xml_sax_parser_context.c
-rw-r--r-- wheel/wheel     192 2020-07-06 09:18 ext/nokogiri/xml_sax_parser_context.h
-rw-r--r-- wheel/wheel    3683 2020-07-06 09:18 ext/nokogiri/xml_sax_push_parser.c
-rw-r--r-- wheel/wheel     180 2020-07-06 09:18 ext/nokogiri/xml_sax_push_parser.h
-rw-r--r-- wheel/wheel    5391 2020-07-06 09:18 ext/nokogiri/xml_schema.c
-rw-r--r-- wheel/wheel     145 2020-07-06 09:18 ext/nokogiri/xml_schema.h
-rw-r--r-- wheel/wheel    1788 2020-07-06 09:18 ext/nokogiri/xml_syntax_error.c
-rw-r--r-- wheel/wheel     359 2020-07-06 09:18 ext/nokogiri/xml_syntax_error.h
-rw-r--r-- wheel/wheel    1143 2020-07-06 09:18 ext/nokogiri/xml_text.c
-rw-r--r-- wheel/wheel     138 2020-07-06 09:18 ext/nokogiri/xml_text.h
-rw-r--r-- wheel/wheel    7695 2020-07-06 09:18 ext/nokogiri/xml_xpath_context.c
-rw-r--r-- wheel/wheel     311 2020-07-06 09:18 ext/nokogiri/xml_xpath_context.h
-rw-r--r-- wheel/wheel    7420 2020-07-06 09:18 ext/nokogiri/xslt_stylesheet.c
-rw-r--r-- wheel/wheel     292 2020-07-06 09:18 ext/nokogiri/xslt_stylesheet.h

Hmm. After some thought, it's helpful to have the C extension files present as extra_rdoc_files, and they compress down to about 43KB which isn't much compared to the size of the 5.6MB gemfile. I'm going to close this and not actually do it, to preserve the local rdoc experience and avoid surprise.

repo: sparklemotion/nokogiri


text:
remove cli installation from setup script

Description
We no longer do this by default. The cli is installed in the dockerfile, and if users want to use the remote version these instructions are in the docs.
Related PRs
List related PRs if applicable
Todos

[ ] Tests
[ ] Documentation
[ ] Link to Trello

@martineehrlich this is no longer needed as the CLI has been removed from the install script in https://github.com/sparkswap/broker/pull/454

authors: dannypaz martineehrlich

repo: sparkswap/broker


text:
Warning C4996: TBaseMulticastDelegate

Issue
This warning is produced when I build 4.24-SpatialOSUnrealGDK-release using Visual Studio 2019 16.8.4:
1>C:\Unreal\UnrealEngine\Engine\Source\Runtime\Core\Public\Delegates/DelegateSignatureImpl.inl(788): warning C4996: 'TBaseMulticastDelegate<void>::AddRaw::FDeprecationMsg_788::condition': Binding a delegate with a const object pointer and non-const function is deprecated. Please update your code to the new API before upgrading to the next release, otherwise your project will no longer compile. 1> C:/Unreal/UnrealEngine/Engine/Plugins/Runtime/nDisplay/Source/DisplayCluster/Private/Render/DisplayClusterRenderManager.cpp(649): note: see reference to function template instantiation 'FDelegateHandle TBaseMulticastDelegate<void>::AddRaw<const FDisplayClusterRenderManager,>(UserClass ,void (__cdecl FDisplayClusterRenderManager:: )(void))' being compiled 1> with 1> [ 1> UserClass=const FDisplayClusterRenderManager 1> ] 1> C:/Unreal/UnrealEngine/Engine/Plugins/Runtime/nDisplay/Source/DisplayCluster/Private/Render/DisplayClusterRenderManager.cpp(649): note: see reference to function template instantiation 'FDelegateHandle TBaseMulticastDelegate<void>::AddRaw<const FDisplayClusterRenderManager,>(UserClass ,void (__cdecl FDisplayClusterRenderManager:: )(void))' being compiled 1> with 1> [ 1> UserClass=const FDisplayClusterRenderManager 1> ]
Workaround
This warning is harmless, you can ignore it, or follow these steps to turn it off.
Internal ticket
UNR-4705.

This warning is produced by Epic's code, not Improbable's.
It does not produce in later Unreal Engine versions.

For the above reasons, we will not fix this issue.

repo: spatialos/UnrealGDK


text:
fix ltdb codebook error and make windows tests optional

this pr fixes an error in the codebook for ltdb and allows windows tests to fail because they segfault when performing the add_data test when the data are available. I'm not sure what the underlying cause is, but for now we can just run the tests but allow them to fail in that case

resolves #225

repo: spatialucr/geosnap


text:
Add metadata to log items

Hi,
When our app is running, we basically have some "metadata" that we would like to see logged on all activitylog entries.  For instance, we always know the "supplier" and "customer" the request is running for, so, next to the user, I would always like to see these items added to the log as well.
What's the best way to achieve this?
Should I listen to the Spatie\Activitylog\Modelssaving event to update the properties at that time?  That'll probably work, but not sure if it's the 'best way'...

I see two options:

event listener, like you said - my favorite
override the log method in the manager - not so cool

It could be that we add a third option - a callback function. But if you want it everytime the event listener would be the best.
Think about cronjobs, commands and so on. They don't have a session, so write your listener to respect this. 😉

authors: Gummibeer denjaland

repo: spatie/laravel-activitylog


text:
Using this library but the branch l5.2

Hi
Is there a way to use this package but with php 5.6? I saw the other repository but this one relates to a model and is the perfect case scenario I'm looking.
Hope to hear back from you guys
Great work!

Some users have created a backport for PHP 5.6. I think you'll find the fork when searching for it on packagist.

thanks @freekmurze after the post, I found the backport listed on the issues here in this repo.

authors: freekmurze krugerdavid


text:
Restore Laravel 5.1 LTS compatibility

Tying this again...  I believe it really is this simple, it is working fine for me.  All tests are passing under 5.1 (have to force composer to install it—it looks like it is possible to automate this in Travis.)
Please let me know if you can think of anything I've missed here.

Thanks! I'll add this in for now. Be warned however that I'm likely to drop 5.1 support again if it makes introducing a new feature difficult.

No problem.  Hopefully I'll have been able to upgrade by the time that happens, but feel free to ping me and I'll see if I can't contribute another fix.

authors: freekmurze hackel


text:
Url with no extension?

Suddenly today I am getting an error as the package is getting this url back without an extension.
https://fonts.gstatic.com/l/font?kit=XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTA3iazbXWjgevT5&skey=27bb6aa8eea8a5e7&v=v26
It is a woff file but GoogleFonts::localizeFontUrl() expects it to have an extension and therefor throws a 500 error. It seems to happen quite randomly, and if I run my test suite it happens at least once.
If I check the font files in the storage directory I dont find this url anywhere, so I expect it comes directly from google.
Is it perhaps possible to ensure it does not query google in tests at all (even if not preloaded)?

After several attempts with xdebug I finally was able to get the content of $css in GoogleFonts::fetch()
/* cyrillic-ext */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/l/font?kit=XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTk3iazbXWjgevT5&skey=27bb6aa8eea8a5e7&v=v26) format('woff');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* cyrillic */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/l/font?kit=XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTA3iazbXWjgevT5&skey=27bb6aa8eea8a5e7&v=v26) format('woff');
  unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
}
/* vietnamese */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/nunito/v26/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTs3iazbXWjgevT5.woff) format('woff');
  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+0300-0301, U+0303-0304, U+0308-0309, U+0323, U+0329, U+1EA0-1EF9, U+20AB;
}
/* latin-ext */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/nunito/v26/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTo3iazbXWjgevT5.woff) format('woff');
  unicode-range: U+0100-02AF, U+0304, U+0308, U+0329, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/s/nunito/v26/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTQ3iazbXWjgeg.woff) format('woff');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Can you share the Google Fonts URL you're using to load fonts?

Sure :) Its this https://fonts.googleapis.com/css?family=Nunito
But as I said it seems to happen at random. I had force download for this font which made it redownload every time, which cause issues like 1-10 time it downloaded. Just a suggestion to perhaps just have it do a fallback to .woff if no extension is found or similar :)

Interesting, haven't come across this during testing. I agree it should fall back to providing an extension based on the format function in the CSS property.
I currently don't have time to work on this, but contributions welcome!

authors: sebastiandedeyne sinnbeck

repo: spatie/laravel-google-fonts


text:
Dependabot Updates for Github Actions

This PR adds a GitHub Dependabot config file & workflow for updating github action versions.  It auto-merges the PRs for minor and patch versions only, and only creates PRs for major version updates.  It checks for updates once weekly.
I feel this is a necessary and important step forward in maintaining a large number of packages as I've discovered a number of outdated GitHub action versions that should have been updated long ago while working on PHP 8.1 updates.  There is no reason, in my opinion, not to automate the updating of github action versions.
This only affects github actions within workflow files and doesn't update composer (or any other) dependencies.  While possible, I think that updating/automerging composer dependencies requires an involved discussion.
I am only opening this PR for package-skeleton-php, and if approved I will open one for package-skeleton-laravel as well, along with a project of updating all existing packages.
I open the floor to discussion.

Cool, let's try it out! Feel free to send this to the Laravel skeleton as well.

authors: freekmurze patinthehat

repo: spatie/package-skeleton-php


text:
Update badge alt text

If the bade doesn't load, this will still allow users to see what the license is. It is also beneficial for users who use screen readers.

Thanks for your input and PR.

authors: BackEndTea Gummibeer

repo: spatie/schema-org


text:
Fix issue where multidimensional arrays with a singleton dimension sometimes fail

Encountered a bug where multidimensional arrays with a singleton dimension can result in a failing SDFG. @tbennun guided me on the bug fix, and has said he'll write the unit tests. Leaving this as a draft until appropriate unit tests can be written.

@tbennun Isn't this a code generation error? If the data being indirected has n dimensions, then the lookup index should also have n indices. The issue seems to be in DaCeKeywordRemover._subscript_exr:
            # Pointer to a single element can use all strides
            is_scalar = not isinstance(dtype, dtypes.pointer)
            if is_scalar or data._prod(subset_size) != 1:
                strides = [
                    s for i, s in enumerate(strides) if i not in indexdims and not (s == 1 and subset_size[i] == dimlen)
                ]

Shouldn't the scalar detection be if is_scalar or data._prod(subset_size_ == 1 (equality)? I may have misunderstood what this code is doing and it is squeezing the strides on purpose but we need to somehow document this. Still, expecting squeezed data in the code generator looks like a dangerous design.

@alexnick83 unfortunately not. We thought so too at first and then found out that a memlet with [0, …] is already fed into the tasklet, which squeezes that dimension. So the tasklet mismatches the incoming memlet already in the frontend

@alexnick83 unfortunately not. We thought so too at first and then found out that a memlet with [0, …] is already fed into the tasklet, which squeezes that dimension. So the tasklet mismatches the incoming memlet already in the frontend

Then the test is not showcasing the problem (and showing a code generator problem instead). Array a has shape 1, 2, 3; so the first index will be 0 anyway. I tried the test in master and the access is not squeezed, all dimensions are in the memlet.

Superseded by #1302

authors: alexnick83 computablee tbennun

repo: spcl/dace


text:
Convert RDF to a Golang struct

Does this project enables to convert a rdf turtle (TTL file format) to a Golang struct.
I.e. marshal & unmarshal to/from TTL/struct.

This library is written to convert a rdf file written in rdf/xml format to triples.
Thanks for asking.

authors: BoraBak RishabhBhatnagar

repo: spdx/gordf


text:
Added Option<>.get() that throws on none() instances

This can be usually avoided with fold(), Option.map2() etc., but there
are still cases where it's otherwise known that given instance of
Option<> is some() and then this shorthand can be useful.

Hi and thanks for your PR! I'm really sorry, but I'm going to take the role of obsessive FP zealot here... :-/
Not including Option#get in dartz has been a very deliberate decision. Among the guiding principles I've tried to adhere to while designing dartz has been to keep the public API referentially transparent and free of things that break parametric polymorphism. This implies staying away from observable side effects and reflection on free type parameters, but in practice also means avoiding exceptions and "weird" things such as nully/toppy/bottomy types and values as far as possible. I've made some compromises down the road (forEach, toIterable, etc.), but I'm still trying to avoid adding non-RT things unless they are essential for bridging between FP and non-FP code in an efficient way.
To me, Option#get not only breaks these principles, but also obscures the purpose of using Option in the first place. I'm very aware that several popular implementations of Option/Optional/Maybe/etc do have a get() method or similar functionality. I've seen way too much java code where Optional is only used to avoid if (something != null) statements and to get to map and filter before unwrapping with get(). In my mind, this kind of misses the point and makes other programmers question the value of Optional. Subjectively, the point of Option is to deal with partial functions in an honest, open and RT way, as well as to have the type system remind the programmer to deal explicitly with partiality when necessary.
For Option#get, I think there are plenty of escape hatches available already, such as:
final valueOrNull = optionalValue|null;

A barf<A>() => throw "Hey! This Option wasn't supposed to be None :-(";
.
.
.
final value = optionalValue.getOrElse(barf);

optionalValue.forEach(sideEffect);

I think all of the options (excuse the pun...) above make it more explicit when you, as a developer, make the conscious decision to either apply out-of-band knowledge concerning the existence of a value or to somehow deal with the consequences of a missing value in a non-RT way.
Having said that, I have a counter proposal. There's the dartz_unsafe sub-library, where I've stuffed non-RT things such as unsafePerformIO. How about a method there? Something along the lines of:
part of dartz_unsafe;

A unsafeForceOption<A>(Option<A> oa) => oa.getOrElse(() => throw new StateError("Tried to force empty Option"));

Expressed this way and with the requirement of an import of dartz_unsafe, it is hopefully more clear that this is not the intended way of unwrapping Option and that referential transparency potentially is lost in code that uses it.
What do you think? Sorry for being difficult :-)

Hi, thanks for a thorough response!
This is kind of what I expected, because the traditional "get()" is more basic than other things in the library that were already implemented, and it does have a smell of being less pure.
As you're expecting, I don't agree with some of your reasoning.
For example, I don't see how throwing an assert-like exception (one the caller is not supposed to handle) constitutes a side effect.
Most importantly, in practice, I found that I need this when I'm in part of the code that I know has invariants fulfilled, but that were impractical to express via the type system (say, non-trivial relationships between optional values, where not all combinations of them being "some" make sense).
I fully agree that lack of "get()" probably made a few people look for other options and find a more robust solution, but there are reasonable use cases and this is where I get bitten by the opinionated choice.
Anyway, as you said it's easy to workaround - like a trivial private method optionGet(Option) that I'm using, so I'll survive.
I'd vote against unsafeForceOption - at least I wouldn't use it myself.

@noinskit, what and what doesn't constitute a side effect is definitely debatable, but it is easy to prove that throwing exceptions break referential transparency: https://nrinaudo.github.io/scala-best-practices/referential_transparency/avoid_throwing_exceptions.html
Slightly related -- you might also find the recently merged PR https://github.com/spebbe/dartz/pull/15 interesting.

authors: noinskit spebbe

repo: spebbe/dartz


text:
Fix ReverseProxied middleware and add docs

Starlette introduced some new changes to how the root_path is handled, which broke our ReverseProxied example and test.
This PR fixes both and adds documentation on how to run behind a proxy.

coverage: 94.214%. remained the same
when pulling df8abd34c414b615a34645c073cd12a227948d50 on bugfix/reverse-proxy
into f8f461c5240f6d01b0d8c7104387993ce811b2c7 on main.

authors: RobbeSneyders coveralls

repo: spec-first/connexion


text:
Cannot get a "raw" value without the formatting

It's not possible to get a "raw" value without the formatting even if you were to send false in the format_value parameter in get_field. See the third parameter $format_value here https://www.advancedcustomfields.com/resources/get_field/.
I think it could be fixed by changing the load_value function in acf-price-common.php to format_value instead.

Thanks. Merged.

authors: speccode triggerjoi

repo: speccode/acf-price


text:
Slow loading times on Operations.Receive

Hi,
we are currently having issues with long loading times within unity with the latest connector.
When we are getting an object with ~10k objects then we need to wait ~4min (at least!) for just the Receiving operation of speckle.
The algorithm which generates the game objects from the base object only takes around ~30seconds which is really good for that amount of objects.
The problem is at file Receiver.cs @ line 134.
        var @base = await Operations.Receive(           objectId,           remoteTransport: transport,           onErrorAction: OnErrorAction,           onProgressAction: OnProgressAction,           onTotalChildrenCountKnown: OnTotalChildrenCountKnown,           disposeTransports: true         );
Nearly the same code which I reproduced on .NET Core 3.1 Console Application with the latest NuGet package of speckle core only needs ~45seconds.
Why is it so slow? Is it a known problem? What can I do to speed it up?
We are using the connector within an application for an 3d cave environment with a customer.
Later on we want to load even larger models, the customer already told us that he experienced loading times up to 40 minutes.
The test above were taken both from our cave application and the provided unity speckle playground. There was no difference in performance.
I also tried to upgrade the speckle connectors speckle sharp dlls manually to the latest version, which also didn't help. Same issue.
Tested on hardware:
11th Gen Intel Core i7 1165G7 @ 2,8GHz
16GB DDR4 RAM 3200MHz
SSD
Integrated Graphics

After some further testing, I am noticing some quite significant slowness even in Unity 2021.
Compared with a .NET project, the Deserialisation appears to be around 10x slower in Unity 😢 not good.
Going to do some more rigorous measurements, and continue investigating.

I've tested it with unity 2019, 2020 and 2021 each with mono and il2cpp scripting background. There was no measureable performance difference.
What's strange: Shouldn't the models be cached? Then the second loading time should be much faster than the first, but it is not.
Unfortunately, I can not share the model, as it is a model from the customer.

hi, I might be able to help clarify what's happening here. I don't think the issue with Operations.Receive but with the conversion routines from a speckle stream to native unity geometry.

The algorithm which generates the game objects from the base object only takes around ~30seconds which is really good for that amount of objects.

This part ends up happening after the receive command has completed and starts dropping all the speckle data into the conversion process, and then I'm assuming that's where the long 20-40 minute delays are coming in. It doesn't matter if the geometry is cached locally on your machine, the conversion process still needs to rebuild all the speckle goodness into the unity scene. The converters are currently all bound to run on the main unity thread, and also have a few steps for serializing a speckle object that are creating the bottleneck.
I have some PR's coming in the near future that will address these issues. In the meantime, @LukasKlepper how are you using the connector? Is it for visualization purposes? If you don't need to worry about the properties of your objects and you're comfortable with jumping around the code you could comment out the part in the converter that uses SpeckleProperties, that would reduce the conversion overhead a bit.

Hi @haitheredavid ,
thanks for you answer. So correct me if im wrong:
the line Receiver.cs@134 takes part of getting all the data from the speckle server. Thats just the base informations which later on will be converted to game objects which get feeded with the speckle properties. We also use that exactly same method in other applications which build up on speckle, but in asp.net core server applications rather than unity. In other projects this method is very fast (~30 seconds for the same model as in unity)
the line Receiver.cs@142-152 takes those informations from the base object and then converts this base information to unity game objects ands adds the speckle properties to it. It gets queded by the Dispatcher to the main thread as only there you can build game objects or access specific api calls. Of course thats slower than multi-theading but I think thats the way unity currently works on the classical API. I'm not a unity expert so thats a pure idea: Maybe Unity DOTS is a way how those game objects could be built up multi threaded? I've never done it so I dont know if that could solve the problem of conversion process, but as you will later on read, thats (for me) not as much of a problem.
I've debugged the code with visual studio and got to the point where I moved trough it via procedure steps (so for every new call I needed to press it manually). For the timing I grabbed my phone and stopped the watch for the time I've started the method and when it arrived at the next call.
Thats the way I calculated (debugged) that the lines:
134: var @base = await Operations.Receive(...) takes around ~4min
146: var go = rc.ConvertRecursivelyToNative(@base, commitId); takes around ~30 seconds (sometimes its longer, but no longer than one minute)
for a model with ~10k objects in both Unity 2020 and Unity 2021.
Is that a wrong way to calculate it? Did I make an mistake? Or is Operations.Receive already doing a conversion in the background?

To answer your question: We are currently visualising a model to walk through it like in a vr application but in a cave. Later on there will be also the need to select objects and look at the speckle properties, so removing those properties is not a solution.

@haitheredavid Hi there,
i've just retested it, the operation now took 250 seconds with stopwatch for just the receiving part of speckle. I dont know why its so slow. Also interestingly I cannot even load the model in speckle.xyz. Its just loading forever. The model comes out of revit, its ~10k mep objects.
Code used to benchmark:
133: var transport = new ServerTransport(Client.Account, StreamId);
134: System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
135: Debug.Log("Starting stopwatch Operations.Receive().");
136: sw.Start();
137: var @base = await Operations.Receive(           objectId,           remoteTransport: transport,           onErrorAction: OnErrorAction,           onProgressAction: OnProgressAction,           onTotalChildrenCountKnown: OnTotalChildrenCountKnown,           disposeTransports: true         );
145: sw.Stop();
146: Debug.Log($"Stopped stopwatch Operations.Receive(). Stopwatch took {sw.Elapsed.TotalSeconds} seconds.");
The properties are there, after the stopwatch finished it just took seconds before the model was shown in unity. I dont think its a problem with the unity converter rather than the communication in the DLL between Unity and Speckle. Maybe its because its mono underneath and not native .net?

As you see the models are relatively detailed and its the basic properties of mep objects, nothing fancy.
As of the performance things we already knew that, thats why our customer machine is very beefy:

gpu 2x RTX 3090
cpu 5950x
32 gb ram
ssd

Im sure it should be able to handle even more objects than ~10k as they are all static, but correct me if im wrong.
Im looking forward to the DOTS support, I always wanted to try it :)

Hi, are there any news up on this issue? Our problem still exisits within unity.

Hi, are there any news up on this issue? Our problem still exisits within unity.

Hi @LukasKlepper,
If you have time, please could you try the latest version of the Unity Connector.
I've made several improvements to the editor time receiving process that should have some noticeable speed-ups on receive performance.

For now, just the editor Speckle Receiver component has these improvements.
In a future update, I would like to consolidate these components with the runtime receiving components used in the Playground sample project.

When you get the chance, I'd greatly appreciate any feedback.
If you still think we need to improve performance, I can re-open this issue in our sharp SDK repo.

authors: JR-Morgan LukasKlepper haitheredavid

repo: specklesystems/speckle-unity


text:
Fix exception formatting for generic methods

The generic parameters were double escaped and would display as [[T0,T1,TRet]] instead of [T0,T1,TRet]. This is because the builder.AppendWithStyle method already escapes its value so the caller must not escape the passed value.

@0xced looks reasonable. I have not done any testing of this currently, but I think I will get to it tomorrow. Would you mind opening an issue, so we can track this "correctly"?

Would you mind opening an issue, so we can track this "correctly"?

Done in #641

@0xced your changes have been merged, thanks for your contribution :+1:


text:
Some improvements to the documentation

What does this PR do?
This PR aims to make some minor fixes and improvements to the documentation. The set of changes is better described by checking the commit history for this PR.

Before submitting

[x] Did you read the contributor guideline?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[x] Did you verify new and existing tests pass locally with your changes?
[x] Did you list all the breaking changes introduced by this pull request?
[x] Does your code adhere to project-specific code style and conventions?

PR review

Reviewer checklist

[x] Is this pull request ready for review? (if not, please submit in draft mode)
[x] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[x] Add labels and milestones (and optionally projects) to the PR so it can be classified
[x] Confirm that the changes adhere to compatibility requirements (e.g., Python version, platform)
[x] Review the self-review checklist to ensure the code is ready for review

Thank you @asumagic!

authors: asumagic mravanelli

repo: speechbrain/speechbrain


text:
🛑 Proxmox2 is down

In 391174b, Proxmox2 (pve2.speednight.tk) was down:

HTTP code: 0
Response time: 0 ms

Error present due to maintenance work (Router removed)

issue resolved after reinstalling ISP router


text:
Update scalatest to 3.2.15

Updates org.scalatest:scalatest from 3.2.13 to 3.2.15.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalatest", artifactId = "scalatest" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scalatest", artifactId = "scalatest" }
}]

labels: test-library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #71.

repo: spekka/spekka


text:
Move extracting/packing into subprocess to avoid locking up UI

Despite the extraction and packing process happening in its own thread it still freezes the UI because of the GIL. Moving this to a subprocess would allow the UI to remain responsive.

This has been completed for a while


text:
Repo-cleanup

General repo cleanup

removed unused deps
moved source code into src directory
other things of that nature (see commits)

@FaBjE @gameguy682 If one of you guys could take a gander and give this a quick approval i'd like to try and release a new patch version of the extension today.
Production branch was in a pretty rough state and this PR should address that (besides my code ;))

@gameguy682

repo: spencerwmiles/vscode-task-buttons


text:
debug

Enhancement:
Reason:
Result:
Issue Tracker Tickets (Jira or BZ if any):

[test]

repo: spetrosi/network


text:
add annotation to Collections so that type of collection content is in IDE autocomplete

foreach ($collection as $item)
$item->  Bäääh, no IDE autocomplete.

@ct-jensschulze  nice for many, but it didn't fix the issue we were talking about yesterday (iterating over a PagedSearchResponse  -> item should be a ProductProjection).     But I have the impression that I'm doing something wrong. Let's look over my code again.

repo: sphereio/sphere-php-sdk