Hotspot Hardware Setup - Add note to never power on device while antenna is off

https://github.com/NebraLtd/Helium-Guides/blob/main/docs/indoor-hotspot/quick-start.md#preparing-your-nebra-indoor-hotspot
Add a note to never power the unit on without the antenna.

@suprnrdy does this cause some issue with Helium if you do? Or you just mean because it won't work properly?

@shawaj It's actually to protect the LoRa module as it can cause damage if ran without an antenna connected.

Fixed for indoor, leaving open to remember to put it in the outdoor's guide.

@shawaj It's actually to protect the LoRa module as it can cause damage if ran without an antenna connected.

Would it be possible to add a check for this in software? It does sound like an easy mistake to make when assembling it (e.g. not screwed in properly).

Not that I know of @vpetersson.

Yeah I thought that was a long shot, but just thought I'd ask. Any chance we could use a proxy for it, such as RSSI or similar?

I think the issue is any software route would mean the module turns on and then essentially is at the stage where it could cause damage.
I also don't think we could use RSSI / Signal strength and run a scan on boot as the hotspot is the gateway so it wouldn't have anything to scan in comparison to wi-fi.

Fair enough, @ryanteck.

Maybe there's a way to do it in hardware @ryanteck @vpetersson for a v2. Does seem like a bit of a pain for a consumer product.  But probably not as trivial as I'm making it sound of course 🤣
Something to consider anyway

I would guess this would be something that has to be designed into the mPCIe module rather than the gateways themselves so could be something that Milan could look into for that?

cc @mmilann

I'd say the risk is fairly low and it's been a common thing with any radio technology.
However we could for production get a little sticker over the power connector,

I'd say it's worth it. We're not selling to a lot of RF educated customers, so best warn them ahead of time. You can put the sticker next to the power plug.

No need to engineer a solution, just slap a warning sticker on it

Could be above or below yeah, I thought if over then they couldn't pretend to have not seen it.
Slightly smaller too maybe,

Yeah - and/or we could just print it on the plastic. But yes - i agree that would be good


Issue #7: Create Post interface

Created global interface named Post
Contains example of how to use an interface in typescript

Looks good except for the Date type in the interface. We want to store the posts as JSON objects, so we want to use primitive types instead of a complex type like Date. I'll make changes to it after merging into master

My bad about the confusion in the comments for issue #7. I forgot to update what I wrote before about using Date as a type before


Bridging Dart Exceptions with Isolates: Addressing the Incompatibility

When exploring the Dart standard library, it becomes evident that exceptions are the primary mechanism for handling errors. This approach works seamlessly in most scenarios—until you introduce isolates into the equation. Isolates rely on values to handle errors, creating a dissonance between the two paradigms.
This mismatch forces developers to write wrapper functions to convert exceptions into value-based errors to make them compatible with isolates. This process can be tedious and introduces unnecessary complexity, especially when working with existing Dart codebases.
A potential improvement would be enabling isolates to propagate exceptions back to the sender. This enhancement could significantly reduce the friction caused by this inconsistency, allowing for a more harmonious interaction between isolates and Dart's standard error-handling mechanisms.
Currently, this disconnect makes it cumbersome to leverage isolates effectively within Dart, particularly in projects that depend on exception-driven error handling.

Isolates rely on values to handle errors, creating a dissonance between the two paradigms.

Isolates rely on sending objects (errors are objects too) to communicate anything between different isolates.
Exceptions are control flow based. you throw them and they unwind the control flow stack until they are handled, or until reaching the top level where they too are treated as objects. (Asynchronous errors are also just objects until they are re-raised using an await.)
Different isolates do not share any control flow, so they can't communicate using thrown objects. So, yes, isolates communicate objects, by necessity.
What do you suggest to do?
The current Isolate.run does communicate errors back as as asynchronous errors in the returned future.
It's definitely possible to run a computation that returns a Stream in a different isolate and communicate back the events and errors. (The biggest question is whether to use messages or Isolate.pause/Isolate.kill for push-back, the rest is basic.)

@lrhn I have limited knowledge of Isolate so I might be doing something wrong.
I have a function Fibonacci that can throw errors.
I have a list of numbers that are all messages for Fibonacci
I want all of these computations to run in parallel so on different Isolte
List<Future> futures;
for (var message in messages) {
   var future = compute(Fibonacci, message);
   futures.add(future);
}
try {
results = Future.wait(futures)
} catch (e) {
    print("I lost everything if one fail!")
}

from my understanding if one of the Fibonacci calls throw I lose everything
I don't know any good way to await multiple futures and have a list of results and a list of failures on the other side.
My really ugly solution is wrapping Fibonacci into:
(int result, String error) FibonachiWithoutException(int message) {
try {
     return Fibonachi(message), null
} catch(e) {
   return 0, e.toString();
}
}

so I have a list of results and I can check if it's an error or a value (really golang style)
removing the need for FibonachiWithoutException is what I want

This doesn't seem to be about isolates, just got to combine multiple synchronous results.
You have a number of futures, where done may contain errors, and you want to combine those into a single result, somehow, that represents all of the results.
 The .wait extension operation on a List<Future<T>> will return a Future<List<T>> with all the results if nothing throws, or will throw a ParallelWaitError<List<T?>, List<AsyncError?>> which will contain the results split into errors and values (with a null at a position if the result of that future is in the other list).
Then you have all the results, and can decide how you want to continue with those.

@lrhn thanks for your great answer!

This doesn't seem to be about isolates, just how to combine multiple synchronous results.

await compute(Fibonacci, message); would result in no parallelism regarding computing values.
And from my understanding, because of exceptions, you should always await at the same time, all the future you have access to.
Because of this, I came up with this solution, but it's more about, "How to compute multiple values in parallel using Dart Isolate?"
I don't care about having all the results all at once, I would much prefer to get their results as soon as they are finished (with some clue of which message has been sent to them preferably) so I can show a progress indication for example or move to the next steps for those fast to compute values.
Do you see any more relevant way to compute multiple values in parallel?
I imagine some streams might be useful.

class _MyHomePageState extends State<MyHomePage> {

  @override
  Widget build(BuildContext context) {
    return DropTarget(
      onDragDone: _processDroppedFiles,
      child: Text("Hello world"),);
    }

  Future<void> _processDroppedFiles(DropDoneDetails dropDoneDetails) async {
    var pool = IsolatePool(4);
    await pool.start(); // never returns
    ... try to use the pool to work in parallel on the files
    }
}

You'd have the same issue here if compute started asynchronous computations in the same isolate, that run by interleaving instead of concurrently. You have a number of futures created at the same time, where you need to listen to the futures immediately (that's correct), and want to get the results when they're ready.
I would use a steam for that, if you don't need to know by the original order of the futures.

@lrhn Thanks again for this great explanation,
You are right that my issue was not about Isolates but what was the correct way to generate as many future as possible (concurent computation) while still beieng able to await them properly.
I'm not used to the future.then syntax and always use the await syntax instead but I just realize that they have totally different behavior! one is blocking while the other is not (that's really surprising to me, I was really thinking they were equivalent)
Let's take your example:
// Nothing to do on `.onListen`/`onCancel`/`onPause`/`onResume`, can't stop the computations anyway.
var controller = StreamController<int>(sync: true);
var onValue = controller.add;
var onError = controller.addError;
for (var message in messages) {
   var future = compute(Fibonacci, message);
   future.then(onValue, onError: onError);
}
var results = controller.stream;

if I was using await this would not behave the same!
var controller = StreamController<int>(sync: true);
var onValue = controller.add;
var onError = controller.addError;

Future<void> processMessages() async {
  for (var message in messages) {
    try {
      var result = await compute(Fibonacci, message); // It will only compute one at a time here!
      onValue(result);
    } catch (error) {
      onError(error);
    }
  }
}
var results = controller.stream;

Do you see any elegant equivalent using await, the await futures.wait is much less elegant than the future.then option.
I didn't knew it was doing different thing... how would you choose between when to use await vs the future.then syntax?

An await blocks a function call and waits for one future. It works as if it was calling a .then (because it is) with a callback that is the entire rest of the current function invocation, the "continuation" of the computation.
Since, as you pointed out above, you should do something to a future immediately, if the only thing you use is await, you'll immediately block and wait for that one future, and only continue when that asynchronous computation completes.
That makes your program single-threaded.
If you want to have concurrent computations, you need to do something other than just await'ing every future.
You don't have to use .then, you can also use async/await and just not await one of the futures.
For example changing the loop above to:
  ...
  void receiveResult(Future<T> future) async {
    try {
      controller.add(await future);
    } catch (e, s) {
      controller.addError(e, s);
    }
  }
  for (var message in messages) {
     var future = compute(Fibonacci, message);
     receiveResult(future); // Runs asynchronously, but is not awaited.
  }
 ...

There are many ways to run things in parallel, but they all require not immediately await'ing some future,
or using event kinds other than future completion (timers, streams, etc.)
Or just collecting a bunch of futures and using await [bunch, of, futures].wait to wait for all of them at once.
Which strategy to use depends on how you need the results.

thanks, @lrhn, our conversation was eye-opening to me.
Of all the strategies discussed, I think I like the most future.then because the elements are treated one by one as opposed to await [bunch, of, futures].wait and I'm not a fan of running async code without await because it can't throw (until I can because you change it later)


WIP: centosci-tasks-vkcj5: [no-test] Check for NPM dependency updates

Check for any outstanding update of point version of any outstanding NPM package dependency

[ ] npm-update

npm-update in progress on centosci-tasks-vkcj5.
Log: https://logs-https-cockpit.apps.ci.centos.org/logs/npm-update-916-20200326-070000/

npm-update react-dom done: https://github.com/cockpituous/welder-web/commits/npm-update-react-dom-20200326-070101

Please manually check features related to these files:
main.js:import ReactDOM from "react-dom";
package.json:    "react-dom": "16.13.1",


Built-in compatibility resource pack has wrong pack format

Shows as "built for old version" or whatever the error is in Minecraft. Pack format should be 15 for 1.20

Fixed with v1.2.1


Added radio button support to suppliers

Added radio button support to suppliers.

Coverage increased (+4.0e-05%) to 99.959% when pulling 1536f557824d37f4cb857ce4d6ee68aee7fc2a7d on radio-button-support into 9c97e32fb85ae8b4996bf34689a34b87ee917392 on master.


