Add components inside markdown

Is it possible like with Sycamore to add components in markdown that are reactive?
https://lukechu10.github.io/mdsycx/

Wow, mdsycx is really cool !
I didn't consider that, but it could be a cool feature for sure !

It may be possible by passing a HashMap of signals as a prop for example.
What do you think would be the best syntax ?
Something like that maybe ?
# Reactive markdown:
<signal>name_of_my_signal</signal>

That is one solution part of the solution. By passing a component like <Counter initial="42" /> the Counter component could have implemented actions to increase or decrease like any other component in the view tree. With this you could for example embed a complete app inside your markdown. The feature is more powerful then just having a reactive signal in them.
I can't find his example of the counter but it worked like I described above.

Having a look at the code it uses a macro. Since Sycamore al very identical to Leptos it should be simple to port. Here is the macro

I just realized that would involve writting a proc-macro to implement FromMd
from the mdsycx docs:
#[derive(Prop, FromMd)]
pub struct MyProps<'a, G: Html> {
    /// A prop that can be set from markdown.
    special_number: i32,
    /// The `children` prop is always required.
    children: Children<'a, G>,
}

Closed by 336fe
Note that it is still an experimental feature


Downloading the Wrong Images

was archiving my favourites and i noticed the errors i was getting were strange. it was requesting the correct id to download but when it started to download it was downloading a completely different one that wasn't valid. not sure if this is a program issue or a server issue 😥
Log: https://gist.githubusercontent.com/MrWeeb69/0c509e592d615be962f2109acd28c3f0/raw/2aecc3c18cc185acf742c16cf9c791947ab0f979/gistfile1.txt

i'd like to add that it was working fine 40 min ago and any id i try ends up with the same result of downloading a completely different number then what i inputed

Duplicate of #33 and #34?


Missing imagick extension , i already installed in local machine

- spatie/pdf-to-image 2.1.0 requires ext-imagick * -> it is missing from your system. Install or enable PHP's imagick extension.
- why I am getting same error I have installed imagick i can check in phpinfo();

See #178


Unable to input Chinese character in mobile

iphone6s, chrome
Unable to input Chinese character in mobile

https://github.com/codemirror/CodeMirror/issues/3137

@jet10000 is this an issue with CodeMirror specifically?

Same issue here, with Bopomofo input.


History suggestions

Hi.
2 questions about History suggestions.

How to force to show history suggestions after focusing the Search View? Now they appears only after typing the first letter.

I want to use the  Search Views in 2 different parts of my app for searching different things. Is it possible to have separate independent history databases for them? How?

1- that behavior is already working, check sample app or send me your code
2- you are going to need to implement that (i was thinking about pull request it, but idk)

I just got it. i used

SearchAdapter searchAdapter = new SearchAdapter(this);
instead of
List suggestionsList = new ArrayList<>();
SearchAdapter searchAdapter = new SearchAdapter(this, suggestionsList);
Now it works properly.

Thank you, it would be nice to implement that in your great lib!

Actually it's not mine, but i'll do it maybe tomorrow because i need it too.
The first constructor of searchAdapter should work... weird.


how do i set min and max user can slide?

i have this kind of use case where i need to show all available options to user. user with free plan can only slide to 1 day, meanwhile user with pro plan kat slide up to 1 week. i expected the drag will stop when free user try to slide higher. how do i achieve this? i have tried setting up max value, doesn't seem to be work.

The dotOptions can be set to limit the sliding range of a single slider. document

@NightCatSama alright. let me test it first

nice. it's working. thanks


Remove gpgme_data_t signed_text parameter from verifyPlain function

gpgme_data_t signed_text is not used by gpgme and can be removed from type signature.
https://www.gnupg.org/documentation/manuals/gpgme/Verify.html

https://github.com/rethab/h-gpgme/issues/36


Apply automatic identity selection for forwarding emails based on to: field of mail being forwarded

fixes #4791

My proposal:
Include Action.FORWARD and Action.FORWARD_AS_ATTACHMENT to the if-condition here:
https://github.com/k9mail/k-9/blob/b9eba6971fa86b95a4855caddbfa7144e5c23884/app/ui/legacy/src/main/java/com/fsck/k9/activity/MessageCompose.java#L1281-L1287

The line number referenced above are inside processMessageToReplyTo(...) and so adding logic for forwarded message didn't work(I checked using debugger to make sure). Luckily, right below that block of code is the method processMessageToForward - inside which I added the logic highlighted by @simontb.
I had to do some research to understand the use of identity which I think is quite useful! Anyway, after following #935 discussion I think I've understood the goal somewhat. For reply to an email, the to: email is used to check for existing identities and if found, the found identity is used instead of default one to fill inside the from field of the new message. Please correct me if I got something wrong.
What I've achieved is an effect exactly like the reply feature, when I forward a mail sent to<EMAIL_ADDRESS>the default<EMAIL_ADDRESS>is not filled inside from :, instead the identity associated with<EMAIL_ADDRESS>is used.

I used the settings.jar for code style guidelines and I think I once pressed the code reformat shortcut which caused some extra changes in the file(at 3-5 places) by Android Studio, please tell me if I have to do anything about them.

Updated (2020/10/05 15:00 UTC): Individual pull requests can also be directly opted-in to Hacktoberfest with the ‘hacktoberfest-accepted’ label, on any public GitHub repository, without the need for the ‘hacktoberfest’ repository topic.

If its not too much to ask, could you please add this label to my PR if it's acceptable? It could help me win some swag :)

Thanks :+1:


interp1d on ND arrays where some series are nan

scipy 1.0.1, Anaconda 5, Linux 64 bit
When y is a N-dimensional array, I would expect interp1d to work independently on each series.
When invoked with kind='quadratic' or kind='cubic', however, if any series contains NaNs then the interpolated values of all series will be NaN:
import numpy
from scipy.interpolate import *

x = numpy.arange(0, 8, 1)
y = numpy.stack([numpy.arange(0, 80, 10), numpy.full((8, ), numpy.nan)], axis=1)
print("x =", x)
print("y =", y)

for kind in ('nearest', 'linear', 'zero', 'slinear', 'quadratic', 'cubic'):
    print(kind + ' =', interp1d(x, y, axis=0, kind=kind)(4.5))
print("Akima =", Akima1DInterpolator(x, y, axis=0)(4.5))
print("PCHIP =", PchipInterpolator(x, y, axis=0)(4.5))

Output:
x = [0 1 2 3 4 5 6 7]
y = [[ 0. nan]
 [10. nan]
 [20. nan]
 [30. nan]
 [40. nan]
 [50. nan]
 [60. nan]
 [70. nan]]
nearest = [40. nan]
linear = [45. nan]
zero = [40. nan]
slinear = [45. nan]
quadratic = [nan nan]
cubic = [nan nan]
Akima = [45. nan]
PCHIP = [45. nan]

PCHIP and Akima splines are local, hence they have easier time dealing with nans than cubic or quadratic splines. A more relevant comparison is CubicSpline, which raises a ValueError for even a single nan anywhere in an array. So does make_interp_spline, actually.
interp1d does fairly weird things to work around and to not raise, see
https://github.com/scipy/scipy/blob/v1.0.0/scipy/interpolate/interpolate.py#L504
Clearly, this logic can be improved so that _call_nan_spline actually does computations for the parts of the input array which are all finite, and fills with nans the rest. PR welcome, I'd say.

I tried taking a kludgey stab at this. From the comment in this block, it seems LAPACK is sensitive to nans and the input arrays need to be sanitized. nans are easy enough to mask out, but the difficulty (in my view) seems to be no way to pass position information into the spline function (or getting it when it returns).
So the _call_nan_spline does it in post and masks everything since dummy arrays were sent into the spline.
I didn't really change the post-correction strategy, but instead of sending in dummy arrays, I replace nans with a, shall we say, "recognizable" value (full-scale float) that can be filtered after. Obviously, this can be dangerous if users are interpolating data near max floats where outputs could be incorrectly nan'd.
https://github.com/seanpquinn/scipy/blob/interp1d_nan_work/scipy/interpolate/interpolate.py#L540
I removed PCHIP and Akima from the above snippet since it gives a value error. This hack also fails test_interpolate.py but seems like that test assert is checking that all outputs are nan for any nan input anyway.
python test_interp.py
x = [0 1 2 3 4 5 6 7]
y = [[ 0. nan]
 [10. nan]
 [20. nan]
 [30. nan]
 [40. nan]
 [50. nan]
 [60. nan]
 [70. nan]]
nearest = [40. nan]
linear = [45. nan]
zero = [40. nan]
slinear = [45. nan]
quadratic = [45. nan]
cubic = [45. nan]

Nice! But not quite.
It's not obvious what that large values mean for e.g. condition number. That pchip/akima start giving valueerrors might already be a sign.
Also, having a nan in the x array makes it non salvageable, one cannot just replace it with a value.

Hmm, I think I get the value error for pchip/akima without my mods though, at least using 1.4.1 on my laptop
Noted about the x nan: so the behavior for x needs to be changed to return all nans if at least one nan in the input

OK, as of
In [3]: scipy.__version__
Out[3]: '1.10.0.dev0+1644.903bc39'

PchipInterpolator and Akima1DInterpolator snippets in the OP raise ValueErrors (this is now exactly new in 1.9.x; this change has been made at some point after April 2018), the rest is as it was.
Otherwise, this issue is a duplicate of gh-9315, which has some more details, so let's close this one in favor of that one. Thanks all.


[bug] content harvest error for a Nuxeo collection: outofmemoryerror: container killed due to memory usage

