Add flexible support for other LLM providers

First of all, many thanks for sharing this project! It's a much better execution of an idea we (University of Groningen, Center for Information Technology) had floating internally. We are currently serving models through vLLM for our research staff and this would be a great tool for them to start designing their on-premise LLM powered workflows. Unfortunately, vLLM configuration options like the API base URL and the API key can't be set through environment variables so an approach similar to the Ollama example would not work for adding vLLM as a provider.
Proposed solution
I would be happy to contribute to a more flexible way of adding LLM providers, particularly for vLLM, but also considering the future addition of other providers. Since the project already uses LiteLLM, I had a few thoughts:

Generalize the configuration options
It would be helpful to do a scan over all the keywords used in in the LiteLLM completion calls per provider (so not just vLLM) and add them as configuration options similar to default_model on the pipeline level and model on the step level.

Use OpenAI client with configurable options
Instead of having multiple call_llm operations spread across the project, it might make sense to use the OpenAI client with configurable parameters for the base URL and API key. For users who wish to use a non-OpenAI provider (e.g., vLLM), we could suggest using a LiteLLM proxy setup, allowing for easier switching between providers without code modifications.

Next steps

Does this proposal align with the direction of the project?
Are there any specific constraints or guidelines I should keep in mind while implementing this?
I could start by outlining how these configurations can be generalized and submit a proof of concept PR.

I'd be happy to discuss further and adjust based on any feedback. Thanks again for the great work on this project!
Best regards,
Michiel van der Ree
University of Groningen, Center for Information Technology

This support can also be extended to include open source models like llama, gemma or phi maybe.

Hi @michielree, thanks for the interest! I agree, it would be nice to be interoperable with vLLM. Your proposal definitely aligns with the project direction.
I am not super attached to the liteLLM integration, but I think that wrapping all the LLM providers is a bigger engineering effort right now. People as of now have been using openai, ollama, and gemini. Maybe we can detect (via the user-defined config) if the user wants to point to a liteLLM proxy, and we can use the openai client for those model calls? As demonstrated in the litellm docs: https://docs.litellm.ai/docs/providers/vllm
Open to other design ideas though; feel free to comment any ideas or submit a proof of concept PR. Thank you for taking this on 🙏🏽

Hi @shreyashankar, thanks for your reply. I agree facilitating user to optionally access models through a liteLLM proxy would be easiest to implement now and most flexible in the long run. Advantages are that it decouples the API key management per provider from DocETL, and allows pipelines with steps that use multiple OpenAI compatible providers (e.g. OpenAI and vLLM). Currently, we would need to commit to one of those because we would have to define the api_base used by litellm.completion via an environment variable. I'll work on a PR and circle back! Feel free share any comments in the meantime.

Work in progress here for those interested: https://github.com/michielree/docetl/tree/feature/streamline-litellm-proxy

awesome thank you!! let me know if any issues come up.

@shreyashankar it took me a while to realize that my use case can be covered by simply using this litellm provider (i..e using the litellm_proxy/ prefix and the environment variables mentioned in linked docs), closing this issue for now.

Ah, that's great! If you have the time to write a short markdown doc on how you set it up (so we can add it to the examples in our documentation), that would be amazing 🙏🏽

Using the litellm_proxy method to call services started by vllm will result in incompatible request parameters, see details: https://github.com/BerriAI/litellm/issues/4769

@Tendo33 are you using the new vllm_hosted litellm provider in your litellm config? That seems to be working for me.

@shreyashankar Yes happy to provide an example! Although it might take me a while until I have the bandwidth, will circle back.

@Tendo33 are you using the new vllm_hosted litellm provider in your litellm config? That seems to be working for me.@Tendo33您是否在 litellm 配置中使用了新的vllm_hostedlitellm 提供程序？这似乎对我有效。

The default_model in pipline.yaml, I'm usinghosted_vllm/xxxx, but I feel like I need to set the vllm api_base environment variable in the .env file, though I haven't found it yet.

@shreyashankar Yes happy to provide an example! Although it might take me a while until I have the bandwidth, will circle back.

Finally🤣, I found all the issues you mentioned in litellm. I think it's time to update the litellm version.

Ah--will update the litellm version; thank you!!


Changed html element back to 'body' from Spanish

Change CSS rules back to English as well.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@devbysalas Thanks for catching this.


fix(operator): update type definitions for union types

allow multiple type parameters can be accepted for observable,
operator supports array of union types