semantic highlighter labels await as an identifier

the semantic highlighter seems to think await is an identifier, and not a (contextual) keyword.

because sourcekit-lsp provides a classification (identifier) for await, instead of leaving it unclassified, this means it is not possible to override the highlight in vscode.

this might be related to modifiers being dropped from:
https://github.com/apple/sourcekit-lsp/blob/main/Sources/SourceKitLSP/Swift/SyntaxHighlightingToken.swift#L161
if there is more than one bit set at a time.

Which version of sourcekit-lsp are you using? await is highlighted correctly in recent the swift-DEVELOPMENT-SNAPSHOT-2022-06-16-a development snapshot for the following Swift file
func foo() async {}

func test() async {
  await foo()
}

on DEVELOPMENT-SNAPSHOT-2022-07-06-a, it is not highlighted correctly, when semantic highlighting is enabled:

if semantic highlighting is disabled, the fallback grammar comes into effect and await is highlighted correctly (but other syntax is no longer highlighted correctly.)

semantic highlighting is disabled by default in the swift vscode plugin, which is likely why there is less awareness of this issue.

related issue: https://github.com/swift-server/vscode-swift/issues/366

I just tried this as well and await is correctly highlighted for me with swift-DEVELOPMENT-SNAPSHOT-2022-07-18-a.

I don’t see any option to enable or disable semantic highlighting in the VSCode plugin. How do you enabled/disable it?
Also: How did you open the debug panels showing in your screenshots?

to enable semantic highlighting, set the editor.semanticHighlighting.enabled option to true, or use a syntax theme (like swift-madrid) that overrides the default setting.
see: https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide
to activate the token inspector, Ctrl-Shift-P and select the Developer: Inspect Editor Tokens and Scopes command

can confirm this is fixed in DEVELOPMENT-SNAPSHOT-2022-08-01-a. this was driving me nuts, thank you @ahoppen !


IMPORTANT Domain pyenv.run needs reissuing due to expired intermediate certs

curl https://pyenv.run | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: certificate has expired

Check:
https://www.ssllabs.com/ssltest/analyze.html?d=pyenv.run
Meanwhile users can:
curl https://pyenv.run | bash

You can solve this by removing the expired intermediates, rather than needing to reissue anything.
Your cert chain looks like this:
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=pyenv.run
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

You can remove certs 2 and 3, since clients should have the newer USERTrust certificate installed, which is now a root certificate.
Some more info on HN: https://news.ycombinator.com/item?id=23362759

This is fixed. Thanks for letting us know!


Switch to MapLibre

This is an experimental PR which swaps out the (actually now discontinued mapbox.js) in favour of MapLibre.
See also:

Discussion of bundle sizes
Question about Mapbox-GL-Leaflet
https://observablehq.com/@rkaravia/hello-swisstopo-light-base-map

Thanks Oleg for looking into this. I will check later today. Please also have a look at #51 and #52 for the overarching topic of how to re-organize configuration options.

Couldn't get it the vue part to work yet. How did you install the new dependencies inside the container?
In general: we are currently using the Mapbox Wrapper around Leaflet JS, not mapbox-gl. Since we only have very light vector rendering needs. Also, every vector based library comes with their own way of defining styles that are usually incompatible with our current snapshot spec approach which combines geometry and styling in the snapshot.resource. We also added circle layers specifically based on the Leaflet API. We either need to rethink the spec to add a layer of abstraction or build translators for old snapshots if we switch to a different approach.

Sounds like a topic we should do some guru meditation on soon. Have a nice
weekend!

I've moved the Docker changes from this PR into #67

We are working on maplibre-gl-leaflet at https://github.com/maplibre/maplibre-gl-leaflet. We plan to publish a package at @maplibre/maplibre-gl-leaflet on NPM. Maybe this can be useful for your project.

Continued in https://github.com/cividi/spatial-data-package-platform/issues/452.


Patch 1

My tagline and some other minor changes.
Alon.

:warning: Validation status: warnings

File
Status
Preview URL
Details

rd/alon-fliess.yml
:warning:Warning

Details

rd/alon-fliess.yml

[Warning] the value Profile is undefined for metadata pagetype

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


cgllc.airm.cgdn1 does not work after update

My  Qingping Air Monitor Lite (cgllc.airm.cgdn1) works fine via xiaomi_miot_raw.
Unfortunately yesterday it stoped work.
Please check it

Are there any errors in Home Assistant Logs?
Please try delete and re-add the device in hass.
If 2 doesn't work, try 0d51431 . The commit ahead it adds "device class" to sensor.
If 3 doesn't work, try a35a9db . The commit ahead it adds multi-sensor support.

I use config in configuration.yaml

platform: xiaomi_miot_raw
name: air_monitor_kitchen
host: <IP_ADDRESS>
token: xxx
mapping:
.......
Now I returned to 8aab7ec. It works but sometime device lost connection with HA.
Error log I could drop later

Logger: miio.miioprotocol
Source: /usr/local/lib/python3.8/site-packages/miio/miioprotocol.py:239
First occurred: 12:25:48 (2 occurrences)
Last logged: 12:26:38
Got error when receiving: timed out
Logger: custom_components.xiaomi_miot_raw.sensor
Source: custom_components/xiaomi_miot_raw/sensor.py:114
Integration: Xiaomi MIoT
First occurred: 12:25:48 (2 occurrences)
Last logged: 12:26:38
No response from the device
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:214
Integration: Сенсор (documentation, issues)
First occurred: 12:25:48 (3 occurrences)
Last logged: 12:26:38
Platform xiaomi_miot_raw not ready yet. Retrying in 30 seconds.
Platform rest not ready yet. Retrying in 30 seconds.
Platform xiaomi_miot_raw not ready yet. Retrying in 60 seconds.

It is a pity that you have to use such a old version. Some nice features were added recently. Does the sensor not work exactly after that version? Since I don't have that device, I have to go through all the commits to find out the problem.

After upgrade to fix version (4cdace2): id of object doesn't set correctly from YAML
{code}

platform: xiaomi_miot_raw
name: air_monitor_bedroom
host: <IP_ADDRESS>
{code}
After apply and restart In HASS UI id of object is sensor.none_4

5181760 should fix. But the object id will not change unless you delete it from entity registry.

5181760 should fix. But the object id will not change unless you delete it from entity registry.

Thanks, 5181760 works fine

@LeoI5 Does it work for you now?

@ha0y I removed old installation of integration and reinstalled it.
After adding device it is not available.
There is a error:
Logger: custom_components.xiaomi_miot_raw.deps.miot_device_adapter
Source: custom_components/xiaomi_miot_raw/deps/miot_device_adapter.py:164
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:08:54 (1 occurrences)
Last logged: 22:08:54
'NoneType' object has no attribute 'values'
Logger: custom_components.xiaomi_miot_raw.deps.miot_device_adapter
Source: custom_components/xiaomi_miot_raw/deps/miot_device_adapter.py:331
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:08:54 (1 occurrences)
Last logged: 22:08:54
'NoneType' object has no attribute 'get'
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:602
Integration: Сенсор (documentation, issues)
First occurred: 22:10:17 (1 occurrences)
Last logged: 22:10:17
Updating xiaomi_miot_raw sensor took longer than the scheduled update interval 0:00:05
Logger: custom_components.xiaomi_miot_raw
Source: custom_components/xiaomi_miot_raw/init.py:546
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:09:07 (14 occurrences)
Last logged: 22:10:18
Got exception while fetching zxc 's state: Unable to parse message payload

@ha0y
I removed old installation of integration and reinstalled it.
After adding device it is not available.
There is the errors:
Logger: custom_components.xiaomi_miot_raw.deps.miot_device_adapter
Source: custom_components/xiaomi_miot_raw/deps/miot_device_adapter.py:164
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:08:54 (1 occurrences)
Last logged: 22:08:54
'NoneType' object has no attribute 'values'
Logger: custom_components.xiaomi_miot_raw.deps.miot_device_adapter
Source: custom_components/xiaomi_miot_raw/deps/miot_device_adapter.py:331
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:08:54 (1 occurrences)
Last logged: 22:08:54
'NoneType' object has no attribute 'get'
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:602
Integration: Сенсор (documentation, issues)
First occurred: 22:10:17 (1 occurrences)
Last logged: 22:10:17
Updating xiaomi_miot_raw sensor took longer than the scheduled update interval 0:00:05
Logger: custom_components.xiaomi_miot_raw
Source: custom_components/xiaomi_miot_raw/init.py:546
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:09:07 (14 occurrences)
Last logged: 22:10:18
Got exception while fetching zxc 's state: Unable to parse message payload

Just now I updated integration to f13e278 and found error:
Logger: custom_components.xiaomi_miot_raw
Source: custom_components/xiaomi_miot_raw/init.py:546
Integration: Xiaomi MIoT (documentation, issues)
First occurred: 22:49:41 (6 occurrences)
Last logged: 22:50:06
Got exception while fetching zxc 's state: Unable to parse message payload

The Unable to parse message payload is not a common error. It is usually caused by that the device didn't return a correct JSON format. Please follow the readme and enable miio debug log to see what the device returned. Since not every user encounters this error, updating your firmware may solve the issue.

It seems that the issue was solved and another problem raised. If the problem persists, open a new issue.


Update afinn111.json

Remove bad/slur words. Hopefully I got them all.  (Also removed a couple that were not really words.)

Thank you! I renamed the file, added a code comment, and also updated the code file headers.


First pass at mem functional model

Right now this just implements SRAM mode and hooks it up to the existing genesis test. It's basically the same interface to the plain Python dictionary we used originally, but also exposes the abstraction for configuration.
Some issues that came up when implementing this:

Do all functional models need to implement a __call__ method?  Right now it's an abstractmethod so it forces this. I originally planned to write the memory using a read and write interface, but the __call__ method could be used to a implement a lower level interface (e.g. cycle-level abstraction using the input ports to the circuit). More generally, this raises the question as to what level of abstraction these functional models should be implemented? This proposed implementation is very high level. For the SRAM, it uses a dictionary mapping address to value and exposes read and write. Instead, I could implement an interface that takes in the rdata, raddr, ren signals and a clock, and mimics the cycle level behavior. A cycle level implementation seems useful for automatically generating tests of the RTL, but a higher level implementation seems useful for specification and documentation. Perhaps we should have both with a strategy for connecting the two models?
config interface. It seems like for this model, the config address we're interested in is always 0 (stores mode, enable, depth, almost count, and enable chain). What is the usecase for exposing other configuration addresses? Does it make sense to just provide the config_data for the model if it's only using one address? Basically, abstract away the notion of address, so this could be decided by some other process.