Mapper: Nuxeo
Collection ID: 26973
Run ID: manual__2024-04-24T00:05:08+00:00
Permalink to the log: https://7a8067cb-3b99-477e-a883-7e311175a9b4.c3.us-west-2.airflow.amazonaws.com/log?dag_id=harvest_collection&task_id=content_harvesting.content_harvest&execution_date=2024-04-24T00%3A05%3A08%2B00%3A00&map_index=0
Link to the gridview: https://7a8067cb-3b99-477e-a883-7e311175a9b4.c3.us-west-2.airflow.amazonaws.com/dags/harvest_collection/grid?dag_run_id=manual__2024-04-24T00%3A05%3A08%2B00%3A00&task_id=content_harvesting.content_harvest&tab=mapped_tasks&map_index=0&num_runs=365
[2024-04-24, 00:06:24 UTC] {{base.py:73}} INFO - Using connection ID 'aws_default' for task execution.
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Harvesting content for 1 records at 26973/vernacular_metadata_2024-04-24T00:05:18/mapped_metadata_2024-04-24T00:05:30/data/r-p0.jsonl
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Mime-type 'image/tiff' was pre-checked and recognized as something we can try to convert.
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] --------------------------------
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] ERROR: make_jp2 command failed: ['/usr/bin/convert', '-quiet', '-format', '-jp2', '-define', 'jp2:rate=10', '/tmp/CiudaddeMexico.tif[0]', '/tmp/CiudaddeMexico.jp2']
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] returncode was: -9
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] output was:
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] --------------------------------
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] 26973/vernacular_metadata_2024-04-24T00:05:18/mapped_metadata_2024-04-24T00:05:30/data/r-p0.jsonl
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Harvested 0 media records
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] 1/1 records described a media source
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Source Media Mimetypes: Counter({'image/tiff': 1})
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Destination Media Mimetypes: Counter({None: 1})
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Harvested 1 thumbnail records
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] 1/1 described a thumbnail source
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Source Thumbnail Mimetypes: Counter({'image/jpeg': 1})
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] Destination Thumbnail Mimetypes: Counter({'image/jpeg': 1})
[2024-04-24, 00:07:54 UTC] {{task_log_fetcher.py:65}} INFO - [2024-04-24, 00:07:49 UTC] [{'thumb_source_mimetypes': Counter({'image/jpeg': 1}), 'thumb_mimetypes': Counter({'image/jpeg': 1}), 'media_source_mimetypes': Counter({'image/tiff': 1}), 'media_mimetypes': Counter({None: 1}), 'children': 0, 'records': 1, 'with_content_urls_filepath': '26973/vernacular_metadata_2024-04-24T00:05:18/mapped_metadata_2024-04-24T00:05:30/with_content_urls_2024-04-24T00:05:47/data/r-p0.jsonl'}]
[2024-04-24, 00:08:25 UTC] {{ecs.py:619}} INFO - ECS Task stopped, check status: {'tasks': [{'attachments': [{'id': 'df00839f-4c84-4485-bb8e-0fbb21127f9b', 'type': 'ElasticNetworkInterface', 'status': 'DELETED', 'details': [{'name': 'subnetId', 'value': 'subnet-09e65806b80ebad6b'}, {'name': 'networkInterfaceId', 'value': 'eni-0bbc62c5ab40c2f9f'}, {'name': 'macAddress', 'value': '02:f7:14:30:a9:3d'}, {'name': 'privateDnsName', 'value': 'ip-10-192-21-186.us-west-2.compute.internal'}, {'name': 'privateIPv4Address', 'value': '<IP_ADDRESS>'}]}], 'attributes': [{'name': 'ecs.cpu-architecture', 'value': 'x86_64'}], 'availabilityZone': 'us-west-2b', 'clusterArn': 'arn:aws:ecs:us-west-2:777968769372:cluster/rikolti-ecs-cluster', 'connectivity': 'CONNECTED', 'connectivityAt': datetime.datetime(2024, 4, 24, 0, 5, 57, 673000, tzinfo=tzlocal()), 'containers': [{'containerArn': 'arn:aws:ecs:us-west-2:777968769372:container/rikolti-ecs-cluster/9a86a3a2b74f4b859c29b7983f047218/047d644c-0ccf-4a7c-9ae2-09fd1eada1f0', 'taskArn': 'arn:aws:ecs:us-west-2:777968769372:task/rikolti-ecs-cluster/9a86a3a2b74f4b859c29b7983f047218', 'name': 'rikolti-content_harvester', 'image': 'public.ecr.aws/b6c7x7s4/rikolti/content_harvester:latest', 'imageDigest': 'sha256:22357206871a0636ee73331963282e84f527c43aaaf74e267378c68e2cdc85bf', 'runtimeId': '9a86a3a2b74f4b859c29b7983f047218-3530892436', 'lastStatus': 'STOPPED', 'exitCode': 0, 'reason': 'OutOfMemoryError: Container killed due to memory usage', 'networkBindings': [], 'networkInterfaces': [{'attachmentId': 'df00839f-4c84-4485-bb8e-0fbb21127f9b', 'privateIpv4Address': '<IP_ADDRESS>'}], 'healthStatus': 'UNKNOWN', 'cpu': '0'}], 'cpu': '1024', 'createdAt': datetime.datetime(2024, 4, 24, 0, 5, 54, 324000, tzinfo=tzlocal()), 'desiredStatus': 'STOPPED', 'enableExecuteCommand': False, 'executionStoppedAt': datetime.datetime(2024, 4, 24, 0, 7, 49, 420000, tzinfo=tzlocal()), 'group': 'family:rikolti-content_harvester-task-definition', 'healthStatus': 'UNKNOWN', 'lastStatus': 'STOPPED', 'launchType': 'FARGATE', 'memory': '3072', 'overrides': {'containerOverrides': [{'name': 'rikolti-content_harvester', 'command': ['26973', '["26973/vernacular_metadata_2024-04-24T00:05:18/mapped_metadata_2024-04-24T00:05:30/data/r-p0.jsonl"]', '26973/vernacular_metadata_2024-04-24T00:05:18/mapped_metadata_2024-04-24T00:05:30/with_content_urls_2024-04-24T00:05:47/', 'nuxeo.nuxeo'], 'environment': [{'name': 'MAPPED_DATA', 'value': 's3://rikolti-data'}, {'name': 'WITH_CONTENT_URL_DATA', 'value': 's3://rikolti-data'}, {'name': 'CONTENT_ROOT', 'value': 's3://rikolti-content'}, {'name': 'NUXEO_USER', 'value': 'Administrator'}, {'name': 'NUXEO_PASS', 'value': 'cable8:ringmasters'}, {'name': 'AWS_RETRY_MODE', 'value': 'standard'}, {'name': 'AWS_MAX_ATTEMPTS', 'value': '10'}]}], 'inferenceAcceleratorOverrides': []}, 'platformVersion': '1.4.0', 'platformFamily': 'Linux', 'pullStartedAt': datetime.datetime(2024, 4, 24, 0, 6, 5, 878000, tzinfo=tzlocal()), 'pullStoppedAt': datetime.datetime(2024, 4, 24, 0, 6, 26, 829000, tzinfo=tzlocal()), 'startedAt': datetime.datetime(2024, 4, 24, 0, 6, 31, 17000, tzinfo=tzlocal()), 'startedBy': 'airflow', 'stopCode': 'EssentialContainerExited', 'stoppedAt': datetime.datetime(2024, 4, 24, 0, 8, 14, 468000, tzinfo=tzlocal()), 'stoppedReason': 'Essential container in task exited', 'stoppingAt': datetime.datetime(2024, 4, 24, 0, 7, 59, 446000, tzinfo=tzlocal()), 'tags': [], 'taskArn': 'arn:aws:ecs:us-west-2:777968769372:task/rikolti-ecs-cluster/9a86a3a2b74f4b859c29b7983f047218', 'taskDefinitionArn': 'arn:aws:ecs:us-west-2:777968769372:task-definition/rikolti-content_harvester-task-definition:6', 'version': 6, 'ephemeralStorage': {'sizeInGiB': 20}}], 'failures': [], 'ResponseMetadata': {'RequestId': 'ffbbbb1c-0e48-4ff4-bd57-e4db88b6ee56', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': 'ffbbbb1c-0e48-4ff4-bd57-e4db88b6ee56', 'content-type': 'application/x-amz-json-1.1', 'content-length': '3143', 'date': 'Wed, 24 Apr 2024 00:08:24 GMT'}, 'RetryAttempts': 0}}
[2024-04-24, 00:08:25 UTC] {{taskinstance.py:1824}} ERROR - Task failed with exception
Traceback (most recent call last):
  File "/usr/local/airflow/dags/rikolti/dags/shared_tasks/content_harvest_operators.py", line 116, in execute
    return super().execute(context)
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/utils/session.py", line 76, in wrapper
    return func(*args, session=session, **kwargs)
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/providers/amazon/aws/operators/ecs.py", line 476, in execute
    self._start_wait_check_task(context)
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/providers/amazon/aws/hooks/base_aws.py", line 743, in decorator_f
    return fun(self, *args, **kwargs)
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/providers/amazon/aws/operators/ecs.py", line 511, in _start_wait_check_task
    self._check_success_task()
  File "/usr/local/airflow/.local/lib/python3.10/site-packages/airflow/providers/amazon/aws/operators/ecs.py", line 659, in _check_success_task
    raise AirflowException(
airflow.exceptions.AirflowException: This containers encounter an error during launching: outofmemoryerror: container killed due to memory usage
[2024-04-24, 00:08:25 UTC] {{taskinstance.py:1345}} INFO - Marking task as FAILED. dag_id=harvest_collection, task_id=content_harvesting.content_harvest, map_index=0, execution_date=20240424T000508, start_date=20240424T000552, end_date=20240424T000825
[2024-04-24, 00:08:25 UTC] {{logging_mixin.py:150}} INFO - Message sent to SNS with Message ID: a230118f-e3d1-5cd5-9756-4f2dac685fbe
[2024-04-24, 00:08:25 UTC] {{standard_task_runner.py:104}} ERROR - Failed to execute job 77525 for task content_harvesting.content_harvest (This containers encounter an error during launching: outofmemoryerror: container killed due to memory usage; 846)
[2024-04-24, 00:08:25 UTC] {{local_task_job_runner.py:225}} INFO - Task exited with return code 1

This object has a 1GB tiff file: https://nuxeo.cdlib.org/nuxeo/nxdoc/default/83cbedca-e4cd-45ec-b2d1-490d6b9fd951/view_documents?conversationId=0NXMAIN
Do we want to support such enormous image files?

@barbarahui Nuxeo should support importing of large TIFFs as the main content file -- but we've previously leaned on Nuxeo to generate a JPEG derivative to fetch. We somehow got a JPEG derivative to display in CSphere prod for this object (simple image Nuxeo object, from UCB Bancroft), last time we harvested; https://calisphere.org/item/83cbedca-e4cd-45ec-b2d1-490d6b9fd951/ .
That said -- @christinklez is this one we could just ETL for the time being?

@aturner we can't ETL this because it is coming from Nuxeo.

Hmm yeah, I think the legacy deep harvester grabbed the "medium" sized image from Nuxeo rather than the full-sized image. I'll take a look at the rikolti content harvester code to see what's going on.
It's also possible that the legacy deep harvesting infrastructure supported processing larger files. There's also the option to bump up the memory on the ECS workers.

@aturner @christinklez Actually the legacy deep harvester did just grab the main content file. I'm guessing we had to use XL workers for processing this collection/object.
We haven't set up the rikolti harvester to be able to spin up mega-workers just for a specific collection. I guess we could temporarily reconfigure it for just this collection...

@aturner @christinklez It just occurred to me that you should be able to ETL this collection since there's only 1 simple objects. It's the complex objects that the ETL mapper doesn't support.

@barbarahui -- Exciting turn of events! I'll test this out now!!!!

@barbarahui @aturner -- ETL works for Nuxeo simple objects: https://calisphere-stage.cdlib.org/item/83cbedca-e4cd-45ec-b2d1-490d6b9fd951/
However, it's not supported by a viewer, and includes a circular link back to the page we're on.

Ohh, it's because the frontend determines whether or not the item is hosted based on mapper type. I can update the mapper type in OpenSearch to nuxeo.nuxeo for this one record. It's a bit hacky, and if you re-ETL this record it will break the viewer again but I think it's acceptable compromise for now?

@barbarahui I think that sounds acceptable for this record--I'll record this in our notes! @aturner, what do you think??

This sounds good to me -- as a back-pocket strategy for ETL'ing simple Nuxeo objects into the new index, for the time being!

Sadly this doesn't work. I forgot that since we ETLed the collection, the content harvester doesn't create the jp2 and so there isn't anything to display in the image viewer 👎
I vote for leaving this as is for now, if that's acceptable? As you say above, it's probably not worth doing the work to accommodate this object unless we run into a lot more of them?

I agree that we can move forward with this particular record as is. It's a quirky frontend experience, but it's not completely broken.
Let's consider this a low priority issue for now, and revisit if it happens to come up for other Nuxeo collections. Thank you for looking into this, Barbara!!


ThunderHub

OK, trying this again. Should only be 3 new files, one .md and two compressed .png .
As I said earlier, I have no idea at this point how much info is too much, too little, or just right. If anything, I kept it short and expandable if others think more is needed.
Please review & critique

Ok, I finally noticed that I branched off of abhiShandy's LND branch instead of master. Last time I do this without wearing my glasses.

You should checkout to master branch, pull the latest commits and then create a new branch


Callables for is_now?

I wonder if you'd considered allowing callable for is_now and was conditions? For example, if this function:
    def _check_is_now_condition(self, field_name: str, specs: dict) -> bool:
        return specs["is_now"] in (self._current_value(field_name), "*")

Was changed to something like:
    def _check_is_now_condition(self, field_name: str, specs: dict) -> bool:
        if callable(specs["is_now"]):
           return specs["is_now"](self)
        else:
           return specs["is_now"] in (self._current_value(field_name), "*")

Then users could pass a callable and implement any logic they like in relation to the tested values.

That's interesting. I had not considered it. Is there a specific use case you're working on? Might be helpful for us to have something to work backward from.


Atto Mixer

Was thinking about NANO privacy and I think atto could really help. I'm sure you're not really interested, but I figured I'd pitch the idea regardless.

echo $seed$ | atto mix -a 1 $amount -m $count $new_seed

Using $seed and using $amount of NANO from -a 1 split the $amount into random quantities and mix them between -m $count addresses from the seed.
So basically;

echo $seed | atto mix -a 1 10 -m 20 $new_seed

Would split the 10 NANO from account index 1 of $seed into random amounts (or just $amount / $addresses), and then shoot that balance around a bit between these 20 new addresses, and finally sweeping the total balance (10 NANO) into account index 0 of $new_seed. This way it makes it far far far more difficult to discern from where the funds initially came from. $new_seed could even be the same seed, mixing the balance from -m 1 into -m 0.
Or something to that effect. Doesn't really have to be that complicated. I know this really goes outside of what you want atto to do, but I feel like it could really help the community and something which is requested with more and more frequency. Let me know what you think.

Hi Zach,
thanks for the pitch. As you guessed, I would not include this with the "regular" atto. One could, however, write a script for this, using atto, or even a separate tool using the atto library.
I must say, though, that I'm not familiar with how mixers usually work, so I read the Wikipedia article on it. There I learned, that mixers do two things:

They pool funds from multiple participants.

They mix over a random, but long period of time. This makes it harder to distinguish the transactions from normal user transactions (I assume).

could be achieved in a script, that is similar to what you pitched, by introducing random delays between all transactions. 1. could not be achieved with such a script; I think that's why tumblers are always external services. There is another problem with the method you suggested: The node operator could always see, that all your "mixing-transactions" come from the same IP address and thus he could easily tell what you did.

My takeaway is, that the tool you suggested could reduce traceability a little bit, but would not prevent any serious investigator from finding out where the funds came from. Thus the tool could give the user a false feeling of security, which I find very dangerous. Personally I am a "all or nothing" kind of guy, so I'm afraid I'm not interested in developing such a tool.


Generate pulp package versions

This is used to generate: https://github.com/stackhpc/stackhpc-release-train-package-versions. Instructions:

Login to test pulp with:

(venv-pulp) [cloud-user@will-control-host-0 ~]$ pulp config create --username admin --base-url http://<IP_ADDRESS>:8080 --password <> --overwrite

Run playbook. The default output is to /tmp/pulp-packages.

This is quite a cool feature but obviously a long way out of date now. @jovial is there any chance we'll update it or should we close this?


Add new line before field description

If we will generate SDL schema then we get:
"""Desc 1"""
type Object1 @key(fields: "field1") {
  """Desc field 1"""
  field1: DateTime
  """Desc field 2"""
  field2: ID
  """Desc field 3"""
  field3: String
  field4: String
  field5: String
}

but by default there should be a new line before descriptions:
"""Desc 1"""
type Object1 @key(fields: "field1") {
  """Desc field 1"""
  field1: DateTime

  """Desc field 2"""
  field2: ID

  """Desc field 3"""
  field3: String
  field4: String
  field5: String
}

Can anybody check this PR please?

Hey there, I'll check it out more closely this week.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

2 of 3 (66.67%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 90.553%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

graphene_federation/service.py
2
3
66.67%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
393

Relevant Lines:
434

💛  - Coveralls


Theta and Tuple reset

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

23 of 23 (100.0%)  changed or added relevant lines in 9 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 92.656%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
2170

Relevant Lines:
2342

💛  - Coveralls


[OIS] OTA requestor and DFU implementation

Provides the implementation of the OTA Image Processor class for Open IOT SDK platform
Add Matter OTA support
Add OTA Requestor example

@woody-apple To review.


Add exercise: anagram

The tests coincide with:
https://github.com/exercism/x-common/blob/master/exercises/anagram/canonical-data.json

🚢 ❗


[Outreachy Meta] Read this issue if you are participating in the outreachy contribution period December 2024

Hello everyone!
Thank you for participating in Outreachy and being interested in contributing to the OpenTelemetry Project! This issue will help you during the contribution phase, by providing some instructions on how to get started and it also will list contribution period tasks you can pick up, complete and then submit!
Getting Help
If you have any questions, any issues, or just want to chat with mentors and participants, register with CNCF Slack and join the channels #otel-comms and #otel-registry-uxui-mentorship-outreachy-december-2024.
Getting Started
As a good starting point to familiarize yourself with our project, we recommend you dive into our contribution guidelines, especially the section around setting up a dev environment will be helpful, since you will need a local development environment to contribute to our project successfully.
Since those guidelines are made for new comers, do not hesitate to ask any questions or call out what is unclear!
When you have your local setup up and running I recommend that you start playing around with it by introductions minor changes and seeing how they affect the website. It’s all build using Hugo (https://gohugo.io/) and we use the docsy theme (https://www.docsy.dev/)
As you know for the project itself we will look into the UI/UX of the registry which you will find when you click on “Ecosystem” at the top and then registry. Explore it, try to find something with it, take a look if you understand how it works.
Contribution Period Tasks
When you have set up your local development as outlined above and have yourself familiarized with our website, and the registry, you can start with the small contribution period tasks from the list below:

after going to the Getting Started above, setting up the development environment and familiarizing yourself with the website & registry, apply a minor change to your local copy of the registry (http://localhost:1313/ecosystem/registry/), take a screenshot, visually highlight the change you applied on the image and attach the image as a comment to this issue.
review the Registry and create a short usability report using the following form: https://forms.gle/vA3vSQv5vcsmtdzQ9. Note: if you'd like to redo your report or if we ask you to apply changes to your report, just fill out the form another time.

After you have completed both steps above, we will ask you to implement one or two improvements for the registry UI and submit a pull request for it. Although we aim for it, we may not merge the PR during the contribution period, which will be for reasons outside of your control. In any case we will confirm with a comment, when you have completed the task successfully.
Here are a few requirements and recommendations for the implementations:

Make yourself familiar with Bootstrap and Docsy, since our current design is building on top of this framework and theme. Your change should not introduce any other major design framework dependencies. If you want to use an additonal external dependency, please ask on slack upfront if what you plan to use is acceptable.
As of today the registry is build within hugo, so it is a static website without a proper backend and database. This is a limitation we are not going to change in this project, so do not try to change that.
Provide your pull request early: there is no harm to submit your unfinished work as a draft PR. As a new comer to any opensource project it is advicable to ask for feedback early, so you are not spending a lot of time in implementation and will then be asked to change major parts once again
After you have provided your pull request there will be a set of CI checks running and some of them will very likely fail. Do not worry about them until told otherwise. Maintainers will help you to get them fixes as needed.

Registry Source Code
The OpenTelemetry Registry consists of multiple components that you will need to take a look into to modify it:

The _index page, which will cause hugo to render the page at /ecosystem/registry
search-form.html shortcode which is responsible for rendering the registry formular
registry partials a set of templates used for rendering entries and "quick install" instructions
registry.scss for the stylesheets
registrySearch.js powers the search engine
data/registry all the entries in the registry
registry.json.json for populating the search index

Thank you once again for contributing to OpenTelemetry!

@svrnm
I edited a line on the registry page, and I’ve completed the usability report form.

I had my name inputed as an author  for the cloud foundry article thereby validating usability report form.

I have edited the Envoy Proxy title and also filled out the usability report form.

Hello. I have edited index page and search form. Looking forward to the next part.

Hello i added my name as an author

Hello, I edited the Title and the Language & Type filter. I have also completed the usability report.

Hy  @svrnm, I've been able to successfully set up the codebase and make some edits. Moving to the form now

Hi, @svrnm It's Rebecca. I have set up the dev env on my local machine using WSL for Ubuntu.
I changed the background color and color of the "Search 832 entries" to blue and white as seen in the image below. I also added "Our" to the text.

Hello @svrnm, I am Yashi. I have been able to set up dev environment on my local and made some changes -

Have changed the background color of cloud foundry card and added black borders for the right section.
I have also filled out the usability form.
Thanks

Hello @svrnm I've been able to setup my local environment successfully also I added my name here ..  Moving to the form now

Hi @svrnm , my name is Oluchi Gift. I have been able to set up my dev environment. And i changed the title to Registry (Edited by Oluchi) and the subtitle to "This helps to find libraries, plugins, integrations and other useful tools for using and extending opentelemetry

Hello @svrnm I was able to set up my local environment and also made some changes underlines in red. I have also gone ahead to fill out the usability report.

Hi @svrnm, I have finished setting up the project locally. I have also made some edits to the registry page and filled out the usability form.

Hi @svrnm, I have finished setting up the project locally and I have made some changes to the registry.

Hi @svrnm i was able to make a small change to the registry

as highlighted below. Now moving on to the usability report

Hi,
Classic hello world 😉😅

@svrnm Please review this and give me your feedback.

Good day, I modified the form input placeholder to " Type to search the registry.." and the input field label.
**I am working from GitHub codespaces hence my project is not exactly reflecting "localhost:1313..." please let me know if this is not allowed.

@ladyami while I appreciate your effort, please review the instructions in the issue description above, I ask people to show a screenshot of them successfully setting up a dev environment, and also the survey (that you filled out) is not asking for a visual design suggestion yet.

I am sorry I did the design based on what I read about the project in outreachy website here is my setup I set it up on gitpod

@svrnm Good day, I have successfully set up my local dev environment and was able to edit the index page and search button (from Submit to Search) and I also included the link to Traefik hub API management. I have also filled the usuability form.

Good day @svrnm, I have successfully set up the local dev environment and edited the registry page. I have also filled the usability form.

Hello @svrnm, I have successfully set up my local environment.

[!IMPORTANT]
Thank you all for participating, as announced I closed the project for new contributors. I will work with those of you who still have open tasks to work on.

[!IMPORTANT]
The deadline to register for the project via the outreachy platform has been extended until Oct 23 7am UTC. If you want to participate, please make sure that you record at least one contribution to the "OpenTelemetry Registry" project.


CPU-only compilation fails

Issue summary
It is not possible to compile gnina in CPU-only mode. If the CPU_ONLY flag is used in cmake, all CUDA-related flags remain active. During the compilation, CUDA is persistently being searched, checked and .cu sources compiled regardless of CPU_ONLY and CUDA settings (trying to turn CUDA off). CUDA is installed on the test system, but I do not want it to be used. Finally, the compilation fails at caffe:

[  5%] Building CXX object caffe/src/caffe/CMakeFiles/caffe.dir/layers/batch_reindex_layer.cpp.o
In file included from /home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/blob.hpp:8,
                 from /home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/layers/argmax_layer.hpp:6,
                 from /home/gigo/autodock/gnina/github/gnina01/caffe/src/caffe/layers/argmax_layer.cpp:6:
/home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/common.hpp: In static member function 'static void caffe::Caffe::device_synchronize()':
/home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/common.hpp:173:56: error: 'cudaDeviceSynchronize' was not declared in this scope; did you mean 'device_synchronize'?
  173 |   inline static void device_synchronize() { CUDA_CHECK(cudaDeviceSynchronize()); }
      |                                                        ^~~~~~~~~~~~~~~~~~~~~
      |                                                        device_synchronize
In file included from /home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/blob.hpp:8,
                 from /home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/layers/accuracy_layer.hpp:6,
                 from /home/gigo/autodock/gnina/github/gnina01/caffe/src/caffe/layers/accuracy_layer.cpp:5:
/home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/common.hpp: In static member function 'static void caffe::Caffe::device_synchronize()':
/home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/common.hpp:173:56: error: 'cudaDeviceSynchronize' was not declared in this scope; did you mean 'device_synchronize'?
  173 |   inline static void device_synchronize() { CUDA_CHECK(cudaDeviceSynchronize()); }
      |                                                        ^~~~~~~~~~~~~~~~~~~~~
      |                                                        device_synchronize
/home/gigo/autodock/gnina/github/gnina01/caffe/include/caffe/common.hpp:173:45: error: 'CUDA_CHECK' was not declared in this scope; did you mean 'DCHECK'?
  173 |   inline static void device_synchronize() { CUDA_CHECK(cudaDeviceSynchronize()); }
      |                                             ^~~~~~~~~~
      |                                             DCHECK

With CUDA and cuDNN, gnina compiles and works fine.
I would be grateful for some hints on how to proceed.
Thank you very much for gnina!
Best,
g
Steps to reproduce
cd gnina
mkdir build01
cd build01
cmake .. -DCPU_ONLY=ON -DBUILD_python=OFF -DBUILD_python_layer=OFF
make
Your system configuration
Operating system: Debian sid
Compiler: gcc 12.1.0
CUDA version (if applicable): not applicable
CUDNN version (if applicable): not applicable
Python version: 3.10.5 (not applicable?)
cmake: 3.23.3

Currently, you have to build with CUDA, but once it it built you do not have to use it.

Duplicate of #168


qutebrowser configuration

take a look at how to configure qutebrowser: https://www.qutebrowser.org/doc/help/configuring.html

finish configuring qutebrowser
look into user scripts


Fix for issue #61

"get-stdin" now uses the Promise API from v5.0.0
https://github.com/sindresorhus/get-stdin/commit/385a9ce4b44e9311158d58de14e919b67f45b638#diff-0730bb7c2e8f9ea2438b52e419dd86c9L19

Oh awesome, thanks @turusuke

Published as v4.1.3


WFLY-9728 Upgrade jgroups-azure to 1.2.0.Final

Jira
https://issues.jboss.org/browse/WFLY-9728

@rhusar heh needs a rebase

:-) Rebased now.


method Intersects of Class  MRect  storage problem

public bool Intersects(MRect? rect)
{
    if (rect is null) return false;

    if (rect.Max.X < Min.X) return false;
    if (rect.Max.Y < Min.Y) return false;
    if (rect.Min.X > Max.X) return false;
    if (rect.Min.Y > Max.Y) return false;

    return true;
}

It is not an intersecting relationship judgment.
I hope my findings can help improve

This is my intersection implementation
public bool Intersects(MRect? rect)
{
if (rect is null) return false;
    return (rect.Contains(TopLeft) || rect.Contains(TopRight) || rect.Contains(BottomLeft) || rect.Contains(BottomRight));
}

Are you saying the method is not correct? Do you have an example of a flawed calculation?


perf issue with 'ws' in "drop-in" mode

Hey, thanks for working on improving ws performance.
I'm testing uWebsocket as a drop-in to replace 'ws.
The test is very basic...
I have a single client that connects and sends 100,000 short MsgPack messages.
Time to completion for ws server: 26,026ms
Time to completion for uWebSockets: 31,060ms
I realize this is a micro-benchmark, and kind of meaningless in isolation, but it is worth noting.

Do you have the benchmark source code for us to test it with?

Yup, I'm at lunch now.  Give me a few
On Jul 18, 2016 12:37 PM, "Иван К"<EMAIL_ADDRESS>wrote:

Do you have the benchmark source code for us to test it with?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233296186,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0shVSTVbr4FuKGvIvjj0lZZ40ccMks5qW1d8gaJpZM4JOlrK
.

You connect 1 client, send 100k short messages and what is considered completion? Echo?

Is this over network or just connecting to localhost?

localhost
On Jul 18, 2016 1:00 PM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

Is this over network or just connecting to localhost?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233299932,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0tG5o8Il64v_hz0S-Tdlvm5BwvS-ks5qW1zCgaJpZM4JOlrK
.

No not echo.
The first message prints out the time on the server, then I send 100k
messages Then I instruct the server to print the time again. These are real
timings
On Jul 18, 2016 12:45 PM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

You connect 1 client, send 100k short messages and what is considered
completion? Echo?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233297507,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0sJrZ2fSAyvYtGmhJUEjLGKTNaC0ks5qW1lOgaJpZM4JOlrK
.

So you have any code? What OS is this on?

On my way back from lunch. Will get you the code.
It's on Linux Mint Sarah up to date.
On Jul 18, 2016 1:39 PM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

So you have any code? What OS is this on?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233306238,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0lLsKFkhhIHM_o8nt98cioQLQcw-ks5qW2YLgaJpZM4JOlrK
.

I can definitely see a difference in the two servers.
I checked, and I get to read 20 bytes all the time (I send 100k 20 byte). ws (the client) sends all the messages as separate packages, this is not what you want to do. This is what TCP_NODELAY is about, queuing up small sends into bigger packages. If you would send 100k messages as one package, or maybe a couple packages then µWS would parse them a lot faster than ws (I wouldn't be surprised about a 50x improvement).
Currently I cork the socket on each read event, so this adds two syscalls per read. I guess this is one difference that shows here. I could make the corks more intelligent by only corking when you actually send something, but its such a small difference in perf. The main idea is to not have the client send a lot of small packages.

You could make polls that trigger all the time take a break and use a timer of 5ms instead. That way each read would be doing far more. But that's just strange and not really something you want in real situations.

Something like SO_RCVLOWAT could potentially be used...

I mean I can get 8ms with SO_RCVLOWAT but it doesn't time out so I cannot use it. But the general idea is to not trigger a read on every 20 bytes. You will never get 20 bytes sent like this if the transmitter uses default TCP settings (aka not using TCP_NOWAIT).

@socmag Can you test with cork/uncork?
ws._socket.cork();
// do all your sends
ws._socket.uncork();
I can get 2ms with this.

What's even more messed up is how I get 7 seconds in Node.js, while I get 2 ms in the C++ server...

@socmag I need your code and I need you to test what I've asked you to test. Both ws and uws are in the seconds, not milliseconds in my test.

Sorry was distracted here... I think you are on to something here with the
comments above.  I'll try it.
I'm going to send you two separate test suites... the original one with
some of my application logic inside, and another test-suite which is a
purely "synthetic benchmark".
First of all, here is the "synthetic benchmark", and an excel graph that we
made from it.
just run server.js, then in another console client.js
server.js will print out line by line a CSV
Batch Size,  Time For Batch, Messages Per Second
The client starts by sending 1000 messages, then waits for the server to
process them all, at which point it sends 2000 messages, and so on,
incrementing the batch size by 1000.
You will notice in the graph that on Linux at least, there is a steep cliff
at batch sizes of 75k messages (for both 'ws' and uWebSockets) where all of
a sudden we go from processing ~20k messages/sec to around 4,500.   As we
approach batch sizes of 100k messages it drops off even further.  We are
not sure if this is Node GC, or the networking stack.  We don't think this
is anything to do with you guys.
Okay, here is the test.  I'll send you the one with some of our app code in
a sec.  Need to reboot back to linux
On Mon, Jul 18, 2016 at 3:41 PM, Alex Hultman<EMAIL_ADDRESS>wrote:

@socmag https://github.com/socmag I need your code and I need you to
test what I've asked you to test. Both ws and uws are in the seconds,
not milliseconds in my test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233331288,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0qpx3KaWeIThK22kphEDIFbsu2Mvks5qW4JvgaJpZM4JOlrK
.

Note that Github issues do not show attachments. You need to upload it somewhere, and then provide a link to it.

A decent host is https://conf.6f.io/ -- it deletes all uploads after 24 hours.

Or if you want a more permanent solution, put it all in a Github Gist.

(y)
On Mon, Jul 18, 2016 at 4:33 PM, Иван К<EMAIL_ADDRESS>wrote:

Or if you want a more permanent solution, put it all in a Github Gist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233346535,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0gsbKwbeoji51kOgOb9_fng-m9UEks5qW47VgaJpZM4JOlrK
.

LOL!
Yes that is messed up, but I can believe it :/
So I tried the cork/uncork idea in the client.  At first it didn't make any
difference whatsoever, but then I realized the sends are async, and the
cork/uncork's are not - duh.
Like you said, if I go into a cork/uncork cycles on a timer, things work
much better, but yes, it's an odd way to code it.
I totally it would be better if the client wasn't sending so many tiny
messages flooding the networking stack.  That's fine and I can even do that
in my own protocol layer.  It's not a huge deal - I can batch
hundreds/thousands of messages.  My main concern was why uWS (at least in
my app) was taking longer than ws, and I just wanted you to know.
I'm trying a more intelligent cork/uncork thing right now as well.
On Mon, Jul 18, 2016 at 3:20 PM, Alex Hultman<EMAIL_ADDRESS>wrote:

What's even more messed up is how I get 7 seconds in Node.js, while I get
2 ms in the C++ server...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233325936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0ka5qOPlwjRErgvvjgGxwhOq3XI5ks5qW32LgaJpZM4JOlrK
.

okay, so this "nagle" algorithm is the best general case we could come up
with without a lot more effort.   It does improve things quite a bit, but
it's not spectacular (about 10-20%) at the cost of some latency.
we're going to try using the C/C++ version of the library and see how we
get on with that.  i'm sure it will be much better.
cheers,
-chris
On Mon, Jul 18, 2016 at 5:18 PM, Christian Beaumont <
<EMAIL_ADDRESS>wrote:

LOL!
Yes that is messed up, but I can believe it :/
So I tried the cork/uncork idea in the client.  At first it didn't make
any difference whatsoever, but then I realized the sends are async, and the
cork/uncork's are not - duh.
Like you said, if I go into a cork/uncork cycles on a timer, things work
much better, but yes, it's an odd way to code it.
I totally it would be better if the client wasn't sending so many tiny
messages flooding the networking stack.  That's fine and I can even do that
in my own protocol layer.  It's not a huge deal - I can batch
hundreds/thousands of messages.  My main concern was why uWS (at least in
my app) was taking longer than ws, and I just wanted you to know.
I'm trying a more intelligent cork/uncork thing right now as well.
On Mon, Jul 18, 2016 at 3:20 PM, Alex Hultman<EMAIL_ADDRESS>wrote:

What's even more messed up is how I get 7 seconds in Node.js, while I get
2 ms in the C++ server...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233325936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0ka5qOPlwjRErgvvjgGxwhOq3XI5ks5qW32LgaJpZM4JOlrK
.

We still don't have any example code from you. Like I said, whatever files you attached to your email, we cannot see or access them.

Ah damn, I'll send it to you in the morning, already left work. Sorry about
that.
The good news is we rewrote it in C++ this evening and now we are handling
300,000 messages at 6% CPU on one core within our broker.
Much better and nice work guys!
We are having beer!
cheers,
-chris
On Jul 18, 2016 6:55 PM, "Иван К"<EMAIL_ADDRESS>wrote:

We still don't have any example code from you. Like I said, whatever files
you attached to your email, we cannot see or access them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233389216,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0mjy33Q_4rNIq8k-oJr5wf6jG8JFks5qW6__gaJpZM4JOlrK
.

@socmag You want to spend some time on Gitter tomorrow? I still haven't gotten enough info. It's really strange, I'm getting 7 seconds, ws is getting 5 seconds and the C++ server is getting 2 milliseconds. Maybe this is just JavaScript overhead and not at all about networking or anything other. I still don't get if your timings are in seconds or milliseconds? Do you mean 26 seconds or 26 milliseconds? I get 36 milliseconds in the C++ server without corked sends and I get 2 milliseconds when corking sends.

@socmag OMFG, I just realized I was using permessage-deflate in Node.js! I disabled it, now it runs about the same as the C++ server (which ofc was running without it). If you cork your sends µWS is about 10x faster just by looking at it.
I think this is really not an issue. If you need good throughput you should either cork your sends or use default TCP settings which will automatically group small sends into larger packets.

I'm closing this as I now have absolutely no problems significantly outperforming ws, and I don't see any reason to try and tinker with the perf when reading 20 bytes per send (this is not how things are supposed to be used anyways).
If you still have problems getting good perf with µWS I would like to see some code.

Here are my benchmark numbers if you're interested:
Non-corked send: 1100ms (µWS), 900ms (ws)
Corked send: 90ms (µWS), 900ms (ws)
So yeah, you're right - ws is currently a little faster handling non-corked masses of small messages, but if you apply nagles algorithm or cork ontop of this the perf is dramatically to µWS advantage.

And with C++:
Non-corked: 1050ms (I need to look into this one!)
Corked: 3ms

I've checked why ws is faster - they are not getting 20 bytes with every read but rather a chunk of 65kb. I tested removing everything in my readable event handler and it still executed in 1050ms. It's not possible to be any faster than this if you are going to respond to every readable event. I guess libuv does some kind of coalescing of receives, will check that out. But yeah, ws is already as fast as it can be at 900ms, while you can potentially get down to 2-3ms in µWS.

Hah, you know, I wondered if you were doing that. It did cross my mind.
Well that sounds great.
I'm not going to switch back to Node at this point (for he server at least)
since the C++ version is so fast it's not even funny, plua the memory usage
trundles along at 34MB working set and 6% CPU while the Node clients are
utilizing 1.3GB of RAM and occupying 100% of a full core.
I will be using it for some peripheral services on the other hand, so it is
still impprtant.
I will get you the benchmark when I get to work. Currently waiting here at
home for the postman to pick up a package.
On Jul 18, 2016 11:25 PM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

@socmag https://github.com/socmag OMFG, I just realized I was using
permessage-deflate in Node.js! I disabled it, now it runs about the same as
the C++ server (which ofc was running without it). If you cork your sends
µWS is about 10x faster just by looking at it.
I think this is really not an issue. If you need good throughput you
should either cork your sends or use default TCP settings which will
automatically group small sends into larger packets.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233464009,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0lL9D5eOcP-v73pQDkoTDrqN74yzks5qW-9egaJpZM4JOlrK
.

Good stuff. Yup closed.
Thanks!
On Jul 19, 2016 12:33 AM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

And with C++:
Non-corked: 1050ms (I need to look into this one!)
Corked: 3ms
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233479403,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0iRy55XSP4QxWUvbafVndSmXVBSpks5qW_9BgaJpZM4JOlrK
.

Yeah I guess you are better off with the C++ server then. Hope it works out good. Btw, I just tested a raw net.Socket in Node.js and it actually has this coalescing built-in, it triggers 65k long chunks so it's not even a matter of ws or not ws, it's more of a difference in the way net.Socket works compared to the raw sockets I use.

@socmag I cleaned up here a bit. I know why this happens now.
We both have done the very classic flaw of benchmarking the wrong component. We've not been benchmarking the server at all. Just the client. You cannot benchmark µWS with ws as client - that's wrong in so many ways.
Basically, the bottleneck here is ws - it cannot go any faster than 900 ms no matter if you cork or not. If you replace ws with a high perf client (I just wrote a basic one) you will see µWS outperform ws no matter if you cork or not. We are talking 10-300x better perf in µWS.

ws client (not corked) -> ws server takes 900 ms (bottleneck: ws)
ws client (not corked) -> µWS server takes 1050 ms (bottleneck ws, added kernel overhead of excessive syscalls)
ws client (corked) -> ws server takes 900 ms (bottleneck: ws)
ws client (corked) -> µWS server takes 3 ms (bottleneck: µWS)
high perf client (not corked) -> µWS server takes 100 ms (bottleneck: syscalls)
high perf client (not corked, but using TCP_NOWAIT=false) -> µWS server takes 18 ms (bottleneck: syscalls / µWS)
high perf client (not corked, but using TCP_NOWAIT=false) -> ws server takes 900 ms (bottleneck: ws)

When µWS is fast enough to process the data faster than the speed it is being produced you get thousands of small reads of size 20 bytes. Since ws is the bottleneck, any disturbance of the resources ws makes use of will slow it down. I guess the added 150 ms comes from µWS reading the buffer ws is writing to all the time, I don't know exactly how this works in the kernel but it makes sense. If you disturb the producer which is the bottleneck you will get worse performance. I don't know if this is correct but that's the closest explanation I can think of.
As an example of how obvious this is [that ws is the bottleneck], I added a blocking sleep of 500 ms in the message handler of µWS. This speeded up the receive dramatically. That's not how it works. You don't get better performance by sleeping for 500 ms!
So trying this out with the high perf client, I got something like 10 ms in µWS and obviously ws still performing at 900 ms. Just to really make it glass clear I added a 1 nanosecond sleep between my sends in the client and logged the size of the receives in µWS. They all has the size of 20-50 bytes, while still performing the full receive at about 180 ms. Obviously the bottleneck is ws, which makes this issue invalid from the get go. Always use high perf clients when benchmark, otherwise the benchmark is invalid.

Guys...
https://gist.github.com/socmag/a2a195923767bb4196c9559e2fc530ba
Sorry it took so long to get you this, people have had me running around
the last couple of days and it has been quite hectic.
For me, 'ws' is faster than 'uws' in uncorked mode, and 'uws' is faster in
corked mode. (Benchmark timings for ws/uws corked/uncorked in the Gist)
Would be interested to know what you get as results...
cheers,
-chris
On Mon, Jul 18, 2016 at 11:25 PM, Alex Hultman<EMAIL_ADDRESS>wrote:

@socmag https://github.com/socmag OMFG, I just realized I was using
permessage-deflate in Node.js! I disabled it, now it runs about the same as
the C++ server (which ofc was running without it). If you cork your sends
µWS is about 10x faster just by looking at it.
I think this is really not an issue. If you need good throughput you
should either cork your sends or use default TCP settings which will
automatically group small sends into larger packets.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233464009,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0lL9D5eOcP-v73pQDkoTDrqN74yzks5qW-9egaJpZM4JOlrK
.

Like I said, ws is never faster than uws. You are using an extremely slow client, that's the problem. Use a faster client (or cork) and you see that uws is 300x faster than ws. You cannot possibly squeeze out anything faster than 900 ms when using ws, while uws does it in 3 milliseconds.

This is a fast client, use it and see the 300x (we are talking 30000%) perf diff:
#include <stdio.h>
#include <stdlib.h>

#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>

#include <chrono>
#include <thread>
using namespace std;

int main(int argc, char *argv[]) {
   int sockfd, portno, n;
   struct sockaddr_in serv_addr;
   struct hostent *server;

   char buffer[1024];
   portno = 3000;
   sockfd = socket(AF_INET, SOCK_STREAM, 0);
   server = gethostbyname("localhost");
   bzero((char *) &serv_addr, sizeof(serv_addr));
   serv_addr.sin_family = AF_INET;
   bcopy((char *)server->h_addr, (char *)&serv_addr.sin_addr.s_addr, server->h_length);
   serv_addr.sin_port = htons(portno);
   if (connect(sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr)) < 0) {
      return -1;
   }

   int flag = 1;
   setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int));

    const char upgradeHeaderBuffer[] = "GET / HTTP/1.1\r\n"
                                       "Upgrade: websocket\r\n"
                                       "Connection: Upgrade\r\n"
                                       "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==\r\n"
                                       "Host: server.example.com\r\n"
                                       "Sec-WebSocket-Version: 13\r\n\r\n";

    send(sockfd, upgradeHeaderBuffer, sizeof(upgradeHeaderBuffer) - 1, 0);

    recv(sockfd, buffer, sizeof(buffer) - 1, 0);

    int byteSize = 20, framesPerSend = 1;
    unsigned char *framePackBuffer;
    int framePackBufferLength = 0;

    // Fill with random data
    int allocLength = (byteSize + 14) * framesPerSend;
    framePackBuffer = new unsigned char[allocLength];
    for (int i = 0; i < allocLength; i++) {
        framePackBuffer[i] = rand() % 255;
    }

    // Format message frame(s)
    unsigned char *framePackBufferOffset = framePackBuffer;
    for (int i = 0; i < framesPerSend; i++) {
        framePackBufferOffset[0] = 130;
        if (byteSize < 126) {
            framePackBufferLength += byteSize + 6;
            framePackBufferOffset[1] = 128 | byteSize;
            framePackBufferOffset += byteSize + 6;
        } else if (byteSize <= UINT16_MAX) {
            framePackBufferLength += byteSize + 8;
            framePackBufferOffset[1] = 128 | 126;
            *((uint16_t *) &framePackBufferOffset[2]) = htons(byteSize);
            framePackBufferOffset += byteSize + 8;
        } else {
            framePackBufferLength += byteSize + 14;
            framePackBufferOffset[1] = 128 | 127;
            *((uint64_t *) &framePackBufferOffset[2]) = htobe64(byteSize);
            framePackBufferOffset += byteSize + 14;
        }
    }

    for(int i = 0; i < 100000; i++) {
        send(sockfd, framePackBuffer, framePackBufferLength, 0);
    }

   return 0;
}

I appreciate that. I'm just sending you the benchmark and the numbers as
requested that I am seeing. Slow client or not.  Did you even look at it?
:-)
Anyway as I said, it isn't even a problem anymore since now I am using your
library in C++.
Which rocks by the way. It far outshines WebSocket++
On Jul 20, 2016 11:21 AM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

Like I said, ws is never faster than uws. You are using an extremely
slow client, that's the problem. Use a faster client (or cork) and you
see that uws is 300x faster than ws. You cannot possibly squeeze out
anything faster than 900 ms when using ws, while uws does it in 3
milliseconds.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233897448,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0j-P1IIB6a_cjJzkMfTfXzEk8SzQks5qXeiFgaJpZM4JOlrK
.

Thanks for the fast client!
On Jul 20, 2016 11:26 AM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

This is a fast client, use it and see the 300x (we are talking 30000%)
perf diff:
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include
#include using namespace std;
int main(int argc, char *argv[]) {
int sockfd, portno, n;
struct sockaddr_in serv_addr;
struct hostent *server;
char buffer[1024];
portno = 3000;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
server = gethostbyname("localhost");
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *)server->h_addr, (char )&serv_addr.sin_addr.s_addr, server->h_length);
serv_addr.sin_port = htons(portno);
if (connect(sockfd, (struct sockaddr)&serv_addr, sizeof(serv_addr)) < 0) {
return -1;
}
int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int));
const char upgradeHeaderBuffer[] = "GET / HTTP/1.1\r\n"
                                   "Upgrade: websocket\r\n"
                                   "Connection: Upgrade\r\n"
                                   "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==\r\n"
                                   "Host: server.example.com\r\n"
                                   "Sec-WebSocket-Version: 13\r\n\r\n";

