Pandoc implementation for metadata pdf

resolves #1013

Add a new function into dopy/lifecycle/package/generate_metadata_assets, which transforms yaml into pdf.
Add a sample pdf output metadata yaml file, which could be used to config the format of the output pdf. For more instructions, read https://pandoc.org/chunkedhtml-demo/6.2-variables.html#variables-for-latex

Sample pdf outputs:
standard
output.pdf
Landscape layout with two columns
output.pdf
***To Install Pandoc
With the container running, enter from your local terminal as root host:
Follow the instructions to install pandoc on Linux
https://github.com/jgm/pandoc/blob/main/INSTALL.md#linux
We also need to install Latex and Font packages:
apt-get install -y texlive
apt-get install -y texlive-fonts-extra
***TBD
The files are messy at this point, and the function requires too many args, which are probably not necessary. For example, for
def generate_pdf_from_yml(
yaml_file_path: str,
html_template_path: str,
output_html_path: str,
output_pdf_path: str,
pdf_metadata_path,
) -> Path:
We could omit one or two arguments if we have fixed directories for those intermediate HTML or templates.
*** CSS vs. YAML
It seems like we could use a css to control elements such as font and margins, but the pdf metadata yaml is best capable of handling more advanced things like table of contents, hyperlinks, etc.. We could pass in both the CSS and YAML though.

*** CSS vs. YAML
It seems like we could use a css to control elements such as font and margins, but the pdf metadata yaml is best capable of handling more advanced things like table of contents, hyperlinks, etc.. We could pass in both the CSS and YAML though.

@HengJiang0206 Let's merge this, and call it good on any further Data Dictionary work. For this week, we'll likely be turning our focus to READMEs, which we'll discuss at our meeting later today. Thanks!


1.0.4 Recipe Conflict - Storage Drawers Upgrade I and Storage Downgrade

The first-tier upgrade recipe was changed from obsidian to flint, but the same recipe is already in use by the storage downgrade.
This makes the "Upgrades" quest uncompletable.

Fixed in 1.0.5


polyfill not filling the complete polygon

Hello,
I just stumbled on an issue where the polyfill function is not able to fully fill polygons. The problem  affects long, diagonal polygons, like this:

The blue part is the polygon, the green shape are the generated hexagons. Here is a closeup of the lower end of the polygon:

The polyfill was done at resolution 13. Interestingly the result at resolution 12 looks much better:

The GeoJSON for my test polygon is
{"type":"Polygon","coordinates":[[[5.76910652153309,51.1122595579185],[5.74843667987113,51.0844285870957],[5.74868565718131,51.0841156106137],[5.76939661923247,51.1120877871771],[5.76910652153309,51.1122595579185]]]}

To further investigate this issue I went ahead and removed the line of code which does the removal of heaxgons located outside the polygon in this file:
https://github.com/uber/h3/blob/96a0e86d6a80f0d5e83e7a9d1fde34147847af27/src/h3lib/lib/algos.c#L710
I took this approach because I wondered about the clean cut at the end of the filled part  and wanted to see in which radius H3 is generating it indexes.
Running polyfill on my test polygon again gave the following results:
Resolution 12:

Resolution 13:

So the filled minK hex radius seems to be a bit too small for this case. I gave it a try and changed the 1.5 multiplicator in
https://github.com/uber/h3/blob/96a0e86d6a80f0d5e83e7a9d1fde34147847af27/src/h3lib/lib/bbox.c#L120
to the - wildly guessed value - 1.35:
return (int)ceil(bboxRadiusKm / (1.35 * centerHexRadiusKm));

This value is certainly not mathematically correct and needs to be validated. It also increases the number of indexes being generated, but gave me a polygon completely covered in indexes:

So I assume the issue is in the bboxHexRadius function in combination with filling shapes with a large number of indexes. This function seems to have some deficits dealing with long, thin, diagonal shapes.
I did not notice any issues when using polyfill with rounder geometries.

Definitely an amazing bug report.
I disagree on leaving the issue alone until h3ToIJ is ready for use, though. I think we should alter the scaling factor to guarantee correctness and deal with the polyfill slowdown for the short term and then get the performance back up.
We don't have to do the math to determine the maximum extent of hex distortion, if that's what you're worried about wasting time on; just set the constant to something we know could never be reached even with distortion, such as 1.1, and move on.

Thank you both!
You are correct @nrabinowitz , resolution 11 also has this problem:

I had a brief look at #102 and will keep an eye on this functionality in the future. For now I will wait and use the released version of H3.
In the meantime I am thinking of additionally tackling this issue outside of H3 by splitting the polygon into smaller parts and running polyfill on each of them separately. I hope to compensate the increased radius and keep performance up by having to generate and check less indexes.

I will re-check this issue tomorrow, but there is a good chance this issue is invalid and H3 works as expected. So please do not spend any more time on this right now.

Please close this issue as invalid. The problem was caused on my side where I had a systematic mixup of coordinate positions (x,y to lon,lat and back). I am working on an Postgresql binding for H3 and the bug happened during the translation from native postgresql geometry types to the H3 types. Because this error was a systematic mistake, it took a while for me to notice it. It can be frustrating when such simple errors can be the cause for bugs.
Thank you both for your support. I am sorry for the effort this caused on your side.

I think it might still be worth looking into this, though - the original bug report seemed legit, and even if the OP's current issue is solved, there may still be areas of the world/H3 resolutions where this is an issue. Seeing if we can get a repro case would allow us to say whether we fixed it with an h3ToIJ implementation.

This issue is legitimate, even if it doesn't affect the OP. Reversing the lat/long in the test case is still a valid polygon, and does hit this issue.
Repro case:
static GeoCoord testVerts[] = {{0.10068990369902957, 0.8920772174196191},
                               {0.10032914690616246, 0.8915914753447348},
                               {0.10033349237998787, 0.8915860128746426},
                               {0.10069496685903621, 0.8920742194546231}};
static Geofence testGeofence = {.numVerts = 4, .verts = testVerts};
static GeoPolygon testPolygon;

SUITE(polyfill) {

    testPolygon.geofence = testGeofence;
    testPolygon.numHoles = 0;

    TEST(weirdShape) {
        int res = 13;
        int numHexagons = H3_EXPORT(maxPolyfillSize)(&testPolygon, res);
        H3Index* hexagons = calloc(numHexagons, sizeof(H3Index));

        H3_EXPORT(polyfill)(&testPolygon, res, hexagons);
        int actualNumHexagons = countActualHexagons(hexagons, numHexagons);

        printf("Hex count: %d\n", actualNumHexagons);

        free(hexagons);
    }
}

Output with the current 1.5 coeffecient in bboxHexRadius:
TEST polyfill
Hex count: 3945

Output with the coefficient set to 1.0:
TEST polyfill
Hex count: 4353

@greatathrun There's currently a known issue where you can't polyfill a polygon containing a pole. For this particular purpose, though, you ought to be able to use the h3ToGeoBoundaryHier utility, passing in each of the base cells.


Decode capture files in two passes

Instead, read the file twice. The first time through, collect the memory
records and find the high water mark. After that, the user can choose to
do a pass that actually yields allocation records.
Note that with this design it no longer makes sense to warn if the input
file was closed before we reached EOF, since now that's a normal
consequence of retrieving the high water mark allocations: the second
pass over the file closes it once it has read up through the high water
mark index.
Closes: #43

With this branch, I'm able to successfully generate a flame graph from a 125 GB output file.

A couple of comments:

Can you run some quick benchmarks of this PR against the current main branch when generating flame graphs for less crazy files? I recall that when we moved to hold everything in memory it was quite a significant speedup so we should know how much we are going to miss.

We could do some optimizations here: the second pass just needs to deal with allocation records. Every other record (like frames and other stuff) can just be skipped. I suspect dealing with the frame map is one of the major operations so we can avoid it in the second pass.

We should think about showing some progress to the user. I doubt many people will wait for those 20 minutes if we don't tell them what's going on. We could do this in a separate PR thought.

That's certainly not the case as things are written today - we're returning Allocation objects created by the second RecordReader to Python land, and if the user calls .stack_trace() on one of them, it accesses the RecordReader it was created with, passing it the frame index, which the RecordReader looks up in its internal tables.

Maybe I am missing something but here is how I imagine this:

We do a first pass, we insert all frame ids, stack traces we construct the frame tree while calculating the high watermark point.
We already have all the tables and data structures created. Technically, if we return an allocation at this point (which we do not since we are just calculating the high water mark) the stack trace could be resolved because the data is on the reader tables.
When we do the second pass to calculate the high watermatk records technically we do not need to create the tables again because we already have done that in the first pass. We just need to copy over those vectors, tree and maps to the second reader (if we use a second reader) and just ignore the records we read that are not allocations. Here ignoring the record mean reading them but not inserting them anyware. Having to recreate the frame tree in the second pass is going to be super costly an unnecesary.

Of course, the specifics on how we just skip the records elegantly are to be discussed, but we can have some attribute that just say "don't create these" and the reader just skips the insertion on the data structures. We can have an alternate constructor that receives these from the second reader and using this would said the "second pass" flag. Do you see any problem with this approach?

Even if in "second pass" mode it only needs to parse ALLOCATION and ALLOCATION_WITH_NATIVE, that means it still needs d_stack_traces and d_symbol_resolver.currentSegmentGeneration(), and getting those means it also needs FRAME_PUSH, FRAME_POP, and MEMORY_MAP_START. I don't think this would save as much as you think...

My guess is that the tree is the most expensive operation (from previous benchmarking).

My guess is that the tree is the most expensive operation (from previous benchmarking) so I still have hopes.

This would save the work of writing the tree, but we'd still need to read from the tree, and if I recall correctly, that was the one where we spent more time.
I have a different proposal that I think should be possible: I think I can combine HighWatermarkFinder and SnapshotAllocationAggregator into a single class that, in one pass over the records, finds the set of allocation records that represent the high water mark, the set of allocation records that represent the leaked records, and the number of bytes that were in use at the high water mark.
I think that's both less work than what you're proposing and more efficient. I'm gonna spend a bit of time experimenting on that...

After some offline discussions, we realized the reverse of this proposal:

3. When we do the second pass to calculate the high watermark records technically we do not need to create the tables again because we already have done that in the first pass.

is much easier to implement: instead of collecting these tables in the first pass and reusing them in the second pass, we can avoid collecting them in the first pass, where we know nothing needs them, and only collect them in the second pass where we know that stack traces will be needed for each allocation.
I've pushed a commit that does that, which gives some reasonable performance gain over the initial two-pass approach.

