Update forms extensions

There's already an extension-point for ShopAccountForm, it's updateShopAccountForm, called from within the ShopAccountForm constructor.
Regarding your extension-point to modify the default-address-form: Can you give me a use-case for this? Are you adding other addresses than Shipping and Billing to your Order?

I'd like to make it bootstrap compatible so I will need to set custom form templates

Wouldn't that be a global change to Form? Or do you have different templates for every form?

Nope, I have BootstrapForm class for frontend which I use to setup custom templates on frontend side. Global change of the Form class will make changes in the CMS.

Can't you just put a custom templates/Includes/Form.ss inside your theme for custom Form markup? As long as it's part of your theme, it won't be used within the CMS…

There's also extra functions like appending fields, placeholders and etc

I see, please remove the updateEditAccountForm hook, as it is redundant. Then this is good to merge.

I will add updateForm hooks directly to Form objects and will send you a request, thank you.

I think we should decide on the path of action first by coming to a conclusion in #538


add clarifications

Thank you. I didn't even notice that NSLocationWhenInUseUsageDescription was misspelled in the readme.

BTW I wrote https://github.com/jacobrosenthal/react-native-estimote but
they dont use the ibeacon api under the hood so I still need you to get
called when we enter region :)
On Wed, Jun 17, 2015 at 3:37 PM, Johannes Stein<EMAIL_ADDRESS>wrote:

Merged #14
https://github.com/geniuxconsulting/react-native-ibeacon/pull/14.
—
Reply to this email directly or view it on GitHub
https://github.com/geniuxconsulting/react-native-ibeacon/pull/14#event-333693178
.


Itinerary Team Lead (EPIC)

We need to include the concept of a team lead for an itinerary. This will be one team member, marked as the team lead. We will need to track this in the database and provide a UI to enable assigning a team lead, change the assignment and potentially remove the assignment.
Team leads will be able to

Can close out requests assigned to their itinerary
create manual requests within their itinerary

This EPIC will be broken down into the following work items:

[x] Database changes to persist team lead data - Included in #1813
[x] Ability for Org Admin to set a team lead on an itinerary - Included in #1813
[x] UI to highlight the team lead within the itinerary team member list - Included in #1813
[x] Ability to change the team lead - Included in #1813
[x] Ability to remove the team lead (leaves the itinerary without a team lead) - Included in #1819
[ ] Appropriate messaging (via email/sms) to notify volunteer once they are made a team lead - Included in #1820
[ ] Team lead view itinerary details for any itinerary they lead - Included in #1821
[ ] Team lead view requests details from any itineraries they lead - Included in #1822
[ ] Team lead can edit request details (within any itinerary they lead) - Included in #1823
[ ] Team lead can close requests (within any itinerary they lead) - Included in #1788
[ ] Team lead UI to enable creation of requests (within any itinerary they lead) - Included in #1824

@stevejgordon
I've been looking at some of the broken down work items.  Several have

I'm working on a pre-requisite PR to support easier authorization of such actions

Has the pre-requisite PR been completed?  If so, I would to take a crack at them 😄.

There is a PR in which I hope sets many of these up. Just waiting on a review since its a largish change. Then we can release many of these sub items.
Sent from my Windows Phone