Pull Request Test Coverage Report for Build 334

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.035%

Totals

Change from base Build 324:
0.0%

Covered Lines:
134

Relevant Lines:
141

💛  - Coveralls

Also, the pattern based on the connection box is to define a factory method that returns a functional model that can be instantiated. I'm guessing this is to mimic the generator/module flow used for the actual hardware. I think this is okay, but it seems like there can be some confusion as to where certain parameters/state should be held.
For example, data_width and data_depth are available in the closure for the factory method, but I decided to store data_depth for use in a helper decorator that I defined. I don't think this is really a user facing issue, but we should be clear about how functional models should be written with respect to this generator pattern.
Take mode for example, in this case, I made it match the implementation by having mode be a setting in the instantiation of the functional model. This would suggest that in theory it would be possible to change modes after instantiation (which reflects the hardware). However, another approach might be to instantiate the functional model with a fixed mode, for the duration of a test. This might more accurately reflect the model where the hardware unit is configured once, and stays in that mode for the duration of the execution. Perhaps this notion could be abstracted somehow into the configurable model abstraction

Good points. I think the heart of all of these issues is fundamentally, the differentiation between a "logical" vs. "bit-level" specification or model. This is similar to what I was talking about in my PE presentation (and of course is not new, all high level languages provide an abstraction on top of bits, even verilog). I do think there is probably a nice way to incorporate both levels of abstraction in the same "place". For example, overloaded pack/unpack (to/from bits respectively) functions on data types could be one way to do this. The combination of a bit-level model + pack/unpack functions fully specifies both levels of abstractions.
For now, however, I think our methodology can be to hand-craft two different types of models. They can use some common core elements, if it makes sense, and the documentation/naming should make very clear what exactly a class is modeling.
To drill down on your specific points:

I think __call__() should have two different meanings. For purely combinational circuits, it should return the evaluation of the circuit given a set of inputs. For stateful circuits, it should represent one tick of the clock with the given inputs. This should be a useful paradigm for most circuits. I think trying to define an interface formally will be hard. For example if things happen on both pos and neg edge of the clock. We don't want to reinvent SystemC or SystemVerilog. We could look into this for more complex things: https://pypi.org/project/sydpy/. The upshot is, for simple modules we should be able to write simple python classes/functions for fn models. They need not follow a single standard however, IMO.
For config, in general, we could expose functions like config_x(x_val) and config_y(y_val) or have a single fn like config(addr, data). Again, I think these correspond to 2 different levels of abstraction. For now I think we should stick to the bit-level one, so config(addr, data), so we pack all bits into a 32bit word, and the internals of the model can interpret it.
One thing that I do think is clear is that generator params should be part of an outer function that match exactly the RTL generator interface (as much as possible). And the generated model/class should have the same IO as the generated RTL module. Perhaps I'm missing something.

As I think more about this, I think the right path is: for now stick to bit-level interfaces as much as possible. Though it makes development harder, it makes the resulting tests more thorough. We can always abstract back up one level. It also makes it less likely for matching errors to occur, i.e. errors where our tests become trivially correct because we wrote the tests that way. It's better to err on the side of false negatives. Ideally, in the future, everything user-facing will be at a higher level of abstraction (e.g. high level fn model tests a high level RTL spec).

I'm working on a bit/cycle-level implementation as you described, I've rebased this branch on https://github.com/leonardt/fault/pull/15 so I won't conflict with those testing related changes, so this pull will need to be handled after those.

For now I changed the base to the dependent branch.

In order to get the test to pass the wen and ren in the same cycle, I had to update the sram_stub.v to match the behavior noted in the memory spec google doc, specifically:
 In the case that both read enable and write enable are asserted the output data is the data written in the same cycle (not the previous value).

This meant reordering the statements in the always block so the data is written before the read.  Can we confirm that this is the expected behavior?

In the case that both read enable and write enable are asserted the output data is the data written in the same cycle (not the previous value).

This might have changed. Let me double check and get back on this.

4108e2a renames mem to memory_core in the folder/file structure.

Closing this for now, going to try a bottom up approach of testing each individual module, then I'll integrate those functional models with this top-level one.


FAQ Entry "Can you persist cache between restarts" seems outdated

https://github.com/memcached/memcached/wiki/ProgrammingFAQ#can-you-persist-cache-between-restarts
But there's also https://github.com/memcached/memcached/wiki/WarmRestart saying:

Memcached 1.5.18 and newer can recover its cache between restarts. It can restart after upgrades of the binary, most changes in settings, and so on. It now also supports using persistent memory via DAX filesystem mounts.

Fixed, thanks!
That wiki page looks a bit out of date... should give it a scrub soon.


fix(@angular-devkit/build-angular): revert performance optimization causing regression

This reverts commit 10200f1395229032caebf98d92a32ba4c975a96f.
The optimization was causing regression because we didn't cherry-pick https://github.com/angular/angular-cli/pull/14419 in patch.

Superseded by https://github.com/angular/angular-cli/pull/14853


cxxstandard is not respected for tests

Describe the bug
cxxstandard in scargo.toml is not interpreted correctly for tests.
To Reproduce

Add cxxstandard = "17" to scargo.toml under [tests].
scargo update
Note SET (CMAKE_CXX_STANDARD 17) is not present in tests/CMakelists.txt.
Change line in scargo.toml to CMAKE_CXX_STANDARD = "17".
scargo update
Note CMAKE_CXX_STANDARD is set correctly.

Expected behavior
cxxstandard = "17" should work the same way as for the build profiles (setting CMAKE_CXX_STANDARD explicitly is a confusing workaround).

@rap-spyro

Add cxxstandard = "17" to scargo.toml under [tests].

Is it required that tests have a separate cxxstandard setting? Currently they don't, which can be seen in the documentation: https://spyro-soft.github.io/scargo/scargo/scargo-toml.html#tests
Maybe it's enough to reuse cxxstandard defined under [project] for tests?

It is possible that for the embedded target we would like to set a different setting, but I don't think it's needed at this point. Main issue is that it's not set for tests at all for now, so if you have a fix for that - reusing it would be enough.


Use the atom-text-editor tag instead of the editor class.

In keymaps/cowsay.cson: Use the atom-text-editor tag instead of the editor class.

Solved in v0.2.0


ktlint: 0.47.0 -> 0.47.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/pinterest/ktlint/releases.
meta.description for ktlint is: "An anti-bikeshedding Kotlin linter with built-in formatter"
meta.homepage for ktlint is: "https://ktlint.github.io/"
meta.changelog for ktlint is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.47.1 with grep in /nix/store/im9pxij4khldsi31mfvphbxh8z7apxlh-ktlint-0.47.1
found 0.47.1 in filename of file in /nix/store/im9pxij4khldsi31mfvphbxh8z7apxlh-ktlint-0.47.1

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
ktlint
uniffi-bindgen

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/im9pxij4khldsi31mfvphbxh8z7apxlh-ktlint-0.47.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 ktlint https://github.com/r-ryantm/nixpkgs/archive/03154daf6ea76d7b6363b3c1fc447ed12d07c783.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/im9pxij4khldsi31mfvphbxh8z7apxlh-ktlint-0.47.1
ls -la /nix/store/im9pxij4khldsi31mfvphbxh8z7apxlh-ktlint-0.47.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

2 packages built:

ktlint
uniffi-bindgen

Maintainer pings
cc @tadfisher @SubhrajyotiSen for testing.

Result of nixpkgs-review pr 190338 run on x86_64-linux 1

2 packages built:

ktlint
uniffi-bindgen


Peak index in a mountain

Is your feature request related to a problem? Please describe.
I want to add a solution to the problem "Peak index in a mountain".
What is a mountain array?
A mountain array is an array which is increasing in the first part and then decreasing in the second part.
The peak element is that which is the largest element in the array. Suppose i is the the index of peak element, then:
arr[0] < arr[1] < ... < arr[i - 1] < arr[i] > arr[i + 1] > ... > arr[arr.length - 1]
Example:
Input: arr = [0,3,5,7,10,8,4,3,2]
Output: 4 (index of 10)
Describe the solution you'd like
I would like to solve this problem by using a modified version of Binary Search.
Please assign this issue to me in C++, I am willing to work on it!

@Kumar-laxmi please assign me this issue in C.

@Kumar-laxmi Please assign me this issue in java


Bibliography sections on target profile page and disease profile page not loading

Description
The Bibliography sections on the target profile page and disease profile page are not loading properly. Instead, the UI displays an empty space and the console log identifies a number of errors.
Platform interface:

Browser console log:

Environment:
Safari, Chrome, Firefox

Likely related to https://github.com/opentargets/platform/issues/444.

I think library/link has recovered to a point where this problem is solved. Please re-test and confirm.


Can't install ruby_dep because ruby_dep itself needs Ruby >= 2.2.5

Locally I am using Ruby 2.2.4, however when I do a bundle install ruby_dep raises an error saying it needs ruby >= 2.2.5 because of the constraint in its own gemspec. which in turn reads .travis.yml.
This dog fooding, while cute, means I can't install ruby_dep locally on anything other than Ruby >= 2.2.5m forcing an upgrade.
I assumed setting export RUBY_DEP_GEM_SILENCE_WARNINGS=1 would work, but it appears not too.
Many thanks.

If your setup prevents Bundler from falling back to a supported
version of the gem, lock to RubyDep '~> 1.3' and you should be fine.
That's if you can't upgrade for some reason.
Also, for dependency handling see here:
https://github.com/guard/listen/wiki/Ruby-version-requirements
If you can spare a moment, let me know why you can't upgrade (if
you're stuck or something). I can relax the dependency if there's are
real technical need.
https://www.ruby-lang.org/en/news/2016/04/26/ruby-2-2-5-released/
And the list of fixes and improvements:
http://svn.ruby-lang.org/repos/ruby/tags/v2_2_5/ChangeLog
E.g. previously, Ruby 2.2.4 was supported because JRuby wasn't
released with a 2.2.5 equivalent.
Upgrading Ruby should ideally be as easy as upgrading gems like
RubyDep. I get that on server farms upgrading Ruby may be expensive,
though it shouldn't be more expensive than installing/updating
multiple gems.
Whenever you're installing gems, you usually want either one of 2
things:

Installing exact, known, working version locked by patch-level.

Installing the latest possible gems for development, to reduce
upgrading work when it is less expensive to do sooner.

I'm interested in your situation, because decisions like these are
tough. No one wants to be forced to upgrade. Some people get angry
even if they're forced to upgrade a version of Ruby that is
vulnerable.
I'd rather work on helping you easily upgrade your Ruby version or
help contribute to Bundler so upgrading is painless.
Sorry for the issues. I'm still wondering how to deal with this.
I think it's better for me to make a mistake that you can overcome,
than for you to be forced to upgrade Ruby at a very inconvenient time
due to a Ruby bug or vulnerability.
The Ruby 2.2.4 support was dropped because of JRuby 9.1.x series has
been around already and 2.2.5 and 2.3 are usually already provided by
Amazon and other hosting companies.
Thanks for letting me know.
On Fri, Aug 12, 2016 at 01:27:55AM -0700, Kris Leech wrote:

Locally I am using Ruby 2.2.4, however when I do a bundle install ruby_dep raises an error saying it needs ruby >= 2.2.5 because of the constraint in its own gemspec. which in turn reads .travis.yml.
This dog fooding means I can't install ruby_dep locally on anything other than Ruby >= 2.2.5m forcing an upgrade.
I assumed setting export RUBY_DEP_GEM_SILENCE_WARNINGS=1 would work, but it appears not too.
Many thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/e2/ruby_dep/issues/20

OS X 10.10 (current version) still comes with ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]. I've been tripped now because the listen gem depends on this, and even though it installs fine on this ruby, through this dependency it is now tied to a newer ruby.
So I think it's kind of ironic that the tool to declare the dependencies has stricter version constraints that the original tools.
So please relax these constraints.

If OS X 10.10 has an outdated version of Ruby, I don't work at Apple
to be able to change that.
People should install a maintained version of Ruby. I don't use OSX,
so I don't know about the installation options (Brew?).
Updating Ruby should ideally be just as easy as updating a gem.
Especially since Ruby more-or-less follows SemVer. (Except on the
C-side and perhaps for bug fixes that need API changes).
Another thing is: newer versions of Bundler should automatically
resolve to older versions of RubyDep and Listen.
If it's impossible to satisfy those dependencies, let me know.
Please support the ongoing work on Bundler, so that dependencies like
these can be resolved automatically. (Try a pre-release version of
Bundler).
There are also options to avoid the stock version of Ruby on any OS:
rbenv, RVM, Brew, setting your own variables, etc.
You also probably don't need to upgrade Listen if you don't need to
upgrade Ruby. Because it makes no sense to avoid Listen bugs (which I
can backport to older versions if needed - just ask) and yet opt-into
known Ruby interpreter bugs and vulnerabilities that will never be
fixed.
I'm more than eager to relax the constraints if there's a specific
important business case for it. E.g. outdated EC2 images on an
important hosting provider, unable to upgrade Bundler, needed JRuby
versions unaffected by vulnerabilities, etc. (But all of these have
been already handled).
Relaxing the constraints doesn't seem to solve the real problem.
If Bundler can't install, it's a Bundler issue - unless Bundler cannot
find a combination of gems to fit your constraints.
A better solution is to backport the fixes you need to an older
version of Listen. But you have to tell me what you need, so I can
carefully prepare a minimal-change release without breaking anything.
On Sun, Aug 21, 2016 at 11:08:09PM -0700, rekcäH nitraM wrote:

OS X 10.10 (current version) still comes with ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]. I've been tripped now because the listen gem depends on this, and even though it installs fine on this ruby, through this dependency it is now tied to a newer ruby.
So I think it's kind of ironic that the tool to declare the dependencies has stricter version constraints that the original tools.
So please relax these constraints.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/e2/ruby_dep/issues/20#issuecomment-241322158

Upgrading Ruby should ideally be as easy as upgrading gems like
RubyDep

Well it isn't. Don't forget you are dealing with a wide range of users, some who are experts, some who are just starting out -- for those users even installing Ruby can be a challenge, let alone upgrading it. And even if upgrading Ruby were easy it isn't always something that people have time to do right at that moment.

I'm more than eager to relax the constraints if ...

Stop. Back up. IMHO the only reason for constraints is that they are actually required to make the  thing work. If you think that people need to upgrade because you think they should -- for whatever reason, including security -- you have it backwards.
Making my (many) Ruby installations secure and bug-free is my problem. Let me handle it.

If installing or upgrading Ruby is a challenge on OSX, I can't help
because I don't have or work on OSX to help fix that issue.
If someone has a cold and they're coughing, the solution isn't to just
cover their mouth because "it's easier".
And just as people don't have time to upgrade Ruby (5 minutes?) I
don't have time to spend weeks supporting and testing an outdated Ruby
versions just because they don't have 5 minutes.
Most people don't understand the cost of compatibility - codebases end
up complex, dead and no one wants to maintain them if there's a burden
that using X "won't work on an older version of Ruby".
Overall, there are many reasons for not supporting older Rubies -
mostly because it's VERY expensive in Listen to GUARANTEE
compatibility with non-current Ruby versions.
That word "GUARANTEE" is important for some people. And because it's
important for some, I can't make it so they have what they want and
you're not affected.
Maybe frontend web developers don't care, because if something doesn't
work they can just report/complain in the issues (which I would have
to find time to respond to - as opposed to doing more useful work).
By reducing the supported Ruby versions I can continue to maintain and
quickly respond to issues people have with gems like Listen.
 They're mine, whether I want them
