Add GeeksforGeeks DSA Problems Practice Extension

Is your feature request related to a problem? Please describe.
I'm always frustrated when I have to switch between different websites to practice Data Structures and Algorithms (DSA) problems. It disrupts my workflow and makes it harder to focus on learning and practicing DSA concepts.
Describe the solution you'd like
I would like a Chrome extension that integrates GeeksforGeeks DSA problems directly into the browser. This extension should allow users to access and complete DSA exercises from GeeksforGeeks without leaving their current tab. Users should be able to choose different topics and difficulty levels for practice.
Describe alternatives you've considered
Using multiple tabs to access GeeksforGeeks for DSA practice, which is not as efficient.
Using other DSA practice websites, but they may not offer the same comprehensive range of exercises and tutorials as GeeksforGeeks.
Bookmarking specific GeeksforGeeks practice pages, but this still requires switching tabs and can be cumbersome.
Additional context
Add any other context or screenshots about the feature request here.
The extension should feature a welcoming page with a typewriter effect to engage users.
The welcoming page should display a motivational or thoughtful message about the importance of practicing DSA problems.
The extension should offer a menu to select different topics and difficulty levels available on GeeksforGeeks.
What problem is this feature trying to solve?
This feature aims to streamline the process of practicing DSA problems from GeeksforGeeks by providing a quick, browser-based solution. It eliminates the need for switching between tabs and helps users focus on their learning and practice.
How do we know when the feature is complete?
A functional Chrome extension is available for installation.
The extension displays a welcoming page with a typewriter effect and a thoughtful message about DSA practice.
Users can access GeeksforGeeks DSA problems directly from the extension.
The extension provides options to select different topics and difficulty levels.
The extension has been tested and verified for usability and performance
I am contributing upon Gssoc24

No pull request received. Closing this


Still encounter this error: Could not find trained model in model_dir: ./output/sa_nn1.

Hi, i have seen the privious issue about the error  ValueError: Could not find trained model in model_dir: ./output/sa_nn1.  But it seems that your latest modify doesn't work. I still encounter this error when i use the latest code. Can you check it?
here's the traceback :

Traceback (most recent call last):
File "E:/learning-drl/magnet-1/magnet/main.py", line 87, in
main()
File "E:/learning-drl/magnet-1/magnet/main.py", line 49, in main
ddpg_agent.train_transformer(sess, env)
File "E:\learning-drl\magnet-1\magnet\models\ddpg_agent.py", line 150, in train_transformer
next_state, reward, terminal, info = self.env.step(action)
File "E:\learning-drl\magnet-1\magnet\env_processing\env_wrapper.py", line 47, in step
all_actions = self.gym.act(obs)
File "D:\Anaconda3\envs\tensorflow-gpu\lib\site-packages\pommerman\envs\v0.py", line 137, in act
return self.model.act(agents, obs, self.action_space)
File "D:\Anaconda3\envs\tensorflow-gpu\lib\site-packages\pommerman\forward_model.py", line 122, in act
ret.append(act_ex_communication(agent))
File "D:\Anaconda3\envs\tensorflow-gpu\lib\site-packages\pommerman\forward_model.py", line 101, in act_ex_communication
return agent.act(obs[agent.agent_id], action_space=action_space)
File "E:\learning-drl\magnet-1\magnet\models\ddpg_agent.py", line 99, in act
input_to_ddpg = self.input_to_ddpg(prev_state, curr_state)
File "E:\learning-drl\magnet-1\magnet\models\ddpg_agent.py", line 84, in input_to_ddpg
graph_predictions = np.asmatrix(list(itertools.islice(y_generator, prev_state.shape[0]))[0]['graph'])
File "D:\Anaconda3\envs\tensorflow-gpu\lib\site-packages\tensorflow\python\estimator\estimator.py", line 488, in predict
self._model_dir))
ValueError: Could not find trained model in model_dir: ./output/sa_nn1.

Hi. Is it solved now?


Replace any uncaught links with shorthands

For instance, long links change to: YouTube Link. Should be opened in a new tab.

Done.


replaced insecure URLs by secure (https) ones

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Does your manifest conform to the 1.2 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run


Spache Formula

See https://github.com/DaveChild/Text-Statistics

hi @DonaldTsang
Thanks for raising this. This seems to already be implemented here.

Please update the documentation if that is the case, thank you for your attention.


change order of tabs

Changes order of grc tabs so policy sets is before policies
Signed-off-by<EMAIL_ADDRESS><EMAIL_ADDRESS>

/retest

/retest


Resolve Automated Test Failures

https://github.com/OpenVoiceOS/OVOS-workshop/actions/runs/3942872737
https://github.com/OpenVoiceOS/OVOS-workshop/actions/runs/3942797703


[ST] Slow path Arbitrum to Optimism

Describe the bug
tx: https://connextscan.io/tx/0x117994b735354fc026154e1a532e84097e3716204c6f16dc2e7091560734a97a
routers: https://connextscan.io/router/0x97b9dcb1aa34fe5f12b728d9166ae353d1e7f5c4
https://connextscan.io/router/0xc4ae07f276768a3b74ae8c47bc108a2af0e40eba
Link to ticket in discord
https://discord.com/channels/454734546869551114/1194429290037657741/1194430205444501594

A "routers not bidding" issue? Going to close this out as we have a thread on this and the transaction in question has completed.


Create APIResource from ApiResource for extension an APIService

Motivation
Tries to address https://github.com/kube-rs/kube/issues/1194
This seems too easy that I am sure this is not what you had in mind. What did you have in mind?

they have one version, while kube-rs has api_version and version.
 I am guessing we need to match version with kube-rs’s api-version.
hard coding verbs with vec!["list".to_string(), "get".to_string()], feels wrong, is that okay?

Solution

test cases are failing even tho this is trivial 🤔