From: Gary<EMAIL_ADDRESS>Sent: 26/03/2017 18:19
To<EMAIL_ADDRESS>Cc: Steve<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [HTBox/allReady] Itinerary Team Lead (EPIC) (#1787)
@stevejgordonhttps://github.com/stevejgordon
I've been looking at some of the broken down work items. Several have
I'm working on a pre-requisite PR to support easier authorization of such actions
Has the pre-requisite PR been completed? If so, I would to take a crack at them 😄.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/HTBox/allReady/issues/1787#issuecomment-289299816, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADf8b7J1HIY1aBRyOi4S-232J-gG1AW0ks5rpp4egaJpZM4L4Mf2.

@stevejgordon Are you ready to release any of these sub items yet? 😄

@c0g1t8 The foundation for the authorisation is in. I've implemented some of the bits around authorising event managers, so the issues related to #1803 may be possible to start picking up now. I've nearly got the next step done which is around campaign managers. Once that's finished up a bit further I can get in the bits around doing the auth for the team leads.

@c0g1t8 Started work on the authorizable Itinerary and Request bits which will then enable the checks in the controllers around doing this. Will get this wrapped into a PR as soon as possible.

@stevejgordon I'll start familiarizing myself with the issue related to #1803. 😄  Been reading up on resource base authorization and was looking to apply what I learned.

I went a little off course with the ItineraryController🤕. I originally implemented the authorization for its methods based on AuthorizableEvent. Once I completed my implementation I rediscovered #1787. It's apparent that the work I did could have/should have used an AuthorizableItinerary. This would provide some uniformity in implementation.

I'm creating a WIP PR based on this.  Even if we don't use it, it could be the basis for using AuthorizableItinerary.

@stevejgordon I've almost completed reworking the ItineraryController to follow the pattern used for the EventController.  Some of this work will overlap the broken down work items.
@tonysurma Please assign me 😄

@c0g1t8 Do you know which you expect to touch as part of this. In this case each is broken into it's own issue so would be good to assume specific ones. I'm also looking at pickup up some sub items of the epics but don't want to tread on any work you've started.

@stevejgordon I've been updating the ItineraryController as part of the working on the Event Managers Epic #1803.  There is a cascading effect since I needed to make changes to how authorization worked in the ItineraryController to make it work for and Event Manager.
After some thought, I'm proposing that I check these changes in with #1803 since they are a consequence of that issue.  I need to review the changes one more time before doing that.

@stevejgordon While working on #1803 many of the sub-items in this issue were also addressed.  PR #1970 included the addition of the new authorization model to the ItineraryController.
The following should/could be closed:

Team lead view itinerary details for any itinerary they lead - Included in #1821
Team lead view requests details from any itineraries they lead - Included in #1822
Team lead can edit request details (within any itinerary they lead) - Included in #1823
Team lead can close requests (within any itinerary they lead) - Included in #1788
Team lead UI to enable creation of requests (within any itinerary they lead) - Included in #1824

At the moment, the Team Lead can manage team membership including changing the Team Lead which I don't think is a good idea.  The Team Lead should only be able to add and remove non-team lead members.  If you concur, I can create a PR for that.

Thanks @c0g1t8


performance issue

when i open vs code it taking lots of time to open and its performance has also decreased. working very slow

Are you using McAfee antivirus? If so please see https://github.com/microsoft/vscode/issues/178962
/needsMoreInfo

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!


lathe for stick manufacture?

howabout the lathe to make sticks via machine?

The lathe is a simple input/output device isn't it? just put stuff in the input, provide power, get stuff in output? I'll start working on that, then.

https://github.com/belathus/Wanderlust-Renewed/commit/aa42c0814430204805700dbd66e7b058a763b2b3

Though, I admit that a lathe would probably be more appropriate for making tool rods. I guess it could be an interesting way to make TiC tool rods. Differentiating between tough tool rods and normal tool rods might be tough.


rpn_loc_loss  is nan, fast_rcnn_loc_loss is 0.0

I have changed the database and converted to tfrecords . when i run it for minutes,  fast_rcnn_loc_loss  become 0.0  rpn_loc_loss  become nan.
``

for t_w = np.log(w/reference_w), I have check  picture ,w >0 .So I think reference_w is wrong, I don't know how to modify it .Ask for your help.

I speculate that it may be a problem with the data set. You can check if the data read from tfrecord is correct. @Llq201809

Thanks for your reply very much. I find error in my data set. Now it works . @yangxue0827

@Llq201809 in my case, fast_rcnn_loc_loss=0.0. I am using a custom dataset. How did you find the error in your dataset? My dataset looks fine.

I have writed a print function to delete error coordinate when translate dataset to VOC format. For example,if Xmin<Xmax or Ymin<Ymax，print image then delete it manually. ------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年8月30日(星期五) 下午5:57
收件人<EMAIL_ADDRESS>抄送: "Llq201809"2996816323<EMAIL_ADDRESS>主题: Re: [DetectionTeamUCAS/Cascade-RCNN_Tensorflow] rpn_loc_loss  is nan,fast_rcnn_loc_loss is 0.0 (#8)
@Llq201809 in my case, fast_rcnn_loc_loss=0.0. I am using a custom dataset. How did you find the error in your dataset? My dataset looks fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Sorry，it should be Xmax-Xmin<=0 or Ymax-Ymin>=0，delete it. ------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年8月30日(星期五) 下午5:57
收件人<EMAIL_ADDRESS>抄送: "Llq201809"2996816323<EMAIL_ADDRESS>主题: Re: [DetectionTeamUCAS/Cascade-RCNN_Tensorflow] rpn_loc_loss  is nan,fast_rcnn_loc_loss is 0.0 (#8)
@Llq201809 in my case, fast_rcnn_loc_loss=0.0. I am using a custom dataset. How did you find the error in your dataset? My dataset looks fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


TypeError: PathParser is not a constructor

<EMAIL_ADDRESS>
I just upgraded from version 3.x.x to 4.2.0, and got the above error. And makes sense since, in 4.x.x, require('path-parser') returns an Object:
const PathParser = require('path-parser');

> PathParser
{ Path: { [Function: Path] createPath: [Function] },
  default: { [Function: Path] createPath: [Function] } }

So, if used in Node, const PathParser = require('path-parser').default is required. But the CHANGELOG says nothing about it.

default export will be removed in next major (#42)


npm package is empty

➤➤ npm i emojify.js
<EMAIL_ADDRESS>node_modules/emojify.js
➤➤ tree node_modules/
node_modules/
└── emojify.js
    ├── LICENSE-IMAGES.md
    ├── LICENSE.md
    ├── README.md
    └── package.json

1 directory, 4 files

Thanks for pointing that out, clearly something's gone wrong with package.json, I'll do another release when I get home

https://github.com/hassankhan/emojify.js/blob/master/.npmignore#L1

I've published a new version on NPM, could you try it out and let me know? It seems to work for me

@hassankhan Confirmed :)


ScriptDom.TSql160Parser fails to parse simple T-SQL expression

Microsoft.SqlServer.DacFx Version 161.6374.0
Reproduced on both .NET 6.0 and .NET 7.0
Windows 11

The Microsoft.SqlServer.TransactSql.ScriptDom.TSql160Parser fails to parse the following expression.
We noticed the issue on a much more complicated and realistic expression but we simplified the repro to the following minimal expression.
Repro:
using Microsoft.SqlServer.TransactSql.ScriptDom;

var parser = new TSql160Parser(true); //sql server 2022 parser
IList<ParseError> errors;

var expr = @"
(
    SELECT 1
    WHERE (IIF(1 > 0 AND 2 > 1, 1, 0)) = 1
)";

var res = parser.ParseExpression(new StringReader(expr), out errors);

if (errors?.Count > 0)
    Console.WriteLine(errors.First().Message); //ERROR!!!!    Incorrect syntax near ).

To prove that the given expression is definitely a valid one, you can simply execute the following statement in SSMS and see that SQL SERVER executes the query succesfully.
SELECT
(
    SELECT 1
    WHERE (IIF(1 > 0 AND 2 > 1, 1, 0)) = 1
)

Could this be addressed with the release of the sql server 2022 parser?

Hi @clement911, this expression worked
var expr = @"
(
SELECT 1
WHERE IIF(1 > 0 AND 2 > 1, 1, 0) = 1
)";

That's right. The parser gets confused by extra wrapping parentheses so hopefully the code fix is not too hard?
Of course we wouldn't write such a simple expression manually but our actual expression is much more complicated. Also, sql is sometimes autogenerated or provided by a user, in which case we have no control over it.

Could we please get an update on this bug?

@clement911 Apologies for the delay, would update you whether it would be included in the next release. Thank you

@SeenaAugusty we really look forward to it.
By the way, if you would open source the parser, we'd be happy to spend some time working on such issues

@clement911 we are planning to make it open source in near future :)

@SeenaAugusty this is great news that you will open source this project 😄
However, I was also told the same thing.... 2.5 years ago.
Could you share the (rough) time line of when you will be open sourcing this project?

Hi, any updates on this issue?

@SeenaAugusty any news on the open sourcing?
Bugs remain open for months or years so the only hope I see of them getting fixed is if you open source the code.

While the time it takes to bring ScriptDOM to open source may be frustrating, we'll keep those conversations primarily over at https://github.com/microsoft/DacFx/issues/101

@dzsquared  could you give  a quick update there?
Are you still working towards open sourcing the ScriptDom?


Render the UI of the tracks fetched using Spotify API

Currently, the UI is just a simple ListView like shown below 👇🏻

There is a lot of scope of improvement here, like working on the font style, the cover image displayed, etc.

@DinuBotan you might want to take a look at this 😺

Sure I'll work on this. @NoahCardoza please assign this to me and @shravani05

@DinuBotan make sure to look into those squashed images! I left some comments about how to fix them in @Sargam-Agarwal initial PR. We decided to break it into a new issue to make more available issues.

https://github.com/MLH-Fellowship/prep-project-4.1.4/pull/27#discussion_r756284846
Here is the direct link of what exactly Noah is talking about 👍


Transparent caching of parsed data

Sonarlog should probably cache parsed data in a binary format, transparently.  Currently, parsing the csv takes something like 30%-50% of the running time of eg sonalyze uptime, running on 30 days of data, and this is after warming up any disk cache with a couple of runs.  If we want to run analyses frequently because we want fresh data then caching will be helpful in reducing the load.  A cache could be local to the user that runs the analysis, and could be invalidated by either capacity or by the raw data having a newer timestamp than the cache or for that matter by periodically or randomly discarding cached data - the cache will be repopulated as needed, and over time unused data will disappear.

I think this is much more interesting now that we can run queries on server.  Consider (if you have the access rights):
http://<IP_ADDRESS>:8087/profile?cluster=ml&job=563661&fmt=html,gpu&from=2023-11-01

This looks at 45 days of data and takes quite a few seconds to run.  A large part of that time is spent reading and cleaning up the data, but except for today's data, all those data and the cleanup results are completely static.
The cache could be "owned" by sonalyzed though since there can be many queries running concurrently there still needs to be some kind of coordination.

I'm closing this for the time being, to be reopened if we need it.  Parsing is much, much faster now, and if we do any caching it's going to be in-memory, not on-disk, see #379.


Respect strip_suffix

Codecov Report

Merging #2 (969ec0e) into main (0300fb7) will not change coverage.
The diff coverage is 62.50%.

@@           Coverage Diff           @@
##             main       #2   +/-   ##
=======================================
  Coverage   75.00%   75.00%
=======================================
  Files           1        1
  Lines          12       12
=======================================
  Hits            9        9
  Misses          3        3

Impacted Files
Coverage Δ

src/Test/Tasty/AutoCollect/Utils/Tree.hs
75.00% <62.50%> (ø)

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 0300fb7...969ec0e. Read the comment docs.


Do sites need to be named sequentially?

Hi @r-glennie, thanks so much for the sharing package. I have to run hundreds of multi-year occupancy models and this package makes it super efficient!
One question, I found the condition that sites need to be named sequentially a bit restrictive. Sequentially in the sense that sites need to be labelled from 1 to max(site) without missing any numbers in the sequence.
From line #223 in occu_tmb.R:
# check site data
num <- site_data[, .(max = max(site), n = uniqueN(site))]
if (any(num$max != num$n)) stop("site_data has missing sites or sites are mis-numered: ", num[which(num$max  != num$n,)])

Sometimes, one might decide to remove sites from the analysis, and is then forced to re-label all other sites. It is not a major issue, but I don't completely understand the reason why. I was thinking alternative ways to perhaps write this condition but I couldn't pinpoint the exact problem to prevent. You probably have a better idea of why non-sequential sites are a problem?
Thanks!
Here is a toy example of what I am talking about:
library(dplyr)
library(occuR)

# Parameters for simulating data
psi <- 0.8
p <- 0.9
nsites <- 5
noccasions <- 1
nvisits <- 10

## Name sites sequentially and fit model ##

sims <- data.frame(site = rep(seq_len(nsites), each = nvisits), # this labels sites sequentially
                   occasion = 1,
                   visit = rep(seq_len(nvisits), times = nsites),
                   occu = rep(rbinom(nsites, 1, psi), each = nvisits)) %>%
    mutate(obs = rbinom(nrow(.), 1, psi*p*occu))

site_data <- sims %>%
    group_by(site) %>%
    summarize(occasion = unique(occasion)) %>%
    data.table::as.data.table()

visit_data <- sims %>%
    data.table::as.data.table()

# Fit simple model (works well with all sites)
mod <- occuR::fit_occu(list(psi ~ 1, p ~ 1), visit_data, site_data)

## DON'T name sites sequentially and fit model ##

# Remove one site
site_data <- site_data %>%
    filter(site != 2)

visit_data <- visit_data %>%
    filter(site != 2)

# Fit simple model (doesn't work, because there is no site number 2)
mod <- occuR::fit_occu(list(psi ~ 1, p ~ 1), visit_data, site_data)

Thanks @patchcervan for highlighting this. I have a tendency to be prescriptive with the inputs I expect from users simply to try to avoid errors. In a previous version of the package, I think I needed sites to be sequentially numbered, but I don't think this is required for the current version. I decided to keep it because I thought it might prevent users accidently losing sites but I can see how it would be annoying to enforce this, so I have removed it in commit ef0e0069fbcfa780679b21e10053dfb9146b6685.
Hope you find the package useful and please do keep bringing up issues!

Thanks! I hope it doesn't cause trouble :)

I hope so too! I had a look through the code and ran some tests / examples and there was no issues.


Breaking: Registration Options require Client Capability during creation

Registration Changes
The 3.16 specification defines the SemanticLegend in such a way that the client produces a list of supported tokens and the server must return the tokens it supports and the index order it will use.
Today we get the registration options at registration of a handler, but this is typically before we have started communicating with the server.
This change adds a new interface IRegistrationOptions<TOptions, TCapability> and all interfaces have been updated to implement this interface if they have both a client capability and a server registration option.
Abstract Handlers Registration Options
The abstract base classes by the above change now have a new method that must be implemented.
protected internal abstract TRegistrationOptions CreateRegistrationOptions(TCapability capability);
The base handler then caches the resulting value so this method is only ever called once.
Existing implementations of GetRegistrationOptions can be replaced with CreateRegistrationOptions.
Abstract Handlers
All the abstract handler base classes have been renamed to have a Suffix of "Base" if there was not one there before.
The fix for this is simply to make sure the Base suffix has been applied.
Feature Specific Files
This is not a breaking change, the goal was to make sure that namespaces did not change, if there is a miss let me know.
Any classes related to the Request, Response, Capability and Registration Options have been moved into a XyzFeature.cs file.  This will help reduce the number of overall files in the repo, as well as hopefully with discoverabiliy.  More importantly this make it easier to create new features, as all the components for a given feature will be in the same file.
TextDocumentSyncRegistrationOptions Added
The IDidXyzTextDocument handlers have been updated to have specific named options, and a master options class TextDocumentSyncRegistrationOptions has been added.  You provide the TextDocumentSyncRegistrationOptions and all the other named options can be implicitly created from it.
Source Generation
Source Generation has been refactored to be a little more flexible and better organized (it's not prefect but better).
Some documentation has been added to document the attributes and their usage.  These should available to consumers to also use themselves, please let me know of any bugs you might encounter with them.

Docs link for this PR: (The above description will be rolled into the release notes).
https://github.com/OmniSharp/csharp-language-server-protocol/blob/feature/2-registration-options/docs/source-generation.md


[iOS] Is this plugin not working with React Native Navigation Wix?

Without Viewpager

With Viewpager

As shown in the screenshot, after I use the viewpager, my bottom tabs navigation from react native navigation wix has disappear. Anyone has any idea or facing the same issue?

yes react-native-navigation Version v6 in use react-native-community/viewpager conflict bottomTabs disappear

@skyliwq Is there any workaround for this issue? Is this issue with react native navigation or viewpager?

Linked issue https://github.com/wix/react-native-navigation/issues/6037

seems like this problem was gone when I updated RNN 6.4.0 and viewpager 3.3.0

In of any problem, please reopen an issue


xCode shell script doesn't run

Hello, I searched everywhere for informations but without success.
I have a project in xCode with SwiftProtobuf (1.27.1) pod installed and would like to run a build phase script:
    cd MyProject/Resources/
    protoc --swift_out=../../MyProject/Models/ Models.proto

so that model would be created. But protoc is not found or for some reason can't be run from this script. Does anyone know why this would not work?
if I run the command from terminal it works as it should.
I am using xCode 15.4 on macOs 14.5

It's mentioned in the Getting Started you need to installed it from the protobuf repo or if you use homebrew to install the plugin for this library that will also install protoc.

@thomasvl I have installed it with homebrew, like I said, I can run it in my terminal, I just can't run it from xCode shell script

Then odds are it isn't on your PATH when Xcode is spawning the action.
However you've configured your environment, you probably are modifying your PATH such that it is there for the Terminal.app, but not things spawned from Gui apps.

@thomasvl could you explain a bit more please, since this is my PATH
 "${PATH//:/\n}"
/opt/homebrew/bin
/opt/homebrew/sbin
/usr/local/bin

and this si where to protoc is
/opt/homebrew/bin/protoc

When you dumped PATH, was that from the same Xcode build phase that tries to invoke protoc? Or something you did in Terminal.app?  You need to examine the environment Xcode is provided/providing when invoking your custom build phase.
Note: This isn't really a problem specific to this library; it's something about your setup and install/usage of homebrew. So you might be better off looking for help on a forum specific to homebrew. I think you'd want to ask there about how to ensure what you've installed via homebrew is available to Xcode build phases. I personally don't use homebrew, so don't have any experience with it.

@thomasvl got my answer or should I say, found the source to my problem 😓 , thank you


Merge the new home page to the build branch

The old team page should be removed, all references to it must be removed, etc


Fix broken Julia compat entries for Cairo_jll

Currently, the Compat.toml file for Cairo_jll.jl is broken.
For example, the version 1.16.0+3 is duplicated in Compat.toml.

I'm going to merge this now because it's blocking some other work.
@staticfloat and @giordano please take a look, and please revert this if I was mistaken.

Looks good to me


Added default values to all Sass variables

I've also namespaced all variables. This allows people to directly import the scss file and adjust the colors, etc without needing to override them in their CSS file later on.

Lovely, thanks!


Update the F-Droid version

Hi
I installed Gear Shift from F-Droid, works great. But the version on F-Droid is 1.0 added 26/9/2015. The program tells me to update to 1.2 version, but the apk that it downloads does not work, I guess because the signature differs from the one from F-Droid. So could you or whoever is in charge update the F-Droid version.
There is a minor bug, but it is already solved in the newer version so I am waiting for an update before doing anything else.

Looks like the versionname has been upped, but the versioncode is still at 84. So as far as Android (or fdroid) is concerned , no new version was released.

So what is the solution?

Bump the versioncode to 85 (or anything higher than what it is now), move the tag to point to this commit. See https://developer.android.com/studio/publish/versioning.html

@krt16s Does f-droid require that an apk be built, or does it just monitor the git repo for those changes?

It monitors the repo. I can even bump the versioncode on our side, as long as i can safely assume the versioncode I might pick will not be used for another upstream version :)

Nah, I'll change it directly through the github editor


Add Ubuntu 20.04 development setup instructions to readme.md

This pull request adds local development instructions for Ubuntu 20.04

I wil test the commands in the readme before merging this branch


Document framework version defaults

With tensorflow version and PyTorch version, etc optional we should document their (implicit) default values.
The defaults are implicit atm as they are not defined here, but in the collection repo we use default versions for testing:
https://github.com/bioimage-io/collection-bioimage-io/blob/08238241e4bbea60f8a970f2aac8755621d7944b/scripts/static_validation.py#L105
Imho we should consider making the respective version fields mandatory.

all framework versions in model 0.5 are mandatory


Stylesheets not loading in ie11

Stylesheets were loading inconsistently in ie11
I found that removing the line where the rel is set to preload solved the issue

Preload isn't supported by IE11 (link) so I don't think MUI is the source of this issue but let me know if that isn't the case.

The rel attribute still gets set to Preload though (shown when I inspect element in ie11) and then the style rules from that style sheet are not applied

Sorry I think I was using an old version of loadjs =\

Can you describe your setup? I tested LoadJS in IE11 running on Win8.1 and it isn't setting rel to "preload":

@jesserosenfield There's a github message in my inbox from you saying that you were using an old version of LoadJS but I don't see it here. Can you confirm that you're still seeing this issue?


fix: distributed online covariance samples fix

Description
Pr contains the fix for nightly job + removing definition of partial compute(comm version)

Nightly job: https://intel-ci.intel.com/eed705c2-f813-f15f-b29e-a4bf010d0e2e

/intelci: run

Changes resolve failures - but is non-preview finalize_compute compatible with spmd?

Changes resolve failures - but is non-preview partial_compute compatible with spmd?

Hi! We use batch(no distributed partial_compute on each node, and merge it only in finalize step) it means that in partial_compute we dont use comm functions


testing etc

I was thinking about how we could test and I thought about the idea of mocking curl_fetch_memory.
Check this out:
curl_env <- environment(curl::curl_fetch_memory)
old_curl_fetch_memory <- curl::curl_fetch_memory
unlockBinding(quote(curl_fetch_memory), curl_env)
assign("curl_fetch_memory",
       function(...) list(
                       response_code = 200,
                       content = charToRaw("Hello Curled!")),
       envir = curl_env)
a <- curl::curl_fetch_memory("http://whatever")
print(a)
#> $response_code
#> [1] 200
#>
#> $content
#>  [1] 48 65 6c 6c 6f 20 43 75 72 6c 65 64 21
print(rawToChar(a$content))
#> [1] "Hello Curled!"

assign("curl_fetch_memory",
       old_curl_fetch_memory,
       envir = curl_env)

lockBinding(quote(curl_fetch_memory),
            curl_env)

a <- curl::curl_fetch_memory("http://whatever")
#> Error in curl::curl_fetch_memory("http://whatever"): Could not resolve host: whatever

Created on 2020-07-02 by the reprex package (v0.3.0)

Some more relevant discoveries:

assignInNamespace()
testthat::with_mock()


Development: Add Theia configuration

This PR implements changes requested by the ITG in this issue.
Currently, the ongoing integration of Theia into Artemis requires some new configuration values. This PR adds the theia_base_url to prod and env templates and the defaults.
@Hialus are the changes in artemis.env.j2 sufficient or are there other changes necessary in some, e.g., Dockerfile?

What's the status on this PR? @bensofficial


fix: ci version

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

Comparison is base (b66aabd) 36.56% compared to head (d3d7608) 36.56%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #799   +/-   ##
=======================================
  Coverage   36.56%   36.56%
=======================================
  Files          36       36
  Lines        4365     4365
=======================================
  Hits         1596     1596
  Misses       2620     2620
  Partials      149      149

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


Fix performance issue

What
The solution right now in master and 4-immersion-improvements is very jagged and laggy, which ruins the experience.

UE meeting
Prebuild lighting!
It will be deployed as .exe

Close
Performance better after packaging. May be improved by employing new code principles as Delegates.


newbie question about option names override for arg groups.

Hi, as mentioned in the PR description. I am new to picocli.
I did go through the documentation and didn't find examples of what I was looking for.
class CatalogOptions {
    @CommandLine.Option(names = "--catalog-type")
    String type;

    @CommandLine.Option(names = "--catalog-prop")
    Map<String, String> properties;
}

In the main command, I need to have two instances of this CatalogOptions.
@CommandLine.ArgGroup(
      exclusive = false,
      multiplicity = "1",
      heading = "source catalog options: %n")
  private CatalogOptions sourceCatalogOptions;

  @CommandLine.ArgGroup(
      exclusive = false,
      multiplicity = "1",
      heading = "target catalog options: %n")
  private CatalogOptions targetCatalogOptions;

Is it possible to override the option names of --catalog-type into --source-catalog-type and --target-catalog-type
and --catalog-prop into --source-catalog-prop and --target-catalog-prop in the arg group?
If I am using it wrongly. please suggest to me how to achieve the same without duplicating CatalogOptions?

Hi @ajantha-bhat, thanks for asking!
I don't think what you are asking is possible in picocli; I would recommend just having a separate class with different option names in the annotations.

@remkop: Thanks for the clarification.


Add Medicine Hat College

This PR enables support for students of Medicine Hat College, Canada.

@staa99 Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Initialize Array with array literal

E.g
var a = Array([1,2,3,4]);

Note also no generics type needed, since it can be determined from the type of the array given to the constructor

You can now use one of the following:
var a = Array(&[1,2,3,4]);

or
var a = Array<int>([1,2,3,4]);

Once generic argument inference and auto-referencing work together we can have Array([1,2,3,4]).


feat(examples): update quickstart with new wasi-kv

Feature or Problem
This PR updates the http-hello-world example wits to match the latest wasi-keyvalue example. It shouldn't be merged until wash is released with the host's RC2.
Related Issues
https://github.com/wasmCloud/wasmCloud/issues/1859
Release Information

Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

Surprised this didn't modify the example source. Can we run through manual verification before merging? I know we now have CI for examples but it's ✨ new and might be missing something.

Sure thing @ricochet let me double triple check, I ran through a few in https://github.com/wasmCloud/wasmcloud.com/pull/378 but admittedly I just ran through compilation. We don't have to update any source code here because there's no keyvalue calls yet but people add them through the quickstart


DNS not resolving steamcontent.com correctly

Describe the issue you are having
From inside the DNS container, the correct internal private IP is returned for DNS lookups.  Outside of the container it is returning public IP's.
Lancache is running on an Ubuntu 20 server at IP <IP_ADDRESS>.
From any machine on my nework
dig @<IP_ADDRESS> steam.cache.lancache.net  returns
;; QUESTION SECTION:
;steam.cache.lancache.net.      IN      A

;; ANSWER SECTION:
steam.cache.lancache.net. 600   IN      A       <IP_ADDRESS>

;; AUTHORITY SECTION:
cache.lancache.net.     600     IN      NS      localhost.

This is expected.
dig @<IP_ADDRESS> lancache.steamcontent.com returns
;; QUESTION SECTION:
;lancache.steamcontent.com.     IN      A

;; ANSWER SECTION:
lancache.steamcontent.com. 0    IN      CNAME   origin-tier2.steampipe.steamcontent.com.
origin-tier2.steampipe.steamcontent.com. 0 IN CNAME steampipe-origin-tier2.steamcontent.com.
steampipe-origin-tier2.steamcontent.com. 0 IN A <IP_ADDRESS>
steampipe-origin-tier2.steamcontent.com. 0 IN A <IP_ADDRESS>
steampipe-origin-tier2.steamcontent.com. 0 IN A <IP_ADDRESS>
steampipe-origin-tier2.steamcontent.com. 0 IN A <IP_ADDRESS>

This is unexpected.
To take steps just a little further, if I docker exec -it lancache_dns_1 /bin/bash and then run dig @<IP_ADDRESS> lancache.steamcontent.com it returns:
;; QUESTION SECTION:
;lancache.steamcontent.com.     IN      A

;; ANSWER SECTION:
lancache.steamcontent.com. 5    IN      CNAME   steam.cache.lancache.net.
steam.cache.lancache.net. 600   IN      A       <IP_ADDRESS>

;; AUTHORITY SECTION:
cache.lancache.net.     600     IN      NS      localhost.

Which is the answer I am expecting.
I am trying to figure out why the dns is returning the public DNS resolution instead of the private dns resolution when queried from outside of the container, but from inside the container it returns the correct answer.
How are you running the container(s)
docker-compose.yaml
version: '2'
x-restart-policy: &restart-policy "unless-stopped"
services:
  dns:
    image: lancachenet/lancache-dns:latest
    env_file: .env
    restart: *restart-policy
    ports:
      - ${DNS_BIND_IP}:53:53/udp
      - ${DNS_BIND_IP}:53:53/tcp

## HTTPS requests are now handled in monolithic directly
## you could choose to return to sniproxy if desired
#
#  sniproxy:
#    image: lancachenet/sniproxy:latest
#    env_file: .env
#    restart: *restart-policy
#    ports:
#      - 443:443/tcp

  monolithic:
    image: lancachenet/monolithic:latest
    env_file: .env
    restart: *restart-policy
    ports:
      - 80:80/tcp
      - 443:443/tcp
    volumes:
      - ${CACHE_ROOT}/cache:/data/cache
      - ${CACHE_ROOT}/logs:/data/logs

.env
## See the "Settings" section in README.md for more details
## Set this to true if you're using a load balancer, or set it to false if you're using seperate IPs for each service.
## If you're using monolithic (the default), leave this set to true
USE_GENERIC_CACHE=true

## IP addresses that the lancache monolithic instance is reachable on
## Specify one or more IPs, space separated - these will be used when resolving DNS hostnames through lancachenet-dns. Multiple IPs can improve cache priming performance for some services (e.g. Steam)
## Note: This setting only affects DNS, monolithic and sniproxy will still bind to all IPs by default
LANCACHE_IP=<IP_ADDRESS>

## IP address on the host that the DNS server should bind to
DNS_BIND_IP=<IP_ADDRESS>

## DNS Resolution for forwarded DNS lookups
UPSTREAM_DNS=<IP_ADDRESS>

## Storage path for the cached data
## Note that by default, this will be a folder relative to the docker-compose.yml file
CACHE_ROOT=/mnt/cache/lancache

## Change this to customise the size of the disk cache (default 2000000m)
## If you have more storage, you'll likely want to increase this
## The cache server will prune content on a least-recently-used basis if it
## starts approaching this limit.
## Set this to a little bit less than your actual available space
CACHE_DISK_SIZE=3000000m

## Change this to allow sufficient index memory for the nginx cache manager (default 500m)
## We recommend 250m of index memory per 1TB of CACHE_DISK_SIZE
CACHE_INDEX_SIZE=750m

## Change this to limit the maximum age of cached content (default 3650d)
CACHE_MAX_AGE=3650d

## Set the timezone for the docker containers, useful for correct timestamps on logs (default Europe/London)
## Formatted as tz database names. Example: Europe/Oslo or America/Los_Angeles
TZ=America/Detroit

DNS Configuration
The DHCP configuration in my Firewalla is configured to hand out <IP_ADDRESS> as the only name server.
Output of container(s)
Let me know if there is any specific output you are interested in.

Turns out my Firewalla router was hijacking all DNS lookups on the network with their "DNS Booster" feature.  I turned that off and the cache started working as expected.


Add version disclaimer to README

Explain that PROCESS v3.x is not stable and even minor releases are not backward compatible. Version 4 will enforce such compatibility.

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

Project coverage is 29.54%. Comparing base (f834c69) to head (229283b).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3436   +/-   ##
=======================================
  Coverage   29.54%   29.54%
=======================================
  Files          78       78
  Lines       19143    19143
=======================================
  Hits         5656     5656
  Misses      13487    13487

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


Renamed improperly named migration

Closes #574

Successful PR Checklist:

[ ] Tests

[x] (not applicable?)

[ ] Documentation

[x] (not applicable?)

https://pypi.org/project/procrastinate/0.24.1/


Fix for Issue 98

Fix For Calling device_interface with itype=0 Returns Object without type attribute
Changes if itype else None to if itype is not None else None  to prevent itype = 0 to evaluate to false

Hello @Haeki!
Thanks for the contribution. I realized this mistake when fixing #91. I've patched it and pulled it into develop through #97. Would you mind giving it a review? You'll see I opted to remove the optional as this was change in the upstream NetBox project to a required field. Thanks!

I'm closing this as a duplicate, but please feel free to continue to contribute. I really appreciate all the support I can get.


Add dns_notify to dns class and dns::zone define

In a situation with a single master and multiple slaves, the slaves will end up attempting to notify other slaves of updates to the zones.  Messages like this will appear
Jan 20 10:53:33 HOSTNAME named[1628]: client SLAVE_IP#52691: received notify for zone 'DOMAIN'
Jan 20 10:53:33 HOSTNAME named[1628]: zone DOMAIN/IN: refused notify from non-master: SLAVE_IP#52691

It may be worth making the value for notify automatically no when zonetype is slave, but wasn't sure if such an assumption would be too much.

:+1: looks OK to me, and I'd be fine with changing the default to "no" for slaves.

I've updated PR to set notify to "no" for slaves, if the dns_notify parameter is left undefined.

Looks good :+1:

@domcleal I've updated PR to use validate_re in both dns class and dns::zone defined type.
@ekohl I have been using $_ on numerous modules to denote "private" variables.  So far it has not caused me problems in 3.6.x or 3.8.x.  I run many of those modules through future parser and Puppet 4 unit tests and have seen no issues.  If the use of $_ is a problem for Puppet, I'd very much like to know as I'd have to update most of my modules, as well as this PR.

@treydock like I said, it was a vague recollection. In that case I trust you on it since it's trivial to change if it does turn out to be a problem somewhere.
:+1:

merged, thanks @treydock!


Completeness of a tern scan

Describe the Feature
This feature would give you a summary at the end of the scan telling you the completeness of the scan, i.e. how big of a percentage of the files in the container can be attributed to a detected package in the bill of materials, and a list of the files that could not be associated to any package.
Use Cases
This feature would give the user more assurance about how much they can "trust" the scan results.
Implementation Changes
Tern would first need the functionality to extract file info for packages to know what files were installed by which package. The completeness result would also need to be presented in the final output in some way.

I like the idea of expressing a “completeness %” of a scan but I think there is some ambiguity and room for clarification in that definition. I would think of completeness as the number of files/packages found where an associated license was detected in the file/package. It sounds like you are defining the completeness as a percentage of the files that belong to a package where the license was reported in the SBoM? What about files that have file-level licenses different from that of the overall package to which they belong? If you are not performing file-level scanning, the completeness percentage would incorrectly reflect the percentage of files covered by the detected SBoM if it just assumed that the file had the same license as the package that installed it. It sounds like your proposal is only concerned with associating a file with the package that installed it and counting that as “complete” for finding the license without actually looking at the file-level license. Am I understanding that correctly? I’m curious how you see handling this scenario where a file-level license differs from the package license. I would have a similar question about files that do not explicitly state a file-level license as well.

We don’t currently have file-level scanning (i.e. looking at the contents of a file to find the license statement inside the file) enabled natively in Tern. File scanning is something that can be accomplished in Tern using the Scancode plugin. When you say, “Our idea is to scan all files in the container and associate the installed packages with the discovered files” are you planning to look at the file-level licenses of each individual file with Scancode, or just scan for the existence of a file natively in Tern?

I would start the implementation for your proposal by first adding functionality to extract file info for packages. There was a contributor working towards this a few months but the PR was eventually closed before it was merged.

I’m not sure exactly how you are envisioning representing the association between installed packages and the files that they install, but the SPDX tag:value spec has ways to do this nicely. Or, if you see yourself creating a new type of output report with a more visually appealing presentation, it may be a good candidate for its own custom report format plugin.

I like the idea of expressing a “completeness %” of a scan but I think there is some ambiguity and room for clarification in that definition. I would think of completeness as the number of files/packages found where an associated license was detected in the file/package. It sounds like you are defining the completeness as a percentage of the files that belong to a package where the license for the package was reported in the SBoM? What about files that have file-level licenses different from that of the overall package to which they belong? If you are not performing file-level scanning, the completeness percentage would incorrectly reflect the percentage of files covered by the detected SBoM if it just assumed that the file had the same license as the package that installed it. It sounds like your proposal is only concerned with associating a file with the package that installed it and counting that as “complete” for finding the license without actually looking at the file-level license. Am I understanding that correctly? I’m curious how you see handling this scenario where a file-level license differs from the package license. I would have a similar question about files that do not explicitly state a file-level license as well.

We rely on the correctness of the package managers to indicate if some files have different licenses than the top level license of the project. With this completness % we are measuring the completness of Tern-s scan and not the correctness of the package managers.

We don’t currently have file-level scanning (i.e. looking at the contents of a file to find the license statement inside the file) enabled natively in Tern. File scanning is something that can be accomplished in Tern using the Scancode plugin. When you say, “Our idea is to scan all files in the container and associate the installed packages with the discovered files” are you planning to look at the file-level licenses of each individual file with Scancode, or just scan for the existence of a file natively in Tern?

No we just try associate every file with a detected package. To have correct file scanning result with scancode we would need the source code of all the installed packages. This is not our plan with this feature.

I would start the implementation for your proposal by first adding functionality to extract file info for packages. There was a contributor [working towards this ](https://github.com/tern-tools/tern/pull/573)a few months but the PR was eventually closed before it was merged.

Thanks for the hint. Do you think that #573 would be a good base to implement our idea?

I’m not sure exactly how you are envisioning representing the association between installed packages and the files that they install, but the SPDX tag:value spec has ways to do this nicely. Or, if you see yourself creating a new type of output report with a more visually appealing presentation, it may be a good candidate for its own [custom report format plugin](https://github.com/tern-tools/tern/blob/master/docs/creating-custom-templates.md).

Our first idea was just to output a completness percentage and a list of files what are not associated with any package, but as a next step a full report on file and package associations could be also a good idea.

We rely on the correctness of the package managers to indicate if some files have different licenses than the top level license of the project. With this completness % we are measuring the completness of Tern-s scan and not the correctness of the package managers.

I'm not sure we can rely on package managers that way. Tern uses the package manager to find licenses associated with each package at the package level. Tern does not currently rely on package managers to check for licenses at a file level and most do not do this by default. My concern is with the implications of the word "complete" and it being just a simple percent. According to your suggestion of calculating % complete as "files associated with a package," a file being counted as part of the "% complete" would indicate that no further investigation of that file is required simply because the license for the file has been "reported" according to the package that installed it. But in the case where a file has a different license than the package that installs it, this is false and it would be misleading to count that file as part of the % complete if we are not reporting file-level licenses. Most of the time, I suspect a file installed by a deb or rpm is going to have the same licenses as the package, but we cannot be certain of this until we inventory licenses at a file-level.
It could be that the "% complete" as you are suggesting is too simple a metric to be helpful here. Maybe there is a slightly more detailed way we can represent the information you are needing to see. Another example where the percentage complete might be over simplistic and misleading: Say you have 99 small text files that are clearly licensed and belong to a package in your container but if you also have a 300MB binary pulling in content from other projects that doesn't belong to any project…is Tern's scan 99%? Technically, 99% of the files in the container could be be attributed to a detected package, but the 1% binary blob that can't carries significantly more weight compliance-wise.
I think there is a valid user story here and would like to find something that satisfies your use case but think more discussion is necessary :)

Thanks for the hint. Do you think that #573 would be a good base to implement our idea?

Yes, this would be a great place to start until we agree on the output style/implementation details for the "completeness" metric we are discussing above. This work on #573 would also incorporate the files and their associated metadata into Tern's data model which would make it easier later to gather package/file relationships later down the road. I would loop the original author, @PrajwalM2212, in to this. He might have some ideas about the best way to get started here.

Sorry for not responding to this earlier.
My only issue with associating "completeness" to "tern scan" is that there are some files that are not associated with a package that can be installed independently. Think for example of the Go programming language where installation is basically downloading the binary off the internet. In this case the "package" and the "file" are the same thing. Another examples are config files, install scripts, and embedded metadata. You will never get 100% completeness in this case.
However, it looks like what you are looking for is a confidence percentage. This is a more complicated measure than "number of files we can associate with a package". I still haven't figured out how to calculate this although it is something that users have asked for. If you have any ideas on how to calculate this I'd love to take a look!

@nishakm I agree that a confidence percentage would be a better way to do this and that my approach was a bit too simplistic. Unfortunately I don't have time to work on this anymore, so I will close my pr for now.

@yannjor No worries. The confidence score is something I think the whole compliance tooling community is figuring out anyway. It really is hard to tell unless you actually look at the supply chain manually or if the supplier says that's what the license is and the supplier has a track record of providing accurate information. I'm still looking for suggestions :)


sigrok-cli: 0.7.0 -> 0.7.1

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/sigrok-cli/versions.
meta.description for sigrok-cli is: '"Command-line frontend for the sigrok signal analysis software suite"'.

Checks done (click to expand)

built on NixOS
/nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1/bin/sigrok-cli passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 0.7.1 with grep in /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1
directory tree listing: https://gist.github.com/664f52a10ff6e77e29cacad5904be8d1
du listing: https://gist.github.com/94c4a212c10cbc4b6c19589408c4f51b

Outpath report (click to expand)

Outpath difference report
3 total rebuild paths
1 package rebuilds
1 x86_64-linux rebuilds
1 i686-linux rebuilds
0 x86_64-darwin rebuilds
1 aarch64-linux rebuilds
First ten rebuilds by attrpath
sigrok-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A sigrok-cli https://github.com/r-ryantm/nixpkgs/archive/dc29fb505731a2a5227dbcb1ff6cfcb2ca72afdc.tar.gz

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

cc @bjornfor for testing.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: sigrok-cli
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: sigrok-cli
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1
shrinking /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1/bin/sigrok-cli
gzipping man pages under /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1/share/man/
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1/bin
patching script interpreter paths in /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1
checking for references to /build in /nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1...
/nix/store/fq4m9h4irfbd1vd7g2cy249paw9awc4d-sigrok-cli-0.7.1

Success on aarch64-linux (full log)
Attempted: sigrok-cli
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1
shrinking /nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1/bin/sigrok-cli
gzipping man pages under /nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1/share/man/
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1/bin
patching script interpreter paths in /nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1
checking for references to /build in /nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1...
/nix/store/ddlljlxmgz4qdmwxjn80ij4f4szh1mif-sigrok-cli-0.7.1


Tweak theme query

Use Number.parseInt since we expect this to be an integer.
@jmervine I think this is a better solution, WDYT?

I'm putting this on hold because I found another issue with that code. I need to first deduplicate the code and then fix it along with the tests.


Cannot record outbound call

I'd like to record outbound calls and I tried these ways:

Events (this works but for incoming calls):

flex.Actions.addListener("beforeAcceptTask", payload => {
      payload.conferenceOptions.conferenceRecord = true;
    });

Param on function create-new-task and call-outbound-join:
record: true

I can only see inbound calls recordings

I did the exact same thing using the add listener action and adding record: true on creat-new-task, call-outbound-join, and also on add-conference-participant but none of those are triggering a call recording for the outbound call.
Please advise.

@prbenson add this line in CustomActions.js:
reservation.call(
reservation.task.attributes.from,
https://${runtimeDomain}/agent-outbound-join?taskSid=${               payload.task.taskSid             },
{
accept: true
record: "record-from-answer"
}
);

@erperejildo thank you!  That did the trick!


Update the Metropolis-within-Gibbs example

Update the Metropolis-within-Gibbs example markdown notebook to be compatible with API changes, as mentioned  in #551.
Included a function that takes the variance of a normal distribution as a parameter and returns a RMH kernel with a normal proposal generator. Also added minor changes to text to keep consistency with updates. I have a couple more thoughts for a few more minor edits, so I'm opening this up a draft PR (also I'm a first time contributor).
potential (nitpicky) edits:

AlgorithmState is mentioned, but is this an actual object in the code base referring to some generic class or type? If not, I think it would be better to refer to a generic state as "algorithm state", so its not confused as something in blackjax.
Change references of blackjax.mcmc.algorithm.init() to just init(), as the former makes it seem like there is an algorithm submodule.

Also, make test reports that 3 tests are failing related to tests/optimizers/test_pathfinder.py. But I don't think it's related to my changes.
Thank you for opening a PR!
A few important guidelines and requirements before we can merge your PR:

[x] If I add a new sampler, there is an issue discussing it already;
[x] We should be able to understand what the PR does from its title only;
[x] There is a high-level description of the changes;
[x] There are links to all the relevant issues, discussions and PRs;
[x] The branch is rebased on the latest main commit;
[x] Commit messages follow these guidelines;
[x] The code respects the current naming conventions;
[x] Docstrings follow the numpy style guide
[x] pre-commit is installed and configured on your machine, and you ran it before opening the PR;
[ ] There are tests covering the changes;
[x] The doc is up-to-date;
[x] If I add a new sampler* I added/updated related examples

Consider opening a Draft PR if your work is still in progress but you would like some feedback from other contributors.

Thanks for your contribution! Actually the change could be a bit more simple, please see the patch that i push


Improve Provider requirement handling

Pull Request Title
Description
Requirement checks are added for docker providers before daytona starts
This PR addresses issue #673
Screenshots
Condition when docker  is not enabled

Condition when docker is enabled

It also detects if docker is not installed

@Tpuljak this is ready for a review 👀

@Philip-21 while I can see what you were going for here, this is not the desired solution.
The requirements will be checked successfully, but we can not hardcode provider requirements into Daytona. The requirements have to be checked by the providers themselves.

I propose that we implement a method in the provider that can return the description of the requirements that will be logged on server startup

This part here means that the Provider interface must have that method and that our providers (e.g. https://github.com/daytonaio/daytona-docker-provider) need to implement that method which the server can then call and disaply it to the user.
Closing this PR. Feel free to reopen it if you decide to implement the required solution. Thanks for understanding.

The pr doesnt have to be closed @Tpuljak  just make it a draft then i can work on the changes you've requested

The pr doesnt have to be closed @Tpuljak just make it a draft then i can work on the changes you've requested

We draft PRs that require smaller changes. Since this PR isn't going in the right direction, I closed it. You're still free to work on this and submit a new one.

The pr doesnt have to be closed @Tpuljak just make it a draft then i can work on the changes you've requested

We draft PRs that require smaller changes. Since this PR isn't going in the right direction, I closed it. You're still free to work on this and submit a new one.

i should still be able to push changes on this pr right even if its closed, so when i am done and it works fine, it can be opened and merged

i should still be able to push changes on this pr right even if its closed, so when i am done and it works fine, it can be opened and merged .

Closing the PR doesn't prevent you from pushing to your branch.

@Tpuljak so i should create a pr in this repo (https://github.com/daytonaio/daytona-docker-provider) that implements the valdiation logic for docker providers, which i will then import and call into  daytona server to display it to the users

@Philip-21 you need to add a new method to https://github.com/daytonaio/daytona/blob/main/pkg/provider/provider.go#L15 and the RPC server and client in that folder. Once you do that, then you can add the necessary implementation in the Docker provider. You'll also need to use GOs replace feature to use daytona from your workspace. (You can find an example of how to do it here https://github.com/daytonaio/daytona/tree/main/pkg/docker#testing)

okay, thank you,

but the way i implemented the validation logic in  this pr, will the method be proper enough for validating the docker provider in the Docker provider library((https://github.com/daytonaio/daytona-docker-provider)) ?

but the way i implemented the validation logic in this pr, will the method be proper enough for validating the docker provider in the Docker provider library((https://github.com/daytonaio/daytona-docker-provider)) ?

It's okay but I suggest you use the docker SDK (example) instead of invoking docker through exec.

but the way i implemented the validation logic in this pr, will the method be proper enough for validating the docker provider in the Docker provider library((https://github.com/daytonaio/daytona-docker-provider)) ?

It's okay but I suggest you use the docker SDK (example) instead of invoking docker through exec.

Alright, thanks i will look through it

Now in the server.go, for me to check these requirements do i import the (https://github.com/daytonaio/daytona-docker-provider) directly for handing the requirement, or i call the method i created from the RPC server ?

You do not import the docker provider. The method is implemented in the provider interface and you need to call it from the provider. (e.g. https://github.com/daytonaio/daytona/blob/main/pkg/provisioner/create.go#L15).
Note: This method will need to be implemented in all our other providers as well.

Alright, thank you

Note: This method will need to be implemented in all our other providers as well.

Please, how do you mean by this, i defined the checkdockerreequirement() in the provider interface already and i have made the function calls in the RPC server and client to his method

and i want to ask based on the architecture it seems the RPC server and client are responsible for performing functions calls from  the Provider interface and some methods in the interface are in various daytona libraries where they get triggered right ?

Note: This method will need to be implemented in all our other providers as well.

you mean i should implment checkdockerreequirement() here ?

you mean i should implment checkdockerreequirement() here in theIproviderManager ?

No, I mean you should add a CheckRequirements() method to the Provider interface and then implement that method in all our providers
https://github.com/daytonaio/daytona-provider-azure
https://github.com/daytonaio/daytona-provider-aws
https://github.com/daytonaio/daytona-provider-fly
https://github.com/daytonaio/daytona-provider-digitalocean
https://github.com/daytonaio/daytona-provider-docker
The task at hand is not only to check docker requirements but to add requirement checks to all providers based on their specific needs.

and i want to ask based on the architecture it seems the RPC server and client are responsible for performing functions calls from the Provider interface and some methods in the interface are in various daytona libraries where they get triggered right ?

The RPC server and client are mandated by https://github.com/hashicorp/go-plugin which we use to interface with the providers.

you mean i should implment checkdockerreequirement() here in theIproviderManager ?

No, I mean you should add a CheckRequirements() method to the Provider interface and then implement that method in all our providers https://github.com/daytonaio/daytona-provider-azure https://github.com/daytonaio/daytona-provider-aws https://github.com/daytonaio/daytona-provider-fly https://github.com/daytonaio/daytona-provider-digitalocean https://github.com/daytonaio/daytona-provider-docker
The task at hand is not only to check docker requirements but to add requirement checks to all providers based on their specific needs.

hmmm....so here is what i had in mind, to start with docker providers, this is the requirement setup code for the docker provider using docker sdk in handling requirements, in https://github.com/daytonaio/daytona-provider-docker
func (p DockerProvider) CheckDockerRequirements() ([]DockerRequirementStatus, error) {
  var results []DockerRequirementStatus
  ctx := context.Background()

  cli, err := docker_sdk.NewClientWithOpts(docker_sdk.FromEnv, docker_sdk.WithAPIVersionNegotiation())
  if err != nil {
  	results = append(results, DockerRequirementStatus{
  		Name:   "Docker installed",
  		Met:    false,
  		Reason: "Docker is not installed",
  	})
  	return results, nil
  } else {
  	results = append(results, DockerRequirementStatus{
  		Name:   "Docker installed",
  		Met:    true,
  		Reason: "Docker is installed",
  	})
  }

  // Check if Docker is running by fetching Docker info
  _, err = cli.Info(ctx)
  if err != nil {
  	results = append(results, DockerRequirementStatus{
  		Name:   "Docker running",
  		Met:    false,
  		Reason: "Docker is not running. Error: " + err.Error(),
  	})
  } else {
  	results = append(results, DockerRequirementStatus{
  		Name:   "Docker running",
  		Met:    true,
  		Reason: "Docker is running",
  	})
  }
  return results, nil
}

so does it mean the checkRequirements() will be something like this
func CheckRequirements()error{
   case "docker":
 requirements, err :=  CheckDockerRequirements()// importing from the daytona docker provider library
 if err != nil {
 	return err
 }

 for _, req := range requirements {
 	if req.Met {
 		allRequirementsMet = true
 		fmt.Printf("%s[0000]     Requirement met: %s\n", infoColor("INFO"), req.Reason)
 	} else {
 		allRequirementsMet = false
 		fmt.Printf("%s[0000]  Requirement not met: %s\n", warningColor("WARNING"), req.Reason)
 	}
 	if !allRequirementsMet {
 		return fmt.Errorf("    Daytona server startup aborted, one or more requirement not met")
 	}
 }

}

Not really.
(p DockerProvider) CheckDockerRequirements()

This method should be called CheckRequirements() ([]RequirementStatus, error) and be implemented in all providers.
Then in daytona
for _, p := InstalledProviders {
 reqs, err := p.CheckRequirements()
...
}

There shouldn't be a special case for the docker provider in daytona. Daytona doesn't know any of the names of the providers nor should daytona import anything from them.

you mean i should implment checkdockerreequirement() here in theIproviderManager ?

No, I mean you should add a CheckRequirements() method to the Provider interface and then implement that method in all our providers https://github.com/daytonaio/daytona-provider-azure https://github.com/daytonaio/daytona-provider-aws https://github.com/daytonaio/daytona-provider-fly https://github.com/daytonaio/daytona-provider-digitalocean https://github.com/daytonaio/daytona-provider-docker
The task at hand is not only to check docker requirements but to add requirement checks to all providers based on their specific needs.

It seems the code i just posted so far, i am not yet on the right track, just to be clear should  the checkrequirement() setup be implmented in the Daytona codebase or each of the main daytona providers
https://github.com/daytonaio/daytona-provider-azure
https://github.com/daytonaio/daytona-provider-aws
https://github.com/daytonaio/daytona-provider-fly
https://github.com/daytonaio/daytona-provider-digitalocean
https://github.com/daytonaio/daytona-provider-docker       ?

It seems the code i just posted so far, i am not yet on the right track, just to be clear should the checkrequirement() setup be implmented in the Daytona codebase or each of the main daytona providers

https://github.com/daytonaio/daytona/pull/1222#issuecomment-2421812300
Does this answer your question?

Not really.
(p DockerProvider) CheckDockerRequirements()

This method should be called CheckRequirements() ([]RequirementStatus, error) and be implemented in all providers.
Then in daytona
for _, p := InstalledProviders {
 reqs, err := p.CheckRequirements()
...
}

There shouldn't be a special case for the docker provider in daytona. Daytona doesn't know any of the names of the providers nor should daytona import anything from them.

Alright, I understand now

so the https://github.com/daytonaio/daytona-provider-docker  will have only for docker
func  CheckRequirements() ([]RequirementStatus, error) {
  var results []RequirementStatus
  ctx := context.Background()

  cli, err := docker_sdk.NewClientWithOpts(docker_sdk.FromEnv, docker_sdk.WithAPIVersionNegotiation())
  if err != nil {
  	results = append(results, RequirementStatus{
  		Name:   "Docker installed",
  		Met:    false,
  		Reason: "Docker is not installed",
  	})
  	return results, nil
  } else {
  	results = append(results, RequirementStatus{
  		Name:   "Docker installed",
  		Met:    true,
  		Reason: "Docker is installed",
  	})
  }

  // Check if Docker is running by fetching Docker info
  _, err = cli.Info(ctx)
  if err != nil {
  	results = append(results, RequirementStatus{
  		Name:   "Docker running",
  		Met:    false,
  		Reason: "Docker is not running. Error: " + err.Error(),
  	})
  } else {
  	results = append(results, RequirementStatus{
  		Name:   "Docker running",
  		Met:    true,
  		Reason: "Docker is running",
  	})
  }
  return results, nil
}

while, fly, aws, digitalocean providers will have their own implementations, but the same function name and return statement
func  CheckRequirements() ([]RequirementStatus, error){}

@Tpuljak  Apologies i am asking too many questions, hope you are not offended

@Philip-21 exactly. That's the point of the Provider interface.

@Philip-21 exactly. That's the point of the Provider interface.

wow, so it means each  of our providers (aws, docker, digitalocean etc) have the same function definitons and return statement, but various implmentations for each respective providers.
But this provider interface handles for each respective ones (aws, docker, digitalocean, etc)  when called by the daytona server,
type Provider interface {
	Initialize(InitializeProviderRequest) (*util.Empty, error)
	GetInfo() (ProviderInfo, error)
	CheckRequirements() ([]RequirementStatus, error)

	GetTargetManifest() (*ProviderTargetManifest, error)
	GetDefaultTargets() (*[]ProviderTarget, error)

	CreateWorkspace(*WorkspaceRequest) (*util.Empty, error)
	StartWorkspace(*WorkspaceRequest) (*util.Empty, error)
	StopWorkspace(*WorkspaceRequest) (*util.Empty, error)
	DestroyWorkspace(*WorkspaceRequest) (*util.Empty, error)
	GetWorkspaceInfo(*WorkspaceRequest) (*workspace.WorkspaceInfo, error)

	CreateProject(*ProjectRequest) (*util.Empty, error)
	StartProject(*ProjectRequest) (*util.Empty, error)
	StopProject(*ProjectRequest) (*util.Empty, error)
	DestroyProject(*ProjectRequest) (*util.Empty, error)
	GetProjectInfo(*ProjectRequest) (*project.ProjectInfo, error)
}

wow, so it means each of our providers (aws, docker, digitalocean etc) have the same function definitons and return statement, but various implmentations for each respective providers.

Exactly. That's how interfaces work. I suggest you find some resources online on Object Oriented Programming and read up on interfaces. They are very important to understand if you want to hone your skills further, especially in OOP.

Yeah, Ngl i usually run away from interfaces and maps in Go,when developing,  but seeing its effective use here i have to hone my skills further , personally for my OOP approach i like using struct receivers for each methods and create new instance of the struct  to make my code modular, let me just give a glimpse of what i mean
type DockerProvider struct{}

func (p DockerProvider) GetWorkspaceInfo(workspaceReq *provider.WorkspaceRequest) {}
func (p DockerProvider) StartProject(projectReq *provider.ProjectRequest) (*provider_util.Empty, error) {}
func (p DockerProvider) GetTargetManifest() (*provider.ProviderTargetManifest, error)

//then create new instance
func NewDockerProvider ()*DockerProvider{}{}

but interfaces are more powerful from what i can see here. Thanks i will look them up

@Philip-21 you need to add a new method to https://github.com/daytonaio/daytona/blob/main/pkg/provider/provider.go#L15 and the RPC server and client in that folder. Once you do that, then you can add the necessary implementation in the Docker provider. You'll also need to use GOs replace feature to use daytona from your workspace. (You can find an example of how to do it here https://github.com/daytonaio/daytona/tree/main/pkg/docker#testing)

Hi @Tpuljak i followed these instructions here when running the provider locally,
i observed these errors
when i ran go mod tidy
cannot use &p.DockerProvider{} (value of type *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider) as "github.com/daytonaio/daytona/pkg/provider".Provider value in struct literal: *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider does not implement "github.com/daytonaio/daytona/pkg/provider".Provider (missing method CheckRequirements)
i think this is because i didn't do this
(p DockerProvider) CheckRequirements() ([]RequirementStatus, error)
i also observed another error
unknown field Label in struct literal of type "github.com/daytonaio/daytona/pkg/provider".ProviderInfo
This error is located here

i also observed another error

unknown field Label in struct literal of type "github.com/daytonaio/daytona/pkg/provider".ProviderInfo
This error is located here

This is due to the fact that you're not rebased with main. Please pull the latest changes.

cannot use &p.DockerProvider{} (value of type *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider) as "github.com/daytonaio/daytona/pkg/provider".Provider value in struct literal: *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider does not implement "github.com/daytonaio/daytona/pkg/provider".Provider (missing method CheckRequirements)
i think this is because i didn't do this
(p DockerProvider) CheckRequirements() ([]RequirementStatus, error)

That's correct. You need to implement the CheckRequirements() method in provider.go

That's correct. You need to implement the CheckRequirements() method in provider.go

I did but not as
(p DockerProvider) CheckRequirements() ([]RequirementStatus, error)
But
 CheckRequirements() ([]RequirementStatus, error)

This is due to the fact that you're not rebased with main. Please pull the latest changes.

Alright 👍

cannot use &p.DockerProvider{} (value of type *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider) as "github.com/daytonaio/daytona/pkg/provider".Provider value in struct literal: *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider does not implement "github.com/daytonaio/daytona/pkg/provider".Provider (missing method CheckRequirements)
Hey @Tpuljak  i still keep getting this error, i have defined my checkRequirement in the provider.go

func  CheckRequirements() ([]RequirementStatus, error) {
	var results []RequirementStatus
	ctx := context.Background()

	cli, err := docker_sdk.NewClientWithOpts(docker_sdk.FromEnv, docker_sdk.WithAPIVersionNegotiation())
	if err != nil {
		results = append(results, RequirementStatus{
			Name:   "Docker installed",
			Met:    false,
			Reason: "Docker is not installed",
		})
		return results, nil
	} else {
		results = append(results, RequirementStatus{
			Name:   "Docker installed",
			Met:    true,
			Reason: "Docker is installed",
		})
	}

	// Check if Docker is running by fetching Docker info
	_, err = cli.Info(ctx)
	if err != nil {
		results = append(results, RequirementStatus{
			Name:   "Docker running",
			Met:    false,
			Reason: "Docker is not running. Error: " + err.Error(),
		})
	} else {
		results = append(results, RequirementStatus{
			Name:   "Docker running",
			Met:    true,
			Reason: "Docker is running",
		})
	}
	return results, nil
}

when i also defined it like this
func (p DockerProvider) CheckRequirements() ([]RequirementStatus, error) {
	var results []RequirementStatus
	ctx := context.Background()

	cli, err := docker_sdk.NewClientWithOpts(docker_sdk.FromEnv, docker_sdk.WithAPIVersionNegotiation())
	if err != nil {
		results = append(results, RequirementStatus{
			Name:   "Docker installed",
			Met:    false,
			Reason: "Docker is not installed",
		})
		return results, nil
	} else {
		results = append(results, RequirementStatus{
			Name:   "Docker installed",
			Met:    true,
			Reason: "Docker is installed",
		})
	}

	// Check if Docker is running by fetching Docker info
	_, err = cli.Info(ctx)
	if err != nil {
		results = append(results, RequirementStatus{
			Name:   "Docker running",
			Met:    false,
			Reason: "Docker is not running. Error: " + err.Error(),
		})
	} else {
		results = append(results, RequirementStatus{
			Name:   "Docker running",
			Met:    true,
			Reason: "Docker is running",
		})
	}
	return results, nil
}

I got this error message
# command-line-arguments ./main.go:23:54: cannot use &p.DockerProvider{} (value of type *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider) as "github.com/daytonaio/daytona/pkg/provider".Provider value in struct literal: *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider does not implement "github.com/daytonaio/daytona/pkg/provider".Provider (wrong type for method CheckRequirements)                 have CheckRequirements() ([]"github.com/daytonaio/daytona-provider-docker/pkg/provider".RequirementStatus, error)                 want CheckRequirements() ([]"github.com/daytonaio/daytona/pkg/provider".RequirementStatus, error)
This is how i handled the function call from the provider interface in Daytona Repo
package server

import (
	"fmt"
	"os"
	"runtime"

	"github.com/daytonaio/daytona/internal/util"
	"github.com/daytonaio/daytona/pkg/api"
	"github.com/daytonaio/daytona/pkg/cmd/server/daemon"
	"github.com/daytonaio/daytona/pkg/provider"//provider interface
	"github.com/daytonaio/daytona/pkg/server"
	"github.com/daytonaio/daytona/pkg/views"
	view "github.com/daytonaio/daytona/pkg/views/server"
	"github.com/fatih/color"

	log "github.com/sirupsen/logrus"
	"github.com/spf13/cobra"
)

type RequirementProvider struct {
	provider.Provider
}

var ServerCmd = &cobra.Command{
	Use:     "server",
	Short:   "Start the server process in daemon mode",
	GroupID: util.SERVER_GROUP,
	Args:    cobra.NoArgs,
	RunE: func(cmd *cobra.Command, args []string) error {
		confirmCheck := true

		if !yesFlag {
			view.ConfirmPrompt(&confirmCheck)
			if !confirmCheck {
				views.RenderInfoMessage("Operation cancelled.")
				return nil
			}
		}
		infoColor := color.New(color.FgHiBlue).SprintFunc()
		warningColor := color.New(color.FgRed).SprintFunc()
		p := RequirementProvider{}

		requirements, err := p.CheckRequirements()
		if err != nil {
			return err
		}

		for _, req := range requirements {
			if req.Met {
				allRequirementsMet = true
				fmt.Printf("%s[0000]     Requirement met: %s\n", infoColor("INFO"), req.Reason)
			} else {
				allRequirementsMet = false
				fmt.Printf("%s[0000]  Requirement not met: %s\n", warningColor("WARNING"), req.Reason)
			}
			if !allRequirementsMet {
				return fmt.Errorf("    Daytona server startup aborted, one or more requirement not met")
			}
		}
......the remaining code

This is where i am so far, It seems i am getting something wrong on how i  called the interface

"github.com/daytonaio/daytona/pkg/provider".Provider (wrong type for method CheckRequirements) have CheckRequirements() ([]"github.com/daytonaio/daytona-provider-docker/pkg/provider".RequirementStatus, error) want CheckRequirements() ([]"github.com/daytonaio/daytona/pkg/provider".RequirementStatus, error)

Seems to me that you created a new struct in the docker provider instead of importing from daytona.
The method in the docker provider should have the following signature:

import "github.com/daytonaio/daytona/pkg/provider"

func (p DockerProvider) CheckRequirements() ([]provider.RequirementStatus, error)

"github.com/daytonaio/daytona/pkg/provider".Provider (wrong type for method CheckRequirements) have CheckRequirements() ([]"github.com/daytonaio/daytona-provider-docker/pkg/provider".RequirementStatus, error) want CheckRequirements() ([]"github.com/daytonaio/daytona/pkg/provider".RequirementStatus, error)

Seems to me that you created a new struct in the docker provider instead of importing from daytona.
The method in the docker provider should have the following signature:
import "github.com/daytonaio/daytona/pkg/provider"

func (p DockerProvider) CheckRequirements() ([]provider.RequirementStatus, error)

it works thanks
But i came accross this, *"github.com/daytonaio/daytona-provider-docker/pkg/provider".DockerProvider does not implement "github.com/daytonaio/daytona/pkg/provider".Provider (missing method GetPresetTargets)
it seems GetPresetTargets() is not implemented in the provider.go, this affects the  build

@Philip-21 it is implemented. (https://github.com/daytonaio/daytona-provider-docker/blob/main/pkg/provider/provider.go#L87)
You need to rebase with main.

@Philip-21 it is implemented. (https://github.com/daytonaio/daytona-provider-docker/blob/main/pkg/provider/provider.go#L87)
You need to rebase with main.

Alright

The build works and a file gets generated. so do i push changes to  on daytona-docker provider and also the daytona codebase.


⚠ Documentation has degraded performance

In cca74a2, Documentation (https://docs.tonicpow.com) experienced degraded performance:

HTTP code: 500
Response time: 10397 ms

Resolved: Documentation performance has improved in a4cbae7.


Added Danish(DK) Phone number

Matches DK phone number format
allows '-' or ' ' as a separator and allows parens around area code
some people may want to put a '+45' in front of their number

+45 21-77-21-77
+45 21 77 21 77
+45 21772177
+4521772177
21 77 21 77
21-77-21-77
2177 2177
2177-2177
21772177

but not

+1<PHONE_NUMBER>
+45 112
+452143284233
2143284233

Please add tests

@staabm what do you mean ??? screenshots?

I mean unit tests, see the tests folder. I also realized we dont have tests for the other languages, so this is not a must have.
@Arkni could you add some example tests for phoneUs so people see a example?

@staabm
I will see if I can find a moment to work on them tomorrow.
Tests should not block us from merging this PR though, as @HawkonDK can add them in another PR.

@staabm
Just did a quick read to the test files and I found that tests for phoneUS are already added (phoneUK tests are there too). See https://github.com/jquery-validation/jquery-validation/blob/38cb9b9c8c135d9737d56f4a19ee48ca9a2d888b/test/methods.js#L779-L789

@Arkni  awesome, we should separate them into a „additional“ folder and equal named files like the impl the

Hi @HawkonDK
Are you willing to continue working on this?
Thanks!


[New game]: [GSSOC '23] Block Buster

🎮 Game Request
Game logic and basic description:
Block buster game is a frontend game developed using HTML, CSS, JavaScript.
The player will get points according to the number of successful hits in a specific time.
Point down the features
Game points:

There will be a throwable object and some targets
The player has to throw the object to the targets
The player will get points according to the number of successful hits

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @sujanrupu !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @sujanrupu ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


[zh] Resync federation content cleanup

This is a resync of the English site change (05bf8be2051737abd92c666bea545bc9a40140ec).

/lgtm
/approve


feat: support parameterized constructors

Codecov Report

Merging #51 (0c493b5) into main (077fa72) will increase coverage by 0.59%.
The diff coverage is 91.97%.

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
+ Coverage   89.83%   90.43%   +0.59%
==========================================
  Files          66       70       +4
  Lines        1968     2154     +186
  Branches      261      282      +21
==========================================
+ Hits         1768     1948     +180
- Misses        138      141       +3
- Partials       62       65       +3

Impacted Files
Coverage Δ

...ings/PropertyMappings/PropertyAssignmentMapping.cs
64.58% <64.58%> (ø)

...yMappings/PropertyNullDelegateAssignmentMapping.cs
70.58% <75.00%> (ø)

...Builder/NewInstanceObjectPropertyMappingBuilder.cs
85.88% <85.88%> (ø)

src/Riok.Mapperly/Descriptors/DescriptorBuilder.cs
97.91% <100.00%> (+0.02%)
:arrow_up:

...scriptors/MappingBuilder/NullableMappingBuilder.cs
95.83% <100.00%> (-1.54%)
:arrow_down:

...ors/MappingBuilder/ObjectPropertyMappingBuilder.cs
99.23% <100.00%> (-0.23%)
:arrow_down:

...pingBuilder/ObjectPropertyMappingBuilderContext.cs
100.00% <100.00%> (ø)

...Riok.Mapperly/Descriptors/MappingBuilderContext.cs
97.50% <100.00%> (+1.50%)
:arrow_up:

...ptors/Mappings/NewInstanceObjectPropertyMapping.cs
100.00% <100.00%> (ø)

...erly/Descriptors/Mappings/ObjectPropertyMapping.cs
100.00% <100.00%> (ø)

... and 14 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Add new models

Codecov Report

Merging #10 (18dd38b) into main (ef05ca3) will decrease coverage by 3.64%.
The diff coverage is 50.00%.

@@             Coverage Diff             @@
##              main      #10      +/-   ##
===========================================
- Coverage   100.00%   96.35%   -3.65%
===========================================
  Files           14       16       +2
  Lines          318      329      +11
===========================================
- Hits           318      317       -1
- Misses           0       12      +12

Impacted Files
Coverage Δ

src/LocalSearchSolvers.jl
100.00% <ø> (ø)

src/problems/cut.jl
0.00% <0.00%> (ø)

src/state.jl
100.00% <ø> (ø)

src/constraints/equal.jl
42.85% <42.85%> (ø)

src/problems/golomb.jl
100.00% <100.00%> (ø)

src/problems/sudoku.jl
100.00% <100.00%> (ø)

src/solver.jl
100.00% <100.00%> (ø)

src/utils.jl
100.00% <100.00%> (ø)

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 ef05ca3...18dd38b. Read the comment docs.


[Android] Base 64 input/output, fit option

@JoschkaSchulz,
Here is PR I've mentioned in issue https://github.com/JoschkaSchulz/cordova-plugin-image-resizer/issues/37.
Changes

accept base64 data-uri as input
option fit to fit input image within bounds (options.width and options.height)
output as base64 string

When will this be released?

When will this be released?

When will this be released?

Hey, sorry for the long response... are you able to clean up the history a bit... it seems that there could be much squash. After that I would create a new version. 👍 Thank you very much

This is already merged


Django Form

Goals

Get familiar with how to create forms in Django

Acceptance Criteria

Basic form with different questions types (multiple choice, checkbox, free text) and with an example of conditional logic

Not merging because of Django dependency issues


Stable 1.80.14

Welcome to New Eridu!
To celebrate the release of Zenless Zone Zero, we are finally bringing a support for this HoYo's new title to Collapse Launcher. The launcher will be supporting the initial preloading on July 2nd, 2024 and the installation process on release date (July 4th, 2024).
Also, as a commitment to continuously improving the quality of the app and in suppose to bring more better experience, we are also bringing bug fixes and some minor performance improvement in this release.
Some metadata changes might need to be pushed during the initial preload if necessary.
With our excitement and hopefully so are you, we hope that you're enjoying to play this new title!
See you soon in New Eridu, Proxies!
What's New? - 1.80.14

[New] Zenless Zone Zero Support.
[Impl] Ignore the use of sophon download if delta patch is detected.
[Impl] Enable nullable on RegionClasses
[Impl] Move some GameSettings properties to SettingsBase.
[Impl] Bring InitializeSettings() into IGameSettings Interface.
[Impl] Update Game Logo and Icon
[Impl] Code QA
[Fix] Potential NullReferenceException throw if some GamePreset and GameSettings values are null.
[Fix] Launcher unaware of HoYoPlay's Game Info API status.
[Fix] Duplicated SDK entry in the Install routine's List<T>.
[Fix] Sophon Download not removing redundant DXSetup folder.
[Fix] Hard crash when the game region failed to load.
[Fix] Existing Games installed with HoYoPlay were unable to be detected for migration.
[New] Moving Community Tools informations to Metadata.
[New] Steam Shortcut support for ZZZ, by @gablm
[New] Showing "Sophon mode" label under Installation Progress indicator if detected.

[Fix] CPU and Memory Usage overhead due to unnecessary loops on "Running Game Check" routine.

[Loc] Update localizations, by localizers <3

Templates

Changelog Prefixes
  **[New]**
  **[Imp]**
  **[Fix]**
  **[Loc]**
  **[Doc]**

Nice


Generating a migration puts migration files in _build folder

Steps to reproduce:
mix new mongo_test
cd mongo_test

Add {:mongodb_driver, "~> 1.0.0"} to the dependencies in mix.exs
mix do deps.get, deps.compile
mix mongo.gen.migration test

Outputs
* creating _build/dev/lib/mongodb_driver/priv/mongo/migrations
* creating _build/dev/lib/mongodb_driver/priv/mongo/migrations/20221129151911_test.exs

Yes, I think that's right, because if you look at the _build file there should be a symbol link to your priv folder:
lrwxr-xr-x    1 micha  staff     16 25 Nov 09:21 priv -> ../../../../priv

And keep in mind, you need to configure the migration module.

So here's what I added to configure the migration module:
config/config.exs
import Config

config :mongodb_driver,
  migration: [
    otp_app: :mongo_test
  ]

Now when I run it, I get:
** (FunctionClauseError) no function clause matching in IO.chardata_to_string/1

    The following arguments were given to IO.chardata_to_string/1:

        # 1
        {:error, :bad_name}

    Attempted function clauses (showing 2 out of 2):

        def chardata_to_string(string) when is_binary(string)
        def chardata_to_string(list) when is_list(list)

    (elixir 1.14.2) lib/io.ex:670: IO.chardata_to_string/1
    (elixir 1.14.2) lib/path.ex:548: Path.join/2
    (elixir 1.14.2) lib/path.ex:518: Path.join/1
    lib/tasks/gen/migration.ex:15: Mix.Tasks.Mongo.Gen.Migration.run/1
    (mix 1.14.2) lib/mix/task.ex:421: anonymous fn/3 in Mix.Task.run_task/4
    (mix 1.14.2) lib/mix/cli.ex:84: Mix.CLI.run_task/2

:mongo_test is the name of my mix app, did I name it wrong?
Also when running the steps before, it never generated a priv folder in my mix project. Is there some other standard step to set up the symlink? I've tried doing these from a generated phoenix project and just a plain mix project, and neither of them set up that symlink.

This is a bug. The function :code.priv_dir/1 does not work like expected. I will fix it! Thanks for reporting!

I see, the :code.priv_dir/1  works only under some conditions and my local test accidentally hold that conditions :-)

Awesome, thanks for looking at it 😄

I you like, you can try out the master branch. I replaced the function.

@zookzook That did the trick 👍 Thank you!

Hey @ksmithut. I added support for options and multiple topologies to have full control of the migration. Check the README file.

Yes! Maybe I find the time to draft a new release. For the time being you can use the master branch.

Should be fixed in version 1.0.1!


[tauri] bundle llama.cpp, whisper.cpp, and tts for all-in-one easy setup/install

Would be cool if users could just download an installer, download model when it loads, and start using amica without requiring additional setup.
requires a model downloading solution and #49

Arbius has a $500 AIUS bounty for this issue!
Brief: Fix/Complete Issue, with an explanation of what was done to achieve this. All-in-one installs all the prerequisites for running Amica locally without setup on first run.
Please read carefully:
To begin work on a bounty, reply by saying “I claim this bounty” - you will have 48 hours to submit your PR before someone else may attempt to claim this bounty.
To complete the bounty, within 48 hours of claiming, reply with a link to your PR referencing this issue and an Ethereum address. You must comply with reviewers comments and have the PR merged to receive the bounty reward. Please be sure to focus on quality submissions to minimize the amount of time reviewers must take.


Make tests less verbose

Just a copy for the same issue on the frontend side: https://github.com/opencollective/frontend/issues/365
On the API side, I guess we have:

[x] silence Mailgun errors/warnings
[x] silence errors/warnings from graphql queries that we expect to fail.
[x] silence preview email template info (or move to a specific debug level, like template)

Closed by https://github.com/opencollective/opencollective-api/pull/1282


test: make the static library test actually test something

It was previously capturing the output but not checking it.  Actually
validate the output.  Fix the windows invocation check.  Ensure that we
disable the logo for the librarian on Windows.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please smoke test and merge


fix: Add prefix to the transfer

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #5957
[ ] Requires deployment <snek/rubick/worker>

Before submitting pull request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality

Optional

[ ] I've tested it at </ksm/collection>
[ ] I've tested PR on mobile
[ ] I've written unit tests 🧪
[ ] I've found edge cases

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

Copilot Summary

🤖 Generated by Copilot at 4d9fa2e
This pull request updates various files related to the payment link and the network prefix for the Kusama chain. It fixes quotation marks, whitespace, and formatting issues in the issue and pull request templates, the README, and the REWARDS files. It also adds a middleware function to redirect /transfer routes to /ksm/transfer and makes the transfer and teleport pages use dynamic network prefixes. These changes improve the consistency, functionality, and user experience of the NFT gallery.

🤖 Generated by Copilot at 4d9fa2e

urlPrefix prop
helps to avoid redirection
cutting through the web

I found the edge case with is not scope of this PR

@Jarsen136 can you please roll back change from " to ' ? Its unrelated to this PR

Looks like deployment is failing?

@Jarsen136 can you please roll back change from " to ' ? Its unrelated to this PR

I'm sorry for that. It's an auto format on my side.


No FAQ section

some user would want to know a little info  the help FAQ section will help them out.

Thank you for your suggestions @ladyami. Do you have FAQs in mind?

@ladyami @BatoolMM i do have some FAQs in mind, can i work on it?

yes @AminMusah I have code the FAQ Just  the questions and answer to fill it

sure i have the question and answer to fill it, i can help you with that.

@AminMusah  please open a issue and submit a pr for it