send(sockfd, upgradeHeaderBuffer, sizeof(upgradeHeaderBuffer) - 1, 0);

recv(sockfd, buffer, sizeof(buffer) - 1, 0);

int byteSize = 20, framesPerSend = 1;
unsigned char *framePackBuffer;
int framePackBufferLength = 0;

// Fill with random data
int allocLength = (byteSize + 14) * framesPerSend;
framePackBuffer = new unsigned char[allocLength];
for (int i = 0; i < allocLength; i++) {
    framePackBuffer[i] = rand() % 255;
}

// Format message frame(s)
unsigned char *framePackBufferOffset = framePackBuffer;
for (int i = 0; i < framesPerSend; i++) {
    framePackBufferOffset[0] = 130;
    if (byteSize < 126) {
        framePackBufferLength += byteSize + 6;
        framePackBufferOffset[1] = 128 | byteSize;
        framePackBufferOffset += byteSize + 6;
    } else if (byteSize <= UINT16_MAX) {
        framePackBufferLength += byteSize + 8;
        framePackBufferOffset[1] = 128 | 126;
        *((uint16_t *) &framePackBufferOffset[2]) = htons(byteSize);
        framePackBufferOffset += byteSize + 8;
    } else {
        framePackBufferLength += byteSize + 14;
        framePackBufferOffset[1] = 128 | 127;
        *((uint64_t *) &framePackBufferOffset[2]) = htobe64(byteSize);
        framePackBufferOffset += byteSize + 14;
    }
}