or not.
Listen needs another rewrite - except that I don't want to support
Ruby 1.8 syntax (too much work, too much frustration and the solution
is upgrading Ruby). Not supporting Ruby 1.8 is fair. Dropping support for
1.9 is also fair. Turns out ... dropping support for < 2.2.5 is also
fair due to security issues.
Turns out ... dropping support for 2.2.x would be beneficial, but
2.2.x is still officially supported.
And it turns out - there are no compelling reasons to support older
Rubies.
If there are bugs in Listen due to threading issues in a given Ruby
version ... you're not the one who is going to get notifications about
bug reports.
For Listen to support any Ruby version, I'd have to support EVERY
version.
And that's not fair given my limited time, especially since there's no
payoff neither for me nor anyone else.
The solution here is to make a friendlier Ruby installer/upgrader for
OSX. I don't see how relaxing constraints here helps such a project
come about.
Also, spending 5 minutes upgrading is better than spending 5 hours
debugging a known Ruby bug fixed by an upgrade.
Meanwhile, people are going to have to upgrade their Ruby anyway (at
some point). So it's better to find 5 minutes now than to be forced to
upgrade at a much more inconvenient time.
Again, people can choose to NOT upgrade Listen and/or RubyDep.
In short: the constraints are saying: "these are the supported
versions of Ruby - using any other version is too risky for
production".
I'm not forcing anyone to upgrade RubyDep or Listen. It's a choice,
just like upgrading Ruby or not.
What you're effectively asking for is: for me to spend extra time to
make sure things work on an older version of Ruby.
And I don't see a good reason to do that. I offer backporting and
quick releases upon request (in case someone is seriously stuck with
an older version and not viable way to upgrade their cluster or
something - and in that case I want to know the exact bug, so I can
make sure it's well tested to avoid adding to the frustration).
Summary: relaxing constraints isn't a good solution to anything (you
can prove me I'm wrong based on a specific use case). It just fools
users into thinking their Ruby version is supported when it officially
isn't. And THAT can cause a lot more grief than the "inconvenience" of
not being able to upgrade Listen without upgrading Ruby.
Solutions:

Bundler should fall back to a version of RubyDep+Listen to match
your Ruby version. Try upgrading Bundler if this doesn't work. If
this still doesn't work, try upgrading to a pre-release of Bundler.
If that still doesn't work, help out in the Bundler project -
there's a fantastic team that's working on that feature right now.

Upgrade Ruby. If you have time to upgrade Listen/RubyDep, then
it's also the best time to upgrade Ruby. The sooner, the better.
Especially with the bugfixes, speed improvements, syntax
improvements, etc.

Lock to an older version of Listen which doesn't rely on RubyDep.

Ask for backports if you're stuck with a given version of Ruby
and there's a bug you need fixed in Listen. This is probably want
you want if you want to deal with vulnerabilities and bugs yourself.

Provide a specific real-life business scenario where you're stuck
and how none of the above are acceptable.

Release your own version of Listen/Rails without the
check/dependency. Yes, it's troublesome, but if the above solutions
don't fit you, your situation is already incredibly demanding.

Support the Listen project in some way so that older versions of
Ruby stay supported. I don't recommend this option at all - it's not
worth the attention.

On Fri, Aug 26, 2016 at 02:55:54PM -0700, Tom Head wrote:

Upgrading Ruby should ideally be as easy as upgrading gems like
RubyDep

Well it isn't. Don't forget you are dealing with a wide range of users, some who are experts, some who are just starting out -- for those users even installing Ruby can be a challenge, let alone upgrading it. And even if upgrading Ruby were easy it isn't always something that people have time to do right at that moment.

I'm more than eager to relax the constraints if ...

Stop. Back up. IMHO the only reason for constraints is that they are actually required to make the  thing work. If you think that people need to upgrade because you think they should -- for whatever reason, including security -- you have it backwards.
Making my (many) Ruby installations secure and bug-free is my problem. Let me handle it.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/e2/ruby_dep/issues/20#issuecomment-242861522

@e2 that is a well-considered, thoughtful argument, and I appreciate the work you put in to it. There are only a couple of points where I disagree:

dropping support for < 2.2.5 is also
fair due to security issues.

How so? If there is no other reason (like workload), I don't agree that this makes sense. Basically you are deciding that anyone who uses the gem should agree with your judgment vis-a-vis security. That smacks of paternalism.
I don't think any user would blame you for a security problem that they brought on themselves. You could certainly recommend that users upgrade their Ruby version, but to make it a requirement is just annoying.

5 minutes

5 minutes to install Ruby? Sure, on my development system, under ideal circumstances. It's not that it's hard to do, its that the decision to move up to a later version is a whole lot more complicated than how long it takes to install on one machine. We're dealing with multiple systems, multiple platforms, multiple projects, all of which have to be tested with a new version before we are ready to make that jump. It isn't just this gem --- open source projects move at different speeds, and we may have to hold back until other gems are working.
I appreciate your hard work in building open source software. We probably don't say that enough.

Thanks - much appreciated.
It's not about paternalism. It's about resolving the conflict between
doing what the experts expect (no one has time to track thousands of
vulnerability mailing lists) vs not making things harder for users.
Paternalism would be if I didn't give people a way out.
Here, no one is forcing anyone to upgrade Listen. If someone decides
they want to keep a vulnerable Ruby, it makes sense to also keep an
outdated buggy or even perfectly adequate version of Listen.
Wanting the newest Listen and not wanting the newest Ruby - that's an
unreasonable demand. Demands like that take a huge toll on
contributors, who spend sometimes hundreds of hours supporting a Ruby
only because some business can't afford to find 20 minutes to test and
deploy a cluster of 5 servers.
Mostly it's unfair to the Ruby core developers - they spend an insane
amount of time investigating and fixing bugs, while also developing
lots of valuable features.
A huge amount of time is spent for backward compatibility. The upgrade
from Ruby 1.8 to Ruby 1.9 is probably a thousand times more
challenging than from Ruby 1.9 to Ruby 2.4.
I wouldn't call it a "jump", it's more like "agrophobia". Fear of
being bitten by issues while not being terrified of the existing old
bugs and waste in productivity and opportunities. (And an upgrade will
be inevitable anyway, so why not get it over with sooner and reduce
the business risk down the road?).
(That's because of all the time put into decision making - just check
out the ruby-dev mailing list or the issue tracker or the change
history between versions).
Every time an expert or business upgrades to a newer Ruby, they risk
maybe 10 new problems (and maybe 8 occur immediately and are
straightforward to fix), but they save themselves thousands of hours
dealing with headaches - now and in the future.
So a Ruby 2.4.0 project will likely support a Ruby 1.9 project pretty
well (given the years and unthinkable amounts of hours spent on fixes,
improvements and new features).
I'd say the only reason not to use the main development branch of Ruby
is: sometimes it exposes too many bugs (or too many cases of poor
coding) in existing projects. And not all of them are high priority
(and it may take time until gem authors catch up).
But for every released version of Ruby, it's a no-brainer. Less bugs,
faster tests, catching code smells sooner (while the person who
created them is still hired and available to fix it), productivity
increases (new Ruby warnings, frozen string literals, immutability,
better APIs, new APIs).
It's actually a major issue if gems don't work on a newer released
Ruby. So my policy is: lightning-fast releases whenever possible.
I believe that if a business can't adapt quickly, it won't survive
long. This includes upgrading Ruby.
The only case for not upgrading Ruby is: if it affects time-to-market.
And in that case, upgrading Listen doesn't make sense either.
This means: if some gems aren't keeping up right now, it's only going
to get worse in the future. (So it's better to support them to move on
to newer Ruby versions, so new maintainers can step in and everyone
wins in the end).
The reason to make it a requirement is: so new Ruby features can be
used in Listen. Not every new Ruby feature can be easily reimplemented
for an older version, and the maintenance costs of doing so are huge.
I can't count the hours and frustrations from accidentally using a
JSON-style hash syntax or splat argument syntax on code that was
supposed to be Ruby 1.8 compatible. (Result: broken builds, crashes
during run time, hours of rebasing, amending, squashing, commenting,
dealing with duplicate issue reports, waiting for tests to finish,
delayed releases, etc - all 100% wasted effort with no benefit to
anyone).
Also, unless there's a requirement up front, I may get lots of bug
reports about crashes on Ruby 1.8, etc. Many users are web developers
who accidentally use officially incompatible Ruby installations and
"syntax error" isn't instantly obvious to them that their Ruby is
outdated. (Or that they're accidentally running a stock version of
Ruby). And that means the issue tracker gets polluted with irrelevant
bugs, duplicates, lots of email notifications, discourages users from
searching the issue tracker, interruptions, wasted time, etc.
Meanwhile on servers, you won't see it if it's just "a warning" - and
that's where it's better to crash on startup than 5 hours after people
have gone home to their families after launching.
So instead of quietly letting Listen potentially fail during startup
on an important server cluster, the "requirement" is really saying "if
your Ruby version doesn't match, you have to consciously disable the
requirement and test it properly yourself, because I can't guarantee
it will work".
Backward compatibility often means that everyone is terrified to
change a single line of code. Then it soon takes top experts to fix a
bug without breaking the world. That's how projects (and whole
frameworks) die.
And top experts have zero time nowadays. So little time, that they get
annoyed even if it means upgrading their Ruby, no matter how
beneficial and inevitable that is anyway.
So annoying you is not something I want, but I can't think of a
solution with less downside for everyone.
I would really rather spend time helping you automate your deployments
with e.g. Docker and automated acceptance tests, so that you can both
quickly test a Ruby upgrade ... and ... deploy it just as fast.
I'd also rather spend time upgrading and maintaining other gems you
have issues with - than allowing installs on outdated, unsupported
Rubies.
If testing really is that expensive, you could consider just bundling
a given Ruby version with your software. (Sounds insance, but it has
lots of surprising upsides as well).
On Mon, Aug 29, 2016 at 04:43:45PM -0700, Tom Head wrote:

@e2 that is a well-considered, thoughtful argument, and I appreciate the work you put in to it. There are only a couple of points where I disagree:

dropping support for < 2.2.5 is also
fair due to security issues.

How so? If there is no other reason (like workload), I don't agree that this makes sense. Basically you are deciding that anyone who uses the gem should agree with your judgment vis-a-vis security. That smacks of paternalism.
I don't think any user would blame you for a security problem that they brought on themselves. You could certainly recommend that users upgrade their Ruby version, but to make it a requirement is just annoying.

5 minutes

5 minutes to install Ruby? Sure, on my development system, under ideal circumstances. It's not that it's hard to do, its that the decision to move up to a later version is a whole lot more complicated than how long it takes to install on one machine. We're dealing with multiple systems, multiple platforms, multiple projects, all of which have to be tested with a new version before we are ready to make that jump. It isn't just this gem --- open source projects move at different speeds, and we may have to hold back until other gems are working.
I appreciate your hard work in building open source software. We probably don't say that enough.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/e2/ruby_dep/issues/20#issuecomment-243291226

People should install a maintained version of Ruby.

We would love to install a newer version of Ruby. Unfortunately there isn't a released rvm version that enables us to deploy 2.2.5 to our machines. So because this project and the most popular ruby version manager are out of step, we're now unable to run bundle update to keep our dependencies up to date. That is kind of a counterproductive result: we want to be up-to-date with at least our gems, but can't be.

Unfortunately there isn't a released rvm version that enables us to deploy 2.2.5 to our machines.

If the RVM release is behind, you can fork RVM, branch it and install from your branch,e .g.
rvm get branch Confusion/my_branch

Sure, and apart from me, all users of gems depending on ruby_dep would have to do that, resulting in a lot of aggregate effort. On top of that, it's hard for all of them to judge whether perhaps there is a good reason (open bug in one of the last commits) for the code not to have been released yet. So I don't think that solution quite works.

@Confusion - good points, thanks.
**TL;DR - I didn't want to suggest forking is easy and effort-free ... I'm saying that may be the only option left: for some one to either find a way to help that project, or heroically take things into their own hands. **
Ruby 2.2.5 has been released 5.5 months ago. If RVM can't support it, obviously there aren't enough maintainers available there. So maybe that project needs help.
If a project isn't responsive (or crushed with issues/work/etc.), that's be best thing we can do: fork and take on the "ungrateful" role of maintainers. It's like everyone is silently waiting for someone else to pick up the project and help out.
I have spent time debugging RVM and solving all kinds of horrible shell/path issues (which sometimes weren't RVM's fault at all), but I was ok doing that and glad that I didn't have to be an RVM maintainer.
Nowadays there's more value in having contributors as opposed to users. Even opening up issues is a big thing.
Sometimes the most valuable contribution is helping get to the core of the problem (no matter which gem it ends up being). Many "easy" issues are actually complex and tough to solve elegantly.
I rely on issues to know people are having problems. Because for every issue reported, there are at least tens of users who won't bother to report, but will complain wherever else possible.
Sidenote: The RVM author was badly burned out at some point and had to step down.

TL;DR:

I've just reworked the README to help solve issues: https://github.com/e2/ruby_dep/blob/master/README.md
I can support 2.2.4 if there's a clear issue installing 2.2.5 and locking versions is expensive for someone. Please open a new issue with the use case if so.

Thanks to everyone here for the feedback. It obviously helped me a lot!
@krisleech - thanks for reporting this. The reason 2.2.4 was dropped is that I couldn't think of a scenario where 2.2.4 was necessary, given the list of bugs fixed in 2.2.5. It's not a massive upgrade in terms of features, so it can only "work better".
2.2.5 installation problems in RVM is something I didn't know about. Can someone point me to an issue there?
It seems silly that RubyDep doesn't support < 2.2.5, but with Ruby 2.4 being developed it just shows that there will be 3 minor-level versions of Ruby in play out there.
I am considering adding 2.2.4 support if there's a compelling reason (e.g. RVM issue) - so I know exactly when to drop support again.
On the flip side, I'm not going to bump the Ruby 2.2.5 requirement, unless there's a very strong reason there too. (I doubt there will be).

It turns out I was wrong: I thought the output of rvm list known was authoritative, but it isn't. Although rvm doesn't list 2.2.5 as a known Ruby, it can install 2.2.5 just fine, because it is available in the 'expected location'.


Changes to Characteristics get lost on restart of BLE Device

What is happening is that I write and read successfully till the BLE Device remains open i.e its not restarted , the change shows properly in read. i.e suppose i write wifi ssid as 'aaa' and read it after some time it works fine.
But when the device is restarted and i read again the change is lost and I read the value that I wrote to the BLE the first time.
Plugin - Flutter Blue

Is this happening on both Android and iOS devices?

Man This is not the exact issue , what is happening is device is getting
connected properly and after that discoverServices() function gives an
error.
On Fri 22 Feb, 2019, 6:24 PM Daniel Duvanå<EMAIL_ADDRESS>wrote:

