text:
Bug report

I was compiling OpenFast in oder to use BladedDLLInterface.f90 commenting out UserSubs.f90.  I have followed the precedure according to earlier version of FAST guide and I have got the following error. How I can solve it.
Best regards,
Derek

repo: OpenFAST/openfast


text:
OpenFAST Errors occur during regression test

Hello, I'm new user of OpenFAST. I am Building OpenFAST on Windows with Visual Studio.
Prerequisites are

Visual Studio 2015 Community Edition
parallel_studio_xe_2017_update8_cluster_edition_online_setup
Git for windows
Anaconda for Python 3.6
I successfully finished installation and openfast compilation. After that I started windows with visual studio regression test but at step 2 Build the regression testing DISCON DLLs as

When I opened "Discon.sln" file with visual studio the following error occurs

the Discon files are incompatible in visual studios....
Please guide me for windows OS.

Dear @Sohail-hasan,
Your error seems very similar to the one reported and solved in issue #354.
Best regards,

Dear @jjonkman
Thank you for prompt reply. Although I already installed parallel_studio_xe_2017_update8_cluster_edition (Student Version). but let me reinstall it.
Best Regards,

Dear @jjonkman
Thank you for guidance. Now I am on the last stage of regression test.
Total PASSING tests - 21
Total FAILING tests - 13
Now i am reading the related issues to pass the regression test

source: gharchive/issue

authors: Sohail-hasan jjonkman

license_type: permissive

license_source: github-api


text:
Tests for capped AAs

These set of changes implement basic tests for capped amino acids.
Solves #78
It follows the same testing structure that was created for the NonEquilibriumCyclingProtocol, which is based on fixtures.
To avoid having to generate the mapping every time, the mappings are being deserialized from json files.
Please note that this is aimed to be merged to a feature branch where we would have the complete functional MVP for the protein mutation protocol.

Hello @ijpulidos! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file feflow/protocols/protein_mutation.py:

Line 11:80: E501 line too long (105 > 79 characters)
Line 33:80: E501 line too long (97 > 79 characters)
Line 34:80: E501 line too long (102 > 79 characters)
Line 49:80: E501 line too long (94 > 79 characters)

In the file feflow/tests/test_protein_mutation.py:

Line 47:1: E302 expected 2 blank lines, found 1
Line 75:80: E501 line too long (84 > 79 characters)
Line 85:80: E501 line too long (84 > 79 characters)
Line 107:80: E501 line too long (80 > 79 characters)
Line 168:80: E501 line too long (80 > 79 characters)
Line 179:80: E501 line too long (80 > 79 characters)
Line 180:80: E501 line too long (81 > 79 characters)

It seems like the only tests failing here are the ones expected to be failing https://github.com/OpenFreeEnergy/feflow/actions/runs/11185794043/job/31099415246?pr=92#step:8:298 this one should be good to go now. We will be implementing the code for the tests to pass in different PRs. This is to make reviews more modular and easier to do.

source: gharchive/pull-request

repo: OpenFreeEnergy/feflow

license: MIT


text:
自定义数据集支持多轮对话吗

目前在官方给的自定义数据集格式里看起来只支持单轮对话，请问多轮对话的数据集格式应该怎么写？
https://github.com/OpenGVLab/InternVL/blob/main/document/How_to_finetune_mini_internvl_chat_v1_5_on_a_custom_dataset.md#2-prepare-datasets
{"id": 0, "image": "image path relative to dataset path", "conversations": [{"from": "human", "value": "\nyour question"}, {"from": "gpt", "value": "response"}]}

就是这个格式吧

就是这个格式吧

多轮对话我是接着往下写吗，如下所示
{"id": 0, "image": "image path relative to dataset path", "conversations": [{"from": "human", "value": "\nyour question"}, {"from": "gpt", "value": "response"}, {"from": "human", "value": "\nyour question2"}, {"from": "gpt", "value": "response2"}]}

就是这个格式吧

多轮对话我是接着往下写吗，如下所示 {"id": 0, "image": "image path relative to dataset path", "conversations": [{"from": "human", "value": "\nyour question"}, {"from": "gpt", "value": "response"}, {"from": "human", "value": "\nyour question2"}, {"from": "gpt", "value": "response2"}]}

对的 我试过可以work，'\n' 不需要加。

可以按照这个文档准备数据：https://internvl.readthedocs.io/en/latest/get_started/chat_data_format.html

repo: OpenGVLab/InternVL


text:
Cannot find the videos

Dear Sir,
I want to use the dataset from https://github.com/OpenGVLab/Ask-Anything/tree/main/video_chat but I cannot find the link to the videos, there seem to be annotations here. Are the videos from Webvid? In this case, the format "000001_000050/1066682446.mp4" doesn't seem to match with the webvid annotations, I'll appreciate it so much if you could give me some hints!
Thanks!
Best,
Yu

Your given case '000001_000050/1066682446.mp4' is the relative path of a video from WebVid10M. This dataset is structured like the following:

我想问一下是不是1066682446.mp4是唯一的，因为我只下载了部分的webvid数据集，想根据已经有的视频对
videochat_instruct_11k.json进行过滤一下。

Webvid dataset is no longer available. Is it possible that you can share the videos of 11k dataset in a zip file?

videochat_instruct_11k_withurl.json

thank you

authors: icemoon-creative shepnerd wangyu-ustc williamium3000 yinanhe

repo: OpenGVLab/InternVideo


text:
Design Review for Feedback