for(int i = 0; i < 100000; i++) {
    send(sockfd, framePackBuffer, framePackBufferLength, 0);
}

return 0;
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233898627,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0jGakNDyirHo1jgei44Xp7vrK5-Gks5qXem_gaJpZM4JOlrK
.

I did take a look at it and I can see your results. The problem is, the results are invalid. You are benchmarking the client. ws never were and never will be faster than uws, that is completely insane. You need to realize ws is the slowest WebSocket library of all tested. It's a complete joke to even consider ws being even remotely close to the speed of uws, especially when stressing the parser like this. The parser is 95% of what makes uws fast. It's a zero-copy SIMD beast built directly ontop of the kernel. ws's parser is built in play dough, hello kitty toy script. What you are observing is kernel contemption and nothing else.

You need to understand that the send syscall is going to take longer time to execute if it needs to trigger a readable event each time, right?
When ws is the server, it is not as fast, so it doesn't have time to read in time, so data sent is being buffered.

send -> trigger read
send -> does not trigger read, since server has not read yet, buffer up
send -> does not trigger read, since server has not read yet, buffer up
recv
send -> trigger read

vs.

send -> trigger read
recv
send -> trigger read
recv
send -> trigger read

Triggering an event on each send is making the client slower and this it seems uws is slower. You are observing an excessive event overhead.