Nits addressed, take another look when you can.


Highlight new parts with colored boundaries similarly to how LEGO does in their instructions

This can be done by splitting rendering into 3 parts:

Draw parts from previous step (old part - the ones that can currently be drawn in a single color)
Draw new parts in a single highlighting color and have their size increased by x amount
Draw new parts with their correct colors and no size increase.

If you have a better (faster) way of achieving this, then please feel free to comment and make a pull request.

Very interesting feature!
If I want to change the color of the boundary what should I do please?

Fantastic!
Bunch of thanks

Any time :)


Bioportal mapping

can now map any set of enums to any target ontology from bioportal
examples in Makefile
no live pull of tables yet (limited access Google sheets? Felix Postgres?)
but Makefile does include conversion of a manually obtained TSV to YAML

@cmungall Is that failure from something I did? I haven't been working with dates/times.
PS, I haven't written any test of my own for the BioPortal mapping yet.


CLion/Ninja incompatible with /MP flag

Hi, recently found this project and decided to see if I could get it working with CLion on Windows. The good news is that it almost does. I had to make a slight change to the CMake file for RavEngine.
I changed line 97:
add_definitions(/MP)
to
if(NOT CMAKE_GENERATOR STREQUAL "Ninja")
    add_definitions(/MP)
endif()

But once I did that the project builds, runs and debugs just fine. I don't think it should cause too much of an issue. IIRC /MP is for using multiple threads to build which I think Ninja handles automatically by just using multiple processes. Additionally there are a large number of compiler flag warnings Command line warning D9025 : overriding '/MTd' with '/MDd' etc. These don't break the build, but possible need looking into

Thank you for your report! I have incorporated your suggestion: https://github.com/RavEngine/RavEngine/blob/a9536976d19ec9a728779894ca7ccc1ec03b9f01/CMakeLists.txt#L97-L99
Out of curiosity, does CLion + Ninja work with the UWP builds? I don't have a CLion license so I can't try it.

I've never worked with UWP before but if you have a setup guide for it I would be happy to test it for you

To build for UWP, you should only need to set CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION="10.0" on the command line.
This project supports UWP (despite it being deprecated) because that's currently the only way to develop for Xbox without signing the GDK NDA and becoming an official Xbox developer.

I see, that's fair enough. I wasn't able to get it to build. With just CMAKE_SYSTEM_NAME amd CMAKE_SYSTEM_VERSION enabled it wasn't compiling, but I noticed that it also wasn't defining _WINRT either for the UWP version START_APP. I manually defined it and it still was unable to builod. SDL seems to be the erroring member.
cl : Command line error D8048 : cannot compile C file 'C:\Dev\CPP\Planes\RavEngine\deps\SDL2\src\SDL_assert.c' with the /ZW option for example.

Thank you for testing! In that case, I think we will require Visual Studio for UWP builds but have the option of either Visual Studio or Ninja for Win32 builds.


The write method should throw when writing fails

RSA encryption only allows 256 bytes to be encrypted, so if you try to write a large value then Whorlwind will silently fail with a log in the following format:
Failed to write value for <name>
javax.crypto.IllegalBlockSizeException: input must be under 256 bytes

Of course there are other reasons why this might fail too, but this one is probably one that people will run into often. It would be better to be able to handle this as an error. An alternative solution would be to have this method return a boolean that returns true only when the write was successful.

Oh, fun. Yeah, this should probably be documented and throw!


Add support for specifying the local bind address for each connection

Putting each service on its own address avoids sharing/collisions
between services on cookies and port number.  Specifically this lets me put staging kubernetes dashboard on <IP_ADDRESS> and production on localhost so that they don't overwrite each others' cookies.

@lnikell I added a checkbox as requested, can you try it and let me know what you think?

@lnikell Have you had a chance to review / test this feature?

@Inikell Anything I could do to move this PR forwards?

@lnikell  @proAlexandr Is there anything I can do to move this PR forwards?


Raw Data

Hey,
I want to work on my university Project. I really find your Contribution useful. I wanted to learn and practice this i request you to please give me raw data. You can email me at<EMAIL_ADDRESS>Thanks in Advance,
Shrey

hey, have you received the raw data? if yes please mail me to<EMAIL_ADDRESS>or at least tell me how it is structured.

Hey everyone,I was also working on this project.if you get the raw data please tell me How the files are structured inside that or mail me at<EMAIL_ADDRESS>

I think i got it. They have just taken all the  audio files of actor folders from ravdness dataset and placed all of them into one rawdata folder then they have labelled all the audio files according to their type as mentioned in code.. you can also refer to kaggle dataset ,there they have defined  their meaning.     https://www.kaggle.com/datasets/uwrfkaggler/ravdess-emotional-speech-audio

Hello, can anyone share the raw data with me ....
I am working on the unversity project and I need the raw data to proceed further
mail<EMAIL_ADDRESS>


Update multiple-schedulers doc

Addresses https://github.com/kubernetes/kubernetes/issues/39032
Updates the documentation to reflect new paths and commands where needed.
Adds --leader-elect=false to the example.
cc @kubernetes/sig-scheduling-misc

This change is

@davidopp Do you have time to review this? If not, can you suggest an alternate reviewer? Thx

@foxish There seems to be some conflicts now, so if you can resolve them, I can merge this PR. Thx!

@chenopis Fixed conflicts. Thanks!

Thanks @foxish!


test(rust): use tokio test to simplify some unit tests

This PR uses the #[tokio::test] macro on some unit tests. This removes some clippy warnings which I am getting locally though they don't appear on CI though (but I don't know exactly why):
  assert!(poll_once(async { ac.is_authorized(&msg).await })?);
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: you can reduce it to: `ac.is_authorized(&msg)`

Probably because we use v1.68 on CI

That's also what I'm using, there must be something else, I'll try to get to the bottom of it


ANNOUNCEMENT: App Analysis Tool Now Available!

Several months ago, we announced that we were working on an App Analysis tool to help new users get started with the bridge, and today we're happy to announce the tool is available and live on our website. You can check it out here.
The tool will examine your compiled project (IPA) and cross-reference the frameworks and classes used with the ones currently supported by the bridge, and return the results right in your browser. The tool will also identify third-party libraries and SDK packages used in your project and let you know if they – or equivalent libraries – are available on Windows 10. The analysis is just a starting point, but it will give you a good idea of how much work will be required to bring your iOS app to Windows 10 using the bridge.
We've also published a blog post on the Building Apps for Windows blog with some more information about what the tool does and how to use it.
There are currently a handful of known issues with the tool that we're working to fix as soon as we can, including:

IPAs larger than 2 GB will not be accepted by the tool
IPAs with a capitalized ".IPA" extension will not work. The extension must be lower-case, as in ".ipa"
An invalid IPA file will provide no feedback or error message

If you have any feedback on the tool, please let us know in the comments below!

Everytime I try to upload an IPA, it says:

The file you submitted is not a correctly formatted iOS app package. Please try again with a different IPA.

I generated the IPA using the instructions on the page.

@tmm1 Try checking your Build Settings in Xcode. Under Architectures, make sure you're targeting both arm64 and armv7 (or use the $(ARCHS_STANDARD) variable). Then try rebuilding and resubmitting your IPA.

I see, thanks for the pointer. My app targets 64-bit iOS devices only. Some of my dependencies are aarch64 only, so it would require considerable effort to create an armv7 ipa.

@tmm1 In that case, your best bet is to try out the bridge itself, which you can download here. Once your project is up and running in Visual Studio, you'll see any unsupported methods or properties you're calling printed to the console. (This is similar to the data you'd get from the IPA Analysis Tool, but has the added benefit of being generated at runtime – rather than extracted from a compiled binary – so it should correspond even more closely to what you're actually using.)


Syntax highlighting of RustDoc code samples in block quotes is not stopped

Similar to issue #1, when a fenced code sample appears inside a RustDoc block quote, the entire rest of the file is highlighted as a comment.
For example:

Deleting the last > character in the block quote fixes this issue:

Should be fixed with 7307ce37c70c8ca326955d91fb8adadce9c82552 in 0.2.2.


Added Unit Tests for Format Instrument String Response.vi

[x] This contribution adheres to CONTRIBUTING.md.

TODO: Check the above box with an 'x' indicating you've read and followed CONTRIBUTING.md.
What does this Pull Request accomplish?
Adds Unit Tests for Format Instrument String Response.vi
Why should this Pull Request be merged?
In order to be able to test also this VI during the validation.
What testing has been done?
The new tests were run successfully using the VI tester.

Conflicts solved.


gateway-api: Bump version to v0.8.0-rc1

This is to regularly sync-up with upstream releases, which will make things easy for v1.0.0 later.
Uptream release: https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0-rc1

/test


Fix/payment tests dev2

Explain your changes:
This PR resolves conflicts of #13634
Explain how you tested your changes:
*
Checklist:

[ ] Dependency versions are unchanged

Notify Velocity team if dependencies must change in CI

