Distributed package doesn't have NCCL built in

环境：windows11 python3.10
按照要求安装了环境，pip install "modelscope[nlp]" -f https://modelscope.oss-cn-beijing.aliyuncs.com/releases/repo.html和pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118，运行报错Distributed package doesn't have NCCL built in,查询资料发现windows系统不支持NCCL 需要改为gloo，请问是在代码的哪一处改？或者有其他解决方法？

code:
from modelscope.pipelines import pipeline
from modelscope.utils.constant import Tasks
import os

if __name__ == '__main__':
    os.environ["PL_TORCH_DISTRIBUTED_BACKEND"] = "gloo"
    input = '程序员脱发用什么洗发水'
    model_id = 'damo/nlp_gpt3_text-generation_2.7B'
    pipe = pipeline(Tasks.text_generation, model=model_id)

    print(pipe(input, max_length=512))

log:
2023-06-20 21:10:48,866 - modelscope - INFO - PyTorch version 2.0.1+cu118 Found.
2023-06-20 21:10:48,867 - modelscope - INFO - TensorFlow version 2.12.0 Found.
2023-06-20 21:10:48,867 - modelscope - INFO - Loading ast index from C:\Users\69048\.cache\modelscope\ast_indexer
2023-06-20 21:10:48,912 - modelscope - INFO - Loading done! Current index file version is 1.6.1, with md5 9be2c5e65a02c287ccff03cfaafaca96 and a total number of 849 components indexed
2023-06-20 21:10:50,106 - modelscope - INFO - Model revision not specified, use the latest revision: v1.2.0
2023-06-20 21:10:52,063 - modelscope - INFO - PyTorch version 2.0.1+cu118 Found.
2023-06-20 21:10:52,064 - modelscope - INFO - TensorFlow version 2.12.0 Found.
2023-06-20 21:10:52,065 - modelscope - INFO - Loading ast index from C:\Users\69048\.cache\modelscope\ast_indexer
2023-06-20 21:10:52,110 - modelscope - INFO - Loading done! Current index file version is 1.6.1, with md5 9be2c5e65a02c287ccff03cfaafaca96 and a total number of 849 components indexed
using world size: 1, data-parallel-size: 1, tensor-model-parallel size: 1, pipeline-model-parallel size: 1
using torch.float32 for parameters ...
> initializing torch distributed ...
[W ..\torch\csrc\distributed\c10d\socket.cpp:601] [c10d] The client socket has failed to connect to [kubernetes.docker.internal]:29500 (system error: 10049 - �����������У�������ĵ�ַ��Ч��).
[W ..\torch\csrc\distributed\c10d\socket.cpp:601] [c10d] The client socket has failed to connect to [kubernetes.docker.internal]:29500 (system error: 10049 - �����������У�������ĵ�ַ��Ч��).
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
  File "C:\MyTool\python\python3.10.11\lib\multiprocessing\pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "C:\MyTool\python\python3.10.11\lib\multiprocessing\pool.py", line 48, in mapstar
    return list(map(*args))
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\pipelines\nlp\distributed_gpt3_pipeline.py", line 39, in _instantiate_one
    cls.model = DistributedGPT3(model_dir, rank, **kwargs)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\models\nlp\gpt3\distributed_gpt3.py", line 958, in __init__
    init_megatron_util(megatron_cfg, model_dir, rank=rank)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\utils\megatron_utils.py", line 64, in init_megatron_util
    initialize_megatron(megatron_cfg)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\megatron_util\initialize.py", line 70, in initialize_megatron
    finish_mpu_init()
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\megatron_util\initialize.py", line 51, in finish_mpu_init
    _initialize_distributed(master_ip, master_port)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\megatron_util\initialize.py", line 139, in _initialize_distributed
    torch.distributed.init_process_group(
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\torch\distributed\distributed_c10d.py", line 907, in init_process_group
    default_pg = _new_process_group_helper(
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\torch\distributed\distributed_c10d.py", line 1013, in _new_process_group_helper
    raise RuntimeError("Distributed package doesn't have NCCL " "built in")
RuntimeError: Distributed package doesn't have NCCL built in
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\utils\registry.py", line 212, in build_from_cfg
    return obj_cls(**args)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\pipelines\nlp\distributed_gpt3_pipeline.py", line 34, in __init__
    super().__init__(model, preprocessor=preprocessor, **kwargs)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\pipelines\base.py", line 466, in __init__
    self.model_pool.map(
  File "C:\MyTool\python\python3.10.11\lib\multiprocessing\pool.py", line 367, in map
    return self._map_async(func, iterable, mapstar, chunksize).get()
  File "C:\MyTool\python\python3.10.11\lib\multiprocessing\pool.py", line 774, in get
    raise self._value
RuntimeError: Distributed package doesn't have NCCL built in

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\MyTool\pycharm\PythonProject\modelTest\main.py", line 9, in <module>
    pipe = pipeline(Tasks.text_generation, model=model_id)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\pipelines\builder.py", line 140, in pipeline
    return build_pipeline(cfg, task_name=task)
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\pipelines\builder.py", line 56, in build_pipeline
    return build_from_cfg(
  File "C:\MyTool\pycharm\PythonProject\modelTest\venv\lib\site-packages\modelscope\utils\registry.py", line 215, in build_from_cfg
    raise type(e)(f'{obj_cls.__name__}: {e}')
RuntimeError: DistributedGPT3Pipeline: Distributed package doesn't have NCCL built in

Any suggestions?

can you use wsl  in Windows to run the code in linux env, we haven't tested distributed function on Windows


"You exceeded your current quota, please check your plan and billing details."

The transcript works but it gives me this error. Where can I pay for the plan? Thanks.

The transcript works but it gives me this error. Where can I pay for the plan? Thanks.

I assume you need to increase the limits on OpenAI API (soft,hard).
Goodluck 😀

do we need open ai subscription

Sure, the repo used Whisper for live transcription.

do you fixed this problem? I meet the same one, how to deal with it?


HELP, im having a issue sending large values trought Firebase Database

Hello, im having a small issue when using the command:
if (Firebase.setString(fbdo2, path , data))
Im trying to send in huge strings that have from 4k to 11k letters.
it works fine the first 2 times, but after that it gets a weird bug, and resets the ESP32.
I always get this same error:
bort() was called at PC 0x4017d0d3 on core 1
Backtrace: 0x4009140c:0x3ffb19a0 0x4009163d:0x3ffb19c0 0x4017d0d3:0x3ffb19e0 0x4017d11a:0x3ffb1a00 0x4017c02f:0x3ffb1a20 0x4017c13a:0x3ffb1a40 0x4017c0d9:0x3ffb1a60 0x400d98fd:0x3ffb1a80 0x400ddd07:0x3ffb1aa0 0x400de928:0x3ffb1d70 0x400dee91:0x3ffb1d90 0x400def47:0x3ffb1dc0 0x400df0ca:0x3ffb1e70 0x400df135:0x3ffb1f30 0x400d4eff:0x3ffb1f50 0x400d2d56:0x3ffb1f70 0x400eac01:0x3ffb1fb0 0x4008db55:0x3ffb1fd0
I checked the backtracer and it comes back to the line i first posted.
Can someone please help me fix this issue?
Also im currently using the Firebase ESP32 Client Version 3.8.22

Memory is not sufficient in your device cause memory allocation failed.
It' not possible to  do that in embedded device ram.
You can store large file in flash or sd by using this.


Breaking: Rename cdp connector to chrome

Work on #361

Renaming cdp to chrome because it is more meaningful and we are using cdp in the shared part for those connectors that rely in the protocol.
This should help with #361 and the first run experience for users.


Format json config

To make it easier to read json.
(In the future, it will not be necessary for users to look at the json directly.)

no need because of

it will not be necessary for users to look at the json directly


Roadmap: Job Support

ETA for Public Preview: end of June 2023
In ACA, customers have no way of deploying containers that should terminate after completion. To run this type of workload, developers need to be able to deploy a specific resource type known as a Job. Jobs perform one or more tasks to completion and are finite resources unlike container app objects which continuously run until explicitly deleted.
Initial scope will include support for the following:

Manually triggered jobs
Jobs which run on a schedule
A subset of event-triggers supported by KEDA

Note: Additional due diligence may be required to ensure support for Azure Pipeline agents and/or Azure DevOps agents as part of this feature
Related requests:

https://github.com/microsoft/azure-container-apps/issues/24
https://github.com/microsoft/azure-container-apps/issues/87

#176 appears to be a similar request too

This would be excellent. I have a batch process (a data downloader / processor) that I would love to run via a CRON job. The current ACA / Dapr approach isn't really suitable, but this sounds like it would be an excellent fit.

Hello :)
Is there any ETA on this?

@JonasCordsen Thanks for asking! I just updated the description, and we should have Jobs support out in public preview by the end of this quarter (end of March 2023).

This is awesome news. Thanks @SophCarp

Is there any detail on what "subset of event-triggers supported by KEDA" means for the upcoming preview? ;)

This is awesome! Just for clarification. I have a scaler using azure service bus but I need to allow the app to run up to 30 minutes. This would allow me to continue using an azure service bus trigger but also specify activeDeadlineSeconds (https://keda.sh/docs/2.9/concepts/scaling-jobs/) to handle the longer time limit right? The longer limit is rarely needed since most of the time 5 minutes or less is sufficient. If the app completes and exits in 5 minutes will the instance be removed (scaled down) or does the scaler wait  activeDeadlineSeconds before testing and removing it?

Updating ETA in original post to reflect latest status. Now targeting public preview in Q2 2023.

Until this new feature is available is it possible to run long-running jobs as a static # of instances (no scaler). This link states that ACA supports long running/background tasks however when I run a single instance it gets killed every few minutes and then restarted. https://learn.microsoft.com/en-us/azure/container-apps/compare-options#azure-container-apps. Are there additional requirements such as health probes? This app uses an Azure Service Bus queue to perform processing that can take a few seconds or up to over 30 minutes to process so I can't have the container killed mid-process. Thanks in advance for the help!

@ronlhayes what's your scaling rule and mix/max replicas?

We had a similar issues, that every few minutes the container gets killed and restarted. If you don't have health probes yet, I would suggest to enable them.

@kjeske - I tried using no scaling rule with a single (min/max = 1) replica. Is there an automatic KEDA monitor such as cpu usage. This app is waiting for ASB messages so idle (not active) for testing.   initions-soeren - Yes, I'll try adding health monitors. Curious what the assumption is when no health monitors are defined (assume ok, watch for app exiting)?

I have all health check probes enabled (startup, readyness, liveness) and my container running a NodeJS app that is a long background process that emits ASB events every minute gets killed always after 4 minutes of running. ChatGPT says that there is a timeout option in advanced settings, but I cannot see it in portal.azure.com.
Question is weather Azure Container Apps is really well suited to host scalable background processes? if so, how I can make it running as long as health check probes are returning ok status?

Updating ETA in original post to reflect latest status. Now targeting public preview in Q2 2023.

@anthonychu, is this still a realistic ETA for the preview? Do you have any more information on progress?
Thx!

I just spotted "Container App Jobs (Preview)" in the portal, really looking forward to the next standup to hear the details on this!

Seen in docs too
https://learn.microsoft.com/en-us/azure/templates/microsoft.app/2022-11-01-preview/jobs?pivots=deployment-language-bicep

Seen in docs too https://learn.microsoft.com/en-us/azure/templates/microsoft.app/2022-11-01-preview/jobs?pivots=deployment-language-bicep

This look promising, let's test this :)

@anthonychu @vinisoto
Can we get environment variables inside each running job container populated similar to normal container apps like
CONTAINER_JOB_NAME=myjobName
CONTAINER_JOB_RUN_NAME=myjobName--7fbbb48d64-hghtz
This would help a lot to connect runs with process logic

Is there an ETA to make this feature Generally Available?

This would be excellent. I have a batch process (a data downloader / processor) that I would love to run via a CRON job. The current ACA / Dapr approach isn't really suitable, but this sounds like it would be an excellent fit.

We ported one of our apps to use it last week and it's working brilliantly. Thanks very much 🔥

Do jobs support Storage like plain Apps (Azure File)?

@sebaguozden ACA Jobs is now GA: https://azure.microsoft.com/en-us/updates/generally-available-azure-container-apps-jobs/

we have tested azure container app jobs it works like a charm.
My Question is when scale set to zero. How does It assume the process has been completed and scale in the instance.


Content changes for dashboard

Changes for content as specified by Ralph.

We should merge this now for the sake of the demo, so :+1:
--
…but it still feels a bit weird. There is now the concept of "automatically submitted" as well as "eligible", which are both words for the same thing.


Handling of very large (>1GB) binary attachments

In MHD (Mobile access to Health Documents) [1], which builds on the FHIR standard, there is the need to be able to send large binary attachments (contained) in the DocumentReference resource. Eg. if a mobile client wants to store a multi-gigabyte video file of eg. an operation to a repository. Of course using a reference to a binary resource might be a solution in some cases for this but this might not always be possible when using a mobile client because of network (ie. NAT) restrictions when retrieving the binary resource. Also we want to limit the complexity for the client side.
Currently HAPI-FHIR will read the entire data stream into memory when parsing the JSON/XML object. For very large resources this can be a problem on servers which have to handle many clients in parallel and to accomplish this in a resource efficient manner it would be good if the binary resource could be streamed directly to disk. To accomplish this we propose to extend HAPI-FHIR to allow to set the XML and JSON parsers that FhirContext creates with newJsonParser and newXmlParser much like it already allows to set the RestfulClientFactory.
If this is okay with you we would like to implement his feature as a contribution to HAPI-FHIR!
[1] http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)

This sounds awesome, I'm totally supportive.

Ps- it sounds like you have a sensible design in mind... but feel free to reach out if you want to bounce ideas off.

Great! We will think about the implementation and get back to you if we have any questions!

What about approaching this in a manner similar to MTOM/XOP used with SOAP??
·         Client detects when a native content element (picture, video, etc) is larger than a specified threshold
o   Client replaces that element with a “pointer” to…
o   Client includes the native content as a MIME attachment
·         Server sees the “pointer” and uses the MIME attachment, somehow, to resolve the unmarshalled native content element.
This approach using MIME attachments has several advantages
·         There no longer is the +1/3 size expansion needed for Base64 encoding
·         Since the attachment is a separate part of the HTTP stream, it is pretty easy to treat it differently (stream to output, send to media server, etc) from the primary XML/JSON payload
Don’t know whether something like this could be done without getting the FHIR spec updated….
Thoughts?
From: jodue<EMAIL_ADDRESS>Sent: Wednesday, February 8, 2017 2:49 AM
To: jamesagnew/hapi-fhir<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [jamesagnew/hapi-fhir] Handling of very large (>1GB) binary attachments (#554)
Great! We will think about the implementation and get back to you if we have any questions!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/jamesagnew/hapi-fhir/issues/554#issuecomment-278294688, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AM9nghJnTYI_LkozLd0vTUSzT5wMhSHFks5raZ2ugaJpZM4L6iOk.

We thought about that as well. Using a multipart POST to submit large binary bundles would definitely have several advantages. However, this is not specified in the FHIR/MHD standard as of now so the only two standardized ways of doing this now are by either submitting the resource directly base64 encoded or by submitting an URL which in turn has the described downside that the client must be able to provide the data which is probably not desirable in some cases.
This seems to be a problem that definitely has to be solved in the standard the future as both possible solutions appear to be insufficient to handle large binary files properly. I would agree that the best solution would be a multipart stream which would allow us to first parse the FHIRobjects and then stream the binary data directly to disk.
For now i think we should try to handle this within the standard as best as possible. Maybe we should bring this to the attention of the MHD/FHIR committee so that it can be adressed in the near future?!

Bill certainly does raise an important point. If your payload is potentially a gigabyte worth of video, putting it as-is in a resource is really not a great option, since no matter how efficient you are, it will be base64 encoded and therefore take up way more bandwidth than it needs to.
FHIR does of course already have the concept of the /Binary endpoint, which can be used to transfer binary media. One possible way of achieving what Bill is describing without needing to resort to multipart mime payloads could be to use the Binary endpoint to store the payload, coupled with an Attachment datatype with a URL reference to that payload.
HAPI's server doesn't currently have a super-efficient way of dealing with /Binary (it's currently parsed into a Binary resource) but that could definitely be improved, and wouldn't require spec changes.

This is definitely an interesting alternative, thanks for pointing this our!
We still have to be prepared to receive rather large binary resources via bundle (base64 encoded data wastes about 1/3 of data worst case) but you made a good point as this is already covered by FHIR! I did not think about that because MHD does not discuss this issue at all!
Coming back to my original post, i think we also should improve the efficiency of the handling of binary resources. Making it possible to (much in the same way as with base64 encoded binary resources within a bundle) directly stream the content to disk and to never hold the entire resource in memory as they could sometimes get rather large!

So, I guess there are two sides to this:
If you want to look at improving the /Binary endpoint in a server, probably the easiest way to do this would be with a custom interceptor that handles the request before the rest of the framework gets to it. I think this would be quite easy to write actually.
If you want to look at enhancing the parser, I guess ultimately what you need is some way of registering a handler for binary content so that the handler would get it rather than the parsed object model. Unless you're envisioning some sort of streaming API like SAX, replacing the current parsed object model (which acts more like DOM).
Either way, there is one big caveat: The XML parser internally works on a stream, so having an efficient streaming handler is easy. On the other hand, the JSON parser does not work on a stream, but rather parses the JSON object tree into memory entirely before translating it into FHIR. We do this because of a JSON limitation: JSON hashes do not have ordered keys, so you need to be able to handle properties in an object coming in an arbitrary order. This isn't an insurmountable problem, but isn't trivial either..


Fix card-control colors

Card-control styles only adapt colors for dark backgrounds.
The following example is therefore not displayed correctly:

    <post-card-control label="Label" type="checkbox"> </post-card-control>

The issue is fixed for the web component on browsers that do not the :host-context selector (#3358).

@alizedebray can you check if this is still a valid issue? Otherwise you can close it.

@gfellerph Yes, this issue is sill relevant.


Duplicated Suggestion in Python

Does this issue occur when all extensions are disabled?:  No , offiocial Python package needed

VS Code Version: 1.73.1 (system stetup)
OS Version:  Win 10

Steps to Reproduce:

start a clean VS code without any settings and packages
install Microsoft's official Python package
it will show duplicated suggestions in Jupyter Notebook

there's probably a hint for finding the bug :

open Jupyter Notebook
disable Pylance
restart VS code
enable Pylance again.
the duplicated suggestions disappear


Reduce typo count.

@dfrg Ping per your directions.

“Identifer” and “horizonal” seem to be favorites of mine :) Thanks!


custom vs core encode symbols differently

using the core encoding symbols whether interned or not have no namespace name prefixed to the symbol name. This is not the case for the custom encoder which prefixes the namespace name to the symbol name if the symbol has been interned. This behavior is inconsistent with the core behavior.
Is core supposed to be that much faster that resolving name spaces for symbols is considered a hit?

Do you have an example of the inconsistent behavior?

Crap...and I know better too.
Yes... here is one:
user> (def foo 'bar)
#'user/foo
user> (cheshire.core/parse-string (cheshire.core/encode (list 'foo 'bar)))
["foo" "bar"]
user> (cheshire.core/parse-string (cheshire.custom/encode (list 'foo 'bar)))
["user/foo" "bar"]
user>
(William Hidden) https://sites.google.com/site/hiddenhome/
On Wed, Jan 11, 2012 at 6:37 PM, Lee <
<EMAIL_ADDRESS>
wrote:

Do you have an example of the inconsistent behavior?

Reply to this email directly or view it on GitHub:
https://github.com/dakrone/cheshire/issues/14#issuecomment-3455754

I didn't catch this, but I can have it do resolves like this:
user=> (require 'cheshire.custom)
user=> (require 'cheshire.core)
user=> (def foo 'bar)
#'user/foo
user=> (cheshire.core/parse-string (cheshire.core/encode (list 'foo 'bar)))
["user/foo" "bar"]
user=> (cheshire.core/parse-string (cheshire.custom/encode (list 'foo 'bar)))
["user/foo" "bar"]

Would that be preferable?

I think it would be consistent and I would prefer that it be encoded this
way.
(William Hidden) https://sites.google.com/site/hiddenhome/
On Wed, Jan 11, 2012 at 6:50 PM, Lee <
<EMAIL_ADDRESS>
wrote:

I didn't catch this, but I can have it do resolves like this:
user=> (require 'cheshire.custom)
user=> (require 'cheshire.core)
user=> (def foo 'bar)
#'user/foo
user=> (cheshire.core/parse-string (cheshire.core/encode (list 'foo 'bar)))
["user/foo" "bar"]
user=> (cheshire.core/parse-string (cheshire.custom/encode (list 'foo
'bar)))
["user/foo" "bar"]

Would that be preferable?

Reply to this email directly or view it on GitHub:
https://github.com/dakrone/cheshire/issues/14#issuecomment-3455922

I agree, I'll release another version (should have waited before doing the other one)

Fixed in 2.0.6.


Foliage only visible from one direction

for example foliage visible from north is not visible from south.
https://github.com/spimort/TerraBrush/assets/61717342/b193fbed-0e38-4c91-b020-9f73dad03f80

nvm, i needed to disable cull mode on the mesh material :)


missing the key code in ipmt_transformer.py

in IMPTnetwork.py L7, it said 'from model.ipmt_transformer import IPMTransformer', but i can not find the definition of the function IPMTransformer in model.ipmt_transformer.

metoo，


Update gogo/protobuf vendored dep

for CVE-2021-3121

Not sure why codegen felt the need to muck with the CRD manifests, but it's harmless so :shrug:
/assign @abutcher

Not sure why codegen felt the need to muck with the CRD manifests

Well, verify didn't like that. make manifests restored it. Again :shrug:

/test e2e

/lgtm

/test e2e

/test e2e

/test e2e


Upgrade Micrometer to version 1.0.11

Upgrade Micrometer from version 1.0.0 to 1.0.11. Version 1.0.11 is the last patch in the 1.0.x line.
Since Micrometer releases follow semantic versioning (see their support policy), 1.0.11 should not contain breaking changes.
An upgrade to the latest release (1.3.0) could be considered instead.

Travis CI failed to install JDK 11... :thinking:

no longer relevant


NumberFormatException when set a String or clear field in networkDelay (minor)

Describe the bug
NumberFormatException when set a String or clear field in networkDelay.
To Reproduce
Given i go to Rest method update
When i set networkDelay to String or clear the field (Ex.: Test)
And apply the changes (click on "Update method")
Then an exception is showed to user.
Expected behavior
It would be interesting to show an error message to the user or block the field to accept only numbers.
Screenshots

Tested in:

OS: Microsoft Windows 10 Pro Build number 17134
Browser: Google Chrome 70.0.3538.110 (Versão oficial) 64 bits
Version  Castle Mock 1.34
Apache TomCat 9.0.14

Thank you @tiagoguimaraesss for raising this issue. I will take a look at it as soon as I can.
Best regards,
Karl Dahlgren

This makes me very happy to hear @tiagoguimaraesss.
Thank you very much! Great start for 2019!
Once again, thank you for creating the ticket. Don't hesitate to contact me if you need any support or experience any other issues.
Happy new year!
Best regards,
Karl Dahlgren


Single hotel page

Please create single hotel page structure with basic components (Relay container, visual components for header, description, rooms, ...). This issue is not about design but about proper components structure (you'll design it properly later).
~For this, you'll need this MR chatbot/kiwi-chatbot-infrastructure!538. In case the MR will not be merged yet please use mock data.~
zpl://screen?sid=5a1edf0356c752b71a613634&pid=5a1308cdae8ae89cae5c15af

Until "Hotel detail fields" issue in our GraphQL gets resolved, I'm mocking the data.

Not completely done but I will create new tasks since the description of issues doesn't work very well and we have different direction now...


Add cli argument --disable-enforced-types

This kinda implements the request made in #104, as it makes it possible to disable the default enforced types roles and rolebindings with an additional cli argument --disable-enforced-types that can be used with the hnc-manager. The old behaviour (using enforcedTypes) is the default.
Tested: added new e2e tests and checked them against a vanilla k8s cluster. No issues found.

I'll try to implement the per-object-level filtering proposed by @adrianludwin in https://github.com/kubernetes-sigs/hierarchical-namespaces/issues/104#issuecomment-946865077 in another PR soon.
If there are any issues with this PR, please let me know. This being my first contribution to a k8s / cncf project, I've probably missed something ;)

Hmm, do we still need this if we have #125 ? I far prefer #125 to this change.

As discussed on #125 , we'll go with that solution instead of this one.
/close


Wrong player stats

Both CasualStats and CompetitiveStats are using List<> when it should be IEnumerable<> so that the extensions work.

List<T> Implements IEnumerable<T> through ICollection<T> and IList<T>.
The extensions should work just fine.


DCOS-48338: add placement form section

Add placement form section to jobs form.
Testing
Using an OSS cluster:

Go to jobs form > Placement tab
Try adding a placement constraint to a job (it should work)
Try submitting with an incomplete constraint/some fields left unfilled (you should see validation messages)
Try adding a constraint in the form and then changing it in the JSON editor so that constraints is no longer an array (you should see validation message)

Trade-offs
Dependencies
This is the OSS implementation of the placement section - DCOS-48338 is not complete without the EE implementation as well.
Screenshots

Translation conflicts

@GeorgiSTodorov That's happening because the EE PR where those translations come from is not merged yet. If that merges before this does, I'll update it. Otherwise the EE PR that contains those message will need to have a follow up dcos-ui PR for message extraction.

I still think that the double message can be removed - https://github.com/dcos/dcos-ui/pull/3831#pullrequestreview-229936528 .

Looks as though the duplicate translation issue was resolved in the other PR. We should run a lingui extract once again after.

:tada: This PR is included in version 2.95.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Added DisableCulexMusic flag. YouTube likes to flag and demonetize VoDs containing it.

Added the rest of the music groups as well, including "no change from the overworld" BattleMusic.CURRENT
Separated music group ID from can_run flag bits.

I mostly decided to do this one little thing, but if I continue, I'd like to:

Add a flag for all formations to have shuffled music
Add a flag for all songs to have a chance to be in one of the 8 groups

Optionally only replaces the ordinarily unused groups

(Battle music is limited to 8 different Songs, but they don't have to be the 8 we're used to! See data/bosses.py)

Add a separate instance of RNG so a cosmetic change such as this (or palette) doesn't affect item placement/race viability.

I'm not sure about this change, specifically the new flag...
While I don't have an issue with potentially allowing other songs to be used in the shuffle, I'm not a huge fan of adding more flags to disable specific music tracks because of an external site being dumb.  The number of flags is already large and cluttered to begin with, and this could happen with any track in the game.  If we add a flag for Culex's music, where does it stop?
My feeling is it's not the randomizer's job to account for YouTube's ridiculous content policing.

I'm not sure about this change, specifically the new flag...
While I don't have an issue with potentially allowing other songs to be used in the shuffle, I'm not a huge fan of adding more flags to disable specific music tracks because of an external site being dumb. The number of flags is already large and cluttered to begin with, and this could happen with any track in the game. If we add a flag for Culex's music, where does it stop?
My feeling is it's not the randomizer's job to account for YouTube's ridiculous content policing.

I have plans to build a stronger cosmetics interface during the next major release that could have an option to pick and choose which songs you want included in the shuffle. The flag interface is cluttered as it is and will be undergoing a massive overhaul.

That's fair! I was thinking about the messiness when I was working on it, but I figured it would be more worth it for bigger youtubers to desire to play the game and spread its popularity than hold the feature up while overhauling the flags. A little mess now for a medium gain, rather than a large detangling for medium gain.

It doesn't seem like too big of a mess from the user's perspective, although the UI could be a lot nicer. From a flag's perspective, well people endure much worse :P

By no means was this an attempt at a permanent fix for YouTube's bs nor for music selection/cosmetic things. :)

Just as an update, I've got this basically working in the upcoming version 9.0.0 - this hasn't been forgotten about and cosmetics will be separated from flags entirely, including an option to pick and choose which songs you want in your random song pool. I've gotten most of the front end working this past weekend to go with the backend I wrote about a month ago.

The next patch will be a major rewrite which has a new flag UI for selecting any songs, so this won't be needed there.


Encoding Error when publishing pacts

We currently face an encoding problem while publishing pacts to the pact broker from our npm build on a gitlab CI runner.
The same script works fine from our local windows machines and has worked fine on gitlab (unix), too, until we introduced the "€" symbol into the pacts.
This is the stacktrace:
    Could not publish pact:
    /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/ruby/lib/ruby/gems/2.2.0/gems/bundler-1.9.9/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /builds/renew/ui/node_modules in PATH, mode 040777

    Error making request - Encoding::InvalidByteSequenceError "\xE2" on US-ASCII /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/pact_file.rb:28:in `pact_hash', attempt 1 of 3

    Error making request - Encoding::InvalidByteSequenceError "\xE2" on US-ASCII /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/pact_file.rb:28:in `pact_hash', attempt 2 of 3

    Error making request - Encoding::InvalidByteSequenceError "\xE2" on US-ASCII /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/pact_file.rb:28:in `pact_hash', attempt 3 of 3

    /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/json-2.1.0/lib/json/common.rb:156:in `encode'
    :
    "\xE2" on US-ASCII
     (
    Encoding::InvalidByteSequenceError
    )

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/json-2.1.0/lib/json/common.rb:156:in `initialize'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/json-2.1.0/lib/json/common.rb:156:in `new'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/json-2.1.0/lib/json/common.rb:156:in `parse'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/pact_file.rb:28:in `pact_hash'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/pact_file.rb:20:in `consumer_name'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:98:in `consumer_name'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:80:in `rescue in tag_consumer_version'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:73:in `tag_consumer_version'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:68:in `block in apply_tags'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:67:in `each'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:67:in `all?'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:67:in `apply_tags'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:27:in `call'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/publish_pacts.rb:13:in `call'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/cli/broker.rb:125:in `publish_pacts'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/cli/broker.rb:51:in `publish'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/thor-0.20.0/lib/thor/command.rb:27:in `run'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/thor-0.20.0/lib/thor/invocation.rb:126:in `invoke_command'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/thor-0.20.0/lib/thor.rb:387:in `dispatch'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/thor-0.20.0/lib/thor/base.rb:466:in `start'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.14.0/lib/pact_broker/client/cli/custom_thor.rb:15:in `start'

    	from /builds/renew/ui/node_modules/@pact-foundation/pact-standalone/platforms/linux-x64/lib/app/pact-broker.rb:28:in `<main>'

Any ideas how we can address this issue?

@bethesque any ideas?  Seems like it's the standalone.  Why is it using US-ASCII?  Figured everything would be in UTF8 no?

What version of everything are you using @thombergs? There was a problem with this that got fixed in a more recent version. Can you please reproduce with the pact-ruby-standalone-e2e-example project?

@bethesque I will try with the latest versions and if it still fails create a minimal example to reproduce.

@thombergs any updates on this?

I finally took the time to create a minimal example. See https://github.com/thombergs/pact-test.
There's a single pact file with a single interaction, that contains a '€' symbol in the body.
When calling npm publish:pacts the file publish-pacts.js is called which publishes the pact file to a Pact Broker.
This task works OK on a windows machine but fails in our unix-based Gitlab CI environment with the error above. Without the € symbol, it works under unix as well.
Our current workaround is replacing some special characters with their unicode escape string (see method replaceSpecialChars in the javascript file). But this is a flakey workaround.

amazing, thank you. I'll take a look at this and see what's going on.

It'll be a problem with the ruby code.

That's what I thought, but I'm surprised it happens only on Linux?
On Fri., 16 Mar. 2018, 8:01 am Beth Skurrie<EMAIL_ADDRESS>wrote:

It'll be a problem with the ruby code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pact-foundation/pact-node/issues/75#issuecomment-373521479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjA5OH-Kn43Li59599wlTv5nt7WMSnMks5tetaYgaJpZM4SYB7M
.

Me too. The Travelling Ruby package is different for each of the operating systems however, so it may have to do with the linux one, or some environment variables on the linux one.

@thombergs could you try setting the environment variable LANG="UTF-8" as per the External encoding section in https://ruby-doc.org/core-2.2.0/Encoding.html ?

@bethesque doing an export LANG="UTF-8" before running the script doesn't change anything, sadly.

I'm just doing some refactoring in a pact go and came across a similar regression (on Linux) during provider verification. I'll get it into shape and share here. It once worked, I'm almost positive

OK, here's the broken build that fails provider verification with the following pact.
{
  "consumer": {
    "name": "billy"
  },
  "provider": {
    "name": "bobby"
  },
  "interactions": [
    {
      "description": "A request to login with user 'billy'",
      "providerState": "User billy exists",
      "request": {
        "method": "POST",
        "path": "/users/login",
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "password": "issilly",
          "username": "Jean-Marie de La Beaujardière😀😍"
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "user": {
            "name": "Jean-Marie de La Beaujardière😀😍",
            "type": "admin"
          }
        },
        "matchingRules": {
          "$.body": {
            "match": "type"
          },
          "$.body.user.type": {
            "match": "regex",
            "regex": "admin|user|guest"
          }
        }
      }
    },
    {
      "description": "A request to login with user 'billy'",
      "providerState": "User billy does not exist",
      "request": {
        "method": "POST",
        "path": "/users/login",
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "password": "issilly",
          "username": "Jean-Marie de La Beaujardière😀😍"
        }
      },
      "response": {
        "status": 404,
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        }
      }
    },
    {
      "description": "A request to login with user 'billy'",
      "providerState": "User billy is unauthorized",
      "request": {
        "method": "POST",
        "path": "/users/login",
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "password": "issilly",
          "username": "Jean-Marie de La Beaujardière😀😍"
        }
      },
      "response": {
        "status": 401,
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

Interestingly, I can't reproduce that issue with my fork at https://github.com/mefellows/pact-ruby-standalone-e2e-example (both Mac OSX and a Docker environment). I wonder if it's because Rack is part of the framework, and therefore the external HTTP request isn't actually being made?

The standalone e2e executes real HTTP requests. It's this one that doesn't. https://github.com/pact-foundation/pact-ruby-e2e-example

Isn't it linux that has the issue anyway?

Hmm good point. Yes it's Linux, but I've not managed to reproduce it even in a Linux docker container with the standalone example from above. So perhaps it's how we're executing the standalone?
The issue is exactly the one from https://github.com/pact-foundation/pact-go/issues/41 and https://github.com/pact-foundation/pact-go/issues/36.

OK update. Adding Encoding.default_external = 'UTF-8' beneath the requires in pact/lib/vendor/ruby/2.2.0/gems/json-2.1.0/lib/json/common.rb fixes this for my Pact tests. More investigation coming, perhaps it's an env var like LANG configuring it.

Digger further...
root@3b6b4b83fead:/go/src/github.com/pact-foundation/pact-go# ./build/pact/lib/ruby/bin/ruby  -e 'p Encoding.default_external'
#<Encoding:US-ASCII>
root@3b6b4b83fead:/go/src/github.com/pact-foundation/pact-go# LC_ALL=en_US.UTF-8 ./build/pact/lib/ruby/bin/ruby  -e 'p Encoding.default_external'
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
#<Encoding:US-ASCII>
root@3b6b4b83fead:/go/src/github.com/pact-foundation/pact-go# LC_ALL= LANG=en_US.UTF-8 ./build/pact/lib/ruby/bin/ruby  -e 'p Encoding.default_external'
#<Encoding:US-ASCII>
root@3b6b4b83fead:/go/src/github.com/pact-foundation/pact-go# LC_ALL=C LANG=en_US.UTF-8 ./build/pact/lib/ruby/bin/ruby  -e 'p Encoding.default_external'
#<Encoding:US-ASCII>
root@3b6b4b83fead:/go/src/github.com/pact-foundation/pact-go# LC_ALL=en_US.UTF-8 LANG=C ./build/pact/lib/ruby/bin/ruby  -e 'p Encoding.default_external'
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
#<Encoding:US-ASCII>

OK! Looks like it might be an OS specific thing, which would explain why the standalone test works - it's a slightly different linux variant.
setting LANG=C.UTF-8 fixes the issue for me locally, i'll validate with a Wercker build for Pact Go later.
This now begs the question - should the framework care about this or not? Also, as most wrapper libraries will be kicking off the process execution, we now need to select which, if not all, environment variables come through (my default position will be to pass it through).

We should explicitly set it to UTF8 as that should be our baseline.
On Tue, Mar 20, 2018 at 1:03 PM Matt Fellows<EMAIL_ADDRESS>wrote:

OK! Looks like it might be an OS specific thing, which would explain why
the standalone test works - it's a slightly different linux variant.
setting LANG=C.UTF-8 fixes the issue for me locally, i'll validate with a
Wercker build for Pact Go later.
This now begs the question - should the framework care about this or not?
Also, as most wrapper libraries will be kicking off the process execution,
we now need to select which, if not all, environment variables come through
(my default position will be to pass it through).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pact-foundation/pact-node/issues/75#issuecomment-374447104,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjA5K39FWWYoNUg73hMBi3pUS37Bhohks5tgGNagaJpZM4SYB7M
.

Is it possible that someone may want a different encoding? Wondering if we should set it to UTF-8 if it is not already set.?

@thombergs can you see if setting LANG=C.UTF-8 works for you too?

My Ubuntu machine has
$ echo $LANG
en_AU.UTF-8

Back from lunch - so yeah, it totally fixed it in the latest Pact Go build: https://app.wercker.com/Pact-Foundation/pact-go/runs/build/5ab06ebbdfd4d200017900c7?step=5ab06ee5e368b50001097df7

Beth, the web works in UTF8, so I'd doubt anyone would willingly try to get
ASCII encoding or windows ones (shudder)
On Tue, Mar 20, 2018 at 2:08 PM Matt Fellows<EMAIL_ADDRESS>wrote:

Back from lunch - so yeah, it totally fixed it in the latest Pact Go
build:
https://app.wercker.com/Pact-Foundation/pact-go/runs/build/5ab06ebbdfd4d200017900c7?step=5ab06ee5e368b50001097df7
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pact-foundation/pact-node/issues/75#issuecomment-374457992,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjA5PCfgWO42BooCLVQR9kz8frC6dhlks5tgHKtgaJpZM4SYB7M
.

That LANG definition looks correct, however in the official golang (Debian stretch) image for example, this is not respected at all. So unfortunately I'm not sure even env vars will solve the problem. I'll investigate a bit later to confirm this, perhaps it's just a matter of ensuring the system is properly configured for a locale.
I'm leaning towards forcing UTF-8, but I'm not yet fully aware of the impact across all tools/languages this might produce.
Documentation might be the next best option.

I'm inclined to agree with @mboudreau on this one. Let's default it to UTF-8 (I'll set it in the ruby code so that people's default locale won't screw with it), and if someone wants a different encoding, we'll deal with it then via a different mechanism (eg command line parameter). I'm guessing there is a very low chance of anyone wanting a different encoding, as Michel points out.

I tend to agree. Just as an aside, this issue had encoding set to ASCII-8BIT. So we might need to be agile if it comes up (and probably worth a documentation note across projects).

I guess the other option is that we could print out a large and ugly warning when the environment variable is anything other than UTF-8. I don't think people tend to read warning messages however!

FYI I've reproduced this on Windows too (seems to be the activity of the week for us contributors). I just got a working build but removing the UTF-8 stuff. I then tested on a local Windows 10 VM:
PS C:\go\src\github.com\pact-foundation\pact-go> $env:LANG="utf-8"
PS C:\go\src\github.com\pact-foundation\pact-go> C:\pact\pact\lib\ruby\bin\ruby  -e 'p Encoding.default_external'
#<Encoding:IBM437>

Pretty much everything I tried ended with this.
After manually modifying the file as per above, it worked a treat. I suggest we move to make this happen.

@bethesque is the plan to fix it at the ruby standalone by forcing utf8 for everything?

Ok, update to the latest standalone.

@thombergs Good news, we're now forcing utf8 encoding, get all the tasty goodness from 6.12.2 :)

@mboudreau @bethesque thanks for the fix! Will try it out in our project as soon as possible.


generate gtin 12

Hi there,
I was wondering if from this we could generate a gtin 12 bar code or if you can help add it as a feature?
Since gtin 14 is used for vased products, and gtin 12 is use for retail
Thank you!

Sure. We'll look into it. We don't work with UPCs, but adding support for them is no problem. Thanks for your comment and star.

GTIN-12 support added in 1.1.3

Thank you very much amigo.... let me try it


Rework the testing KZG trusted setups presets

Add testing KZG trusted setups generator tool

Add make gen_kzg_setups command to generate the testing KZG trusted setup JSON files:

presets/mainnet/trusted_setups/testing_trusted_setups.json
presets/minimal/trusted_setups/testing_trusted_setups.json

Load the files and set KZG_SETUP_* presets during building pyspec
Update compute_kzg_proof and evaluate_polynomial_in_evaluation_form: add int casting to avoid underflow

[x] Question: once we have the real mainnet trusted setups, it should be in presets/mainnet/eip4844.yaml. The reason why I store them in other JSON files is that I feel it’s weird to put the testing presets into it and poison the git log. Also, the KZG ceremony may use JSON schema. Any opposite opinions?

Hello. Let's get https://github.com/ethereum/consensus-specs/pull/3038 in first because it revamps the cryptography subsystem, and then we can do this PR!

Hey @asn-d6 I rebased it after #3038.


cleanup any outstanding unsafe size calculations and unsafe casts

cleanup any outstanding unsafe size calculations and unsafe casts

systematic cleanup of any outstanding unsafe size calculations and unsafe casts


roadmap for .NET MAUI 9 & 10

Type of issue
Typo
Description
Hi, Would like to know features planned part of .NET MAUI version 9 & 10. please provide me where i can find roadmap for .NET MAUI version 9 and 10.
Page URL
https://learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-7?view=net-maui-8.0
Content source URL
https://github.com/dotnet/docs-maui/blob/main/docs/whats-new/dotnet-7.md
Document Version Independent Id
d951aa88-bfc9-1071-9ed8-d4e8f37f3bce
Article author
@davidbritch
Metadata

ID: d951aa88-bfc9-1071-9ed8-d4e8f37f3bce
Product: dotnet-mobile
Technology: dotnet-maui

Hi @shilpaCM
The roadmap lives in the engineering repo - https://github.com/dotnet/maui/wiki/Roadmap
It's a bit thin right now because it's still being planned.


javascript and javascriptreact are the same language

I assumed this issue was spotted before, but I couldn't find any issues regarding this.

Open a new file
Set the language to javascript (not javascriptreact)
Type:

const x =

;

There is no syntax error, even though I selected JavaScript without React.
Looking at the source code of vscode, the syntax of these 2 languages is identical - link to the code that generates the language file.
You can see that the resulting javascript language file admits it supports React.
I understand that many React JSX projects use the .js file extensions when they should be using .jsx, so it might be desirable for the JS language to support JSX.
But then why does the second language exist (javascriptreact) if it is identical?
I suggest making javascript not support React. This will force existing React devs who are using VSCode to configure their file association of .js to javascriptreact, and regular JS devs know when they have a syntax error in their code before they run it.

VSCode Version: 1.39.2
OS Version: Windows 10
Does this issue occur when all extensions are disabled?: Yes

This is intentional. React previously encouraged using the jsx but now many developers use just plain js files for react components, so we just always have react support enabled. Removing react support from normal js files and requiring developers to specify a file associations would cause a lot of pain with no real benefit
We still have the javascriptreact mode:

For historical reasons and to match the typescript/typescriptreact language setup
For advanced use cases, users can enable different settings for javascript and javascriptreact (such as emmet)
Extensions may want to target javascriptreact specifically in some cases


Running the t code shows loss=nan when calculating the coco dataset.

Running the t code shows loss=nan when calculating the coco dataset.

I encountered the same problem with the coco_stuff dataset.
2023-08-07 16:07:13,007 INFO    [trainer.py, 229] Train Epoch: 0        Train Iteration: 30      Time 4.248s / 10iters, (0.425)  Forward Time 2.557s / 10iters, (0.256)  Backward Time 1.583s / 10iters, (0.158)  Loss Time 0.075s / 10iters, (0.007)     Data load 0.033s / 10iters, (0.003317)
Learning rate = [0.0009995649894856365, 0.009995649894856365, 0.009995649894856365]     Loss = nan (ave = nan)
Is it because there aren't enough training epochs?

I encountered the same error, have you solved this problem?

I encountered the same problem when I changed the architecture to my own model. In my case, I found some elements of exp_logits + neg_logits could be zeros, thus resulting in inf after a log function.
After making a small change from
https://github.com/tfzhou/ContrastiveSeg/blob/287e5d3069ce6d7a1517ddf98e004c00f23f8f99/lib/loss/loss_contrast.py#L121
to
log_prob = logits - torch.log(exp_logits + neg_logits + 1e-10)

Everything was going well.

That makes sense for me, thanks for your help!!


Occasional 404/502 Errors from RPC Proxy

When testing the current implementation/deployment of the RPC Proxy approx 8 out 10 requests are serviced properly but 10-20% of requests receive 404 not found or 502 forbidden responses.
Version - 0.0.1-rc2
Testable via - curl -ks https://peers.akash.network:443/rpc
Example - received 502 error moments ago and proxy logs show no evidence of issue such as:
Aug 26 22:21:29 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:21:29 INFO updated server list total=17
Aug 26 22:26:29 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:26:29 INFO updated server list total=17
Aug 26 22:31:29 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:31:29 INFO updated server list total=17
Aug 26 22:32:19 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:32:19 INFO proxying request name=Notional url=https://rpc-akash-ia.cosmosia.notional.ventures:443
Aug 26 22:32:19 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:32:19 INFO request done name=Notional avg=443.96568ms last=405.591407ms
Aug 26 22:33:57 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:33:57 INFO proxying request name=c29r3 url=http://akash.c29r3.xyz:80
Aug 26 22:33:58 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:33:58 INFO request done name=c29r3 avg=377.501588ms last=330.60033ms
Aug 26 22:33:59 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:33:59 INFO proxying request name="AutoStake 🛡 Slash Protected" url=https://akash-mainnet-rpc.autostake.com:443
Aug 26 22:34:00 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:00 INFO request done name="AutoStake 🛡 Slash Protected" avg=444.685044ms last=473.324183ms
Aug 26 22:34:03 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:03 INFO proxying request name=Kleomedes url=https://akash-rpc.kleomedes.network
Aug 26 22:34:03 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:03 INFO request done name=Kleomedes avg=518.63857ms last=500.393158ms
Aug 26 22:34:05 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:05 INFO proxying request name=Stakeflow url=https://rpc-akash-01.stakeflow.io
Aug 26 22:34:05 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:05 INFO request done name=Stakeflow avg=462.42117ms last=457.665301ms
Aug 26 22:34:06 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:06 INFO proxying request name="Cosmonaut Stakes" url=https://akash-mainnet-rpc.cosmonautstakes.com:443
Aug 26 22:34:07 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:07 INFO request done name="Cosmonaut Stakes" avg=281.433645ms last=308.477328ms
Aug 26 22:34:08 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:08 INFO proxying request name=w3coins url=https://akash-rpc.w3coins.io
Aug 26 22:34:08 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:08 INFO request done name=w3coins avg=382.23996ms last=565.146647ms
Aug 26 22:34:10 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:10 INFO proxying request name="Allnodes ⚡ Nodes & Staking" url=https://akash-rpc.publicnode.com:443
Aug 26 22:34:10 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:10 INFO request done name="Allnodes ⚡ Nodes & Staking" avg=328.144464ms last=228.557756ms
Aug 26 22:34:13 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:13 INFO proxying request name=ValidatorNode url=https://akash-rpc.validatornode.com
Aug 26 22:34:13 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:13 INFO request done name=ValidatorNode avg=154.788507ms last=181.662926ms
Aug 26 22:34:14 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:14 INFO proxying request name="WhisperNode 🤐" url=https://rpc-akash.whispernode.com:443
Aug 26 22:34:14 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:14 INFO request done name="WhisperNode 🤐" avg=355.714206ms last=436.637606ms
Aug 26 22:34:16 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:16 INFO proxying request name=Stakewolle url=https://public.stakewolle.com
Aug 26 22:34:16 rpc-proxy akash-rpc-proxy[52783]: 2024/08/26 22:34:16 INFO request done name=Stakewolle avg=295.560864ms last=318.479477ms

that seems to be running an older version of this project.. the most recent one should have the status in that log, and also properly ignore servers that are erroring
see #12

yeah, this is not the latest version: https://peers.akash.network

Installed just cut release v0.0.1-rc3 and indeed status messages are written to logs in this version.
When request receives 404/502 response such as:
curl -ks https://peers.akash.network:443/rpc

<title>502 Bad Gateway</title>

502 Bad Gateway

nginx/1.26.1

RPC proxy server logs show:
Aug 27 13:12:10 rpc-proxy akash-rpc-proxy[54476]: 2024/08/27 13:12:10 INFO request done name=Stakewolle avg=294.04119ms last=294.04119ms status=404
Aug 27 13:14:31 rpc-proxy akash-rpc-proxy[54476]: 2024/08/27 13:14:31 INFO request done name=Notional avg=398.930145ms last=398.930145ms status=502

@caarlos0 are those Stakewolle and Notional that gives errors?

@caarlos0 can you capture reply status and rule out nodes with 404/502 errors?

We could definitely consider removing nodes from seeds if those nodes consistently error.
But in addition - do we currently attempt an additional seed if the first attempted is unresponsive/returns error?

@caarlos0 can you capture reply status and rule out nodes with 404/502 errors?

it already does that... but after a while it will try again... its designed for intermittent errors, not exactly for things that always error...

But in addition - do we currently attempt an additional seed if the first attempted is unresponsive/returns error?

we don't, easy enough to do though, can pr it later today

@caarlos0 are those Stakewolle and Notional that gives errors?

https://public.stakewolle.com/cosmos/akash/rpc always 404
https://rpc-akash.cosmos-spaces.cloud always 502
https://akash-rpc.kleomedes.network always 502
https://rpc-akash-ia.cosmosia.notional.ventures always 502
https://akash.declab.pro:26601 always times out

these seem to be all the problematic ones

But in addition - do we currently attempt an additional seed if the first attempted is unresponsive/returns error?
if original node return error pass it to the client, don't try another node for node

cool!
there are a few nodes that I think always error - maybe we should remove them from the seed file as well?

@caarlos0 - was there intent to remove these unresponsive nodes?  Still getting sporadic occurrences of 404/502 and these same, identified nodes are used in such cases.  Example - this morning getting 502 errors when https://rpc-akash.cosmos-spaces.cloud/ is used.

I can remove them yes, @troian wdyt?

https://akash-rpc.kleomedes.network always 502

this one seems to be back up though

@caarlos0 lets do the following.
if node replies with anything than 200

pass reply back to user
mark node as unhealthy.
run healthcheck query (for example query validator set) until it starts replying 200 within 10 consecutive attempts.
return node back to active set if query check pass.
if node becomes unhealthy 3 times within 30minutes then exclude is completely from set until rpc-proxy restarts

that sounds a bit overcomplicated... maybe something like this works better: https://github.com/akash-network/rpc-proxy/pull/11
for the cases here, in which the server is always 5xx/404, it should solve the issue I think 🤔

sadly nature of RPC nodes on cosmos needs sophisticated health checks, historically the were pretty bad.
for example node can become simply due to being asked way to many requested and get back to normal shortly

@caarlos0 are those Stakewolle and Notional that gives errors?

https://public.stakewolle.com/cosmos/akash/rpc always 404
https://rpc-akash.cosmos-spaces.cloud always 502
https://akash-rpc.kleomedes.network always 502
https://rpc-akash-ia.cosmosia.notional.ventures always 502
https://akash.declab.pro:26601 always times out

these seem to be all the problematic ones

https://public.stakewolle.com/cosmos/akash/rpc/  <- note the last slash, is causing issues because they seem to use a proxy with the public available rpcs themself but dont seem to filter them. cosmos-spaces and notional are down consistently and handled. Other works for me.


Unreal Archive sometimes fails to index mutators

Website recognizes mutator, but fails to index files even when I try to force the file type. This happens regardless of the game. Here's a link to one such mutator for UT99 as an example.

Thanks I did not know this was a problem.
Seems to be for mutators with weapons without a description, where the description is under a WeaponDescription in a section named after the weapon class.
This has been fixed, per the MR https://github.com/unreal-archive/unreal-archive-data/pull/2963
https://unrealarchive.org/mutators/unreal-tournament/T/thunderstormrifle_62f3eeec.html


Improve logging and debugging of violations

Initial implementation of logging for the audits has been minimal. Currently, it just outputs the violations in numeric order follow by a dump of the object. Example:

This isn't the worst, but can definitely be made better before the official 1.0 release. Following are proposed features for better logging of violations (subject to change):
General Improvements

[ ] Present information in an easy-to-digest format before dumping the object.

Potential format: [impact]: [help]. Offending markup is: [nodes.html].
Ex: CRITICAL: Form elements must have labels. Offending markup is: <input id="test" type="test">.

Component Improvements

[ ] Include the Component name/reference (e.g., component.toString()) so that it is clear who the offender was

[ ] Provide hook to break on a specific violation

Acceptance Test Improvements

[x] For Acceptance Test audits, specify the run number of the audit

[x] Provide hook to break on a specified run number to aid in debugging

Closed as part of the migration to ember-a11y-testing.


Out-of-box terminal cannot display Emoji

I just got a new laptop and installed Windows Terminal from the store. The weird thing is emojis cannot be displayed correctly. Initially i thought it was that my font doesn't support powerline, so I verified that and realized it was actually emoji. This never happened on my old machines. Where should I start investigating? Thanks!

Where should I start investigating?

Choose correct font.

Yep, @237dmitry is correct. You need to select a font that supports power line glyphs

@zadjii-msft the screenshot might be misleading. the font i use (Fira Code) supports power line glyphs and they are showing fine. this is what looks like with "fontFace": "Cascadia Mono PL"

Sorry, we mis spoke. These are “nerd font” glyphs.

hey @DHowett what "nerd font" glyphs are you referring to here?

Each glyph in your screenshot that is displayed as an empty box. The PowerLine glyphs are working fine, but some prompts use the additional 1,200 glyphs added by the "Nerd Font" patcher.

i don't remember doing any patching on other machines but thanks so much for the help. Aren't nerd fonts already included in Cascadia Code/Mono PL?

No. Like all other powerline-patched fonts, only powerline glyphs are included in the PL variant. We aren't distributing "NF" variants because of the licensing concerns about the company logos and other glyph in the NF variant ☹

@DHowett gotcha thanks so much background 👍 i'll try some other fix later today


Font error on png mode

When I use .png option some characters are converted to rectangle

@fudio101 Thanks a lot for reporting this.
Could you please give me some info about what characters are not printed properly,
so I could fix the bug?
Here is the place, where the characters are classified,
and some classes seem to be missing.
https://github.com/chubin/wttr.in/blob/master/lib/fmt/png.py#L154


Remove version: Mullvad.Browser version 12.5.3

Description

This is a package removal
Resolve #135228

Checks

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest

Microsoft Reviewers: Open in CodeFlow

@wingetbot run

URL: https://cdn.mullvad.net/browser/12.5.3/mullvadbrowser-install-win64-12.5.3_ALL.exe
Response status code does not indicate success: 404 (Not Found).
(Automated message - build 627)


No way to figure out which model provider I am picking when a model is selected from model drop down when creating agent.

Steps to reproduce the problem:

Create  a model provider as Azure OpenAI with target model as gpt4-o

Model List:

Create an agent and open the Model drop down

Notice that there are 2 entries for gpt4-o and no way to tell what the model provider is for these 2 entries

Expected Behavior:
Should be able to show the model provider along with model in the drop down.

@sangee2004 Thanks for opening this issue. I noticed this as well, and planned to bring it up with Ryan this week.

Assigning this to @ivyjeong13 because it will be a pretty easy fix and will help her get acclimated to the codebase.
@ivyjeong13 The object that is iterated over to create this list should already have a provider property on it, so once you locate the dropdown it should be a simple fix.

@ryanhopperlowe @thedadams Hey hey, quick question for the provider!
I see modelProvider but wondering if it should match with what's displayed on the Models page? ex. Azure OpenAI instead of azure-openai-model-provider.

This issue is addressed when testing with latest build.


roxterm: 3.12.1 -> 3.14.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/roxterm/versions.
meta.description for roxterm is: Tabbed, VTE-based terminal emulator
meta.homepage for roxterm is: https://github.com/realh/roxterm
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.13.2 with grep in /nix/store/ffi0qjbhf0d5bx04v0wx5kvzziw78ydf-roxterm-3.13.2
found 3.13.2 in filename of file in /nix/store/ffi0qjbhf0d5bx04v0wx5kvzziw78ydf-roxterm-3.13.2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
roxterm

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ffi0qjbhf0d5bx04v0wx5kvzziw78ydf-roxterm-3.13.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A roxterm https://github.com/r-ryantm/nixpkgs/archive/dce1b061efc5fa0649b01ee08073c8748c3bc650.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/dce1b061efc5fa0649b01ee08073c8748c3bc650#roxterm

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ffi0qjbhf0d5bx04v0wx5kvzziw78ydf-roxterm-3.13.2
ls -la /nix/store/ffi0qjbhf0d5bx04v0wx5kvzziw78ydf-roxterm-3.13.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

roxterm

Maintainer pings

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/realh/roxterm/releases.
meta.description for roxterm is: Tabbed, VTE-based terminal emulator
meta.homepage for roxterm is: https://github.com/realh/roxterm
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.14.1 with grep in /nix/store/njyrzz3lpdvmhb6ifc8f518gmh7b9rvz-roxterm-3.14.1
found 3.14.1 in filename of file in /nix/store/njyrzz3lpdvmhb6ifc8f518gmh7b9rvz-roxterm-3.14.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
roxterm

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/njyrzz3lpdvmhb6ifc8f518gmh7b9rvz-roxterm-3.14.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A roxterm https://github.com/r-ryantm/nixpkgs/archive/921507e404f2f203c71cc96332144b241882c290.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/921507e404f2f203c71cc96332144b241882c290#roxterm

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/njyrzz3lpdvmhb6ifc8f518gmh7b9rvz-roxterm-3.14.1
ls -la /nix/store/njyrzz3lpdvmhb6ifc8f518gmh7b9rvz-roxterm-3.14.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

roxterm

Maintainer pings


Height on pagination button removed

I didn't notice a difference but it might worth getting another pair of eyes on it.

I'll double check it in the morning. Merging for now
On Mon, May 15, 2017 at 10:33 PM Mark Hatch<EMAIL_ADDRESS>wrote:

I didn't notice a difference but it might worth getting another pair of
eyes on it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tannerlinsley/react-table/pull/275#issuecomment-301672849,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFUmCQK0EtFhuzZFQWB_2ocdPreUXHUiks5r6ScIgaJpZM4Nb-iE
.

Great job!


Allow skip option to be a message string

Could be good for explaining why the spec is skipped
ngDescribe({
  skip: 'the api object is not ready',
  ...
});

Done


Project tree shows confusing directory structure

IntelliJ shows a confusing picture of the directory structure in the project tree pane.

Example 1
The following directory tree
src
├── main
│   ├── resources
│   └── scala
└── test
    └── scala

is shown like this:

I.e. the test directory is omitted, and it is not obvious where the lower scala folder belongs to.
I would expect the project tree to match the actual directory structure.

Example 2
The following directory tree
src
├── main
│   └── scala
└── test
    └── scala

is shown like this:

I.e. the main and test directories are omitted. It is not obvious where the two "floating" scala folders belong to.
I would expect the project tree to match the actual directory strucuture.

Version information
IntelliJ:
IntelliJ IDEA 2018.2.5 (Community Edition)
Build #IC-182.4892.20, built on October 16, 2018

JRE: 1.8.0_152-release-1248-b6-amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o

Bazel plugin:
2<IP_ADDRESS>.2

A full reproduction of this issue is available here: https://github.com/aherrmann/reproduce-intellij-project-view-issue

I believe this is an upstream bug with IntelliJ. If you import that exact same project as a plain IntelliJ project (without the bazel plugin) does it still occur?

@brendandouglas If I import it as a regular IntelliJ project (without the bazel plugin) then I get the following "Project" tree:

And the "Packages" tree looks like this:

I don't mean importing from scratch, but importing the exact project created by the bazel plugin, but with the bazel plugin disabled (you should see a 'Required plugins weren't loaded' error).
When I do that, and check 'compact empty middle packages' (the source of this problem), I see all main/test files and directories disappear, except src/main/resources/dummy.txt

So there's an upstream bug and/or a bug with the project definition written by the bazel plugin.
The project definition looks valid to me, so this appears to be an upstream bug.

@brendandouglas Okay, so, a workaround for this issue is to disable "compact empty middle packages". I can confirm that this produces the expected project tree.
I've tested loading the project with the Bazel plugin disabled, and as you say the main and test folders disappear, except for dummy.txt. It looks like this for me:

The project definition looks valid to me, so this appears to be an upstream bug.

I'm afraid, I don't know enough about IntelliJ to make that judgement. Could I ask you to file an issue for this upstream? I'm happy to provide additional information if required.
Or, if that's not possible, could you point me to the relevant information that should be included in the  upstream ticket?

@aherrmann if you check in the project definition, and point to that in an upstream ticket it should be enough to go on.

If you can write here the issue we’d love to follow it as we have the same
problem
On Sun, 11 Nov 2018 at 17:07 brendandouglas<EMAIL_ADDRESS>wrote:

@aherrmann https://github.com/aherrmann if you check in the project
definition, and point to that in an upstream ticket it should be enough to
go on.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/intellij/issues/437#issuecomment-437678037,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF4PtzeUSxEB9nHNHZ27MeHfyppWoks5uuD05gaJpZM4YSb4z
.

I don't think it's a bug in IntelliJ. The issue is that the root folder is added as a Source Folder in Intellij. This means IntelliJ interprets every sub-folder as a java-like "package". Removing the root folder from the module setup manually yields the expected results:

Notice that this also changed the icons for the folder src and main, as they are now regarded as normal directories rather than java-like packages.

Thanks for tracking it down. That still seems like a bug in IntelliJ. What if this test project actually had nested source directories?

Conceptually, having nested source directories doesn't make much sense for a conventional maven-like project structure. Multiple source directories that don't overlap is fine (e.g. src/test/scala and src/main/scala).
I think the assumption that each directories entry is by default a source directory doesn't hold when it comes to conventional java/scala project structures.
That said, possibly the maven inspired project structure doesn't fit how bazel works to begin with, and trying to square this particular circle is doomed to lead to issues down the line.

I agree it wouldn't be common, and we should stop marking the root directories as source roots by default.

if you'll "stop marking the root directories as source roots by default"
what will you mark as source roots? How will we mark source roots?
On Tue, Nov 13, 2018 at 9:48 PM brendandouglas<EMAIL_ADDRESS>wrote:

I agree it wouldn't be common, and we should stop marking the root
directories as source roots by default.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/intellij/issues/437#issuecomment-438411439,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF_HMIePqS-qkC1YrLM3j7KUT6j2Qks5uuyIogaJpZM4YSb4z
.

Marking the root directory as a source root regardless of its contents was a hack (which happened to make sense internally). We also detected source roots during sync by looking for java-like sources built by bazel targets in the project, and checking their package path using a set of heuristics (up to actually reading the file contents via our aspect).
You shouldn't notice any regression when the release after next lands, or need to manually mark source roots.

Awesome, thanks!
On Wed, 14 Nov 2018 at 16:41 brendandouglas<EMAIL_ADDRESS>wrote:

Marking the root directory as a source root regardless of its contents was
a hack (which happened to make sense internally). We also detected source
roots during sync by looking for java-like sources built by bazel targets
in the project, and checking their package path using a set of heuristics
(up to actually reading the file contents via our aspect
https://github.com/bazelbuild/intellij/blob/194f34b0690827918356eab5ae84fe85c8f6c50c/aspect/tools/src/com/google/idea/blaze/aspect/PackageParser.java
).
You shouldn't notice any regression when the release after next lands, or
need to manually mark source roots.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/intellij/issues/437#issuecomment-438684902,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF8Yljs9LsQEZNsH8MTQvaDhFqI-aks5uvCu0gaJpZM4YSb4z
.

Sounds great, thanks!


Create base58 crate

Just the last patch. Once https://github.com/rust-bitcoin/rust-bitcoin/pull/1264 goes in this one is not that hard to do.
Draft for now, early feedback welcome but there is nothing surprising here.

I would suggest doing a pub use bitcoin_base58 as base58 in util/mod.rs so that there is no API change (at least for this rev). But otherwise concept ACK

Going to hold off reviewing this until #1264 is in.
But I'm leaning toward "we should just keep the bitcoin_hashes dependency". I'd really rather not have another impl of sha256 floating around.

No worries, I'll convert to draft.

BOOM! Turns out we can make bitcoin-encoding crate and there is actually no dependency cycle between base58, hashes, hex.
Check out: https://github.com/rust-bitcoin/rust-bitcoin/discussions/1306

Ooh, very nice. Because -str has to depend on hashes in order to support base58 ... so then whatever hex traits it defines, it can go ahead and impl those on the hash types.

I still don't understand. Can you describe it as a graph of dependencies?

-str depends on hashes
-str defines hex traitsand impls those on the types fromhashes; hashes` itself doesn't know about hex at all

I'm also thinking about having bitcoin_sha256 containing just the algorithm

I can also get behind that, though I'm not certain now that it's needed.

Also note that I'm not too excited about having -str crate. The things it contains are not used together that much

if you are exposing bitcoin data to a human then you need everything in -str. You need base58 for legacy addresses, bech32(m) for newer ones, base64 for PSBTs and hex for everything else. It would be a fairly narrow application that didn't use most of these.
These are also write-once code that should basically never be touched (aside from perhaps a one-shot overhaul to introduce unsafety and optimize them), similar to bitcoin_hashes whose core logic hasn't been touched since it was written. So it's nice to have a single crate that you don't need to think about.


[FEAT] Image Generation Endpoint

Creating images from scratch based on a text prompt.

Resources

https://platform.openai.com/docs/guides/images

{
   prompt: string,
   n: 10,
   size: '256x256'
 }

Now we have encounter that type of image-urls returning from api isn't working on client. Thus store the image into cloudinary and return the response as array of url.
Also do error handling fo: when api doesn't repond for the prompt, as discussed.

@dhruvrajsinh-7 we need some more changes for this feat

Now we have encounter that type of image-urls returning from api isn't working on client. Thus store the image into cloudinary and return the response as array of url.

Also do error handling fo: when api doesn't repond for the prompt, as discussed.


cmd + f in browser breaks simple-bar-process.jsx

SyntaxError: JSON Parse error: Unterminated string

Indeed, I'll look into it, thanks!

Indeed, I'll look into it, thanks!

This should be resolved now.

This should be resolved now.

Can confirm.
Closed in 2b4dc694dea152abd308b80168850780ddd41079.

Can confirm.
Closed in 2b4dc694dea152abd308b80168850780ddd41079.


Crawl PDF files and scaned documents

I faced with such kind of problem as crawling deep web PDF files and scaned documents in it. For instance, I have a number of PDFs (belong to one science topic ) which may be used as a seed, but I m not sure of the harvest quality.  I can turn my PDFs into text files, but nothing about crawling PDFs and using text files as seeds in the project's documentation.  Is Ache crawler capable fo deep web science data crawling? IF no, would you advise me some advanced crawlers ?

Hi @tpolo777 , apologies for the late response.
ACHE is able to download PDF files when it finds links to them, but it won't necessarily prioritize downloading such files. More specifically, all current ACHE page classifier implementations assume that pages are HTML page and won't extract any text from PDF files, so it has no way identify that a PDF is relevant. Creating a new page classifier that is able to handle PDFs (identify the PDF mime-type and extract its text) would be enough to make it work.
I'm also not aware of any web crawler that crawls PDFs out-of-the-box.

I wonder how easy / hard it would be to pass all content through a Tika parser that always returns html?


feat: vote by signature

:notebook: Overview
This PR adds back the castVoteBySignature method after correctly defining the domain for Vote(uint256, uint8) where VoteType is treated as uint8. It adds all tests for signature verification and an assertion against invalid signatures which does not revert with error since any valid EIP712 signature on wrong domain, id, vote type, does bypass the assertion as non-null signer address is recovered. It also adds protection against sig malleability.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 98.98%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
1289

Relevant Lines:
1297

💛  - Coveralls


JS Api fs import

File system part of JS API Documentation is outdated (https://github.com/tauri-apps/tauri/wiki/11.-API#file-system)
It should be
import {
  Dir,
  copyFile,
  createDir,
  readBinaryFile,
  readDir,
  readTextFile,
  removeDir,
  removeFile,
  renameFile,
  writeFile
}  from 'tauri/api/fs'

Also when I tried that, I got an error importing the module because it searches for tauri.js in current directory, while it should be in the parent.

You're right, bad copy/paste, here. :|
Fixed!


connected textures are reflective

i'm using Deep origins overlays by Devoneox resource pack that adds connected textures and all the custom textures end up being reflective, and also (or mb because of that) the lighting on them is off
Steps to reproduce the behavior:

use Deep Origins Overlays + Continuity mod
use Miniature shaders + Iris

Expected behavior
It not happening (?)
Screenshots
reflections issue

lighting issue

System Information

minecraft 1.21
fabric 0.16.0
continuity v3.0.0-beta.5
iris v.1.7.3
Deep Origins Overlays RP

love the shader — been looking for something minimalistic like that — but that bug is pretty distracting
maybe add an option to choose which surfaces are gonna be reflective?, i'd like only water to be reflective

This is an issue with Deep Origins Overlays. They registered the sand overlays as translucent, instead of cutout_mipped.


Build an Android Application Bundle

Introduces the following things:

Build configurations for generating a signed Android Application Bundle (AAB)
NPM scripts / Yarn commands for running builds
Instructions on how to build the AAB

@dsamojlenko is working on a Fastlane setup, so left a placeholder in the documentation for that.

Here's the rough notes of what I've done so far. Will add into documentation. Likely to change too after @dsamojlenko 's Fastlane work.
Following React Native docs.

Put the keystore file in "android"
Setup .env file
Add Gradle build steps
Add vars to Grade properties (if not in the .env)
Add ENVFILE=/Users/jeffreymaher/code/covid-shield-mobile/.env
Fix APP_ID ("ca.tbs-sct.covid" is not valid for Android, changed to "ca.canada.covid_notification")
yarn bundle-android
android/gradlew bundleRelease

This doesn't fully work yet, but did produce a signed Android Application Bundle to jump start work on Fastlane.

Let me know if you want me to merge or junk, given that there is still a bug at the end of the instructions.

If we have Fastlane building for both think we can scrap this unless there's something I'm missing.


Fix to Ensure All Rules Satisfy not isInterface

Fix

[x] Add a unit test to verify that the fix works.

[x] Explain briefly why the bug exists and how to fix it.
According to the code principles of net.bytebuddy.matcher.ElementMatcher.Junction:
In the current code, the running effect can only ensure that the first NamedMatch satisfies not isInterface:
 (((NamedMatch) and (not(isInterface))) or IndirectMatch) or...IndirectMatch.
After moving not isInterface to the end, the running effect can ensure that all rules satisfy not isInterface:
 (((NamedMatch) or (IndirectMatch)) or...IndirectMatch) and not(isInterface).

[x] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.

[x] Update the CHANGES log.

In the current code, the running effect can only ensure that the first NamedMatch satisfies not isInterface

@wengyingjian I think the current Junction expression is
(A and not(isInterface())) or (B and not(isInterface())) or ...

Is my understanding right?

I think original request is all things should be not an interface.
First or last are not accurate.
It should use and with all other condition or before all other checks run.

Yes, because I didn't find a place that required modifying the bytecode for interfaces, I think all matching rules should be non-interface based.
If that's the case, adding and (not isInterface) in the for loop is indeed a safer approach.
Additionally, I've noticed that some custom IndirectMatch instances include not interface, while some do not.
I'm not sure if this means there is already a place that requires modifying the interface bytecode, or if it's just to maintain flexibility, allowing subclasses to implement it themselves.

In theory, there is no point to intrument an interface, especially we require to add new field to the target.

I've noticed that some custom IndirectMatch instances include not interface, while some do not.

I think those are not necessary, but as the bug you are fixing, they may be added as it is.

In the current code, the running effect can only ensure that the first NamedMatch satisfies not isInterface

@wengyingjian I think the current Junction expression is
(A and not(isInterface())) or (B and not(isInterface())) or ...

Is my understanding right?

I think the logic error is, that the is not interface could be overridden by the or from the 2nd condition, as it is flat.


Add support for table-valued functions

Some database systems provide user defined functions that return table values. Those table values can be joined with other relational objects like tables or views. The main advantage is the possibility to make use of parameters in those user defined functions.
An exemplary implementation of this kind of user defined functions is Microsoft SQL Server's Table-Valued User-Defined Function (see http://msdn.microsoft.com/en-us/library/ms191165.aspx). Querydsl support would be a great benefit.
Maybe, Querydsl's RelationalPath can be extended in a way that supports parameters and allow the generation of SQL like select * from Table t join TableValuedFunction(?, ...) tvf on tvf.value=t.value.

Original post: https://groups.google.com/forum/#!topic/querydsl/wOvmKWXP6s0

Just for clarification. Should I support both
from table join tableValuedFunction where ...

from table join tableValuedFunction alias where ...

To avoid ambiguities concerning column names I'd prefer the latter alternative.

I added now support for table valued function calls in joins. I added the RelationalFunctionCall type for this. Here is a usage example :
    SQLQuery query = new SQLQueryImpl(SQLTemplates.DEFAULT);
    QSurvey survey = QSurvey.survey;
    query.from(survey).join(RelationalFunctionCall.create(Survey.class, "functionCall()"), Expressions.path(Survey.class, "fc"));
    query.where(survey.name.isNotNull());
    assertEquals("from SURVEY SURVEY\njoin functionCall() as fc\nwhere SURVEY.NAME is not null", query.toString());

Could you verify that this works for you?

Could you please provide me with a pre-compiled bundle to allow me to verify this new functionality? Thank you for the quick implementation of this feature.
Where can the parameters be passed to functionCall()? And where to place the join conditions? Which type is Survey.class of?

I simplified the contract a little bit :
    StringPath str = new StringPath("str");
    RelationalFunctionCall<String> functionCall = RelationalFunctionCall.create(String.class, "getElements", "a", str);
    assertEquals("getElements({0}, {1})", functionCall.getTemplate().toString());
    assertEquals(ConstantImpl.create("a"), functionCall.getArg(0));
    assertEquals(str, functionCall.getArg(1));

The first argument to the create method is the row type, the second the function name and the rest are the arguments. All non-Expression arguments are treated as constants.

I just deployed 2.2.4.BUIlD-SNAPSHOT

You can add join conditions via on(...) calls

Sorry, I cannot find 2.2.4.BUILD-SNAPSHOT...

Sorry. Should be available now :
https://source.mysema.com/maven2/snapshots/com/mysema/querydsl/querydsl-sql/2.2.4.BUILD-SNAPSHOT/
Timo
On Tue, Nov 8, 2011 at 8:09 AM, nyc2 <
<EMAIL_ADDRESS>
Sorry, I cannot find 2.2.4.BUILD-SNAPSHOT...

Reply to this email directly or view it on GitHub:
https://github.com/mysema/querydsl/issues/35#issuecomment-2664239

--
Timo Westkmper
Mysema Oy
+358 (0)40 591 2172
www.mysema.com

Obviously, I'm doing something wrong. I really don't know how to build this query:
select tab.col from Table tab join TableValuedFunction('parameter') func on tab.col not like func.col

I tried this:
RelationalFunctionCall<String> func = RelationalFunctionCall.create(String.class, "TableValuedFunction", "parameter");
query().from(QTable).join(func, **Expressions.path(String.class, "func")**).on(QTable.col.like(**how to reference columns returned by TableValuedFunction**).not()).list(QTable.col);

Could you tell me what I have to put in the bold-styled parts to make this working?
At the moment, the join alias seems to be rendered as func.*

The problem still remains, that
RelationalFunctionCall<String> tokenizeFunc = RelationalFunctionCall.create(String.class, "tokenize", csvStr);
PathBuilder<String> tokenizeFuncAlias = new PathBuilder<String>(String.class, "tokFunc");
sq().leftJoin(tokenizeFunc, tokenizeFuncAlias).on(QTable.col.like(tokenizeFuncAlias.get(new StringPath("token"))).not());

delivers the following SQL (excerpt):
left join tokenize(?) as tokFunc.*
on not QTable.col like tokFunc.*.token

.* leads to this SQLException:
Caused by: java.sql.SQLException: Incorrect syntax near '.'.

Do you have any suggestions on that?

I will see what goes wrong later today.

I've had problems to reproduce this issue. This works in Querydsl SQL :
@Test
public void FunctionCall() {
    //select tab.col from Table tab join TableValuedFunction('parameter') func on tab.col not like func.col

    QSurvey table = QSurvey.survey;
    RelationalFunctionCall<String> func = RelationalFunctionCall.create(String.class, "TableValuedFunction", "parameter");
    PathBuilder<String> funcAlias = new PathBuilder<String>(String.class, "tokFunc");
    SQLSubQuery sq = new SQLSubQuery();
    SubQueryExpression<?> expr = sq.from(table)
        .join(func, funcAlias).on(table.name.like(funcAlias.getString("prop")).not()).list(table.name);

    SQLSerializer serializer = new SQLSerializer(new SQLServerTemplates());
    serializer.serialize(expr.getMetadata(), false);
    assertEquals("select SURVEY.NAME\n" +
            "from SURVEY SURVEY\n" +
            "join TableValuedFunction(?) as tokFunc\n" +
            "on not SURVEY.NAME like tokFunc.prop escape '\\'", serializer.toString());

}

Do you use Querydsl SQL with or without JPA?

Ok, this appears to be a bug in Querydsl JPA Native query support. I was always testing on the Querydsl SQL side, that's why I didn't encounter it before.

This works for me, thanks again!

Released in 2.2.5


docs: fix typos

I will try to upstream. Thank you very much.

@rootulp @evan-forbes I have reverted those files forked from cometbft.