Thanks for looking into this. However, turns out, this is actually a little harder than I first thought :(
Currently, not all the information we need is currently in ApiResource as the struct is currently split into two (ApiResource + ApiCapabilities) and these two are usually returned together via discovery`.
So together; ApiResource + ApiCapabilities
should combine to APIResource.
However writing an impl Into<APIResource> for (ApiResource, ApiCapabilities) is not the greatest interface.
Seeing that this is currently impossible to do cleanly, we need to wait until we resolve: https://github.com/kube-rs/kube/pull/1038

Nits. Although you won't actually be able to proceed at the moment. I have accidentally mislead you with a "good first issue". Sorry.

that's okay. happens 😅


Procedure Naming

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 448c2de3-f23c-108e-6d4e-31cd32586c58
Version Independent ID: 0dbc9199-71ff-34f4-f7f6-86bd5fb20b66
Content: Substituting Reports - Business Central
Content Source: dev-itpro/developer/devenv-substituting-reports.md
Service: dynamics365-business-central
GitHub Login: @blrobl
Microsoft Alias: solsen

Your suggested change has been deleted and is now stuck in the edit history, but I'm not certain about it anyway. The idea of putting a description of the subscriber seems opinion-based. Other developers just do PublisherName_EventName[_FieldName] and such. I'm not sure Microsoft state a policy on this, or should, so it's not clear why it matters how they name in example code.

Hello, not sure about this issue, can you please elaborate a bit on where you found the bug in the article? Thanks

Closing this issue. Please open a new issue if needed, thanks.


toJSONFilter has no instances to take the "meta"-block into account

As far as I can see, the ToJSONFilter typeclass can work with any Walkable that is a Pandoc , and thus can walk the Blocks (or lists), Inlines (or lists), or Meta, but a common usecase would be to walk over the blocks, and have access to the Meta for querying, something like:
instance (Walkable a Pandoc, MonadIO m) => ToJSONFilter m (Meta -> a -> a) where
    -- ...

Run it in a Reader Meta monad, then you can just ask?

Ok, but then we need to construct the runReader ourselves if I understand it correctly? Perhaps it is nice that there is an instance that could automatically "inject" the data into the Reader?

No, I'd rather keep it conceptually simple.  If we add an unnecessary instance for every need someone might have, things will get quite cluttered.

But just to clarify, it thus will use something like \Pandoc m bs -> walkM (runReader m) bs?

no, you'd put the runReader outside of walkM.


Investigate churn created by Ehcache 3

The reason for this issue comes from the following micro benchmarks results:
Setup

Keys: long; values: byte[1000] with randomized content - 2,000,000 entries
Ehcache 2.9.1, pure on-heap, max elements = Integer.MAX_VALUE (eh2 in results)
Ehcache 3.0.0-SNAPSHOT, pure on-heap user managed cache, max elements = Long.MAX_VALUE (eh3 in results)

I then ran two tests with 4GB and 8GB heaps.
Results follow:
==> results-eh2-4g.txt <==
"Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit"
"org.ehcache.CacheBenchmark.testGetEhcache2","thrpt",20,20,24274469.272589,1612218.164819,"ops/s"

==> results-eh2-8g.txt <==
"Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit"
"org.ehcache.CacheBenchmark.testGetEhcache2","thrpt",20,20,30344616.164551,270831.911948,"ops/s"

==> results-eh3-4g.txt <==
"Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit"
"org.ehcache.CacheBenchmark.testGetEhcache3","thrpt",20,20,7362629.399195,776230.819703,"ops/s"

==> results-eh3-8g.txt <==
"Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit"
"org.ehcache.CacheBenchmark.testGetEhcache3","thrpt",20,20,43161946.345913,3398501.848252,"ops/s"

What is clear is that Ehcache 3 creates more churn than Ehcache 2 but is otherwise faster when not under memory pressure.
After discussion with the team, we believe this is an item that will need attention once we have all the major features in, in order to find the best way to resolve it.

Investigation has shown that Ehcache 2 generates almost zero churn when under read-only load: not a single new object is created under the Cache.get() path, while Ehcache 3 can easily generate a gigabyte per second on a 8 cores machine just because of the few new objects we allocate under the Cache.get() path.
A quick and dirty prototype that makes o.e.c.Ehcache.get() call Store.get() instead of Store.computeIfAbsent() and OnHeapStore.get() call CHM.get() instead of CHM.computeIfPresent() would reduce the amount of churn generated by Ehcache 3 by about 65% and make it beat Ehcache 2 even under heap pressure.
The last bit of churn that Ehcache 3 would need to get rid of to be 100% "no new in get() path" would be to find a way to eliminate the new LookupOnlyOnHeapKey() in OnHeapStore.MapWrapper.get().

#777, #787 and #791 took care of that.


Fix: Do not crash when using alternative service name

Issue
When using an alternative service name, Juju first creates a Service with the name of the app. When checking if the Service is already patched, the library crashes because it is trying to read the Service with the alternative name and it does not exists yet, since it was not patched.
Solution
This change catches the ApiError when checking if the Service is patched and returns False.
Context
N/A
Testing Instructions
Create a charm with a KubernetesServicePatch with a custom service name and deploy it successfully.
Release Notes
Fix: Do not crash when using alternative service name

LG2M, thanks!

Merged and published to the store :)


xkb::select_events is missing a parameter

The generated function looks like this:
pub fn select_events<'c, 'input, Conn, A, B, C, D>(conn: &'c Conn, device_spec: DeviceSpec, clear: A, select_all: B, affect_map: C, map: D, details: &'input SelectEventsAux) -> Result<VoidCookie<'c, Conn>, ConnectionError>
where
    Conn: RequestConnection + ?Sized,
    A: Into<u16>,
    B: Into<u16>,
    C: Into<u16>,
    D: Into<u16>,

But the corresponding XCB function looks like this:
xcb_void_cookie_t
xcb_xkb_select_events (xcb_connection_t      *c,
                       xcb_xkb_device_spec_t  deviceSpec,
                       uint16_t               affectWhich,
                       uint16_t               clear,
                       uint16_t               selectAll,
                       uint16_t               affectMap,
                       uint16_t               map,
                       const void            *details);

The affect_which parameter is missing. It seems like a similar issue (#281) was fixed already for the old python generator.

TL;DR: You decide on the value of the affectWhich argument via SelectEventsAux. In XCB, there is a void * last argument from which XCB just copies as many bytes as it wants. We wanted a memory-safe API instead.
Long version:
You already found #281. The other important part is #450. This PR explicitly removed the affect_which argument that you are looking for. Let's look at some XML...
The "magic" which detects length fields triggers here. For example, here is how InternAtom is defined in the XML:
  <request name="InternAtom" opcode="16">
    <field type="BOOL" name="only_if_exists" />
    <field type="CARD16" name="name_len" />
    <pad bytes="2" />
    <list type="char" name="name">
      <fieldref>name_len</fieldref>
    </list>
    <reply>
[...]
    </reply>
    <doc>
[...]
    </doc>
  </request>

Clearly, name_len is just the length of the name argument. Since Rust slices already come with a length, this parameter is passed implicitly. Thus, the Rust API is: pub fn intern_atom<'c, 'input, Conn>(conn: &'c Conn, only_if_exists: bool, name: &'input [u8]) -> Result<Cookie<'c, Conn, InternAtomReply>, ConnectionError>. No name_len argument (once upon a time, we did have a name_len argument here...)
Okay, the above is an obvious case. Here comes a less obvious one:
	<request name="SelectEvents" opcode="1">
		<field name="deviceSpec" type="DeviceSpec" />
		<field name="affectWhich" type="CARD16" mask="EventType" />
		<field name="clear" type="CARD16" mask="EventType" />
		<field name="selectAll" type="CARD16" mask="EventType" />
		<field name="affectMap" type="CARD16" mask="MapPart" />
		<field name="map" type="CARD16" mask="MapPart" />
		<switch name="details">
			<op op="&">
				<fieldref>affectWhich</fieldref>
				<op op="&">
					<unop op="~"><fieldref>clear</fieldref></unop>
					<unop op="~"><fieldref>selectAll</fieldref></unop>
				</op>
			</op>
[omitted all the bitcases]
		</switch>
	</request>

The above says that there are multiple cases (<switch>), depending on which bits are set on the expression affectWhich & !clear & !selectAll (<op op="&"> is "bitwise and" and <unop op="~"> is "bitwise not").
The value for the <switch> is passed in via the details argument in the API: You already select which of the bit cases are present. Thus, the API caller already provides the value of the expression affectWhich & !clear & !selectAll. This makes the "length field deduction" trigger and remove an unnecessary / implicit argument from the function. (Okay, "length field deduction" is a bad name for this since it is not about the length of something, but hopefully you still get the idea. I do not know how the code generator currently calls this.)
Anyway, now that we already have the value of affectWhich & !clear & !selectAll, we have a problem: If all of these three fields are also present as API arguments, the user could try to send invalid requests where the value provided for the <switch> does not match the values provided for these three fields. Thus, one of these fields was chosen to be implicit. Its value is deduced from the value for the <switch>. This argument is the affect_which field.
Here is how the generated code computes this field:
        let affect_which = u16::try_from(self.details.switch_expr() | (u32::from(self.clear) | u32::from(self.select_all))).unwrap();

So... we have the value affectWhich & !clear & !selectAll let's call this switch_expr. We know from something that is not part of the XML (see #450) that (clear | selectAll) & !affectWhich == 0 must hold, i.e. all bits that are set in either clear or selectAll must also be set in affectWhich. This last property means that affectWhich = switch_expr | clear | select_all, which is exactly what the code generator generates. Hence, we can deduce the value of affectWhich from the other arguments.
Hopefully this makes it clearer what is going on.
Sadly, the XML does not provide names for these bit cases, so we end up enumerating them, leading to this ugly struct that you now have to work with (Option is used to decide between "this case is present" / "this case is not present") (also see #156):
pub struct SelectEventsAux {
    pub bitcase1: Option<SelectEventsAuxBitcase1>,
    pub bitcase2: Option<SelectEventsAuxBitcase2>,
    pub bitcase3: Option<SelectEventsAuxBitcase3>,
    pub bitcase4: Option<SelectEventsAuxBitcase4>,
    pub bitcase5: Option<SelectEventsAuxBitcase5>,
    pub bitcase6: Option<SelectEventsAuxBitcase6>,
    pub bitcase7: Option<SelectEventsAuxBitcase7>,
    pub bitcase8: Option<SelectEventsAuxBitcase8>,
    pub bitcase9: Option<SelectEventsAuxBitcase9>,
    pub bitcase10: Option<SelectEventsAuxBitcase10>,
    pub bitcase11: Option<SelectEventsAuxBitcase11>,
}

If you are looking at some C code using XCB's XKB API, I could help translating that to x11rb.

TL;DR: You decide on the value of the affectWhich argument via SelectEventsAux. In XCB, there is a void * last argument from which XCB just copies as many bytes as it wants. We wanted a memory-safe API instead.
Long version:
You already found #281. The other important part is #450. This PR explicitly removed the affect_which argument that you are looking for. Let's look at some XML...
The "magic" which detects length fields triggers here. For example, here is how InternAtom is defined in the XML:
  <request name="InternAtom" opcode="16">
    <field type="BOOL" name="only_if_exists" />
    <field type="CARD16" name="name_len" />
    <pad bytes="2" />
    <list type="char" name="name">
      <fieldref>name_len</fieldref>
    </list>
    <reply>
[...]
    </reply>
    <doc>
[...]
    </doc>
  </request>

Clearly, name_len is just the length of the name argument. Since Rust slices already come with a length, this parameter is passed implicitly. Thus, the Rust API is: pub fn intern_atom<'c, 'input, Conn>(conn: &'c Conn, only_if_exists: bool, name: &'input [u8]) -> Result<Cookie<'c, Conn, InternAtomReply>, ConnectionError>. No name_len argument (once upon a time, we did have a name_len argument here...)
Okay, the above is an obvious case. Here comes a less obvious one:
	<request name="SelectEvents" opcode="1">
		<field name="deviceSpec" type="DeviceSpec" />
		<field name="affectWhich" type="CARD16" mask="EventType" />
		<field name="clear" type="CARD16" mask="EventType" />
		<field name="selectAll" type="CARD16" mask="EventType" />
		<field name="affectMap" type="CARD16" mask="MapPart" />
		<field name="map" type="CARD16" mask="MapPart" />
		<switch name="details">
			<op op="&">
				<fieldref>affectWhich</fieldref>
				<op op="&">
					<unop op="~"><fieldref>clear</fieldref></unop>
					<unop op="~"><fieldref>selectAll</fieldref></unop>
				</op>
			</op>
[omitted all the bitcases]
		</switch>
	</request>

The above says that there are multiple cases (<switch>), depending on which bits are set on the expression affectWhich & !clear & !selectAll (<op op="&"> is "bitwise and" and <unop op="~"> is "bitwise not").
The value for the <switch> is passed in via the details argument in the API: You already select which of the bit cases are present. Thus, the API caller already provides the value of the expression affectWhich & !clear & !selectAll. This makes the "length field deduction" trigger and remove an unnecessary / implicit argument from the function. (Okay, "length field deduction" is a bad name for this since it is not about the length of something, but hopefully you still get the idea. I do not know how the code generator currently calls this.)
Anyway, now that we already have the value of affectWhich & !clear & !selectAll, we have a problem: If all of these three fields are also present as API arguments, the user could try to send invalid requests where the value provided for the <switch> does not match the values provided for these three fields. Thus, one of these fields was chosen to be implicit. Its value is deduced from the value for the <switch>. This argument is the affect_which field.
Here is how the generated code computes this field:
        let affect_which = u16::try_from(self.details.switch_expr() | (u32::from(self.clear) | u32::from(self.select_all))).unwrap();

So... we have the value affectWhich & !clear & !selectAll let's call this switch_expr. We know from something that is not part of the XML (see #450) that (clear | selectAll) & !affectWhich == 0 must hold, i.e. all bits that are set in either clear or selectAll must also be set in affectWhich. This last property means that affectWhich = switch_expr | clear | select_all, which is exactly what the code generator generates. Hence, we can deduce the value of affectWhich from the other arguments.
Hopefully this makes it clearer what is going on.
Sadly, the XML does not provide names for these bit cases, so we end up enumerating them, leading to this ugly struct that you now have to work with (Option is used to decide between "this case is present" / "this case is not present") (also see #156):
pub struct SelectEventsAux {
    pub bitcase1: Option<SelectEventsAuxBitcase1>,
    pub bitcase2: Option<SelectEventsAuxBitcase2>,
    pub bitcase3: Option<SelectEventsAuxBitcase3>,
    pub bitcase4: Option<SelectEventsAuxBitcase4>,
    pub bitcase5: Option<SelectEventsAuxBitcase5>,
    pub bitcase6: Option<SelectEventsAuxBitcase6>,
    pub bitcase7: Option<SelectEventsAuxBitcase7>,
    pub bitcase8: Option<SelectEventsAuxBitcase8>,
    pub bitcase9: Option<SelectEventsAuxBitcase9>,
    pub bitcase10: Option<SelectEventsAuxBitcase10>,
    pub bitcase11: Option<SelectEventsAuxBitcase11>,
}

If you are looking at some C code using XCB's XKB API, I could help translating that to x11rb.

Yes, that clears it up, thanks.

If you are looking at some C code using XCB's XKB API, I could help translating that to x11rb.

Thanks, but I was just looking at some C code examples to try and figure out how the request is supposed to work since I found XKB spec hard to understand and the XCB man pages are unhelpful.

Yes, that clears it up, thanks.

If you are looking at some C code using XCB's XKB API, I could help translating that to x11rb.

Thanks, but I was just looking at some C code examples to try and figure out how the request is supposed to work since I found XKB spec hard to understand and the XCB man pages are unhelpful.


Trivial contributing.md references Bitcoin (not dogecoin)

Bug Report
Current behavior:
Dev;s trying to learn  how to contribute to dogecoin, are greeting by a contributing.md that tells them all about how to contribute to bitcoin.
Expected behavior
Would expect this file to tell me the rules/behaviors if I want to contribute to dogecoin.
Steps to reproduce:
Read the contributing.md file
Screenshots
N/A - Not GUI - Trivial Update
Dogecoin Core version
main
Machine specs
N/A
Extra information
This is just one of those trivial text updates, nothing too special, replace words 'bitcoin' with 'dogecoin' like has been done already in various areas of the the source.

This file has been modified for the upcoming 1.14.4 release: contributing.md in 1.14.4-dev. Does that look like what you would want to see?

Shoot, I never noticed it.  Need to get better at looking in active branches.


Support country-level locations

@abdullahdevrel since it is available in MMDB format, it should be just a drop-off replacement of the Maxmind DB, I added the link to the Readme.
The more interesting thing is daily updates: is there an URL geo302 can use to update the database automatically?

@hombit Thank you very much!

The more interesting thing is daily updates: is there an URL geo302 can use to update the database automatically?

Yes. Direct downloads:

Filetype
API endpoint

CSV
https://ipinfo.io/data/free/country.csv.gz?token=<YOUR_TOKEN>

JSON
https://ipinfo.io/data/free/country.json.gz?token=<YOUR_TOKEN>

MMDB
https://ipinfo.io/data/free/country.mmdb?token=<YOUR_TOKEN>

Some notes:

API endpoints work with a token that can be availed by opening a free account.
The MMDB file is not gzipped.
The data structure of the MMDB database is flat and tabular.
Rate limit is 3 downloads per token, per unique IP address, per day. Users can use download the database across multiple devices using the same token.
We also have a checksums endpoint: https://ipinfo.io/data/free/country.mmdb/checksums?token=<YOUR_TOKEN>

You can use our mmdbtcl CLI to lookup IP addresses from the MMDB file like so:
ipinfo ► mmdbctl read <IP_ADDRESS> country.mmdb -f json-pretty
{
  "continent": "EU",
  "continent_name": "Europe",
  "country": "NL",
  "country_name": "Netherlands"
}

Please let me know if you have any feedback.


rename visible => open everywhere

KILL THE VISIBLE PROP.
Got sick of the console errors. one fell swoop cleanup

Yep scrolled through the code and gave a decent smoke test - LGTM. Great cleanup 🙌


PEAR-2186: Update Download Icon size

Description
Just updated the icon size based on comments from @cemile-ctds
Checklist

[N/A] Added proper unit tests
[N/A] Left proper TODO messages for any remaining tasks
[N/A] Scanned for web accessibility with aXe, and mitigated or documented
flagged issues

Screenshots/Screen Recordings (if Appropriate)

oh, looks better now. 👍


Add plan_updateable to plans

Right now plan_updateable is a flag on the Service in the Catalog, and it tells the Platform whether or not people can switch plans for that Service. However, that doesn't really help w.r.t. knowing if people can switch from any particular plan.
Proposal: add an "updateable" (yes with misspelling) to the Plan struct so that Platforms can know if users will be allowed to update services of this plan to another. Granted it won't tell them which ones they can migrate to, but its at least better than nothing like they have today. This also would not remove the need for the Broker to reject an upgrade if the Platform ignore this new field.
What do people think?

correct

How many use cases do we know of where only some plan migrations are allowed (i.e. small to large is allowed, but large to small isn't)? I'll do some digging on my side to see if this is a problem for any of the brokers I know of

I'm not sure how often it does happen but it happens enough for us that our product guys are asking for it :-)

This is related to https://github.com/openservicebrokerapi/servicebroker/issues/217

Why with misspelling?

Closing this issue as it was solved in #595


How are the distractors made in the dataset?

I want to use my own custom dataset with this project, but I don't understand how the distractors were made in the original dataset to get a grasp on how to do this. Are they randomly sampled from other conversations?

I suggest looking at example_entry.py. The candidates are all possible replies to the prompt sentence. In train.py:
for j, candidate in enumerate(utterance["candidates"][-num_candidates:]):                         lm_labels = bool(j == num_candidates-1)                         instance = build_input_from_segments(persona, history, candidate, tokenizer, lm_labels)
The last sentence in candidate is taken as the gold reply. Everything else in candidates is taken as the distractor.

Sorry for the late response.
I did not really use the example_entry.py to run an example. As far as I am aware example_entry.py is just an example of the format in the JSON files.
If you want to see how all the distractors being selected I suggest you add a print statement in this code snippet from train.py:
for j, candidate in enumerate(utterance["candidates"][-num_candidates:]):        lm_labels = bool(j == num_candidates-1)       print(candidate)       instance = build_input_from_segments(persona, history, candidate, tokenizer, lm_labels)
In my code its at line 93.


Eloquent WHERE LIKE query escaping with '%' character behaves unexpectedly

Laravel Version: 5.4.36
PHP Version: 7.0
Database Driver & Version: MySQL 5.6.36

Description:
When attempting to query using eloquent with a LIKE statement, the search term gets urldecoded which causes, for example, a '%23' to resolve to another character unexpectedly.
Steps To Reproduce:
//A common use case for term would be user input from a search form:
//eg: $term = $request->input('search');
$term = '23 test';

$query = User::where('name', 'LIKE', '%' . $term . '%');

dd($query->toSql(), $query->getBindings());

The dd() will output a dump showing the binding as # test% instead of %23 test%
A quick workaround is to use $term = urlencode($term); but this seems like it shouldn't be required. I would expect to be able to search with a LIKE query + % + digits in a Database query without having to first URL encode them.

Can't replicate this in 5.5.
Please upgrade to 5.5 as your version is currently not supported.

Facing the same problem today, you can do
$query = User::where('name', 'LIKE', "%$term%");
dd($query->toSql(), $query->getBindings());

// toSql() print
"select * from `Users` where `name` LIKE ?"
// getBindings() print
array:1 [▼
  0 => "%yourterm%"
]

This should work.

How about 2 or 3 or more LIKE?

BookingDates::where('email', Input::get('email'))
->orWhere('name', 'like', '%' . Input::get('name') . '%')->get();

$categories = DB::Where('name', 'like', '%' . Input::get('name') . '%')->get();

$categories = DB::Where('name', 'like', '%' . Input::get('name') . '%')->get();


Use .editorconfig for MaxLineLength rule

I think it would be a good feature to read the max. line length from the .editorconfig file. I know that it's possible to add it to the detekt.yml config, but then the max. line length is defined in two different config files.
For example ktlint is using the .editorconfig too for the max. line length. I think there are many projects out there which want to use ktlint  and detekt in their CI.

Sorry this has been open so long with no reply.
As detekt wraps all of ktlint's rules you could disable detekt's max line length rule then turn on ktlint's wrapped rule.

As @3flex mentioned, using the ktlint rule here is the way to go. It doesn't make much sense to reimplement ktlint's rule. We're sorry for the really late answer.


Pass trust_remote_code to fix test_token_classification_parity

Pass trust_remote_code to fix test_token_classification_parity.
After investigation, the test was not passing due to the following error:
ValueError: Loading conll2003 requires you to execute the dataset script in that repo on your local machine. Make sure you have read the code there to avoid malicious use, then set the option `trust_remote_code=True` to remove this error.

Fix #632.

Maybe we can have the conll2003 dataset in an HF repo than trusting remote code from a user's repo ?


feat: initial creation of autoscale vsi module

Description
This PR contains the initial support for the vsi autoscale module
Release required?

[ ] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[x] Major release (X.x.x)

Release notes content
Initial release of the vsi autoscale terraform module
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

Couple of CRA rules failing
Failed SCC rules:
	 Rule ID rule-0e5151b1-9caf-433c-b4e5-be3d505e458e: Check whether Application Load Balancer for VPC is configured with multiple members in the pool
		Found in:
			resource_address: module.auto_scale.ibm_is_lb.lb["srv-lb"]
	 Rule ID rule-8c923215-afdc-41b1-886c-64ce78741f8c: Check whether Application Load Balancer for VPC has health check configured when created
		Found in:
			resource_address: module.auto_scale.ibm_is_lb.lb["srv-lb"]
	 Rule ID rule-65b61a0f-ffdb-41ba-873d-ad329e7fc0ee: Check whether Application Load Balancer for VPC is configured to convert HTTP client requests to HTTPS
		Found in:
			resource_address: module.auto_scale.ibm_is_lb.lb["srv-lb"]
	 Rule ID rule-d544f217-3723-4376-b3aa-037c5f201e8d: Check whether Application Load Balancer for VPC uses HTTPS (SSL & TLS) instead of HTTP
		Found in:
			resource_address: module.auto_scale.ibm_is_lb_listener.listener["srv-lb"]

terraform-validate completed in 10.252813404s

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

just 1 comment left from me and I'm good to merge

fixed

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


Soul hackers 2 missing effects

While the game runs fine it‘s missing magical effects and the graphic effect for, for example, the teleportation circles.
Missing rain effects:
https://user-images.githubusercontent.com/85197579/188305343-bd755602-4400-43f1-aae4-33d04a2637d7.png
Missing triangles graphics effect
https://user-images.githubusercontent.com/85197579/188305309-e0adddac-b11f-4716-90f6-11b965e48a66.png
Issue was reported to proton GitHub already, but still unresolved
https://github.com/ValveSoftware/Proton/issues/6139
About sportscaster and the rest of information: I looked the guide up, but the steam deck is my first Linux device and I seriously don’t understand all these steps and report this as good as I can. Sorry for the inconvenience.
Software information
Soul Hackers 2 on steam with every graphic setting tested and all of them are affected
System information

GPU: AMD steam deck APU
Driver:
Wine version: GE-Proton 7-41 and Proton 7.0.4
DXVK version:

Apitrace file(s)

Put a link here

For instructions on how to use apitrace, see:
Log files

d3d9.log:
d3d11.log:
dxgi.log:

Apitrace file(s)
Put a link here

Please do that.

Yes as said above a thing to try is to install d3dcompiler_47 with protontricks/winetricks.
Kinda forgot to suggest that back after i asked if the issue was also present with wined3d.

The d3dcompiler_47 did the trick and now the effects all work.

Roger. Then it's a wine (proton wine) issue as dxvk doesn't take care of those dll's
But good to hear you got it working.


Integration Test - Release - 2020/02/04 22:29:17

Auto create for integration test. IssueCommandFlow

@PRMergerTest2 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Stress Test Before Deployment

I need to stress test all routes of the API before deployment to find huge issues or bottlenecks.
Will definitely use the following python package to do so: https://github.com/locustio/locust

Used locust to stress test. Some summary data:

Main route / : 1000's of requests per second
Get tracks /playlists/{playlist_id}/tracks : 10's of requests per second
Get analysis `/{playlist_id}/analysis : 1-2 requests per second

Need to update performance of analysis route - I am hitting the Spotify API rate limit. See issue #18 for details and tracking. Will update when another stress test is done.

API underwent serious refactoring to conduct analysis... new stress test results:
Main Route / : Test passed at a steady rate of 15 requests/second
Get Tracks /playlists/{playlist_id}/tracks : Test passed at a steady rate of 8 requests/second (one rate limit error was hit)
Get analysis /{playlist_id}/analysis : Test (sorta) passed at a steady rate of 5 requests/second (some rate limit errors were hit).
It seems that in terms of scalability and performance - Spotify's rate limits designated to my application will be the ultimate bottleneck. I think we should be good for now to deploy and promote and that even a steady stream of users wont break the application.
Only once serious traffic is being achieved will I need to consider a Spotify partnership or seriously refactoring the API.
Closing the issue for now.


Error while make

I have the ./configure completely done without any warning or error, but I got lots of warnings and 2 errors while making:
http://pastebin.com/JkG6ssC0
I'll be thankful if you let me know what has went wrong and how can I tackle it.

GTK currently does not support clang. Please build with GCC>

Thanks for the rapid reply.
As far as I understand, I'm using gcc for the building since:
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in po
make[2]: Nothing to be done for `all'.
Making all in src
gcc -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/inclu...
clang: warning: argument unused during compilation: '-pthread'
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [gummi] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
am I on the right track?

I'm not familiar with MacOS, but from the log it seems that the gcc here is just a wrapper for clang. Perhaps you need to install gcc from MacPorts or HomeBrew. Please let me know the results :)

I'm closing this because of inactivity. Please re-open it if you have further questions.


Docker for api

Did we have Docker for api for local implement?
I think we can add Run capability for simple client/helloworld.rs rust client that interact with program we already deploy.
I know this may be out of scope of this project but what we have here is pretty close to rust's playground+solana create already.
FYI: I just having fun playing around here so feel free to say no. :)

Can you expand on this? Would love to hear how exactly this would work.

The title maybe mislead 🤔. It would be "Do api have Run endpoint for rust client? If not (it's not i guess), maybe you can provide current api Docker file so I can I help add that Run endpoint.
I expected something like rust playground + solana related create.
After that in ui should have separated section for both program and client side and run button something like...

and when click run it should call https://api.solpg.io/run and get the result back at cli.
Motivation
When user open the repos that contain both program and (simple) rust client. They should able to run both in playground.
Anyway JIT ts and lazy load module should be more suitable (widely used) than rs client example.
But I'm kinda bore to mess with ts so I propose to take care of rust client example instead. 😅
And again, nothing serious here, just itchy to having fun with the playground.

Would love to have something like this but I think there are a few problems with this approach.

The server would need the keypair of the user to make this work
The server would need internet access
The server would need premium RPC endpoints on all networks to serve all those requests. Any free RPC provider would block the IP since we are sending it from the same location
This would also add lots of load to the server(trying to do as little as possible from the server, that's why we are using wasm for the CLI's even though it would have been much easier to just have a server for it)

TS/JS sounds good for this purpose to do everything in the client. For now though, the main goal is to do the tests from the UI to have a different value proposition.
This would be great to return back to when browser tooling for Rust improves and we can do most if not all of these from the client.

i can see nearly most example and test use new KeyPair() in ts or embed byte keypair in rs which mean it  should be fine for example purpose on devnet and maybe some serious warning (or blocking) for mainnet

2. 3. 4. Can be address with money or subscription (no joy), anyway I'm agree we should get back to this when things viable.
I will try POC ts way while wait. 👍


CompositedTransformFollower callback when unlinked

Currently if you use CompositedTransformFollower and have showWhenUnlinked as false, the follower widget will be hidden.
How is it hidden? Is it put in offstage, I tried to read the source but couldn't quite understand it. If it is put in offstage then it will be still running there but hidden, why not just remove the widget from tree? This way we could get notified using the widget disposed if the widget is removed from the tree.
If the above is not possible, then I would suggest adding a callback when the follower widget is unlinked.
If there is some better way to do this without making a PR, please suggest.
Thanks 👍

Hi @KlausJokisuo
I am not familair with CompositedTransformTarget, this issue needs further triage
Thank you for the patience


Component page

The component page (dynamic) has been initialized. I have added a few details like the tags, description, and title for the component. I will continue working on it when the APIs are ready.

Sorry for the wait. I will take a look at this today.

Changed URL for the top 10 API.
Few changes to be done in the API (backend):

Icon to be added
Downloads to be added

Components to be linked to their respective pages.

@sarthak-sehgal make a global variable for the BASE_URL. That way, you will not have to write '<IP_ADDRESS>' for every URL constant. Also, if the IP changes/we start using a domain, you will have to change it at one place only.

@Megh-Thakkar okay, I'll do it. Deleting this branch for now. I'll be creating a new branch.


Reintroduce unit tests

Unit tests were removed in c62d50d0696e553ff75bb1f6e5ae3f440a4bb9c8 to support the refactoring effort, as the new signature of setConstraint and behavior of @MarkupConstraintsLogic.register is incompatible with the approach used when the tests were created.
Equivalent unit tests for the new signature and behavior should be reintroduced.

Resolved.


Add a badge reader/writer board firmware system

Per https://makesaltlake.slack.com/archives/CGDLBCCCT/p1610320781275700
We need a way to allow developers to upload new firmware for the badge readers and writers and allow them to download it over-the-air and update themselves whenever it's changed.
Current thinking is to have that baked into Heimdall itself, probably in the form of something like:

A new model, DeviceFirmware, that has an Active Storage attachment for a binary firmware blob
Some way of flagging which uploaded firmware should be the current one that gets rolled out to all devices
Some way of having different sets of firmware for badge readers and badge writers (and other devices in the future)

Open questions:

Is there any sort of CI pipeline attached to this or is the expectation that a developer builds the firmware on their local computer and uploads it manually to Heimdall?

How feasible would a CI pipeline be with Espressif's SDK's requirements?

How best to support anyone outside of Make Salt Lake who wants to deploy a Heimdall instance? It wouldn't be any good if they had to install Espressif's SDK themselves, build the firmware, and upload it to their own instance. (If CI is feasible, perhaps firmware releases could be built automatically on repo push and Heimdall could pull them in from GitHub and expose them in the UI, with the ability to also upload firmware blobs by hand in case a developer wants to test out some changes they've made locally but haven't pushed.)

The current expectation is that developers would build the firmware on their local machine and upload it manually. But it would be good to have CI to build it automatically. I'm sure it would be possible to do - I'll look into it.
I like the idea of Heimdall pulling firmware from Github and displaying it in a UI. The initial customization will always have to be locally, since without it the firmware doesn't know the WiFi SSID/password: which brings up the point of what to do if (when?) the WiFi password gets changed? Should we be able to build firmware that has the new password embedded in it, and which updates the non-volatile storage key/pair storage area?

The current expectation is that developers would build the firmware on their local machine and upload it manually. But it would be good to have CI to build it automatically. I'm sure it would be possible to do - I'll look into it.
I like the idea of Heimdall pulling firmware from Github and displaying it in a UI. The initial customization will always have to be locally, since without it the firmware doesn't know the WiFi SSID/password: which brings up the point of what to do if (when?) the WiFi password gets changed? Should we be able to build firmware that has the new password embedded in it, and which updates the non-volatile storage key/pair storage area?

@bcran I totally forgot about the WiFi credentials. That throws a wrench in the works...
Is it possible to update the NVS area programmatically from firmware without otherwise replacing the firmware itself? If so, it seems like another way to do it would be to have firmware bundles that don't embed credentials uploaded to GitHub and then have a separate, out-of-band mechanism for pushing new wireless credentials to the devices, like a separate endpoint in Heimdall, since yeah, that totally needs to be specific to a given Heimdall instance. Would that work?

@bcran I totally forgot about the WiFi credentials. That throws a wrench in the works...
Is it possible to update the NVS area programmatically from firmware without otherwise replacing the firmware itself? If so, it seems like another way to do it would be to have firmware bundles that don't embed credentials uploaded to GitHub and then have a separate, out-of-band mechanism for pushing new wireless credentials to the devices, like a separate endpoint in Heimdall, since yeah, that totally needs to be specific to a given Heimdall instance. Would that work?

(Not that any of this needs to be done right off the bat, of course.)

(Not that any of this needs to be done right off the bat, of course.)

@javawizard Yes, the way it's designed is that the NVS area is always updated separately from the firmware, using the esp-idf nvs tool on the host computer. I presume the firmware running on the device can also update that area itself.
I'm guessing we'd need to support having two sets of WiFi credentials, with the old one being tried until the new one starts working?

@javawizard Yes, the way it's designed is that the NVS area is always updated separately from the firmware, using the esp-idf nvs tool on the host computer. I presume the firmware running on the device can also update that area itself.
I'm guessing we'd need to support having two sets of WiFi credentials, with the old one being tried until the new one starts working?

@bcran Yeah, seems like that'd be helpful when doing a switchover. (It's not strictly needed here at the space since our access points can serve multiple SSIDs at the same time, but at least from the Heimdall end it wouldn't be hard to implement.)
So in that case I'll plan to write two different systems, one to expose to badges the WiFi credentials they should use and one to expose the firmware blob they should use.
How do you want to determine if an update is needed? I could write an endpoint to fetch the SHA of the latest firmware bundle - would that be sufficient?

@bcran Yeah, seems like that'd be helpful when doing a switchover. (It's not strictly needed here at the space since our access points can serve multiple SSIDs at the same time, but at least from the Heimdall end it wouldn't be hard to implement.)
So in that case I'll plan to write two different systems, one to expose to badges the WiFi credentials they should use and one to expose the firmware blob they should use.
How do you want to determine if an update is needed? I could write an endpoint to fetch the SHA of the latest firmware bundle - would that be sufficient?

The firmware has a built-in version number, so I think the ESP-IDF OTA API takes care of it.

The firmware has a built-in version number, so I think the ESP-IDF OTA API takes care of it.

Got it. Rephrase: is there anything special you'd like me to do to prevent the firmware from needing to download a full copy of the current firmware version every time it checks for an update? (Or, is the firmware small enough that that's not a problem?)

Got it. Rephrase: is there anything special you'd like me to do to prevent the firmware from needing to download a full copy of the current firmware version every time it checks for an update? (Or, is the firmware small enough that that's not a problem?)

This may be a little optimistic, but I'm presuming just the first few bytes of the firmware need downloaded to get the firmware description header and check the version.

This may be a little optimistic, but I'm presuming just the first few bytes of the firmware need downloaded to get the firmware description header and check the version.

Otherwise, the firmware .bin file is only 800 KB, so it wouldn't be terrible if it did download it all.

Otherwise, the firmware .bin file is only 800 KB, so it wouldn't be terrible if it did download it all.


Build: project repository updated

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


fix: issue when contracts w/o source IDs would not enrich

What I did
fixes: #2035
Enrichment was skipped for contracts missing source IDs. This adds it.
bonuses that are not needed but were still part of the fun:

https://github.com/ApeWorX/ape-foundry/pull/100
https://github.com/ApeWorX/ape-solidity/pull/141

TODO: Refactor CompilerAPI plugins to use new helper method (instead of re-implementing n-places) compiler_manager.get_custom_error()
How I did it

How to verify it

Checklist

[ ] All changes are completed
[ ] New test cases have been added
[ ] Documentation has been updated

so in my initial tests it shows the correct error at the end

but in the trace it's still reverted without message

moreover, if an error encodes some additional details, it doesn't get caught at all. here is an updated test.
def test_custom_error_2(accounts):
    universal_router = Contract("0x3fC91A3afd70395Cd496C647d5a6CC9D4B2b7FAD")
    for value in [10**18, 0]:
        receipt = universal_router.execute(
            "0x0b00",
            [
                "0x0000000000000000000000003fc91a3afd70395cd496c647d5a6cc9d4b2b7fad0000000000000000000000000000000000000000000000000de0b6b3a7640000",
                "0x000000000000000000000000f39fd6e51aad88f6f4ce6ab8827279cfffb922660000000000000000000000000000000000000000000000000de0b6b3a7640000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002bc02aaa39b223fe8d0a0e5c4f27ead9083c756cc20001f4a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000000000000000000000",
            ],
            sender=accounts[0],
            value=value,
        )
        receipt.show_trace()

expected AllowanceExpired(uint256) that encodes 0
actual
E   ape.exceptions.ContractLogicError: 0xd81b2f2e0000000000000000000000000000000000000000000000000000000000000000

inputs should work!
but it looks like it is struggling to find the AllowanceNotAccepted ABI - it is not on the contract for some reason.

OK - custom errors appear in traces now..
The only thing left is figuring out why some contract's are missing ABIs, will fix that on another PR though


Rename Bulk Tagger to Tag Importer

We've renamed this feature to avoid confusion with the concept of 'bulk
tagging' a content item with multiple tags manually via the UI. The
spreadsheet-driven tagging is now referred to as the Tag Importer.

👍


Dashboard module for Feedback

Missing this module

We'll include it when we make a new dashboard for OWF.


iPSK-Manager Fails to create DB

Describe the bug
I am installing iPSK-Manager on ubuntu 22.04-LTS Server and cannot create the iPSK Database.
To Reproduce
Steps to reproduce the behavior:

Following the Install readme on Github. I got to the install.php
Filled in all details as per suggestions
Create Admin Password Click Next
Click Install
Get 500 Error
Expected behavior
should create a DB and continue to install iPSK-Manager
Screenshots

Server (please complete the following information):

OS:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS"

Desktop
OS: Windows 10 22H2
Browser: Edge
Additional context
Add any other context about the problem here.

I've managed to get iPSK-Manager installed.
Ubuntu 22.04 comes with PHP 8.1.x the php code in the installer.php file doesn't work very well with php 8.1 I had to "downgrade" the php version back to 7.4.x and install all the 7.4 exentions:
Downgrade:
sudo apt install software-properties-common apt-transport-https -y
#install the php 7 repo
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt upgrade
#install php7
sudo apt install php7.4 php7.4-common libapache2-mod-php7.4 php7.4-cli
#Disable php 8
sudo a2dismod php8.1
#Enable php 7
sudo a2enmod php7.4
#restart Apache2
sudo systemctl restart apache2
#Install php extentions needed for iPSK-Manager
sudo apt install php7.4-mbstring
sudo apt install php7.4-xml
sudo apt install php7.4-ldap
sudo apt install php7.4-mysqli
sudo apt install php7.4-mysqlng
sudo apt install php7.4-curl
#I do not know if all those are needed I am using my command history for this
Then restart apache2 again:
sudo systemctl restart apache2
After doing this I could then get through the full installer.
This is not ideal as php7.4 could have issues in it. Ideally iPSK-Manager needs to be updated to php 8

The exception appears from lines 358 ~ 363 of installer.php
			if($dbConnection->select_db($_SESSION['databasename'])){
				$installProgress .= "
Database Already Exists
";
				goto Bail;
			}else{
				$installProgress .= "
Database is not in use
";
			}

Likely, this is due to this change PHP RFC: Change Default mysqli Error Mode, which reported in PHP 8.1.

This specific issue (lines 358-363 above) has been fixed and working on another fix or two before pushing it up to the branch.

changes have been merged into master branch


Update dependencies for v2024.1

As part of this, we should update caniuse-lite. I'm seeing this message during testing:
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme


grandorgue: 3.9.0-1 -> 3.9.2-1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/GrandOrgue/grandorgue/releases.
meta.description for grandorgue is: "Virtual Pipe Organ Software"
meta.homepage for grandorgue is: "https://sourceforge.net/projects/ourorgan"
meta.changelog for grandorgue is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.9.1-1 with grep in /nix/store/kd0kfixh384kkafyqqgd8kmw7zg2nbkb-grandorgue-3.9.1-1
found 3.9.1-1 in filename of file in /nix/store/kd0kfixh384kkafyqqgd8kmw7zg2nbkb-grandorgue-3.9.1-1

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
grandorgue

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A grandorgue https://github.com/r-ryantm/nixpkgs/archive/39549ea9e56cfb8b6c282a53756f14f0ba5fdbfe.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/kd0kfixh384kkafyqqgd8kmw7zg2nbkb-grandorgue-3.9.1-1
ls -la /nix/store/kd0kfixh384kkafyqqgd8kmw7zg2nbkb-grandorgue-3.9.1-1/bin

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

1 package built:

grandorgue

Maintainer pings
cc @puzzlewolf for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/GrandOrgue/grandorgue/releases.
meta.description for grandorgue is: "Virtual Pipe Organ Software"
meta.homepage for grandorgue is: "https://sourceforge.net/projects/ourorgan"
meta.changelog for grandorgue is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.9.2-1 with grep in /nix/store/gz7s7z7bjkq299358vkmx8m97wgivnkn-grandorgue-3.9.2-1
found 3.9.2-1 in filename of file in /nix/store/gz7s7z7bjkq299358vkmx8m97wgivnkn-grandorgue-3.9.2-1

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
grandorgue

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A grandorgue https://github.com/r-ryantm/nixpkgs/archive/0b7ea9030cd907fa56ea95a5cdd47bd2a33b9f35.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/gz7s7z7bjkq299358vkmx8m97wgivnkn-grandorgue-3.9.2-1
ls -la /nix/store/gz7s7z7bjkq299358vkmx8m97wgivnkn-grandorgue-3.9.2-1/bin

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

1 package built:

grandorgue

Maintainer pings
cc @puzzlewolf for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/GrandOrgue/grandorgue/releases.
meta.description for grandorgue is: "Virtual Pipe Organ Software"
meta.homepage for grandorgue is: "https://sourceforge.net/projects/ourorgan"
meta.changelog for grandorgue is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.9.3-1 with grep in /nix/store/7imqdxwi2hv88736r72gckm4pbn543y1-grandorgue-3.9.3-1
found 3.9.3-1 in filename of file in /nix/store/7imqdxwi2hv88736r72gckm4pbn543y1-grandorgue-3.9.3-1

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
grandorgue

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A grandorgue https://github.com/r-ryantm/nixpkgs/archive/fce6b6c3aefa0de03227ad14fd608e9432975693.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/7imqdxwi2hv88736r72gckm4pbn543y1-grandorgue-3.9.3-1
ls -la /nix/store/7imqdxwi2hv88736r72gckm4pbn543y1-grandorgue-3.9.3-1/bin

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

1 package built:

grandorgue

Maintainer pings
cc @puzzlewolf for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/GrandOrgue/grandorgue/releases.
meta.description for grandorgue is: "Virtual Pipe Organ Software"
meta.homepage for grandorgue is: "https://sourceforge.net/projects/ourorgan"
meta.changelog for grandorgue is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.9.4-1 with grep in /nix/store/qbbj8dc88xn5jr812v8na4m1v9i4r6fw-grandorgue-3.9.4-1
found 3.9.4-1 in filename of file in /nix/store/qbbj8dc88xn5jr812v8na4m1v9i4r6fw-grandorgue-3.9.4-1

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
grandorgue

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A grandorgue https://github.com/r-ryantm/nixpkgs/archive/82d9fb7d15a819590a07bc5cfa62fd1755500f7f.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/qbbj8dc88xn5jr812v8na4m1v9i4r6fw-grandorgue-3.9.4-1
ls -la /nix/store/qbbj8dc88xn5jr812v8na4m1v9i4r6fw-grandorgue-3.9.4-1/bin

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

1 package built:

grandorgue

Maintainer pings
cc @puzzlewolf for testing.

@ofborg build grandorgue grandorgue.passthru.tests


Cannot upate external interface in clew

I've added an external interface. Then I clicked Edit external interface for the added interface and changed proxy send  and read timeouts and clicked update. Result:
Unexpected error occurred
Object is invalid
Request ID: 475be631-6f43-43cc-b94b-504b87c9ef06
When reporting this issue use the provided request ID
Details
key:has already been taken

@tbartynski can you explain what is wrong here?

I was able to reproduce this error on exp.moc.ismop.edu.pl. I created an external interface for a running VM. Then I cannot update it's properties. It seems like CLEW tries to create new external interface instead of updating existing one hence the "key:has already been taken" error.

@dharezlak can you take a look?

So, if I understand this correctly, the POST in step 2 should succeed as there are no previous properties present, right?

I will take a look at this issue

Exp was using quite old atmosphere version. After upgrading into latest atmosphere I cannot reproduce this issue.


OCS Deployment Fails with OpenShift 4.8

The stable-4.6 channel is not available in the operator catalog for 4.8.

Adjust deployment to stable-4.8 channel
Deploy resource locker
Apply patch for Quay: oc patch bucketclass noobaa-default-bucket-class --patch '{"spec":{"placementPolicy":{"tiers":[{"backingStores":["noobaa-pv-backing-store"]}]}}}' --type merge -n openshift-storage

Resolved by PR #133


Nested routes in sysl file and code gen

Hi everyone,
come across to a problem. we want to avoid repeating our code while implementing business logic.
what we want to describe as a sysl file:
Example "app description" [package="example"]:
    @version = "0.0.1"
    @description =:
        | This is the definition of ......

    /v1:
        /customer/{custId<:string}/abc:
            GET:
                | No description.
                Downstream <- POST /form/{FormId}/refresh/{ContextId}
                return ok <: returnExampleTypeA

        /customer/{custId<:string}/efg/calculate:
            GET:
                Example <- GET /v1/customer/{custId}/abc
                return ok <: sequence of returnExampleTypeB

        /customer/{custId<:string}/xyz:
            GET:
                Example <- GET /v1/customer/{custId}/abc
                return ok <: returnExampleTypeC

The reason we want to reuse that "GET /v1/customer/{custId}/abc" is due to a large number of calls will repeat the code inside and it is not quite follow the "DRY" concept.
Cheers,
Ping

What's the actual problem?
You don't want to repeat GET /v1/customer/{custId}/abc in the sysl?
I don't understand the sentence The reason we want to reuse that "GET /v1/customer/{custId}/abc" is due to a large number of calls will repeat the code inside and it is not quite follow the "DRY" concept.

we basically need to repeat "Logic A" in Endpoint_A, Endpoint_B, Endpoint_C. They are the same code repeating for each of the above endpoints.

Sysl describes relationships between applications (or systems).
If your shared logic is internal to the application then it doesn't need to be defined in the specification, just write a method and call it in the required endpoints.
If your shared logic is on a separate application then model it as a separate application.

Just to be clear the issue here is around reusing code, and not the calls. The business flow will still make the same no of calls. Any custom code written to aggregate calls would make it convoluted in sysl file and would make diagramming impossible.

Have a discussion with @springwiz just now, i walked him through what we are facing for the moment while consuming the downstream. He is fully understand what we are facing in a code and business logic level.
@andrewemeryanz, yes, i can see your points here. We can write our http call code which will do that logic, but moving that out ends up removing the related sysl file from:
        /customer/{custId<:string}/efg/calculate:
            GET:
                Example <- GET /v1/customer/{custId}/abc
                return ok <: sequence of returnExampleTypeB

to
        /customer/{custId<:string}/efg/calculate:
            GET:
                return ok <: sequence of returnExampleTypeB

which mean when we generate the diagram and swagger file will not be accurate.
As @springwiz requests, this is not a simple decision that we could make to bring forward, thus looping @anzdaddy in as well.
Cheers,
Ping

@suipinglu Sindhu asked me to comment on this issue, I completely mis-understood the initial issue at first, I didn't realise the Example <- GET /v1/customer/{custId}/abc was the line you had issues with duplicating. Please in the future be sure to make your issues more obvious (pretend you're trying to explain the issue to a 5 year old!)
Anyway, as it turns out I think my answer I was going to give would be pretty close to the solution you want.
I think you want the sysl to basically look like this:
Example "app description" [package="example"]:
    @version = "0.0.1"
    @description =:
        | This is the definition of ......

    /v1/customer/{custId<:string}/abc:
             | No description.
             Downstream <- POST /form/{FormId}/refresh/{ContextId}
             return returnExampleTypeA

        /efg/calculate:
            GET:
                return ok <: sequence of returnExampleTypeB

        /xyz:
            GET:
                return ok <: returnExampleTypeC

where /v1/customer/{custId<:string}/abc would handle the actual downstream and pass the returnExampleTypeA object down into the two nested endpoint handlers automatically? This is trivial in go to write up but I have no idea how complicated it would be to implement in the current sysl codegen :( (also the /abc endpoint without the METHOD name isnt legal sysl)

If i have made any confusion to you guys, sorry for that. :)
If you are free, I am more than happy to spend some time with you in a call to walk you though in the code level.
Sometime, cuz here is public, not ideal to put details in.

I have a probably the most immediate resolution.
I think what you want to do is, you have an endpoint /a and you want to use the data responded by endpoint /b.
    /a
        GET:
            Fxxxxxx <- POST /whatever_api
            Fxxxxxx <- GET /whatever_api
            return ok <: RespA
    /b
        GET:
            Fxxxxxx <- POST /whatever_api
            Fxxxxxx <- GET /whatever_api
            return ok <: RespB

    !type RespA:
        Name <: string:
            @json_tag = "Name"
        RespB <: RespB:
            @json_tag = "RespB"

    !type RespB:
        Data <: string

Now, what you are going to do next is: call the handler b from the handler a.
Assuming the BFF handler struct for /a and /b are HandlerA and HandlerB. In the handler function A, you can create a HandlerB struct easily because both 2 endpoints share the same downstream APIs.
Once you have the HandlerB struct in handler A, then you can call handler b freely from handler a.


Docker Swarm Alpine

Docker containers in swarm mode are terminating immediately on grsec enabled Alpine swarm cluster.

Steps to reproduce the issue:
1.
install latest Docker from community repo
2.
create swarm cluster
3.
create overlay network:
docker network create --driver overlay logging
4.
schedule containers:
docker service create --network logging --name elasticsearch elasticsearch:2.4
Describe the results you received:
failed task with error: "task: non-zero exit (1)"
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Issue happens all the time.
Output of docker version:
Docker version 1.13.0, build v1.13.0

Output of docker info:
Containers: 9
 Running: 0
 Paused: 0
 Stopped: 9
Images: 4
Server Version: 1.13.0
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: active
 NodeID: ftbeplywjba422ybtxfs2f8k4
 Is Manager: true
 ClusterID: otvire4pkhp9mhf25yd9022u6
 Managers: 1
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: LAN_IP_HERE
 Manager Addresses:
  LAN_IP_HERE:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Kernel Version: 4.9.11-0-grsec
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.854 GiB
Name: alp01
ID: YAN3:PBF7:KSDM:KQYV:5OJV:IP43:VT4R:IWH2:4EHP:VGKJ:74Z7:FARW
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
Environment is on ESXi 2016.03.02

ping @justincormack

Let me close this ticket for now, as it looks like it went stale.


Render scheduled during previous render not commited to DOM

This can't be reproduced on master so perhaps this bug has already been addressed. Since I've already written the report I'll post it anyway, in case this wasn't noticed, and for others who may stumble across this.
I was expecting the code below to render the current timestamp, schedule a new render, and render the new timestamp:
use std::time::{SystemTime, UNIX_EPOCH};
use dioxus::prelude::*;

fn main() {
    dioxus::desktop::launch(App);
}

fn App(cx: Scope) -> Element {
    let nanos = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("Time went backwards").as_nanos();

    cx.use_hook(|_|{
        let update_fn = cx.schedule_update();
        (update_fn)();
    });

    println!("Rendering with {nanos}");
    cx.render(rsx! (
        div {
            "{nanos}"
        }
    ))
}

As expected, the component is rendered twice with 2 different timestamps:
Rendering with<PHONE_NUMBER>528600736
Rendering with<PHONE_NUMBER>528797320

However, only the initial value is actually committed to the DOM:

Instead, the latest value should be rendered.
It seems this can only be reproduced if an update is scheduled during render – if it is scheduled as part of some event (e.g. button click), everything is fine.
Environment:

Dioxus version: 0.2.3 (can't be reproduced on master)
Rust version: 1.59
OS: Ubuntu 20.04
App platform: desktop

This is fixed on master, but I haven't released the new version yet. Some other PRs need to be merged too, but I expect to release by the end of the weekend.

Awesome, thank you! I'll wait for the release then :)


fix: Decrement BMC credential count

When validating BMC IPMI/OpenBMC credentials a count is stored to keep
track of the successful connections. When a new successful connection is
validated the count is decremented by the total number of BMCs instead
of 1. This resulted in a binary pass/fail if any or no BMC
connections were validated.

@rayjh I'm submitted this as a draft because I think we need to add something more (not sure what). If ValidateClusterHardware._get_credentials() returns an incomplete bmc_ai dict pup deploy is on a path to fail. Calls to set_*_clients modules will omit the missing system when attempting to PXE boot. If the user selects the option to reset missing nodes they will encounter a KeyError from ValidateClusterHardware._reset_unfound_nodes(). I'm thinking we should at least add in a prompt to force the user to retry or exit (and fix/remove the node that won't communicate).

Unresponsive nodes has been a long standing problem largely because it's not simple to deal with. Any cluster of more than a few nodes is likely to have some unresponsive. What really needs to happen is give the user the option to retry multiple times (presumably he attempts some corrective action at some point) or continue on without the missing node(s). Of course that's where things get tricky.  I see two options - The first would be to 'remove' the missing nodes(s) from the config file and potentially the inventory file and attempt to go on.  That could get tricky and it's probably not a good idea to mess with the user's config file. The second approach (and cleaner) is to make sure the balance of code can deal with missing / unresponsive hardware. We may want to add a 'failed hardware' list to the inventory file to assist with this....


Add worker field to LogMessage

This will make it easy to correlate datums with workers and figure out which datums are spiking your cpu / memory on a particular worker.

This is done as far as I can tell.


Feature Request: Mass Download, Audio Format Download.

Hi! I wanted to suggest, If it would be possible, to make 2 new feature:

Mass Download: After we select twitch ID, select date range, select the output format (audio or video), and search for the vods, with a button, we can download all avaiable videos, without the need to download each one, from the list.
Audio Format Download: Would be possible to download the vods in MP3 or AAC format, even without conversion, but ready into an audio format? Every time I download a video, I have to export it with an external software. Would be amazing if we can just download audio, or have a feature which does give only an audio file.

See #518
Audio only is already there. Twitch does not support it for every VOD, though


Add poker exercise

See exercism/x-common#62.

Gosh, that will take people a while.  There should be lots of variation in solutions as well!


Idea: show all problems when running :bazel_env instead of short-circuiting

When I ran the bazel_env target the first time, it showed
====== bazel_env ======

⚠ direnv is not installed. Please follow the setup instructions at https://direnv.net.

Then when I fixed this issue, and re-ran bazel run :bazel_env, it showed
====== bazel_env ======

✔ direnv is installed
⚠ bazel_env's bin directory is not in PATH. Please add the following snippet to a .envrc file next to your MODULE.bazel file:

# Generated by 'bazel run //:bazel_env'
watch_file bazel-out/bazel_env-opt/bin/bazel_env/bin
PATH_add bazel-out/bazel_env-opt/bin/bazel_env/bin
if [[ ! -d bazel-out/bazel_env-opt/bin/bazel_env/bin ]]; then
    log_error "ERROR[bazel_env.bzl]: Run 'bazel run //:bazel_env' to regenerate bazel-out/bazel_env-opt/bin/bazel_env/bin"
fi

Then allowlist it with 'direnv allow .envrc'.

For some reason I thought to re-run bazel run :bazel_env, but I'm not sure if everyone would think to do that. So I wonder if people might miss the second setup step? I wonder if the first setup step could show all problems at once, or if it should suggest re-running the bazel_env target once direnv is installed.
Side note: my terminal doesn't render these emojis nicely :P

Ah, I needed to add the output of direnv hook bash to my ~/.bashrc. Might be useful to mention that in the error message? (I didn't fully read the install instructions from direnv)


dse url

I'm trying to create a dse cluster but I keep getting an invalid url error. I manually downloaded dse (mac) from the webpage so I had to register and I got a username and password. I'm using this username/password combination to create a cluster as below. I keep getting the same error with and without sudo.
./ccm create --dse --dse-username=my_usernaname  --dse-password=my_password test -v 2.0.5 -n 3 -s
Traceback (most recent call last):
File "./ccm", line 72, in
cmd.run()
File "/Users/icaste/gitext/ccm/ccmlib/cmds/cluster_cmds.py", line 124, in run
cluster = DseCluster(self.path, self.name, install_dir=self.options.install_dir, version=self.options.version, dse_username=self.options.dse_username, dse_password=self.options.dse_password, opscenter=self.options.opscenter, verbose=True)
File "/Users/icaste/gitext/ccm/ccmlib/dse_cluster.py", line 18, in init
super(DseCluster, self).init(path, name, partitioner, install_dir, create_directory, version, verbose)
File "/Users/icaste/gitext/ccm/ccmlib/cluster.py", line 51, in init
dir, v = self.load_from_repository(version, verbose)
File "/Users/icaste/gitext/ccm/ccmlib/dse_cluster.py", line 25, in load_from_repository
return repository.setup_dse(version, self.dse_username, self.dse_password, verbose)
File "/Users/icaste/gitext/ccm/ccmlib/repository.py", line 47, in setup_dse
download_dse_version(version, username, password, verbose=verbose)
File "/Users/icaste/gitext/ccm/ccmlib/repository.py", line 150, in download_dse_version
raise ArgumentError(msg)
ccmlib.common.ArgumentError: Invalid url http://downloads.datastax.com/enterprise/dse-2.0.5-bin.tar.gz (underlying error is: HTTP Error 404: Not Found)
Am I'm missing anything? Thanks!

Is 2.0.5 a valid version of DSE?

Not 100% sure if it is but I tried with a valid version (4.6.0) and the download succeeded. Thanks!

I have checked, and it is not a version. Good to hear 4.6.0 worked for you.


doc(guide/reactivity): object spread syntax

Thanks for the PR! To prepare for a smooth migration to v3, we're currently limiting changes made to v2 docs to critical issues only. Since yours doesn't appear to be one, I'd have to skip it for now.


Added devicetype provisioning script.

This script allows you to import or update exising devicetype record from Netbox's official devicetype-library git repository.
For more details and instruction, you may check this git repo.
Note: This scripts has dependency to two other folder found in the directory below:

reports/scripts/library
reports/scripts/template

library folder contains the custom class script device_type_handler.py to compliment the main script device_type_provisioning.py.
template folder contains the jinja2 template file for generating the script report summary output.

As netbox 3.5 pretty much did away with nested packages, I'm not sure it makes sense to merge this with seperate dependencies. Even without the nested part, using non-script dependencies in netbox 3.5 is messy as they either have to be uploaded in the UI and will show an empty script header or they will have to be sideloaded outside of the normal script feature.
The script looks fine though, but I worry that it's too complex to get working with the current status of scripts in netbox.

Thanks for the feedback. I totally agree with you as this one has been written for the older version. I'll be closing this PR and raise a new one as needed.