closes #581
This PR replaces array of union type declaration more explicit way by language spec (https://github.com/Microsoft/TypeScript/issues/805), get rid of type inference error by typescript compiler when multiple type of parameters are actually provided.

:+1:

Merged with 9d90c75... thanks @kwonoj


Allow developers to configure the epoch of the snowflake ID generator

To make things easier with better performance, we use a constant epoch.


use_technical_indicator= False has keyError for environment setup step

When I do not want to use the technical indicator and set it to false, I cannot set up the correct environment because e_train_gym = StockTradingEnv(df = train, **env_kwargs) this will return KeyError: 'macd'

technical_indicator_list is imported from config.py.
If use_technical_indicator== False，technical_indicator_list should be an empty list.


Need to fix the problem with outdated scipy method

Need to replace scipy method with numpy to fix this error on import:
"ImportError: cannot import name 'triu' from 'scipy.linalg'"

Problem appears with the import of flair in geododer module

ohh... scipy.linalg again... I remember we fixed one in that scipy.linalg subpackage. Turns out it was some numpy issue as I remember(


WIP: Flatten default initializer dictionaries

This PR has (or should have) no functional changes. All it does is reorganize the default initializer dictionaries for our AgentTypes so that all parameters for that class are present and explained in one place. All parameter values remain the same, and the dictionaries themselves should be exactly identical as before.
This branch builds from #1410 under the assumption that it will be merged in relatively soon.

[ ] Update CHANGELOG.md with major/minor changes.

So I said it wouldn't change any dictionaries, but then I found an extraneous CubicBool=True and removed it. Test values changed by 0.0001 to 0.001.

This branch is ready for review and merge. It extends #1410 , so that should be merged first.
There are very few functional changes, mostly just "flattening" of dictionaries so that each AgentType subclass is better documented in the file in which it appears. A few tests and examples had to have their formatting changed slightly to account for dictionary differences. Only one test had a value change, and that was due to removing a (likely mistaken) CubicBool=True in an example dictionary.
The tests that changed will be easier to see when #1410 is merged into master.

I'll review this once #1410 is in. As is, it's hard to isolate the changes specific to this PR


Please add py.typed marker

Using fastapi-health, mypy reports "module is installed but missing library stubs or py.typed marker".
As fastapi is nicely typed, you can easily add a py.typed marker. It's enough to add an empty file called py.typed in the fastapi_health package directory, and to include it in the distribution.
I would provide a MR, but I have no idea how to do include the file in a project using pyproject.toml file. If there was a setup.cfg file, it would be enough to add a stanza such as:
[options.package_data]
fastapi_health = py.typed

I need to add a "contribution guidelines", but just including the file py.typed, and hatch build.


Downloads files from a large torrent that I didn't choose

When I import a large torrent (a whole season from series) and quickly deselect the files that I don't need to be downloaded, WTD ignores my selection and keeps downloading the whole torrent.
For example, I need only 1 file out of 10. I import the torrent. Deselect 9 files. But WTD keeps downloading them like nothing happened.

Duplicate of https://github.com/feross/webtorrent-desktop/issues/719


Tilt Bluetooth failing to open socket

TL;DR I think you need to install libbluetooth-dev before compiling Python 3.7.7 for a fresh install.
OS: Stretch
Fermentrack Branch: dev (Commit Date: | May 19, 2020, 10:07 a.m.)
Just did a fresh install of fermentrack last night/this morning. Had no errors so started configuring everything and noticed it's not detecting my TILT.
Checked the logs and it's just a whole bunch of this stack trace.
/home/fermentrack/fermentrack/log/tilt--stderr.log
Traceback (most recent call last):
  File "/home/fermentrack/fermentrack/gravity/tilt/tilt_monitor_aio.py", line 155, in <module>
    mysocket = aiobs.create_bt_socket(mydev)
  File "/home/fermentrack/venv/lib/python3.7/site-packages/aioblescan/aioblescan.py", line 1280, in create_bt_socket
    sock = socket.socket(family=socket.AF_BLUETOOTH,
AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'
Sentry is attempting to send 0 pending error messages
Waiting up to 2 seconds
Press Ctrl-C to quit

Looking at the Python source, it looks like it needs some bluetooth defines
Modules\sockemodule.c
...
451: #if (defined(HAVE_BLUETOOTH_H) || defined(HAVE_BLUETOOTH_BLUETOOTH_H)) && !defined(__NetBSD__) && !defined(__DragonFly__)
452: #define USE_BLUETOOTH 1
...
7020: #ifdef USE_BLUETOOTH
7021:     PyModule_AddIntMacro(m, AF_BLUETOOTH);
...

Seems like HAVE_BLUETOOTH_* defines can be set multiple ways, but having libbluetooth-dev installed apparently can do it, but your script installs after python is compiled. I double checked that libbluetooth-dev is installed and ran  fermentrack-tools/fix-environment.sh forcing Python to re-compile and it's now fine. Tilt is connecting.
So yeah, will leave it to you to decide, but you just need to install libbluetooth-dev before compiling Python 3.7.7 for a fresh install.
Also, a few minor things

If I go to /gravity/tilt/test/ it says python3-dev is Not Installed, which I believe is expected now that you're compiling it manually.
How do I rename by Fermenter? I tried changing it in /devices/1/manage/ but I can't get it to stick. I'm using an Arduino Uno if that effects anything.
Thanks for your work on this project. Been manually maintaining my own BrewPi legacy fork and it's been showing its age haha.

Hey there -- sorry for the delay in addressing this! You raised a couple of points, so I'll address them separately:

I think the installer now installs libbluetooth-dev prior to Python 3.7 in both fix-environment.sh and install.sh for both new and existing installs.

Thanks for the heads up about python3-dev - I'll get that pulled out shortly

I'll need to take a look at fermenter renaming. It should work just fine, but there's always the chance I missed something somewhere. I'll track this separately as #522


Angular template - VS2017 npm install fails due to package.json being in the clientapp folder

When I build or manually try to restore npm dependencies through the UI in Visual Studio 2017 (15.7.5) using the Angular template in .net 2.1 it's failing to do so.
It gives the npm WARN ENOENT ENOENT: no such file or directory, error and seems to be looking in the project root folder for package.json. That's a problem since the template creates the package.json folder in the ClientApp folder instead of root.
Is this intentional for the template to place it there even though it seems to break VS's ability to install packages through the UI?
Even on build it's failing (which is odd since there's some voodoo in the csproj that tells it to look in sparoot, which should be the clientapp folder).
Thanks for any help with this.

Thanks for contacting us, @tizubythefizo.
@ryanbrandenburg can you please look into this? Thanks!

This seems to be a VS bug to me. When you right click a package.json and select Restore Packages VS should know what folder that file is in and execute the NPM script there. There is no way (that I know of) for the templates to "tell" VS where to look. I recommend using the comment button on the top right of your VS window to report this behavior.
The "voodoo" you refered to worked for me, but it has two conditions.

You must be building Debug (The idea here is that when you build something in release you should be using a specific package-lock.json to ensure you get the dependable version).
node_modules must not already exist (npm install takes a while, so we don't want to waste a ton of time always re-installing).

If you meet both those requirements and still can't get it to restore I'll need some more information about exactly how you're trying to build, the the result your getting when you do (I assume it's different from the one you listed above).

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.


Add support for multiple floors

The user should be able to see

which floor he is on
which floor his POI is on
whether or not he needs to change floors to reach his POI

This information could either be determined after scanning a marker or from the user's location sensors.

Once this is finished, the list of POI's the user chooses from could be sorted by the floor (or even location) he is currently in. It might be more interesting to see important rooms on the user's current floor than seeing a room the floors below the user just because its name  starts with an 'A'.


Implement a LateInitializer struct for use by providers

Description of your changes
LateInitializer will help providers figure out whether a change has been made and spec update is needed after the late initialization without using DeepCopy of the original and changed objects.
I wanted to include only the bare minimum I need for generated ACK resources where the source and target field types are the same to be conservative about what we expose. We can add more as needed.
Example usage:
func lateInitialize(cr *svcapitypes.Table, resp *svcsdk.DescribeTableOutput) bool {
  li := awsclients.NewLateInitializer()
  cr.Spec.ForProvider.Property = li.LateInitializeStringPtr(cr.Spec.ForProvider.Property, resp.Table.Property)
  // .. many calls using the same li object ...
  return li.IsChanged()
}

I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Unit tests.

@hasheddan sounds good. I started with having a lot of LateInitialize* functions and then reduced to these few, thinking providers could extend it if they want non-conventional late initialize functions but missed the fact that they can't access changed field. Thanks!


Key hash policy on version, rather than package

Summary
First part of: https://github.com/astral-sh/uv/issues/5168.

Dangit, I realized this isn't strictly necessary...

I'll probably keep parts of this but roll back the use of versions as keys.

Actually, I think this is a good change.


Resizing notebooks locks up the UI thread

Testing #177719

This seems to go away when doing a perf/cpu profile, it might do something with process priority that fixes the problem? Regardless, in all profiles I see some 15-20ms frames on my fast CPU (12th Gen Intel(R) Core(TM) i7-12700KF 3.61 GHz) which will be much worse on the average machine.

I can reproduce, it's much smoother while profiling but still we have tons of frames running more than 50ms


blinky_timer_irq example broken ?

examples/blinky_timer_irq.rs doesn't work for me. I know how to fix it, but I don't understand why my fix works.
My test repo:
https://github.com/timbod7/stm32f1xx-hal-testing
demonstrates the problem using a blue pill board.
The first commit has src/main.rs as example/blinky.rs. It works as expected.
The second commit replace src/main.rs  with example//blinky_timer_irq.rs.rs. This doesn't work. If I look at PC13 with an oscilloscope I can see that it pulses low for only 10us.
The third commit reorders the actions in the interrupt handler, and fixes the issue, with the LED flashing with a 2 second period as expected.
Any suggestions as to what is going on here?

Could be this issue - https://developer.arm.com/documentation/ka003795/latest
Interrupt may be happening twice because "interrupt clear" signal doesn't "get through" before interrupt handling routine returns.
When I debugged a similar issue, it was extremely strange - e.g. it started working if asm::nop() is called somewhere in the handler, presumably because interrupt routine became more complex and had to store extra registers on stack, and extra RAM access ensured that interrupt had cleared. Adding a bunch of nops that did not affect memory after interrupt clear also did help, and so on.
The document above suggests one of the solutions, and it's exactly what you did - clear interrupt first, and then toggle the LED.
The question is, should HAL try to mitigate this in clear_update_interrupt_flag() and similar functions...

@vitalyvb Thanks for the reply. That does sound like a potential cause. It does seem to depend on the build setup somehow.
Whilst example/blinky_timer_irq.rs works in the the original source repo when I run it as:
cd stm32f1xx-hal
cargo run --example blinky_timer_irq --features stm32f103,rt

yet the identical code fails as described above when run in the test repo


IN-722 Get or create 004 test project

Now has extra script which finds an existing 004 test project for the config file which has been updated or creates a new one
Uploads the updated config file to that 004 project (instead of a static 003 proj)
Updated get_production_config.py to handle dias batch configs rather than conductor configs for this first version (so added an example TWE config and removed the example conductor config)
Creates nicer diff report which is wider with 3 lines of context

This change is

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

In the file get_or_create_testing_project.py:

Line 100:28: W605 invalid escape sequence '\d'
Line 100:35: W605 invalid escape sequence '\d'
Line 100:42: W605 invalid escape sequence '\d'
Line 111:9: E122 continuation line missing indentation or outdented
Line 153:21: E251 unexpected spaces around keyword / parameter equals
Line 153:23: E251 unexpected spaces around keyword / parameter equals
Line 154:24: E251 unexpected spaces around keyword / parameter equals
Line 154:26: E251 unexpected spaces around keyword / parameter equals
Line 184:80: E501 line too long (122 > 79 characters)
Line 212:1: E302 expected 2 blank lines, found 1
Line 222:1: E305 expected 2 blank lines after class or function definition, found 1

In the file get_production_config.py:

Line 169:80: E501 line too long (80 > 79 characters)


Update ExtractCenterline.cpp

corrected heuristic for tip point selection; the L2, i.e., Euclidian distance to the image center should be taken into account not the minimal distance in x or y direction (which might be very small even if the point is close to the border)

Thanks for the help! That is not clear in the code, but the L2 distance to the center was commented and not used because in the paper we used the heuristic taking as a tip the endpoint the farthest from the border (see section 2.4 Centerline extraction). So the code is just sticking to the paper.
You're however free to use any heuristic you think it will better fit your data.
I'm gonna add a #ifdef part to be more clear in the code.
Also you changed '<' to '>=' so I guess you last point is the tip? In my case the first point was the tip. So here as well, it depends how do you use the output centerline of this function.
Tell me if I missed something?


Add more unit test case

/kind improvement

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (2750b22) 74.64% compared to head (1498e0c) 76.56%.

:exclamation: Current head 1498e0c differs from pull request most recent head d671e8d. Consider uploading reports for the commit d671e8d to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #40      +/-   ##
==========================================
+ Coverage   74.64%   76.56%   +1.91%
==========================================
  Files          39       39
  Lines        4852     4852
==========================================
+ Hits         3622     3715      +93
+ Misses       1043      957      -86
+ Partials      187      180       -7

see 9 files with indirect coverage changes


App crashed by typing address in the address field when composing a message

Expected behaviour
Creating new email or answer to an email. Normaly I can look for my contacts by typing the letter one by one to find the desierd contact
Actual behaviour
in 5.108 K9 is crashing every time I am typing the 2nd letter. Let´s assume i am looking for a contact namend "Claus"
I type "c" than I type "l" and K9 is crashing
If the name is "Hugo"
I type "h" than I type "u" and K9 is crashing.
To overcome this problem I have uninstalled 5.108 and reinstalled it but no change.
Went back to 5.107 and it is working.
Steps to reproduce

Environment
K-9 Mail version: 5.108
Android version: 4.4.4
Account type (IMAP, POP3, WebDAV/Exchange):
IMAP (web.de and gmail)

What keyboard are you using? Were you given the option of sending a crash report?

I am using the Swype Keyboard
And I had no chance to send a crash report

Hi
I am using the Swype Keyboard.
I had no chance to send a crash report.
K9 was not closing completely just closes the new e-mail and than I was back in the inbox or the folder I was starting from
Best regards
Claus
Am 3. April 2016 16:18:08 MESZ, schrieb Philip<EMAIL_ADDRESS>
What keyboard are you using? Were you given the option of sending a
crash report?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/k9mail/k-9/issues/1253#issuecomment-204984541

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Hmm. Can you try enabling debug logging in the preferences and then provide the contents of any new "e-mail" created in the K9mail-errors folder after trying again?
I downloaded the trial Swype keyboard and it seems to work fine on my device (but it's a later OS and different device).

Ok, I will give it a try
I can also use a different keyboard just to see.
Best regards
Claus
Am 3. April 2016 19:30:50 MESZ, schrieb Philip<EMAIL_ADDRESS>
Hmm. Can you try enabling debug logging in the preferences and then
provide the contents of any new "e-mail" created in the K9mail-errors
folder after trying again?
I downloaded the trial Swype keyboard and it seems to work fine on my
device (but it's a later OS and different device).

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/k9mail/k-9/issues/1253#issuecomment-205018262

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Hi,
I have now updated - again to 5.108.
Guess what?
No crash when typing a contact.
Problem is that the contacts are now in a inverted type and the bar is white
and the letter are grey (not black), so it is not easy to read
But now I cannot send emails at all.
I have now a number of error meassages in the k9 error folder but how can I
get those over to you?
Best regards,
Claus
Am 03.04.2016 um 19:30 schrieb Philip<EMAIL_ADDRESS>Hmm. Can you try enabling debug logging in the preferences and then provide
the contents of any new "e-mail" created in the K9mail-errors folder after
trying again?
I downloaded the trial Swype keyboard and it seems to work fine on my device
(but it's a later OS and different device).
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

Either paste them here / a GitHub gist / http://pastie.org/

copied 2 error messages
K9-Mail version: 5.108
Device make: samsung
Device model: SM-N910F
Android version: 4.4.4
java.lang.Exception: Message count 0 for folder Entwürfe
at
com.fsck.k9.controller.MessagingController.synchronizeMailboxSynchronous(MessagingController.java:931)
at
com.fsck.k9.controller.MessagingController.access$300(MessagingController.java:99)
at
com.fsck.k9.controller.MessagingController$8.run(MessagingController.java:754)
at
com.fsck.k9.controller.MessagingController.run(MessagingController.java:257)
at java.lang.Thread.run(Thread.java:841)
K9-Mail version: 5.108
Device make: samsung
Device model: SM-N910F
Android version: 4.4.4
javax.net.ssl.SSLException: Read error: ssl=0x7aeb5db0: I/O error during
system call, Connection timed out
at com.android.org.conscrypt.NativeCrypto.SSL_read(Native Method)
at
com.android.org.conscrypt.OpenSSLSocketImpl$SSLInputStream.read(OpenSSLSocketImpl.java:746)
at java.io.InputStream.read(InputStream.java:162)
at java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:142)
at java.io.BufferedInputStream.read(BufferedInputStream.java:227)
at
com.fsck.k9.mail.filter.PeekableInputStream.peek(PeekableInputStream.java:34)
at
com.fsck.k9.mail.store.imap.ImapResponseParser.readResponse(ImapResponseParser.java:38)
at
com.fsck.k9.mail.store.imap.ImapResponseParser.readResponse(ImapResponseParser.java:30)
at
com.fsck.k9.mail.store.imap.ImapResponseParser.readStatusResponse(ImapResponseParser.java:88)
at
com.fsck.k9.mail.store.imap.ImapConnection.readStatusResponse(ImapConnection.java:626)
at
com.fsck.k9.mail.store.imap.ImapFolderPusher$PushRunnable.sendIdle(ImapFolderPusher.java:294)
at
com.fsck.k9.mail.store.imap.ImapFolderPusher$PushRunnable.run(ImapFolderPusher.java:187)
at java.lang.Thread.run(Thread.java:841)
Am 03.04.2016 um 19:30 schrieb Philip<EMAIL_ADDRESS>Hmm. Can you try enabling debug logging in the preferences and then provide
the contents of any new "e-mail" created in the K9mail-errors folder after
trying again?
I downloaded the trial Swype keyboard and it seems to work fine on my device
(but it's a later OS and different device).
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

Ok neither of those are related. Looks like we aren't going to get a stacktrace for this.
I might try and see if I can reproduce it on an emulator...

Related to what?
to the not sending problem?
or
to the crash while typing the 2nd letter of a contact?
Is there anything I can do further?
If not I would switch back to 5.107
Best regards,
Claus
Am 03.04.2016 um 20:23 schrieb Philip<EMAIL_ADDRESS>Ok neither of those are related. Looks like we aren't going to get a
stacktrace for this.
I might try and see if I can reproduce it on an emulator...
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

by the way:
I can receive the email you are sending with my Note
Am 03.04.2016 um 20:23 schrieb Philip<EMAIL_ADDRESS>Ok neither of those are related. Looks like we aren't going to get a
stacktrace for this.
I might try and see if I can reproduce it on an emulator...
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

To either - the first is #1174 , the second is a simple network error while trying to connect for push e-mail.

ok,
could I do something against the simple network error?   ;-)
It came after updating from 5.107 to 5.108
Am 03.04.2016 um 20:27 schrieb Philip<EMAIL_ADDRESS>To either - the first is #1174 , the second is a simple network error while
trying to connect for push e-mail.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

The network error just says the connection timed out. Can you create a separate issue for this - assuming you can get the e-mail on another device. I'm going to close this one as we have two open ( #1251 ) for the same thing

I have the same error. When typing a second character in the recipient field, I get "K-9 Mail" was closed with no option to send crash log.
K-9 Mail 5.108 on Android 6.0.1 on Moto X Style.

See #1251 wweich


Call to function "cidrhost" failed: invalid CIDR expression: invalid CIDR address: /0.

Following the README step for step, I get this error:
╷
│ Error: Error in function call
│
│   on main.tf line 141, in data "template_file" "deploy_anthos_cluster":
│  141:     ingress_vip      = cidrhost(metal_reserved_ip_block.ingress_vip.cidr_notation, 0)
│     ├────────────────
│     │ metal_reserved_ip_block.ingress_vip.cidr_notation is "/0"
│
│ Call to function "cidrhost" failed: invalid CIDR expression: invalid CIDR address: /0.
╵
╷
│ Error: Error in function call
│
│   on output.tf line 22, in output "Ingress_VIP":
│   22:   value       = cidrhost(metal_reserved_ip_block.ingress_vip.cidr_notation, 0)
│     ├────────────────
│     │ metal_reserved_ip_block.ingress_vip.cidr_notation is "/0"
│
│ Call to function "cidrhost" failed: invalid CIDR expression: invalid CIDR address: /0.

@di has your IP Reservation been approved? I'm wondering if there is a bug in handling IP reservations that have not yet been approved.

Hi @displague, I'm not sure! How do I determine that?

In the Equinix Metal Portal UI, click IPs & Networks and then IP Requests:

The status should say "Approved".

If the request was not automatically approved, you may need to terraform apply (which triggers a terraform refresh and terraform plan) again, and Terraform will see that the reservation is ready for use.
This assumes there is a problem with how these addresses are handled in the Terraform provider, which may not be the case.
It may be more helpful to run terraform state show metal_reserved_ip_block.ingress_vip and look for a valid cidr_notation value (a.b.c.d/32).

Looks like this is indeed the case:

And after a refresh:
$ terraform state show metal_reserved_ip_block.cp_vip
# metal_reserved_ip_block.cp_vip:
resource "metal_reserved_ip_block" "cp_vip" {
    address_family = 4
    cidr           = 0
    cidr_notation  = "/0"
    description    = "Cluster: 'anthos-metal-1-fthpu' Contol Plane VIP"
    facility       = "dc13"
    global         = false
    id             = "2cc10c1a-e75d-44ef-88a0-38ccb8a0542c"
    manageable     = true
    management     = false
    project_id     = "..."
    public         = true
    quantity       = 0
    type           = "public_ipv4"
}

Don’t feel bad. There shouldn’t be human’s in the loop. You’re probably caught up in the anti-fraud system…

@di this is something that the Terraform provider should take into consideration, perhaps optionally.
A module can't function with a cidr_notation value of /0.  Terraform resources are generally expected to return when the resource is ready to use.
I think the Terraform provider should adopt a behavior of waiting for themetal_reserved_ip_block to have a state of created before releasing the resource.  In some cases, a user may be ok with this resource being released early, so a behavior flag could be used to toggle that.

To close the loop here: once the request was approved, running terraform apply --auto-approve again worked.
I'll close this in favor of https://github.com/equinix/terraform-provider-metal/issues/135 which seems to describe the actual bug better.
Thanks @c0dyhi11 and @displague!


Use pipelineRun unique identifier within a task

Hi, I'm creating a pipeline where I build and push a container image. To ensure that if in the case of two instances of the pipeline being run in parallel, I then access the correctly tagged container image in a subsequent task in the pipeline, I'd like to ensure the container image is given a unique tag.
I was hoping I could somehow obtain the pipelineRun unique identifier and use this as a parameter in the pipeline (as asking the user to enter a "unique" value could still lead to duplication. Likewise generating a random value in one instance of the pipelineRun doesn't truly ensure it's unique.
Is this possible? Or is there a "usual process" to achieve what I'm describing? Thanks.

There's a variable available in pipelines: context.pipelineRun.uid
More info here: https://github.com/tektoncd/pipeline/blob/master/docs/variables.md#variables-available-in-a-pipeline
/kind question

Amazing, thanks @sbwsg I hadn't spotted that page earlier when hunting around the docs. Much appreciated.


Add bash run.sh script for Mac and Linux.

Just a thought, the existence of the python3 command is not necessarily evidence of python >= 3.4. I might opt for just running python3, or python in that order of preference, and then checking version in menu.py.

Agreed. Let's do it that way.

How's that?

Ah, now it lost the check for python3 I think.

I merged this in #6.


Adds Tessen Library

Description
Adds Tessen to the project so that we can start sending additional analytics to New Relic.
Reviewer Notes
There are were couple of hurdles to getting Tessen added to the site:

Due to this project being open source, we could not rely on internal registries for npm install
The library does not seem to play well with webpack, so import was not working
The library relies on window and document, but I was unable to get it to work in any of the gatsby- files

It turns out that gatsby provides a static folder for these edge cases that can be referenced using withPrefix. This adds it to the page header and doesn't throw any errors.
Related Issue(s) / Ticket(s)

Closes #472 (issue to add Tessen)
#394 (previous issue to add Tessen for GTM)

Screenshot(s)

Out of curiosity, does this library set a global variable on window? If so, should we consider adding an externals mapping to webpack to allow us to "import" tessen? This might be nicer and feel more consistent than trying to use window.Tessen everywhere.


How to test with nodejs_compat workers?

Let's say you had a worker that looks like so:
import { init, wrapper } from 'third-party-lib';

init();

/**
 * @type {import('@cloudflare/workers-types').ExportedHandler}
 */
export default {
  async fetch(_request, _env, _ctx) {
    return wrapper(() => {
      return new Response('Hello World!');
    });
  },
};

where third-party-lib uses Node API's under the hood (so nodejs_compat: true - specifically it uses AsyncLocalStorage, so using nodejs_als would be more accurate but that doesn't seem to work at all with NodeJsCompatModule).
How do you set up Miniflare to test this? Everything is also ESM.
I get the following error:
stderr | test/index.test.ts > index > simple test
workerd/util/symbolizer.c++:96: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
*** Fatal uncaught kj::Exception: kj/async-io-unix.c++:945: failed: ::bind(sockfd, &addr.generic, addrlen): Address already in use; toString() = <IP_ADDRESS>:8787
stack: 1054ac4b7 1054ac24f 102e82813 102e8302f 102e837ef 102e83ea7 102e2ccdb 102e2c8f7 1054d73ef 1054d78ab 1054d6027 1054d5dbf 102e1c1b7 1985420df

when using a single module that has type: NodeJsCompatModule and a path to the ESM worker script

It looks like the error you're seeing is an Address in use error (i.e. something else is already running on port 8787). Could you share a reproduction to help us debug further?


Implement multiple parametrization for Negative Binomial

As discussed in #69, we need to be more flexible with the parametrization of NegativeBinomialLikelihood.
This is done here by having an extra parameter.
The interface is easily extended by defining a new type and two functions!
Also add docs to explain all this mess
There is still an issue with Functors.jl I will try to solve. But I thought I would already show the current status to get some feedback.

also, patch bump?


The cog icon doesn't make clear this is a "Help" screen

Not everyone will get that this is Minesweeper clone (or recall its rules). The cog icon is a bit unclear and not everyone will understand that this is where one can get help. Suggestion: make this clearer through an "info" icon.

This is addressed with #318


test

What
Link to story
Describe what you did and why.
Checklist
Before you ask people to review this PR:

[ ] Tests and rubocop should be passing: bundle exec rake
[ ] Github should not be reporting conflicts; you should have recently run git rebase master.
[ ] There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
[ ] The PR description should say what you changed and why, with a link to the JIRA story.
[ ] You should have looked at the diff against master and ensured that nothing unexpected is included in your changes.
[ ] You should have checked that the commit messages say why the change was made.

Codecov Report

Merging #2504 (4ecdc19) into master (b287c2b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master     #2504   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          516       516
  Lines        10191     10191
=========================================
  Hits         10191     10191

Continue to review full report at Codecov.

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


Build fails on i386 systems: error: no matching function for call to 'make_ul'

See the log here: http://beefy5.nyi.freebsd.org/data/120i386-default/503690/logs/rumur-2019.06.05.log

Thanks for reporting this. Looks like the code incorrectly assumes size_t is the same as unsigned long. I don't have an i386 machine on which to reproduce this, but I've pushed some changes to the branch bugfix/github-136 that I think should resolve the problem. It hasn't passed Travis CI yet, but could you have a look at the changes in that branch and let me know if they solve your problem?

I don't have an i386 system either, and wouldn't be able to test it.
If you found some obvious problem, please just merge the fix and it will be auto-tested with the next port update.

Hm a little awkward. I'll see if I have a platform that can bring up an i386 FreeBSD VM to test. Stay tuned...

I brought up an i386 FreeBSD 12 VM and b04ecbc does indeed fix the compilation error. Unfortunately this unmasks the next problem.
The test suite fails because compilation of the generated verifier includes calls to undefined functions __atomic_store_8 and __atomic_load_8. This is a situation I'm familiar with, where the compiler is expecting you to link against libatomic. However, the verifier is intended to be standalone (e.g. we pass -mcx16 on x86_64 to force 128-bit operations to be emitted as cmpxchg16b, avoiding the libatomic call).
I tried to get Clang to emit a cmpxchg8b instead of the libatomic calls, using -march=i586 and upgrading to Clang 8.0.0, but with no success. So I went digging for some details. It seems this problem was independently discovered during RC testing of LLVM on FreeBSD 11 (https://lists.llvm.org/pipermail/llvm-dev/2018-August/125090.html). The general consensus seems to be that the upstream in change in LLVM is actually a correction, but this doesn't help FreeBSD much whose tale seems to lead to this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888.
I'm not sure what the best solution here is, as it seems libatomic is not available on FreeBSD and Rumur's generated verifier relies on double-word (64-bit on i386) atomics. We could work around this by taking a mutex, but it would be sort of self-defeating as the purpose of the atomics is to support a lock-free algorithm. As I can't imagine anyone using an i386 machine for the kind of memory-/runtime-intensive verification that Rumur is designed for, I'm inclined to just note we don't support i386 and leave it at that. What do you think?

libatomic might be unavailable by mistake.
There are some ports tat are disabled specifically on i386 for a similar/same reason:
astro/siril/Makefile:BROKEN_i386=       undefined reference to `__atomic_load' and `__atomic_compare_exchange'
science/cctbx/bootstrap.pyscience/gromacs/Makefile:BROKEN_i386=   undefined reference to `__atomic_load' and `__atomic_compare_exchange'
science/qmcpack/Makefile:BROKEN_i386=     undefined reference to `__atomic_load'
science/gabedit/Makefile:BROKEN_i386=   undefined reference to `__atomic_load'
science/openmx/Makefile:BROKEN_i386=    undefined reference to `__atomic_load', see bug#229605 and https://reviews.llvm.org/D42154
science/erkale/Makefile:BROKEN_i386=    liberkale_omp.so.0.1.0: undefined reference to `__atomic_compare_exchange'

And there's this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230888
So I suggest to label rumur likewise broken on i386 until this problem is resolved in the system.

Please commit your fixes up to the point of this libatomic-related.
The port is already labeled BROKEN on i386.

I toyed with this some more and discovered it's reproducible on non-FreeBSD platforms as well (at least macOS). If you do a 64-bit __atomic_* you end up with calls to ___atomic_*_8 in the emitted code when building with -m32. This all works out on macOS because Clang/LLVM itself provides these instead of relying on libatomic. Even so, this is undesirable as it makes this lock-free code no longer lock-free.
It seems we can force a cmpxchg8 by using the older __sync_*_compare_and_swap. I think we should do this as we do for x86-64. I'll work on implementing this and see if it repairs FreeBSD i386 builds.

I've just pushed a new release, v2019.06.12, that passes the test suite for me on FreeBSD i386. I'll wait for the Travis tests to pass and then tag the release commit.

The tests passed and I've pushed the release tag. This should be everything to get the FreeBSD i386 port passing I think. Let me know if you have further problems, and thanks again for the packaging work!

Thank you for fixing this issue!
I've just updated the port.


Added pub use on embedded_hal::watchdog traits so clients can use ena…

…ble/disable on watchdog without having to "use" the embedded_hal.
I ran into this when disabling the new watchdog with the SAM4E BSP:
error[E0599]: no method named disable found for struct sam4e_xplained_pro::atsam4_hal::watchdog::Watchdog in the current scope
--> examples/blinky.rs:68:36
|
68 |     Watchdog::new(peripherals.WDT).disable();
|                                    ^^^^^^^ method not found in sam4e_xplained_pro::atsam4_hal::watchdog::Watchdog
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a use for it:
|
7  | use sam4e_xplained_pro::atsam4_hal::prelude::_embedded_hal_watchdog_WatchdogDisable;
|

Looks good.
You'll want to run cargo fmt first.


Templating  Dockerfiles - JAVA

This PR is the first in a series of PRs to simplify the process of writing and changing our docker files.  The goal here is to introduce a common base image for the Azure Host runtime bits that can be shared across all of our images.  The method I achieve that through here is by running a script to combine our language specific images with the base image defined in this PR.
Re-using the same base image has two major benefits.  The most pronounced is to reduce the need for scripts like update-version.sh or github commits that require changes to all of our host base images.  With our current configuration, changes to the base image require over 50 file change just to maintain consistency between images.  This is dangerous as there is not an automated method to change all files at once (other than hostversion) and it is easy to miss one or two files while trying to alter all of them.
Base image re-use hopefully reduces the need for PRs like this : https://github.com/Azure/azure-functions-docker/pull/515/files
By introducing this method, it should be much easier to change our images and maintain consistency.  A lack of consistency is an important barrier to overcome as inconsistent base images invalidate the docker cache leading to unnecessarily longer build times, quicker worker cache exhaustion, and possibly hard to track bugs.
This PR and the forthcoming PRs to apply this everywhere have limited expected impact on cache size but, will hopefully boost developer productivity, traceability and maintainability of this repo. There are numerous PRs in the history of this repo that were required to fix dockerfiles that were accidentally ignored during initial work.  This tool aims to change that.
Another major benefit of this approach is breaking apart multi-stage builds.  This makes it easier to produce early stages as images which can allow us to cut down on image size by inspecting the runtime-image stage file system and ensuring we are only copying over what is needed.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which has an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] If applicable, the PR references the bug/issue that it fixes in the description.
[ ] New Unit tests were added for the changes made and CI is passing.

As discussed offline - Please checkin the produced docker files into a test directory and add unit tests

I will be squashing and merging this branch after approval :) Just rebased.

Looks great. Greatly simplifies updating host versions. One minor thing for later - if there is any guidance for new dockerfile authors / making more involved changes in existing dockerfiles, please document them somewhere.


Maintainance + Dropping Node Support

Replaces #1121

not sure the status on this or if this is still necessary, will close


Australia

I have asked the Australian Embassy to advocate for this over on FB
https://www.facebook.com/groups/AustralianEmbassyGermany/permalink/1266063263747452/

Internal Tracking Id: EXPOSUREAPP-2073

Hi @zspitzer,
Thank you for your proposal. All issues in the cwa-wishlist repository will be discussed with our contracting entities.  As soon as we have any updates, we will let you know about the details.
Best regards,
SD
Corona-Warn-App Open Source Team


Magic Leap API + docs

We have supported the Magic Leap simulator for a while now. We will also support the real hardware when it ships!
However our approach/API exposition is not documented anywhere. We should clean up the API to conform to web expectations, with minimal deviation from WebXR, and then write up the documentation on https://docs.webmr.io 📖.

Closing this issue due to being outdated. Magic Leap docs can now be found at magicleap.md.


fix(docs): type key missing on resourceTaggingApi example

Issue # (if applicable)
/
Closes #/
Reason for this change
The example in the docs for the resourceTaggingApi were missing a type key, so it didnt work.
Description of changes
Adding a line of documentation
Description of how you validated changes
/
Checklist

[ ] My code adheres to the CONTRIBUTING GUIDE

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

This issue was fixed in #84 which was needed for other development


feat: new "platform image statements"

"platform statements" graphics
@hakeemawbrey

[ ] (optional) redesign the image below
Flutter platform statement > "An open-source, full-stack platform for creating end-to-end encrypted Dart/Flutter apps"

Also would like a "platform statement" for java, Flutter, and IoT

[ ] Java platform statement > "An open-source, full-stack platform for creating end-to-end encrypted Java apps"
[ ] IoT platform statement > "An open-source, full-stack platform for simplifying and securing IoT devices"

These would go in the Get started sections, ideally, a dark-mode and light-mode would be awesome.
Thank you @thenobleone14 @jenmonroe for input on the statements
Once graphics are done, @JeremyTubongbanua will implement using image shortcodes

[ ] implement the images

@hakeemawbrey @Dariamarg can this be a Hacktoberfest issue?

@JeremyTubongbanua @XavierChanth I would like to work on this, kindly assign this to me.

@XavierChanth Do i have to design the images and provide them to @JeremyTubongbanua ?

Hi @kaggrwal, the lead for this issue is currently away. I will do my best to find this info. I will get it to you next week if I cannot get it today.

Hey @kaggrwal Sorry that there was no context for this ticket.. it was assigned to people who knew what the task was.
Basically, we need images like this one, but updated with new messages and just an overall redesign.

We need 3 versions:

[ ] "An open-source, full-stack platform for creating end-to-end encrypted Java apps"
[ ] "An open-source, full-stack platform for creating end-to-end encrypted Dart/Flutter apps"
[ ] "An open-source, full-stack platform for simplifying and securing IoT devices"


Can't remove flairs from edit flair list

And now we are stuck like this on the live FlairHQ:
http://i.imgur.com/8KRXoyk.png
Let's hope nobody notices (they will).
Shared things are fun sometimes!

You can now delete a flair and then save and it'll be gone.


Not working in VS code

Extension Name: search-rg
Extension Version: 1.0.0
OS Version: Windows_NT x64 10.0.17134
VSCode version: 1.28.0

We have written the needed data into your clipboard. Please paste:

pls see https://github.com/Microsoft/vscode/issues/60318


Decouple hdfs storage, support config multiple folders for hdfs

Coverage remained the same at 51.71% when pulling 0ab9b43cbb432a2476758f70683be06e2d6cedcb on zimiao/decouple_hdfs_storage into 829a018a25f09231ed56bbae9cdffd66e02c7629 on master.

Coverage remained the same at 51.71% when pulling 0ab9b43cbb432a2476758f70683be06e2d6cedcb on zimiao/decouple_hdfs_storage into 829a018a25f09231ed56bbae9cdffd66e02c7629 on master.

Coverage remained the same at 51.71% when pulling 0ab9b43cbb432a2476758f70683be06e2d6cedcb on zimiao/decouple_hdfs_storage into 829a018a25f09231ed56bbae9cdffd66e02c7629 on master.

Coverage remained the same at 51.71% when pulling 0ab9b43cbb432a2476758f70683be06e2d6cedcb on zimiao/decouple_hdfs_storage into 829a018a25f09231ed56bbae9cdffd66e02c7629 on master.


Link against GaudiAlgLib to work with Gaudi v38

BEGINRELEASENOTES

Link tests against Gaudi::GaudiAlgLib to make them build / link with Gaudi v38.

ENDRELEASENOTES

GaudiAlgLib is what we want to get rid of in https://github.com/key4hep/k4FWCore/issues/114. On top of that, Gaudi v38 has been in the stack for a while and tests work fine, see the CI of any recent PR. I don't understand, what's the problem?

Than it might be an issue with my local stack and a newer (>38.2) version of Gaudi. Let me investigate a bit further. Also this is for the tests, I think, so a normal build might work if it doesn't build the tests.

It might also be a Ubuntu thing? If I build on Ubuntu against the current nightly (2024-04-15), I get the following linker error without this PR:
&& /usr/bin/g++ -fPIC -fdiagnostics-color=always   -shared  -o test/k4FWCoreTest/libk4FWCoreTestPlugins.so test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleEventHeaderConsumer.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleFunctionalConsumer.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleFunctionalConsumerMultiple.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleFunctionalProducer.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleFunctionalProducerMultiple.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleFunctionalTransformer.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ExampleFunctionalTransformerMultiple.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/ReadDDSimOutput.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/TestUniqueIDGenSvc.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/k4FWCoreTest_AlgorithmWithTFile.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/k4FWCoreTest_CheckExampleEventData.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/k4FWCoreTest_CreateExampleEventData.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/k4FWCoreTest_HelloWorldAlg.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/k4FWCoreTest_cellID_reader.cpp.o test/k4FWCoreTest/CMakeFiles/k4FWCoreTestPlugins.dir/src/components/k4FWCoreTest_cellID_writer.cpp.o -L/home/tmadlener/work/key4hep/k4FWCore/build/.plugins -Wl,-rpath,/home/tmadlener/work/key4hep/k4FWCore/build/.plugins:/home/tmadlener/work/key4hep/k4FWCore/build/k4FWCore:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-04-15/x86_64-ubuntu22.04-gcc11.4.0-opt/edm4hep/792cefc3a0f7cb3dfa12aba50a24a6f37089e84e_develop-v2np7t/lib:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/gaudi/38.0-76wkel/lib:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/boost/1.84.0-vbjlqy/lib:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/intel-tbb/2021.9.0-frifn6/lib:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/python/3.10.13-7ljnw7/lib:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-04-15/x86_64-ubuntu22.04-gcc11.4.0-opt/podio/428150fe3704867ae0b24b5df5b7a0fe803681a9_develop-hw3hk6/lib:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root:/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/vdt/0.4.4-eq3nlo/lib:  k4FWCore/libk4FWCore.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-04-15/x86_64-ubuntu22.04-gcc11.4.0-opt/edm4hep/792cefc3a0f7cb3dfa12aba50a24a6f37089e84e_develop-v2np7t/lib/libedm4hepDict.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-04-15/x86_64-ubuntu22.04-gcc11.4.0-opt/edm4hep/792cefc3a0f7cb3dfa12aba50a24a6f37089e84e_develop-v2np7t/lib/libedm4hep.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/gaudi/38.0-76wkel/lib/libGaudiKernel.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/gaudi/38.0-76wkel/lib/libGaudiPluginService.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/boost/1.84.0-vbjlqy/lib/libboost_filesystem.so.1.84.0  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/boost/1.84.0-vbjlqy/lib/libboost_atomic.so.1.84.0  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/boost/1.84.0-vbjlqy/lib/libboost_thread.so.1.84.0  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/boost/1.84.0-vbjlqy/lib/libboost_regex.so.1.84.0  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/boost/1.84.0-vbjlqy/lib/libboost_system.so.1.84.0  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/intel-tbb/2021.9.0-frifn6/lib/libtbb.so.12.9  -ldl  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/fmt/10.2.1-ysbeqp/lib/libfmt.a  /usr/lib/x86_64-linux-gnu/librt.a  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-04-15/x86_64-ubuntu22.04-gcc11.4.0-opt/podio/428150fe3704867ae0b24b5df5b7a0fe803681a9_develop-hw3hk6/lib/libpodioRootIO.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libTree.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libMathCore.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libROOTNTuple.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libImt.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libMultiProc.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libNet.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libRIO.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libThread.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libROOTVecOps.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/vdt/0.4.4-eq3nlo/lib/libvdt.so  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/root/6.28.10-or4q4m/lib/root/libCore.so.6.28.10  /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-04-15/x86_64-ubuntu22.04-gcc11.4.0-opt/podio/428150fe3704867ae0b24b5df5b7a0fe803681a9_develop-hw3hk6/lib/libpodio.so  -Wl,-rpath-link,/cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/python/3.10.13-7ljnw7/lib && cd /home/tmadlener/work/key4hep/k4FWCore/build/test/k4FWCoreTest && /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/cmake/3.27.9-u6cj5k/bin/cmake -E create_symlink /home/tmadlener/work/key4hep/k4FWCore/build/test/k4FWCoreTest/libk4FWCoreTestPlugins.so /home/tmadlener/work/key4hep/k4FWCore/build/.plugins/libk4FWCoreTestPlugins.so && cd /home/tmadlener/work/key4hep/k4FWCore/build/test/k4FWCoreTest && /home/tmadlener/work/key4hep/k4FWCore/build/run /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/gaudi/38.0-76wkel/bin/listcomponents --output k4FWCoreTestPlugins.components libk4FWCoreTestPlugins.so && cd /home/tmadlener/work/key4hep/k4FWCore/build/test/k4FWCoreTest && /home/tmadlener/work/key4hep/k4FWCore/build/run /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2024-03-08/x86_64-ubuntu22.04-gcc11.4.0-opt/gaudi/38.0-76wkel/bin/genconf --configurable-module=GaudiKernel.Proxy --configurable-default-name=Configurable.DefaultName --configurable-algorithm=ConfigurableAlgorithm --configurable-algtool=ConfigurableAlgTool --configurable-auditor=ConfigurableAuditor --configurable-service=ConfigurableService -o genConfDir/k4FWCoreTest -p k4FWCoreTest -i /home/tmadlener/work/key4hep/k4FWCore/build/test/k4FWCoreTest/libk4FWCoreTestPlugins.so
ERROR: failed to load libk4FWCoreTestPlugins.so: /home/tmadlener/work/key4hep/k4FWCore/build/test/k4FWCoreTest/libk4FWCoreTestPlugins.so: undefined symbol: _ZN14GaudiAlgorithm10sysExecuteERK12EventContext
[26/29] Linking CXX shared module k4FWCore/libk4FWCorePlugins.so

with
$ c++filt _ZN14GaudiAlgorithm10sysExecuteERK12EventContext
GaudiAlgorithm::sysExecute(EventContext const&)

I have no explanation however, how spack is able to build it in this case.

Now all the references to GaudiAlg should be gone for this repository

Now I run into a undefined symbol: _ZTI14GaudiAlgorithm. I am not really sure what is different on my end and for the nightlies which are obviously working.

Is it when linking or running some dictionary generation?

It's during linking. I have no idea why it fails though. The library contents for Gaudi are the same for the nightlies and for me locally. However for the stacks deployed on CVMFS libk4FWCoreTestPlugins.so (which is the one that fails linking for me), does not depend on libGaudiAlgLib.so at all. It looks like the linker (settings?) is trying to pull something in that it does not necessarily need. Anyhow, I have a local workaround for now, and it doesn't seem to happen for the nightlies, so we can keep this on low priority.

Not reproducible


feat: add titleColor property to event rendering

This PR introduces the titleColor property to the EventItem in react-native-calendar-kit, allowing developers to customize the color of individual event titles directly.
Why This Change?
Previously, the event title color could only be customized globally via theme.eventTitleStyle. While this works for consistent styles, it lacked the flexibility to dynamically set different colors for individual events.
By introducing the titleColor property:
Developers can assign unique title colors for specific events.
The fallback to theme.eventTitleStyle ensures backward compatibility and consistent behavior for events without titleColor.

thtit


AOT compiled WASM couldn't be loaded on macOS M1 environment

Step to replicates

Build ./sample/basic WASM application
Move to wamr-compiler and build wamrc
Built AOT object from  ./out/wasm-apps/testapp.wasm with wamrc:

/path/to/wamr-compiler/build/wamrc --cpu=apple-m1 --size-level=3 -o ./out/wasm-apps/testapp.aot ./out/wasm-apps/testapp.wasm
Create AoT compiler with:
  target:        arm64
  target cpu:    apple-m1
  cpu features:
  opt level:     3
  size level:    3
  output format: AoT file
Compile success, file ./out/wasm-apps/testapp.aot was generated.

Execute basic sample application with AOT object.
Then, :boom:!

$  ./out/basic -f out/wasm-apps/testapp.aot
Load wasm module failed. error: AOT module load failed: mmap memory failed

Environment
Software versions:
$ sw_vers
ProductName:	macOS
ProductVersion:	12.5
BuildVersion:	21G72

Host Compiler version:
$ clang --version
Apple clang version 13.1.6 (clang-13<IP_ADDRESS>.5)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

WASI SDK's compiler version:
$ ~/work/wasi-sdk-16.0/bin/clang --version
clang version 14.0.4 (https://github.com/llvm/llvm-project 29f1039a7285a5c3a9c353d054140bf2556d4c4d)
Target: wasm32-unknown-wasi
Thread model: posix
InstalledDir: ~/work/wasi-sdk-16.0/bin

I tried to take a look on M1 Mac issue and I found the several issue before calling WASM function part:

With macOS arm64 runtime, it is always hardened. We shouldn't use PROT_EXEC flags in mmap. Otherwise, mmap is failed.

diff --git a/wasm-micro-runtime-WAMR-05-18-2022/core/shared/platform/common/posix/posix_memmap.c b/wasm-micro-runtime-WAMR-05-18-2022/core/shared/platform/common/posix/posix_memmap.c
index 2dfbee453..1de331ea3 100644
--- a/wasm-micro-runtime-WAMR-05-18-2022/core/shared/platform/common/posix/posix_memmap.c
+++ b/wasm-micro-runtime-WAMR-05-18-2022/core/shared/platform/common/posix/posix_memmap.c
@@ -16,6 +16,12 @@ static size_t total_size_munmapped = 0;

 #define HUGE_PAGE_SIZE (2 * 1024 * 1024)

+#if defined(__APPLE__) && defined(__arm64__)
+#define EXEC_FLAGS 0
+#else
+#define EXEC_FLAGS PROT_EXEC
+#endif
+
 #if !defined(__APPLE__) && !defined(__NuttX__) && defined(MADV_HUGEPAGE)
 static inline uintptr_t
 round_up(uintptr_t v, uintptr_t b)
@@ -66,7 +72,7 @@ os_mmap(void *hint, size_t size, int prot, int flags)
         map_prot |= PROT_WRITE;

     if (prot & MMAP_PROT_EXEC)
-        map_prot |= PROT_EXEC;
+        map_prot |= EXEC_FLAGS;

 #if defined(BUILD_TARGET_X86_64) || defined(BUILD_TARGET_AMD_64)
 #ifndef __APPLE__
@@ -243,7 +249,7 @@ os_mprotect(void *addr, size_t size, int prot)
         map_prot |= PROT_WRITE;

     if (prot & MMAP_PROT_EXEC)
-        map_prot |= PROT_EXEC;
+        map_prot |= EXEC_FLAGS;

     return mprotect(addr, request_size, map_prot);
 }

Default target name of M1 macOS is arm64 not aarch64v8

diff --git a/wasm-micro-runtime-WAMR-05-18-2022/core/iwasm/aot/arch/aot_reloc_aarch64.c b/wasm-micro-runtime-WAMR-05-18-2022/
core/iwasm/aot/arch/aot_reloc_aarch64.c
index 4c46eaa00..dc3cb8f41 100644
--- a/wasm-micro-runtime-WAMR-05-18-2022/core/iwasm/aot/arch/aot_reloc_aarch64.c
+++ b/wasm-micro-runtime-WAMR-05-18-2022/core/iwasm/aot/arch/aot_reloc_aarch64.c
@@ -53,7 +53,11 @@ get_target_symbol_map(uint32 *sym_num)
     return target_sym_map;
 }

+#if defined(__APPLE__) && defined(__arm64__)
+#define BUILD_TARGET_AARCH64_DEFAULT "arm64"
+#else
 #define BUILD_TARGET_AARCH64_DEFAULT "aarch64v8"
+#endif
 void
 get_current_target(char *target_buf, uint32 target_buf_size)
 {

With the above change, I still got bus error:
$ lldb --  ./out/basic -f out/wasm-apps/testapp.aot
(lldb) target create "./out/basic"
Current executable set to '/Users/cosmo/GitHub/wasm-micro-runtime/samples/basic/out/basic' (arm64).
(lldb) settings set -- target.run-args  "-f" "out/wasm-apps/testapp.aot"
(lldb) r
Process 27342 launched: '/Users/cosmo/GitHub/wasm-micro-runtime/samples/basic/out/basic' (arm64)
Process 27342 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1002dc004)
    frame #0: 0x00000001002dc004
->  0x1002dc004: str    d8, [sp, #-0x70]!
    0x1002dc008: stp    x29, x30, [sp, #0x10]
    0x1002dc00c: stp    x28, x27, [sp, #0x20]
    0x1002dc010: stp    x26, x25, [sp, #0x30]
Target 0: (basic) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1002dc004)
  * frame #0: 0x00000001002dc004
    frame #1: 0x000000010001c224 basic`call_func + 8
    frame #2: 0x0000000100030fb0 basic`invoke_native_with_hw_bound_check + 444
    frame #3: 0x0000000100030bc0 basic`aot_call_function + 420
    frame #4: 0x00000001000199a4 basic`wasm_runtime_call_wasm_a + 740
    frame #5: 0x0000000100001288 basic`main + 612
    frame #6: 0x00000001000d508c dyld`start + 520

Hello, I'm getting the same error on MacOS M1, did you manage to find a solution?

No, I didn't. Currently, I disable to use AOT execution on M1 Mac.

@wenyongh Any hints on what changes would be needed to use AOT on M1 macs?
After reading the docs, I was changing
diff --git a/core/iwasm/aot/aot_loader.c b/core/iwasm/aot/aot_loader.c
index b5fa33c0..854453ad 100644
--- a/core/iwasm/aot/aot_loader.c
+++ b/core/iwasm/aot/aot_loader.c
@@ -3232,6 +3232,7 @@ aot_load_from_aot_file(const uint8 *buf, uint32 size, char *error_buf,
     if (!module)
         return NULL;

+    pthread_jit_write_protect_np(false);
     if (!load(buf, size, module, error_buf, error_buf_size)) {
         aot_unload(module);
         return NULL;
diff --git a/core/iwasm/aot/arch/aot_reloc_aarch64.c b/core/iwasm/aot/arch/aot_reloc_aarch64.c
index 4c46eaa0..10ec3f5a 100644
--- a/core/iwasm/aot/arch/aot_reloc_aarch64.c
+++ b/core/iwasm/aot/arch/aot_reloc_aarch64.c
@@ -53,7 +53,12 @@ get_target_symbol_map(uint32 *sym_num)
     return target_sym_map;
 }

+#if defined(__APPLE__) && defined(__arm64__)
+#define BUILD_TARGET_AARCH64_DEFAULT "arm64"
+#else
 #define BUILD_TARGET_AARCH64_DEFAULT "aarch64v8"
+#endif
+
 void
 get_current_target(char *target_buf, uint32 target_buf_size)
 {
diff --git a/core/shared/platform/common/posix/posix_memmap.c b/core/shared/platform/common/posix/posix_memmap.c
index 2dfbee45..9c403d66 100644
--- a/core/shared/platform/common/posix/posix_memmap.c
+++ b/core/shared/platform/common/posix/posix_memmap.c
@@ -36,7 +36,7 @@ void *
 os_mmap(void *hint, size_t size, int prot, int flags)
 {
     int map_prot = PROT_NONE;
-    int map_flags = MAP_ANONYMOUS | MAP_PRIVATE;
+    int map_flags = MAP_ANONYMOUS | MAP_PRIVATE | MAP_JIT;
     uint64 request_size, page_size;
     uint8 *addr = MAP_FAILED;
     uint32 i;

And with that I managed fix some problems and get farther in the execution, but I still get
thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100430008)
  * frame #0: 0x0000000100430008
    frame #1: 0x000000010006f5f0 iwasm`invoke_native_with_hw_bound_check(exec_env=0x0000000103600800, func_ptr=0x0000000100430008, func_type=0x0000000102400590, signature=0x0000000000000000, attachment=0x0000000000000000, argv=0x0000000000000000, argc=0, argv_ret=0x0000000000000000) at aot_runtime.c:1392:19
    frame #2: 0x000000010006f160 iwasm`aot_call_function(exec_env=0x0000000103600800, function=0x000000016fdfdc80, argc=0, argv=0x0000000000000000) at aot_runtime.c:1601:15
    frame #3: 0x000000010006e7b4 iwasm`execute_post_instantiate_functions(module_inst=0x0000000102703380, is_sub_inst=false, exec_env_main=0x0000000000000000) at aot_runtime.c:1022:14
    frame #4: 0x000000010006d0b8 iwasm`aot_instantiate(module=0x0000000101ed0a40, parent=0x0000000000000000, exec_env_main=0x0000000000000000, stack_size=65536, heap_size=0, error_buf="", error_buf_size=128) at aot_runtime.c:1231:10
    frame #5: 0x00000001000372a0 iwasm`wasm_runtime_instantiate_internal(module=0x0000000101ed0a40, parent=0x0000000000000000, exec_env_main=0x0000000000000000, stack_size=65536, heap_size=0, error_buf="", error_buf_size=128) at wasm_runtime_common.c:1340:44
    frame #6: 0x0000000100037314 iwasm`wasm_runtime_instantiate(module=0x0000000101ed0a40, stack_size=65536, heap_size=0, error_buf="", error_buf_size=128) at wasm_runtime_common.c:1354:12
    frame #7: 0x0000000100006d3c iwasm`main(argc=1, argv=0x000000016fdfecc8) at main.c:933:15
    frame #8: 0x000000019a953f28 dyld`start + 2236

I tried adding the address sanitizer to get more info:
./iwasm -v=5 wasm-apps/no_pthread.aot
[5/5] Linking C executable iwasm
[10:45:10:477 - 1F610DB40]: Found malloc function, name: malloc, index: 17
[10:45:10:626 - 1F610DB40]: Found free function, name: free, index: 19
[10:45:10:632 - 1F610DB40]: Load module success.

[10:45:10:654 - 1F610DB40]: Memory instantiate:
[10:45:10:656 - 1F610DB40]:   page bytes: 65536, init pages: 1, max pages: 30
[10:45:10:658 - 1F610DB40]:   data offset: 5808, stack size: 32768
[10:45:10:660 - 1F610DB40]:   heap offset: 65536, heap size: 0

AddressSanitizer:DEADLYSIGNAL
=================================================================
==37835==ERROR: AddressSanitizer: BUS on unknown address (pc 0x000100618008 bp 0x00016fc19800 sp 0x00016fc195d0 T0)
==37835==The signal is caused by a UNKNOWN memory access.
==37835==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x100618008  (<unknown module>)
    #1 0x1002535ec in invoke_native_with_hw_bound_check aot_runtime.c:1392
    #2 0x10025315c in aot_call_function aot_runtime.c:1601
    #3 0x1002527b0 in execute_post_instantiate_functions aot_runtime.c:1022
    #4 0x1002510b4 in aot_instantiate aot_runtime.c:1231
    #5 0x10021b29c in wasm_runtime_instantiate_internal wasm_runtime_common.c:1340
    #6 0x10021b310 in wasm_runtime_instantiate wasm_runtime_common.c:1354
    #7 0x1001ead38 in main main.c:933
    #8 0x19a953f24  (<unknown module>)

==37835==Register values:
 x[0] = 0x0000000103600800   x[1] = 0x0000000000000000   x[2] = 0x0000000000000000   x[3] = 0x0000000000000000
 x[4] = 0x0000000000000000   x[5] = 0x0000000000000000   x[6] = 0x0000000000000000   x[7] = 0x0000000000000000
 x[8] = 0x0000000100221cf0   x[9] = 0x0000000000000000  x[10] = 0x0000000000000000  x[11] = 0x0000000000000001
x[12] = 0x0000000000000000  x[13] = 0xffffff8fd205cd1f  x[14] = 0x0000000000007e01  x[15] = 0x0000000000000006
x[16] = 0x000000019acda3d0  x[17] = 0x00000001006b45e0  x[18] = 0x0000000000000000  x[19] = 0x0000000100618008
x[20] = 0x000000010021f1b0  x[21] = 0x0000000000000000  x[22] = 0x000000016fc195d0  x[23] = 0x000000019a9ce366
x[24] = 0x000000016fc1a9d0  x[25] = 0x0000000000000001  x[26] = 0x0000000000000000  x[27] = 0x0000000000000000
x[28] = 0x0000000000000000     fp = 0x000000016fc19800     lr = 0x0000000100221d74     sp = 0x000000016fc195d0
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS (<unknown module>)
==37835==ABORTING
[1]    37835 abort      ./iwasm -v=5 wasm-apps/no_pthread.aot

I don't know much about AOT, so I would appreciate any inputs or suggestions on what to try next.

Managed to get it to work, opening a PR

Seems to be resolved in https://github.com/bytecodealliance/wasm-micro-runtime/pull/2618.


[Relay] Use opaque for where op

Fuse where op will cause significant performance degradation in BERT model

Can we look a bit into what is going on? e.g. too deep fusion or selection? This seems to be a quite arbitrary change

ping @kevinthesun @icemelon9 Please take a look into this. I still think it is a quite arbitrary change, given that operators like relu can be implemented using where, and it makes sense to fuse in these cases.

Sorry about the delay. I'll look into this this week.

@tqchen After some benchmark, I do see there's slightly improvement on the CPU instances. On C5.9xl, with where being opaque, the latency of BERT is 34.51ms (std: 0.59ms), while with where being broadcast, the latency is 36.06ms (std: 0.50ms). The difference is about 1.5ms or 4%. But the difference on C5.4xl is smaller, opaque 46.99ms (std: 0.13ms) vs broadcast 47.87ms (std: 0.24ms), 1.8% improvement. I also evaluate this on GPU instance P3.2xl, which I didn't see much difference in performance.
Given the improvement is not very signficant on CPU, I think let's don't make this change for now. In the future, we can potentially have a performance based op fusion pass which it can determin what kind of fusion gives the best performance.

@icemelon9 Looks like the performance gap is not huge for cpu. We can keep the current fusion pattern then.

Agree. Close this PR for now.

@tqchen @kevinthesun After further investigation, I found that when the sequence length is 256, the fused batch_matmul + ones_like + where is significantly slower (~50%) than the non-fused version (code shown in below). I checked the schedule and found out that the culprit is likely to be the memory allocation in the fused op. This also explains why there's no much performance penalty when seq length is smaller.
Here's the example I used.
fn (%x: Tensor[(12, 256, 64), float32], %y: Tensor[(12, 256, 64), float32], %z: Tensor[(12, 256, 256), float32]) {
  %0 = nn.batch_matmul(%x, %y);
  %1 = ones_like(%0);
  where(%z, %0, %1)
}

A better solution to solve this should expose the workspace allocation into the memory planning as well. But for now, should we just use opaque for where?

#4537 fix the batch_matmul schedule issue


Error running the teacher forcing experiment from documentation

When running the teacher force example from documentation with tf backend I get
tensorflow.python.framework.errors_impl.InvalidArgumentError: The node 'recurrent_sequential_1/while_1/Variable_1/Assign' has inputs from different frames. The input 'recurrent_sequential_1/while_1/Const_1' is in frame 'recurrent_sequential_1/while_1/recurrent_sequential_1/while_1/'. The input 'recurrent_sequential_1/while_1/Variable_1' is in frame ''.
from keras.layers import Activation, Input
from keras.models import  Model
from recurrentshop import RecurrentSequential, LSTMCell
import numpy as np

rnn = RecurrentSequential(readout='add', teacher_force=True, return_sequences=True)
rnn.add(LSTMCell(10, input_dim=10))
rnn.add(LSTMCell(10))
rnn.add(LSTMCell(10))
rnn.add(Activation('softmax'))

x = Input((7, 10))
y_true = Input((7, 10))  # This is where you feed the ground truth values

y = rnn(x, ground_truth=y_true)

model = Model([x, y_true], y)

model.compile(loss='categorical_crossentropy', optimizer='sgd')

# Training

X_true = np.random.random((32, 7, 10))
Y_true = np.random.random((32, 7, 10))

model.fit([X_true, Y_true], Y_true)  # Note that Y_true is part of both input and output

# Prediction

X = np.random.random((32, 7, 10))

model.predict(X)  # >> Error! the graph still has an input for ground truth..

zeros = np.zeros((32, 7, 10)) # Need not be zeros.. any array of same shape would do

model.predict([X, zeros])

tf version = 1.2.0
keras version = 2.0.5

I get the same error - have you managed to resolve it?

I realize that this thread is quite old, but since I recently stumbled on recurrentshop, I also experienced this bug. As it turns out, the example from the documentation didn't work even when it was pushed on Github in April. Here is a quick fix, that will allow you to run the example:
Simply change the backend of keras to theano.
Either do this by following the instructions here (which didn't work for me) or run your code with KERAS_BACKEND=theano python your_teacher_enforcing_file.py .
Hope this helps!


Switch publish to build in the same way we manually build.

Also removed type restriction, this was preventing job from being
triggered, and add workflow_dispatch to allow manual triggering.
Signed-off-by: Jason Guiditta<EMAIL_ADDRESS>

lgtm


NewTrains should track Green line trains

We should ensure that we're actually tracking all the new trains when they go into service and are last seen

Likely related to https://github.com/transitmatters/data-ingestion/issues/3


Update and enhance the Documentation.txt file

The look of the Documentation file is not right.
I can make the file look better by fixing the Font size, headings, indentation, etc. It'll be easily readable for everyone.
@4darsh-Dev Kindly label the issue and assign it to me.

@abhi-la-sha  thanks for showing interest,
but we have moved our docs to wiki page and readme itself, so it is no longer needed.
You can find more things to contribute in project as well.


Add LDC 1.4.0

Thanks again! Should get installed tonight and then picked up on the next site update (coming soon I hope). If you haven't seen a site update including it by the end of the week, ping me directly and I'll cherry pick a release!

@mattgodbolt Welcome :)
About the default D compiler, can we switch it to LDC 1.4.0? The current default is GDC 5.2.0, but it's quite old (using D language 2.066, LDC 1.4.0 is D language 2.074).

Absolutely! Please file a PR and I"ll merge straight away!
On Mon, Sep 18, 2017 at 2:38 PM Johan Engelen<EMAIL_ADDRESS>wrote:

@mattgodbolt https://github.com/mattgodbolt Welcome :)
About the default D compiler, can we switch it to LDC 1.4.0? The current
default is GDC 5.2.0, but it's quite old (using D language 2.066, LDC 1.4.0
is D language 2.074).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattgodbolt/compiler-explorer-image/pull/29#issuecomment-330333289,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmsddI2nJ6ElEiIxzl17haK6zXft0WBks5sjsbOgaJpZM4PaJQJ
.


Implementation For Request Booking At Event Space

We have event space at dashboard then explore events and under that request booking for the space i made the schema for supabase check LEARN.md you just need to make the form and run insert query on it.
Make PR to dev and post video before make PR

@TejasNasre  Please Assign this issue to me so I'll start by creating the form and running the insert query as mentioned.

@TejasNasre Just to confirm, what do you mean by "Make PR to dev and post video before make PR"? Are you referring to recording a video walkthrough of the changes before submitting the PR? Please let me know so I can follow the correct process.

Yeah recording the walkthrough video

@TejasNasre Ok sir I will try to do my best.

@rudrapratap63 any updates ?

@TejasNasre, for confirmation, when the user clicks the Request Booking button, they will be redirected to a new form page where the form will have the following inputs:

Organizer ID
Space ID
Request Date
Status

There will also be a Submit Request button. When the user clicks the Submit Request button, we will run the insert query on it.

Yes

@TejasNasre I think in your learn.md documentation there is two typo error so can you please check this .

instead of this :
 constraint event_space_img - vid_pkey primary key (id),
 constraint event_space_img - vid_event_space_id_fkey foreign key (event_space_id) references event_space (id)

it should be like this:
constraint event_space_img_vid_pkey primary key (id),
constraint event_space_img_vid_event_space_id_fkey foreign key (event_space_id) references event_space (id)

@TejasNasre, when the user clicks the Submit Request  button, where should we redirect the user: to the explore-events page or the home page?

@TejasNasre, when the user clicks the Submit Request button, where should we redirect the user: to the explore-events page or the home page?

Redirect to dashboard

Ok I will change and redirect to the dashboard

@TejasNasre , please check the PR. I have now redirected the user to the dashboard when they click the request-booking button.


added command line batch size to the rali performance test app and ad…

…ded a modified app for rali performance that takes both batch size and depth size as input

@paveltc can you sync with TOT master before merge.


Ship Gradle API Kotlin extensions JAR with the Gradle distribution

First step for https://github.com/gradle/gradle/issues/26483

The code for Kotlin extensions generation that is now shared between the build logic building the Gradle distribution and the Gradle runtime for generated accessors has been moved from :kotlin-dsl to :build-logic:kotlin-dsl-shared-runtime.
The added weight to the Gradle distribution is ~145KB.
A couple subprojects of :build-logic have been pulled up to :build-logic-common in order to produce a valid Gradle module jar in :build-logic.
The generated extensions were never part of our binary compatibility check. This PR makes it possible but currently skips the @Generated code on purpose. A subsequent PR will deal with this.

This change makes first use faster by removing runtime processing. On my beefy m2 mac the gain is around 4s. On our performance test agents it is around 5s. On older or smaller machines, e.g. ephemeral CI agents, the impact will be larger.

This also makes iterating on our integration tests that use the Kotlin DSL faster because the extensions are compiled with a hot Kotlin compiler daemon as part of building the Gradle distribution vs. the cold embedded Kotlin compiler from the under-test Gradle runtime. Moreover, integration tests that require an isolated Gradle user home will simply not do that work anymore.

Thanks for the review @jbartok!
I'm going to start merging this as the risk of conflicts is high. I'll do follow ups anyway so please all feel free to still comment on this PR.
@bot-gradle test and merge

Your PR is queued. See the queue page for details.

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


HLA result

Hi，
  there are two questions when I use HiFihla software.
   1、why the HLA-A_1 is "HLA-A*11:01:01" not "HLA-A*11:01:01:55"? (final column)
   2、why the HLA-B_0 is "HLA-B" not "HLA-B*52:01:01:02"? (final column)

There are 2 equivalent matches at 99.93% of bases covered for the 2 reads in this cluster, and thus the exact match is ambiguous for these two reads.  This is probably a case where the locus is homozygous and the extra call is a spurious cluster.   you can adjust the min cdf to help remove this extra call.
Probably a similar case where the locus is homozygous and its generating a spurious cluster based on read error.  Any match that has coding diffs (exEdit > 0) is not given a final type call.

Given that  locus C also looks homozygous you can also set --haplotypes 1 and it won't try to cluster.


Conda build not working with python 3.6

Details
I am trying to build my python 3.6 only project's documentation using a conda environment. However, this fails because the package requirements are not satisfiable for 3.6. Locally my docs build fine with python 3.6. Not sure if that is because the package python versions are not updated on conda or because of the hardcoded version for some of the packages.

Project URL: http://readthedocs.org/projects/multiset/
Build URL: http://readthedocs.org/projects/multiset/builds/4880183/
environment.yml: https://github.com/wheerd/multiset/blob/master/environment.yml
Read the Docs username: Wheerd

Actual Result
Conda cannot find a working constallation for python 3.6:
The following specifications were found to be in conflict:
  - alabaster >=0.7,<0.8,!=0.7.5 -> python 2.7*|3.4*|3.5*
  - certifi (target=certifi-2016.9.26-py36_0.tar.bz2) -> python 2.6*|2.7*|3.3*|3.4*|3.5*|3.6*
  - docutils ==0.12 -> python 2.7*|3.4*|3.5*
  - mock -> python 2.7*|3.4*|3.5*
  - pillow ==3.0.0 -> python 2.7*|3.4*|3.5*
  - pip (target=pip-9.0.1-py36_1.tar.bz2) -> python 2.7*|3.4*|3.5*
  - pip (target=pip-9.0.1-py36_1.tar.bz2) -> setuptools
  - pygments ==2.1.1 -> python 2.7*|3.4*|3.5*
  - python 3.6*
  - setuptools (target=setuptools-32.3.1-py36_0.tar.bz2) -> certifi
  - setuptools (target=setuptools-32.3.1-py36_0.tar.bz2) -> python 2.6*|2.7*|3.3*|3.4*|3.5*|3.6*
  - sphinx ==1.3.5 -> python 2.7*|3.4*|3.5*
  - sphinx_rtd_theme ==0.1.7 -> python 2.7*|3.4*|3.5*
  - wheel (target=wheel-0.29.0-py36_0.tar.bz2) -> python 2.7*|3.3*|3.4*|3.5*|3.6*

We saw the same issue on Jupyter docs and temporarily have pinned python to 3.5 in environment.yml. See https://github.com/jupyter/nbconvert/pull/506 for temporary fix by @michaelpacer.
Issue also filed on conda https://github.com/conda/conda/issues/4168.

I am afraid that will not work for me, because I use autdoc and my project does not work under 3.5 anymore. I guess those are the downsides of trying to use the latest and greatest...

@wheerd Bummer... Perhaps a temporary work around for the autodoc would be a 2 step build: 1) locally build the source files that use autodoc and save those. 2) Use the locally generated files as input source files. We did that in the early days of the notebook docs. Not a great long term strategy but ok in a pinch. If I see any cleaner solutions, I'll post here.

I think I will have to wait for python 2.5.3 which is due to arrive in a week and fixes the typing module. I guess the docs will have to wait until then to get updated. But thanks for your help anyways @willingc :)
Getting python 3.6 support with conda on rtd would be nice though.

Could try using conda-forge. Many things have already been rebuilt for Python 3.6. This amounts to adding the code block below to your environment.yml file.
channels:
  - conda-forge

@jakirkham I will double check our files. We do have conda-forge on some of our Jupyter repos 👍

If you do find there are Python 3.6 packages missing from conda-forge, it is pretty easy to fix. One merely needs to re-render the feedstock in question. Though we definitely have Sphinx on Python 3.6. If you need help configuring the Jupyter repos for RTD, would be happy to chip in.

I am already using conda-forge. However, the problem ist that RTD locks the sphinx version to 1.3.5 for which there is no package at all in conda-forge and no python 3.6 package in the normal channel apparently. The same is probably true for the other packages that are version locked.
And since there is not python 3.5.3 package yet, I cannot use that either. I have already create an issue over there to get that version bumped (conda-forge/python-feedstock#110).

Yep, I went backed and looked at some of the Jupyter repos even those with the conda-forge channel were failing. @jakirkham Thoughts?

However, the problem ist that RTD locks the sphinx version to 1.3.5...

That's a pretty old version. Where in the logs are you seeing this getting pinned?

Yep, I went backed and looked at some of the Jupyter repos even those with the conda-forge channel were failing. @jakirkham Thoughts?

Could you please share a log from one of the failures? Feel free to email it if you prefer.

@jakirkham Here's an example from this morning.
RTD Build (Failed): https://readthedocs.org/projects/jupyter-client/builds/4913160/
jupyter_client environment.yml (PR change to pin to 3.5): https://github.com/jupyter/jupyter_client/commit/74cde1ff6963
RTD Build (Passed): https://readthedocs.org/projects/jupyter-client/builds/4913426/
Second step in the RTD build process has the failure.

Related PR to fix this issue https://github.com/rtfd/readthedocs.org/pull/2589

Also PR https://github.com/rtfd/readthedocs.org/pull/2378
Likely the best solution would be to automate the tests/builds when new sphinx versions are released.

So Python 3.5.3 is being built, which hopefully helps, @wheerd.
In general, we (conda-forge) could try to build Python 3.6 packages for all of these old versions that RTD is using. Though maybe we would be better off to work with RTD to get them to upgrade to newer versions. Found an issue ( https://github.com/rtfd/readthedocs.org/issues/2548 ) to bump the Sphinx version to 1.5, which would help.

@jakirkham thanks for the help, that should get my docs building again. But yes, I guess the best solution for building docs with python 3.6 docs would be to update the RTD dependencies to newer versions.

Perhaps a temporary work around for the autodoc would be a 2 step build: 1) locally build the source files that use autodoc and save those. 2) Use the locally generated files as input source files. We did that in the early days of the notebook docs.

@willingc How would I upload the generated files to rtd? I am also on a project that uses python 3.6 features.

Finally, the Sphinx 1.5.3 version was added to conda-forge. So, now there are two more issues opened regarding this topic that when they get closed, this issue you are having will disappear :)
Those are #2713 and #2714. I'm adding them here in case you want to subscribe also.

We're having the same issue. We're starting a Python 3.6 or later package, would like to install dependencies with conda, and can't get around this issue:
UnsatisfiableError: The following specifications were found to be in conflict:
  - python 3.6*
  - sphinx_rtd_theme ==0.1.7 -> python 3.5* -> xz 5.0.5
Use "conda info <package>" to see the dependencies for each package.

https://readthedocs.org/projects/hips/builds/5477266/
https://github.com/hipspy/hips
If a workaround exists (tell RTD to not try to install these old versions of Sphinx and sphinx_rtd_theme at all), please let us know.

@cdeil there is no a workaround for this but this week we did this PR #2876 that removes the pinned versions for conda environments so it shouldn't conflict with your own packages.
I think it will be deployed next week. So, please try again after that. Thank you for your report.

@humitos - thank you very much!!!
The point of using conda is that it gives you something that's independent of system config. So I was very confused when my RTD conda builds failed trying to conda install stuff that I never asked for (like the old version sphinx_rtd_theme ==0.1.7 mentioned above).
What exactly does #2876 do? Does it remove the conda install command from the build that was failing for me in https://readthedocs.org/projects/hips/builds/5477266/ ?
Is it simple to reproduce the RTD build / check locally if it will work now? I.e. are there a few docker / other commands listed somewhere that I could use to check if my project will now build after your change?

What exactly does #2876 do? Does it remove the conda install command from the build that was failing for me in https://readthedocs.org/projects/hips/builds/5477266/ ?

These are the steps used to create a project with conda environment:

conda env create -f user-environment.yml
conda install sphinx==1.5.3 rtd_sphinx_theme==0.1.7 ...
conda env update -f user-environment.yml

Now, with #2876 we are doing: 1) and in 2) we are not pinning at all and 3) is not ran.`

has to be ran since RTD needs a couple of extra packages that the user doesn't need for their own project. We think this new way of execution will work better. So, in case the user has some conflicts with the packages that RTD needs, the user could pin the RTD packages in their own environment.yml

Is it simple to reproduce the RTD build / check locally if it will work now? I.e. are there a few docker / other commands listed somewhere that I could use to check if my project will now build after your change?

Yes, it's easy to reproduce how RTD works (without installing the whole project) by running the commands I mentioned or taking a look at your own build -there are all the commands ran.
Please, let me know any comment you have on this. Besides, if you have a better idea, share it :)

@humitos - That's pretty good, thanks for this detailed infos!
I think it might even be nicer to have full control over the build, being able to e.g. provide a Dockerfile.
At the moment my main problem is the failing pip install in a conda build: #2827
I'll try to reproduce that locally now by copy & pasting the commands from the build log.
(but I'd be surprised if I can reproduce the issue locally ... why is no pip available???)

@humitos - The problem I'm having is with the pip install command you generate and run on RTD. I'm not able to reproduce the issue locally: https://github.com/rtfd/readthedocs.org/issues/2827#issuecomment-304534964
Does this pip install command go away with your changes in #2876 ?
Could it make sense to activate the conda env?


Using with elixir's "version" facade?

Is this possible? To use gulp to create a versioned assets (css,js,etc) and then upload and push to to Amazon AWS or something?

I just do:
``
{{ Cdn::Asset(elixir('css/all.css')) }}

and that works just fine


If the spacing is chosen small, the watermark is very close to the window

This product is great, I love it so much!
There is a small problem at the moment.
If the spacing is chosen small, the watermark is very close to the window

I just noticed it. Thanks for letting me know that.
Should I just push the watermark to the edge a bit more or do you have any other idea how we can solve this issue?

Increase the spacing of the minimum(small) size a little bit.😁
I tried to change the value of bottom and it solved the problem,
I still think we should increase the space a little

@code4you2021  That's exactly what I just did 😃


AAF-73 Refactor Input to include html input attribute list

Just started reviewing :) :octocat: Sent from GH.

@jwu910 so what's the problem with travis now
/home/travis/build/5-gwoap/adopt-a-family/src/components/Form.js   53:12  error  'formTitle' is missing in props validation  react/prop-types

Looks like we only have snapshot errors. @psyduc @phuchle review and it and merge if you can. Otherwise I will do so mañana


Documentation search bar

Let's enable search bar in the docs.

Just to be clear what's involved here - this isn't a simple configuration to enable.  It requires integration with something else that actually indexes the site content. Docusaurus does not index itself.


fixed: very un-effecient trigger handling may cause the moVirt to cra…

…sh on some devices

looks good :+1:

Tested, and now it's working.


style(GUI): capitalize every text for consitency purposes

As per @konmouz's request.

Fixes: https://github.com/resin-io/etcher/issues/881
Change-Type: patch
Changelog-Entry: Capitalize every text throughout the application.
Signed-off-by: Juan Cruz Viotti<EMAIL_ADDRESS>

As this also touches on the "marketing text" at the bottom of the window (changing it from UPPER CASE to Mixed Case), should we get @alisondavis17 's input on this?

I think I am missing some context here, but I prefer the "marketing text" at the bottom of the window to match the other sentence-length text in the app, where not every word is capitalized. So I would prefer: "[ETCHER LOGO] is an open source project by [RESIN.IO LOGO]."

Done!

@jviotti, thanks. Are we also transferring settings to a modal window?

@konmouz Yeah, we'll move the settings page to a modal and also update the main page to better match Zeplin's designs (e.g: remove number ordering, move the bar to be between the icons, etc).


Improving docs to list options for some of the settings

Some of the settings as themes and languages have options that are not being listed in the documentation. In this PR I'm adding them to README and also to the demo page. On the page it looks like:

If you believe they should be presented in another form, let me know and I can adjust them. :)

