text:
Live Exercise Export bug

Describe the bug
When 2 or more exercises are selected on the Live Exercises page - image 1 - and the Export Data button clicked, the report features an extra column - see image 2 - columns K and L are duplicates, and the data ends in column AD rather than AC. Furthermore, if 3 exercises are selected, an additional duplicate column is created, with 4 exercises another one, and so on. This is causing lots of issues putting together data for our monthly Rolling Diversity Report, and other purposes.
To Reproduce
Steps to reproduce the behavior:

Go to Live Exercises
Select multiple exercises, e.g. 130 and 131, and Click 'Export data'
Open the download and note that columns K and L are duplicates
Repeat with 3 exercises if desired

Expected behavior
Irrespective of how exercises are selected, the exported spreadsheet should only contain a single column for 'Attended state or fee-paying school'. Please share with Sean for UT once fixed.
Screenshots
Image 1
Private Zenhub Image
Image 2
Private Zenhub Image

Note that if exercises are selected from before and after the social mobility questions changed on 01/04/2023 then the download will contain extra columns. We'll need columns for both sets of questions.
In this case I propose we prepend "[pre 01/04/2023] " (or similar [TBC]) to the three older questions as one or two of them had similar titles to the new questions.

@HalcyonJAC Hi Ryan, I know this is live now, but it should still be code reviewed - can you request approval from other Devs, pls?

authors: nickaddy warrensearle

repo: jac-uk/admin


text:
Missing fields when using -a with bedtobigbed

Hello,
I have found a discrepancy in the number of fields and some other metadata when using bigtools vs ucsc and it is having an impact on how things appear in the browser.
Basically, when I test with bigbedinfo I see differences in field number and other metadata columns (the correct number of fields is 17):
# bigtools
version: 4
fieldCount: 3
isCompressed: yes
isSwapped: 0
itemCount: 1100122467552
primaryDataSize: 367,623,108
primaryIndexSize: 20,200
zoomLevels: 6
chromCount: 2
basesCovered: 97,494,196
meanDepth: 44.449296
minDepth: 1.000000
maxDepth: 3195.000000
std of depth: 69.740202
version: 4

# UCSC
fieldCount: 17
isCompressed: yes
isSwapped: 0
itemCount: 1100122467552
primaryDataSize: 386,514,961
primaryIndexSize: 46,952
zoomLevels: 8
chromCount: 2
basesCovered: 101,269,035
meanDepth: 82.861921
minDepth: 1.000000
maxDepth: 4056.000000
std of depth: 96.352168

I have uploaded all the data in my test to:
https://s3-us-west-2.amazonaws.com/stergachis-public1/index.html?prefix=Mitchell/temp/bigtools-test/
And here is the script I am running:
zcat my.bed.gz | bigtools bedtobigbed -a decoration.as -s start - hg38.fai bigtools.bb
bedToBigBed -as=decoration.as -type=bed12+ my.bed.gz hg38.fai ucsc.bb

bigbedinfo bigtools.bb
bigbedinfo ucsc.bb

Any help with an obvious error on my part would be great!
Cheers,
Mitchell

working on this, should have a solution soon

Sorry to be a bother but have you had a chance to look at this?

Sorry for the delay - just published bigtools 0.5.1 which should fix the fieldCount and definedFieldCount when an autosql is passed.

Awesome, it's working for me. I'll approve the bioconda PR once it passes tests :)

Hi @jackh726,
Found an issue with the new release that I think is requiring the autosql argument to be passed everytime.
I have a standard three column bedfile and when I try:
zcat results/ONT_heuristic/coverage/unreliable-coverage-regions.bed.gz | bigtools bedtobigbed -s start  - ~/assemblies/hg38.analysisSet.fa.fai tmp.bb

I get
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

But if I add the SQL argument, it works:
zcat results/ONT_heuristic/coverage/unreliable-coverage-regions.bed.gz | bigtools bedtobigbed -s start -a tmp.as - ~/assemblies/hg38.analysisSet.fa.fai tmp.bb

And here tmp.as is just the three-column definition:
table bed3 "bed3"
(
string  chrom;  "Reference sequence chromosome or scaffold"
uint    chromStart; "Start position in chromosome"
uint    chromEnd;   "End position in chromosome"
)

I am also noticing that I have to filter out lines starting with the BED comment character (#), whereas I don't think I needed to before, but I am not sure about that.
For now, I can add the as files for all my commands, but I wanted to let you know.
Cheers,
Mitchell

v0.5.2 should at least not error when not passing an autosql (this only happened when passing the bed via stdin)
I still need to add the following:

autosql parsing when using stdin
Filtering of commented lines

I have not had time to put together a test case to share yet, but now it seems to me that the --autosql argument is ignored when using stdin with 0.5.2 whereas it worked with 0.5.1. But I am realizing maybe that is what you meant with:

autosql parsing when using stdin

?

Ah no, that should work but I made a mistake. Will update with fix either later today or tomorrow.

Great thank you!
Sorry for all the questions/comments, but I think I am also noticing that setting the zoom level on the command line is not respected when I check after the file is created with bigbedinfo.

No worries - the testing is helpful. I'll take a look at that too

Awesome thanks!
I was playing with the zoom level because I thought it might fix an issue I am seeing where some data will disappear as I zoom in when using decorator tracks.
e.g.

to

Ah that's weird, if you can get a reproduction, I can look into it.

Thanks, I made a test case here that reproduces the issue in this region of hg38 chrX:47191183-47195924, and uploaded it here:
https://s3-us-west-2.amazonaws.com/stergachis-public1/index.html?prefix=Mitchell/tests/bigtools-test/
And within that dir is a "hub.txt" that you can load on UCSC to see the issue:

When making the small test case, I did find that depending on the size of the dataset, I sometimes would or wouldn't see the issue pop up. This was the smallest file I could get where the issue appeared.

Just wondering if you got a chance to look at this? Thanks in advance!

Sorry, this fell off my radar. I'm looking at this now - will let you know.

So, I ran out of time looking at this for now, but here are my general thoughts:
It doesn't seem like this is an issue with the data that is written. I.e. it doesn't look like there's a bug that is causing some data to not be written to the final bigBed.
Rather, I think this is more likely a quark fundamentally attributed to zooms. My hunch is that because you're writing the bigBed from stdin, the heuristics for calculating/including zoom levels just has a poor interaction here. And really, I think it all comes down to the decoration bigBed. I think likely the calculated zoom sizes are just too big.
The easiest check here is just write the declaration bigBed with nzooms=0, which should force the genome browser to use the primary data. I have wanted to add an option to be a little bit more explicit about what zooms to write, so this might be the push to do that. I expect you would then want to manually set the initial zoom to be small.

I'll try to get back to this maybe later today or this week and test out my theory about writing the decoration bigBed with no zooms (if you don't get to it).

To help out a little I just tested creating from stdin and from a pre-made bed file, and both with a variety of zoom levels (including 0), and unfortunately none of the combinations made these items visible on UCSC.
I extended the script and trackhub so that it also contains a ucsc test just to confirm that it works with the OG tooling:

So I don't think it is something I can fix by forcing the zoom level.
(reminder: I am using bigtools 0.5.1 since 0.5.2 since the --autosql argument seems to be ignored in this case with 0.5.2).

Thanks, this is helpful. I'll keep looking into it, but I'm really not sure!

Just being a squeaky wheel. Thanks in advance!

