text:
Change seed to accept unsigned long for c compatibility

When parsing arguments with the i format string ParseTupleAndKeywords returns an OverflowError on Uint32 values. I will correctly accept both Int32 and Uint32 seeds.

I'm grateful to you for commit. But, for two reasons, I opt for the format unit i.

Security concern. The format unit I does not check overflow. In realty it may be not a problem, since a variable seed is statically allocated and will be never overflown. But because C/C++ is very tricky, I'm still not sure.

Interface concern. By changing the format unit i to I, I place the burden of checking inputs on users. This might cause unfavorable issues which are hard to detect in some cases. For example, hash('foo', 2 ** 33) and hash('foo', 2 ** 34) return the same results without any notices.

If seeds within the range [2 ** 31, 2 ** 32) have imminent and important use cases, I will change the format unit. Until needed, though, I think it's safer to leave them untouched. It is just a design choice so your commit itself is quite reasonable. Again, I appreciate for your help.

Integer overflow and stack/heap overflow are two different things. The C standard guarantees that the storage size and alignment requirements are the same for any given signed integer type and its corresponding unsigned integer type. There can be no memory overflow here, it's not tricky at all and exactly why the C standards are useful. All integer overflow related security bugs stem from the use of integers in pointer arithmetic, eg to calculate offsets which are then used to index into arrays. None of this happens to this value and none of this will ever happen to this value.
The use case for this patch is correctness. Murmurhash3's function signature tells you it wants an unsigned int, the int you give it will be treated as such anyway. Document that the seed parameter is a 32-bit unsigned int and it is the user's responsibility to make sure he passes in a correct seed.

I was hoping to move some of our code from https://github.com/phensley/python-smhasher over to mmh3 and this is literally the only thing stopping me.

Because there is a growing need for the feature, I added unit tests/CI to ensure stability and merged this one. Thank you very much for your commit.

authors: dan-blanchard hajimes paulie-g pik


text:
Doesn't connect

The app does connect to the i3s, but nothing happens afterwards on chrome / mac.
On WebBLE on Ipad there is thrown an error message: "console.time is not a function" and
console.time("scrambo.initialize took")... is undefined...

any news why the "new 2019 version" can't connect?

source: gharchive/issue

authors: cartyfox popel

repo: hakatashi/smart-cube-timer

license: MIT

license_type: permissive

license_source: github-api


text:
Do not prevent files listing if ls/stat has error(s)

Changes
Fixes issue https://github.com/halcyon-tech/vscode-ibmi/issues/1299
This PR lets the getFileList method parse ls or stat output even if the call return code is not 0. Error output is reported as error notifications (one per error).
Checklist

[x] have tested my change
[x] eslint is not complaining
[x] for feature PRs: PR only includes one feature enhancement.

Thanks for the feedback @chrjorgensen, right on point as always 😊
The error when stat runs on an empty directory is gone again.
And I figured out that the error raised when opening a symlink to a directory using ls was occurring with /usr/bin/ls but not with /QOpenSys/pkgs/bin/ls. So I added ls to the connections' Remote Feature, looking in both locations in the event it's not found in /QOpenSys/pkgs/bin. I also reordered the locations in the Remote Feature so that /QOpenSys/pkgs/bin are used in priority over /usr/bin's.
Everything should be fine now. Let me know how it goes 😉

@sebjulliand Perfect - code works as requested. I especially like your ordering of the remote features, so the OSS tools are preferred over the PASE tools! 🚀
But why the commit e25aff2? It does not seem related to the ls/stat issue...?

Ugh, I activated the reorganize import on save action and those two were reorganize...so I thought it wouldn't hurt to have them pushed as well 😅

@sebjulliand What happened to the commit ffc5b92? Seems like it is not in the code anymore - did you do a merge/rebase on the master branch and forgot this?

Gasp, you're right! I did a rebase that went wrong apparently and I didn't merge this part properly. I restored it, it should be fine now.
Thank you and your keen eyes @chrjorgensen !

source: gharchive/pull-request

repo: halcyon-tech/vscode-ibmi


text:
Regex values in ignore don't seem to work

Hi there,
I'm working with the Tomorrow Agency where we're using Kit. I'm looking to prevent the templates/*.json files from being deployed but I'm not having success with the Regex pattern. Here's my kit.config.js:
module.exports = {
  ignore: [
    /templates\/.*[.]json/
  ],
}

However, I still see the JSON templates being uploaded when running kit deploy. This is with the ignore key in the top-level after module.exports. I've also tried with ignore nested within the individual environments and I see the same results there.
Other files are ignored if I add in the full path.
Kit version: 1.1.1
Is this a known issue? I'm happy to provide any other information that may help debugging, just let me know!
Thank you

Hey @MathewKostiuk We've just deployed 1.1.2 which should include this functionality. Can you try this again and let me know if the issue persists?

@maxrolon Thanks for the response! I've just tried this again with the updated version and it's working just as expected. kit.config.js is looking much better now!

@MathewKostiuk Awesome! In the future I can get back to you faster, sorry for the delay with this one.

authors: MathewKostiuk maxrolon

repo: halfhelix/Kit


text:
Auto restarts server

Overview
Automatically restarts docker container if container crashes

Should fix some parts of #115

@aschnapp it doesn't look like this brought the server back up for some reason. Even after triggering the server deployment it is still down.

authors: aneuhold aschnapp

repo: halomod/TheHaloMod-SPA


text:
🛑 Grafana1 is down

In 55fbfa0, Grafana1 (https://grafana1.jenshamann.solutions) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Grafana1 is back up in b7f053a after 7 minutes.

repo: hamannjens/upptime


text:
An issue about _gather

Hi,
The _gather() function in HMNet.py seems to have two return (return list_dst and return outputs, states). Is it correct for this function?
Besides, in the forward function, the _gather should have 3 return values (outputs1, outputs2, outputs3). However, no matter whether it's return list_dst or return outputs, states, neither matches the expected number of return values. I am confused about this function, could you please check it or give some explanation about the _gather function？

Hi,
Thanks for pointing out. The second return (return outputs, states) is the old code which is not used now and the first return (return list_dst) is correct. Now, I have removed the unused return.

Besides, in the forward function, the _gather should have 3 return values (outputs1, outputs2, outputs3). However, no matter whether it's return list_dst or return outputs, states, neither matches the expected number of return values. I am confused about this function, could you please check it or give some explanation about the _gather function？

In the forward function, the _gather function has 3 return values; The _gather function takes (output1, output2, output3) as the first argument, list_dst, updates it with (out1, out2, out3) based on gather_indices and time_idx, and returns updated list_dst, i.e. (output1, output2, output3).

I guess the idx_offset += len(list_keys) should be put before the return list_dst. Like the following code. But I am not sure.
    def _gather(self, list_dst, list_src, gather_indices, time_idx):
        time_indices = gather_indices['time']
        batch_indices = gather_indices['batch']
        assert len(time_indices) == len(batch_indices)
        destination = torch.arange(len(time_indices))

        mask = time_indices == time_idx
        src_indices = batch_indices[mask]
        dst_indices = destination[mask]

        for dst, src in zip(list_dst, list_src):
            dst[dst_indices] = src[src_indices]

        idx_offset += len(list_keys)
        return list_dst

 #       states = (idx_offset, z1, z2, z3)
 #       outputs = (out_z1, out_z2, out_z3)
 #
 #       return outputs, states

After comparing the hmdepth.py for depth and hmdet.py for detection. I guess the self.idx_offset += len(list_events) should be added before the return outputs. But I am not sure.
    def forward(self, list_events, list_image_metas, list_gt_bboxes, list_gt_labels, list_ignore_masks, init_states=True) -> Tensor:
        if init_states:
            self.idx_offset = 0

        # Gather gts for loss calculation
        gather_indices = self._identify_required_outputs_batch(list_gt_labels, self.idx_offset)
        print(gather_indices)
        out_image_metas  = self._gather(list_image_metas , gather_indices)
        out_gt_bboxes    = self._gather(list_gt_bboxes   , gather_indices)
        out_gt_labels    = self._gather(list_gt_labels   , gather_indices)
        out_ignore_masks = self._gather(list_ignore_masks, gather_indices)

        # Backbone
        features = self.backbone(list_events, list_image_metas, gather_indices, init_states=init_states, detach=True, fast_training=True)

        # Head
        loss, log_vars = self._forward_head(features, out_gt_bboxes, out_gt_labels, out_ignore_masks)

        # Make sure all parameters are involved in loss calculation
        loss = loss + sum([ 0. * params.sum() for params in self.parameters() ])

        outputs = dict(loss=loss, log_vars=log_vars, num_samples=len(out_image_metas))
        self.idx_offset += len(list_events)  # I guess the update for idx_offset should be added here
        return outputs

Yes, you are right. There should be self.idx_offset += len(list_events) added at the end of forward function.
But this may not solve the problem you are facing because idx_offset is always zero when trained without TBPTT.
idx_offset is only used to store the timestep index for second forward call in TBPTT training.

The idx_offset will not update during the whole training process. It means that the logical and to select the mask index will always be False (in the _identify_required_outputs in hmdet.py). This will cause the output of _identify_required_outputs_batch be empty.

The mask index should become True even when idx_offset is zero. The mask is computed as
mask = torch.logical_and(time_indices < len(list_gt), (time_indices + idx_offset) > self.backbone.warmup).
Then, time_indices < len(list_gt) is always True (we may not need this condition) and (time_indices + idx_offset) > self.backbone.warmup) become True when the time_indices exceeds the warmup steps.
So, I don't know why the gather indices become empty in your case.
Could you check if time_indices in logical and is empty or not?

Hi,
I found that the list_gt input to _identify_required_outputs is a list of length 40 (because TRAIN_DURATION = 200e3 and DELTA_T = 5e3).
However, the list_gt only has the first element that is not [None], as shown below.
# the value for list_gt
# only the first one is tensor[0], others are [None]
[[tensor([0], device='cuda:2')], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None]]

Therefore, the time_indices extracted in for tidx, gt_labels in enumerate(list_gt) is always be 1.
Since we didn't update the idx_offset (always 0), the (time_indices + idx_offset) will always be (1+0) and (time_indices + idx_offset) > self.backbone.warmup always be False.
Thereby, the mask is always tensor([False]), and time_indices is empty.
P.S. I use your providing code in experiments/detection/data/gen1to segment Gen1 dataset. I guess the segment duration is 1000 .
Because the _identify_required_outputs is called in _identify_required_outputs_batch, I am not sure whether the size of list_gt is related to the batch size. I set the batch size is 16 in  hmnet_B3_yolox.py. Because I didn't use single GPU, so the real batch size is 1 according to the code in train.py