Is this happening on both Android and iOS devices?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pauldemarco/flutter_blue/issues/184#issuecomment-466387181,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ah6JI9OPRjIjG5sIOtWXG7AKRo0wzEfKks5vP-iZgaJpZM4am1e-
.


Prevent Net/ReadTimeout error in Ruby 2.6

This PR fixes the following build error in Ruby 2.6.0 (ruby-head).
$ ruby --version
ruby 2.6.0dev (2018-03-07 trunk 62693) [x86_64-linux]
% bundle exec rake
(snip)

  1) Net:HTTP with WebMock when net connect is allowed should make a
  real https request if request is not stubbed
     Failure/Error: response = super(request, nil, &nil)

     Net::ReadTimeout:
       Net::ReadTimeout
     Shared Example Group: "allowing and disabling net connect" called
       from ./spec/acceptance/webmock_shared.rb:25
     Shared Example Group: "with WebMock" called from
       ./spec/acceptance/net_http/net_http_spec.rb:10
     # ./lib/webmock/http_lib_adapters/net_http.rb:97:in `block in
       request'
     # ./lib/webmock/http_lib_adapters/net_http.rb:105:in `block in
       request'
     # ./lib/webmock/http_lib_adapters/net_http.rb:137:in
       `start_with_connect_without_finish'
     # ./lib/webmock/http_lib_adapters/net_http.rb:104:in `request'
     # ./spec/acceptance/net_http/net_http_spec_helper.rb:35:in `block
       in http_request'
     # ./lib/webmock/http_lib_adapters/net_http.rb:123:in
       `start_without_connect'
     # ./lib/webmock/http_lib_adapters/net_http.rb:150:in `start'
     # ./spec/acceptance/net_http/net_http_spec_helper.rb:34:in
       `http_request'
     #
       ./spec/acceptance/shared/allowing_and_disabling_net_connect.rb:14:in
       `block (4 levels) in <top (required)>'
     # ------------------
     # --- Caused by: ---
     # Net::ReadTimeout:
     #   Net::ReadTimeout
     #   ./lib/webmock/http_lib_adapters/net_http.rb:97:in `block in
       request'

(Errors continue after this)

https://travis-ci.org/bblimke/webmock/jobs/350668167#L942-L1202
This is because it was changed to use IO#read_nonblock based on the value of @rbuf by the following commit.
https://github.com/ruby/ruby/commit/b02fc0f9fedd635eb64f4bb6440ab63923c2af24
This PR forces the 2nd argument tmp of IO#read_nonblock to nil by using TracePoint. So this prevents Net::ReadTimeout from occurring.

@koic Clever! Thank you.


Write a TypeScript program to convert hours to minutes

Description
Write a TypeScript program to convert hours to minutes
1 hour = 60 minutes
Input  : 5
Output : 300

How to contribute

Save the solution in program/ConvertHoursToMinutes.ts file
Add ConvertHoursToMinutes.ts file in convert-hours-to-minutes folder

!assign


Importing bedtools_merge module from nf-core

Is there an existing PR for this?

[ ] I have searched for existing PRs

Types of changes:

[ ] Bug fix (change which fixes an identified problem)
[x] "New" feature (change which adds or improves existing functionality)

Description
Please include a summary of the changes and the related issue(s). List any dependencies that are required for this change, if any.
Fixes #ISSUE-NUMBER
Checklist:
Please verify that you have completed the following:

[x] Guidelines adherence: my changes follow the guidelines of this project.
[x] Documentation update: I have made corresponding changes to the documentation, if necessary.
[ ] Test inclusion: I have added tests that prove my code is effective and works.
[ ] New and existing unit tests pass locally with my changes.

Hola @marinaEM
Me parece bien el PR. Antes de aceptarlo, editame el mensaje inicial del PR, por favor. Falta marcar las casillas que correspondan y añadir el número del issue que resuelves.
Un saludo,

Adding bedtools-merge module - resolves issue #24


JsonConvert.Deserialize doesn't throw when unable to read JSON

When a string is provided to JsonConvert.Deserialize that isn't a valid JSON string I would expect it to throw an exception, whereas it just returns a null response and allows the calling code to continue executing.
Steps To Reproduce
Bridge
https://deck.net/40350fdb12783fe82e18a2b977bebe07
C#
https://dotnetfiddle.net/Al1Jhz
Expected Result
JsonReaderException should be thrown.
Actual Result
BEFORE
null
AFTER
This just means that we have to ensure that our calling code null guards as well as exception handling, which makes it a bit clunky.

Hi @Porl91 – I don't want to be a bother, but could you recreate this Issue in the Newtonsoft.Json repo? That will help us better track the defect.

@geoffreymcgill Done :)


Material 0.9.1 - toolbar icons now missing

Having just updated to Material to 0.9.0 (which worked great), I have now applied the 0.9.1 update. As a result, the toolbar icons have gone missing, as seen here:

(That's actually an animated gif -- the pic above is static.) My Shaarli itself is 0.9.2. I'm happy to help debug if some instructions are provided.

It's probably linked to the icon font which doesn't load properly. Can you open devtools (F12) and check the console so see if you have any error message? It could also be linked to a browser extension which may block non-standard fonts.

Here's a screenshot of the network downloads from Chrome. You can see the icons that it is stalling on. (At least it gets two! In Firefox I don't get any.)

Any thoughts?

Looks like a cache issue. Your browser tries to download icon that are not present anymore since they have been replaced by the font (example: tools.png, key.png, etc.).
Can you try to clear your browser's cache?

Can you try to clear your browser's cache?

I tried that - no change. I also tried two browsers on this machine that had not visited the site before (Chromium and Safari -- no toolbar icons), and from another machine that had not visited the site (no icons).
Is there something else I can check?

It strange, it looks like you only updated CSS and JS but not HTML templates. For exemple, the toolbar login button should look like that:

But in your case you still have the old template:

There is maybe a flat file cache on your server side but I can't help with that.

Thanks so much for looking around -- that was a help. I just got a fresh master.zip, uploaded and installed it (instead of the release version) and now all is well. I'm still puzzled why it didn't work before (I always upload the zip and "expand" on the remote site) but all good now!
Shaarli + Shaarli-Material = 👍  :)


fix errors

was not working for custom extension and I badly implemented the unit test.
This is actually working in native without doing something more.

undo the foreach on lambda. Quarkus wants to avoid lambda only and they must be replaced by anonymous classes but we can keep streams.
use a different table to isolate test


Better lint

Codecov Report
Attention: Patch coverage is 58.33333% with 10 lines in your changes missing coverage. Please review.

Project coverage is 87.15%. Comparing base (9753f32) to head (fd8b3ce).

Files with missing lines
Patch %
Lines

pandas_streaming/ext_test_case.py
0.00%
5 Missing :warning:

pandas_streaming/df/dataframe_helpers.py
33.33%
4 Missing :warning:

pandas_streaming/df/dataframe_split.py
50.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #42      +/-   ##
==========================================
- Coverage   87.17%   87.15%   -0.02%
==========================================
  Files          13       13
  Lines        1450     1448       -2
==========================================
- Hits         1264     1262       -2
  Misses        186      186

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


bootstrap import from file

hello
How can I do the following for bootstrap?
I put bootstrap.min.js in public folder but I keep getting errors about it not being in build folder.
import("bootstrap.min.js").then(({ default: bootstrap }) => {

    console.log('bootstrap', bootstrap)
  })

Thanks!

i found this
<EMAIL_ADDRESS>

When you do import, you need to use the /public/ folder in the URL.

let me try that. thanks


Bump frameworks to 5.11.2 to update error message

As per this pivotal comment - https://www.pivotaltracker.com:/story/show/138430483/comments/162122003

I think my recent merge put this out of sync with master. Once that's done, 👍


'Expecting data to be a DMatrix object, got: ', <class 'pandas.core.frame.DataFrame'>

Was following example https://github.com/interpretml/interpret-community/blob/master/notebooks/explain-regression-local.ipynb on my own data and xgboost object, but get error ('Expecting data to be a DMatrix object, got: ', <class 'pandas.core.frame.DataFrame'>) at explainer.explain_global(x_test). Changed x_test to DMatrix generates error 'DMatrix' object has no attribute 'shape'. Please advise. Thank you.
x_train, x_test, y_train, y_test = train_test_split(df[features], df[LABEL], test_size=0.2, random_state=0)

from interpret.ext.blackbox import TabularExplainer
explainer = TabularExplainer(model,
                             x_train,
                             model_task = 'regression',
                             features=features)
global_explanation = explainer.explain_global(x_test)
# xgtest = xgb.DMatrix(x_test.values)
# global_explanation = explainer.explain_global(xgtest)

Version:
interpret-community==0.23.0
interpret-core==0.2.7
xgboost==1.4.1

@yzheng27 Thanks for reporting the issue. Could you try with the latest interpret-community release 0.24.2 and see if you continue to see this issue? In case you still see the issue, could you provide a sample notebook so that we can reproduce this issue locally. A stack trace of the error will also help us greatly in triaging this issue.
Regards,

@gaugup I think the issue is happening because they are using the XGBoost API that uses DMatrix, instead of the scikit-learn API that is pandas compatible, so I'm guessing that upgrading to latest version won't fix it.  @yzheng27 I will take a look to see if we can support DMatrix from XGBoost somehow, but an easy quick fix would be to use the scikit-learn API for XGBoost,

thank you. i was able to generate the global_explanation by loading the model with scikit-learn interface. But now my notebook is running code below for several hours. is it expected?  the shape of x_test is around 24000*325.
ExplanationDashboard(global_explanation, model, dataset=x_test, true_y=y_test, public_ip = host, port = 7780)

"the shape of x_test is around 24000*325"
@yzheng27 yes that may be too large for the UI to handle, please limit it by downsampling to ~5k rows instead of 24K.  If you are still seeing issues with downsampled data, then there might be something about the host/port configuration.  However even then you should still see the dashboard, just what-if analysis and ICE plots won't work in the ExplanationDashboard.

@yzheng27 one other thing, are you importing the dashboard from raiwidgets package, on this repository:
from raiwidgets import ExplanationDashboard

https://github.com/microsoft/responsible-ai-toolbox
Make sure you don't import it from interpret-community package, as it has been moved to the other repository.