Oh I get all right, I've looked at the code for your library and it's quite
beautiful.
One of tge problems is that from the current bits available on NPM, there
is no way to use uws as the client (or did you fix that already).

My only purpose for even creating this thread was to try and help. At least
now, when someone else cones along you can point art me and say look, this
dude went through the same exercise. There was a difference which I pointed
out, but now I understand more fully.
Also it was certainly a useful exercise for me having only discovered your
work a couple of days ago.
I'm building a serious piece of infrastructure architecture on top of this
thing, and really do appreciate what you have done.
In fact I almost don't want to tell anyone about it because it's that
goodMy little secret. Haha.
Alright, putting this thing to bed. I'll go grab lunch and then test the
new client.
cheers
-chris
On Jul 20, 2016 11:51 AM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

I did take a look at it and I can see your results. The problem is, the
results are invalid. You are benchmarking the client. ws never were and
never will be faster than uws, that is completely insane. You need to
realize ws is the slowest WebSocket library of all tested. It's a
complete joke to even consider ws being even remotely close to the speed of
uws, especially when stressing the parser like this. The parser is 95% of
what makes uws fast. It's a zero-copy SIMD beast built directly ontop of
the kernel. ws's parser is built in play dough, hello kitty toy script.
What you are observing is kernel contemption and nothing else.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233904311,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0hjRbCfM_C6E9_8jLUJ6xOhAhvO5ks5qXe-ogaJpZM4JOlrK
.