[ ] Modified the current draft of release notes with details on what is completed or incomplete within this project
[ ] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[ ] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[ ] All tests pass (CI will check this if you didn't)
[ ] Serialized types are in stable-versioned modules
[ ] Does this close issues? List them

Closes #0000

!ci-build-me

!ci-build-me


When will you release version 4?

It took me a while to figure out that the site with documentation is talking about version 4 as having safe defaults. The instructions just tells to npm install cssnano --save-dev which installs version 3 apparently.
So two questions:

When will 4 be released?
Where can I find the documentation for 3?

Thank you for your hard work.

When will 4 be released?

Well, we're currently waiting for the following dependency to be updated: https://github.com/stylelint/stylelint/issues/275

Where can I find the documentation for 3?

I'm.. not sure 😅 The main difference between 3.x and 4.x is the safe default preset, as you've discovered. 3.x has more or less the same options, but passed directly to cssnano.

The stylelint pull request you point to has been merged and released. Did you mean another issue?
I am asking because cssnano is the only thing in my build holding on to postcss 5 (https://github.com/postcss/autoprefixer/issues/905)

Sorry, I meant the following issue: https://github.com/stylelint/stylelint/issues/2757
I accidentally removed the last number.

For completeness: the stylelint issue is waiting for bugs in https://github.com/postcss/postcss-selector-parser to be fixed

Which seems to be stalled because @ben-eb does not have time. Since this (the cssnano) repository is hosted on the account of @ben-eb maybe other contributors of cssnano have enough experience to help fix the issues in postcss-selector-parser that are preventing the release of stylelint.

You can always install cssnano to point to a specific version or to a Github repository and keep it pinned to that version.
For example:
npm install cssnano@next  will install 4.0.0rc2 or whatever version is tagged with next at the time you install
Would that solve your issue until 4.0

@caraya It would certainly do, but at my company we can not use release candidates in production software.

@ben-eb friendly ping, it is allow to upgrade postcss in css-loader and speed up

Hi,
I have to agree on the documentation point, not being able to consult the current stable version docs is quite disturbing and time consuming.
For instance css-loader use the curent 3.x versions.

Just an update for anyone interested.
It seems stylelint/issues/2757 is at a standstill. Stylelint exposes a few issues with the postcss/postcss-selector-parser that show the parser is not compliant with the specs.
The guys at stylelint are very willing to help and even work around the problems with the parser. That however would just be a band aid as the postcss-selector-parser (by @ben-eb) is itself also used by cssnano. The problem here is that @ben-eb seems to be unavailable. I do not want to judge because I don't know @ben-eb and there may be personal circumstances preventing him from participating.
I hope there is someone in the cssnano team that has contact with him at a personal level and is able to find a way to add collaborators to the postcss-selector-parser.
An alternative might be someone forking the postcss-selector-parser, fixing the problems and have cssnano depend on that version.
In short, there will (or maybe should) be no version 4 of cssnano until the postcss-selector-parser is fixed (compliant to the specs).

The issues have been fixed and merged: https://github.com/stylelint/stylelint/pull/2984
At the next release of stylelint it will not be blocking the new version.
Since cssnano itself relies on the postcss-selector-parser I recommend it updates its dependency to the same (fixed) version.

Any news about this issue?

https://github.com/stylelint/stylelint/issues/3012
seems that stylelint will have its 8.3 soon.

Hi folks,
Yeah as you can probably imagine I've been really busy over the last few months, I've decided to take full-time employment and that has meant so far a long working week. Although my employer is already benefiting from my work on this project I don't see any plans in the short term that will enable me to contribute in a sustainable way (due to the rather large backlog of work I have to fulfil), nor can I promise anything longer term.
I am not 100% confident in the stability of the 4.x codebase, which is why I wanted to land some release candidates and get a feel for what the direction should be. Unfortunately as our main consumer is webpack, I don't think we'll actually get much further feedback until they upgrade, which might mean that future maintainers have to do a few patch/minor versions after 4.0.0 is landed.
I've already handed administrative access over to @chriseppstein but I can't speak for him. @andyjansson knows probably more than most about the codebase, but we haven't spoken in a while due to work pressure. Other recent contributors have been mostly drive-by, you can check the activity for yourself.
About the docs, it's difficult enough voluntarily maintaining a project with millions of downloads and keeping docs up to date for two release lines, so I hope you can cut me some slack... 😞

I want to dig into this, but I have my own work deadlines I have to hit at the moment, so I can't devote any significant time to this for another few weeks.
What I could really use help with is getting my arms around what's needed to do to release 4.0.
I'm happy to fix bugs and cut a release, but I need a hit list of open bugs that folks consider a blocker to adopt.
Taking over a code-base this big is pretty hard, especially when you've not been doing any serious development on it. I could really use the community's help testing. At some point, I'll probably just say "eff it" and release. major versions don't auto-upgrade so if there's any major issues, we'll just have to iterate once we find out about them.

@ben-eb Thank you for clearing up your position
@ben-eb @chriseppstein For me it would be good enough in the short term to simply make 3.x work with / depend on postcss 6. I have no clue if that is feasible at all.

I have no clue if that is feasible at all.

@EECOLOR Nor do I, if someone wants to see what's involved and report back, it would be helpful.
As a process point, I do not even have the requisite permissions to contribute to older versions of most of the cssnano dependencies from before the monorepo conversion. Moving forward with 4.0 may be the only route if updates to the dependencies are needed.

Ok, so now this library needs to update both stylelint and postcss-selector parser and then it can be released?

@chriseppstein @andyjansson friendly ping, in near future we release webpack@4 and upgrade css-loader, we need first stable release for starting reporting and fixing bug, also you can invite me and show roadmap. I help with fixing bugs :+1:

https://github.com/postcss/postcss-selector-parser/pull/133

@chriseppstein friendly ping, we need some fixes and stable release :+1: I can help maintain this package

@evilebottnawi @EECOLOR I'm like a week or two from releasing css-blocks, which has been consuming 95% of my open source development time. I'm not great at context switching so I try to keep it to a minimum. I thought I could get the selector parser 3.0 out, but that has already spiraled into more work than I can justify at the moment. I'm going to put a bow on my current changes there and cut another pre-release. If there's other changes needed, I could use a hand in the form of Issues, Pull Requests, and testing against important downstream consumers. In terms of cssnano, I don't have the cycles at the moment to do much more than merge pull requests and cut releases, if one of you wants to take point on getting it into releasable state for 4.0, that would be helpful. Once I see movement on that, I'll update repo access permissions as warranted.

@chriseppstein Thank you very much for the effort you have put in so far!
CSS is on the other end of the spectrum for me. I'm mainly a backend developer and we have developed a zero configuration wrapper around webpack. We would like to keep stuff up-to-date and cssnano is the part that holds us back from the new postcss. I don't know a lot about CSS, display: none; is about the best I can do haha. What I mean to say is that I don't feel I can help out here.
I really hope that more people with a better skill-set can jump in and help cssnano to 4.0!
PS. I like your css-blocks idea!

I've started a project to track issues that need to be addressed to release 4.0
https://github.com/ben-eb/cssnano/projects/1
I really could use a hand with pull requests and triaging issues that are considered blockers or high-priority regressions in 4.0 compared to 3.x.
If there's other issues that aren't yet on that project board, please mention them here and I'll add them.

@chriseppstein It might be an idea to add the request for help to the readme, the npm readme and the documentation site.

@chriseppstein ping, i send 3 PR to solve problems and no answer. Can you solve the problem with your time? If you don't have time on project transfer it to people who have at this time, or at least give the right to continue development.
@ai I am very concerned about this situation, maybe somebody from evil martians have permissions and can help with this

@evilebottnawi yeap, I am very concerned about cssnano 4 as well.
@chriseppstein can we have PR reviews? It is not a big problem to send new developers to fix issues, but without PR review process we will need to find different solution :(.

ping, i send 3 PR to solve problems and no answer.

@evilebottnawi I've merged two of your PRs and left some comments on the third.

@ai what about fork and release on new name? i know it is very very bad, but i send around 10 PR (https://github.com/ben-eb/cssnano/pulls) and all are unanswered/unreviewed, it is impossible to fix problem(s) and release new versions :disappointed: Maybe we can contact with @ben-eb and solve this problem, i don't have @ben-eb contacts

@evilebottnawi Ben Briggs burned out and left open source.
@andyjansson can we review other PR?

@ai Of course, but I'm a bit busy until tomorrow. I will get around to it, don't worry.

Sorry that the amount of my time I donate to this project is insufficient for you. I have a life aside of this, and sometimes I might not be available for a few days.

@andyjansson I know about all people have life aside. I just suggest take care of this project as main contributors. I will do PR, if no unanswered 72 hours, i merge as is (good practice for open source projects which don't have enough contributors). Also take care about all issue bug/features/regressions/documentation and etc. I just can not understand why this is avoided. I offer my help free.

Looks like per #476 that @evilebottnawi will be picking up the project as a maintainer. Thank you for picking this project up!
Does this get v4 stable closer to a release date? It looks like @evilebottnawi has been working on getting things ready and I saw the milestone for v4. Is that milestone / issue list accurate?

@bjankord thanks. I want to release this on this week, but don't have enough time :disappointed:
Prioritized issue https://github.com/cssnano/cssnano/issues/439, feel free to go ahead and send a PR with fix :+1:

@evilebottnawi any blockers? do you need help with something?

@ai sorry, a lot of work, only one bloker https://github.com/cssnano/cssnano/issues/439

Can that issue go in a 4.1.0 or 4.0.1 release to unblock the 4.0.0 release?

@bjankord better fix this in 4.0.0, it should be not difficult, just don't have time right now, in todo list for tomorrow

@ai can't release 4.0.0, because don't have access to many repos in npm: css-size, cssnano-preset-advanced, cssnano-preset-default, cssnano-util-get-arguments, cssnano-util-get-match and a lot of other.
Solution:

Looks you have access, clone repo and run lerna publish --skip-git, then git tag 4.0.0 and git push and add release https://github.com/cssnano/cssnano/releases
Give me access to repos.

@evilebottnawi I gave you a access for all packages in packages/. 4.0!!! 🎉

If I run my script with version 4, I got following error:
BrowserslistError: Unknown version 67 of android

If a remove cssnano or revert to the old version, everything works fine.

@jonnitto looks you have bad browserslist file, can you put here

@evilebottnawi I've updated my comment above

@jonnitto can't reproduce, can you try rm -r package.lock && rm -r node_modules && npm cache clear --force && npm i

@evilebottnawi I created a build package and I found a way to solve this problem. Thank you for your hint! it didn't solve it but gave me an idea.
Another problem
If I have some css like this:
body {
    min-height: calc(100vh - constant(safe-area-inset-top));
    min-height: calc(100vh - env(safe-area-inset-top));
}

I receive following error:
Parse error on line 1:
100vh - constant(safe-area-i
--------^
Expecting 'SUB', 'LPAREN', 'NESTED_CALC', 'NUMBER', 'CSS_VAR', 'LENGTH', 'ANGLE', 'TIME', 'FREQ', 'RES', 'EMS', 'EXS', 'CHS', 'REMS', 'VHS', 'VWS', 'VMINS', 'VMAXS', 'PERCENTAGE', got 'PREFIX'

@jonnitto I wrote the current implementation of postcss-calc. As @evilebottnawi says, it only works on valid CSS. You need to transform your CSS, resolving your constant and env functions before postcss-calc executes.

Thank you for the hint. I could solve it with first creating a CSS property and then using this property in calc. Thank you both a lot for your great work ❤

Please open new issue, don't write here if you have problem after upgrade.


Reducing hash functions

There are several different uses of hash functions within the draft. These generally refer to the hash parameter, but some refer to the xof parameter, which currently appears independent. For compatibility, every hash function that is used in operations by multiple parties must be referenced in the ciphersuite ID. Because we don't want to list several hash functions here, and because supporting multiple hash functions adds extra dependencies (and implementation cost, platform incompatibilities, potential vulnerabilities) I suggest we try to reduce requirement to a single hash function per ciphersuite. Here are the use current cases I've identified:

In hash_to_scalar: Used to generate various scalars within signature and proof generation. We have a proposal to add an XMD version to support non-XOF hashes. This is the primary use of the hash function.
Within KeyGen: this one doesn't need to be included in the ciphersuite ID as it has no impact on other parties. Maybe the hash function should become an input parameter? If we want to keep this operation.
In generator creation:

The current method uses an XOF to generate a stream of bytes which is then fed into a hash-to-curve implementation. If we want to support non-XOF hash functions then we might need to define an alternative method (like the one in the old draft).
The chosen hash-to-curve suite should be required to use the same hash and a compatible expand_message method (XOF or XMD). It must also use hash_to_curve not encode_to_curve in order to guarantee a uniform distribution, ie. the suite identifier must end with 'RO'.

Hashing message inputs:
This one seems a little problematic. It is essential to the security of the signature scheme that all parties understand the encoding used to create the message scalars. Some implementations are going to need type-aware conversion of input values to scalars, which seems beyond the scope of this spec as it implies a dependency on a schema to define the value types. We could completely avoid standardizing message-to-scalar conversion and only use predefined scalars in the test cases. On the other hand, I also believe we need to support the base-level use case of simply signing one or more octet strings, in which case 'MapMessageToScalarAsHash' is sufficient. (In this case, do we want to require that the hash used to convert input messages is the same as the hash used within the other operations?)
In order to support both the typed-values message encoding use case and the simple hash-and-sign use case, perhaps we could add a simple parameter to the ciphersuite ID to distinguish between the two. We could add an ENC_TAG with two values: RAW (treat all input messages as octet strings), and SCHEMA (validate message inputs according to the associated schema, and apply its rules for converting into message scalars). When the ENC_TAG is SCHEMA, then a schema identifier would need to be included in the header value or somehow implied at the application level – I don't think we need to formalize this beyond adding a security guideline.

TBH I think the current effort to support non-XOF hash functions is impeding progress, and we should revisit that after a first draft if at all.

Upon consideration, we don't want to use this ENC_TAG within the ciphersuite ID, as then we'd need to define twice as many ciphersuites. Perhaps this can just be left to the application level?

Agreed with the direction! IMO a suite should define that whatever hash is used for h2c will be used for everything else ass well (mainly hash_to_scalar, which is also used by MapMessageToScalarAsHash). That way the H2C_ID is enough to characterize the suite.
As far as usefulness of the non-xof hash_to_scalar I'm (obviously) of the opinion that is needed. The reason is that a lot of times, only supporting an xof has caused issues in the impenetrability of the scheme, for example, when trying to use libs that don't support shake256 (but they do support h2c with sha256 like blst or noble-bls12-381). Personally, I would like to push a first draft with two ciphersuites, one using shake256 and one using sha256. That way, it will be very easy to implement bbs+ with bls12-381 libs, that are targeted to bls-sigs (that are most of them AFAIK).
To further support the above, I'm also worried that developers will use a lib like the above, with a sha256 based h2c implementation, and just use shake256 for everything else, essentially implementing a wrong suite (which can be dangerous).
Of-course always more than happy in keep discussing this. If the group feels that the _xmd version of hash_to_scalar is not worth wile right now I'm more than happy to close PR #151.

Yes, I think the key is that a 'raw' BBS signature is unlikely to be encountered in the wild – it will be wrapped in a JWS, or a VC, or some other container which defines the interpretation (including the ciphersuite) and hopefully protects that associated data using the header. And of course on the verifier side they will often only see a proof of a signature. I do think we want to avoid the perception that input messages are always hashed.

Personally, I would like to push a first draft with two ciphersuites, one using shake256 and one using sha256. That way, it will be very easy to implement bbs+ with bls12-381 libs, that are targeted to bls-sigs (that are most of them AFAIK).

Well.. it will be easy to implement the sha256 version, but that won't help compatibility with libraries that use shake256. Maybe we should be focusing on adding XOF support to those libraries instead of complicating the spec, or defining an XOF-like primitive based on HDKF.

That's true! And definitely something to consider! The two ciphersuites will not be compatible with each other either way though?? (when it comes to the challenge hash for example). So IMO it's fine to have two different suites that target two different groups of implementations. Since the spec is pretty well suited for use with an xof already (which is very much encouraged), I don't see why also supporting a fixed-output-length hash would do more harm than good (when it comes to the compatibility with shake256 supporting libs)??
Of-course, raising the complexity of the spec is something that i also want to avoid as much as possible. However, in this case, i think its worth it since,

IMO it's for a good reason (I do believe that adding this support on the spec will allow use of a much wider range of already established implementation + i think it's much easier than trying to add xof support to those libs)
I don't think complexity will be raised that much. It will be at most 2 more operations (hash_to_scalar_xmd and maybe a compute_generators_xmd. although i don't think the last one is even needed).

When it comes to HKDF I'm not at all opposed to it. However, it is less efficient. We could also use hash_to_field, although that too is less efficient. In any case I'm fine with the approaches, as long as we have something so we will not make implementing a suite using sha2 next to impossible (as it kinda is right now IMO). In general, currently the spec does fill to me like we try to "force" people in an xof, which I don't think it's wise (IMO many will choose to just not be compatible with the spec than implementing shake256, if they get the chance).
Of-course i could be convinced otherwise. Lets discuss this more!!
(Also i do agree that each suite should be able to be used with only 1 hash and I do think it will be possible with the direction the spec is currently going)

It looks like there are two slightly odd cases, KeyGen and MapMessageToScalarAsHash, which are inheriting the suite's hash parameters but don't necessarily need to because they aren't directly involved in signature generation or verification. Favouring simplicity, though, I think it's fine to only define these in terms of the suite's hash parameters. In both cases alternatives can be used instead, so we are only providing a useful default implementation.

That's a great point! I haven't considered those cases. I do agree that those are just suggestions that cater the more "simple" use cases so it's fine to define everything based on 1 hash??
As a side note. I do start to believe that we overthinking this. Similar considerations could apply to bls-signatures (for the ''Aggregate" scheme) however they just leave everything to the upper layer, and it makes for a readable spec (they don't even worry about PK and message correspondence and ordering in AggregateVerify, which has been a big discussion here).
Personally i would leave KeyGen as it is with a note that it is optional but if used it must use whatever hash is defined by the suite. Same for MapMessageToScalarAsHash. As you pointed out, bbs+ will be warped to containers that will specify the message encoding. To avoid the perception that each message is hashed, we could move the MapMessageToScalarAsHash to the appendix, have a discussion around message encoding in the main part and only point to this operation as an example.

In any case i think we are mostly in agreement here?? Maybe we should start with the xof vs hash discussion on the next call, as i think it's the main issue holding back some progress. Deciding on a direction would be very helpful.
Just to try and clarify the options:

Option 1: Define everything on the basis of an xof only. This means hash_to_scalar, hash_to_curve + createGenerators and MapMessageToScalarAsHash.

Advantages: fewer and simpler operations i.e., no need for hash_to_scalar_xmd or a more complicated createGenerators procedure (like the proposals here)
Disadvantages (-IMO-): making it hard to define a sha2 based suite, and as a result, to use certain libraries like blst and noble-bls12-381.

Option 2: Add support for fixed-output-length hash functions.

Advantages (-IMO-): Ability to easier use a wider range of bls-sigs targeted implementations. Ease of defining sha2 based suites, that can give rise to more use cases (like emending systems or blockchain based ones).
Disadvantages: (As described above) higher spec complexity + more time and effort required to add that support, at a time that we maybe should be focusing on other things.

Please let me know @andrewwhitehead if the above is not accurate or if i missed something. I'm also very keen to hear others opinion around this!

Yes I think that's a good summary, and we should definitely hash it out (lol) on the next call.

One drawback of the xof-only option is that the hash to curve spec only defines SHA256 test vectors for BLS. If we adopt the xof method, we'd need to specify these test vectors as well. The implementation point noted above is also important: the lack of library support for this option complicates the implementation. The level of expertise required to implement the low-level pairing primitives vs. the BBS app layer are vastly different; it blocked my own progress on my javascript ref implementation using the noble library.

@andrewwhitehead can we close this now after the merge of #177 and #151??


Update CHANGES.rst

Hey @harryd31,
thanks for creating a PR. I think there are at least 2 more changes chat should be reflected in the changelog:

Updated django-filter filterset_class syntax
Allow geometry-less models

https://github.com/openwisp/django-rest-framework-gis/compare/v1.0.0...master

@tfranzel  I've submitted another pull request with the changes you proposed

Superseeded by https://github.com/openwisp/django-rest-framework-gis/pull/302. Thanks!


Dark mode issue in the price section

What

Dark mode issue in the price section

Probably a very recent issue: doesn't appear in my local version.


Profile Icons ++

Add the option to choose your profiles icon by some of our made icons and of course your own, in a fancy dropdown :^)

Some parts are implemented.
Todo: Add Custom option for custom images
Bug: Icon changes back because we change to a tinted image by default, remove that if custom icon is set

Custom button now exists, sets value of "Icon" to custom.
We now need to copy the image selected to a folder inside "SnipSniper" and then add a loading function to the switch case that handles the custom state. Currently it just null pointers.
Tinted bug will need to be fixed too.

Done


Progress toward Quality Level 1

This issue tracks the progression of class_loader to Quality Level 1 and a 1.0 version level. It follows the outline described in REP 2004.
This issue tracks the progression of rmw_implementation to Quality Level 1 and a 1.0 version level. It follows the outline described in REP 2004.
1   Version Policy:

[x]  1.i    Must have a version policy (e.g. semver)
[x]  1.ii   Must be at a stable version (e.g. for semver that means version >= 1.0.0)
[x]  1.iii   Must have a strictly declared public API - N/A
[x]  1.iv  Must have a policy for API stability
[x]  1.v   Must have a policy for ABI stability
[x]  1.vi  Must have a policy that keeps API and ABI stability within a released ROS distribution

2    Change Control Process:

[x]  2.i   Must have all code changes occur through a change request (e.g. pull request, merge request, etc.)
[x]  2.ii   Must have confirmation of contributor origin (e.g. DCO, CLA, etc.)
[x]  2.iii  Must have peer review policy for all change requests (e.g. require one or more reviewers)
[x]  2.iv  Must have Continuous Integration (CI) policy for all change requests
[x]   2.v   Must have documentation policy for all change requests

3    Documentation:

[ ]  3.i     Must have documentation for each "feature" (e.g. for rclcpp: create a node, publish a message, spin, etc.) N/A
[ ]  3.ii    Must have documentation for each item in the public API (e.g. functions, classes, etc.) N/A
[x]  3.iii   Must have a declared license or set of licenses
[x]  3.iv   Must state copyrights within the project and attribute all authors
[x]   3.v  Must have a "quality declaration" document, which declares the quality level and justifies how the package meets each of the requirements

[x]  3.v.a     Must have a section in the repository's README which contains the "quality declaration" or links to it
[v]  3.v.b     Should register with a centralized list of 'Level N' packages, if one exists, to allow for peer review of the claim (counting REP-2005 as such list)
[ ]  3.v.c     Must reference any 'Level N' lists the package belongs to, and/or any other peer review processes undergone

4    Testing:

[ ]  4.i    Must have system tests which cover all items in the "feature" documentation

[ ]  4.ii   Must have system, integration, and/or unit tests which cover all of the public API

[x]   4.iii  Code Coverage:

[x]  4.iii.a        Must have code coverage tracking for the package
[x]  4.iii.b        Must have and enforce a code coverage policy for new changes
not required but stating something like "above 95%" as a minimum would be good too (to match developer guide)

[x]   4.iv   Performance:

[x]  4.iv.a        Must have performance tests (exceptions allowed if they don't make sense to have) N/A
[ ]  4.iv.b        Must have a performance regression policy (i.e. blocking either changes or releases on unexpected performance regressions)

[x]  4.v   Linters and Static Analysis:

[x]  4.v.a        Must have a code style and enforce it
[x]  4.v.b        Must use static analysis tools where applicable

5    Dependencies:

[x]       Must not have direct runtime "ROS" dependencies which are not at the same level as the package in question ('Level N'), but...
[x]       May have optional direct runtime "ROS" dependencies which are not 'Level N', e.g. tracing or debugging features that can be disabled
[x]       Must have justification for why each direct runtime "non-ROS" dependency is equivalent to a 'Level N' package in terms of quality

6    Platform Support:

[x]       Must support all target platforms for the package's ecosystem.
For ROS 2 this means supporting all tier 1 platforms, as defined in REP-2000

7    Security

[ ]       Must have a declared Vulnerability Disclosure Policy and adhere to a response schedule for addressing security vulnerabilities

TODO to reach QL1
Version Policy:

[ ] Must have a policy that keeps API and ABI stability within a released ROS distribution

Change Control Process:

[ ] Must have confirmation of contributor origin (e.g. DCO, CLA, etc.)
Linters

[ ] copyright

Documentation
Dependencies

[ ] Must register with a centralized list of 'Level N' packages, if one exists, to allow for peer review of the claim

This package reached level 1! https://github.com/ros/class_loader/pull/177
All boxes can be checked (except for the centralized list) and this issue can be closed. I don't have the powers :zap: .

All boxes checked. Closing!


Trying to change existing CSS

I'm trying to change the design a bit. Specifically, I'm trying to change the CSS of the displayed error and the login container. I can't seem to change it at all. I've tried changing the #error in litarvan/packages/lightdm_webkit_theme_litarvan/components/login_component.css. Still doesn't work.

I'm working on it, i planned to finish it late August/early September


Cancel debounce on component unmount

If input is unmounted before onChange callback is called, it may be called anyway for the element that does not exist anymore.

Wrong repo


refactor: Move LIBRARY_TASK_MAPPING_EXCLUDING_TRANSFORMERS closer to TASKS_MODEL_LIBRARIES

From the review comment by Julien. Context: https://github.com/huggingface/hub-docs/pull/552#discussion_r1045843182
Although semantically the two maps should be the same and one should generate another, but in practice, there are a few differences.
IIUC, TASKS_MODEL_LIBRARIES is only used for task page and it seems to be manually maintained.
LIBRARY_TASK_MAPPING_EXCLUDING_TRANSFORMERS is used for inference and is auto-generated from api-inference-community.
This PR is only about refactoring the existing code, not about merging the two together. Just a few thoughts on the merging:
I think the latter is more reliable and probably more up-to-date also, but not sure if we will have a case where we can show a library on the task page, even if the inference API is not ready. Also the latter doesn't have any information on transformers and assume that transformers can handle all tasks, which is not really the case per the former, so merging the two is not enough unless we have a new list of tasks that transformers can't handle :-)

I think the import type { ModelLibraryKey } from "./Libraries"; in Types.ts can then be removed?

Thanks @Pierrci  ! Removed.


make order (de)serialize

This PR adds the appropriate derive attributes
so that the Order type can be sent in messages

How is that type serialized in JSON? Could you add a test and an entry to https://github.com/CosmWasm/cosmwasm/blob/main/docs/MESSAGE_TYPES.md?


升级最新版启动报错

What is the issue?
升级了最新版本0.1.32，启动报错，错误如下：
Error: llama runner process no longer running:<PHONE_NUMBER>
后来又重装了0.1.31版本，正常启动。
我的是windows10系统
OS
Windows
GPU
Intel
CPU
Intel
Ollama version
0.1.32

I have the similar issue. It just returns: Error: llama runner process no longer running: 1
Because I'm running on a remote node, I do not have the access to ollama log:
Hint: You are currently not seeing messages from other users and the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
Is there any other way to get the log about the error?

What is your configuration? You said you are using a remote node, how are you accessing the remote node?
The error message suggests you are trying to execute ollama run <model> without the service running. If you’re running Windows 10, Ollama would be running as a background service on the desktop. Is the remote node running windows 10?

ollama现在只能看到0.1.32版本，0.1.31版本怎么下载

What is your configuration? You said you are using a remote node, how are you accessing the remote node?
The error message suggests you are trying to execute ollama run <model> without the service running. If you’re running Windows 10, Ollama would be running as a background service on the desktop. Is the remote node running windows 10?

On a debian 10 remote node. I tried to manually start the service using the following commands, and ensure the ollama process has been started.
sudo systemctl daemon-reload
sudo systemctl enable ollama
sudo systemctl start ollama
Then execute ollama run llama3, but the above error persists.

You will need two terminals or use something like tmux or screen:
You can stop the daemon systemctl stop ollama, then in one terminal run OLLAMA_DEBUG=1 ollama serve, the other terminal run ollama run llama3. The logs we would need are from the window for ollama serve. You can pipe it to tee if you want to save it to a file too: OLLAMA_DEBUG=1 ollama serve | tee -a /PATH/TO/FILE

@hyanqing1 sorry that you ran into problems with 0.1.32 on Windows.  We've fixed a number of bugs in 0.1.33 related to windows subprocess handling which should hopefully resolve your problem.  Please try upgrading to 0.1.33 and if you still see problems, please share your server log.

If you're still having problems, please upgrade to the latest version and if that doesn't resolve it, please share your server log and I'll reopen the issue.


Request: Fiat Prices

https://github.com/AugurProject/augur-app/issues/86
...
Would need support for multiple different currencies.
Need live feed support
Recommend doing after V2, as (i.e eth/usd is very different from exchange to exchange).
May not be needed with creation of Dai.
-Chwy5
...
We would need to have a site wide conversions or we could have a tooltip.
@serena What about the idea of having a hover tooltip that gives full precision and give value in currency. We'd probably only support USD initially but could add currencies as we add price feeds.
-bthaile
...
This should be done post-v2.
-adrake33

Not needed with Dai


Add button for new visit or new patient

The button must be visible no matter where the user is at the system.
On hover he have to see the options "new visit" and "new patient".

Button is prepared and ready to be included in the template


Upgrade Microsoft.Data.Sqlite to prevent System.InvalidOperationException: SqliteConnection does not support nested transactions.

The issue described here:
https://github.com/aspnet/Microsoft.Data.Sqlite/issues/532
could be causing the occasional SQLite related exception we've been seeing:
System.InvalidOperationException: SqliteConnection does not support nested transactions.
   at Microsoft.Data.Sqlite.SqliteConnection.BeginTransaction(IsolationLevel isolationLevel)
   at GVFS.Virtualization.BlobSize.BlobSizes.BlobSizesDatabaseWriter.TryAddSizes(ConcurrentQueue`1 sizes, Int32& errorCode, String& error)
   at GVFS.Virtualization.BlobSize.BlobSizes.FlushDbThreadMain()\",\"ErrorMessage\":\"FlushDbThreadMain caught unhandled exception, exiting process\"}"

If there is an internal rollback without the fix mentioned above SqliteTransaction.Complete() will not be called leaving a non-null Transaction set on BlobSizesDatabaseWriter.connection
We should pick up the fix and see if the issue persists.

We're waiting on 2.2.0 here to get out of preview


feat(goal_planner): prioritize goals before objects to avoid

Description

prioritize goals before objects to avoid.
gray numbers are the number of objects to avoid
object not to avoid

object to avoid

https://github.com/autowarefoundation/autoware.universe/assets/39142679/79af93ed-e17c-4d57-84d0-4be711837cce
Related links

none
Tests performed

psim
Notes for reviewers

Interface changes

none
Effects on system behavior

none
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

need to update path priority too.

https://github.com/autowarefoundation/autoware.universe/pull/5137#issuecomment-1735013792
fixed

smart!

@kyoichi-sugahara
thanks! yes please https://github.com/autowarefoundation/autoware_launch/pull/594


what's left

A good point is that the readme tells what's been removed.
For those who do not know k8s features list by heart, it should also tell what's left in k3s.
Nice initiative by the way.

Good idea, I'll update the docs.


can not work when the width of the borders are different (slick 1.6.0)

Here is an example of slick bugs:
1.If slick-slide has border, slick can`t correctly calculate the width of the blocks
2. Slick  blink when we click 'Next'
3. Slick-track height is not current.
http://plnkr.co/edit/6bRXvaTj0MMf22R8OZnx?p=preview
slick 1.6.0
jquery 3.1.1
Every browser problem.

@leggomuhgreggo @kenwheeler are you help me?


getConnectedDevice

await RNBluetoothClassic.getConnectedDevice(); - returned an error - No devices connected ((
But the device is already connected!
Device: iPad Air
index.tsx:274 Error: No bluetooth device connected
    at RNBluetoothClassic.fn [as getConnectedDevice] (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:2165:36)
    at App.initialize$ (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:133436:88)
    at tryCatch (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:29290:19)
    at Generator.invoke [as _invoke] (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:29465:24)
    at Generator.prototype.(anonymous function) [as next] (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:29333:23)
    at tryCatch (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:29290:19)
    at invoke (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:29366:22)
    at http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:29376:15
    at tryCallOne (http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:3244:14)
    at http://<IP_ADDRESS>:8081/index.bundle?platform=ios&dev=true&minify=false:3345:17

index.tsx:279 initializeDevices::list
index.tsx:280 []

Just a couple things here.

Do you have the MFI protocols setup properly
Although Apple says Connected this is just Apples version of Paired.  getConnectedDevice ONLY returns once you've performed a connect(device.address) and the RFCOMM connection is established.

I get that it's a terrible name for the function, since the Apple device says Connected on the screen. But it's an important distinction in how the module works.
You should get that device back with list() if the Mfi stuff is setup right.

          let devices = await RNBluetoothClassic.list();

          console.log('initializeDevices::list');
          console.log(devices);

Returned
index.tsx:279 initializeDevices::list
index.tsx:280 []

And the MFI protocols?

If you don't have MFi Protocols you will never get a device back on IOS.   This is a limitation of the External Accessory framework, not the module.

Thx for the answer.
Give me time - I'll check it

Right on.

No, unfortunately
I added all that can found on the internet

As I understand correctly - they (Garmin) use BLE protocol in the new devices
But  this Garmin GLO 2 - uses something else

Those are not standard protocol values, they should look like a fully qualified name com.garmin.glo1 or something along those lines.   They aren't actually the protocol in terms of RFCOMM.   To give you a quick run down:
Garmin would need to register with apple for the MFI (money and NDAs)
They would pass this down to you (the GPS being 105 dollars means this is unlikely).  If you look at Barcode/Microchip scanners you'll notice that the MFi versions are substantially more expensive than the BLE versions.
The MFI protocols are essentially a secret.  In order to get them you need to sign a bunch of NDAs.  They are like fight club, you can never talk about what they are exactly.
Every version of your app you release, you now need the Vendor to validate that this app is using the correct protocols and they say that "yes this app and version is allowed to use us".  It's super annoying for bug releases and minor version changes on IOS.

))) it's terrible
Thank you, man! I thinking we should dig deeper

Feel free to shoot me an email, I've learned way to much about IOS and bluetooth in the last year trying to get this working.

@kenjdavidson are MFi codes generally available online, or is that something we must obtain from the manufacturer?

I'm not an expert, but I'd say 99% from the manufacturer.  The only company I've seen RELEASE their MFi codes is Zebra (scanners/printers) but those are only for test, in order to release the app to the store you need to have the manufacturer sign off on each iteration of your app (name,version,reason for use).  The vendor we use has been fantastic in this regards, but for just playing around with bluetooth classic, it doesn't seem realistic.
MFi compliant devices seem to be 3-4x the cost of non MFi compliant devices (with regards to Zebra anyhow).  It makes sense, since it costs these companies so much to go through the MFi processes, they need to recoup it somehow.
Again, I may be completely wrong - so take this with a grain of salt.

Thanks for the info @kenjdavidson! Our app is for enterprise / government use so they are used to paying $1500+ for RFID scanners. I reached out to a manufacturer so will see how that goes. I confirmed the device I am using works with iOS because I tested with SerialMagic Keys iOS app.
Thanks for the shoutout on mustache! My wife hated it at first then when I shaved it she missed it and I have had it ever since. Haha!


[core-http] Treat '=' in query parameter values as valid

The '=' character is valid in query parameter values, it is also very
common in base64 encoding. Currently we treat it as invalid and any
parameter name/value pair with '=' in value gets ignore.
I have verified that both NodeJS and browsers' URL types allow '=' in
their searchParameter values.
This change remove the invalidation of this case in
URLQuery.parse() so that the parsing behavior is consistent with
NodeJS and browsers' URL.
Fixes #11014

Seems good. I'm not sure it matters for this change, but do note that = is a subdelim so the encoded form and unencoded form are distinct (and so core should hopefully not be escaping on behalf of clients?)

but I think that = is a subdelim so the encoded form and unencoded form are distinct (and so core should hopefully not be escaping on behalf of clients?)

We don't decode anything here. just parsing url into different parts and put query parameter name/value pairs into a dictionary


Typo fix: Parallell

Typo fix: used the replace all feature across all files to replace ALL instances of "Paralellism" with "Parallellism"

Close for the same reason as mentioned in https://github.com/microsoft/vscode/pull/78576#issuecomment-519731948, thanks!


Add *.Index, *.At and *.Contains

I have code for this in purescript-photons; I'll open a PR for review.

:+1: Sounds good.

Wait, what's the difference between At and Index?

ix is a traversal; "setting" using this traversal will only do so if the value is already present. On the other hand, at is a lens to Maybe a, and can be used to insert or delete a value.

Is it an AffineTraversal (0 or 1 foci)?

Looks like it. Perhaps we can slot AffineTraversal into the hierarchy with something like this.

It is, at least for the instances I am aware of; but I don't know if there is anything about its laws which require it to be so.


fix: Update storage policy assignments (box/box-openapi#396)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-7 of 240 (97.08%)  changed or added relevant lines in 23 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.8%) to 86.875%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

box_sdk_gen/base_object.py
4
7
57.14%

box_sdk_gen/fetch.py
16
20
80.0%

Files with Coverage Reduction
New Missed Lines
%

box_sdk_gen/base_object.py
3
88.1%

Totals

Change from base Build<PHONE_NUMBER>:
0.8%

Covered Lines:
8095

Relevant Lines:
9318

💛  - Coveralls


Added admin/user functionality and created Admin specific portal.

Please resolve conflicts, I can't merge them otherwise


Need equivalent of setRule() method for Attribute

As encountered in PLAT-2950 development:
There is no equivalent for setRule() in the protobuf Attribute object
AC:
Ability to use setRule() method, or some equivalent operation

@jrschumacher @patmantru What's the status of this. Should we close?

@biscoe916 We have disabled the ability to update an attribute but prevent rules since this could cause unintended data leakage (all of --> any of).
We will eventually support unsafe rpcs but that is tracked in another issue. When we do support it I'm not sure if it will be a specific rule or just an unsafe update.


[Loading from Database] Loading underlay scenes from the database does not actually load the underlay

Describe the bug
title. the underlay will show up in the underlay selection menu, but trying to select the underlay you loaded from database will cause a crash.
Steps to reproduce the issue
load up any custom level in BLE, check what underlays are actually loaded so you don't try to load an already loaded underlay from DB and load the underlay through the database, now try to select it as your underlay and you will crash.
Log file
No response
Minimal reproduction
No response

Looks like its one of those cases where it needs load = "true" to work correctly. Try adding it manually to the scene in the add.xml and see if it works like that. I'll try to make it add that by default

added load="true" to  and it works fine now.


client: emit boolean with join/part events.

This new, last argument for the join and part events is true when the username is the same as the client.
You no longer have to write unnecessary code to check this:
Old
client.on('join', (channel, username) => {
    if(username === client.username()) {
        console.log('Joined', channel);
    }
});

New
client.on('join', (channel, username, fromSelf) => {
    if(fromSelf) {
        console.log('Joined', channel);
    }
});

Another option would be to emit "join-self" and "part-self" respectively, but I don't think adding more events is necessary.

Sorry for forgetting "test:" at the start of 2dd8a805ebef71504de387581a6e1e73686205e8's commit message. I'm not good enough with rebasing and stuff to fix it.

git rebase  -i
:)
Joseph Cellucci
Software Developer
ITA Group
<EMAIL_ADDRESS>On Mon, May 30, 2016 at 2:51 AM, Jacob Foster<EMAIL_ADDRESS>wrote:

Sorry for forgetting "test:" at the start of 2dd8a80
https://github.com/Schmoopiie/tmi.js/commit/2dd8a805ebef71504de387581a6e1e73686205e8's
commit message. I'm not good enough with rebasing and stuff to fix it.
https://camo.githubusercontent.com/ff7933f865ebe38bea58eb491896097d7f4fbb08/68747470733a2f2f7374617469632d63646e2e6a74766e772e6e65742f656d6f7469636f6e732f76312f3336302f312e30
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Schmoopiie/tmi.js/pull/142#issuecomment-222433729,
or mute the thread
https://github.com/notifications/unsubscribe/AJyd1cd-hjBu4xtVCypcmiYxFsQkvH4fks5qGpcLgaJpZM4Ipi55
.

For my future reference about the pain of vim and git:
git commit -i 2dd8a805ebef71504de387581a6e1e73686205e8~1

Turn on insert mode (i), change "pick" to "edit" next to the right sha and save (esc, :q)
git commit --amend

Change the commit message and save.
git rebase --continue
git push --force

I keep forgetting the force when committing and since I use GitHub for windows, it doesn't do --force so it undoes my amendments.

LGTM, Thanks!


Grammatical Error

Describe the bug
Missing Period between 2 sentences.
To Reproduce
Steps to reproduce the behavior:

Go to https://app.poolz.finance/dashboard
Choose the Pool No.0
Click on Join green button
See the message.
Tick "I understand" and click Continue button
See the sentences.

Expected behavior
Should replace the Comma with the Period.
Screenshots

Desktop (please complete the following information):

OS: Microsoft 10
Browser Chrome
Version 87.0.4280.88

Additional context
N/A
Wallet address
0x306B769A3B4B4c2D59fC1580f581796Ed9dfDf2F

Thanks for the report. Grammatical bug

Thanks for the report. Grammatical bug


Crome webstore links broken

https://chrome.google.com/webstore/detail/django-query-profiler/ejdgfhecpkhdnpdmdheacfmknaegicff
referenced here on github, and here: https://pypi.org/project/django-query-profiler/     give webstore 404

Issue was also reported months ago on the Django app repo.  https://github.com/django-query-profiler/django-query-profiler/issues/31
I'm kind of surprised this isn't fixed yet.


Compatibility flag

Some functions/properties have unexpected behavior but, to reproduce the official OpenDSS results, they haven't been changed so far. A runtime compatibility flag would allow the library to keep the original behavior and implement a more reasonable one where possible. Some of the oddities:

most array functions return a new array with a single element, but could return NULL/zero elements instead
Solution_Set_Seconds doesn't synchronize dblHour (if you use Solution_Set_Hour first, then Solution_Set_Seconds, the seconds value does affect dblHour)
#36: scaling behavior in the Lines API

I'm considering leaving the new behavior as the default one.

So far a few compatibility flags have been added. Regarding the old list here:

most array functions return a new array with a single element, but could return NULL/zero elements instead

Done in #77.

Solution_Set_Seconds doesn't synchronize dblHour (if you use Solution_Set_Hour first, than Solution_Set_Seconds, the seconds value does affect dblHour)

Still broken.

#36: scaling behavior in the Lines API

Still broken, the whole Lines API needs to be reviewed.
I'm considering adding a flag to keep the broken/unexpected behavior for a few functions, but default to the more correct/expected operation.

Solution_Set_Seconds doesn't synchronize dblHour (if you use Solution_Set_Hour first, then Solution_Set_Seconds, the seconds value does affect dblHour)

Reported upstream at https://sourceforge.net/p/electricdss/discussion/beginners/thread/f6053cece2/?limit=25#340e/46b9


[MB-3539] Remove references to "IsCanceled" as related to Moves/Move Task Orders

Description
Explain a little about the changes at a high level.
Reviewer Notes
Is there anything you would like reviewers to give additional scrutiny?
Setup
Add any steps or code to run in this section to help others prepare to run your code:
echo "Code goes here"

References

Jira story for this change

Messages

:book:
:link: MB-3539

  Generated by :no_entry_sign: dangerJS against ec5e3ac9e919201d911da7b2ad8295fdd11c858b


Feedback

import requests
from html_to_etree import parse_html_bytes
from extract_social_media import find_links_tree

res = requests.get('http://www.costco.com')
tree = parse_html_bytes(res.content, res.headers.get('content-type'))

set(find_links_tree(tree))

The package seems not working for this particular website (costco).

I just had a look, and it could be that the code is not handling schema-less hyperlinks<a href="//www.facebook.com/costco"> well at the moment.
I'll have a look at it.

Yes, the code currently assumes a prefix of r'https?://, so I will need to change that to also allow schema-less urls.

That makes sense. Thanks.


added toString() to help debugging when dumping the monitoring tree

@anthonydahanne : FYI, also added this one so that we know what's going on in the voltron tree in debug mode


Fix custom material glsl example using incorrect CameraViewProj

Objective
The custom_material.vert shader used by the shader_material_glsl example is missing a mat4 View in CameraViewProj (added in #3885)
Solution
Update the definition of CameraViewProj

bors r+


Use a superjson plugin to serialise our Next props

Tentatively closes https://github.com/wellcomecollection/wellcomecollection.org/issues/8364
Who is this for?
Devs.
What is it doing for them?
Allowing us to safely pass non-primitive values through the JSON serialisation in getServerSideProps. In particular, we can now pass Date values in and safely get Date values out the other side.
This should simplify a lot of the client-side date handling, because we can say definitively what the type is.

Size Change: +13.5 kB (+1%)

yikes

Note for Monday: I think review the decision to ditch removeUndefined; it's causing unnecessary bloat in the props, because superjson is managing the custom serialisation in a sidecar field on the props:
      "_superjson": {
        "referentialEqualities": {
          "series.schedule": [
            "series.items.5.series.0.schedule"
          ],
          ...
        },
        "values": {
          "articles.0.color": [
            "undefined"
          ],

That field is pretty large and I removed it unnecessarily.


Skip eng common workflow enforcer for private repos

Skip eng/common workflow enforcer for private repos.

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow


Enable Logging on Cloudfront Distributions

Details can be found at https://jaas.gsfc.nasa.gov/servicedesk/customer/portal/2/GSD-3267

Following advice here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html

Our IAM roles does not give us the ability to put ACLs on S3 Buckets, so for each account we'll need to request that the awslogging service/user has access to a specific bucket in each venue. This is a good reason to avoid cloudformation in venues (we might not have control over) but we'll certainly need it in the shared service venues.

i've created generic buckets in the required accounts for logging purposes. These will be updated by MCP with the correct cloudfront ACLs required.


When Page contains Table its width is wider than Screen

When displaying a html table many columns wide, jqtouch lets you scroll over but the content is covered/cutoff by a black bar

Sorry, the dev is responsible for making sure content fits the width of the page for now-


Loading mBART checkpoint for multilingual translation

I am trying to load the mBART checkpoint to perform multilingual translation as suggested here. When the program attempts to load the pre-trained checkpoint, it gives the following error.
Traceback (most recent call last):
  File "/local/wasiahmad/software/anaconda3/bin/fairseq-train", line 33, in <module>
    sys.exit(load_entry_point('fairseq', 'console_scripts', 'fairseq-train')())
  File "/home/wasiahmad/workspace/fairseq/fairseq_cli/train.py", line 348, in cli_main
    distributed_utils.call_main(args, main)
  File "/home/wasiahmad/workspace/fairseq/fairseq/distributed_utils.py", line 187, in call_main
    main(args, **kwargs)
  File "/home/wasiahmad/workspace/fairseq/fairseq_cli/train.py", line 106, in main
    extra_state, epoch_itr = checkpoint_utils.load_checkpoint(args, trainer)
  File "/home/wasiahmad/workspace/fairseq/fairseq/checkpoint_utils.py", line 137, in load_checkpoint
    reset_meters=args.reset_meters,
  File "/home/wasiahmad/workspace/fairseq/fairseq/trainer.py", line 252, in load_checkpoint
    state = checkpoint_utils.load_checkpoint_to_cpu(filename)
  File "/home/wasiahmad/workspace/fairseq/fairseq/checkpoint_utils.py", line 169, in load_checkpoint_to_cpu
    f, map_location=lambda s, l: default_restore_location(s, "cpu")
  File "/local/wasiahmad/software/anaconda3/lib/python3.6/site-packages/torch/serialization.py", line 592, in load
    return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
  File "/local/wasiahmad/software/anaconda3/lib/python3.6/site-packages/torch/serialization.py", line 852, in _load
    result = unpickler.load()
  File "/local/wasiahmad/software/anaconda3/lib/python3.6/site-packages/torch/serialization.py", line 844, in persistent_load
    load_tensor(data_type(size), size, key, _maybe_decode_ascii(location))
  File "/local/wasiahmad/software/anaconda3/lib/python3.6/site-packages/torch/serialization.py", line 830, in load_tensor
    tensor_file = io.BytesIO(size_long + zip_file.get_record(name))
RuntimeError: [enforce fail at inline_container.cc:143] . PytorchStreamReader failed reading file data/94565435476624: file read failed

Environment:
Name: fairseq, Version: 0.9.0
Name: torch, Version: 1.5.1

I tried to load the checkpoints by simply running the following python code snippet and it works.
path='path2checkpoint'
saved_params = torch.load(
    path, map_location=lambda storage, loc: storage
)

But when I try to load the mBART or CRISS model checkpoint with fairseq-train (using --restore-file), I get the above error.

@myleott any suggestion?

Hi, I got the same error, but I found that it goes well when using the model downloaded from here, which is the mbart v1.
Nonetheless, I have no information about the difference between the model v2 and v1.

@zhengxxn did you try the CRISS model? They have the same architecture as mBART. Can you check?

I actually made the checkpoints work by simply loading and saving the checkpoints as follows.
def load_and_save():
    filename = 'path_2_models/criss_checkpoints/criss.3rd.pt'
    saved_state = torch.load(
        filename, map_location=lambda storage, loc: storage
    )
    torch.save(
        saved_state,
        'path_2_models/criss_checkpoints/model.pt'
    )

Loading from model.pt works perfectly.


up_squared: tests/kernel/semaphore/semaphore failed.

Describe the bug
when running "tests/kernel/semaphore/semaphore" on up_squared, this test will stop at the "test_sem_reset" and fail with timeout.
the last good commit is 6e561570, the first bad commit is da70d20a.
and there were lots of tests failed with the same error:
tests/posix/eventfd
tests/posix/common
tests/portability/cmsis_rtos_v1
tests/kernel/queue
tests/kernel/fifo/fifo_timeout
To Reproduce
Steps to reproduce the behavior:

west build -b up_squared -p auto tests/kernel/semaphore/semaphore
west flash ~/up_squared.sh
see error

Logs and console output
Booting Zephyr OS build zephyr-v2.4.0-2184-g87ddddae5222
Running test suite test_semaphore
START - test_k_sem_define
PASS - test_k_sem_define
START - test_k_sem_init
PASS - test_k_sem_init
START - test_sem_thread2thread
PASS - test_sem_thread2thread
START - test_sem_thread2isr
PASS - test_sem_thread2isr
START - test_sem_reset
the test will stop at there.
Environment (please complete the following information):

OS: Fedora32
Toolchain: zephyr-sdk-0.11.4
Commit ID: 87ddddae5222

based on quick test, this seems to be caused by #30573

Traced it to CONFIG_INTEL_VTD_ICTL being enabled for UP Squared board. After building with it disabled, the test ran fine. So this is not the same cause as #30573, as that problem is still there after disabling CONFIG_INTEL_VTD_ICTL. So re-opening this one as the root-cause is different.

@tbursztyka CONFIG_INTEL_VTD_ICTL is causing issue on UP Squared board.

@dcpleung I will check

this should be closed after the revert in #30716


recapitate with msprime v1

Here's a proposal for how that will work: it lets users specify an ancestral_size, and all populations are merged into one ancestral one of that size.
This builds on #154.

Could you have a look here, @jeromekelleher? I'm trying to recapitate by having all pops come from a population split of an "ancestral" population. However, this doesn't work, because I get an Attempt to sample a lineage from an inactive population error, because the lineages I'm starting with are at time T, and the split is at time T, and so the lineages' populations are inactive at time T.  The only ways I see around this are:

have the split happen at time T + epsilon where epsilon is small
require people to set up their own ancestral demography

... but neither of these seem like great options.

It's not obvious to me that it's actually a good idea to do this, tbh. We're only providing this function so that the returned tree sequence is a SlimTreeSequence instance and we don't lose the reference_sequence, right? In terms of the Demography, I think there'd be less overall confusion if the user was required to specify their own. Since Slim populations don't have names it does get quite messy and confusing, though.
There will need to be some documentation somewhere about how to translate a SLiM population model into a Demography (inevitably the simple approach here won't work for many applications) so why not bite the bullet and focus on writing a documented function to do this first? So, we have a function make_demography(slim_ts) or something, that returns an appropriate demography object from a slim ts. Then, you'd have another function (or maybe this should be something that goes into the msprime API?) that migrates all lineages to a single population at the simulation start time.
Combining the definition of the demography and the simulation like it's currently done will lead to more pain in the long term, I think.

I'm starting to move towards not having SlimTreeSequence be a thing; that's why I wrote this as pyslim.recapitate( ). The goal here is to make this common and important operation be easy, so that people can do the most common, sensible thing without having to understand how to set up a demographic model in msprime. Another real good reason to have a method called "recapitate" is that people know that's what they need to do, so will go looking for it. If there just isn't a sensible deault operation, then OK, we can't do it. But, I think that what I've done here is a pretty sensible default? Let's see:

The most common use case is when SLiM has a single population, and they want to recapitate with a fixed Ne.
The next most common is, when someone has a maybe complicated SLiM simluation, in which most of the genome is coalesced probably. The bit of history they need to simulate is remote enough in time that we don't have a real good idea of exactly what it's like, and just doing a single population with some Ne is, in my opinion, totally the way to go.

I think we definitely want to cover at least (1). Doing that just that is a bit tricky, because we'd need to go through all the roots of all the trees and check which population has lineages in, and if there's only one, changing its size to ancestral_Ne and simulating. Thus, the solution that I've got in the code, which covers (2) also.

Combining the definition of the demography and the simulation like it's currently done will lead to more pain in the long term, I think.

I'm not quite sure what you mean, but one option would be to not allow the demography argument to recapitate, so that the recapitate method only does the default thing of coalescence-in-a-single-unstructured-population. But then the method would need to be called recapitate_with_just_one_pop() or something so people don't think recapitation implies a single population.
We are planning to put names into SLiM populations soon, so if that makes things a lot easier then we could go ahead and do that.

There will need to be some documentation somewhere about how to translate a SLiM population model into a Demography

I guess so? This could be done for a WF simulation, although not all the information (notably, population size) is in the metadata. But, it doesn't even make sense for a nonWF simulation. We do at least need an example of recapitating with "the same" WF model in the docs.

Then, you'd have another function (or maybe this should be something that goes into the msprime API?) that migrates all lineages to a single population at the simulation start time.

Right - is there even a way to do this? I think we'd just need to add a little time epsilon, or define a whole new msprime demographic even that takes place just after time T (ie affects the interval (T, infty) instead of [T, infty)).

Fair enough on the points above. I'd need to think more about the details and maybe work through an example to give more constructive feedback, but I don't have time right now so don't block on me.

Right - is there even a way to do this? I think we'd just need to add a little time epsilon, or define a whole new msprime demographic even that takes place just after time T (ie affects the interval (T, infty) instead of [T, infty)).

Probably easier to  use MassMigration events which will sidestep the state machine stuff entirely. You're not really modelling a population split anyway, and the state machine is only there to prevent users from making mistakes and to make the demography object easier to debug --- neither of which apply here.

Probably easier to use MassMigration events which will sidestep the state machine stuff entirely.

Well, these don't check for correctness, true, but they also don't actually apply, for the same reason as the population split, it turns out: note that in this example, all the nodes are in pop 0, not pop 1:
import tskit, msprime

ts = msprime.sim_ancestry(1, end_time=0.1, random_seed=1)

demography = msprime.Demography.from_tree_sequence(ts)
for pop in demography.populations:
    pop.initial_size=1.0
demography.add_population(name="pop_1", initial_size=1.0)
demography.add_mass_migration(
        0.1,
        source='pop_0',
        dest='pop_1',
        proportion=1.0)

ts2 = msprime.sim_ancestry(initial_state=ts, demography=demography)

print(ts2.tables.nodes)

I used np.nextafter( ) to add an epsilon to the time - I don't think there's a better way to do it.


Multi placeholder string for one uitextview

how to add the placeholder for Arabic and English for the same uitextview if that uitextview code is in my storyboard.i have created the outlet for that too.

Is that available in UITextField?

my question was how to add that in programmatically for English and  Arabic
for the same text field, which I fixed later I got that answer too.
On Fri, Feb 2, 2018 at 12:42 PM, Jeon Suyeol<EMAIL_ADDRESS>wrote:

Is that available in UITextField?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/devxoul/UITextView-Placeholder/issues/46#issuecomment-362505266,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVfm1CbQLvJdYZ3We-IaJesaoWTS_jojks5tQrVtgaJpZM4RyKz0
.

I can't imagine the English and Arabic placeholders in a same place.

no, it's for if u change the language we can give it programmatically for
the different language the same placeholder.
On Mon, Feb 5, 2018 at 10:05 AM, Jeon Suyeol<EMAIL_ADDRESS>wrote:

I can't imagine the English and Arabic placeholders in a same place.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/devxoul/UITextView-Placeholder/issues/46#issuecomment-362979391,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVfm1ImVMvyTH-WisfTlR8xi0IWjdE04ks5tRoUsgaJpZM4RyKz0
.

This is not a placeholder issue, you can just use NSLocalizedString.

yeah, I solved it thanks for your valuable time.
On Mon, Feb 5, 2018 at 2:07 PM, Jeon Suyeol<EMAIL_ADDRESS>wrote:

This is not a placeholder issue, you can just use NSLocalizedString.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/devxoul/UITextView-Placeholder/issues/46#issuecomment-363015141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVfm1HsZ3sRyPeaVlVpIoo-KWIMkGtq3ks5tRr2_gaJpZM4RyKz0
.


LINK-1150 | Remove duplicated code

Description :sparkles:
useEnrolmentData and useEventAndRegistrationData hooks to have unified way to get enrolment, event and registration data
Issues :bug:
Closes :no_good_woman:
LINK-1150

Codecov Report

Merging #44 (3f2a37e) into develop (9791dee) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##           develop       #44   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          113       115    +2
  Lines         2097      2091    -6
  Branches       340       338    -2
=========================================
- Hits          2097      2091    -6

Impacted Files
Coverage Δ

src/domain/enrolment/CreateEnrolmentPage.tsx
100.00% <100.00%> (ø)

src/domain/enrolment/EditEnrolmentPage.tsx
100.00% <100.00%> (ø)

src/domain/enrolment/EnrolmentCancelledPage.tsx
100.00% <100.00%> (ø)

src/domain/enrolment/EnrolmentCompletedPage.tsx
100.00% <100.00%> (ø)

src/domain/enrolment/hooks/useEnrolmentData.ts
100.00% <100.00%> (ø)

...ain/enrolment/hooks/useEventAndRegistrationData.ts
100.00% <100.00%> (ø)

src/domain/enrolment/summaryPage/SummaryPage.tsx
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fix block location iteration with rocksdb

setPrefixSameAsStart does not work when there is a composite key, and
both components need to be specified (2 longs). Therefore, use
setIterateUpperBound instead.
Fixes #11753
pr-link: Alluxio/alluxio#11752
change-id: cid-5c7c45fa69a5c0f0aa078d86baf229c4256d6a50

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-PR-Builder/10487/
Test FAILed.

alluxio-bot, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-PR-Builder/10494/
Test PASSed.

alluxio-bot, merge this please


Add TesterDeposit and TesterWithdrawal methods

This PR will add TesterDeposit and TesterWithdrawal methods for backtesting.

@lazou
You didn't say anything what this tester is to be used for.
What exactly are you testing and what makes this function a "test", instead of actually doing it?

@eabase Thanks for your reply. Both methods are standard mt5 methods (see the used links) which are not yet available in mtapi. They can be used to add or withdraw deposit while backtesting. It is not meant to be a "test" or something else.


Add acceptance test for quickstart

This includes removing some logic that was preventing the DAL Singleton from retrying a connection, although I'm not sure of potential impact.
Fixes #82

Created a new PR rebased on develop (https://github.com/getgort/gort/pull/99). Closing this one.


Something is wrong

Policy and info

Maintainers will close issues that have been stale for 14 days if they contain relevant answers.
Adding the label "sweep" will automatically turn the issue into a coded pull request. Works best for mechanical tasks. More info/syntax at: https://docs.sweep.dev/

Expected Behavior
Please describe the behavior you are expecting.
Current Behavior
What is the current behavior?
Failure Information
Information about the failure, including environment details, such as LLM used.<
I use GPT
Steps to Reproduce
If possible, provide detailed steps for reproducing the issue.
I tried to run the prompt and it started working but I got this error besides it.
Failure Logs
C:\Users\pierr>gpte C:\Users\pierr\Desktop\Projects\flappy-bird-game
C:\Users\pierr\AppData\Local\Programs\Python\Python311\Lib\site-packages\langchain\chat_models_init_.py:31: LangChainDeprecationWarning: Importing chat models from langchain is deprecated. Importing from langchain will no longer be supported as of langchain==0.2.0. Please import from langchain-community instead:
from langchain_community.chat_models import AzureChatOpenAI.
To install langchain-community run pip install -U langchain-community.
warnings.warn(
C:\Users\pierr\AppData\Local\Programs\Python\Python311\Lib\site-packages\langchain\chat_models_init_.py:31: LangChainDeprecationWarning: Importing chat models from langchain is deprecated. Importing from langchain will no longer be supported as of langchain==0.2.0. Please import from langchain-community instead:
from langchain_community.chat_models import ChatOpenAI.
To install langchain-community run pip install -U langchain-community.
warnings.warn(
C:\Users\pierr\AppData\Local\Programs\Python\Python311\Lib\site-packages\langchain_core_api\deprecation.py:117: LangChainDeprecationWarning: The class langchain_community.chat_models.openai.ChatOpenAI was deprecated in langchain-community 0.0.10 and will be removed in 0.2.0. An updated version of the class exists in the langchain-openai package and should be used instead. To use it run pip install -U langchain-openai and import as from langchain_openai import ChatOpenAI.
warn_deprecated(
Running gpt-engineer in C:\Users\pierr\Desktop\Projects\flappy-bird-game
C:\Users\pierr\AppData\Local\Programs\Python\Python311\Lib\site-packages\langchain_core_api\deprecation.py:117: LangChainDeprecationWarning: The function __call__ was deprecated in LangChain 0.1.7 and will be removed in 0.2.0. Use invoke instead.
warn_deprecated(

Can you please provide steps leading to this? It's best to use issue template and add those under the Steps to Reproduce section.

Can you please provide steps leading to this? It's best to use issue template and add those under the Steps to Reproduce section.

Okay I did

We'll check this!

@PierrunoYT just to be sure, your code was working, but it threw those messages, is that correct?

Yes correct

Okay, here's the thing. The messages you are seeing are not errors but warnings. Mostly about some future our current deprecations. They are not errors or bugs, so we will be closing this issue now. Thanks for reporting it, though!