@imatiach-msft i'm using the library from raiwidgets and the version is 0.15.1.
I was able to get the dashboard with the data dimensions I mentioned, though it took several hours. Will try with the smaller data.

@yzheng27 if it took several hours but eventually worked then it must be that the UI just loaded too much data, and downsampling should speed it up significantly.  All of the datapoints are loaded into the UI and I've noticed that usually after >5k datapoints the UI becomes very slow.  Perhaps there is some way to change the UI to stream select data from python backend or to aggregate statistics across multiple points in the future for users who want to run it on a lot of data, I'm not sure.  The ErrorAnalysisDashboard is actually able to work on millions of points if you pass in a sample_dataset, so perhaps something like that could be done for the ExplanationDashboard as well:
https://github.com/microsoft/responsible-ai-toolbox/blob/main/raiwidgets/tests/test_error_analysis_dashboard.py#L83


Selector - after deleting selector item unhighlighted empty space exists

Create new wearable sample project
Add Selector
Add Few selector items
Remove on selector item
Observe

Expected Behaviur

no empty spacwe, selector widget is rebuild
Observation:
epty space

To solve this issue I need to create two PRs - one into TAU repository and the second one into Design - Editor.
The problem is quite complex, because item removal has to be done using Selector widget API - for now there is no generic API for all of the widget. I will extend selector API to accept index or HTMLElement of item to remove and add configurable design-editor method call on removal.

TAU PR: https://github.com/Samsung/TAU/pull/341
DE PR: https://github.com/Samsung/TAU-Design-Editor/pull/296

PRs for this issue are still waiting for review. I will put back "in progress" label.


Unable to delete previous ephemeral interaction response

After successfully sending a ephemeral interaction response, I am unable to delete it.
s.InteractionResponseDelete(appID, i.Interaction)
returns
{"message": "Unknown Webhook", "code": 10015}

This is not possible in the API. The library cannot do anything about it.

Is this possible now? Supposedly Discord added support back in Oct 2022

You can delete it if you somehow store the interaction when it's created then delete it later, interaction tokens last for 15 minutes, attached the example here - I saved the interaction response to the 'new ticket' button, aka the creation of the form with the menu selects, and then deleted it once the user got to the next step.

https://user-images.githubusercontent.com/87721861/234193566-fc829213-c4cd-410f-8d04-74dfec3cf310.mov


Upgrade ember-power-select-blockless and pass all options.

Pass all possible options down to the ember-power-select/ember-power-select-blockless components, as well as take care of https://github.com/kaliber5/ember-bootstrap-power-select/pull/30

Can we cut a new release to take advantage of this change? It adds a lot of important options for eps

@seansellek thanks for the reminder! Just published 1.0.0! 🎉


add cypress tests

You need to add a script to your package.json file to the scripts section. So anyone can see how to run e2e tests.


test_no_empty_file_items not working on some CI setups

Issue Report Checklist

[x] Searched the issues page for similar reports
[x] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[x] Tried basic troubleshooting (if a bug/error)

[ ] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
This is a bit weird.  The test spyder/plugins/findinfiles/widgets/tests/test_widgets.py::test_no_empty_file_items has started failing on the Debian CI system (which uses lxc containers).  Some of these failures can be seen in the test logs at https://ci.debian.net/packages/s/spyder/unstable/amd64/  Here's a relevant part of one of them:
=================================== FAILURES ===================================
___________________________ test_no_empty_file_items ___________________________

findinfiles = <spyder.plugins.findinfiles.widgets.main_widget.FindInFilesWidget object at 0x7f15887e4280>
qtbot = <pytestqt.qtbot.QtBot object at 0x7f1588f8beb0>

    @flaky(max_runs=5)
    @pytest.mark.skipif(not running_in_ci(), reason="Only works on CIs")
    @pytest.mark.skipif(os.name == 'nt', reason="Fails on Windows")
    def test_no_empty_file_items(findinfiles, qtbot):
        """
        Test that a search that hits the max number of results doesn't generate
        empty file items.

        This is a regression test for issue spyder-ide/spyder#16256
        """
        findinfiles.set_search_text("spam")
        findinfiles.set_directory(osp.join(LOCATION, "data"))
        findinfiles.set_conf('max_results', 6)

        with qtbot.waitSignal(findinfiles.sig_max_results_reached):
            findinfiles.find()

        # Assert the results are the expected ones to reproduce the bug this test
        # tries to catch. In other words, this is here to prevent future changes to
        # our test files that would render this test useless.
        results = {
            'spam.py': [(2, 7), (5, 1), (7, 12)],
            'spam.txt': [(1, 0), (1, 5), (3, 22)]
        }
>       assert process_search_results(findinfiles.result_browser.data) == results
E       AssertionError: assert {'spam.cpp': [(2, 9), (6, 15), (8, 2)], 'spam.py': [(2, 7), (5, 1), (7, 12)]} == {'spam.py': [(2, 7), (5, 1), (7, 12)], 'spam.txt': [(1, 0), (1, 5), (3, 22)]}
E         Common items:
E         {'spam.py': [(2, 7), (5, 1), (7, 12)]}
E         Left contains 1 more item:
E         {'spam.cpp': [(2, 9), (6, 15), (8, 2)]}
E         Right contains 1 more item:
E         {'spam.txt': [(1, 0), (1, 5), (3, 22)]}
E         Full diff:
E         - {'spam.py': [(2, 7), (5, 1), (7, 12)], 'spam.txt': [(1, 0), (1, 5), (3, 22)]}
E         + {'spam.cpp': [(2, 9), (6, 15), (8, 2)], 'spam.py': [(2, 7), (5, 1), (7, 12)]}

/tmp/autopkgtest-lxc.3rwfusl7/downtmp/build.Dr5/src/spyder/plugins/findinfiles/widgets/tests/test_widgets.py:340: AssertionError
=============================== warnings summary ===============================

But on my local setup, all works as expected, running what is supposedly an identical lxc container.  The only difference I can think of is in the locale (I'm in en_GB.UTF-8, while I'm guessing the ci.debian.net ones are en_US.UTF-8), but trying to run an en_US.UTF-8 container locally failed to reproduce the problem.  It seems that what has happened here is that in some setups, this find process is looking at the files in a different order from in other setups.  But it is still returning exactly 6 finds.  I don't know whether the order of file searching is deterministic across locales/setups, but I'm guessing that may be the source of this test failure.
Versions

Spyder version: 5.3.3
Python version: 3.10.6
Qt version:
PyQt version:
Operating System name/version: Debian/Linux testing

Hey @juliangilbey, thanks for reporting. @dalthviz just fixed this problem on PR #19564 last Thursday.

Thanks; I don't think that PR will resolve this though.  #19564 allows for two possibilities (3 from spam.py, 3 from spam.txt OR 6 from spam.cpp).  But this failure had 3 from spam.py and 3 from spam.cpp, so it will still fail.  One could add another possibility to the PR:
        {
            'spam.py': [(2, 7), (5, 1), (7, 12)],
            'spam.cpp': [(2, 9), (6, 15), (8, 2)]
        }

though then it is beginning to look a little ugly.  Hence I'm wondering whether there may be a benefit in forcing the search order to be OS-independent instead.

The search order depends on os.walk so I don't think that's feasible. So you can either add that option in another PR or skip this test in your CIs.

Ah, OK; I'll submit a new PR (but it will be a few days before I have a chance).

Looks like it might be something within the last 3 days. This PR has the issue too: https://github.com/spyder-ide/spyder/pull/19553 and the tests were run 3 days ago. My new PR and an older one that had a recent commit also are failing these tests.

Here's the result of process_search_results(findinfiles.result_browser.data) when I run it locally
{'spam.cpp': [(2, 9), (6, 15), (8, 2)], 'spam.txt': [(1, 0), (1, 5), (3, 22)]}

Here's possibly where @dalthviz fix could be implemented, but I'm wary of messing with it myself
https://github.com/spyder-ide/spyder/blob/master/spyder/plugins/findinfiles/widgets/search_thread.py#L123

Thanks for submitting the PR adding the extra case for a result! Looks a little bit ugly (adding all the possible cases) as you said but maybe it could be better than the sort usage (since thinking about it maybe with a large directory it could have an effect over perfomance).
What do you think @ccordoba12 @juliangilbey ? Could it be better to go for the moment with just adding the missing cases to the test or trying to sort the results on the os.walk loop?

I think for now we should try to add the missing cases to the test. As you @dalthviz, I'm worried that trying to sort the search results could impact negatively the performance of this plugin.

I've thought about this a little more over the last few days, and think the best solution is something like this (currently untested):
def test_no_empty_file_items(findinfiles, qtbot):
    """
    ...
    """
    max_results = 6
    findinfiles.set_search_text("spam")
    findinfiles.set_directory(osp.join(LOCATION, "data"))
    findinfiles.set_conf('max_results', max_results)

    with qtbot.waitSignal(findinfiles.sig_max_results_reached):
        findinfiles.find()

    # Assert that the results all come from the expected files and that there
    # are the correct number of them.  (We cannot specify the results precisely
    # because `os.walk` used by `findinfiles` gives an arbitrary file ordering.)
    spamfiles = set(['spam.py', 'spam.txt', 'spam.cpp'])
    findinfiles_results = findinfiles.result_browser.data
    assert set(findinfiles_results.keys()).issubset(spamfiles)
    assert sum(len(finds) for finds in findinfiles_results.values()) == max_results

    # Assert that the files with results are exactly the same as those
    # displayed in the results browser.
    ...

The reason for this suggestion is that in this test, we only care that the correct number of results are returned and that they are returned from some subset of the files containing "spam".

Ah, I've just noticed that the "list all possibilities" has been committed.  So my last comment may well be redundant.

Although it's probably worth noting that if sticking with the current list-all-possibilities scheme, the assert can be simplified to:
    assert process_search_results(findinfiles.result_browser.data) in results

@juliangilbey, you're welcome to open a new PR to simplify and/or improve that test.

Two alternative PRs; obviously at most one of these can be applied!


Error coming while running Nuclei

Encountered a bad command exit code!
Command: 'nuclei -duc  -l /tmp/infile -t /nuclei-templates -config-directory /tmp/'
Exit code: 127
Stdout: already printed
Stderr: already printed

Were you able to resolve the error?

not yet