Hmmm, there may be problem with data loading. The gen1.py crops training sequence so that the labels are placed at the last 25% of the cropped sequence. But in your case, the labels are placed at the beginning.
I also run the training of HMNet-B1 with --distributed and real batch size = 1, but I coluldn't reproduce the error.
In my case, the lsit_gt have labels around the last timesteps, which is expected behavior.
# @GPU0
[[None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [tensor([0], device='cuda:0')], [None], [None], [None], [None], [None], [None]]
# @GPU1
[[None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [tensor([0], device='cuda:1')], [None], [None], [None], [None]]
# @GPU2
[[None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [tensor([0, 0], device='cuda:2')], [None], [None], [None], [None], [None], [None]]
# @GPU3
[[None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [None], [tensor([0], device='cuda:3')], [None], [None], [None], [None], [None], [None]]

The command used:
python ./scripts/train.py ./config/hmnet_B1_yolox_debug.py --amp --distributed --overwrite

Thank you for your detailed information. I cloned your latest code, and it now works correctly. I tried to figure out the reason this afternoon but failed to find which code caused this bug. In the end, I gave up and decided to use the latest code.

authors: JDYG hamarh


text:
⚠ ClamAV has degraded performance

In 99ea89e, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 194 ms

Resolved: ClamAV performance has improved in bfc32aa after 12 minutes.

repo: hamboneZA/caffeine


text:
⚠ ClamAV has degraded performance

In 05cc006, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 54 ms

Resolved: ClamAV performance has improved in 97646c7.


text:
⚠ ClamAV has degraded performance

In 377b68a, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 430 ms

Resolved: ClamAV performance has improved in 87263ef.


text:
⚠ ClamAV has degraded performance

In c0a1cb4, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 52 ms

Resolved: ClamAV performance has improved in d0556c6.


text:
⚠ ClamAV has degraded performance

In a0b7d4d, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 212 ms

Resolved: ClamAV performance has improved in 870ad06.


text:
⚠ ClamAV has degraded performance

In e8a73bf, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 81 ms

Resolved: ClamAV performance has improved in 3f1c78e.


text:
⚠ ClamAV has degraded performance

In 8f1e479, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 427 ms

Resolved: ClamAV performance has improved in fde8bfa.


text:
⚠ ClamAV has degraded performance

In 27bb991, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 596 ms

Resolved: ClamAV performance has improved in 1a3805a.


text:
⚠ ClamAV has degraded performance

In 588e2ac, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 75 ms

Resolved: ClamAV performance has improved in ca2002e.


text:
Remote RethinkDB Connection Example

It would be nice to have an example connection to a remote/non localhost RethinkDB server in the read me.

Added. Let me know if it's clear enough.

That looks great!

authors: Linicks hamiltop

repo: hamiltop/exrethinkdb


text:
Adding recognizers dynamically

Hi, I'm the author of #991 (SVG path trace recognizer)
tl;dr I suggest an enhancement to allow recognizer plugins for Hammer.js
Originally, and like I wrote in the PR comment, Hammer architecture currently does not easily allow adding recognizers dynamically. It assumes all recognizers are pre-packed with the lib, which makes it harder to write external modules. This means that extra functionality that might be relevant to some but not all use cases will either be deemed too out of scope and thus not included with hammer, or get included and bloat up the core lib.
Use case: Other than the SVG path follow I've already implemented, I'm also working on implementing an arbitrary shape/stroke recognizer based on $1 unistroke recognizer. This is a very specific use case that relies on an external library, with a different license than that of Hammerjs. It would be cool if Hammer could support it via external plugins, but without having to include both the implementation and the library in the source code.

Here's the shape/stroke recognizer in action, in a test from my game:

Would love to implement this as a plugin

This is functionality we decided to add directly to the library probably in V3

Neat! Based on my work, or a new implementation?
I'd be happy to contribute/maintain the code. I've learned a lot about the nuances of these types of gestures during my work on the game, which is a high budget production set to release in a few weeks... :)

@OpherV V3 is a complete re-write so not sure how direct it would transfer but we would love your help!

Also the ability to add and remove recognizers has always been planned and will be in v3 to allow custom builds.

Alrighty then - I'll stay tuned.
I'm super excited for the project to be released so I can show you and @runspired

We do most of our planning and discussion on slack feel free to join us

@arschmitz Like I promised it's finally out!
It's an interactive video/html5 game for the Detroit Pistons
Hammer.js is used to drive the game mechanic on mobile, but here's a secret link that lets you see it on desktop as well:
http://pistons.com/1on1?forcetouch=true

Check it out :)

@OpherV What an awesome game!!!

authors: OpherV arschmitz stereokai

license: mit

license_source: bigquery


text:
Allow additional MAF columns

Allow additional MAF columns. Separately, keep track of filterable_effect_function and only_nonsynonymous for easy querying.

Coverage increased (+0.1%) to 52.994% when pulling ff62712ed0e6b88490be9e98ea75d6c60c5b741c on additional_maf into 5ed28a4d54c0646cd01acf47aa55ad30c7d61ac8 on master.

authors: coveralls tavinathanson

repo: hammerlab/cohorts


text:
배너, 배너 그룹 구현

<배너>
학생회 소통창구: 학과학생회 자료가 리스트로 아카이빙 되어 있고 그 바로 위에 배너 형태로 소통창구(페이스북 페이지?) 리다이렉팅.
의결기구 오픈톡방: 의결기구 자료가 리스트로 아카이빙 되어 있고 그 바로 위에 배너 형태로 의결기구 오픈톡방 리다이렉팅.
카대전/아라: 굳이 배너가 필요할까 싶음. 메뉴에서 바로 링크로 리다이렉트 하면 어떨까.
<배너 그룹>
행사와 광고 배너가 섞여진 것을 캐러슬 (https://getbootstrap.com/docs/4.0/components/carousel/) 형태로. 위치는 메인페이지 공지사항 밑으로 내리고 그 위에.

5

+4

3

+4

authors: ashe-sparcs etranger-park jiggum

repo: hangpark/kaistusc


text:
客户端和服务端使用example示例哪里可以看到呢

如题。

https://github.com/hank-whu/rpc-benchmark/tree/master/turbo-server

https://github.com/hank-whu/rpc-benchmark/tree/master/turbo-client

authors: Viyond hank-whu

repo: hank-whu/turbo-rpc


text:
Sidebar cards being open or closed should be based on user interaction

The sidebar option cards currently return to their default state when the page is refreshed, meaning that closed cards will return to being closed even if the user is currently working on changing boxes within that card. We are choosing to make the defaults open so users don't have to keep opening them to change more settings, but preferably it shoudl be based on their interaction.

after discussions with Per, let's set most cards as open by default.

authors: Ambivalentalfa hannamlmv

repo: hannamlmv/tseda


text:
Unify signature of extension writing functions

Some extension writing functions return void, some return int. Study them and unify the signature.

Looking at issue #209 at https://github.com/hannestschofenig/mbedtls/issues/209 regarding the max_fragment_length extension I noticed that the upstream Mbed TLS changed their function signatures for extensions. All of the extensions now return an integer while all our function signatures use void. I wonder whether we now have to adjust the function calls in order to avoid problems upstreaming the code...

I checked this again and noticed that the function signatures for the extension handling differ for the ssl_client.c and the ssl_server.c file in the upstream Mbed TLS repo.
The code in ssl_tls13_client.c and ssl_tls13_server.c just reflects this structure.
Hence, in the future we should maybe aim for a harmonization in the upstream Mbed TLS codebase.

authors: hannestschofenig hanno-arm

repo: hannestschofenig/mbedtls


text:
[Question] How does LLaVA Generate the Exact Tokens in Lecture, Explanation in ScienceQA?

Question
Hi, I am just wondering about how LLaVA was able to generate the exact tokens in the lecture and explanation in the ScienceQA responses. They all match perfect with the ground truth. (though I expect some level of uncertainity). Does ScienceQA fine-tuning lead to this behavior?

Hi, thank you for your interest in our work and for the great question.  Please see the explanation in #109, and please let me know if there are further questions, thanks!

authors: haotian-liu sameeravithana

repo: haotian-liu/LLaVA


text:
related_images download failed, and I have resolved this bug.

I used to download a ton of images related to my keyword by adding '--related_images' or '-ri' in my query. and it worked very well. But recently, it don't work, it just downloads images from my keywords, no any related images.
I have been tossing for a long time. Finally, I resolved this bug! It seems that google has updated its html format. And you just need to find 'get_next_tab(self,s)' function and modify 3 lines code. Or you can copy and replace the function below
def get_next_tab(self,s):
    start_line = s.find('class="dtviD"')#class="ZO5Spb"
    if start_line == -1:  # If no links are found then give an error!
        end_quote = 0
        link = "no_tabs"
        return link,'',end_quote
    else:
        start_line = s.find('class="dtviD"')#class="ZO5Spb"
        start_content = s.find('href="', start_line + 1)
        end_content = s.find('">', start_content + 1)
        url_item = "https://www.google.com" + str(s[start_content+6:end_content])
        url_item = url_item.replace('&', '&')
        start_line_2 = s.find('class="dtviD"')#class="ZO5Spb"
        start_content_2 = s.find(':', start_line_2 + 1)
        end_content_2 = s.find('"', start_content_2 + 1)
        url_item_name = str(s[start_content_2 + 1:end_content_2])
        return url_item,url_item_name,end_content

Hi,
I noticed the same thing. Thanks for sharing.
I had the same problem and it solved it perfectly.
I would like to add to your changes something else.
I noticed that after your changes, the url_item needs to be modified as well.
So after the line nr 229 (where you modified the last instance of "dtviD") I would change the lines of code to the following.
start_content_2 = s.find(':', start_line_2 + 1)
end_content_2 = s.find('usg=', start_content_2 + 1) - 20
url_item_name = str(s[start_content_2 + 1:end_content_2])
url_item_name = url_item_name.replace(',g_1:',' ')
url_item_name = url_item_name.replace('+',' ')

#154 was merged. The issue is resolved and the related_images work fine. However @jimgros you pointed that out right for the first issue you mentioned, can you open a PR for it? Closing this issue.

Done
(that was my first PR :P )

authors: FieldRen hardikvasa jimgros

repo: hardikvasa/google-images-download


text:
Different result using VectorMasterView ?

Using ImageView (as expecting)
<ImageView
        app:srcCompat="@drawable/man_body"
        android:layout_width="match_parent"
        android:layout_height="match_parent"/>

But using VectorMasterView
<com.sdsmdg.harjot.vectormaster.VectorMasterView
        app:use_legacy_parser="false"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:vector_src="@drawable/man_body" />

Why result are different with same vector image, there are any criteria for VectorMasterView ?

I commented on a previous issue as well :

For the functionalities provided by the library, I had to parse the XML manually, but all the path parsing code has been shifted to native after API 21 and hence could not be used directly in the library. Therefore the code for parsing the xml is somewhat outdated even though I tried to port some changes from native back to java.

So the drawable API in android is updated and hence draws the vector perfectly, but the path parser I use is from API 21, therefore it is not able to draw the vector properly.

You may try to set use_legacy_parser="false". Setting this parameter will make the library use a 3rd party Path Parser for parsing the xml and it may render the vector properly.

Try to set use_legacy_parser="false".

@harjot-oberai tanks to reply, I'm already using this attribute.

I don't think I can help then. Backporting the path parser code from the native implementation will be too time consuming. Still I will try to look at the updated native code.

Thanks @harjot-oberai , However I was just need to change any specific path of my Vector Drawable,
that i can do now using VectorChildFinder .

Nice work on that libaray. Closing the issue now
Cheers !

authors: devsideal harjot-oberai

repo: harjot-oberai/VectorMaster


text:
🛑 NowWereCookin.org is down

In 762200c, NowWereCookin.org (https://www.nowwerecookin.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NowWereCookin.org is back up in 21efebe.

repo: harleykin/dotnetuptime


text:
Remove front matter

Signed-off-by: Smriti S smriti.satyanarayana@harness.io

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

authors: SmritiSatya bot-gitexp-user

repo: harness/developer-hub


text:
feat: [DOC-3761] [DOC-3609]: fix cert docs and add new solution doc

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

authors: bot-gitexp-user xingchi-jin


text:
Updating Roadmap with more flag features

Updating Roadmap with more flag features
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screenshot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65dfbf5c016abe86dc734349--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65dfc3adb5f92c8751860133--harness-developer.netlify.app

authors: HarnessTheChaos bot-gitexp-user


text:
Add missing expression to reference. (CDS-95148)

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Purpose
What is the motivation for this PR? What changes does it include? Include as much or as little detail as needed.
To add a missing expression to the expression reference.
If this submission relates to a Jira or GitHub issue, include the issue ID in the title.
CDS-95148
Internal Harness contributors - Please edit this summary to include preview links after the preview build finishes.
Merge requirements

[X] Successful preview build.
[ ] Code owner review.
[X] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://660f23af60006d0092bea7df--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://660f327b43fd690ae3697cb9--harness-developer.netlify.app

authors: SushrutHarness bot-gitexp-user


text:
Node level fault updated structure

Signed-off-by: Smriti S smriti.satyanarayana@harness.io

Preview environment: https://ci.pr.harness.io/pr-630

Preview environment: https://ci.pr.harness.io/pr-630

Preview environment: https://ci.pr.harness.io/pr-630

Preview environment: https://ci.pr.harness.io/pr-630

Preview environment: https://ci.pr.harness.io/pr-630

Preview environment: https://ci.pr.harness.io/pr-630


text:
clarified non-harness ci/cd usage in the onboarding guide

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663a95eca8fc516a1d273ce6--harness-developer.netlify.app

authors: bot-gitexp-user schoudhury


text:
Update delegate-environment-variables.md

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://670582bb44411d2b05836b58--harness-developer.netlify.app

authors: bot-gitexp-user raghuAtWings


text:
(FFM-6483) Wider linux kernel support

Issue
When running an ubuntu 20.04 image on a centos7 machine with linux kernel 3.10 we run into this fairly common linux kernel issue of error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory. This comes when launching our pushpin dependency.
This errors on kernel versions 3.10 because that kernel is incompatible with libQt5Core.so.5 which is only compatible with kernels 3.17 and above. These .note.ABI tags trigger compatibility checks by the linker when loaded. Stripping this tag out only disables the check by the dynamic linker for the kernel version to be at least as high and has no other effects. See this discussion and the many pr's that reference it. This and a multitude of forums/articles/github issues all had this same suggested workaround to remove these tags and prevent the kernel refusing to start over incompatibilities in parts of OS libraries we don't need or use.
Other changes
Also bumped our pushpin version and we now pull the focal version instead of the bionic one to be consistent, though both work fine.
Note
The only thing I'm unclear on and investigating is why this is an issue with ubuntu:20.04 but wasn't with ubuntu:18.04 for us, it's more for curiosity because the proposed solution I have here seems to be the standard workaround on every repo I've seen encounter it. It appears the answer is that some of these OS level dependencies changed between these ubuntu OS versions and that's why it's now being pulled into the dynamic linker when running on ubuntu:20.04 when it wasn't on ubuntu:18.04 and triggering this issue.
Testing
Tested that this new image runs successfully on centos7 machines with a linux 3.10 kernel as well as on regular aws linux2 AMI

Tested using the official aws marketplace centos7 ami which runs Linux kernel 3.10.0-1160.76.1.el7.x86_64 and now functions correctly.
Also sanity tested using Amazon Linux 2 OS on kernel 5.10 and and ECS fargate instance to verify no regressions in addition to our regular e2e test suite.

repo: harness/ff-proxy


text:
how to run it

Hi, thanks for attention,
I compile TC and freevars, but can't run them(error below), seems like they needs more parameters to run?
$ ./TC
[lambda-gpu-server:13913] *** Process received signal ***
[lambda-gpu-server:13913] Signal: Segmentation fault (11)
[lambda-gpu-server:13913] Signal code: Address not mapped (1)
[lambda-gpu-server:13913] Failing at address: 0xc0
[lambda-gpu-server:13913] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x15540)[0x7fc96a8cf540]
[lambda-gpu-server:13913] [ 1] /lib/x86_64-linux-gnu/libc.so.6(+0x66b84)[0x7fc96a72fb84]
[lambda-gpu-server:13913] [ 2] /lib/x86_64-linux-gnu/libc.so.6(__isoc99_fscanf+0x9d)[0x7fc96a72f32d]
[lambda-gpu-server:13913] [ 3] ./TC(_ZN11parallel_io54parallel_read_input_relation_from_file_to_local_bufferEPKcP19ompi_communicator_t+0xf3)[0x564b60e07c1d]
[lambda-gpu-server:13913] [ 4] ./TC(_ZN8relation19initialize_relationER8mpi_comm+0xb36)[0x564b60e25972]
[lambda-gpu-server:13913] [ 5] ./TC(_ZN3LIE7executeEv+0xc2)[0x564b60e1a8b2]
[lambda-gpu-server:13913] [ 6] ./TC(main+0x73c)[0x564b60e361e9]
[lambda-gpu-server:13913] [ 7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fc96a6f01e3]
[lambda-gpu-server:13913] [ 8] ./TC(_start+0x2e)[0x564b60e07a6e]
[lambda-gpu-server:13913] *** End of error message ***
Segmentation fault (core dumped)

Hi, sorry for the delay with our response, we had been constantly making changes to the code base and thus could not get back to you any sooner.
I have added readme on how to run the code.
Please let us know if you are able to run transitive closure.
The path to the input data file is currently baked in the code, but you can easily provide a path to your own input file, and instructions for that is also provided in the readme.
Please feel free to get back to me on sid14@uab.edu and I will be more than happy to help you get this running.
--
sidharth

repo: harp-lab/parallel-RA


text:
Addon scaling broken

Actually scaling an addon is broken. I am disabling addon scalers in our config for now.
Looks like we just need to upgrade out platform-api usage.

Expected([200, 201, 202, 204, 206, 304]) <=> Actual(422 Unprocessable Entity)
/app/vendor/bundle/ruby/2.2.0/gems/excon-0.45.4/lib/excon/middlewares/expects.rb:6:in `response_call'
/app/vendor/bundle/ruby/2.2.0/gems/excon-0.45.4/lib/excon/middlewares/response_parser.rb:8:in `response_call'
/app/vendor/bundle/ruby/2.2.0/gems/excon-0.45.4/lib/excon/connection.rb:372:in `response'
/app/vendor/bundle/ruby/2.2.0/gems/excon-0.45.4/lib/excon/connection.rb:236:in `request'
/app/vendor/bundle/ruby/2.2.0/gems/heroics-0.0.14/lib/heroics/link.rb:60:in `run'
/app/vendor/bundle/ruby/2.2.0/gems/heroics-0.0.14/lib/heroics/resource.rb:27:in `method_missing'
/app/vendor/bundle/ruby/2.2.0/gems/platform-api-0.3.0/lib/platform-api/client.rb:539:in `update'
/app/vendor/bundle/ruby/2.2.0/bundler/gems/dynosaur-e1999cbd4b3b/lib/dynosaur/heroku_addon_manager.rb:22:in `set'
/app/vendor/bundle/ruby/2.2.0/bundler/gems/dynosaur-e1999cbd4b3b/lib/dynosaur/heroku_manager.rb:50:in `ensure_value'
/app/vendor/bundle/ruby/2.2.0/bundler/gems/dynosaur-e1999cbd4b3b/lib/dynosaur/controllers/papertrail_controller_plugin.rb:23:in `scale'
/app/vendor/bundle/ruby/2.2.0/bundler/gems/dynosaur-e1999cbd4b3b/lib/dynosaur/controllers/abstract_controller_plugin.rb:77:in `run'

I'll try to take a look at this, this used to work fine not so long ago :imp:

Did you manage to find a fix? Just tried to use the gem and got the same problem.

Is the gem currently working with Heroku?

We are using dynosaur in production against our heroku app to scale dynos in response to GA Live API and NewRelic RPM data, but we are not using the Papertrail and Redis addon scalers. I believe this issue would need to be addressed before those would work.

authors: ACPK felipekk pjambet werkshy

repo: harrystech/dynosaur


text:
[FEATURE] Support multiple VLAN physical interfaces

Is your feature request related to a problem? Please describe.
Use case: VM workloads must be able to connect to VLANs that are switched on two different physical switches. Example includes a connection to an out-of-band (OOB) management network that is typically hosted on a dedicated physical switch isolated from the  TOR or leaf switch.
Expected implementation
Harvester allows user to define VLAN networks on more than just 1 network interface.

Supporting multi-networks (different NICs are binded to different networks) is planned in:
https://github.com/harvester/harvester/issues/2236

Verified fixed on v1.1.0-rc3. Close this issue.
Result

Can create different vlan on each cluster network

Can create VM using vlan id 91 and retrieve IP address correctly

Can create VM using vlan id 92 and retrieve IP address correctly

Can create VM using vlan id 1 and retrieve IP address correctly

Test Information

Test Environment: 3 nodes Harvester bare machines
Harvester version: v1.1.0-rc3

Verify Steps

Create cluster network cn1

Create a vlanconfig config-n1 on cn1 which applied to node 1 only

Select an available NIC on the Uplink

Create a vlan, the cluster network cn1 vlanconfig and provide valid vlan id 91

Create cluster network cn2

Create a vlanconfig config-n2 on cn2 which applied to node 2 only

Select an available NIC on the Uplink

Create a vlan, the cluster network cn2 vlanconfig and provide valid vlan id 92

Create cluster network cn3

Create a vlanconfig config-n3 on cn3 which applied to node 3 only

Select an available NIC on the Uplink

Create a vlan, select the cluster network cn3 vlanconfig and provide valid vlan id 93

Create a VM, use the vlan id 1 and specific at any node

Create a VM, use the vlan id 91 and specified at node1

Create another VM, use the vlan id 92

How can I configure multiple IP addresses on Harvester host?
My use case, I want to connect all hosts to a dedicated network on the 10G bond. All hosts have an IP from mgm network on another 1G interface

authors: Ali-Gamal TachunLin janeczku w13915984028

repo: harvester/harvester


text:
[FEATURE] Add BIOS or EFI boot option for the bootloader

Is your feature request related to a problem? Please describe.

When booting an ISO, I expect to not see the EFI Interactive Shell. There are still quite a few ISOs that cannot use EFI for booting and need to use BIOS.
Describe the solution you'd like

I'd like to see a toggle option for BIOS or EFI Bootloader
Describe alternatives you've considered

Right now I have to go into YAML to change this. This has caused some issues when trying to learn about this new system.
Additional context

http://kubevirt.io/user-guide/virtual_machines/virtual_hardware/#biosuefi
This Doc is not accurate. It is set to boot in EFI by default.

Should be fixed in v1.0.2 : https://github.com/harvester/harvester/issues/2210

authors: Chrisputer yasker


text:
[BUG] LiveMigration fails because of same product_uuid on same model hardware servers

Describe the bug
We are in the process of setting up an onprem Harvester bare-metal cluster and when we are trying to use the LiveMigration feature, we get the following error message in the events of the virtualmachine resource.
VirtualMachineInstance migration uid c9091bc7-60ce-49b4-84dd-83adb17fbd9d failed. reason:Live migration failed error encountered during MigrateToURI3 libvirt api call: virError(Code=1, Domain=10, Message='internal error: Attempt to migrate guest to the same host 03000200-0400-0500-0006-000700080009')

This is in line with the fact that all our hosts have the same UUID in the "More Information" section of the host resource (e.g. two examples)

We have verified that on all nodes the contents of the SMBIOS interface files /sys/class/dmi/id/product_uuid is excactly the same value  03000200-0400-0500-0006-000700080009 but the contents of /sys/class/dmi/id/product_serial are consecutive numbers like 9000160160, 9000160161
We would like to know how we can fix this so, that concerning rancher all nodes are recognized as different nodes so that we can use the LiveMigration feature.
Best regards
Chris
To Reproduce
Steps to reproduce the behavior:

Go to any VM running on Harvester CLuster
Select Migrate and chose a migration target
after a short while the migration fails with the above error message

Expected behavior
When I use the LiveMigration feature the chosen VM is migrated successfully to another node with a different UUID
Support bundle

I send the support bundle to harvester-support-bundle@suse.com with the correct issue ID
Environment

Harvester ISO version: harvester-v1.1.2-amd64
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): 5x bare-metal AMD Dual-CPU RA2112-ASEPN Server (2x EPYC 75F3 CPUs)

Additional context
As the screenshot shows we are also experiencing the AMD KVM issue described here #3900 but we are waiting for the release of the annouced patch.

Hello and thank you for the quick response.
Manually editing the information in this path /sys/class/dmi/id/product_uuid is unfortunately not possible because the file AFAAIK is just an interface for certain kernel functions. The only way to edit it this way, would be to change those kernel files and recompile the whole kernel of the underlying OS, which is of course not a viable option for us.
We are already in contact with our hardware vendor, to try to change the SMBIOS values that the kernel would read from the mainboard by reflashing the whole BIOS and it looks like a promising avenue for us because our vendor is very helpful and knowledgeable. But nonetheless I think that might not always be the case for every vendor, so that maybe this kind of edge case should be considered and caught from the harvester/hypervisor side as well.
e.g.: Would it maybe possible to somehow make the default value read from the product_uuid overrideable with maybe a special annotation or something so that such a case would not require reflashing of the bare metal BIOSes on each server?

@staedter
It seems to be the first time for Harvester to encounter this, several machines are of same product_uuid, I tried to read them from my local PC and the VM on it, each is unique.
PC:
sudo -i cat /sys/class/dmi/id/product_uuid
30eb9a66-bcb7-25d8-4f74-04421ae88eac

KVM VM on this PC:
sudo -i cat /sys/class/dmi/id/product_uuid
39c53d5b-e7ec-45d1-b53a-263c4d46034f

As the source code is in kubelet, an agent running in each k8s NODE, I suspect the code is not easy to change. I will be much complex than current, kubelet needs to read values from underlayer, and then compare it with api-server, when duplicated, try to random it/use some other value....
And it was ever discussed:
https://github.com/kubernetes/kubeadm/issues/31#issuecomment-309211349

list this as a requirement for everything running smoothly.
Kubernetes and things running on top might require/assume that
a) The product_uuid is unique
b) The MAC address is unique
for every node.

@guangbochen @bk201 We could also add this into Harvester requirements.

We could fix the issue with our servers bei changing the SMBIOS information on our ASUS-Mainboards via the amidmi.exe tool.
We had to create a FREEDOS-Bootstick and then use this command
amidmi.exe /u "00000000000000000000123456789123"
After a reboot the  /sys/class/dmi/id/product_uuid finally showed different results and kube-virt startet working correctly.
Thank you for the help. Issue has been resolved


text:
[BUG] migration failed stauts is missing

Describe the bug
When the migration is failed the VM migration tab UI doesn't include any relevant status.
To Reproduce
Steps to reproduce the behavior:

go to the VM listing page
click to migrate the VM to another node
when the migration is failed e.g the node is down
no migration failed status was shown on the migration tab

Expected behavior
Should display migration failed status on the migration tab page.
Log
migrationState:
    completed: true
    endTimestamp: "2021-04-14T09:18:12Z"
    failed: true # the failed shown as true which means the last migration was failed
    migrationUid: bb525a15-021b-47f0-b1c4-ff45041c8e22
    mode: PreCopy
    sourceNode: bm-har1
    startTimestamp: "2021-04-14T09:18:10Z"
    targetDirectMigrationNodePorts:
      "34459": 49152
      "34791": 49153
      "37895": 0
    targetNode: bm-harv2
    targetNodeAddress: 10.52.0.45
    targetNodeDomainDetected: true
    targetPod: virt-launcher-ub1-l6cqg

Environment:

Harvester ISO version:
Installation Mode: ISO/app-mode
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

Validate version master-0008ce84-head

Start VM(vm name: b) on node A
Migrate VM from node A to node B
Shutdown node B

At this time, the VM status has not been Migrating, and the migration failed status cannot be obtained.
# kubectl get vmi b -o yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  annotations:
    harvesterhci.io/diskNames: '["b-disk-0-8eusw"]'
    harvesterhci.io/migrationState: Migrating
    harvesterhci.io/migrationTargetNodeName: hailong-h2
    harvesterhci.io/migrationUID: dd8e4910-a136-41e6-bad6-da6b97f21c99
    harvesterhci.io/sshNames: '[]'
    kubevirt.io/latest-observed-api-version: v1
    kubevirt.io/storage-observed-api-version: v1alpha3
  creationTimestamp: "2021-04-21T08:11:01Z"
  finalizers:
  - foregroundDeleteVirtualMachine
  - wrangler.cattle.io/VMIController.UnsetOwnerOfDataVolumes
  generation: 11
  labels:
    harvesterhci.io/creator: harvester
    harvesterhci.io/vmName: b
    kubevirt.io/nodeName: hailong-h3
  managedFields:
  - apiVersion: kubevirt.io/v1alpha3
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:interfaces: {}
        f:migrationMethod: {}
        f:phase: {}
        f:volumeStatus: {}
    manager: virt-handler
    operation: Update
    time: "2021-04-21T08:12:32Z"
  - apiVersion: kubevirt.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:harvesterhci.io/migrationState: {}
          f:harvesterhci.io/migrationTargetNodeName: {}
          f:harvesterhci.io/migrationUID: {}
        f:finalizers: {}
      f:spec:
        f:nodeSelector:
          .: {}
          f:kubernetes.io/hostname: {}
    manager: harvester
    operation: Update
    time: "2021-04-21T08:14:43Z"
  - apiVersion: kubevirt.io/v1alpha3
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:harvesterhci.io/diskNames: {}
          f:harvesterhci.io/sshNames: {}
          f:kubevirt.io/latest-observed-api-version: {}
          f:kubevirt.io/storage-observed-api-version: {}
        f:labels:
          .: {}
          f:harvesterhci.io/creator: {}
          f:harvesterhci.io/vmName: {}
          f:kubevirt.io/nodeName: {}
        f:ownerReferences: {}
      f:spec:
        .: {}
        f:domain:
          .: {}
          f:cpu:
            .: {}
            f:cores: {}
            f:sockets: {}
            f:threads: {}
          f:devices:
            .: {}
            f:disks: {}
            f:inputs: {}
            f:interfaces: {}
          f:firmware:
            .: {}
            f:uuid: {}
          f:machine:
            .: {}
            f:type: {}
          f:resources:
            .: {}
            f:requests:
              .: {}
              f:memory: {}
        f:evictionStrategy: {}
        f:hostname: {}
        f:networks: {}
        f:volumes: {}
      f:status:
        .: {}
        f:activePods:
          .: {}
          f:2e5d11d8-5b9f-421e-b3a0-d532ae3cb613: {}
          f:552a46c4-5403-4fa0-8b99-cbc4bb96686b: {}
        f:conditions: {}
        f:guestOSInfo: {}
        f:launcherContainerImageVersion: {}
        f:nodeName: {}
        f:qosClass: {}
    manager: virt-controller
    operation: Update
    time: "2021-04-21T08:14:43Z"
  name: b
  namespace: default
  ownerReferences:
  - apiVersion: kubevirt.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: VirtualMachine
    name: b
    uid: c3d23a00-5080-4dff-98cc-db17acc05c46
  resourceVersion: "204281"
  uid: 84af5c2c-021c-4add-8f7f-bf2a196e3bd2
spec:
  domain:
    cpu:
      cores: 2
      sockets: 1
      threads: 1
    devices:
      disks:
      - disk:
          bus: virtio
        name: disk-0
      inputs:
      - bus: usb
        name: tablet
        type: tablet
      interfaces:
      - masquerade: {}
        model: virtio
        name: default
    features:
      acpi:
        enabled: true
    firmware:
      uuid: 0cfa3079-196c-5502-9d0b-07fe107ad90a
    machine:
      type: q35
    resources:
      requests:
        cpu: 100m
        memory: 4Gi
  evictionStrategy: LiveMigrate
  hostname: b
  networks:
  - name: default
    pod: {}
  nodeSelector:
    kubernetes.io/hostname: hailong-h2
  volumes:
  - dataVolume:
      name: b-disk-0-8eusw
    name: disk-0
status:
  activePods:
    2e5d11d8-5b9f-421e-b3a0-d532ae3cb613: ""
    552a46c4-5403-4fa0-8b99-cbc4bb96686b: hailong-h3
  conditions:
  - lastProbeTime: null
    lastTransitionTime: null
    status: "True"
    type: LiveMigratable
  - lastProbeTime: null
    lastTransitionTime: "2021-04-21T08:12:28Z"
    status: "True"
    type: Ready
  guestOSInfo: {}
  interfaces:
  - ipAddress: 10.52.2.27
    ipAddresses:
    - 10.52.2.27
    mac: 52:54:00:87:75:ef
    name: default
  launcherContainerImageVersion: quay.io/kubevirt/virt-launcher:v0.40.0
  migrationMethod: LiveMigration
  nodeName: hailong-h3
  phase: Running
  qosClass: Burstable
  volumeStatus:
  - name: disk-0
    target: vda

#  kubectl get vmim -o yaml
apiVersion: v1
items:
- apiVersion: kubevirt.io/v1
  kind: VirtualMachineInstanceMigration
  metadata:
    annotations:
      kubevirt.io/latest-observed-api-version: v1
      kubevirt.io/storage-observed-api-version: v1alpha3
    creationTimestamp: "2021-04-21T08:14:43Z"
    finalizers:
    - kubevirt.io/migrationJobFinalize
    generateName: b-
    generation: 1
    labels:
      kubevirt.io/vmi-name: b
    managedFields:
    - apiVersion: kubevirt.io/v1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:generateName: {}
        f:spec:
          .: {}
          f:vmiName: {}
      manager: harvester
      operation: Update
      time: "2021-04-21T08:14:43Z"
    - apiVersion: kubevirt.io/v1alpha3
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            .: {}
            f:kubevirt.io/latest-observed-api-version: {}
            f:kubevirt.io/storage-observed-api-version: {}
        f:status:
          .: {}
          f:phase: {}
      manager: virt-controller
      operation: Update
      time: "2021-04-21T08:14:43Z"
    name: b-pj99j
    namespace: default
    resourceVersion: "204275"
    uid: dd8e4910-a136-41e6-bad6-da6b97f21c99
  spec:
    vmiName: b
  status:
    phase: Scheduling
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

case 1:

do a migration
delete the new launcher pod when it is in ContainerCreating status.

Result: VMIM is in failed phase. VMI.status.migrationState is empty.
In this case, harvester migration annotation is still in migrating state. Need a backend fix for this.
case 2:

do a migration
delete the new launcher pod when it is in Running status.

Result: VMIM is in failed phase. VMI.status.migrationState is failed.

validated on v0.2.0-rc4
When the migration fails, the prompt status of migration failure will be obtained on the UI

authors: gitlawr guangbochen kingsd041


text:
Flutter upgrade 3.13

Why? (ticket link or issue description)
We need to upgrade all the packages to the latest version
What was done and how?

Flutter is upgraded to 3.13+
All packages have been upgraded.
Deprecated properties have been removed.

Anything special? (optional)

Great job @hasibul-hasan-shuvo!


text:
load関数の仕様の明確化

Motivation
load関数の仕様がデータセットごとにバラバラなのである程度統一したい
Details
load関数の大まかな構造は下のコードのようにする．

load_raw: この関数ではデータセットの読み込みのみを行い，データ構造は生データから大きく変更しないようにする(生データを直接扱うケースを想定)．
reformat: load_raw関数で読み込まれた生データをデータセット間で統一のデータ構造*に変換する．

* データ構造の詳細については後述
def load(path, *options):
    # データセットのロードと簡単な整形のみを行う
    raw = load_raw(path, *options)

    # load_raw関数で読み込まれた生のデータを "データセット間で統一のデータ構造" に変更
    data = reformat(raw)

    return data

データ構造
データセット間で統一のデータ構造の候補は次の3つ

センサデータとメタデータを一つにまとめたDataFrame
具体的なデータ構造
DataFrame

センサデータとメタデータをそれぞれList[DataFrame]とDataFrame(またはList[DataFrame])
具体的なデータ構造
Tuple[List[DataFraem], DataFrame] or Tuple[List[DataFrame], List[DataFrame]]

1.と2.の違いを吸収した新たなデータ構造
具体的なデータ構造
class NewData:
    # property
    data: List[DataFrame]
    meta: DataFrame or List[DataFrame]
    type: str ...etc    # 1.や2.を区別する識別子

とりあえずデータ構造は2の形(DataFrame or List[DataFrame])で実装する．

#7 のマージ作業が完了したのでfix

repo: haselab-dev/sensorutils


text:
added saucerswap faucet bot code

Description:
This PR adds the SaucerSwap Labs faucet bot repo in it's current state to this repository.

Great! Although the merge is currently blocked:

Can you mark the first conversation as resolved?

Should be able to pass all checks after that

Will need approval to merge @web3-nomad

Encountering an odd issue trying to merge

Not entirely sure why it's still being blocked

GPG sign. 'capital S on the commit, not lowercase'

Requesting approval again @web3-nomad

repo: hashgraph/hashgraph-defi-alliance


text:
Add actual gasPrice to synthetic transaction receipts

Description:
This PR modifies eth_getTransactionReceipt function in order to add effectiveGasPrice for synthetic transactions (HTS), Contract Create or Contract Call.
Related issue(s):  https://github.com/hashgraph/hedera-json-rpc-relay/issues/1736
Notes for reviewer:
Hash of a test transaction in testnet:
0xd624d50e109c51d3765c3ade221797b6003b5b0dd0063c49fad5add8f04ffcc6
Checklist

[ ] Tested (unit, integration, etc.)

Codecov Report
Patch coverage: 66.66% and project coverage change: -0.90% :warning:

Comparison is base (5c991dc) 77.75% compared to head (4292dc5) 76.86%.

:exclamation: Current head 4292dc5 differs from pull request most recent head 05b74f7. Consider uploading reports for the commit 05b74f7 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1743      +/-   ##
==========================================
- Coverage   77.75%   76.86%   -0.90%
==========================================
  Files          26       39      +13
  Lines        2329     2922     +593
  Branches      478      588     +110
==========================================
+ Hits         1811     2246     +435
- Misses        376      496     +120
- Partials      142      180      +38

Files Changed
Coverage Δ

packages/relay/src/lib/eth.ts
85.71% <66.66%> (-0.08%)
:arrow_down:

... and 14 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@Nana-EC
Hello :)
I have added the two tests you asked for.
Please have a look and comment on them.
Hopefully all your recommendations are addressed.
P.S.
(the previous push was just a test one. I am sorry for the spam)

authors: codecov-commenter stefan-stefanooov

repo: hashgraph/hedera-json-rpc-relay


text:
Terraform 0.12 upgrade

This PR builds on the work that @mustafashabib started in #138 and makes all modules and examples compatible with Terraform 0.12.x.
Please note that this change is BACKWARDS INCOMPATIBLE and you MUST use Terraform 0.12.x and above with the code once this has been merged.

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
Have you signed the CLA already but the status is still pending? Recheck it.

Thank you for picking up my slack!

Since I didn't want @mustafashabib not to be credited with the work he did, I cherry-picked his commit from #138 onto my branch and replayed the commits I made after that (thus the force push).

authors: hashicorp-cla mcalhoun mustafashabib

repo: hashicorp/terraform-aws-consul


text:
DEV: Well: Determine Code Impact to client PUT API Change

#619 - DEV: Determine Code Impact to client PUT API Change
DEV: Analysis: small (search codebase for usage & determine code change)
DEV: Code & Test: TBD
Per client, the current PUT API of some DoT services provides partial update behavior, which is wrong (The correct PUT behavior is to create a new resource or replace whole existing resource). This is DoT technical debt and we’re going to correct them. Below PUT APIs behavior needs correction:
PUT /witsml/wells/{uid}
PUT /witsml/wellbores/{uid}
PUT /witsml/trajectories/{uid}
Before any code change on DoT side, could you please confirm whether Drillflow relies on above APIs partial update? If yes, please adjust code accordingly. After that, we will update DoT code.
Thanks,
Xiaobin

@TessForGithub2 Theresa, for this card history, can you please confirm whether we use the PUT API for Update in store behavior for well?  I believe you looked at this?

This card can be moved back to the well backlog after adding notes about how we use the PUT API.

WELL --
Currently use endpoint ...well/v2/witsml/wells/ as PUT
Refer to the SLB demo website: democore/Slb.Prism.Core.Service.Well-2 which states:
"Create a well object with uid specified or Update a well object in 1.4.1.1 format"
(NOTE: this was designed to accommodate both a creation or an update.)
Need to use endpoint ...well/v2/witsml/wells/ as PATCH
Refer to the SLB demo website: democore/Slb.Prism.Core.Service.Well-2 which states:
"Patch well in 1.4.1.1 format"
ESTIMATE OF CODE IMPACT: Based on the following facts, I estimate this as MEDIUM:
The same endpoint is used, just a PATCH vs. PUT.
However, the SLB schema for PATCH is significantly less defined & there appears to be fewer elements in the PATCH (therefore, some type of data mapping and/or data validation may need to be performed to successfully use this endpoint).

authors: Mike-d-s niaalex

repo: hashmapinc/Drillflow


text:
Tempus-647

Thank you for submitting a contribution to Tempus.
In order to streamline the review of the contribution please
ensure the following steps have been taken:
For all changes:

[ ] Is there a Waffle ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with Tempus-XXXX where XXXX is the waffle number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically dev)?

[ ] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn clean install at the root Tempus folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] Have you added documentation for any UI or API related changes to the /docs folder

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant SPParnerkar

repo: hashmapinc/Tempus


text:
Cleanup warnings

This remedies a few helpful warnings that Elixir provides before compilation.

Merging despite failing on CI. Tests pass locally consistently. Important problem but unrelated to these changes.

repo: hashrocket/tilex


text:
license (top level)

text taken from happy/README.md

@Ericson2314
simple fix

Thanks!

authors: andreasabel askeblad

repo: haskell/alex


text:
Sort module import suggestions

Fixes #786

There are no duplicates

repo: haskell/ghcide


text:
coot/multiple package (ghc-head)

The PRs #1277 and #1379 rebased onto ghc-head branch.

I wasn't able to test it locally, because it does not build for me. I am getting various type errors due to changes in ghc package.
I am getting type errors due to changes in ghc package.

@coot To test locally, you have to apply this patch to the haddock submodule in the GHC tree and run the tests. If you have issues with GHC master branch, please contact the GHC dev team. :)

I mean, something a bit different.  To compile exe:haddock and verify that the changes works as intended. I wasn't able to build it with ghc-head (installed with ghcup, so quite like the CI does).

@coot Can you uninstall ghc 9.2 and reinstall it like this?
$ ghcup install ghc -u "https://gitlab.haskell.org/api/v4/projects/1/jobs/artifacts/ghc-9.2/raw/ghc-x86_64-fedora27-linux.tar.xz?job=validate-x86_64-linux-fedora27" 9.2

With ghc-9.2 I am getting:
cabal build -w ghc-9.2 exe:haddock
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports
'ghc' version < 9.1): /home/coot/.ghcup/bin/ghc-9.2 is version 9.2.0.20210805
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: haddock-api-2.24.0 (user goal)
[__1] next goal: ghc (dependency of haddock-api)
[__1] rejecting: ghc-9.2.0.20210805/installed-9.2.0.20210805 (conflict:
haddock-api => ghc^>=9.3)

I got slightly further with ghc-head (installed through ghcup):
cabal build --disable-documentation -w ghc-head --with-ghc-pkg ghc-pkg-head exe:haddock
Build profile: -w ghc-9.3.20210805 -O1
In order, the following will be built (use -v for more details):
 - haddock-api-2.24.0 (lib) (first run)
 - haddock-2.24.0 (exe:haddock) (first run)
Preprocessing library for haddock-api-2.24.0..
Building library for haddock-api-2.24.0..
[12 of 40] Compiling Haddock.GhcUtils ( src/Haddock/GhcUtils.hs, /home/coot/repos/ghc/utils/haddock/dist-newstyle/build/x86_64-linux/ghc-9.3.20210805/haddock-api-2.24.0/build/Had
dock/GhcUtils.o, /home/coot/repos/ghc/utils/haddock/dist-newstyle/build/x86_64-linux/ghc-9.3.20210805/haddock-api-2.24.0/build/Haddock/GhcUtils.dyn_o )

src/Haddock/GhcUtils.hs:184:61: error:
    • Couldn't match type ‘IsUnicodeSyntax’
                     with ‘GenLocated EpAnnCO (HsUniToken "->" "\8594")’
      Expected: LHsUniToken "->" "\8594" DocNameI
        Actual: IsUnicodeSyntax
    • In the first argument of ‘HsUnrestrictedArrow’, namely
        ‘NormalSyntax’
      In the second argument of ‘HsFunTy’, namely
        ‘(HsUnrestrictedArrow NormalSyntax)’
      In the first argument of ‘noLocA’, namely
        ‘(HsFunTy noAnn (HsUnrestrictedArrow NormalSyntax) a b)’
    |
184 |    mkFunTy a b = noLocA (HsFunTy noAnn (HsUnrestrictedArrow NormalSyntax) a b)
    |                                                             ^^^^^^^^^^^^

@Kleidukos I rebased on a more recent version of ghc-head, and now I was able to verify that things work as expected.

Thank you for your patience!

authors: Kleidukos coot

repo: haskell/haddock


text:
Support GHC 9.4

Depends on https://github.com/haskell/primitive/pull/340
Tests run locally and pass with cabal test --allow-newer.
Without --allow-newer, we get a problem with vector's upper bound.

Please read through https://github.com/haskellari/splitmix/blob/master/CONTRIBUTING.md

I'm confused. By my reading of that file, I'd want to add a line to Tested-With for GHC 9.4. But you've closed the PR. Can you clarify your intent?

tested-with is used for generating CI script, which wasn't re-generated. I'll clarify the CONTRIBUTING.md to say: only bounds, i.e. no code changes.
I maintain plenty of packages, these PRs are noise and not helpful.

I'm still confused.
Do you want to re-open this PR so I can add the Tested-With line, regenerate CI script, etc? Would also be happy to include a note in the PR template ("see CONTRIBUTING.md").
Or do you want me to make an issue about version bounds?
Or do you just want me to stop commenting on this?

These changes are not something you can help with. Thank you anyway.
Please open an issue if you need it for reference elsewhere.

authors: parsonsmatt phadej

repo: haskellari/splitmix


text:
Update DOCS.md

In Home Assistant 2022.10.1, step 4 under "Now it is time to set up Home Assistant:" can be confusing depending on whether Home Assistant has auto-detected this add-on as a Z-Wave device.
Proposed Changes

Add a bullet to help explain this scenario.

FYI, this problem is an HA bug, fixed in https://github.com/home-assistant/core/pull/80110. I suppose it will be part of the 2022.11 release.

That makes sense.  I asked on Discord and didn't get feedback beyond "an issue exists."  I also searched github given that info, but my terms brought up a separate previously resolved issue, so I thought this was "by design."

repo: hassio-addons/addon-zwave-js-ui


text:
🛑 Git Server is down

In d03f264, Git Server (https://git.arash-hatami.ir) was down:

HTTP code: 504
Response time: 15652 ms

Resolved: Git Server is back up in 63c7a60 after 26 minutes.


text:
[HxMessenger] Notice appears under top nav bar with top positions

I have found when using ToastContainerPosition.TopCenter (or top start or top end), that the notice is appearing under the top nav bar (setup with HxNavbar).
I have applied a class that set's the z-index to 10000 to work around the problem for now.

Can not reproduce. The hx-toast-container has its z-index set to 1080 - that is highest value of all Bootstrap components. It should be alright.
What is your version of HAVIT Blazor?

I am on the latest (2.6.3).
I can see that the navbar has a z-index of 1080, but when I inspect the messenger placeholder element I can't see a z-index applied.
I am including the components CSS reference in the "_Hosts" file:
<link href="_content/Havit.Blazor.Components.Web.Bootstrap/defaults.css" rel="stylesheet" />
This is what I can see in the browser coming through from this file (assuming I am inspecting this correctly):

When I specifically inspect the element

, the "Computed" inspector does not show any z-index applied.
I have realised I am using it with the 5.2 beta of Bootstrap - not sure if that would be the problem or not?
Thank you for any help.

The rule
.hx-toast-container {
	z-index: 1080;
	margin: var(--hx-toast-container-margin);
}

is carried in CSS-isolation. Do you reference the Blazor CSS isolation styles from you _Hosts file?
<link href="Your.Blazor.Project.Assembly.Name.styles.css" rel="stylesheet" />

Ok, thank you. That was it - I did not have that reference in my _Hosts file.
I thought that was only needed if I was doing CSS isolation for my own components, not ones coming from other frameworks.
Thank you!

Unfortunately, Blazor mixes all the CSS isolations together (using @import directives) and the reference has to be there.

authors: crdo hakenr rmmcgr


text:
Auth check over-eager

The auth check from #32 is over eager in the sense that it only works for Hawkular-Metrics, but not for Hawkular-services:
$ curl  -u jdoe:password http://localhost:8080/hawkular/metrics/tenants -HHawkular-Tenant:Hawkular
{"errorMsg":"Admin token is wrong or not specified."}

I found that just accessing / may be enough already:
$ curl  -u jdoe:password http://localhost:8080/hawkular/metrics/ -HHawkular-Tenant:Hawkular
{"Implementation-Version":"0.21.5.Final","Built-From-Git-SHA1":"e779588593f13224225356a94f1d8642fbccb30f","name":"Hawkular-Metrics"}

vs
$ curl   http://localhost:8080/hawkular/metrics/ -HHawkular-Tenant:Hawkular
<title>Error</title>Unauthorized

(of course the check for a valid tenant needs to be adjusted)

I checked the "/" endpoint with openshift and a bearer token, unfortunately it is allowed publicly without authentication. The bearer token can be wrong but the requests gives a correct response.
So I suggest to use another endpoint like 'http://localhost:8080/hawkular/metrics/metrics' to be sure that the authentication is checked

authors: jotak pilhuhn

repo: hawkular/hawkular-grafana-datasource


text:
Update the Dockerfile to build from release versions

Note that because the plugins path is declared as a volume in the grafana base image, we cannot straightly download or use grafana-cli from inside the Dockerfile ; we have to work around with that docker/build.sh

What's the motivation for moving from latest to 3.1.1 Grafana version? Isn't the plugin compatible with the latest version?

Yeah, until latest becomes too recent :) I think it's a good practice to rely on a fixed version, no?

(PS I put "invalid" label, actually i'd like to label "DO NOT MERGE" but I can't create new labels , or I don't know how)

Just add "do not merge" to comments it's fine :)
Why "do not merge" ?
2016-11-16 10:45 GMT+01:00 Joel Takvorian notifications@github.com:

(PS I put "invalid" label, actually i'd like to label "DO NOT MERGE" but I
can't create new labels , or I don't know how)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hawkular/hawkular-grafana-datasource/pull/38#issuecomment-260900560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbltg-H_VsEeS5GKYUTJu9IjKufj5k6ks5q-tDQgaJpZM4KzmPk
.

I'm waiting a little bit to let Yaacov eventually comment, since he was the first to introduce a dockerfile here and still using it.

Seems good to him. By the way, the docker image is now on dockerhub: https://hub.docker.com/r/hawkular/hawkular-grafana-datasource/
I will add a note about that on the documentation (which is now deported on hawkular website)

authors: jotak tsegismont


text:
Tags parser: allow underscore in variable name

And fix bug when removing tag

Any test update ? ;-)

Are you incorruptible? :)


text:
Unit tests for parser

Requires #14

I think this can be safely closed; the parser currently handles all functionality in the current spec. As new integration targets are added, I'll add the appropriate tests to the parser test suite as well.

repo: hawkw/seax


text:
Expose config.

Expose config so consumers of the module can programmatically get a list of files generated without having to read the config/icons.json file themselves.
Wanted for https://github.com/davewasmer/ember-cli-favicon/issues/5.
If you prefer, we can expose a deep clone of the config, so that modification isn't possible - though for that, we might want to upgrade from underscore to lodash.
If you're open to it, I want to go even further and expose a flattened list of files, e.g.:
modules.exports.files = ['favicon.png'].concat(_(config.icons).map(function (icon) {
  return Object.keys(icon);
}).flatten().value());

Let me know and I can add that to this PR before you merge.

I can see the value in this. I also like how neat module.exports.config = config; is at the moment. Can you add something to the readme to let people know about this new export? Not sure about .files just yet, it feels a bit messy but we should find a good way of listing these files for sure.

@haydenbleasel Thanks, I've pushed another commit that adds the info to the README - is that what you were thinking?

Yep cool :+1:

@haydenbleasel Thanks, any idea when there will be a next release to include this?

@adjohnson916 It's in the 4.4.5 tag (available now) and it'll be in the 4.5.0 official release.

@haydenbleasel Oh thanks. I didn't see that. Do you not always push the tags to GitHub?

@adjohnson916 I create a new release manually every minor update. There's always a handful of patches and fixes per tag / release so sometimes you'll have to wait a little bit.

repo: haydenbleasel/favicons


text:
Make relay connection args optional explicitly

I'm like 90% sure this was the correct place to make this change but if not please let me know 😄
Fixes #64

Thanks! This looks good. I'm camping and may not be able to release this for a day or 2, but I'll get a new version out as soon as I can

published:

@giraphql/plugin-dataloader@2.2.2
@giraphql/plugin-relay@2.2.6

repo: hayes/giraphql

license: ISC


text:
Prisma Utils plugin does not have createMany option

Maybe I'm wrong, but since we have updateMany, deleteMany, there should also be createMany. Since the original prisma client has such a field.
const EnvironmentVariableCreate = builder.prismaCreateRelation("Project", "environmentVariables", {
  name: "EnvironmentVariableCreate",
  fields: (t) => ({
    create: EnvironmentVariableCreateInput,
    createMany: { data: EnvironmentVariableCreateInput, skipDuplicates: t.boolean() },  // ERROR: <unnamed ref or enum> has not been implemented
  }),
});

const EnvironmentVariablesUpdate = builder.prismaUpdateRelation("Project", "environmentVariables", {
  name: "EnvironmentVariablesUpdate",
  fields: (t) => ({
    create: EnvironmentVariableCreateInput,
    createMany: { data: EnvironmentVariableCreateInput, skipDuplicates: t.boolean() }, // ERROR: <unnamed ref or enum> has not been implemented
    update: {
      where: EnvironmentVariableUniqueFilter,
      data: EnvironmentVariableCreateInput,
    },
    updateMany: {
      where: EnvironmentVariableUniqueFilter,
      data: EnvironmentVariableCreateInput,
    },
    delete: EnvironmentVariableUniqueFilter,
    deleteMany: EnvironmentVariableUniqueFilter,
  }),
});

Thanks in advance for the clarification :)

The reason this hasn't been implemented is that the createMany updates for fields use very specific types that are scoped to the specific relation, so you need to create a very specific input type.  The type would be something like:
ProjectCreateManyEnvironmentVariables.  This input type doesn't support nested relations, and omits the source relation.  To accomidate this, we either need to define this type inline (which gets complicated with nested field builder callbacks), or we need to add another builder method like:
builder.prismaRelateCreateMany('Project', 'environmentVariables',  {
  fields: ...createManyFields
})

This is probably manageable, but adds a lot of overhead for a relatively small use-case

Added a new builder.prismaCreateMany helper added a createMany field to prismaUpdateRelation.  Let me know how that works for you!

authors: SpeedySH hayes

repo: hayes/pothos


text:
Missing documentation for PartitionAware feature usage

Added documentation for PartitionAware feature usage.

Test FAILed.

Test PASSed.

authors: devOpsHazelcast ihsandemir

repo: hazelcast/hazelcast-cpp-client


text:
Multiple 'start' with single 'finished'

I know it should be. an issue of the api, but since this is the implementation I though I open it here.
What is the situation?
Since it is allowed to click on play button next to test name while tests are already running, I though I can support sequentially adding new tests to the batch:
When run is called I just return a global promise and schedule the new tests.
Works fine but on the ui it doesn't show much just when I send the running event about the new tests. If I could send multiple started events with a single finished, that would give enough flexibility.
(Now the next start assumes that there is a missing finished. I guess this is an error handling logic now, so no one should depend on this.)
Bests,

Or another event which indicates that more tests will be run

You could already implement it like this:

if the user clicks run while tests are already running, remember that request in some queue and return a promise that will be resolved after the second test run
once the first test run is finished, fetch the next scheduled test run from the queue and run that
as a result, you'd send the events in this order: TestRunStartedEvent #1, ... , TestRunFinishedEvent #1, TestRunStartedEvent #2, ... , TestRunFinishedEvent #2. In other words: the events would make it look as if the user had requested the second test run immediately after the first test run (even though he really requested it during the first test run). This would also avoid having overlapping test runs, which may confuse Test Controllers.

Do you see any problems with this solution?

I had that solution but the problem the same: No UI feedback: When I start running a test you replace all the icons to blue/pending ones. That is what I'm missing from the second run. Either in case of your solution (which was my old solution) and in case my new solution I cannot achieve that the icon of tests/suites became blue/pending.
We can avoid the confusion by adding a new run event. With that I could send more test id's and you can change the icons: like TestRunExtendedEvent

Damn, I hadn't thought about the blue icons for scheduled tests. Looks like a TestRunExtendedEvent may indeed be the best solution.

I'm not sure about the naming though. extend, append, ...
And since we are talking about events...
I have this concept called 'static event'. It means basically that I don't have to do anything I already have the result of some tests/leafs. When a run of a suite starts at first I send those events and then I do the operation and send the rest of the events based on the result of the operation. Here is a tree.

Root

Suite1

Static1-1
Dynamic1-1

Suite2

Static2-1
Dynamic2-1

Events are the following in order:

TestRunStarted
TestSuiteEvent - running Suite1
TestEvent - running Static1-1
TestEvent - passed/errored/.. Static1-1
TestSuiteEvent - completed Suite1
TestSuiteEvent - running Suite2
TestEvent - running Static2-1
TestEvent - passed/errored/.. Static2-1
TestSuiteEvent - completed Suite2
TestSuiteEvent - running Suite1
TestEvent - running Dynamic1-1
TestEvent - passed/errored/.. Dynamic1-1
TestSuiteEvent - completed Suite1
TestSuiteEvent - running Suite2
TestEvent - running Dynamic2-1
TestEvent - passed/errored/.. Dynamic2-1
TestSuiteEvent - completed Suite2
TestRunFinishedEvent

The 'problem' here is 5 and 9. Sending those event's kills the blue/pending icon for the Dynamic1-1 and Dynamic2-1. (kills means changes to back to greyed normal). Eventually the tests were running so functionally it's ok, but not nice.
I could: not sending 5,9 and 10,14 but then I need some extra logic to check that other tests will be run under that suite, etc.. totally makes sense. But.. I'm a lazy person and I've tried (only on my machine) the following:

TestRunStarted
~TestSuiteEvent - running Suite1~
~TestEvent - running Static1-1~
TestEvent - passed/errored/.. Static1-1
~TestSuiteEvent - completed Suite1~
~TestSuiteEvent - running Suite2~
~TestEvent - running Static2-1~
TestEvent - passed/errored/.. Static2-1
~TestSuiteEvent - completed Suite2~
TestSuiteEvent - running Suite1
TestEvent - running Dynamic1-1
TestEvent - passed/errored/.. Dynamic1-1
TestSuiteEvent - completed Suite1
TestSuiteEvent - running Suite2
TestEvent - running Dynamic2-1
TestEvent - passed/errored/.. Dynamic2-1
TestSuiteEvent - completed Suite2
TestRunFinishedEvent

And it seems working as I expected and good for me. Can you approve this abbreviated usage?
(If yes, do I really need the TestRunStarted and TestRunFinishedEvent events at all for only static events? I guess yes because I can imagine TestRunFinishedEvent might indicates some post processing. Don't know)

I came up with a solution that I like more than having a new event:
First of all, let's see what happens when you simply report 2 separate (though overlapping) test runs: you'd send the 2 started events for both runs as soon as the user requests them and the 2 finished events as soon as the corresponding run is finished. The result would be that each started event colors its corresponding tests blue (good) but when the first run is finished, all blue icons would disappear - including those for the second test run (bad).
The problem is that when Test Explorer receives a TestRunFinishedEvent while multiple test runs are active, it doesn't know which test run is finished. I'd like to fix this by adding a testRunId property to all test run events. So when the TestRunFinishedEvent for the first run is received, only the icons for the first run are changed back to grey.
I think this should fix your problem, right?
As for sending test events without the corresponding suite events: yes, that is explicitly allowed (it's even mentioned in the documentation somewhere that the test suite events are optional).

As for sending test events without the corresponding suite events: yes, that is explicitly allowed (it's even mentioned in the documentation somewhere that the test suite events are optional).

Great, Nitpicking a bit:
Note: I do not send TestEvent state:running event for the static tests either. So I don't need those either, right?
And how about the TestRunStarted and Finished ones if I want to send static event, do I need those?

I came up with a solution that I like more than having a new event

Then I can forget the singleton promise-like solution (returning with the same promise at the second time as at the first time. And you at your side will handle it somehow.
It seems okay at first glance, but I will think a bit more about it.

I do not send TestEvent state:running event for the static tests either. So I don't need those either, right?

Correct.

And how about the TestRunStarted and Finished ones if I want to send static event, do I need those?

Currently you don't need them (I think - I've never tested this). However in that case it would just be a coincidence, not something I intentionally wanted to support.
Generally I'd recommend staying as close to the "normal" sequence of events as possible - something that works today may not be supported by Test Explorer in the future if it's something that I never really intended to support.

The latest version of Test Explorer's API contains the testRunId property for all test run events, so if an adapter uses this property, running multiple test runs in parallel should finally work without UI glitches.

It does something but not bullet proof yet.
Issue no.1:
When the first run finishes the stop button transforms to play button. (Even if I send back the same promise for both run.)

When the first run finishes the stop button transforms to play button.

Thanks, I fixed this in 2.19.1.

Hello, Still there is an issue. I start a long test and then I start shortly after another long test works. But If I start 3 long tests in a row the third one messes it up. :S

authors: hbenl matepek

repo: hbenl/vscode-test-explorer


text:
Remove focus on first element if disableSearch is set to true

Hi,
I would like to report a bug on the drop down menu if you disable the search, the first element has the background focused by default.
It is possible to disable this focus on the first element if search is disabled ?
Reproduction sandbox : https://codesandbox.io/s/awesome-haze-zbsdx?file=/src/App.js
version used: 4.1.8
Thanks :)

@PierrickG1 If search is disabled it's suppose to automatically focused on next available element so it will make it easy for screen readers any specific reason on why this should not happen?

closing this due to no response

repo: hc-oss/react-multi-select-component


text:
🛑 hcsc25 standby site is down

In 758560c, hcsc25 standby site (https://hcsc-25th.codeberg.page/) was down:

HTTP code: 424
Response time: 5800 ms

Resolved: hcsc25 standby site is back up in e91ef19.


text:
Emulator crashes immediately on Linux (debian bookworm)

The emulator crashes instantly on startup, but after many tries it did eventually start once (out of maybe two dozen tries). It crashes in /src/core/input_device.c:485, where SDL_WaitEvent(&event) is called in a new thread context at the same time another SDL activity is happening in the main thread.
The call happens in a function called thread_input_device(void *ptr) which is called from input_device_init like this: pthread_create(&input_device_pid, NULL, , NULL);
Using multithreading with SDL like this will result in crashes(only one thread can use SDL at a time). Perhaps a SDL_mutex can be used to coordinate use of SDL between the threads in the emulator.
Here is the crash output as run with gdb:
Starting program: /home/xxxxx/hdzero-goggle/build_emu/HDZGOGGLE
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6bfe6c0 (LWP 1579019)]
[INFO][rtc.c:rtc_init:186] rtc_init has NOT detected a battery
[INFO][rtc.c:rtc_init:190] rtc_init updating both clocks via settings
[New Thread 0x7ffff63fd6c0 (LWP 1579020)]
[New Thread 0x7ffff5bfc6c0 (LWP 1579021)]
[INFO][mcp3021.c:aduc_read_voltage:60] Voltage ADC is mcp
[ERROR][mcp3021.c:mcp_read_voltage:31] mcp_read_voltage: open error.
[New Thread 0x7ffff53fb6c0 (LWP 1579022)]
[INFO][common.c:bmi2_interface_init:95] I2C Interface
[ERROR][common.c:bmi2_error_codes_print_result:165] Error [-3] : Device not found error. It occurs when the device chip id is incorrectly read
[INFO][accel_gyro.c:init_bmi270:74] init_bmi270 done.
[INFO][accel_gyro.c:enable_bmi270:88] [Pass] BMI270 enabled.
[INFO][fans.c:fans_top_setspeed:24] fans_top_setspeed: 4
[New Thread 0x7ffff7fc17c0 (LWP 1579023)]
[New Thread 0x7ffff4bfa6c0 (LWP 1579024)]
Thread 5 "HDZGOGGLE" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff53fb6c0 (LWP 1579022)]
0x00007ffff7b688d9 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
(gdb) bt
#0  0x00007ffff7b688d9 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#1  0x00007ffff7c16b7b in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#2  0x00007ffff7c180eb in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#3  0x00007ffff7b62383 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007ffff7b626d9 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x000055555556037b in thread_input_device (ptr=0x0) at /home/xxxxx/hdzero-goggle/src/core/input_device.c:485
#6  0x00007ffff7e4d044 in start_thread (arg=) at ./nptl/pthread_create.c:442
#7  0x00007ffff7ecd61c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

I submitted https://github.com/hd-zero/hdzero-goggle/pull/392 to fix this. PLease review, test, and (hopefully) merge.

@lukolszewski Can you fix the PR #392 ?

#392 has been merged months ago. This issue can be closed as fixed.

authors: Master92 ligenxxxx lukolszewski

repo: hd-zero/hdzero-goggle


text:
Running with Bootstrap 3 & 4 in the same app, insane or possible?

We have a mature app using simple_form with Bootstrap 3. We are developing a new set of features where we would like to use Bootstrap 4 or maybe even 5 depending on when we launch the features, with the goal of eventually transitioning the old v3 views to use whatever new version we settle on.
Is there any suggested way of doing this? One option I guess would be to customize all of the wrappers in the generated simple_form bootstrap initializer (e.g. add a bs4_ prefix or something like that and then explicity add wrapper: :bs4_vertical_form or whatever in each call to simple form. I would like to avoid this if possible, but not if it's the only sane way.
I guess another option would be to remove the initializers and create two separate form builders and move all the initialization configuration code into the initialize method of each form builder. That's probably not great for performance but it may not be enough of an issue to matter.
Does anyone have any other ideas or suggestions? Thanks in advance.

Hey @prognostikos, we're looking to do something similar, i.e. have an app running both Bootstrap 3 and 5 while we transition pages in version 3 to version 5.
Did you come up with a solution?
I've been scratching my head looking at https://github.com/heartcombo/simple_form/blob/main/lib/simple_form.rb#L287-L290 but as the configuration is defined on the SimpleForm module it's not easy to have multiple configurations running at the same time.

@metade we ended up doing the second option - moving config out of initializers and into separate form builders. It doesn't seem to have much of an impact on performance.
It's not pretty, but here's what has worked:
class Bootstrap4FormBuilder < SimpleForm::FormBuilder
  def initialize(*)
    configure_boostrap4_wrappers
    super
    @object = convert_to_model(@object)
    @defaults = options[:defaults]
    @wrapper = SimpleForm.wrapper(options[:wrapper] || SimpleForm.default_wrapper)
  end

  def configure_boostrap4_wrappers
    # all of the config code from the initializers
  end
end

Thank you @prognostikos - that leaves us plenty to think about!

authors: metade prognostikos


text:
Add meta info of Label Control in text classification task

Is your feature request related to a problem? Please describe.
When I annotate text classification task, I want to add some additional text of the annotated label. This additional text is just confirmed by current annotated text, can't be listed beforehand.
Describe the solution you'd like
For example
I want to annotate following text within predefined labels Chemical Drug, Biologics and Vaccine
A compound 2-acetoxybenzoic acid can be used to treat Inflammation.

This is annotated Chemical Drug. But I want to add a tag aspirin on  this annotated label. This is not supported currently.
Describe alternatives you've considered
I formulate this text classification task as a NER task to annotate it. I use entity type as text type,  and select some words as region in text randomly and add tag what I required as meta info of this region.

Hi, @supercoderhawk ! Thanks for bringing it up. Do you think this option is something you're looking for?

Yes. If you bind this part to Label control, and I will appreciate it.

What do you mean exactly from binding it to Label control? do you want to streamline the flow in UI to create meta info right after drawing a span? Since technically, once you create meta as in the example above, it becomes connected to the labeled region.
Speaking of a more streamlined approach, you can alternatively attach <TextArea> tag to your label, then it gives you the handy way to create meta info attached to the Label, like in the screen bellow:

Please, check the flow with this labeling configuration, and happy to get your feedback on it!
<View>
  <Labels name="label" toName="text">
    <Label value="Chemical Drug" background="red"/>
    <Label value="Biologics" background="darkorange"/>
    <Label value="Vaccine" background="orange"/>
  </Labels>
  <TextArea name="transcription" toName="text" editable="true" perRegion="true" required="true" maxSubmissions="1" rows="5" placeholder="Meta Info" displayMode="region-list"/>
  <Text name="text" value="$text"/>
</View>

Sorry, I mislead you. I mean let Choice control be associated with (or binded with) meta info box, such as you first reply, not Lable control. When I select a Choice box, I can add meta info on it.

authors: niklub supercoderhawk

repo: heartexlabs/label-studio


text:
Disable Nested Entity Annotations "Named Entity Recognition" in "Natural Language Processing"

In the named entity recognition task, it seems that nested entities are allowed by default. To disable nested entity annotations, how can i set?

This is managed in the labeling configuration file.

Hey @yanwenjie1 — thank you for reaching out.
You can further customize the Named Entity Recognition (NER) template to suit your need.
Here's a link to our documentation on how to customize our Named Entity Recognition template https://labelstud.io/templates/named_entity.html
I'm closing this issue out and marked resolved.
In the meantime come join us on thecommunity slack if you have any further questions.

authors: erinmikailstaples hogepodge yanwenjie1


text:
Fix #48 Jekyll 4.0

Fixes #48 by adding support for Jekyll 4.x as well as  current >3.8.
I tested this by building the Jekyll-project in this git itself:
$ bundle exec jekyll build
Configuration file: /Users/erikw/src/github.com/erikw/the-plain/_config.yml
            Source: /Users/erikw/src/github.com/erikw/the-plain
       Destination: /Users/erikw/src/github.com/erikw/the-plain/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
                    done in 0.442 seconds.
 Auto-regeneration: disabled. Use --watch to enable.

and the test site looks just like before:

I also tested to use build from this PR branch with a completely different Jekyll project erikw/jekyll-4.x.x-test and it works there as well.
As a part of #hacktoberfest :)

@erikw thanks for the PR.

authors: erikw heiswayi

repo: heiswayi/the-plain


text:
Скласти таймлайн

Скласти список всіх (важливих) життєвих подій, визначних дат, досягнень, періодів, що дали приємний і неприємний досвід, тощо. В цьому конкретному випадку довгих списків не буває, натомість бувають погано згорнуті, тому пакуємо сюди все підряд, а про "лишні" події можна буде промовчати пізніше. Список повинен бути систематизованим і посортованим в такий спосіб, щоб читач швидко зрозумів "паттерн" і міг легко орієнтуватись в просторі і часі цього резюме.

done

repo: hekeemje/homepage