new timings are here...
10 clients sending 2,000,000 messages each in parallel
For a total of 20,000,000 messages processed
Total time taken: 2641.09
Messages Per Second: 7,572,638
awesome!
that'll do ;-)
On Wed, Jul 20, 2016 at 11:26 AM, Alex Hultman<EMAIL_ADDRESS>wrote:

This is a fast client, use it and see the 300x (we are talking 30000%)
perf diff:
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include
#include using namespace std;
int main(int argc, char *argv[]) {
int sockfd, portno, n;
struct sockaddr_in serv_addr;
struct hostent *server;
char buffer[1024];
portno = 3000;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
server = gethostbyname("localhost");
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *)server->h_addr, (char )&serv_addr.sin_addr.s_addr, server->h_length);
serv_addr.sin_port = htons(portno);
if (connect(sockfd, (struct sockaddr)&serv_addr, sizeof(serv_addr)) < 0) {
return -1;
}
int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int));
const char upgradeHeaderBuffer[] = "GET / HTTP/1.1\r\n"
                                   "Upgrade: websocket\r\n"
                                   "Connection: Upgrade\r\n"
                                   "Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==\r\n"
                                   "Host: server.example.com\r\n"
                                   "Sec-WebSocket-Version: 13\r\n\r\n";

send(sockfd, upgradeHeaderBuffer, sizeof(upgradeHeaderBuffer) - 1, 0);

recv(sockfd, buffer, sizeof(buffer) - 1, 0);

int byteSize = 20, framesPerSend = 1;
unsigned char *framePackBuffer;
int framePackBufferLength = 0;

// Fill with random data
int allocLength = (byteSize + 14) * framesPerSend;
framePackBuffer = new unsigned char[allocLength];
for (int i = 0; i < allocLength; i++) {
    framePackBuffer[i] = rand() % 255;
}

// Format message frame(s)
unsigned char *framePackBufferOffset = framePackBuffer;
for (int i = 0; i < framesPerSend; i++) {
    framePackBufferOffset[0] = 130;
    if (byteSize < 126) {
        framePackBufferLength += byteSize + 6;
        framePackBufferOffset[1] = 128 | byteSize;
        framePackBufferOffset += byteSize + 6;
    } else if (byteSize <= UINT16_MAX) {
        framePackBufferLength += byteSize + 8;
        framePackBufferOffset[1] = 128 | 126;
        *((uint16_t *) &framePackBufferOffset[2]) = htons(byteSize);
        framePackBufferOffset += byteSize + 8;
    } else {
        framePackBufferLength += byteSize + 14;
        framePackBufferOffset[1] = 128 | 127;
        *((uint64_t *) &framePackBufferOffset[2]) = htobe64(byteSize);
        framePackBufferOffset += byteSize + 14;
    }
}

for(int i = 0; i < 100000; i++) {
    send(sockfd, framePackBuffer, framePackBufferLength, 0);
}

return 0;
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233898627,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0jGakNDyirHo1jgei44Xp7vrK5-Gks5qXem_gaJpZM4JOlrK
.

How does ws perform in this test?

That was against my C++ server, I just did even better with 100 clients -
broke the 11 million messages per second barrier.  Maxed out my laptop
though.
I'll try it with the node server in a bit and let you know.  I already know
ws will suck.
By the way, the C++ server just stays steady at ~35MB resident memory.
I gave you a shout out on twitter btw.
On Wed, Jul 20, 2016 at 2:51 PM, Alex Hultman<EMAIL_ADDRESS>wrote:

How does ws perform in this test?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-233939420,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0o8lfDsoMfd7nxod78nGfQDE8-JUks5qXhm1gaJpZM4JOlrK
.

You mind testing ws also? For fun.

No of course not, I'll do it.
By the way, I saw you had an issue open regarding wanting help testing on
Windows. I can help with that too.
The only thing with that is that the npm bits didn't build out of the box
with Visual Studio installed, and I didn't have time to look into it.
It looked in the tree like you were also working on a client mode as well.
Is that right?
I have been stuck in meetings a lot, but I'll get to it.
On Jul 21, 2016 2:00 PM, "Alex Hultman"<EMAIL_ADDRESS>wrote:

You mind testing ws also? For fun.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-234233365,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0kfW4egTj4M9bFICUngd1UXJikT7ks5qX19agaJpZM4JOlrK
.

Yep next version will have client support and a new interface.

Okay I ran some tests...
tried varying 1 client, 10 clients 100 clients
tried varying messages sent per client @ 50k, 100k and 2 million
pretty much in all cases, uws showed this kind of profile
932,574
924,898
941,530
921,574
972,384
957,395
951,565
955,155
934,230
960,245
961,908
970,073
pretty much in all cases ws had this kind of profile
246,256
215,517
248,787
213,675
248,737
244,130
241,887
236,406
229,357
240,153
Numbers are messages per second.
So in node basically four times faster out of the box using the fast client
that you gave me.
For my C++ server, the numbers are
2,203,166
2,307,043
6,173,465
11,075,824
12,702,170
10,657,072
12,493,203
10,743,498
12,467,487
12,890,398
Basically the more messages and clients I threw at it, the more it scaled.
Note that for these test, I am not round-tripping the incoming messages
back to the client. They are purely client -> server.
Unfortunately I don't have the setup or time to really dig further into it
right now, but clearly uWS is very good - especially native.
cheers,
-chris
On Thu, Jul 21, 2016 at 2:00 PM, Alex Hultman<EMAIL_ADDRESS>wrote:

You mind testing ws also? For fun.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uWebSockets/uWebSockets/issues/199#issuecomment-234233365,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGQZ0kfW4egTj4M9bFICUngd1UXJikT7ks5qX19agaJpZM4JOlrK
.


questions about prediction API

Hi community
Recently, I'm playing with MXNet. and some questions raised during my experiments.
Q1: I just wonder why size of libmxnet_predict.so is large than libmxnet.so? Is it(amalgamation version) target to have a compact lib?
Info:

both are compiled only support CPU
openBLAS is used.
for libmxnet: has Opencv, no openmp, no KVStore, no hdfs, no s3
platform is Mac OSX 10.12
libmxnet_predict.so is around 22M, and libmxnet.so is around 16M.

Q2: I'm using lstm_bucketing.py from rnn folder as training script. and I added following two lines to save json/model parameter.
    model.save_params('xx.params')
    model.symbol.save('xx.json')

but json string could be not parsed by MXPredCreate function of prediction library.
error code shows
mxnet_predict-all.cc:22737: Check failed: op != nullptr Operator Embedding is not registered
Assertion failed: (predh)
It seems embedding OP is not compiled in prediction library.  My question is do we have any workaround to use Embedding layer in prediction library? Or do we have any example to show how to load pre-trained word embedding vectors using CPP or python?
Thanks !
K.

you need to add src/operator/embedding.cc into amalgamation/mxnet-predict0.cc

@piiswrong there is not such file src/operator/embedding.cc
it seems that the embedding code is now in src/operator/tensor/indexing_op.cc
But I have problems including it in amalgamation/mxnet-predict0.cc
In file included from jni/predictor.cc:4:
jni/../mxnet_predict-all.cc:38:10: fatal error: 'indexing_op-inl.cuh' file not found
#include <indexing_op-inl.cuh>

Pull master and try again.
On Mon, Feb 20, 2017 at 4:22 PM, Freddy Chua<EMAIL_ADDRESS>wrote:

@piiswrong https://github.com/piiswrong there is not such file
src/operator/embedding.cc
it seems that the embedding code is now in src/operator/tensor/indexing_
op.cc
But I have problems including it in amalgamation/mxnet-predict0.cc
In file included from jni/predictor.cc:4:
jni/../mxnet_predict-all.cc:38:10: fatal error: 'indexing_op-inl.cuh' file not found
#include <indexing_op-inl.cuh>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmlc/mxnet/issues/5076#issuecomment-281211579, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAiudFAHNDVAayF8Ylv8AK-vkPHNxXwOks5rei4wgaJpZM4MGWBV
.

finally worked, thanks

Hi @piiswrong
Thanks for quick response. I checked your update on python file. it works now
Hi @freddycct
Thanks for sharing. Yes. I got same error message like yours when adding indexing_op.cc
Recap solution after @piiswrong 's update.
1, #include "src/operator/tensor/indexing_op.cc" in mxnet_predict0.cc in the folder of amalgamation
2, make clean && make, again.
3, you could find Embedding OP in generated mxnet_predict-all.cc.
Unfortunately, regarding the issue to use prediction CPP API to evaluate model generated by lstm_bucketing.py is still open. Embedding OP could be found now. but still missing other OP.
Error message shows Operator SliceChannel again.
I'll try to add SliceChannel manually, and keep your guys updated.
Thanks !
K.

I got some time to play with it again.
Here are my findings.
for the model of lstm_bucketing.py from rnn. I added
#include "src/operator/tensor/indexing_op.cc" #include "src/operator/slice_channel.cc" #include "src/operator/tensor/init_op.cc"
and prediction API could work with it now.
Thanks for help !
K.


[Enhancements] Missing some font-awesome symbols

Hi there & thanks for the nice plugin!
I've hesistated a bit to submit this minor issue thus it feels a bit infantile: I am missing some font-awesome icons. Espacally cloud-sun, cloud-sun-rain and solar-panel (from the "free" subset).
Is the plugin like "just a version behind", or is it a more complex issue? Could I help myself?
Thanks for the attention & I am running on boom-table v1.0.0 on Grafana v5.4.3.

This plugin doesn't explictly include any font awesome  icons. But leverage the icons which grafana already provides.
Currently grafana is using version of 4.7.0 of font awesome. So there is no sun & rain 🌥  which were introducted in FA 5+
https://github.com/grafana/grafana/commits/master/public/sass/base/_font_awesome.scss

Thanks for explaination! I tried to update some file by hand, but with no success (on a deeper view; who, it really seems more complex than just replacing some font-files). So I opened a kind request on this at Grafana's place.

Closing this issue as this is not something that this plugin can fix.  Leaving it to grafana.


Add ignoreAnnotatedFunctions to TooManyFunctions

Expected Behavior of the rule

Add ignoreAnnotatedFunctions (better name suggestions appreciated) config entry to TooManyFunctions rule that would exclude functions with specific annotations from the function count
Context

We would like to exclude Compose preview functions from this rule. It is generally a good thing to have many Compose previews in file (to cover as many cases as possible), so we usually have several functions with actual UI code, then 10+ @Preview functions that just render preview for above code. We feel like those functions should not count into this rule as they do not contain any logic and do not actually make the file more complex.
I am prepared to offer a PR for that, if accepted.

This is kinda tricky as to be consistent with the rest of the other props, this should be called ignoreAnnotated. The problem is that we do have a suppressor called also ignoreAnnotated.
I feel that this is probably the case for a local suppression?

I wouldn't do it with local suppressions:

It's a common pattern in our codebase, so we would have to manually suppress lots of files, which goes against "manually suppress only for exceptional cases"
Manual suppressions can only be done for the entire file, meaning that we would also loose TooManyFunctionsfor non-Preview functions in that file.

In general I don't like this rules with "magic" thesholds because this kind of things happen.
Could those multiple Previews be reduced by using a PreviewParameterProvider? In my case I usually prefer to use it because otherwise the code inside @Preview functions is kind of repetitive. Would that help?

I guess they could in some cases, but in not in the other. So this is only a half solution.

I stopped by to request the same feature 😂
The TooManyFunctions rule doesn't have an ignoreAnnotated option: https://detekt.dev/docs/rules/complexity/#toomanyfunctions
But jetpack compose composable previews tend to have a lot of state passed into them...at least that's our use case.

Any verdict on this? I'm prepared to start a PR for this.

Probably ignoreAnnotatedFunctions is the preferred way to go to don't clash with ignoreAnnotated from the suppressor then

Shouldn't it use fully qualified names instead?

ignoreAnnotated also doesn't use fqn annotations, so it was made to be consistent with that. Plus fqn requires type resolving.


error 500 on creating legal_entity with type MIS

Original task 446
Only legal_entity with type MSP or Pharmacy could be created by MIS

"message": "Only legal_entity with type MSP or Pharmacy could be created",


ditch IPython _* history variables?