I know this is old, but adding some info in case anyone else comes across it.
I ran into this yesterday. For me at least, it was being caused by trying to provide nuclei-templates in my container in /tmp but the permissions weren't correct causing nuclei to crash. There is a good chance the permissions on your nuclei-templates directory are also incorrect.
For context, when you build the container via lithops, it runs everything as root. If you are executing this container on AWS Lambda, the user becomes sbx_user1051.
You could try running nuclei with only nuclei -version, which would not attempt to read the templates or config and should return your nuclei version. If that is the case, then it is definitely issues with your templates.

Hi @amiremami, did u find any solution for that error?

@MustafaSky Yes, contact me on discord "amir_23"

@MustafaSky
try this for nuclei
 python shadowclone.py -i /home/kali/ShadowClone/nuc.txt  -c "/go/bin/nuclei -ut && cat {INPUT}|/go/bin/nuclei  -s critical,high -rl 600 -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0'" -o nuc-rez.txt -s 100


Add NavigationView Popup Color

I use fluent_ui with the flutter_acrylic package.
When using NavigationPaneThemeData.backgroundColor to set the background color of NavigationView to transparent
When displayMode is PaneDisplayMode.minimal, I get a black popup layer!
This causes all the PaneItem text to be invisible in the light theme.
Pre-launch Checklist

[x] I have updated CHANGELOG.md with my changes
[x] I have run "dart format ." on the project
[ ] I have added/updated relevant documentation

5e14184


Will there be any update to the system?

You can't use this anymore because any change to an actor, ability, item, etc doesn't stick.

I'm using forge-vtt which is on the latest version. It pings a compatibility issue for Black Hack (also updated to latest build). I thought it might be a problem with lag, but other games don't seem to have this issue.
Just tried it now, and nothing I change to the sheet sticks, even the dropdown options. I checked the console and saw one Uncaught type error, Uncaught TypeError: Cannot read properties of null (reading 'querySelector') at bh2e.js:72:35. Probably not the issue, as it occurs during setup, but it's the only console error.
Otherwise, when updating a character sheet the console outputs a fetching the state and finding the state command. I don't know much about how the system works, but I'm guessing it's trying to update the sheet, and something causes a hitch in the process. It doesn't seem to be able to save the change and then display it.

Okay, just went to the expense to taking a forge license to try this out (shameless self promotion - sponsorship links on the repo root page). This works for me. I installed the system, created a world, created a character, changed things on the character - all changes stuck. Same with abilities, armour, weapons and spells.  That's leading me to think it's something specific to your set up. I'd maybe take this up with Forge.

Will try, thanks!

Okay, just went to the expense to taking a forge license to try this out

Hey @free-beer, I was referred to this issue and noticed the above line. Hit me up on our Discord or send us an email and we'll upgrade your account for free. The Forge gives free subscriptions to developers of Foundry VTT systems and modules, if you weren't aware, so feel free to reach out and we'll hook you up!
@Orphansmith I've checked your account on the Forge and I see that you have the bh2e system installed with version 0.2.1 which is set as compatible with 0.7.9, while the latest version of bh2e, compatible with v9, according to this repository is version 0.3.1.
You need to get it updated, and since it's a custom install (I don't see this in the official system listing, so it's not in the Bazaar), you'll need to go to the Bazaar, under 'custom systems' to keep it updated (https://forge-vtt.com/bazaar#filter=custom&type=system&sort=title).
However, I also see that the system.json file installed on your account has a manifest url that points to https://raw.githubusercontent.com/free-beer/bh2e/v0.2.2/system.json which is pointing to a specific release and will never be able to find updates for you. That would explain your issues.
I recommend you re-install it again directly from the manifest URL, which will update it and will also allow it to find future updates as the new manifest contains a proper latest-pointing url : https://raw.githubusercontent.com/free-beer/bh2e/master/system.json

That worked, thanks!


GCS backend

Alright, GCS isn't 100% working yet, but I'm pretty sure all of the fixes are going to be changing permissions stuff with the GCE console. @derekchiang whenever you have a sec take a look at this for me

Alright pretty sure I addressed everything here

LGTM


Spring Cloud Sleuth 2.0.0 Build Fails

https://jenkins.spring.io/view/Spring Cloud/view/Releaser/job/spring-cloud-sleuth-releaser/38/

Flakey tests or sth

Works everywhere else but jenkins

Done


feat: Sync skip deletes until

- What I did

client side changes for syncSkipDeletesUntil
- How I did it
In SyncServiceImpl, made changes for client to send skipDeletesUntil value during initial sync to server. Server will skip the delete commits until this value.
SyncUtil.shouldSync doesn't check whether a key is local key. Added a check in at_client_impl --> _putInternal, so local keys are not synced to server
added unit and functional tests
changes to publish at_client

*- How to verify it

tests should pass

Will merge this PR once at_client 3.3.1 is published


Jest snapshots different classnames

Everytime i run snapshot test with jest and rest-testing-library for component with tooltip inside, new css classes are generated and thus snapshot is failing. Any ideas to solve this ?
 - Snapshot
    + Received

    @@ -49,80 +49,80 @@
                >
                  XSS
                </div>
              </a>
              <div
    -           class="__react_component_tooltip t478c1214-c3a1-4e62-b8d9-bec855c08c42 place-top type-dark"
    +           class="__react_component_tooltip t6228f914-bd48-4261-96f8-0d9fbdc0096a place-top type-dark"
                data-id="tooltip"
                id="sizePicker-1001"
              >
                <style>

    -           .t478c1214-c3a1-4e62-b8d9-bec855c08c42 {
    +           .t6228f914-bd48-4261-96f8-0d9fbdc0096a {
            color: #fff;
            background: #222;
            border: 1px solid transparent;
                }

    -           .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-top {
    +           .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-top {
              margin-top: -10px;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-top::before {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-top::before {
              border-top: 8px solid transparent;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-top::after {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-top::after {
              border-left: 8px solid transparent;
              border-right: 8px solid transparent;
              bottom: -6px;
              left: 50%;
              margin-left: -8px;
              border-top-color: #222;
              border-top-style: solid;
              border-top-width: 6px;
          }

    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-bottom {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-bottom {
              margin-top: 10px;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-bottom::before {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-bottom::before {
              border-bottom: 8px solid transparent;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-bottom::after {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-bottom::after {
              border-left: 8px solid transparent;
              border-right: 8px solid transparent;
              top: -6px;
              left: 50%;
              margin-left: -8px;
              border-bottom-color: #222;
              border-bottom-style: solid;
              border-bottom-width: 6px;
          }

    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-left {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-left {
              margin-left: -10px;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-left::before {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-left::before {
              border-left: 8px solid transparent;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-left::after {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-left::after {
              border-top: 5px solid transparent;
              border-bottom: 5px solid transparent;
              right: -6px;
              top: 50%;
              margin-top: -4px;
              border-left-color: #222;
              border-left-style: solid;
              border-left-width: 6px;
          }

    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-right {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-right {
              margin-left: 10px;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-right::before {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-right::before {
              border-right: 8px solid transparent;
          }
    -     .t478c1214-c3a1-4e62-b8d9-bec855c08c42.place-right::after {
    +     .t6228f914-bd48-4261-96f8-0d9fbdc0096a.place-right::after {
              border-top: 5px solid transparent;
              border-bottom: 5px solid transparent;
              left: -6px;
              top: 50%;
              margin-top: -4px;

      31 |     const { asFragment } = render(component);
      32 |
    > 33 |     expect(asFragment()).toMatchSnapshot();
         |                          ^
      34 |   });

This looks related to #562

This isn't a fix, but it might help someone out.
We're using react-tooltip in a Storybook.js component library, and it was failing tests for the reason reported. For now, I've just had to ignore the stories that use this component from Storybook's testing suite.
export const YourStory = () => {
  return <Tooltip>Here's some help text!</Tooltip>
}

YourStory.story = {
  parameters: {
    storyshots: { disable: true }
  }
}

I imagine Jest natively has a similar 'ignore' config value - I'm not familiar with it beyond Storybook's Storyshot addon.
Not ideal, but it does mean we can move past this.

What version did this appear?

This first started to occur with version 4.0.5 (see #562). The proposed solution was to add uuid as a dependency and have developers mock the module (see #566):
jest.mock("uuid", () => ({ v4: () => "00000000-0000-0000-0000-000000000000" }));

Initially uuid was bundled to dist/index.js by rollup so uuid could not be mocked. That got fixed with #582.
The current implementation has certain limitations. For example, if your package (or a dependency) depends on a non-compatible uuid version (as of<EMAIL_ADDRESS>its ^7.0.3), uuid will be installed in node_modules/react-tooltip/node_modules/uuid. This requires to change the mocking to:
jest.mock("react-tooltip/node_modules/uuid", () => ({ v4: () => "00000000-0000-0000-0000-000000000000" }));

This could be fixed by making uuid a peerDependency. However that would result in a breaking change, since consumers with no dependency to uuid will get a Cannot find module 'uuid' error message. Instructions for installation would need to be updated as well.
Another alternative that does not depend on uuid's location is to mock crypto's randomBytes function like so:
jest.mock('crypto', () => ({ randomBytes: (num) => new Array(num).fill(0) }));

However, this approach can potentially break other testing that depend on the core crypto module.
As you can see, no solution is without its hiccups, and besides, none of these approaches are officially documented. I believe a more robust approach would be to expose a static method or property that could be executed so that generated uuids are static. For example:
// jest setup file
import ReactTooltip from "react-tooltip";

// alt names: .enableSnapshotMode(), .enableTestMode(), .testMode(), .snapshotMode()
ReactTooltip.useStaticUuids();

We just started using react-tooltip today and it also breaks our snapshot tests... Any update on this?

@marcogrcr Thank you for the initial ideas. I've found a workaround for the Cannot find module message that tests for package availability in a tricky sort of way to survive hoisting.
jest.mock(
  (() => {
    // This will mock the version of uuid belonging to react-tooltip
    // if it exists, otherwise use the top-level uuid module
    try {
      require('react-tooltip/node_modules/uuid');
      return 'react-tooltip/node_modules/uuid';
    } catch (error) {
      return 'uuid';
    }
  })(),
  () => ({
    v4: () => '00000000-0000-0000-0000-000000000000',
  })
);

That should make the tests a bit more reliable across dependency and react-tooltip updates.