The test style can be reviewed here
Overview
I have created some style updates based on conversations with OHM team, which begin with the need to improve road contrast in residential roads (#554). That expanded to update primary and motorway link roads, and the prominance of those roads and need to balance them appropriately with other elements of the map near roads meant considering other visual hierarchy contrasts across the map.
GreenInfo Network discussed some of these visual hierarchy considerations with OHM for the basemap in our last meeting a few weeks ago - noting water color needed changing to help alleviate some contrast balance, and also began conversations about removing some gray from the basemap colors. Conversations at that point discussed considering changing rail from a gray tone to a blueish-gray tone. Adjusting tonality helps shift a dark/heavier gray to becoming something that blends into the basemap more... while still holding enough contrast as a distinct element to be distinguishable and notable. The map has gray tones in other elements of the map, so I also considered where else I could remove gray tones from: the largest visual contrast element in the map with gray tones are administrative boundaries, so I also adjusted the admin lines to have more of a green-gray tone. The green-gray works well with the terrain overlay (which brought in a lot of green to low and mid level zooms).
I utilized zoom based styling to make considerations for all visual hierachy considerations. For example - road contrast considerations has casing removed at mid-level zooms, and the primary and motorway roads shift to a darker color at mid level zooms (that still balances with the rest of the map). As you zoom in, the (darker) casings appear and the primary and motorway roads shift to a lighter color. I tested the best time to bring in the casing so that the visual adjustment felt "natural".
Similarly, I removed rail tick marks at mid zooms and brought them in at higher zooms - the visual clutter/contrast was improved (alongside the tone adjustment to a blue/gray for main rails). Additionally, I adjust the tick mark gaps so that the tick marks had a little more "breathing room" for main rails.
With the above considerations in mind, please read the below
Style changes
Road Contrast
Changes address #554

As noted above, non-primary and motorway roads received a contrast adjustment. They now have slightly wider casing, and a lighter gray casing color. The wider casing provides enough visual contrast to help improve visibility, and the lighter gray change helps ensure the non-main roads do not rise in prominance in visual hierarchy.
Per conversations with OHM, I adjusted primary and motorway roadways by changing white casing to a darker casing - darker version of the primary and motorway roadways, respectively. This initial adjustment caused primary and motorway roadways to be too visually prominent, so I had to adjust colors to both the casing for primary and motorway as well as the colors of the primary and motorway roads themselves: I made them lighter than the current OHM orange/red colors. This helped ensure that the overall map remained balanced, and did not bring the roads into more visual prominance (which would be okay for a road map but not this main map).
I tested the map at all zoom levels, adjustments made with casing per what made sense for visual hierarchy styling across all zoom levels. As noted earlier, I removed casing at mid-level zooms. I also adjusted colors for primary and motorway roads and provided zoom level based styling: at mid-level zooms, the primary and motorway roads themselves are darker, and after mid-level zooms, the casing "turns back on" and the primary and motorway roads themselves turn lighter. Visually, this is not jarring: I tested at what zoom level it was appropriate to do so.
Water Color

I adjusted watercolor: lighter. Making the water color made sense alongside considerations for visual contrast, as was discussed in our last OHM meeting. After a lot of color testing, the main area where adjusting water color (and clashing/lack of legibility) was some green spaces - in particular, nature reserve. I adjusted the nature reserve color (see above in Yellowstone) to a different green, and tested globally (currently only other nature serve I could find is a small area in Mexico) so this green adjustment does not affect anything, and helps make changing water color easier.
This new blue is lighter so allows for easier "stacking of future data" on top, as more data comes in, this will be helpful.
Railroads

Rail is currently very visually prominent on the map because of the gray tones as well as the ticks, as noted in Overview.
Also as noted in the Overview, I adjust the gray to a more blue-gray tone for most rail-related layers, and also adjusted when the tick marks show up (not at mid zooms), and increased the spacing between tick marks for normal rail layers (not mini rail):

[ ] We will want to get feedback from OHM users on this rail adjustment (such as Natfoot in Discord)

Admin boundaries' color (and label halos)

Updated:

I made this adjustment based on conversations we had about there being a lot of gray in the map, and how making some minor adjustments would improve some contrast balance. At low and mid-zooms, the admin colors are a gray-green color, which works well with the underlying terraining. Upon zooming into to higher zooms, it adjusts to a more gray-leaning green-gray color, but still is a little less contrasted than the existing version (see above comparisons). Live link review required for all of these, but especially this one, as images shrink sometimes to fit the ticket.
I found #207 and #279 for previous admin boundary conversations (and I am sure there is far more history than that!). Let me know if gray is preferred for admin boundaries, and then can remove this from the general update if gray is preferred.
While looking at admin boundaries, I also noted that admin halos could be adjusted slightly, so changed halos to white in order to remove some gray as well

For railroads you may also take this issue into consideration, implementing it would clean up a lot: #287 Especially already well mapped areas like Seattle are getting pretty full:

How does your design cope with complex yards, are they easier to read with less orthogonal slashes?

Most of them aren't rendered anyway due to the lack of suppport for siding, but those that do are quite messy.

Thank you @Bauer33333! I will take a look at that ticket and think about how possibly adjusting visibilities per usage to help with visual clutter. @natfoot appreciate any feedback you have on rail in this Design Feedback ticket as well!

I adjusted watercolor: lighter. Making the water color made sense alongside considerations for visual contrast, as was discussed in our last OHM meeting. After a lot of color testing, the main area where adjusting water color (and clashing/lack of legibility) was some green spaces - in particular, nature reserve. I adjusted the nature reserve color (see above in Yellowstone) to a different green, and tested globally (currently only other nature serve I could find is a small area in Mexico) so this green adjustment does not affect anything, and helps make changing water color easier.

Lightening the water color changes the style’s mood dramatically. I think it’s a big improvement. That said, we’re no longer using dark fills at all, other than kind of for parks. At high zoom levels where there’s no terrain, the style looks kind of washed out, as you’d expect more from a data visualization basemap style. Maybe this is a good thing, encouraging mappers to map more POIs. On the other hand, this would be an opportunity to darken roads, road casings, and waterways to produce more definition. For example, at the first zoom levels where primary roads come in, they very easily get drowned out by terrain.

OSM Americana similarly had very dark water to begin with. In ZeLonewolf/openstreetmap-americana#610, I lightened the water as you did. To maintain each waterbody’s definition, I added a darker line for coastlines, shorelines, and riverbanks. I also applied this darker color to waterways to help them stand out against parks and other fills. You might not find it necessary to lighten protected area fills if you darken the waterways instead.
The challenge with waterlines is that the vector tiles only represent waterbodies as polyons, not as linestrings. Simply rendering these polygons with a line layer results in an unsightly seam at each tile boundary and also at the mouth of any river. As a workaround, I placed the waterline layer beneath the waterbody layer. Casing layers are normally implemented as the same layer type as the thing it’s casing; however, I implemented it as a line layer instead, since the style specification lacks a property for outsetting a fill layer.
An ordinary outline would make waterbodies look bloated, and result in some visual artifacts at tile boundaries. So I made the waterline a hairline and gave the waterbody layer a 50% translucent outline. Since the waterbodies aren’t buffered, these 50% translucent outlines add up to fully opaque pixels at tile boundaries and anywhere where two waterbodies meet but only 50% at coastlines/shorelines/riverbanks. The waterline layer shows up beneath that outline, making it darker than the waterbody.

Also as noted in the Overview, I adjust the gray to a more blue-gray tone for most rail-related layers, and also adjusted when the tick marks show up (not at mid zooms), and increased the spacing between tick marks for normal rail layers (not mini rail):

I appreciate the subtle use of blue-gray (and also green-gray for boundaries). The more spaced-out rail ties will help to reduce clutter. Consider darkening rail lines slightly, so that they contrast better against land, especially at zoom level 17 where terrain is still visible. Currently they’re virtually indistinguishable from county boundaries:

Thanks for this feedback! I am looking forward to checking out the work you did on Americana with water related work, if you have links out to that, would love to read through with Tim as well.
I will look into the rail color adjustments s well!
I think all of the above is great commentary and I agree, I have been intentionally maintaining some general balance with the updates. I think this is, as noted on the call, a great reminder of wanting to figure out the overall OHM Design Goals and determine what we do or don't want to emphasize more (at different zoom levels/thematically). I would love to really dig deep/do research/have discourse/bring community and determine what we (OHM map designers, OHM, and community) believe is the best data to highlight at specific zoom levels.
The reality is I can make all kinds of changes based on what I data I believe to be more interesting, or what aesthetics I enjoy (which equally can include me making full color changes to make the map be very vibrant across data, while still balancing visual hierarchy), and I also could in theory make adjustments to make a map look like a particular style inspiration as well - which we could try and do, if we decide that is a better pathway than determining what data is a priority per zoom level. My understanding with this path forward is that OHM began with a little bit of style inspiration - before my time, “Geographia highway map of the United States” by Alexander Gross (1950), which Tim discussed a little here.
I would love to, as you said, determine what the data we should (or shouldn't) highlight and continue to discuss and determine what OHM's Design Goals are and come up with what OpenHistoricalMap should look like, based on community input as well as considerations on what data "should be highlighted over the course of history (and why) on a map that shows a lot of data. OHM has provided unique opportunities like "how to showcase data historically, what should we build to support that (eg: timeslider)". I think that the OHM default map provides a unique opportunity to define a unique cartographic use case: How should we style historical data? Today, cartographers and designers can speak to why a map should highlight roads and other particular data layers for road maps; or how to emphasize terrain and what are the best data, design, and color choices for the different ways to show terrain; what are the best (and worst) color ranges for depicting weather data; and so on and so forth - but there isn't any single use case where all of history is being mapped. So we get to define that - and that is exciting! But I think "what gets highlighted and brought to the foreground" should be design choices that are made with the same amount of intention as is made for navigation maps, for example (design = highlighting road infrascture + salient landmarks + other relevant navigation).
All of this to say.... that I am excited that you are excited about figuring out what data we should bring to the foreground as well! Maybe we can use our next monthly meeting to have more conversations around that topic?

I am looking forward to checking out the work you did on Americana with water related work, if you have links out to that, would love to read through with Tim as well.

Most of the discussion around that work took place in ZeLonewolf/openstreetmap-americana#610, which also contains the code that I wrote for it. Note that OSM Americana is actually a Web application that builds the entire style at runtime using JavaScript code, but the code is just bits and pieces of style JSON anyhow. I’ve heard that ohm-website transforms the style into something similar.
There was also some side discussion in OSMUS Slack:
https://osmus.slack.com/archives/C01V02K52UX/p1626579657471400
https://osmus.slack.com/archives/C01V02K52UX/p1670454337209139
https://osmus.slack.com/archives/C01V02K52UX/p1670615330426679
https://osmus.slack.com/archives/C01V02K52UX/p1670549609314729
For what it’s worth, openstreetmap-carto used to have waterlines but regressed them and declined to bring them back: gravitystorm/openstreetmap-carto#3926.

The reality is I can make all kinds of changes based on what I data I believe to be more interesting, or what aesthetics I enjoy (which equally can include me making full color changes to make the map be very vibrant across data, while still balancing visual hierarchy), and I also could in theory make adjustments to make a map look like a particular style inspiration as well - which we could try and do, if we decide that is a better pathway than determining what data is a priority per zoom level.

To be clear, I’m not interested in nitpicking about what gets shown at what zoom levels. I rather like that I don’t have to worry about it for OSM Americana because OpenMapTiles makes all those decisions for me (not always very well, but not my department).
Rather, my feedback presumes that any feature depicted at a given zoom level should be legible enough to identify, whatever the reason it’s included. The terrain layer makes this more challenging. But if the intention is for roads, rail, and borders at that zoom level to sort of recede into the background as texture, then that’s fine too. It certainly looks aesthetically pleasing, and I understand that there are tradeoffs associated with overemphasizing transportation features, especially in time periods when such things were not as prominent in reality.
I brought up this feedback about waterlines and mid-zoom roads because it seems like you’re encountering some of the same visual constraints I have in recent months, but I don’t mean for it to push you in a particular direction.

@vknoppkewetzel - can you make a post about these proposed changes & ask for feedback @ https://forum.openhistoricalmap.org/? We'll steer people over there to see what additional feedback we might get. I will say - there's so much in this set of changes, it's almost a little intimidating to review them all! But! Let's see what we get.

Hey @jeffreyameyer yes! Sorry week has been very busy I will get on this tomorrow 🙏

Forum link: https://forum.openhistoricalmap.org/t/design-feedback-for-ohm-map-updates/56

I'm a bit concerned that this makes railway lines very difficult to see. I think given the importance of railways to the transport network especially historically they do need to be given more prominence, and also need to be distinct from other features. It seems to work reasonably well on OSM Carto.
Personally I'd also prefer a slightly darker blue for water - it seems a bit too pale for me. Mostly I don't think that's too much of an issue though I think it's a problem for canals which are only represented by a very thin line (unless mapped as water areas, which requires a lot of work). Although the thin line is no different from the current style, the change in colour on top of that I think makes them not prominent enough for something which in many countries was historically (and for some canals today) a key part of the transport network.
Apart from that I think this looks good and normal roads seem clearer.

Thanks @PaulTheArchivist for this feedback! it makes sense that historically rail should have visual prominance because of the reason you noted. I'll take a look at emphasizing more and balancing

Is it intentional that yards now seem to render at level 11 and further away and dissapear at level 12 and closer? Or is something else going on here?
Zoom level 11:

Zoom level 12:

For a better understanding of what you see zoomed to the same location on OHM:

and ID:

If this is really what is going on, it should be the opposite way around imo

Hey @Bauer33333 can you drop a link to the same coordinates (to OHM or OSM or the demo style) so I can also compare with the same spot you are looking at? that would help me make sure I see what you are seeing and compare elsewhere too. ty!

Sure, here you go: https://www.openhistoricalmap.org/#map=17/49.00389/8.41386&layers=O&date=1890-01-01&daterange=1890-01-01,2023-12-31

Hey @Bauer33333 I have updated the style to ensure yards are showing up. You can review the update (and other upcoming updates) in this demo/test style. The latest release to the OHM style will happen in the next week or so.

Thank you! Looks great!
I dind't expect lots of parallel lines to look that clean, especially compared to the old OHM style, and unlike ORM you can even see that there are multiple tracks instead of just a big single colour blob. I also like how the parallel yard tiles get a bit brighter than the parallel main line tracks when you zoom out so you still see a slight difference. But maybe this is related to my short track lenghts.
I don't know areas with a lot of mapped yards yet but it may be worth reviewing the min zoom levels of different track types in the future when the map is a bit fuller, it becomes messy and tiles take longer to render.
What is the max zoom limit for? Having everything (this isn't railroad specific) dissapear when you zoom in very close is a bit weird. Wouldn't it make more sense to block zooming in at level 24 or the 20 the normal website ends at? Instead of the 26ish it is now on the test style with the last two just being void.

We've deployed these changes and also a new railway style (#658 and related tickets), so we're going to close this out

authors: 1ec5 Bauer33333 PaulTheArchivist danrademacher jeffreyameyer vknoppkewetzel

repo: OpenHistoricalMap/issues


text:
Fix threadpool

I discovered that the thread_pool could deadlock if the pool queue
filled and then the subtasks themselves added further subtasks to
the queue and waited for their results (since those subtasks would
never themselves get around to executing, with all the pool threads
waiting).
The solution is primarily to modify task_set::wait() so that instead
of unconditionally blocking for the subtasks to complete, it polls
them without blocking, and so when it finds itself waiting for queue
results to still complete, it steals some work from the queue to do
itself. This unclogs the system nicely.
I also modified parallel_for_chunked (which is the basis for the
unchunked parallel_for as well) so that the calling thread itself
executes the last (or only) subtask rather than send it to the pool.
This is yet another way to reduce pressure on the queue, and especially
for cases where you call parallel_for but only one task is necessary
(due to chunking size), it avoids any overhead of using the pool.

PR updated (not sure if it CC'd you when if it thinks my comment was about an outdated push)

repo: OpenImageIO/oiio

license_source: bigquery


text:
Different behaviour of Document.removeValue(forKey: String) from 5.0 to 5.1

Hello Jiannis,
This week I am porting everything to Swift 4.0 and I updated BSON from 5.0 to 5.1
I was getting weird behaviour on with database queries, object creation etc. After some debugging I managed to pin the problem down. The following lines behave differently in 5.0 and 5.1. The behaviour I am getting in 5.1, i do not believe it is the expected one.
    var document = Document()
    document.removeValue(forKey: "_id")
    document.setObject(object: "123", key: "_id")
    print(document.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("123")"
    document.removeValue(forKey: "_id")
    document.setObject(object: "456", key: "_id")
    print(document.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("456")"
    document.setObject(object: "789", key: "_id")
    print(document.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("789")"
    document.setObject(object: "anyvalue", key: "anykey")
    print(document.dictionaryRepresentation["anykey"]) // prints "nil" used to print "Optional("anyvalue")"

    var document2 = Document()
    document2.removeValue(forKey: "anykey")
    document2.setObject(object: "123", key: "_id")
    print(document2.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("123")"

    var document3 = Document()
    document3.setObject(object: "123", key: "_id")
    print(document3.dictionaryRepresentation["_id"]) // prints "Optional("123")"
    document2.removeValue(forKey: "anykey")
    print(document3.dictionaryRepresentation["_id"]) // prints "Optional("123")"
    print(document3.dictionaryRepresentation["anykey"]) // prints "nil"

Basically what is happening is that if on a fresh document (have not set any keys yet), I try to remove any key, then the document gets in a state that I cannot set any keys.
If we init a document and set any key. Then removing a key that does not exist, will not cause any problems. It only causes problem if the document is fresh.
For the moment I sorted it out by implementing the following function and using it instead of removeValue(forKey:)
extension Document {

    public mutating func removeValueIf(forKey key: String) {
        guard self.dictionaryRepresentation[key] != nil else {
            return
        }
        self.removeValue(forKey: key)
    }
}

Thanks for the heads up. That's a really weird problem! I'll have a look right away

The commit I am using is the following, as 5.1 might not be enough
"pins": [
  {
    "package": "BSON",
    "repositoryURL": "https://github.com/OpenKitten/BSON.git",
    "state": {
      "branch": null,
      "revision": "4efeda0fd802c3bbdaffce264f05a50e12b436c1",
      "version": "5.1.4"
    }
  },

That'll help :) Thanks 👍

You are welcome. Hope it will be an easy one to sort out.

document.setObject. Did you implement setObject yourself?

Let me check

Yes I did the code for it is as follows:
   public mutating func setObject(object: Any?, key: String) throws {
        if let json = object as? JSON, let rawString = json.rawString() {
            let document = try Document.init(extendedJSON: rawString)
            self.setObject(object: document, key: key)
            return
        }
        guard let primitive = object as? Primitive? else {
            if let object = object {
                Log.error("Trying to set unsupported value \(object)")
            }
            throw MongoObject.Error.valueNotSupported
        }
        self.setObject(object: primitive, key: key)
    }

    public mutating func setObject(object: Primitive?, key: String) {
        self.removeValueIf(forKey: key)
        if let object = object {
            self.append(object, forKey: key)
        }
    }

Thanks for posting such a concrete issue. I've already managed to get a test up.

    func testDocumentLockup() {
        var document = Document()
        document.removeValue(forKey: "_id")
        document["_id"] = "123"
        XCTAssertEqual(String(document["_id"]), "123")
        XCTAssertNotNil(document.dictionaryRepresentation["_id"])
        document.removeValue(forKey: "_id")
        XCTAssertEqual(String(document["_id"]), nil)
        XCTAssertNil(document.dictionaryRepresentation["_id"])
        document["_id"] = "456"
        XCTAssertEqual(String(document["_id"]), "456")
        XCTAssertNotNil(document.dictionaryRepresentation["_id"])
        document["anykey"] = "anyvalue"
        XCTAssertNotNil(document["anykey"] as? String)

        var document2 = Document()
        document2.removeValue(forKey: "anykey")
        document2["_id"] = "123"
        XCTAssertNotNil(document2["_id"])

        var document3 = Document()
        document3["_id"] = "123"
        XCTAssertEqual(String(document3.dictionaryRepresentation["_id"]), "123")
        document2.removeValue(forKey: "anykey")
        XCTAssertEqual(document3.dictionaryRepresentation["_id"] as? String, "123")
        XCTAssertNil(document3.dictionaryRepresentation["anykey"])
    }

This doesn't seem to trigger the bug. It seems to work on 5.1.4 for me.

I removed setObject and runs the following and I get the same behaviour:
    var document = Document()
    document.removeValue(forKey: "_id")
    document.append("123", forKey: "_id")
    print(document.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("123")"
    document.removeValue(forKey: "_id")
    document.append("456", forKey: "_id")
    print(document.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("456")"
    document.append("789", forKey: "_id")
    print(document.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("789")"
    document.append("anyvalue", forKey: "anykey")
    print(document.dictionaryRepresentation["anykey"]) // prints "nil" used to print "Optional("anyvalue")"

    var document2 = Document()
    document2.removeValue(forKey: "anykey")
    document2.append("123", forKey: "_id")
    print(document2.dictionaryRepresentation["_id"]) // prints "nil" used to print "Optional("123")"

    var document3 = Document()
    document3.append("123", forKey: "_id")
    print(document3.dictionaryRepresentation["_id"]) // prints "Optional("123")"
    document2.removeValue(forKey: "anykey")
    print(document3.dictionaryRepresentation["_id"]) // prints "Optional("123")"
    print(document3.dictionaryRepresentation["anykey"]) // prints "nil"

Found the culprit. dictionaryRepresentation is broken.

To be honest I do not remember why I am using "append" instead of "[] ="
I think there was a problem with "[] ="

I know the problem... Let me push 4.1.5

Perfect. Let me know when it is ready to update.
If it helps:
    var document = Document()
    document.removeValue(forKey: "_id")
//    document.append("123", forKey: "_id")
    document["_id"] = "123"
    print(document.dictionaryRepresentation["_id"]) // prints "Optional("123")"

    var document2 = Document()
    document2.removeValue(forKey: "_id")
    document.append("123", forKey: "_id")
    //document2["_id"] = "123"
    print(document2.dictionaryRepresentation["_id"]) // prints "nil"

https://github.com/OpenKitten/BSON/releases/tag/5.1.5

Thank you.
If I find anything else i will keep you posted.

authors: Joannis zirinisp

repo: OpenKitten/BSON

license: mit


text:
non recurrent mode for variational dropout

variational dropout as described in Gal et al., 2016 does not have the expected result for NMT. Adding a new mode variational_non_recurrent for further exploration.

Codecov Report

Merging #390 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #390      +/-   ##
==========================================
- Coverage   69.62%   69.61%   -0.01%
==========================================
  Files          74       74
  Lines        6282     6290       +8
==========================================
+ Hits         4374     4379       +5
- Misses       1908     1911       +3

Impacted Files
Coverage Δ

onmt/modules/Encoder.lua
92.2% <100%> (ø)
:arrow_up:

onmt/modules/GRU.lua
94.44% <100%> (ø)
:arrow_up:

onmt/modules/LSTM.lua
98.3% <100%> (ø)
:arrow_up:

onmt/train/Trainer.lua
17.69% <0%> (-0.21%)
:arrow_down:

onmt/data/Preprocessor.lua
92.97% <0%> (+0.05%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-io jsenellart

repo: OpenNMT/OpenNMT


text:
Please make the searchbox from openntf available as a snippet

Hi OpenNTF,
the beautiful searchbox from the openntf.org start page is not yet available as a snippet, right?
Would you be so kind to publish that?

THX!
Bernd

Sorry, Bernd, I just came across this while doing some work on the snippets site. The way it's done pre-dates Bootstrap coming into XPages Extension Library, so it's probably not going to be easy to incorporate as it is in the Application Layout Control. The OpenNTF Snippets search is now a multi-faceted search, working slightly differently.
It would need building up as a drop-down like we do with the login area in the new Snippets site https://github.com/OpenNTF/XSnippets/blob/master/xsnippets-disk/Code/ScriptLibraries/brandcms.login.js. Instead of a login form, it would need an unordered list and best would be to pass to a hidden input control that's bound to a sessionScope variable. Getting it in the nav bar is probably going to be trickier, it may need JavaScript as well to build it up.
For info, this is what we'll be launching soon as the navigation area and search area.

Here's the login area built by that brandcms.login.js

authors: BerndGewehr paulswithers

repo: OpenNTF/XSnippets


text:
VM USER_TEMPLATE messed up

Author Name: Anton Todorov (Anton Todorov)
Original Redmine Issue: 5057, https://dev.opennebula.org/issues/5057
Original Date: 2017-03-12

Hi,
Not sure is this bug or feature, but it is sort of confusing so I am classifying it as bug.
How to reproduce:

Instantiate a VM
Goto VM info
Delete all available Attributes (on centos7.2 I have HYPERVISOR and LOGO)

The Attributes will be populated with the data form the VM TEMPLATE

Editing any of the attributes or add new attribute will update the USER_TEMPLATE with TEMPLATE plus the changes.

Expected behavior:

Empty Attributes with option/interface to create a new one.

Kind Regards,
Anton Todorov

It seems this solved, at least we cannot reproduce it

authors: OpenNebulaProject rsmontero

repo: OpenNebula/one


text:
Ansible modules - switch to PyONE, enhance OpenNebula class

Description

common functions like authentication etc should be part of shared OpenNebula class (lib/ansible/module_utils/opennebula.py)
one_image.py still uses python-oca, switch it to PyONE

one_image was ported in (https://github.com/ansible-collections/community.general/pull/2032)

The remaining part is to refactor the other modules to all use OpenNebula class


text:
Sort user IDs in the VM tab's drop-down

Description
In the VM tab of the web UI, I'm shown all VMs by default.
There's a drop-down to select a user and display only that user's items.
Please sort those entries, or provide a site-config option to do so.
Use case
That drop-down's entries are currently unsorted.
This means I have to look closely at each entry in a long list until I find the one that's my user-ID in the system.
It would be much easier to find my entry if they were alphabetically sorted.
I could then just scan down the list to where the first letter of the alphabet is right and zoom in swiftly to the right entry.
Interface Changes
I have no idea how this would impact software interfaces.
Additional Context
The Qt project's continuous integration system is built on OpenNebula.
Internally, staff have access to the OpenNebula system to spawn debug machines when investigating platform-specific issues.
So I'm only a consumer of a service provided using OpenNebula, sending changes for integration and requesting debug VMs, that I need to be able to find in the system once they're provisioned and ready for use.
However, I would be able to persuade the admins to set a config option, if it exists (or is added).

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

adding a note for new sunstone interface, not implementing it in current Sunstone which will be deprecated soon

authors: ediosyncratic tinova


text:
Cannot print test page for LaserJet 4000 or 2300

Thank you very much for your fix to the margin handling!  I updated the snap and I am now able to install the LaserJet 4000 ppd.  I do have an additional problem now, however.  I cannot print a test page to the printer.  If I print a test page, it starts, but does not complete.  The screen then says "No jobs in history."
I previously had a similar problem with the LaserJet 2300.  This time the test page starts printing but does not finish.  (Under jobs, it just says "Started at 16:49:01," but never progresses or actually prints.)  I then printed another test page which disappeared without printing (like the LaserJet 4000 does).
I am able to poll the options for each printer, so the application is communicating with them.  I also can print test pages using more generic ppds.  I have attached the log and state files.
ps-printer-app.log(1).txt
ps-printer-app.state(1).txt

If you click "Add Printer" in the web interface, do your printers appear under the auto-discovered devices ("Device:")? If so, select your auto-discovered printer, leave the "Driver Name:" field on "Auto-Detect" and create the printer. Does this printer print?
Also, before printing, make sure that the settings, "Device Settings", "Media", "Printing Defaults" correspond to the actual situation of your printer's installable accessories (like extra trays), the paper loaded in the trays, and finally the correct tray to take the paper for the test page from.
I assume that your printers are actually PostScript printers and not those which only get their PostScript capability only by an accessory (but I think their should be no problem as your printers answered the accessory and default option polls and they are also in (PostScript).
Could you send the test page directly to your printers using the following commands:
nc -w1 192.168.1.27 9100 < /snap/ps-printer-app/current/usr/share/ps-printer-app/testpage.ps
nc -w1 192.168.1.40 9100 < /snap/ps-printer-app/current/usr/share/ps-printer-app/testpage.ps

Does this work?

Your log file does not look like that you have printed a test page in that session. Please attach a log file which you obtain right after a failure of printing a test page.

Thanks!  My son is using the computer right now for Minecraft, but I will try these things tomorrow.  (Recreate log files, other steps, etc.)
Some quick answers though:  I did generate the log file (by copying it from the snap directory you gave me and then adding read permissions) after I tried to print the test page.  The test page never shows up in the print job history, so maybe that is part of the problem?
I was able to print the test page for both printers by creating generic postscript driver printers in the app, so I think sending the page with netcat will probably also work.
Both printers do have PostScript capabilities (and print with the more generic PostScript drivers.)
I think I have to install avahi-daemon or something to have the printers show up automatically through mdns.  On default Ubuntu 20.04 LTS, no printers show up as autodiscovered.  Also, when I tried "auto-detect" with the socket address before it wouldn't create a printer.

I printed the test page to the LaserJet 4000 using netcat and it worked.
I have a question on the logs.  If the application crashes and then restarts, are fresh logs created?  Do I need to attach the .O version of the logs in addition to the log and state?

It also works to print the test page to the LaserJet 2300 using netcat.

I do not investigate how PAPPL's logging logic works and what happens in case of a crash. But under the condition that systemd restarts the crashed Printer Application it can make the impression that the Printer Application did not actually crash. But you brought me to the idea now that your attempt to print a test page caused a crash and automatic restart with a new log being started (and hope the old one moved into .O), therefore you have a small log file (client count < 10).
Therefore I ask you first to try to print the test page again and then attach BOTH the current log and the ,O.

Thanks.  I will do that.  Is there also a systemd log I should attach?

Here are the logs that I copied after trying to print a test page.  Clicking the print test page button goes to a sort of incomplete version of the printer page, which I think probably indicated that it was printing.  (I was not quick enough to catch it.)  Then the printer page comes back up in the normal version showing no completed jobs.  (I have attached a screenshot of an earlier version of that, but as the time stamps indicated it was not immediately before I captured these logs.
ps-printer-app.log.O.txt
ps-printer-app.log.txt
ps-printer-app.state.txt

.)

It was actually a crash, caused by the boolean option "ManualFeed" in the PPD file. My previous tests (~20 PPD files) all did not have such an option.
Should now be fixed with commit ee40f0f016. The Snap Store is rebuilding currently.
Thank you very much for your bug reports, the discovery of these two crashers was important.

authors: tillkamppeter userhasaname

repo: OpenPrinting/ps-printer-app


text:
fix quoting of loggers in start-stop-daemon

previously broken in 6034866d1c74d5a23eb9f3e0ebf40c9d278aac93
caused *_logger options to be passed unquoted, so
error_logger="logger -t .." would pass -t to s-s-d and fail to start
the service.

actually this is not a complete fix either. if $error_logger contains " it will not work. there are also problems with other variables, for example $directory is not double quoted and thus must not contain spaces in current implementation which is a unnecessarily limiting.
I think the only way to fully solve quoting issues here using posix shell is to use intermediate function like this
run() {
start-stop-daemon ...... ${directory:+--chdir} "$directory" ....... -- "$@"
}

eval run $command_args $command_args_background

Though $start_stop_daemon_args would also need to be examined

kind of feels like the only way out of this pit is to stop using shell

actually this is not a complete fix either

ah, indeed it's not. though at least this matches the previous behaviour (i think?); before it was broken in the same ways.
+1 for a more complete non-shell solution, though i'm probably not going to be writing it :)

omg @linkted very consistent wow
had to spend over half an hour figuring why my init script doesn't work and produce funny input after rebooting

@l29ah Wow it seems you are writing only bug free code. Good for you.

@nekopsykose sorry for this bug. I did not consider this case. Again, sorry for this inconvenience.

@l29ah Wow it seems you are writing only bug free code. Good for you.

i'm not suggesting writing bug-free code, ofc; i'm suggesting reverting the commit and releasing a point release 24-ish days ago when it was noticed
wait... nevermind

So, when you are writing:

omg @LinkTed very consistent wow

You are suggesting to revert the commit and release a new version? Really? And why did you tag me then?
Maybe next time you have the courage to apologize.

I am about to be unavailable for a few days, but I will look at this on 7/14.

@williamh, this is a trivial fix for a bug introduced in the latest release. This bug breaks basically all init scripts that use output_logger or error_logger. What are you waiting for, what is unclear about this? This should have been already merged and released!
I’m sorry, but I’m really losing confidence in this project.

authors: LinkTed jirutka kaey l29ah nekopsykose vapier williamh

repo: OpenRC/openrc


text:
Fix templating exporter to accept closing braces in expressions

Fixes #3381
Templating is fixed according to the issue specification.

Looks like we have some merge conflicts that should be solved before the CI can kick in.

@wetneb Okay, I think this should be good to go, let me know what you think!

@wetneb Okay I added back the test that I had taken out. (It was causing some build failure but I just needed to format it correctly).

authors: JohnMcGrane wetneb

repo: OpenRefine/OpenRefine


text:
merge the jetty6 upgrade branch to trunk

Thank for the review by Manik, especially "use ExecutorThreadPool instead of QueuedThreadPool" for better performance in the Jetty 9.2.6

fixed the ant build

Thanks for fixing the things that @maniksurtani pointed out.  I agree with all his comments.
The pull request also needs to be done from a feature branch, not from your forked master, because otherwise it's susceptible to getting polluted by unintended later changes (e.g. your removal of openjdk6 from the Travis config which might have been intended to be a purely local change).  Each feature branch/pull request should include a single coherent set of changes without any unrelated changes.
We won't be updating any dependencies until after the 2.6 release, but that should happen very soon.  At that point I'll be doing a major dependency update and probably another relatively quick release, so these code changes will come in handy then.

Agree. The feature branch make perfect sense.
On Sun, Jan 25, 2015, 12:19 PM Tom Morris notifications@github.com wrote:

Thanks for fixing the things that @maniksurtani
https://github.com/maniksurtani pointed out. I agree with all his
comments.
The pull request also needs to be done from a feature branch, not from
your forked master, because otherwise it's susceptible to getting polluted
by unintended later changes (e.g. your removal of openjdk6 from the Travis
config which might have been intended to be a purely local change). Each
feature branch/pull request should include a single coherent set of changes
without any unrelated changes.
We won't be updating any dependencies until after the 2.6 release, but
that should happen very soon. At that point I'll be doing a major
dependency update and probably another relatively quick release, so these
code changes will come in handy then.
—
Reply to this email directly or view it on GitHub
https://github.com/OpenRefine/OpenRefine/pull/934#issuecomment-71381878.

@jackyq2015 what is the status of this PR?

Close it for now due to the file confliction. Separated PR needed to do the library upgrade.

authors: jackyq2015 tfmorris wetneb


text:
Add new Sensors and Actuators for Arduino

Is your feature request related to a problem? Please describe.
There are some commonly used sensors and acutators, which are not implemented in the ORLab with a specific block.
Describe the solution you'd like
There should be a dedicated block to use the device.
Describe alternatives you've considered
The Open Roberta Lab offers the "write digital/analog value to actuator" and "get analod/digital value from sensor" blocks to allow users to use devices that are not specifically implemented on the ORLab.
Additional context
If you want a specific sensor / actuator to tbe added to the ORLab, please comment on this issue.

Request to implement "RTC DS3231" (https://draeger-it.blog/arduino-lektion-17-realtimeclock-rtc-ds3231/) through support.

Request to add a PWM / Heartrate block for analog writing for Arduino. (As discussed, this should be setting on the "acutator analog" configuration block)

Request to add a color sensor, for example TCS3200

Request to implement a geared motor. (like bxma81320, which is used in the mbot)

repo: OpenRoberta/openroberta-lab


text:
当概念类型instance有多个时，与概念类型之间的谓词关系，使用dsl无法查询

在supplychain例子中，TaxOfCompanyEvent: ConceptType有两个instance，TaxOfCompanyEvent/成本上涨和TaxOfCompanyEvent/利润下跌。
根据如下定义：
`TaxOfCompanyEvent`/`成本上涨`:
    rule: [[
        Define (e:CompanyEvent)-[p:belongTo]->(o:`TaxOfCompanyEvent`/`成本上涨`) {
            Structure {
            }
            Constraint {
                R1: e.index == '成本'
                R2: e.trend == '上涨'
            }
        }
    ]]

如果创建了一个CompanyEvent( index == '成本'，trend == '上涨' 类型)，则会存在(e:CompanyEvent)-[p:belongTo]->(o:TaxOfCompanyEvent/成本上涨)这样一条边。
在tugraph中，能够直接查询出来这条边：

但是在spg中使用如下dsl进行查询时，
knext reasoner execute --dsl "
MATCH
    (o:SupplyChain.CompanyEvent)-[e:belongTo]->(c:SupplyChain.TaxOfCompanyEvent)
WHERE o.subject='CSF0000000002'
RETURN
    o.id,o.subject,o.name,o.belongTo,o.leadTo,o.index,o.trend
"

会报如下错误：
java.lang.RuntimeException: com.antgroup.tugraph.TuGraphDbRpcException: CypherException: ParserException: line 1:38 no viable alternative at input 'MATCH (s:SupplyChain_TaxOfCompanyEvent/'
        at com.antgroup.openspg.cloudext.impl.graphstore.tugraph.TuGraphStoreClient.queryRecord(TuGraphStoreClient.java:111)
        at com.antgroup.openspg.reasoner.warehouse.cloudext.CloudExtGraphState.getVertexIterator(CloudExtGraphState.java:117)
        at com.antgroup.openspg.reasoner.runner.local.impl.LocalPropertyGraph.getStartIdList(LocalPropertyGraph.java:124)
        at com.antgroup.openspg.reasoner.runner.local.impl.LocalPropertyGraph.createRDG(LocalPropertyGraph.java:68)
        at com.antgroup.openspg.reasoner.runner.local.impl.LocalPropertyGraph.createRDG(LocalPropertyGraph.java:39)
        at com.antgroup.openspg.reasoner.lube.physical.operators.Start.rdg(Start.scala:28)
        at com.antgroup.openspg.reasoner.lube.physical.operators.PatternScan.rdg(PatterScan.scala:27)
        at com.antgroup.openspg.reasoner.lube.physical.operators.ExpandInto.rdg(ExpandInto.scala:30)
        at com.antgroup.openspg.reasoner.lube.physical.operators.Drop.rdg(Drop.scala:24)
        at com.antgroup.openspg.reasoner.lube.physical.operators.Aggregate.rdg(Aggregate.scala:30)
        at com.antgroup.openspg.reasoner.lube.physical.operators.Drop.rdg(Drop.scala:24)
        at com.antgroup.openspg.reasoner.lube.physical.operators.Select.row(Select.scala:26)
        at com.antgroup.openspg.reasoner.runner.local.LocalReasonerRunner.doRun(LocalReasonerRunner.java:160)
        at com.antgroup.openspg.reasoner.runner.local.LocalReasonerRunner.run(LocalReasonerRunner.java:57)
        at com.antgroup.openspg.reasoner.runner.local.LocalReasonerMain.doMain(LocalReasonerMain.java:62)
        at com.antgroup.openspg.reasoner.runner.local.LocalReasonerMain.main(LocalReasonerMain.java:52)
Caused by: com.antgroup.tugraph.TuGraphDbRpcException: CypherException: ParserException: line 1:38 no viable alternative at input 'MATCH (s:SupplyChain_TaxOfCompanyEvent/'
        at com.antgroup.tugraph.TuGraphDbRpcClient$TuGraphSingleRpcClient.handleGraphQueryRequest(TuGraphDbRpcClient.java:437)
        at com.antgroup.tugraph.TuGraphDbRpcClient$TuGraphSingleRpcClient.handleCypherRequest(TuGraphDbRpcClient.java:444)
        at com.antgroup.tugraph.TuGraphDbRpcClient$TuGraphSingleRpcClient.callCypher(TuGraphDbRpcClient.java:645)
        at com.antgroup.tugraph.TuGraphDbRpcClient.callCypher(TuGraphDbRpcClient.java:86)
        at com.antgroup.openspg.cloudext.impl.graphstore.tugraph.TuGraphStoreClient.queryRecord(TuGraphStoreClient.java:109)
        ... 15 common frames omitted
2024-02-20 12:08:54,887 [] [] [main] ERROR c.a.o.r.r.l.LocalReasonerMain - KGReasonerLocalRunner,error:com.antgroup.tugraph.TuGraphDbRpcException: CypherException: ParserException: line 1:38 no viable alternative at input 'MATCH (s:SupplyChain_TaxOfCompanyEvent/'

看报错是spg向tugraph请求的查询语句为(s:SupplyChain_CompanyEvent)-[e:SupplyChain_CompanyEvent__belongTo__SupplyChain_TaxOfCompanyEvent]->(o:SupplyChain_TaxOfCompanyEvent/成本上涨)
tugraph接收这样的语句时会报错。
请问是否是我的dsl语句有误，还是spg的bug？

不好意思，目前还未支持直接到概念根节点的推理，正在开发中

现在只能指定到具体的概念实例例如
knext reasoner execute --dsl "
MATCH
(o:SupplyChain.CompanyEvent)-[e:belongTo]->(c:SupplyChain.TaxOfCompanyEvent/成本上涨)
WHERE o.subject='CSF0000000002'
RETURN
o.id,o.subject,o.name,o.belongTo,o.leadTo,o.index,o.trend
"

现在只能指定到具体的概念实例例如 knext reasoner execute --dsl " MATCH (o:SupplyChain.CompanyEvent)-[e:belongTo]->(c:SupplyChain.TaxOfCompanyEvent/成本上涨) WHERE o.subject='CSF0000000002' RETURN o.id,o.subject,o.name,o.belongTo,o.leadTo,o.index,o.trend "

还请再帮忙看一下。这条语句的语法好像不对T T

现在只能指定到具体的概念实例例如 knext reasoner execute --dsl " MATCH (o:SupplyChain.CompanyEvent)-[e:belongTo]->(c:SupplyChain.TaxOfCompanyEvent/成本上涨) WHERE o.subject='CSF0000000002' RETURN o.id,o.subject,o.name,o.belongTo,o.leadTo,o.index,o.trend "

还请再帮忙看一下。这条语句的语法好像不对T T

knext reasoner execute --dsl " MATCH (o:SupplyChain.CompanyEvent)-[e:belongTo]->(c:SupplyChain.TaxOfCompanyEvent/成本上涨) WHERE o.subject='CSF0000000002' RETURN o.id,o.subject,o.name,o.belongTo,o.leadTo,o.index,o.trend

了解了，感谢解答~

repo: OpenSPG/openspg


text:
"upload tracks" button too smal if language selected is german and browser is Chrome

If I select german as the language, this is how the track upload looks:

I am using Chrome; it appears that with IE, the problem does not exist..

Fixed translation

authors: cleanerx wschildbach


text:
Tooltipps for Buttons and Icons

everywhere :P
Description

In the user interface, many buttons/icons do not have a tooltip. Therefore, it is not immediately obvious to (new) users what function/action a button has.
In most cases, you first have to click on the button to find out...

Expected behaviour

All buttons have tooltips
When hovering over the icon with the mouse, it should become noticeable as a button as intended, i.e. it should have a dark background (cf. icon tile view or save button for groups).
If possible, create tooltips with "[edit module]" so that user-defined translations work and you do not have to conjugate in German.

List

For easier handling, we have created a table: Sammlung-Tooltips-Icons.ods
This shows which icon/button should be provided with which tooltip (German and English for now).

If you have any questions, please contact Katharina. :)

Like @bastianjoel said in #2407 the tooltip for "Create new change recommendation" cannot be implemented right now
#2407 is only adding some tooltips, the still missing tooltips can be viewed in the updated file.
In the file; line 26ff. shows which edit symbol already has the tooltip
Sammlung-Tooltips-Icons.ods

authors: Elblinator alveolus

repo: OpenSlides/openslides-client


text:
Add STLayout missing properties and rename it in the editor

Rename "STLayout" to "Proportional" in the editor view.

Additionally, include all properties such as offset (left, right, bottom, top) and proportion (left, right, bottom, top).
May be others ?

[ ] Rename "StLayout" to "Proportionnal"
[ ] Add missing constraints on "Proportionnal"
[ ] Add BlFrameLayout
[ ] Add missing constraints on "BlFrameLayout" (alignLeft alignLeftAt: alignCenter alignCenterAt: alignRight alignRightAt: alignNull | alignTop alignTopAt: alignCenter alignCenterAt: alignBottom alignBottomAt: alignNull )
[ ] Add BlLinearLayout
[ ] Add missing constraints on "BlLinearLayout"

repo: OpenSmock/Pyramid


text:
re-runnning results leads to 500 error

I get a dynamic result
http://www.ospc.org/dynamic/behavior_results/21/
Then I click "edit parameters"
http://www.ospc.org/dynamic/behavioral/edit/21/?start_year=2016
Then I try to rerun the simulation:
http://www.ospc.org/dynamic/behavioral/21/?start_year=2016
And I get a 500 internal server error.
This problem does not exist for the static model. I am not sure if it does for the macro elast model; I haven't checked that yet.
cc @talumbau @mistakevin

resolved via https://github.com/OpenSourcePolicyCenter/webapp-public/pull/190

authors: MattHJensen talumbau

repo: OpenSourcePolicyCenter/webapp-public


text:
Build failure

Attempting to build the process by your docs I get the following error:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.259 s
[INFO] Finished at: 2016-07-15T11:30:53-06:00
[INFO] Final Memory: 30M/271M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar (attach-javadocs) on project asynccassandra: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - /bin/sh: scl: line 1: syntax error: unexpected end of file
[ERROR] /bin/sh: error importing function definition for `BASH_FUNC_scl'

This happens when I just run mvn clean package in the root "asynccassandra" directory.

Removing the javadoc portion of the pom.xml lets the project build successfully.

repo: OpenTSDB/asynccassandra


text:
[Feature request] 封禁举报用户

Transfer from https://github.com/DanXi-Dev/DanXi/issues/204 .
此Issue搬运自飞书原《功能需求和bug修复建议》文档
备注
因为有人在举报区人身攻击管理、滥用举报等，希望限制其使用举报功能、或者封禁
提出部门
社区运营部

搬运自原文档下评论
来自 Eric 同学：目前滥用举报的主要表现有：1)错把举报当回复（少数）2)举报的理由根本就不出自于社区公约3)辱骂管理员4)泄愤式举报。我的一个想法是，请求后端的同学把举报栏改成单选题的模式，限制用户只能从公约的条款中选择，而不是打字。这样可以解决前三者，也能够引导用户注意社区公约。
封禁举报用户有助于解决上述第4）点

9dade79a284857266759ec06deb74ff6769170d1 已完成

authors: JingYiJun QLTyrone w568w


text:
[BUG] cpu usage keeps increasing until crash

when using any audio transformer plugin the cpu usage will continuously increase
replicated with ggwave and fasterwhisper lang detect plugins
reported by @builderjer  and verified by @goldyfruit

ovos-dinkun-listener never really crashes, process still up and "running" but there is no wakeword detection.

please test with https://github.com/OpenVoiceOS/ovos-plugin-manager/pull/234
i havent diagnosed the error, but both me an @mikejgray reached the conclusion it must be on that code, so maybe its fixed by the general improvements in that PR

Where I noticed the bug the first time was when testing ovos-transformer-plugin-ggwave.  When it was enabled and automatically started, CPU usage would continually rise.  First indications were at about 5 minutes.  By 15 minutes, CPU was at 100 and OVOS was unusable.
Testing now, with https://github.com/OpenVoiceOS/ovos-plugin-manager/pull/234 , it seems to have fixed the problem.  I have had ggwave transformer running for 45 minutes and no CPU increase.

This is not fixed.  After a full day of being activated, my device crashed and it has to do with ovos-ggwave-listener.  CPU usage still rises, just not near as fast.

can you replicate with the faster whisper lang detect? just to be sure it isnt a different issue with ggwave plugin itself
  "listener": {
    "audio_transformers": {
        "ovos-audio-transformer-plugin-fasterwhisper": {
            "model": "small"
        }
    }
  }

Going to close this and open in ovos-audio-transformer-plugin-ggwave.
With the  above configuration, I have had no issues for over 24 hrs

authors: JarbasAl builderjer goldyfruit

repo: OpenVoiceOS/ovos-dinkum-listener


text:
ERC-721 tokens / note about ERC-165

Please add a note to the ERC-721 implementation that it is incomplete and should not yet be used.
At present, the OpenZeppelin implementation does not support ERC-165, which is required by the ERC standard.

I have added ERC165 to a project I am working with which uses the latest open zeppelin ERC721, this is what I ended up with:
  bytes4 constant InterfaceSignature_ERC165 =
    bytes4(keccak256('supportsInterface(bytes4)'));

  bytes4 constant InterfaceSignature_ERC721Enumerable =
    bytes4(keccak256('totalSupply()')) ^
    bytes4(keccak256('tokenOfOwnerByIndex(address,uint256)')) ^
    bytes4(keccak256('tokenByIndex(uint256)'));

  bytes4 constant InterfaceSignature_ERC721Metadata =
    bytes4(keccak256('name()')) ^
    bytes4(keccak256('symbol()')) ^
    bytes4(keccak256('tokenURI(uint256)'));

  bytes4 constant InterfaceSignature_ERC721 =
    bytes4(keccak256('balanceOf(address)')) ^
    bytes4(keccak256('ownerOf(uint256)')) ^
    bytes4(keccak256('exists(uint256)')) ^
    bytes4(keccak256('approve(address,uint256)')) ^
    bytes4(keccak256('getApproved(uint256)')) ^
    bytes4(keccak256('setApprovalForAll(address,bool)')) ^
    bytes4(keccak256('isApprovedForAll(address,address)')) ^
    bytes4(keccak256('transferFrom(address,address,uint256)')) ^
    bytes4(keccak256('safeTransferFrom(address,address,uint256)')) ^
    bytes4(keccak256('safeTransferFrom(address,address,uint256,bytes)'));

  /**
   * @notice Introspection interface as per ERC-165 (https://github.com/ethereum/EIPs/issues/165).
   * @dev Returns true for any standardized interfaces implemented by this contract.
   * @param _interfaceID bytes4 the interface to check for
   * @return true for any standardized interfaces implemented by this contract.
   */
  function supportsInterface(bytes4 _interfaceID) external view returns (bool)
  {
    return ((_interfaceID == InterfaceSignature_ERC165)
      || (_interfaceID == InterfaceSignature_ERC721)
      || (_interfaceID == InterfaceSignature_ERC721Enumerable)
      || (_interfaceID == InterfaceSignature_ERC721Metadata));
  }

Not entirely sure if this should cover it?

@jamesmorgan would it not make more sense to have the derivation in comments and the final value as a constant static string?

@DanielRX yes this makes sense, I was more demonstrating my first pass at a solution. Not entirely sure of the cost saving but it's probably worth doing.
This is what it looks like using statics:
  bytes4 constant InterfaceSignature_ERC165 = 0x01ffc9a7;
    /*bytes4(keccak256('supportsInterface(bytes4)'));*/

  bytes4 constant InterfaceSignature_ERC721Enumerable = 0x780e9d63;
    /*
    bytes4(keccak256('totalSupply()')) ^
    bytes4(keccak256('tokenOfOwnerByIndex(address,uint256)')) ^
    bytes4(keccak256('tokenByIndex(uint256)'));
    */

  bytes4 constant InterfaceSignature_ERC721Metadata = 0x5b5e139f;
    /*
    bytes4(keccak256('name()')) ^
    bytes4(keccak256('symbol()')) ^
    bytes4(keccak256('tokenURI(uint256)'));
    */

  bytes4 constant InterfaceSignature_ERC721 = 0xcff9d6b4;
    /*
    bytes4(keccak256('balanceOf(address)')) ^
    bytes4(keccak256('ownerOf(uint256)')) ^
    bytes4(keccak256('exists(uint256)')) ^
    bytes4(keccak256('approve(address,uint256)')) ^
    bytes4(keccak256('getApproved(uint256)')) ^
    bytes4(keccak256('setApprovalForAll(address,bool)')) ^
    bytes4(keccak256('isApprovedForAll(address,address)')) ^
    bytes4(keccak256('transferFrom(address,address,uint256)')) ^
    bytes4(keccak256('safeTransferFrom(address,address,uint256)')) ^
    bytes4(keccak256('safeTransferFrom(address,address,uint256,bytes)'));
    */

@fulldecent updated comment above to reflect this 👍

@emkman exists(uint256) was never in the draft or standard. OZ decided to include this function as a proprietary extension to the standard.
FYI, proprietary extensions are good. If something provides utility to you, then use it!

"Proprietary" is not the right word in this context. It's just an extension to the standard.

authors: DanielRX frangio fulldecent jamesmorgan

repo: OpenZeppelin/zeppelin-solidity


text:
Barrage support damage calculation incorrect

When adding the barrage support to a skill, it decreases the attack damage without taking into account the extra arrows being fired, so dps basically gets cut by 68-62%

I would like to add that it also does not include the "5% more Attack Time per Projectile" in the calculation

authors: DanielGillies Xhipias

repo: Openarl/PathOfBuilding


text:
6.0 Feedback:  Software upgrade is available is displayed for unavailable robots

Overview
Software upgrade banner is displayed for unavailable robots
Current Behavior

Expected Behavior
upgrade banner should not be available
Steps To Reproduce

Robot server is not running
it is displayed in the Unavailable robot section, with the software update is available banner
Similar behavior is seen with robot OT2 where the app goes unavailable after the upgrade, and OT2 appears in the unavailable section - still displaying the software upgrade banner

Operating system
No response
Robot setup or anything else?
No response

Then turned off the robot

repo: Opentrons/opentrons


text:
Nothing gets generated

Configured everything as described. Everything seems to work, because:

If there's a syntax error in the SQL migration, the build fails (so Flyway works)
If Docker is down, the build fails (so Docker works)
On a first build, I first see a couple of connection failures, and eventually the build continues without error (so Postgres is online)
Gradle says the generate step completed. When I change something in the migration, I can see the generation step is not up to date

However, no code gets generated. Now what?

Hi,
Do you define the group in your gradle script?
Here's a working example for reference: https://github.com/Optravis-LLC/jooq-gradle/blob/60666c498dbc279bda53f82aba79b02f24e6ddd7/examples/default_config/build.gradle.kts#L7
If it's not that, then it would be nice if you can try to provide a minimal reproducer, as I don't see why the task would be successful (and not up-to-date) without generating code.

Thanks for your quick reply!

The group was missing in my Gradle script indeed.
But I also needed to set the DB schema, using: jooqDbConfig = JooqDatabaseConfig.postgres(schema = "myschema")

Anyway, it works now. Awesome! Thanks for your help.

authors: bartkummel jcornaz

repo: Optravis-LLC/jooq-gradle


text:
added pipes policy

Proposed changes

[x] added pipes policy

Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (changes to code, which do not change application behavior)

Checklist

[ ] I have filled out this PR template
[ ] I have read the CONTRIBUTING doc
[ ] I have added automated tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (README.md, inline comments, etc.)
[ ] I have updated the CHANGELOG.md under a ## next release, with a short summary of my changes

Relevant Links

Further comments

/azp run

/azp run

repo: Optum/dce


text:
Dropdown: min-width on toggle-split dropdown

Have the same width for every .dropdown-toggle-split. Maybe a better solution could be to set a width and remove padding-x.

@louismaximepiton Could you complete the description to explain what this PR fixes or what this modification is needed for? Not sure to understand the context.

authors: julien-deramond louismaximepiton


text:
Fix duplicate items when using url anchors

This pull request fixes an issue with items appearing twice when using anchors. The previous patch, #1, was missing a check on initialTeam to apply the active class for the default team's div.

Thanks Paul


text:
"typeface" conflicts with support libraries

use of the "app:typeface" attribute for custom views is clashing with other libraries who use the same attribute name.
This is a known issue with the platform and with the build tools that these clashes cause issues. The recommended fix is that libraries prefix their attribute names with initials to avoid collisions, e.g. "app:lp_typeface"
example here: https://github.com/rengwuxian/MaterialEditText/issues/122

Any follow-up on this issue? I submitted a PR to resolve the conflict, though anyone moving to the new version will possibly need to update their code if they add any custom layouts

fixed in com.github.orangegangsters:lollipin:1.2.2@aar

repo: OrangeGangsters/LolliPin


text:
TestEnvironment - Update to Thread the WebDriver for performance increase

Update the following
protected OrasiDriver driver;

To use below instead
protected ThreadLocal<OrasiDriver> driver = new ThreadLocal<OrasiDriver>();

At the same time, the additional threaded webDriver and driver hashmap can now be removed as cleanup and making things less confusing.

Due to the way TestNG handles threading, only having the option of a ThreadLocal driver is not good as running parallel methods or instances can result in the driver being stuck in the main thread (if generated in a @BeforeMethod or @BeforeTest) and not be reachable in the TestNG sub-threads. To accommodate this, the option to give the user the ability to thread the driver now exists.
The method setThreadDriver(boolean setThreadDriver) will be used to set internal threading. If the user wants TestNG to control the threads,then nothing needs to be done, by default this is false. If the user want to turn on threading for threading @Test, then setThreadDriver(true). This is only used if the "startTest" method is called inside a @Test. Otherwise, using parallel="methods" will achieve the same result if startTest is called inside a @Before method.
Will revisit in the future to determine if using reflection is possible to determine where "startTest" was called, whether it be in the main @Test or a @Before method. This will take away the need for the user to choose between TestNG threads or WebDriver threads, it would be handled automatically.

repo: Orasi/Selenium-Java-Core


text:
.NET 6.0 application bootstrapping

As suggested by @jhgbrt
It would be a good thing to use the new way of bootstrapping the application in .NET 6.0
Maybe there is a way to use it even if we are multi-targeting frameworks on the CI.

@DAud-IcI please confirm that this is addressed by https://github.com/OrchardCMS/OrchardCore.Commerce/pull/119

Nope, SampleWebApp still uses the generic host builder style. #119 didn't do functional changes unless it seemed necessary.

Maybe there is a way to use it even if we are multi-targeting frameworks on the CI.

What other frameworks do you have in mind, @Skrypt ? I think we only need to target .Net 6, becuase that's what OC 1.3 requires.

Even though we currently only target net6.0 when net7.0 will be out we will probably multi-target to keep an LTS version in the build pipeline. So, you need to keep in mind that we are going to eventually multi-target.

Yes, that makes sense. I just got confused, becuase the new style application boostrapping should be forward-compatible so .Net 7 wouldn't have any effect on the issue topic.
We could take a look at multi-targeting with the 7.0.0-preview.3 SDK (in a container, becuase installing preview SDKs on bare metal is never a good time). But that should be a separate issue, I think.

I believe this is why we dropped net3.1 and net5.0.

Looks like this was done during https://github.com/OrchardCMS/OrchardCore.Commerce/issues/212#issuecomment-1285748447 (see the diff here)

authors: DAud-IcI Skrypt barthamark sarahelsaig


text:
(1.12.2) Serene Seasons Compat (Again) - Savanna Not Receiving Rain In Mid Wet Season

An extension of the previous Serene Seasons issue: jungles behave as they should, not receiving rain in mid dry season (even variants like Traverse's mini jungle behave correctly), but savannas still don't receive rain in mid wet season. Stranger still is that other hot tropical biomes, like Traverse's badlands biome, DOES receive rain in mid wet season, so I'm not sure what's doing on here.
Also, quick addition, deserts (and variants like the mesa or Traverse's desert shrubland and red desert) get rain as they should, but they don't play the correct sounds, instead just getting wind with no rain sounds.
DS: 3.4.9.13
Serene Seasons: 1.1.5
Forge: 14.23.3.2678

Does savanna rain work without DS?

Yes they do. Also, with DS installed, rain droplets appear under trees in the savanna biome when it should be raining. Is there some override for the savanna's weather in the code or in one of the json files perhaps?

No - it's something in my code.  I have to rearrange the check sequence so that tropical seasons get first crack before evaluating for dust.  Question on deserts - should there be dust storms during MID_DRY?

Could you be more specific?

There is a mid dry season for deserts.  Current code says not to do any precipitation effect rendering thus preventing dust storms or rain during that sub season.  My thought was to leave as is.

So an extra weather variant for the deserts, meaning you get nothing in mid dry season? Sure, keeps it varied.

Yep.  So what is going to happen in deserts is:

MID_WET - it will have rain.  Water rain.
MID_DRY - there will be no weather rendering.
Any other season it would have dust storms.

Yeah, that keeps it interesting, makes it feel like the seasons are progressing. Also, watery rain is my favourite type of rain.

For Savanna it will be able to rain during the wet season, and no rendering will take place for the other seasons.

Mid wet season only, right?

Yep.
On Sat, May 5, 2018 at 2:03 PM, TechnoMysterio notifications@github.com
wrote:

Mid wet season only, right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OreCruncher/DynamicSurroundings/issues/332#issuecomment-386834824,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGS7xqbwa2Kd2lHkCu02juD6py_qF6fks5tvhOQgaJpZM4TzxUF
.

Just came here to report the drips from trees issue. Glad to see it's already fixed.

That was what I was referring to, yes. By the way, did you look in the rain sound not playing in rainy deserts?

Rainy deserts - yes.  I think I have all that resolved as well.

Pushed v3.4.9.14 with changes.

repo: OreCruncher/DynamicSurroundings


text:
System.MissingMethodException: Method not found: 'Void Orleans.Runtime.Logger.Error(Int32, System.String, System.Exception)

Hi,
I am trying to use this with the latest Orleans v1.3.0-beta1. However I am getting this stacktrace whenever I try to start Orleans... is this versioning issue?
OrleansHost.exe Error: 0 : [2016-09-16 12:53:36.354 GMT    15	ERROR  	103109	ProviderLoader/IStorageProvider	127.0.0.1:11111]	!!!!!!!!!! Exception initializing provider Name=PubSubStore Type=[PubSubStore, Orleans.StorageProviders.SimpleSQLServerStorage.SimpleSQLServerStorage]
Exc level 0: System.MissingMethodException: Method not found: 'Void Orleans.Runtime.Logger.Error(Int32, System.String, System.Exception)'.
   at Orleans.StorageProviders.SimpleSQLServerStorage.SimpleSQLServerStorage.<Init>d__14.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Orleans.StorageProviders.SimpleSQLServerStorage.SimpleSQLServerStorage.Init(String name, IProviderRuntime providerRuntime, IProviderConfiguration config)
   at Orleans.Providers.ProviderLoader1.<InitProviders>d__6.MoveNext()

OrleansHost.exe Error: 0 : [2016-09-16 12:53:36.376 GMT     1	ERROR  	100439	Silo	127.0.0.1:11111]	!!!!!!!!!! Exception during Silo.Start
Exc level 0: System.AggregateException: One or more errors occurred.
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait(TimeSpan timeout)
   at Orleans.OrleansTaskExtentions.WaitWithThrow(Task task, TimeSpan timeout)
   at Orleans.Runtime.Silo.DoStart()
   at Orleans.Runtime.Silo.Start()
Exc level 1: System.MissingMethodException: Method not found: 'Void Orleans.Runtime.Logger.Error(Int32, System.String, System.Exception)'.
   at Orleans.StorageProviders.SimpleSQLServerStorage.SimpleSQLServerStorage.<Init>d__14.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Orleans.StorageProviders.SimpleSQLServerStorage.SimpleSQLServerStorage.Init(String name, IProviderRuntime providerRuntime, IProviderConfiguration config)
   at Orleans.Providers.ProviderLoader`1.<InitProviders>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---

I assume you are using the nuget package.  The stable package is linked to the 1.2.x release.
Here is a nuget package linked to 1.3.0-beta1.
https://ci.appveyor.com/api/buildjobs/to34ikblh7mrg28d/artifacts/Orleans.StorageProviders.SimpleSQLServerStorage.1.2.77-ffxxhxjd.nupkg.

Yes I was using nuget package... I will try out the latest nuget beta once I can get back to it... cheers...

going to close this as is regarding the beta

authors: amccool rosdi


text:
Manual approval required for workflow run 5433321811: Approve deploy to staging

Workflow is pending manual review.
URL: https://github.com/OrtDevOps-obli-2023/fe-angular/actions/runs/5433321811
Required approvers: [SebaORT JNMiguel]
Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

yes

All approvers have approved, continuing workflow and closing this issue.


text:
🛑 Autogestion is down

In ca8d4cc, Autogestion (https://autogestion.osdop.org.ar/Account/LogOn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Autogestion is back up in b97bb47.

repo: Osdop/upptime


text:
🛑 ClipArt is down

In af4cf74, ClipArt (https://clipart.me) was down:

HTTP code: 502
Response time: 93 ms

Resolved: ClipArt is back up in 4fef278.

repo: OsintUK/Up-or-Down


text:
🛑 Bitify is down

In a779df9, Bitify (https://bitify.com) was down:

HTTP code: 503
Response time: 281 ms

Resolved: Bitify is back up in e5113a0.


text:
feat: add in operator in fetch query core service

API PR Checklist
Pre-requisites

[x] I have gone through the Contributing guidelines for Submitting a Pull Request (PR) and ensured that this is not a duplicate PR.
[ ] I have performed preliminary testing using the test suite to ensure that any existing features are not impacted and any new features are working as expected.
[x] I have updated the required api docs as applicable.
[ ] I have added/updated test cases to the test suite as applicable

PR Details
PR details have been updated as per the given format (see below)

[x] PR title adheres to the format specified in guidelines (e.g., feat: add admin login endpoint)
[x] Description has been added
[ ] Related changes have been added (optional)
[ ] Screenshots have been added (optional)
[ ] Query request and response examples have been added (as applicable, in case added or updated)
[ ] Documentation changes have been listed (as applicable)
[ ] Test suite output is added (as applicable)
[ ] Pending actions have been added (optional)
[ ] Any other additional notes have been added (optional)

Additional Information

[x] Appropriate label(s) have been added (ready for review should be added if the PR is ready to be reviewed)
[x] Assignee(s) and reviewer(s) have been added (optional)

Description:
Added 'in' operator in fetch query core service
Related changes:
N/A
Screenshots:
N/A
Query request and response:
N/A
Documentation changes:
N/A
Test suite output:
N/A
Pending actions:
N/A
Additional notes:
N/A

Summary by CodeRabbit

Bug Fixes

Improved handling of filter values in the CoreService to ensure correct parsing of 'in' operator values as arrays.

@sujoy-pal144 The current IN operator implementation does not seem to work as expected. Except on the field id, all other fields are returning wrong results.
Also, we need to handle the case when we are passing strings in the in operator value. For example, for createdBy or updatedBy
Please test this locally and resolve the issues.

@sujoy-pal144 Please update the request and response in the PR description so we know what cases you tried with the in operator.
Also, looking at the code, I don't know if I really follow the approach used. If the values are already a string, separated by commas, can we not just pass it directly pass it in the query statement?
Any particular reason to convert it into an array first and then spread it back out?

repo: OsmosysSoftware/osmo-x


text:
Add client login and basic error handling

Added basic client functionality

About the two functions returning a u8 to signal an error: It's ok to handle the error inside those functions (= tell the user what happened). But instead of returning u8, you should return a bool.
It would be more "rusty" to return some kind of Result, but I can't find a real reason why this would be better in this scenario. So just make the u8 to bool and it should be ok.

Your functions are pretty indented... I would suggest using a slightly different style to keep it "flatter". Instead of
    let status = buf.read_u8();
    match status {
        Ok(st) => {
            // stuff with st
        },
        Err(_) => return 1
    }

I would write
    let status = buf.read_u8();
    let st = match status {
        Err(_) => return 1,
        Ok(st) => st,
    };
    // stuff with st

You can always pull stuff out... More early returns:
if st != Cnv::GreetPkg as u8 {
    println!("Communication mismatch. Try again later.");
    return 1;
} else {
    // stuff
}

This is the same as
if st != Cnv::GreetPkg as u8 {
    println!("Communication mismatch. Try again later.");
    return 1;
}
// stuff

Think about using this style. Makes it less complicated to comply with the 80 char rule.

authors: LukasKalbertodt SvantjeJung

repo: OsnaCS/uosql-server


text:
🛑 Oswald Labs Blog is down

In cb88ff6, Oswald Labs Blog (https://blog.oswald.foundation) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Oswald Labs Blog is back up in 67100a7.

repo: OswaldLabsOpenSource/status


text:
🛑 Oswald Labs Blog is down

In 989a452, Oswald Labs Blog (https://blog.oswald.foundation) was down:

HTTP code: 429
Response time: 625 ms

Resolved: Oswald Labs Blog is back up in 2614d81.


text:
Anuclim

Pull Request Checklist:

[x] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #411

[x] Tests for the changes have been added (for bug fixes / features)
[x] Documentation has been added / updated (for bug fixes / features)
[ ] HISTORY.rst has been updated (with summary of main changes)
[ ] bumpversion (minor / major / patch) has been called on this branch
[ ] Tags have been pushed (git push --tags)

What kind of change does this PR introduce?
Adds functions for a subset anuclim bioclimatic indicators  (those based on temp and precipitation

Does this PR introduce a breaking change?
No

Other information:
Docs strings have been added but we could possibly add an automodule .rst similar to ICCLIM?

Pull Request Test Coverage Report for Build 1866

161 of 169 (95.27%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.9%) to 77.317%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

xclim/indices/_anuclim.py
152
160
95.0%

Totals

Change from base Build 1865:
0.9%

Covered Lines:
2645

Relevant Lines:
3421

💛  - Coveralls

There was a bug in _get_from_other_extreme that I fixed. Also, added tests using dask to TestTempWetDryPrecipWarmColdQuarter . However, we still have problems : when input_freq='daily' and the data is stored in a dask array, the preliminary resampling operation will create small chunks along 'time' and the resample will fail as the chunks are smaller than half the window size... I skipped those tests for now, as the user can easily do the resampling and rechunk before.

Shouldn't we use 'D', 'W' and 'M' for input_freq? One day, we might use a xr.infer_freq to fill this field automatically and that function will return one of those. And we could test with : input_freq.startswith('D').

2. Shouldn't we use 'D', 'W' and 'M' for `input_freq`? One day, we might use a `xr.infer_freq` to fill this field automatically and that function will return one of those. And we could test with : `input_freq.startswith('D')`.

It would be good if we followed xarray/pandas-like time_freq conventions as closely as possible. I wonder if there are any helper functions from those libraries that we can lean on...?

Shouldn't we use 'D', 'W' and 'M' for input_freq? One day, we might use a xr.infer_freq to fill this field automatically and that function will return one of those. And we could test with : input_freq.startswith('D').

It would be good if we followed xarray/pandas-like time_freq conventions as closely as possible. I wonder if there are any helper functions from those libraries that we can lean on...?

ok. good call.  I think eventually we would like to see a version where input_freq isn't event there and we get the frequency via xr.infer_freq.  However, it currently doesn't support non-standard calendars so this was a work-around

@tlogan2000 Would you be upset if I did a find and replace for dryest to driest ?

@tlogan2000 Would you be upset if I did a find and replace for dryest to driest ?

haha. ok with me.  I had actually coded driest everywhere while @aulemahal had 'dryest'.  I went with 'dryest' as I was not sure what non-native english speakers would be expecting and personally it was  either/or

I had the impression that dryest was an out-west cowboy colloquial spelling, haha.

I had the impression that dryest was an out-west cowboy colloquial spelling, haha.

Websters doesn't seem to have 'dryest' so I guess driest would be the most correct

There was a bug in _get_from_other_extreme that I fixed, my bad. Also, added tests using dask to TestTempWetDryPrecipWarmColdQuarter . However, we still have problems : when input_freq='daily' and the data is stored in a dask array, the preliminary resampling operation will create small chunks along 'time' and the resample will fail as the chunks are smaller than half the window size... I skipped those tests for now, as the user can easily do the resampling and rechunk before.

Would this be a problem for all the 'wetdry'/'warmcold' quarter indices?  i.e. anything with a rolling or is it specific to those using the sub function?

Would this be a problem for all the 'wetdry'/'warmcold' quarter indices? i.e. anything with a rolling or is it specific to those using the sub function?

It's specific to the indices resampling daily to weekly and then calling a xr.apply_ufunc, so right now only the cross-indices (tas of driest, pr of warmest and so on).

out-west cowboy colloquial spelling
Sadly, it was only keb engrish.

In tg_mean_warmcold_quarter, if input_freq is daily, why not set wind to 13*7 ?

Also, the dosctring should probably mention that the freq should include an offset to avoid chopping the warmest quarter in 2 (e.g. AS-JUL) if you're in the SH.

Also, the dosctring should probably mention that the freq should include an offset to avoid chopping the warmest quarter in 2 (e.g. AS-JUL) if you're in the SH.

Right.  This will affect my mapping...  I mapped most as partial with freq='YS'.  ..  Might therfore need to make sure that input freq is annual for some indices (seasonality at the very least)

In tg_mean_warmcold_quarter, if input_freq is daily, why not set wind to 13*7 ?

This would be fine as well.  Initial thought was to try reproduce anuclim output as closely as possible but maybe we don't want to force ourselves to accept their 'weekly' input limitation

So I wrote a _quarter function that could be reused in a couple of indices. I tested it on two of them, I'll let you decide if you want to use that or not. If we decide to change the behavior, then there is only one place it would change.

I think you could simplify the logic by using "min", "max" as the op.

Woups! We implemented different methods at the same time. But they were easily merged. I moved the "from_other" lazy indexing machinery to xclim.indices.run_length.lazy_indexing that can now accept ND inputs. (and to do so, changed _np_argops to _xr_argops.  For reference, the new way was 1.5x faster on my machine.
Also, propagated your fix (@huard ) to prcptot_warmcold_quarter.

@aulemahal Cyclical import issue possibly due to:
xclim/sdba/__init__.py:1:0: R0401: Cyclic import (xclim -> xclim.core.options -> xclim.locales -> xclim.core.formatting) (cyclic-import)

authors: Zeitsperre aulemahal coveralls huard tlogan2000

repo: Ouranosinc/xclim


text:
Address docs warning

Pull Request Checklist:

[ ] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #xyz

[ ] (If applicable) Documentation has been added / updated (for bug fixes / features).
[ ] (If applicable) Tests have been added.
[ ] CHANGELOG.rst has been updated (with summary of main changes).

[ ] Link to issue (:issue:number) and pull request (:pull:number) has been added.

What kind of change does this PR introduce?

Conditionally creates a folder to squelch a build-failing warning in ReadTheDocs.

Does this PR introduce a breaking change?
No.

coverage: 23.077%. remained the same
when pulling afc7c19cefdb1e47fc4ecea2fca93e4cfd2ea363 on enable-docs
into 4c8319e5f7f07355635271fed1ee8d5f24b0697e on main.

authors: Zeitsperre coveralls

repo: Ouranosinc/xsdba


text:
Improve CircleCI build coverage

Currently CircleCI builds with a single compiler, and only does branch builds. It does them much faster than other CI solutions though, and with less hassle to keep things updated.
Recently, in #225, the Dockerfile used by CircleCI was updated to support building with either GCC or Clang. This work can be extended to do concurrent builds with both GCC and Clang. I believe the proper way to configure this is with Workflows.
Another area of improvement, is doing pull request builds, that test the result after a branch would be merged to master (or the pull request base branch). This means no surprises after merging. This could be done in addition to branch builds, which test branch changes in isolation from other development on master. To perform a PR build, the checkout step would need to be updated to put the source tree in a state after a merge.
Of course if this can be done on CircleCI, that may make some of the TravisCI builds redundant. In that case, we could potentially retire the redundant builds.

Closing issue.
PR #227 added a second build so we cover both GCC and Clang, so that part is done.
PR #333 removed support for TravisCI.
The other idea was to add pull request builds, which I don't think we should bother with. They add significantly to the test build time without adding significant test value. In particular, there isn't much concurrent activity on this project, and PR builds only provide value when changes have been merged to master after the current branch was branched off. Lately work is largely serial, one branch at a time. Additionally, a PR build can be simulated by merging master into the branch and doing a branch build.


text:
Revert reworked Doomfist to OW1

Created by: MaxwellJung

Created by: MaxwellJung
https://workshop.codes/ZXJB4
Someone made dps doom in ow2 using workshop. I'm gonna see if we can just use their code. @snappycreeper
edit: I reviewed their entire codebase, and there's some stuff that I think I can improve on. I got permission from author to use their code as reference, but I think I can write their code better from scratch.

mentioned in merge request ow1_emulator_backup!68

mentioned in merge request ow1_emulator_backup!173

moved from ow1_emulator_backup#725

mentioned in issue ow1_emulator_backup#593

Created by: MaxwellJung
https://youtu.be/Cyw70jYlEU4
Video footage of old doomfist abilities for rerference


text:
"Disperse nodes" is not working for some schemes

👋 Thanks for the great tool.
I've tried to visualize a medium-sized schema and "disperse nodes" function failed with Cannot read properties of undefined (reading 'length') here - https://github.com/Ovyerus/prismaliser/blob/d0d9413c0bc1456f2d97ff34191a88706e43437a/util/layout.ts#L66
Incoming data shape -

If I update letters[i]! to something like letters[i] || "" it solves the problem and everything works great
https://github.com/Ovyerus/prismaliser/blob/d0d9413c0bc1456f2d97ff34191a88706e43437a/util/prismaToFlow.ts#L366
Not sure if that's the right way to address this issue.
Anyways, I've corrected it in my local version and am not blocked. Feel free to handle this issue when and as you prefer.

I implemented your change in be302d0711efa86a1fdc36b6456fd60008d08310!
If possible, would you be able to share the schema/a cut down example that caused this, to see if can understand the root cause and possibly come up with a better solution?

Check your mail, there should be a link to a gist with a problematic scheme.

Cheers, got it. I'll see what I can do about this.

authors: Ovyerus theKashey

repo: Ovyerus/prismaliser