Early on, I made IJulia emulate IPython's history variables: _/__/___ refer to the last three execution results, and _nn refers to Out[nn].
At this point, however, I'm not sure that was a great idea, and I'm inclined to ditch them, keeping only ans for the last execution result (like Matlab and the Julia REPL) and Out[nn] to fetch any output.   _ in particular just seems to be too popular as a variable name to shadow it with a global (see e.g. kmsquire/Match.jl#14).
Thoughts?  @StefanKarpinski, @Carreau, are these underscore history variables important to anyone?

_ is a convention IPython inherited from the vanilla Python REPL (IPython added __ and ___), I'm not sure if anyone uses anything beyond _, even in IPython. If there's a better precedent in the community, I think dropping _* is a good idea.

+1. I was only aware of them from digging around in the iJulia source code, so I wouldn't imagine there are many reliances on them. I think using ans is much more common in the Julia community.

+1 also.
Envoyé de mon iPhone

Le 30 janv. 2015 à 23:09, Jacob Quinn<EMAIL_ADDRESS>a écrit :
+1. I was only aware of them from digging around in the iJulia source code, so I wouldn't imagine there are many reliances on them. I think using ans is much more common in the Julia community.
—
Reply to this email directly or view it on GitHub.

+1 – I never cared for this in the first place. How about also exposing In[n]?

@StefanKarpinski, In and Out are already exposed.

So ends an era.


Publish 8.6-20231227013820+0000

Publish 8.6-20231227013820+0000

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.


spring-loaded doesn't work with JVMCI

Java Virtual Machine Compiler Interface is coming to JDK. It has already been integrated into JDK9 and there are backports to JDK8 as well (download from OTN). However the spring-loaded project doesn't work with the JVMCI builds. Download the JVMCI JDK and try:
 ~/bin/labs1.8.0/bin/java -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -javaagent:springloaded-1.2.6.RELEASE.jar -noverify -version
Bootstrapping JVMCIjava.lang.NoClassDefFoundError: org/springsource/loaded/ri/ReflectiveInterceptor
        at jdk.vm.ci.hotspot.UnsafeAccess.initUnsafe(UnsafeAccess.java:43)
        at jdk.vm.ci.hotspot.UnsafeAccess.<clinit>(UnsafeAccess.java:34)
        at jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.getHolder(HotSpotResolvedJavaMethodImpl.java:87)
        at jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl.fromMetaspace(HotSpotResolvedJavaMethodImpl.java:104)

This pull request fixes the problem by  not creating a TypeRegistry for classloaders that don't see the application class path like JVMCI classloader & co.

I've created this PR a year ago and there hasn't been a single reply! That is partially explainable as I was asking people to download a special JDK - however the situation is different today. As @chrisseaton wrote in his Understanding How Graal Works - the Graal compiler is part of standard JDK9. I hope that might increase your motivation to accept my fix.

To reproduce: get JDK9, my version is:
$ /usr/lib/jvm/java-9-oracle/bin/java --version
java 9.0.1
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

and run any long running computation with springloaded.jar agent and following options: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler. For my own testing purposes I used the Sieve of Eratosthenes, but any other long running application will do.  Last one is 509
Computed 194 primes in 1 ms. Last one is 1181
Computed 388 primes in 2 ms. Last one is 2677
Computed 776 primes in 2 ms. Last one is 5897
Computed 1552 primes in 3 ms. Last one is 13033
Computed 3104 primes in 4 ms. Last one is 28541
Computed 6208 primes in 7 ms. Last one is 61687
Computed 12416 primes in 14 ms. Last one is 133033
Computed 24832 primes in 36 ms. Last one is 284831
Nov 24, 2017 5:13:51 PM org.springsource.loaded.agent.SpringLoadedPreProcessor preProcess
SEVERE: Unexpected problem transforming call sites
java.lang.IllegalArgumentException
        at sl.org.objectweb.asm.ClassReader.<init>(Unknown Source)
        at sl.org.objectweb.asm.ClassReader.<init>(Unknown Source)
        at org.springsource.loaded.MethodInvokerRewriter.rewrite(MethodInvokerRewriter.java:345)
        at org.springsource.loaded.MethodInvokerRewriter.rewrite(MethodInvokerRewriter.java:99)
        at org.springsource.loaded.TypeRegistry.methodCallRewriteUseCacheIfAvailable(TypeRegistry.java:1002)
        at org.springsource.loaded.agent.SpringLoadedPreProcessor.preProcess(SpringLoadedPreProcessor.java:361)
        at org.springsource.loaded.agent.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:107)
        at java.instrument/java.lang.instrument.ClassFileTransformer.transform(ClassFileTransformer.java:246)
        at java.instrument/sun.instrument.TransformerManager.transform(TransformerManager.java:188)
        at java.instrument/sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:550)
        at java.base/java.lang.ClassLoader.defineClass2(Native Method)

with my patch, I can successfully execute the same command and even see that the Graal compiler does its compilations:
$ /usr/lib/jvm/java-9-oracle/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Dgraal.PrintCompilation=true -javaagent:/spring-loaded/springloaded/build/libs/springloaded-1.2.9.BUILD-SNAPSHOT.jar -Xverify:none -jar java/algorithm/target/sieve-algorithm-1.0-SNAPSHOT.jar
134    JVMCI Ljava/lang/StringLatin1;                                               hashCode                                      ([B)I                                              (OSR@10) ...
135    JVMCI Ljava/lang/String;                                                     coder                                         ()B                                                ...
Computed 49664 primes in 104 ms. Last one is 607417
135    JVMCI                                                                                |  334ms    15B    63B 10171kB
468    JVMCI Lorg/apidesign/demo/sieve/eratosthenes/Filter;                         acceptAndAdd                                  (I)Z                                               ...
134    JVMCI                                                                                |  345ms    42B   314B  9823kB
419    JVMCI Ljdk/internal/jimage/ImageStringsReader;                               unmaskedHashCode                              (Ljava/lang/String;I)I

Does it make sense to integrate my bugfix now?

Just before I do, have you signed the CLA?  https://cla.pivotal.io/sign/pivotal/icla

Hello Andy, I've just signed the CLA with my apidesign.org address. I hope my PR is now in acceptable state to be merged.

Thanks for confirming, and contributing!


在命令行用code命令启动,插件无法初始化

在命令行输入code .打开vscode,项目无法格式化以及其他正常步骤

感谢您创建此问题！
然而，由于您没有使用英语，我们很难进行处理。如果可能，请您将此问题描述修改为英文。请您直接编辑此问题，不要提交回复或新问题。
请注意，机器翻译服务通常无法处理用于讨论软件问题所需的技术性语言，所以我们推荐您寻找一位熟悉相关技术的人来协助翻译。
如果您无法做到，没有关系。此问题已经被标记为需要翻译，等待社区成员志愿进行翻译。

Thanks for creating this issue!
Unfortunately, as the description is not in English, it's hard for us to work on. If possible, please edit the original issue to be in English.
In our experience, automatic translation services are not able to handle the technical language needed to effectively communicate about software issues, so we recommend finding a human translator who is familiar with our technology to help.
Otherwise, we have marked this as needing translation and a community member may be able to help out.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Add E-Commerce Website Design, Relavant Files, Update in Repository

Title: Phoenix
About:  Add E-Commerce Website Design, Relavant Files, Update in Repository
Name: SarthakSKumar
Label: Feature Request

Is your feature request related to a problem? Please describe.
Add E-Commerce Website Design, Relavant Files, Update in Repository

Additional notes

N/A

Please assign @adithya-s-k


Vertical jquery-flipster

Hello, is possible display in vertical?
we need display the carousel in vertical.
Thanks :)

Currently Flipster is very much set up to be horizontal only (translateX, margin-right, left and right keyboard shortcuts, etc).
Visually, you could fake it. My first inkling was to use just rotate everything, but that will interfere with the center method.
.flipster { transform: rotate(-90deg); }
.flipster__item__content > * { transform: rotate(90deg); }

But by using .flipster__item { position: absolute; }, the center method doesn't really do anything, so you can fake the movements. Here's a basic example: http://codepen.io/shshaw/pen/wKYwMj?editors=010
You'll need to add your own flavor to it, and of course none of the keyboard events or touch events will match, but that's the only option at the moment :-)

ok, Good :)
but the button top don´t appear.

Yeah, looks like you may need to play with the padding values to get it all lined up right. Since this isn't an officially supported featured, and so much will vary with your implementation I'll leave the exact values up to you.
If you need further help, just ask!


 I've only skimmed over it so far but this is great!
Is a fromPromise operator coming? :smiley:

Any thoughts on using __invoke instead of call on single method classes?

Working on fromPromise right now.  Needed to get AsyncSubject out of the way first.

@cboden I just don't like the look of __invoke - it seems magical. In this case, it does seem to make a lot of sense being that the whole point of the Operator is to be invocable.

@Ocramius You'd like it, reactive-ready, functional, and (in theory) immutable. :-)

Any thoughts on using __invoke instead of call on single method classes?

YESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYES!

@cboden I'm aware of reactive patterns, just not the naming and implementation details, so my understanding of the codebase is really low right now ;-)

@cboden I just don't like the look of __invoke - it seems magical. In this case, it does seem to make a lot of sense being that the whole point of the Operator is to be invocable.

We should have a chat about that: __invoke allows you to have an implicit interface (callable), and therefore make all these classes final directly. Overall been implementing it heavily, and it simplifies code by a lot ;-)

@Ocramius I'm glad we were able to __invoke such enthusiasm

@davidwdan :sob:

@Ocramius I did add a commit changing to __invoke and it does make it conceptually a lot cleaner. https://github.com/davidwdan/Rx.PHP/commit/eab510583dfc28b52e9dfcd658ed7f52bea88bb9

@mbonneau awesome! Sorry for not noticing, was just replying to previous comments :-)

@davidwdan @cboden @mbonneau @Ocramius This PR is too big for me to review all at once, so I'll do it in chunks. At an overall quick glance it looks great though!

@davidwdan @cboden @mbonneau @Ocramius I reviewed most of the code, except for the tests. I'm happy to help out on the work to fix the comments. To make sure we don't work on the same stuff, can you comment here if you start fixing something?

I'm going to work on the scan and reduce operators

Working on ScheduledObserver

We still need tests for ScheduledObserver.

@asm89 would it make sense to merge this and then open issues for anything that is remaining? it is getting a little difficult to track.

@mbonneau Yes, that's a good idea. I'll look into merging it later today.
Would you folks be ok if I:

rebase this branch
clean up history a bit
open a new PR for a last +1 from you
ship it

@asm89 - that sounds good - I am going to hold up for now on any more work

:+1:

@asm89, do you have an ETA on merging this PR?  I've got some cleanup and operators I'd like to get started on.

@asm89 ping

I was on PTO/completely off the grid last weeks. Sorry for not giving heads up. Will pick this up again.

Pushed to master! Thanks all for the awesome work in this PR. It's really taking the project to the next level. :+1:


recreated session after some fault

recreated session after some fault #3183

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

Codecov Report
Base: 55.69% // Head: 55.69% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (d867a7c) compared to base (cd981ef).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3190   +/-   ##
=======================================
  Coverage   55.69%   55.69%
=======================================
  Files         142      142
  Lines       33016    33023    +7
=======================================
+ Hits        18388    18393    +5
- Misses      12687    12690    +3
+ Partials     1941     1940    -1

Impacted Files
Coverage Δ

pkg/meta/sql.go
58.73% <0.00%> (-0.08%)
:arrow_down:

pkg/vfs/handle.go
83.58% <0.00%> (-0.75%)
:arrow_down:

pkg/chunk/cached_store.go
72.91% <0.00%> (+0.13%)
:arrow_up:

pkg/chunk/disk_cache.go
73.07% <0.00%> (+0.46%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


rbd: implments getVolumeReplicationInfo

This commit implements getVolumeReplicationInfo
to get the last sync time and update it in volume
replication CR.
Signed-off-by: yati1998<EMAIL_ADDRESS>

/retest ci/centos/mini-e2e/k8s-1.24

addressed all the comments, can you please add your final reviews @nixpanic @Rakshith-R @ShyamsundarR @Madhu-1

This PR can be rebased with Mergifyio and have the ci/retry/e2e label added once #3380 is merged.

/retest ci/centos/mini-e2e/k8s-1.23

/retest ci/centos/mini-e2e/k8s-1.24

/retest ci/centos/mini-e2e-helm/k8s-1.22

/retest ci/centos/mini-e2e-helm/k8s-1.24

/retest ci/centos/upgrade-tests-rbd

/retest ci/centos/k8s-e2e-external-storage/1.22

/retest ci/centos/mini-e2e/k8s-1.23

@yati1998, even though its a new RPC planning to backport this to 3.7?

@yati1998, even though its a new RPC planning to backport this to 3.7?

IMO we can have it in next release, maybe minor. But if you guys think to backport it, I can send a PR.

@yati1998, even though its a new RPC planning to backport this to 3.7?

IMO we can have it in next release, maybe minor. But if you guys think to backport it, I can send a PR.

/retest all

@mergifyio refresh