Also notice that firstDayOfWeek was being listed in README as a String, which is not true by the code.


Process Registration issue with parent requirement to run

It's been reported that restarting a process when the core process is set to not force itself to run would cause the process not to run the second time around.
The issue is that the flag "Allow Parent to Run" is not reset after a process terminates, if it is not destroyed.
Given this process configuration:

With this type of sequence calls:

The process would not run on the 2nd iteration.
The fix is to reset the flag in the SMO:Process.vi after the process terminates (synch'ed):

fixed for 1.3.0


Please add ACAPY_INVITE_PUBLIC env variable to true to IDIM config (startup param --invite-public)

To test, please add it to, and redeploy:
https://github.com/bcgov/trust-over-ip-configurations/blob/main/openshift/templates/issuer-agent/issuer-agent-deploy.idim-sit.test.param
It's likely safe to add it to all of the IDIM controllers.

Done


calibratable_parameters

The PR adds calibratable parameters smcmax ,b, and satpsi to bmi output variables list.

The code has been tested in/out of nextgen,
Tested in active (on) and inactive (off) calibratable mode
Existing tests have been updated
No changes to the functionality
Documentation (todo - as we plan to completely revise the Readme document of the repo)

Tested standalone and unit test, everything passed. I notice that in test/main_unittest.cxx, there is the text: **************** BEGIN SoilFreezeThaw BMI UNIT TEST ******************* . Aside from that I think it's ready.

Looks good! :)