Sorry! Gotten back to this a bit. Still looking, but it's definitely a zoom-related issue with the decoration track.
Using the ucsc read bigBed with the bigtools decoration bigBed results in the same pattern that you see above (no zooms). Manually specifying 4 zooms (haven't yet added the ability to specify zoom sizes, so the default sizes are 40,160,640,2560) actually results in no decorated items showing. Next step here is for me to manually specify the zooms and see if that fixes it.
As a side point, I'm noting that the basesCovered summary item (and the others) are not the same across ucsc and bigtools, which is probably unrelated, but interesting. itemCount is the same (and calling bigBedToBed on both results in the same output).

Just making a note that I am still interested in this.
I'd very much like to move this into our production pipeline since it is a fantastic speed up.
Thanks again for the tool!

Gah! Sorry! I keep forgetting to get back to this... really sorry about the slow progress here.

So, have been investigating this a bit further. And, well, I'm perplexed.
To recap: previously, making a hub with the ucsc data file and bigtools decoration file did not work, but ucsc decoration file and bigtools data file did work.
I added the functionality to manually specify zooms (instead of bigtools calculating them, which is a bit different than ucsc), tried that and it didn't work. So, these none of 0 zooms, 4 zooms (different), or 4 matched zooms work.

As a side point, I'm noting that the basesCovered summary item (and the others) are not the same across ucsc and bigtools, which is probably unrelated, but interesting. itemCount is the same (and calling bigBedToBed on both results in the same output).

I then looked into this, in case it's related. Which ended up being it's own rabbit hole. Essentially, rather than focusing on basesCovered, I looked at maxDepth. I made a smaller file (dec.cut1-3.maxdebug.bed.txt) that differed between ucsc and bigtools (ucsc says maxDepth as 200, bigtools says 185). I did a separate pileup with bedtools (bedtools genomecov -bg -g hg38.fai -i dec.cut1-3.maxdebug.bed > dec.cut1-3.maxdebug.pileup.bed) and that shows the max depth as 185...so it seems like a probably bug in the ucsc bedToBigBed, or I'm just missing something.
Along the way, I tried making a bigBed with a single zoom of 1 bp, and realized there was a bug in bigtools (essentially, when there are overlapping regions, I was not counting past the first region). I fixed this, but it still doesn't fix the decoration problem (which, is not that surprising given that no zooms also doesn't work).
So...still working on it.
(I have a testing branch here with ongoing fixes: https://github.com/jackh726/bigtools/tree/dec-testing2)

Okay next weird thing - subsetting the input bed file where the fourth column == "m6A" seems to result in identical outputs...

Thanks for starting to investigate!
I will say the second thing doesn't surprise me that much. For example, depending on the size of the region I was making for the test case different fibers in different regions disappeared.
Would it be helpful to ask UCSC anything? I know a person or two on the browser team.

Yeah, at this point its probably worth asking the ucsc folks.
I've tried "minimizing" the decoration file in different ways prior to running it through bigtools (subsetting to only m6A, removing FIRE lines, only including regions overlapping the target window) and each time i can't reproduce the problem in the genome browser. Subsetting the data file to one entry that is missing the decorations and one that isn't does reproduce the problem though.
I might have some time to poke at this a bit more today. I'm really just perplexed because it doesn't seem like a file format issue (given that just subsetting the initial bed file has yet to reproduce the issue) and some of the decorations are correct even in the reproduction...

I reached out the to creator of the decorator tracks and linked the issue and asked for any advise he might have. I do know he's has since started working on his masters degree so not sure he'll have time to look.
Did I understand you correctly in that you were able to get a single read version that recreates the issue? If so I'd add it to the track hub if you could share the file.

I did have one idea. There is an option in ucsc bedtobigbed that allows a 1bp overlap between blocks in bed12 files which is something I take advantage of with the m6a track specifically. Is that something that might hit some corner case in bigtools?

My test hub is here: https://users.abdenlab.org/hueyj/bigtools-test/hub.txt
re. 1bp overlap (https://github.com/jackh726/bigtools/issues/49?) I think that makes no difference - ucsc does some checks that needs that flag, and bigtools doesn't do those

For my hub (as it is right now, might be down - we're having server troubles):

the "bigtools-test" track is only two regions in the "read" bed file, one missing decorations in the repro, one fine
the "bigtools-test-sub" track is the same as the above, but the decoration bed file was subsetted to only include entries matching the above two regions
can ignore the "bigtools-test-4zooms" and "bigtools-test-matchedzooms" tracks
the "ucsc-test" track is the same two regions in the "read" bed file, with the full decoration bed file passed through ucsc bedToBigBed
the "bigtools-test-matchedzooms-m6A" and "ucsc-test-m6A" tracks are like "bigtools-test" and "ucsc-test", but the decoration files are filtered to only have '$4 == "m6A"'

Btw, I just published version 0.5.3, which should fix https://github.com/jackh726/bigtools/issues/48#issuecomment-2258917404 and a few other things I found when testing this. It doesn't fix the main issue though, which I unfortunately still haven't found the cause of.

Great, I will update to that version for the other fixes!
One more corner case I have thought of for this data. These bed12 files do sometimes have a zero-length "block/exon". Do you think that could be causing an issue in bigtools?

Nevermind, on the zero length. That is not something I am doing here, got confused with another tool I am working on

Went ahead and renamed the issue to reflect the current state of things - figured there's enough background that even it's better to just keep it here than split it out (even though the original issue is solved)

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
hello_triangle.nim does't compile due to incorrect Use / UseProgram procedure name

I tried to compile the hello_triangle.nim example but I couldn't compile it due to this line.
The UseProgram wrapper procedure is actually just called Use (see here)
I would rename Use to be UseProgram but you could also change the procedure in hello_triangle.nim to be Use. I didn't a pull request because I'm not sure which you would prefer.

Thanks, I probably changed the easygl wrapper and forget to go update hello_triangle, I'll fix it up tonight.

fixed

@jackmott Not sure if I mentioned this to you already, but it would be great if you followed the Nim code conventions. i.e. don't name your templates/procs with a capital letter at the start.

Ok I can fix that, but just noticed that nimble can no longer build because glm now requires nim 17.3 which I do not have, and I can't figure out how to request an older version.
requires "glm 0.2.0" doesn't seem to work.

You can try requires "glm#<commit_hash>" where commit_hash is the git commit hash of the version you want.

that did it!
now to see if vs code's nim plugin has rename symbol

@dom96 what is the best way to be able to compile all of the src files in the examples subdir at once? is there a way to set that up in the nimble file?

not currently. I mean you can write a task that does it, but Nimble doesn't have any default functionality for that.

allright, lowerecased it.

authors: Samulus dom96 jackmott

repo: jackmott/easygl

license: mit

license_source: bigquery


text:
Enable multiple comments per word

As per #7 the existing loadCommentaryData() function only loads one comment.

4c8ca6524d3c14ec05b76bf2c8db8a5a5c914ed9 allows basic functionality.
Now I would like to make sure that several comments look sensible on the card.
There should also be some limit to how large the card is allowed to be.


text:
Refresh command isn't working.

Refresh isn't working, isn't showing up on UI.

Started to fix the problem. Affiliation refresh should work. Tests should be run.

repo: jacksonporter/RaceRegWPF


text:
add canvas render support

Features

[x] Render graph
[x] Drag and zoom
[x] Click on node to navigate
[x] Hover on node to focus
[x] Maintain the current display effect
[ ] Customizable settings for force graph

[x] Repel force
[x] Center force
[x] Link distance
[ ] Font size
[ ] Opacity scale
[x] Max scale size

[ ] Customizable settings for interaction

[ ] Drag
[ ] Zoom

#1144

I have completed all the modifications. There are some configurations that I don't understand what they do, so I didn't implement them.

Font size
Opacity scale

Regarding the "Customizable settings for interaction" part, I currently think it's not really necessary to open up the API. If someone has the capability to make modifications, they should be allowed to modify the original code themselves.

while there are a lot of things to be fixed on this PR, I would suggest to just use canvas as default, and drop svg support to make the codepath simple.

Will track from #1328

source: gharchive/pull-request

authors: aarnphm iceprosurface


text:
Unfurl Links

Use OEmbed tags to unfurl links on hover

Closing because of CORS :(


text:
How to send 'cacheDirectory' to CQuery, non Editor application

Hi,
I want to use CQuery to find e.g. C/C++ symbols to use them for UML-modelling.  I thought it should be doable with CQuery/Language Server. I don't want to use it in the context of an Editor. I only want to use some services of CQuery.
I've tinkered a little around. Then I got stuck by the configuration of the server with e.g.  cacheDirectory.  Is there a specification what and how this information is to be sent to the server.
Maybe I've to send the information according to language_server_api.h
I haven't found anything in the Language Server Protocol specification.
Thanks for every help or advice,
Helmut

cquery pulls grabs cacheDirectory from the LSP initialize method. It's a non-standard configuration, so it ends up getting stashed down in initializeOptions like so:
{
"processId": null,
"rootUri": "file:///home/josh/Repos/cquery",
"initializationOptions": {
  "cacheDirectory": "file:///home/josh/.cache/cquery"
},
"capabilities": []
}

Thanks a lot for the quick answer!!!! Looks good, I'll give it a try.
Helmut

It works, happy new year!

authors: Helmut-Ortmann jaelsasser

repo: jacobdufault/cquery


text:
Thread Safety

Hi,
Just wondering if FullSerializer is thread safe?
Im trying to do serialization/deserialization on threads on a project on Android and iOS but its not working for me on Android, whereas when i disable threading, it works perfectly.
There seems to be a few static dictionarys in places which means, even if i create 2 instances of the parser, it would not be thread safe, i guess?
Thanks.

Thanks, I've added some locking.
FS should be fully thread safe on a per-serializer level. So each thread needs to have it's own fsSerializer instance.

authors: jacobdufault pjohalloran

repo: jacobdufault/fullserializer


text:
SciLexer.dll. This file is within the project directory tree

How can I fix these in Visual Studio 2015?
Severity	Code	Description	Project	File	Line	Suppression State
Warning		The file '3rdparty\ScintillaNET\SciLexer.dll' could not be added to the project.  Cannot add a link to the file C:\Users\mona\playing-for-data\renderdoc\renderdocui\3rdparty\ScintillaNET\SciLexer.dll. This file is within the project directory tree.	renderdocui
Severity	Code	Description	Project	File	Line	Suppression State
Warning		The file '3rdparty\ScintillaNET\SciLexer64.dll' could not be added to the project.  Cannot add a link to the file C:\Users\mona\playing-for-data\renderdoc\renderdocui\3rdparty\ScintillaNET\SciLexer64.dll. This file is within the project directory tree.	renderdocui

Are you possibly using an old v2 of ScintillaNET?
Try our nuget packages or GitHub releases.
Once you have the correct DLL, you can use the documentation found in the wiki to get started.

authors: jacobslusser monajalal

repo: jacobslusser/ScintillaNET


text:
Code Folding (BUG)

Hello Guys,
How or where can i change the code folding. The problem is that the white line are also displayed inside a method when i intend them. Normaly only namespace/methods/regions need them. How can i remove the white lines inside methods?
(1)

(2) The next thing is how can i make this whit ScintillaNet, to highlight brackets:

(3) How can i change the current code folding from:

To:

Better said how can i change it, that the { is not anymore in a single line and will displayed like visual studio with ...?
(4) The BUG:

I use scintilla for c# but when i folded with TextArea.Lexer = Lexer.Cpp is shows like in point (3). When i still use C# as files and change it to TextArea.Lexer = Lexer.VbScript; the brackets seems to works?
Can someone make a tutorial how to make own lexer/custom folding.

https://github.com/jacobslusser/ScintillaNET/wiki/Automatic-Code-Folding
https://github.com/jacobslusser/ScintillaNET/wiki/Brace-Matching

authors: cRUSHER-HLG jacobslusser


text:
is there any way to display tightly connected nodes of graph closer to each other

I want to visualize the graph in such a way that tightly connected nodes displays close to each rather than having too many crossing edges in the graph. In another way, I want as less as possible crossing edges in my graph. Is there any way to do this in sigma js?

Have you tested the forceatlas2 layout ?

I am trying forceatlas2 layout but my nodes are not stable at their position but keep jumping in the final output.

thanks @sim51, now I have fixed this jumping issue.


text:
Overhaul indentation detection

Record level of indentation in indent tokens rather than number of characters of indentation
Support the first line of pipeless-text being indented (jadejs/jade#1588)
Fixed comments-in-case.jade to be a legitimate test case

This breaks compatibility since previously "valid" code like:
html
  body
   p Hello

is now regarded as invalid.

Ping. I really want someone to look at this before I merge it.

I do not feel confident that I fully understand this PR - but on the surface, it looks good.
Am I right in understanding that all children have to be indented by at least 2 spaces or 1 tab? I. e., 0 spaces -> sibling, 1 space -> invalid, 2+ spaces -> child?

Am I right in understanding that all children have to be indented by at least 2 spaces or 1 tab?

No, 1 space works as well.

Then what makes
html
  body
   p Hello

invalid? If I add another space before p it is valid again, right?

Yes. It catches inconsistent cases, not when it is consistently one space.

Do we have that information so that we could print that in the error message?
Something like "Inconsistent indentation, expect N spaces/tabs"?

The error message looks like this:
Error: Jade:3
    1| html
    2|   body
  > 3|    p Hello

Inconsistent indentation
    at makeError (/home/timothy_gu/jade-error/index.js:27:13)
    at Lexer.error (/home/timothy_gu/jade-lexer/index.js:59:15)
    at Lexer.indent (/home/timothy_gu/jade-lexer/index.js:925:14)
    at Lexer.advance (/home/timothy_gu/jade-lexer/index.js:1086:15)
    at Lexer.getTokens (/home/timothy_gu/jade-lexer/index.js:1102:12)
    at internalLex (/home/timothy_gu/jade-lexer/index.js:14:42)
    at lex (/home/timothy_gu/jade-lexer/index.js:10:10)
    at repl:1:13
    at REPLServer.defaultEval (repl.js:164:27)
    at bound (domain.js:250:14)

I guess I can add an "expected" but that would be a bit confusing as it would sound like "inconsistent indentation: got 3 spaces, expected multiples of 2 spaces"

In your case we could print "Inconsistent indentation, expected either 2 or 4 spaces".
Btw, are either of these valid?
html
  body
      p Hello

html
  body
      p Hello
    p World

"Inconsistent indentation, expected either 2 or 4 spaces".

0 spaces work too.

Btw, are either of these valid?

Good catch. They shouldn't be but they are accepted. A even more serious case is:
html
 body
     p Hello
   p World
 p from
p Timothy

which is interpreted as
html
 body
   p Hello
 p World
 p from
p Timothy

But this PR doesn't change the behavior, as the file was already broken.

Fair enough - but let's maybe think of adding this to some bug list somewhere ;)
Regarding the error message, I think an indentation of 3 clearly means you do not want 0, but either 2 or 4, i.e., the user added one space too little or too many.
In a world where the above cases are ruled out we could always print "Inconsistent indentation, expected either X or X+indent spaces", where X is Math.floor(number of spaces / indent) * indent. What do you think?
Also, what is the scope of this indent variable? File-wide? How does it interact with include's and extend's?

Also, what is the scope of this indent variable? File-wide?

Yes, this is the lexer.

Regarding the error message, I think an indentation of 3 clearly means you do not want 0, but either 2 or 4, i.e., the user added one space too little or too many.

I prefer not to guess what the user's intentions are.

How does it interact with include's and extend's?

It doesn't.
How about these:
Error: Jade:3
    1| html
    2|   body
  > 3|    p Hey

Inconsistent indentation. Expected multiples of 2 spaces/tabs, got 3 spaces/tabs.

Error: Jade:4
    1| html
    2|   body
  > 3|       p Hey

Inconsistent indentation. Expected 4 spaces/tabs, got 6 spaces/tabs.

Error: Jade:4
    2|   body
    3|     p.
  > 4|      a

Inconsistent indentation. Expected multiples of 2 spaces/tabs, got 5 spaces/tabs.

Like it a lot. From my code reading and the tests (old and new) it seems good, but maybe someone with better knowledge of the rest of the code wants to take a look as to how it was implemented?

I just finished #16, which achieves the same goals but without the indentation overhaul. The fact that #16 preserves compatibility is something to consider.

Closing in favor of #16.

authors: TimothyGu alubbe

repo: jadejs/jade-lexer


text:
[Bug]: Documentation version early release than operator

What happened?
Jaeger latest version documentation not correctly work for newcomer, because it has been release 1.50, but operator not release yet.
https://www.jaegertracing.io/docs/1.50/operator/#installing-the-operator-on-kubernetes
Steps to reproduce

open: https://www.jaegertracing.io/docs/1.50/operator/#installing-the-operator-on-kubernetes
follow the step to install jaeger operator
A 404 error occurred on the kubernetes CLI.

Expected behavior
why documentation has been released 1.50 and jaeger operator not?
Relevant log output
No response
Screenshot
No response
Additional context
No response
Jaeger backend version
No response
SDK
No response
Pipeline
No response
Stogage backend
No response
Operating system
No response
Deployment model
No response
Deployment configs
No response

This should be fixed as part of the doc repository: https://github.com/jaegertracing/documentation/issues/580

This should be fixed as part of the doc repository: jaegertracing/documentation#580这应该作为文档存储库的一部分进行修复：jaegertracing/documentation#580

Didn't notice that, Thanks.

authors: Roiocam iblancasa

repo: jaegertracing/jaeger-operator


text:
Add the ability to use the gRPC storage plugin with a remote endpoint

Requirement - what kind of business use case are you trying to solve?
Ability to have the gRPC storage API be implemented on a remote endpoint (not only locally over a socket).
I'm happy to submit a PR if the community is open to this.
Problem - what in Jaeger blocks you from solving the requirement?
Right now the gRPC storage plugin can only be used via the go-hashicorp plugin (over a socket). I'd like to expose the storage API on another machine, so having a way for the gRPC plugin to use a regular gRPC client instead would be much easier and also more efficient.
In the short term I've solved this with a gRPC plugin that simply proxies the request to a gRPC client with a remote endpoint so the communication is
jaeger --(go-hashicorp-plugin)-->jaeger-query-proxy--(gRPC)--> grpc Endpoint implementing the storage API.
But the jaeger-query-proxy implements the same exact API as the grpc Endpoint implementing the storage API. so it would be much more efficient to just have
jaeger --(gRPC)--> grpc Endpoint implementing the storage API.
Proposal - what do you suggest to solve the problem or improve the existing situation?
I think there would need to be some additional configuration options added to the grpc plugin (here):

TLS                bool          yaml:"tls"
CaFile             string        yaml:"cafile,omitempty"
ServerAddr         string        yaml:"grpc-server"
ServerHostOverride string        yaml:"grpc-server-host-override,omitempty"
ConnectTimeout     time.Duration yaml:"connection-timeout,omitempty"

And then in the plugin Build function we'd need to initialize a regular gRPC client if using a remote connection (instead of plugin.NewClient from the hashicorp plugin).
Of course the existing hashicorp way would still work and not be effected.
I don't think this would be a big change and again I'd be happy to submit a PR.
Any open questions to address
I think in the choice between the plugin or the remote client would be done depending on whether the PluginBinary configuration option is an empty string or not.
I'm hoping that the hashicorp client and the gRPC client would provide an equivalent interface but I'd have to see during implementation.

Yes, that would be awesome, we talked about it many times, because one thing this would allow us to do is to use in-memory storage as a remote storage, which would allow different deployments of collector/query instead of all-in-one.

I second that, this would be great! I think this would help with addressing #1221, which in turn addresses the recent flaky cross-dock CI jobs due to slow ES startup.

Duplicate of #1519

authors: albertteoh cevian yurishkuro

repo: jaegertracing/jaeger


text:
Exception while invoking method '/Astronomy/insert' TypeError: undefined is not a function

I cannot find any related issues on this so I'm posting this here
I've created a collection with
import { Mongo } from 'meteor/mongo';
import { Class } from 'meteor/jagi:astronomy';

export const Blocks = new Mongo.Collection('blocks');
export const Block = Class.create({
  name: 'Block',
  collection: Blocks,
  behaviors: {
    timestamp: {}
  },
  secured: {
    insert: false,
    update: false
  }
});

then trying to save something with

import { Blocks } from '../../api/blocks.js';
import { Block } from '../../api/blocks.js';

let block = new Block();
block.block_id = "about";
block.content = 'Lorem ipsum';
try {
  block.save();
} catch(er) {
  console.error(er);
}

I get and error Exception while invoking method '/Astronomy/insert' TypeError: undefined is not a function
whole error stack is
I20160720-15:06:09.601(2)? Exception while invoking method '/Astronomy/insert' TypeError: undefined is not a function
I20160720-15:06:09.693(2)?     at classInsert (packages/jagi:astronomy/lib/modules/storage/utils/class_insert.js:22:15)
I20160720-15:06:09.693(2)?     at [object Object].insert (packages/jagi:astronomy/lib/modules/storage/meteor_methods/insert.js:4:10)
I20160720-15:06:09.694(2)?     at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1711:12)
I20160720-15:06:09.694(2)?     at packages/ddp-server/livedata_server.js:711:19
I20160720-15:06:09.694(2)?     at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
I20160720-15:06:09.694(2)?     at packages/ddp-server/livedata_server.js:709:40
I20160720-15:06:09.694(2)?     at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
I20160720-15:06:09.695(2)?     at packages/ddp-server/livedata_server.js:707:46

similar code works for other collections.

Where are you executing this code? In a meteor method? The problem is that Astronomy can't find a class. You may be missing some import.

I'll try to explain this
In client/main.js I have import '/imports/startup/client';
where I have iron router setup
import '../../ui/pages/blocks';
Router.map(function () {
//....
this.route('blocks');
//....
});

in ui/pages/blocks i have
import './blocks.html';

import { Block } from '../../api/blocks.js';

Template.Blocks.events({
  'submit .about-text'(event) {
    event.preventDefault();

    let block = new Block();
    block.block_id = "about";
    block.content = 'Lorem ipsum';
    block.save();

  },
});

and blocks.html is just
<template name="Blocks">
  <form class="about-text">
    <textarea class="wysiwyg" name="about_block" id="about_block"></textarea>
    <button>Save</button>
  </form>
</template>

api/blocks.js
import { Mongo } from 'meteor/mongo';
import { Class } from 'meteor/jagi:astronomy';

export const Blocks = new Mongo.Collection('blocks');
export const Block = Class.create({
  name: 'Block',
  collection: Blocks,
  behaviors: {
    timestamp: {}
  },
  secured: {
    insert: false,
    update: false
  }
});

clicking on <button>Save</button> reproduces that error.
I've made a test in client.js and pasting just this code throws me same error
import { Mongo } from 'meteor/mongo';
import { Class } from 'meteor/jagi:astronomy';

export const Blocks = new Mongo.Collection('blocks');
export const Block = Class.create({
  name: 'Block',
  collection: Blocks,
  behaviors: {
    timestamp: {}
  },
  secured: {
    insert: false,
    update: false
  }
});

let block = new Block();
block.content = 'Lorem Ipsum'
block.save();

Seems like import was missing for that api in server/main.js

authors: jagi qunabu

repo: jagi/meteor-astronomy


text:
Upgrade to Elm 0.18

Just ran elm-upgrade (https://www.npmjs.com/package/elm-upgrade) on a project where I'm using elm-graphql-module, and got an message that elm-graphql-module is not upgraded to elm 0.18. So here is the result of running elm-upgrade on elm-graphql-module 😄

Thanks for your work on helping this upgrade. I looked into this project. It heavily relies on an abandoned lib elm-http by Evan Czaplicki. So extra rewriting is needed for sure.

@jahewson, can this please get merged?

@liamcurry This only update the elm-package file. Check out my fork which really works on 0.18  here

authors: jackalcooper liamcurry valberg

repo: jahewson/elm-graphql-module


text:
Add position parameter to sound effects

This would be primarily used for sound positioning to make sounds more pleasant.

Implemented, however single sounds may still not support the 3D sound. This has a low priority, though.
https://github.com/jakubg1/OpenSMCE/commit/210eb519aa73d0d2ab35fbb29082aca1d17694d5 and https://github.com/jakubg1/OpenSMCE/commit/fe7e82f5344fe3d648a6cfedc9de7c319391eaca.


text:
HTML Entities converted during parsing, but not restored during serializing

In XMLUtil the VALID_ENTITY_NAMES allows for entities to be converted to their values during parsing. However they are not converted back during serialization.
For example, having a resource with a text>div tag like so

§

and running it through the xml parser
IParser parser = fhirContext.newXmlParser();
IResource res = parser.parseResource(...);
String output = parser.encodeResourceToString(res);

Results in the following text instead of the input text.

§

Is this expected? I expected it to return the same value as the input, since this effectively changes the value.
Note: This is on HAPI-FHIR 0.7. Apologies if this is no longer applicable, but having a brief look at the code it seems to be.

I think the easiest solution to this problem is to either test if the namespace is xhtml, or for that specific element, and use a different StringEscapeUtils escape method (maybe escapeHtml4).

Hi Nick,
This behaviour is sort of by design. Entities such as § are valid in HTML/XHTML but not in XML by default, and since a FHIR document is not an XHTML document (even if it contains parts that are) it is not valid to use entities outside of what's allowable in XML
We had some complaints about HTML that was parsed in containing § entities failing to validate with XML validators when the entites were preserved so we coded it to unescape these. Given that FHIR requires the use of UTF-8, this seemed like a safe thing to do.
Is this causing issues on your end? I'm definitely not against changing this behaviour if you have specific issues it's causing, although I don't know what the right behaviour would be..

It isn't causing issues at the moment, but we can see how it would if someone had those tags in their html values. Since it is an edge case it won't have any noticeable benefit to us if it is fixed.
With regards to your answer, would this be invalid in XML? Should that div tag inside the xml actually be

&sect;

That probably makes more sense, and then should be resolved in this case. Now that I am revisiting this it seems like if what you are saying is accurate than the xml document itself is invalid.

I believe the existing functionality is correct. Since this is an error commonly made by implementers, it's useful for HAPI to read html entities, but it should not produce them

Reopening this issue as this fails in one of our examples.
A bit of info of our usage: we are leveraging HAPI-FHIR to convert from XML->JSON and JSON->XML.
Looking through the examples for DSTU1 there is the v3-codesystems. In the examples it has the entity '™' in the JSON and in the symbol '™' in the XML. However using the HAPI-FHIR library this element is dropped as it does not exist in the mapping table.

Hi Nick,
Thanks for the info. It does look like we're missing some entities, including &trade.
I'm completely unable to reproduce what you're seeing though. How are you doing the parsing? For reference I came up with the following unit test, but it fails on the parse step with an exception about there being an unknown entity (which is what I'd expect).
	@Test
	public void testParseTextWithUnknownEntity() {
		String msg = "<Patient xmlns=\"http://hl7.org/fhir\"><text><status value=\"generated\"/>"
				+ "
Trade ™
</text></Patient>";
		Patient pt = ourCtx.newXmlParser().parseResource(Patient.class, msg);

		ourLog.info(pt.getText().getDiv().getValueAsString());
		assertThat(pt.getText().getDiv().getValueAsString(), containsString("Trade ™"));

		String enc = ourCtx.newXmlParser().encodeResourceToString(pt);
		ourLog.info(enc);
		assertThat(enc, containsString("Trade ™"));

	}

Hey James,
Our test has it being parsed from JSON, then being encoded into XML.
So the input would be something like
"{\"resourceType\":\"Supply\",\"text\":{\"status\":\"generated\",\"div\":\"
™
\"}}"

And using the JSON parser. This then throws the exception (but this is valid, as v3-codesystems.json has this). This then shouldn't throw the exception and this should be added to the list of entities.
I think it was dropped due to some minor modifications we made to the library to get around this problem, so ignore that. Reverting to the vanilla library it throws the exception which is what you said.

actually, just because v3-codesystems.json has it doesn't make it valid.
And I don't think it is; it's an html entity, not valid in xhtml.
On Fri, Jun 5, 2015 at 7:58 AM, Nick Kitto notifications@github.com wrote:

Hey James,
Our test has it being parsed from JSON, then being encoded into XML.
So the input would be something like
"{"resourceType":"Supply","text":{"status":"generated","div":"
™
\"}}"
And using the JSON parser. This then throws the exception (but this is
valid, as v3-codesystems.json has this). This then shouldn't throw the
exception and this should be added to the list of entities.
I think it was dropped due to some minor modifications we made to the
library to get around this problem, so ignore that. Reverting to the
vanilla library it throws the exception which is what you said.
—
Reply to this email directly or view it on GitHub
https://github.com/jamesagnew/hapi-fhir/issues/175#issuecomment-109068094
.

--
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065

Perfect, I'll add an update list of entities to convert.

authors: grahamegrieve jamesagnew nickkitto

repo: jamesagnew/hapi-fhir


text:
Matching Content-Type when it contains multiple values

Given the following expectation:
  {
  "httpRequest" : {
    "method" : "PUT",
    "path" : "/documents/doc-id",
    "headers" : [ {
      "name" : "Content-Type",
      "values" : [ "application/x.audacity+txt", "application/x.tsv" ]
    } ]
  },
  "times" : {
    "remainingTimes" : 0,
    "unlimited" : true
  },
  "timeToLive" : {
    "unlimited" : true
  },
  "httpResponse" : {
    "statusCode" : 201,
    "headers" : [ {
      "name" : "Content-Type",
      "values" : [ "application/json" ]
    } ],
    "body" : "{\n  \"artifactId\" : \"doc-id\",\n  \"artifactMd5Hex\" : \"doc-hex\"\n}"
  }
}

I get the following response:
  {
  "method" : "PUT",
  "path" : "/documents/doc-id",
  "headers" : [ {
    "name" : "Content-Type",
    "values" : [ "application/x.audacity+txt" ]
  }, {
    "name" : "Content-Length",
    "values" : [ "15" ]
  }, {
    "name" : "Host",
    "values" : [ "localhost:34364" ]
  }, {
    "name" : "Connection",
    "values" : [ "Keep-Alive" ]
  }, {
    "name" : "User-Agent",
    "values" : [ "test" ]
  } ],
  "keepAlive" : true,
  "secure" : false,
  "body" : {
    "type" : "BINARY",
    "value" : "U29tZSBhdWRpbyBkYXRh"
  }
}

did not match expectation:
{
  "method" : "PUT",
  "path" : "/documents/doc-id",
  "headers" : [ {
    "name" : "Content-Type",
    "values" : [ "application/x.audacity+txt", "application/x.tsv" ]
  } ]
}

because:
method matches = true
path matches = true
query string parameters match = true
body matches = true
headers match = false
cookies match = true
keep-alive matches = true
ssl matches = true

This seems wrong to me.  Is it not the case that multiple values in the expectation of Content-Type (effectively Accept for the server) should be treated as a logical OR?  I'm expecting either  "application/x.audacity+txt" or  "application/x.tsv" to work.

The problem is that it is not possible for MockServer to know if you want an OR or an AND.  In addition there is no specific logic to handle Content-Type separate from any other type of header for matching.
There are two ways to get what you need with the existing MockServer logic:

Define a separate expectation for each different value of the Content-Type header.
Use a regex header value that matches both types of header value.

Thanks for your reply. I'm struggling to imagine a use case where one would want the accept header to act like an AND...but I'm willing to believe that that might be in the http spec somewhere.
I think separate expectations actually makes the most sense, even though it imposes some redundancy. Thanks for the suggestion

I am going to close this ticket, as it is not a bug.  If you need advice or feel there is missing logic please re-open.

authors: jamesdbloom nheitz

repo: jamesdbloom/mockserver


text:
Border style on merged cells applies only to the first cell

If you create a merge cell with border styling, the border styling only applies to first cell.
Applying the border style on row level does not work, too.
row {
    defaultStyle([border: BorderStyle.THIN])
    merge('Test', 1, [border: BorderStyle.THIN])
}

With this only the cell A1 has a border but not B1

Fixed with version 0.4.1. This took a lot more effort than I expected due to the RegionUtil class not supporting custom colors

authors: jameskleeh surfing

repo: jameskleeh/groovy-excel-builder


text:
Remove reference to sourceMappingURL, fix dependencies, bump faye to 1.1.2, and bump to version 2.0.3.

Fixes #86 and #31.
Includes some gemspec changes necessary for a successful build, and includes a bump to 2.0.2 to reflect said changes.

Added commit to bump faye to 1.1.2 (fixes #81).

Looks like you need to change the .travis.yml to build against Ruby 2.[2-3]. Want to give that a go?

Sure!  Just added 2.2.5 and 2.3.1 to .travis.yml.

It looks like 1.9.3 and 2.0.0 are not supported with some current gem dependencies.  If the versions were locked in the gemspec, you could support 1.9.3 and 2.0.0, but these versions are pretty old now.  I yanked them out (which is what I think you actually meant by "change" ;) ).
Let me know if this works!

Thanks!

You're welcome!  Thanks for the merge!

authors: jamesotron synthead

repo: jamesotron/faye-rails


text:
Issue 219

Added provisional mailer to send notice to selector and assistant only. Approved orders still go to selector, admin & assistant.

This looks great. Can you remove the save action on line 52 and submit another commit? I'll merge when that's complete.

authors: billmcmillin crowesn

repo: jamesvanmil/tricerashopper


text:
Updated README.md

The 'Setup' option under 'Run' is changed into 'Run Function'.

Thanks for the help!

repo: jamiewilson/form-to-google-sheets


text:
Option to include predictions/refinements/Ariadne

Right now there is no option for excluding predictions/refinements/ariadne.

Current simplest fix is to just ignore it when copying. Fixed as of commit d6574a4933049f64b1846883440a7b6f6a80f194.

repo: janelia-cosem/annotator-metrics


text:
Unterschiede bei SKOS-Validierung im Turtle-Web-Editor und SkoHub Generierung

für Projektbericht: Erfahrung, dass trotz erfolgreicher Validierung im Turtle Web Editor (Meldung "Congrats! Your syntax is correct.") die Validierung bei der SkoHub Generierung fehlschlägt (vgl. Protokoll der Workflow-Runs auf GitHub https://github.com/jang-rome/skohub-docker-vocabs/actions).
konkrete Beispiele:

GriTHub gibt error code bei fehlenden Language Codes (bei PrefLabel und ScopeNotes etc. wollte SkoHub die flächendeckend)
Hierarchienfehler erkennt der WebEditor nicht immer (Skos:hasTopConcept, skos:inScheme etc.),
die Collections haben Valdiierungsfehler gegeben, obwohl im WebEditor ok
Prefix & Links funktionierten nicht beim Publizieren und erzeugten Felhler

Entscheidung Vorgehen: mehrstufig, (1) zuerst SKOS Kodierung in Ausschnitt des vocabs (2) erst nach Entwicklung des Modells die weiteren Teile des Vocabs (2ff).
Ursache: Was genau validiert eigentlich  der Web Editor?
Lerneffekt & Ausblick: Bei den nächsten Projektschritten den Web Validator https://skos-play.sparna.fr/skos-testing-tool/ in den Workflow integrieren!

Ergänzung SKOS Testing Tool -> besser!

repo: jang-rome/skohub-docker-vocabs


text:
Toggles display opposite to vrchat if default = true, set = false

I'd like a special case added where toggles are displayed the other way around if default = true, set = false, to match how it works in vrchat.
We discussed this in discord, I don't really know how to word it lol.

Added in 83b6bf237c8e537b7f0ccf188bb5d5724de4d261

authors: jangxx rurre

repo: jangxx/VRC-Avatar-Remote-Server


text:
Some per-project configs not persisting

It appears that any checkbox config option for a particular project will lose its applied value and reset to the default if the checkbox has default="${descriptor.foo}" in config.jelly. I've tried this with the "Only use trigger phrase for build triggering" option which lacks the default attribute and persists its value, but the "Close failed pull request automatically" and other options which have defaults in config.jelly do not persist their value once saved (they always show the default value).
I'm not sure if this is only the configuration form which doesn't properly reflect the saved value, or if the value isn't being saved at all.
Tested on 1.16-9

Please retest with 1.24.8

authors: DavidTanner aehlke

repo: janinko/ghprb


text:
fix(rbac): fix role list view permission policies column value

For RHIDP-2431
Screen recording
https://github.com/janus-idp/backstage-plugins/assets/26255262/b130e344-ed3a-4edb-be41-95cefdbc556a
Screenshot for error on fetching role conditions

@ciiay I don't see any issue here. The conditional policy is part of the original policy, functioning as an additional configuration rather than a separate condition. If the intention was to count a conditional policy separately, then we should not consider it as a new policy. In addition, we're going to improve this view to make it clearer which plugins are part of each role, so this column probably will be removed

@ciiay I don't see any issue here.

Hi @ShiranHi , do you mean the screen recording has no issue, or the description from RHIDP-2431 has no issue? I understand they should be considered as same policy from the user's view, but implementation-wise they are retrieved separately.
If there's no issue with the current behavior I could just close this PR.

Hey @ciiay ,It's a bit confusing, so let me clarify :)
In the Jira ticket, it appears that users see "0" in the main table list when they add a conditional policy. However, in the video attached to this PR, everything seems to be working fine. Was the screen recording added as a solution to the Jira ticket, or was it intended to showcase the problem that described in the ticket? If this is the solution - then great, it looks good

Thank you @ciiay for the explanation!

@ciiay CI is failing.

/lgtm

/cherry-pick 1.2.x

authors: ShiranHi ciiay divyanshiGupta

repo: janus-idp/backstage-plugins


text:
Atomics and multi core support

The current implementation of ring_buffer::{Consumer,Producer} only works on single core systems because it's missing memory barriers / fences. The proper way to add those barries is to change the types of the head and tail fields in RingBuffer from usize to AtomicUsize.
We are not doing that right now because that change would make us drop support for ARMv6-M, which is one of the main use cases (single core microcontrollers). If rust-lang/rust#45085 was implemented we could do the change to AtomicUsize while still supporting ARMv6-M.
I think the options are: (a) wait for rust-lang/rust#45085 or (b) provide a Cargo feature that switches the implementation to atomics to enable multi-core support (seems error prone: you could forget to enable the feature -- the other option is to make multi-core support a default feature but default features are hard, and sometimes impossible, to disable which hinders ARMv6-M support).

provide a Cargo feature that switches the implementation to atomics

Or you can just do #[cfg(target_has_atomic = "ptr")] instead of a cargo feature.

That's a very good idea. We can't still claim full multi-core support with that implementation though because multi-core Cortex-M microcontrollers are a thing: probably a Cortex-M0 + Cortex-Mx combination already exists out there and the cfg implementation will use usize on the Cortex-M0 core. Nonetheless, a cfg implementation is as good as we can do for now.

I've looked again at your implementation, and it looks like it's not correct even for single core CPUs.
There is no guaranteed ordering between this two operations:
            unsafe { ptr::write(buffer.get_unchecked_mut(rb.tail), item) }
            rb.tail = next_tail;

So compiler has the right to generate this code instead:
            rb.tail = next_tail;
            unsafe { ptr::write(buffer.get_unchecked_mut(rb.tail), item) }

To prevent that you need to insert a compiler fence between this two operations, so they won't be reordered. Something like this should be sufficient, I think (But I would have also made rb.tail = next_tail; a volatile operation, because there might be some other reordering lurking around.)

Hmm, I don't think the compiler can do that kind of reordering since it changes the value passed to get_unchecked_mut; at least not in this context where a &mut rb.tail (i.e. no aliasing) implicitly exists due to the rb.tail =  assignment.

Oh, and similar thing with reads,
             let item = unsafe { ptr::read(buffer.get_unchecked(*head)) };
            *head = (*head + 1) % n;

It might increment the head first and then do read. Atomic operations guarantee ordering, but volatile operations does not.

since it changes the value passed to get_unchecked_mut
I think this doesn't matter. It can save the old value in register, do assignment and only then do write to a location from register.

I don't follow. Basically you are saying that the compiler can do this kind of reordering (swap A and B) in this code as well:
fn foo(slice: &[u32], head: &mut usize) {
    let n = slice.len();
    let item = slice[*head]; // A
    *head = (*head + 1) % n;  // B
}

(Which is equivalent to the last code you quoted.)
But that doesn't occur in practice; if it did a bunch of safe Rust would break. Adding an unsafe block doesn't make this reordering possible AFAIK.

Why not? I can just swap them, like this:
fn foo(slice: &[u32], head: &mut usize) {
    let n = slice.len();
    let tmp = *head;
    *head = (*head + 1) % n;  // B
    let item = slice[tmp]; // A
}

head can never point into slice because of aliasing rules, so a non racy program can never see the difference between your code and mine. So no save code would break because of this.

But I still can get around the panic like this:
fn foo(slice: &[u32], head: &mut usize) {
    let n = slice.len();
    let tmp = *head;
    if tmp >= n {
        panic!("...");
    }
    *head = (*head + 1) % n;  // B
    let item = slice[tmp]; // A
}

Now the should be identical

OK, I saw the modified read example and I see what you mean now. Sorry, I didn't realize earlier -- I'm already tired. Indeed, if head gets updated before before the data load then an interrupt between the two ops can overwrite the memory slot; I expect something similar can happen in the write case. A compiler barrier should do the trick I think. I'm off for today I'll probably review this again in two days.

then an interrupt between the two ops can overwrite the memory slot

Yes, exactly. Sorry if I was unclear. I just burned myself a lot by writing similar code in C.

Just tested the latest code from git using tsan and it complains about data race:
https://gist.github.com/pftbest/183d7850a3f4535b7e5f9343929f46ad
Here is the code that I used:
https://gist.github.com/pftbest/3642ffba88e7117094bb2053d27637a1
I think the reason why it fails is your recent commit https://github.com/japaric/heapless/pull/8/commits/9faea687d12c79f42217efdc7b31b49ff3830021
If you look at some other popular implementations like boost
https://github.com/boostorg/lockfree/blob/develop/include/boost/lockfree/spsc_queue.hpp#L267
And linux kernel:
https://github.com/torvalds/linux/blob/master/Documentation/circular-buffers.txt#L200
They both do acquire at least for consumer side.
I think it maybe OK to lift the acquire for producer side like they did in linux, because producer doesn't read any data so it doesn't need it. But removing acquire for consumer side is not good, because it is the one thing that provides the actual synchronization. One thread(core) releases the data in buffer and the other thread must acquire it before reading, or else it can read the old value.

Tested without this commit and still get the data race, so there might be something else that I don't see.

I tested locally and I can repro. I changed both loads to acquire and the problem remains. What I find strange is that the report mentions that some backtrace (?) operation is contending with the consumer / producer:
  Previous write of size 4 at 0x56253944a018 by thread T1:
    #0 std::sys_common::backtrace::__rust_begin_short_backtrace hello0-1a838b0df7296149462a69d816ab3a3b.rs:? (hello+0xa58e)
    #1 std::panicking::try::do_call hello0-1a838b0df7296149462a69d816ab3a3b.rs:? (hello+0xa803)
    #2 std::panicking::try::do_call hello0-1a838b0df7296149462a69d816ab3a3b.rs:? (hello+0xa803)
    #3 std::panicking::try::do_call hello0-1a838b0df7296149462a69d816ab3a3b.rs:? (hello+0xa803)
    #4 std::panicking::try::do_call hello0-1a838b0df7296149462a69d816ab3a3b.rs:? (hello+0xa803)

But maybe the backtrace is just pointing to the wrong place.

Found why it fails even if I revert the commit, you had the head and tail mixed up:
https://github.com/japaric/heapless/blob/9533e27f44b21eb331188074771610eb9dae661b/src/ring_buffer/spsc.rs#L46
You release tail in producer, but then acquire head in consumer

Just tested this change against master:
diff --git a/src/ring_buffer/mod.rs b/src/ring_buffer/mod.rs
index 3f53646..abee440 100644
--- a/src/ring_buffer/mod.rs
+++ b/src/ring_buffer/mod.rs
@@ -36,6 +36,10 @@ impl AtomicUsize {
     pub fn store_release(&self, val: usize) {
         unsafe { intrinsics::atomic_store_rel(self.v.get(), val) }
     }
+
+    pub fn load_acquire(&self) -> usize {
+        unsafe { intrinsics::atomic_load_acq(self.v.get()) }
+    }
 }

 /// An statically allocated ring buffer backed by an array `A`
diff --git a/src/ring_buffer/spsc.rs b/src/ring_buffer/spsc.rs
index 488c07a..082aab7 100644
--- a/src/ring_buffer/spsc.rs
+++ b/src/ring_buffer/spsc.rs
@@ -45,7 +45,7 @@ where
         let n = rb.capacity() + 1;
         let buffer: &[T] = unsafe { rb.buffer.as_ref() };

-        let tail = rb.tail.load_relaxed();
+        let tail = rb.tail.load_acquire();
         let head = rb.head.load_relaxed();
         if head != tail {
             let item = unsafe { ptr::read(buffer.get_unchecked(head)) };

It doesn't report any races when N is smaller than buffer size and reports write after read when N > buffer size. But write after read should be OK since it's a circular buffer after all so we can allow such write.

For now I think it would be nice to add to the module-level documentation that this only works on single-core CPU's.

@fluffysquirrels I think this issue was fixed in v0.2.0. No need to update documentation

@pftbest, OK, nice. In which case this issue can be closed. I think it would still be nice to add a line to the ring_buffer module documentation saying what guarantees are provided (i.e. single producer and consumer, as checked by implementing the Send trait but not the Sync trait).

authors: fluffysquirrels japaric pftbest

repo: japaric/heapless


text:
Update sbt-release to 1.0.14

Updates com.github.gseitz:sbt-release from 1.0.13 to 1.0.14.
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!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.gseitz", artifactId = "sbt-release" } ]

labels: sbt-plugin-update, semver-patch

Superseded by #87.

repo: japgolly/univeq


text:
TestScratchDir.test_touch[*] fails on FreeBSD

==================================================================== FAILURES =====================================================================
_________________________________________________________ TestScratchDir.test_touch[Path] _________________________________________________________

self = <test_path.TestScratchDir object at 0x807069e80>
tmpdir = local('/var/tmp/portage/dev-python/path-py-10.3.1/temp/pytest-of-portage/pytest-3/test_touch_Path_1')

    def test_touch(self, tmpdir):
        # NOTE: This test takes a long time to run (~10 seconds).
        # It sleeps several seconds because on Windows, the resolution
        # of a file's mtime and ctime is about 2 seconds.
        #
        # atime isn't tested because on Windows the resolution of atime
        # is something like 24 hours.

        threshold = 1

        d = Path(tmpdir)
        f = d / 'test.txt'
        t0 = time.time() - threshold
        f.touch()
        t1 = time.time() + threshold

        assert f.exists()
        assert f.isfile()
        assert f.size == 0
        assert t0 <= f.mtime <= t1
        if hasattr(os.path, 'getctime'):
            ct = f.ctime
            assert t0 <= ct <= t1

        time.sleep(threshold*2)
        fobj = open(f, 'ab')
        fobj.write('some bytes'.encode('utf-8'))
        fobj.close()

        time.sleep(threshold*2)
        t2 = time.time() - threshold
        f.touch()
        t3 = time.time() + threshold

        assert t0 <= t1 < t2 <= t3  # sanity check

        assert f.exists()
        assert f.isfile()
        assert f.size == 10
        assert t2 <= f.mtime <= t3
        if hasattr(os.path, 'getctime'):
            ct2 = f.ctime
            if os.name == 'nt':
                # On Windows, "ctime" is CREATION time
                assert ct == ct2
                assert ct2 < t2
            else:
                # On other systems, it might be the CHANGE time
                # (especially on Unix, time of inode changes)
>               assert ct == ct2 or ct2 == f.mtime
E               AssertionError: assert (1519224690.72502 == 1519224694.917741 or 1519224694.917741 == 1519224694.917714)
E                +  where 1519224694.917714 = Path('/var/tmp/portage/dev-python/path-py-10.3.1/temp/pytest-of-portage/pytest-3/test_touch_Path_1/test.txt').mtime

test_path.py:321: AssertionError
_______________________________________________________ TestScratchDir.test_touch[FastPath] _______________________________________________________

self = <test_path.TestScratchDir object at 0x8071716a0>
tmpdir = local('/var/tmp/portage/dev-python/path-py-10.3.1/temp/pytest-of-portage/pytest-3/test_touch_FastPath_1')

    def test_touch(self, tmpdir):
        # NOTE: This test takes a long time to run (~10 seconds).
        # It sleeps several seconds because on Windows, the resolution
        # of a file's mtime and ctime is about 2 seconds.
        #
        # atime isn't tested because on Windows the resolution of atime
        # is something like 24 hours.

        threshold = 1

        d = Path(tmpdir)
        f = d / 'test.txt'
        t0 = time.time() - threshold
        f.touch()
        t1 = time.time() + threshold

        assert f.exists()
        assert f.isfile()
        assert f.size == 0
        assert t0 <= f.mtime <= t1
        if hasattr(os.path, 'getctime'):
            ct = f.ctime
            assert t0 <= ct <= t1

        time.sleep(threshold*2)
        fobj = open(f, 'ab')
        fobj.write('some bytes'.encode('utf-8'))
        fobj.close()

        time.sleep(threshold*2)
        t2 = time.time() - threshold
        f.touch()
        t3 = time.time() + threshold

        assert t0 <= t1 < t2 <= t3  # sanity check

        assert f.exists()
        assert f.isfile()
        assert f.size == 10
        assert t2 <= f.mtime <= t3
        if hasattr(os.path, 'getctime'):
            ct2 = f.ctime
            if os.name == 'nt':
                # On Windows, "ctime" is CREATION time
                assert ct == ct2
                assert ct2 < t2
            else:
                # On other systems, it might be the CHANGE time
                # (especially on Unix, time of inode changes)
>               assert ct == ct2 or ct2 == f.mtime
E               AssertionError: assert (1519224694.975006 == 1519224699.010455 or 1519224699.010455 == 1519224699.010384)
E                +  where 1519224699.010384 = FastPath('/var/tmp/portage/dev-python/path-py-10.3.1/temp/pytest-of-portage/pytest-3/test_touch_FastPath_1/test.txt').mtime

test_path.py:321: AssertionError

Well that's annoying. It doesn't fail on macOS (also BSD-based). There are probably other factors at play.
Would you be willing to investigate and characterize the cause of the failure and possibly suggest a more accurate test?

I would love to help but my plate is a big full right now. Could you give me some tips on what could I investigate? I have to say I find it hard to figure out what the assertion is supposed to mean.

Ok, I've added printing of various time in important points of the test (after first touch(), after writing, after second touch()), and that are the results:
{'atime': 1519743112.028664, 'ctime': 1519743112.028682, 'mtime': 1519743112.028664, 'birthtime': 1519743112.02862}
{'atime': 1519743112.028664, 'ctime': 1519743114.154694, 'mtime': 1519743114.154694, 'birthtime': 1519743112.02862}
{'atime': 1519743116.165809, 'ctime': 1519743116.165836, 'mtime': 1519743116.165809, 'birthtime': 1519743112.02862}

So, I think the assumption that fails here is that utime() with NULL argument sets the same value on all modified timestamps. However, apparently it sets them to the different values of 'now' in sequence.

This issue may in fact apply to MacOS as well, and may have emerged with recent builds of BSD as it emerged with recent releases of MacOS as seen in #132.

authors: jaraco mgorny


text:
Add NVM Config

We need to set this .nvmrc config file up with the intended working version from 4 years ago, and update it as we work through the NPM updates.

Link branch.

Done.


text:
Crafttweaker crashes world on start up

Intro:
When generating a world the pack I'm working crashes.
Tried new and old worlds.
I have not made any scripts manipulating mob drops.
Issue Description:
The pack errors as soon as I join the world and outputting something about mob drops. Maybe either too many entities or Epic Siege Mod's chaos mode (which causes mobs to attack each other).
Versions: 3.0.18 and 3.0.19 does this.
What happens:
Crash as soon as I joined the world
What you expected to happen:
I expected to join the world fine as i done in the past.
Script used (Please Pastebin or gist your script, posting an unpasted or ungist'd script will automatically close this issue):
http://pastebin.com/dz7rgyD0
Minetweaker.log file (Please Pastebin or gist your file, posting an unpasted or ungist'd file will automatically close this issue):
http://pastebin.com/hJsuWdXh

Affected Versions (Do not use "latest"):

Minecraft: 1.10.2
Forge: 12.18.3.2221
Crafttweaker: 3.0.19

Your most recent log file where the issue was present:
http://pastebin.com/x1t569ku (crash report)

Update to 3.0.20.
https://minecraft.curseforge.com/projects/crafttweaker/files/2373863


text:
Fixed Collection#set regression when parse returns falsy value

Restored previous code for this logic.
Added a regression test.
Fixes #3871

:+1:

authors: Flamefork craigmichaelmartin

repo: jashkenas/backbone


text:
Chunk

Resolves #1919 pull request (squash, adapted fork of that branch)
Biggest deviation from pr above (and lodash) is chunkSize < 1 returns an array of 0 chunks (empty array)
Closes a bunch of issues #2130 #1891 #2249 #696 #998 #714 (others perhaps?)
Ping https://github.com/underdash/underdash/issues/7 https://github.com/gkz/prelude-ls/pull/81

I'll align lodash to this implementation.

There are no tests for a default count. I'm still against the idea of having a default count.

There are no tests for a default count.

Line 549?
What's your argument against a default count?

Ah, I didn't see that one. My argument against a default count is that I don't feel any particular count is "special" or should be assumed or will be used more frequently than others.

Ah, I didn't see that one. My argument against a default count is that I don't feel any particular count is "special" or should be assumed or will be used more frequently than others.

I sort of agree, however I don't want to deviate from lodash too much

The default could be 0 too. Look to built-in methods with similar params, they have default values.

I'm fine with 0 or 1

The one weak win for having it be 1 would be when it's used as an iteratee in _.map (assuming call guards are in place) but that's a pretty narrow case.

I went with 1 before as that's the smallest meaningful result.

A default of 0 will just return [] unconditionally. That's probably a better default. By the way @jdalton are you coming to the TC39 meeting? There's like 20 MSFT employees here and you're not one of them.

By the way @jdalton are you coming to the TC39 meeting? There's like 20 MSFT employees here and you're not one of them.

Imma be at the dinner. On the agenda items I'm :+1: on trimLeft and trimRight (no name change) and I'm experimenting with the more thorough/robust RegExp.escape implementation being discussed (it escapes leading numbers and things) in lodash as _.escapeRegExp.

I'm down with 0 being a default. It means there's little use for it as a _.map iteratee which means no need to add a guard for it either. (keeps it simple)

Right on, amended.
On Tue, Jul 28, 2015 at 3:47 PM, John-David Dalton <notifications@github.com

wrote:

I'm down with 0 being a default. It means there's little use for it as a
_.map iteratee which means no need to add a guard for it either. (keeps
it simple)
—
Reply to this email directly or view it on GitHub
https://github.com/jashkenas/underscore/pull/2252#issuecomment-125733770
.

authors: jdalton jridgewell megawac michaelficarra

repo: jashkenas/underscore


text:
Minor bug in setup.sh on docker group test if docker is the FIRST group returned by "id -Gn"

Problem
If docker is the first group returned via "id -Gn", setup.sh says "WARNING: You do not appear to be in the docker group"
The issue is with from line 39 of 4.3.1 setup.sh that does the following test:
if ! $(id -Gn 2>/dev/null | grep -qE " docker( |$)"); then
A possible fix it to also use "^docker" so the expression returns true if docker is the first (or only) group listed. But I don't know the full reasoning for the regex, so someone should make sure whatever fix is done is "correct" ... since regex can be "maze of twisty little passages"   ;-)
To Reproduce
$ id -Gn
docker
$ ./setup.sh
Powerwall Dashboard (v4.3.1) - SETUP
WARNING: You do not appear to be in the docker group.
Please ensure your local user is in the docker group and run without sudo.
sudo usermod -aG docker $USER
./setup.sh
Screenshots
N/A
Host System
AlmaLinux release 9.4
Additional context
The reason I stumbled across this bug is because I have a captive account (named solar!) that only runs powerwall ... so I listed the group ID for docker in the /etc/passwd entry for solar. Note the problem ALSO occurs if the user belongs to multiple groups, but docker is the first one returned by id -Gn
So yea, I could make the "primary" group something else and then add solar to the /etc/group docker entry ... but I don't think this should be necessary.
Note that setup.sh does allow you to proceed ... so it's not really a show-stopper ... but a bit confusing because I was like WTF, the user IS in the docker group!    ;-)

Can you run this script to see what you get?
if id -Gn 2>/dev/null | grep -qw "docker"; then
   echo "good"
else
   echo "bad"
fi

I tested using various "group settings" and substrings and that works great @jasonacox.
My situation was a real corner case ... but I think using "-w" for the regex is the way to go.
You can close out this bug report when pushed into production.

authors: hulkster jasonacox

repo: jasonacox/Powerwall-Dashboard


text:
WIP: Limit Rebuy

This is a work in progress to resume discussions from Slack on the Limit Rebuy feature.
The general idea is to add config settings that make the engine use the profits from a sell action as a source for setting post-only limit orders at some interval downward (something like my buy-the-dip bot that probably doesn't work anymore: https://github.com/atomantic/btd_bot)
So new config options would be something like this (assuming a VOL of $100):
CPBB_REBUY: 80, // use $80 from each sell to set limit orders
CPBB_REBUY_VOL: 10, // $10 each limit buy
CPBB_REBUY_AT: -0.5, // -0.5% intervals (e.g. -0.5%, -1%, -1.5%, -2%, -2.5%, -3%, -3.5%, -4%)

Since these limit orders are only filled if the price drops to those targets, this creates some potentially messy adjustments to the growth trajectory system that this project is maintaining, but these can be tracked separately and managed in another local file (I'm thinking of setting up a lowdb json file to store pending limit orders. Additionally, we may want to purge limit orders under a certain price if we think that the price will never see that point again and we want to free up cash for the bot to use in regular taker operations (cash on limit orders is not available for market buys).

Are you thinking the limit orders would stay on the books until they are cleared or filled? What if instead of staying forever, the script wipes out any pending limit orders before taking the official action? Then you’d only have a fixed number of active limit orders on the books and you wouldn’t have to worry about them piling up and adding chaos.
I think I like this idea but I'd like to track it in the ledger like the rest of the orders. Not tracking things gets really hairy. I could see the engine checking with the Coinbase api to see if the limit orders were filled, adding any filled ones to the history, and canceling the rest before taking the official action.
That would change the TotalInput/Target/Diff based on any filled rebuys as additional inputs. Also ensures the bought bitcoin gets tracked.

before you review this, I'm going to break it up into multiple pull-requests and cleanup a bit

authors: atomantic jasonedison

license: ISC