Bare project crashing Azure App Service - API

I'm having an issue with publishing a bare-bones API app up to Azure using v1.0.0. The application will not start successfully, yet runs just fine when developing locally. This is basically the template provided by Visual Studio 2017, targeting Core 1.1, with nothing more than the demo controller/endpoint in place.
Of course, the error message coming back from Azure is less than helpful simply saying "An error occurred while starting the application."
Code posted below since I can't attach the .cs file directly.
Thanks,
Ric
`
using System.IO;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.PlatformAbstractions;
using Swashbuckle.AspNetCore.Swagger;
namespace myApi
{
public class Startup
{
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
.AddEnvironmentVariables();
Configuration = builder.Build();
}
    public IConfigurationRoot Configuration { get; }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSwaggerGen(c =>
        {
            c.SwaggerDoc("v1", new Info
            {
                Title = "myApi",
                Version = "v1",
                Contact = new Contact
                {
                    Name = "My Company Name",
                    Email =<EMAIL_ADDRESS>                    Url = "companyUrl"
                }
            });

            var basePath = PlatformServices.Default.Application.ApplicationBasePath;
            var xmlPath = Path.Combine(basePath, "myApi.xml");
            c.IncludeXmlComments(xmlPath);
        });

        // Add framework services.
        services.AddMvc();
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole(Configuration.GetSection("Logging"));
        loggerFactory.AddDebug();

        app.UseSwagger();
        app.UseSwaggerUI(c =>
        {
            c.SwaggerEndpoint("/swagger/v1/swagger.json", "my API V1");
        });

        app.UseMvc();
    }
}

}
`

I may have located the source for my problem - the XmlComments, well, more importantly - the path to the XmlComments.
I'm publishing through Visual Studio 2017 to an Azure App Service and even though I've moved the .xml file into the Controllers folder, it was not getting published properly. No idea why, and don't have the time to investigate past what I've done to get this working, but, adding the XmlComments to the wwwroot folder does result in the file being published properly.
                const  string xmlPath = "wwwroot/PromiseZoneApi2.xml";                 c.IncludeXmlComments(xmlPath);
Granted, there's nothing dynamic or flexible about this whatsoever, but it does work.

Thanks for finding that - I tried the #21 solution proposed by @RehanSaeed but no dice even after updating the IApplicationEnvironment references.


Update mathematical-functions-transact-sql.md

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

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


View within view

Hello!
Is it possible to have a view within another view? I'm not really sure if it's even possible, or if I just can't figure out a way to do it.
Basically, what I need to do is to route the links contained in a view (A) so they're loaded into another view (B), which is contained inside view A. Is there a way to have two different Core instances running at the same time, to allow having 2 router wrappers?
Possible or not, thank you anyways for this great library!

Hey @rcobiella,
That doesn't seem logic at all. You always have a content that is removed and replaced by another content when a navigation happens. So, what's the purpose to have a view within a view? That's not even a thing we do when we don't use page transitions.
Best regards,
Anthodpnt

Issue closed because no more informations has been provided.


RPC Methods: make diagnostic events XDR clickable links

Example

Preview is available here:http://laboratory-pr1072.previews.kube001.services.stellar-ops.com/

In the network tab, set mainnet RPC to https://soroban-rpc.mainnet.stellar.gateway.fm.
Go to getLedgerEntries and paste AAAAB7r5ePEO/bzYV0eGi++IMoRepoCfdkO2ekrAzWaTJ/ws into the Ledger Key XDR and click submit. In the response, click on the xdr string and see an error page.
https://github.com/user-attachments/assets/a55d50bf-0958-41ea-9c32-e08356a1ce54


rustc: re-enable parallel building

Description of changes
We previously disabled this based on a now-closed issue from 2015 0. I think enough time has passed that we can give it a shot again, given that the in the worst case scenario we revert, and in the best case scenario we get a performance boost.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin, nix-build -A fd

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Built on x86_64-linux.


Show the service identity on the events page.

Currently the events page only shows the service uuid even if a service identity is defined.

If there is one, that should be shown instead of the UUID. For example:
Showing events of instance c8f659cd-68a9-4b9d-bf47-667ca1795b63
should become
Showing events of instance iso4-rc.inmanta.com

Issue moved to inmanta/web-console #2862 via ZenHub


💡 Extend mocking idea

Background
Currently, I am researching if we may use the ms-dev-proxy as a tool to support us in integration/manual/QA tests for our apps, and mocking responses is just the perfect functionality we could use 😉.
Idea

Currently the ms-dev-proxy will look for responses.json file in the working directory which is just perfect to keep mock related to the app in the projects folder. What I was thinking is maybe ms-dev-proxy could have a new option that would allow specifying the relative path to the response.json with mocks to be used. Maybe something like -r --responses-file-path (optional). The aim for this would be to have different test scenarios with different mocks for the same app and then use them as part of integration tests. That way I could keep something like

.
├── MyApp
├── TestScenarios
│   ├── groups-fail-timeout-responses.json
│   └── throttle-responses.json

In this case, each integration test could start the ms-dev-proxy giving different responses.json mocks as param.
TBH this is very low 😉 (and probably stupid) idea as the current workaround I have for it is:

keep responses.json in subfolders and run the ms-dev-proxy in the subfolder with correct mocks as working directory
the test may just copy/paste the needed responses.json file to be used for this test.

Second idea I had (sorry for adding 2 ideas in one issue, I am a bit lazy and running out of time 😝), is to give possibility to define  the  failure rate for each mocked response in case we are mocking error response.

Thank you for the idea and the reasoning. It makes perfect sense to be able to define different mocks for the different scenarios and it wouldn't be too hard for us to make the file name configurable and default to responses.json if no name has been specified.
As for your second suggestion, I wonder if that wouldn't mean a different configuration, basically a preset.
Combining the two: what if you'd start the proxy from the working folder which has responses and a specific config (if I recall correctly we don't support project-specific config just yet)? Would that work?

yes that would work.  A specific responses.json for the test scenario and config.json for it as well. This would also mean the --failure-rate option will need to respect the mock responses. Currently if we mock some response it is always used does not matter what rate we use. This make total sense 😉 as we don't always need to mock failures 🙂. But it would also make sense that in case we mock and error response the --failure-rate is considered 👍 (could be either taken from separate config, or passes as an option running the tool)

BTW I forgot to mention that if one of those ideas will get approved I am willing to help out and work on those.

We're tracking adding project-specific config in #62. With that, I think we've got everything covered. The new feature from this request is to be able to combine failures with mocks, rather than mocks taking precedence. Let us think about what would be the best way to support this without making the setup too hard to understand and too unpredictable. Perhaps our plugin-architecture could play a role here, where by defining the order of plugins you can define if you'd prefer mocks or chaos to take precedence.

BTW I forgot to mention that if one of those ideas will get approved I am willing to help out and work on those.

We appreciate your help. We're not accepting community contributions just yet, but we'll definitely keep you in mind for the future. ❤

I'm very much in favor of allowing developers to set the mock responses file name/path at runtime. In fact, it's something that I was playing around with in #99
The idea of rates of mock responses is an interesting one. What about keeping it very simple and extending the schema for the mock responses file to allow for an optional rate field, in the 0-100 range, at both the file and request entry level?
The top level defaults to 100 if not specified and is used unless a request provides a rate value which is used instead if specified.
This way the mocks can have a rate of usage that is independent of the failure rate for unmatched requests (assuming mocks => failures precedence)

That's a very good question.
I think that constraining mock response rating to error responses makes sense.
@Adam-it I'd like to hear your thoughts on this idea, perhaps if you could share some scenarios where you want to apply rates to mock might help too.

That's a very good question.
I think that constraining mock response rating to error responses makes sense.
@Adam-it I'd like to hear your thoughts on this idea, perhaps if you could share some scenarios where you want to apply rates to mock might help too.

Sure.
So the idea I had was to give the possibilty to define rates only for mocked errors (failures). Easiest would be to have it in the responses.json file as a new property that might be set when we mock an error response, but I am opened for any other way to set it.
I was thinking of a functionality that would allow me to mock success response for some request and additional failure mock for the same request that could happen 20% of the time.
The scenario I was thinking of was to use the tool also for QA tests which in our case are done manually by testers. We could create dedicated response.json files for dedicated test scenarios. When tester clicks over the app to perform tests according to the scenario, we may also mock a potential error that may happen in the app (for example mocking that server suddenly stopped responding and our request failed). This kind of (a bit unexpected) case that might happen during QA tests present a real life use case which would be hard to create without this kind of proxy tool (in our case the dev/test APIs are rather always working and would be hard to mock that some request may fail from time to time without explicitly adding it to the API code which would be really stupid. This kind of Proxy tool may give us this possibility and also help us to reduce resources as we would not require any API working for the QA tests as well, only good quality mocked responses 🙂). A random error (mocked) that might happen during QA tests provides possibility for the tester to check how the app reacts to failures, if it is handled properly, and gives the possibility to provide feedback what was the user experience in case of errors.
I hope my description is understandable and answers your question 😉. Let me know if I may help out in any other way.
I already booked some time with graph-dev-proxy also in the coming weekend.
If this idea is also interesting for you maybe I should open a separate issue so we may track it? Otherwise we may ignore it 😉.

Thanks for the additional information, @Adam-it! It helps a lot. In your scenario of QA folks testing apps for API failures, if the mocked response has only 20% chance of occurrence, what if the Proxy doesn't return an error? Would they consider the app working or would they keep rerunning the app until they see an erroneous response, defeating the idea of rates?

Thanks for the additional information, @Adam-it! It helps a lot. In your scenario of QA folks testing apps for API failures, if the mocked response has only 20% chance of occurrence, what if the Pro mexy doesn't return an error? Would they consider the app working or would they keep rerunning the app until they see an erroneous response, defeating the idea of rates?

They would consider the app working and finish the test which is also ok. Tester follow the scenario step by step. If only for some of them during the scenario they will get the error (the mocked one) they should try to resolve it with the app (trying to click on the provided retry button if there is any, or refresh or whatever). If they managed to 'resolve' the issue and continue the scenario then it is also ok and we should get the feedback that there was something unexpected but the app was prepared for it and the user may manage to retry and continue, which a very realistic case. If the fail crashed the app (worse case) then we also get the feedback but the scenario is not done.
Currently we are unable to 'prepare' this kind of tests scenarios and cases. We rather test only success from begging to end of the scenario without the possibility to 'prepare' a fail. If we were suppose to also test something like this then probably we would have to have some setting or API which will always fail and have a scenario where the steps are actually to test over bug handling case. We don't do it, and expecting a bug always to happen and have it in the scenario is rather unrealistic and provides no value.
Having going over scenarios that ended up with success from begging to end provide little value and confidence that the app is working.
Having scenarios that randomly for some testers for some scenarios mail fail and the user may manage to resolve it or it crashes the app provides most value 😉.

Understood. Thank you for clarifying.


Implement Envie.values()

Use case:
const envie = require('envie')
const Joi = require('joi')

const { PORT } = envie({
  PORT: Joi
    .number()
    .min(0)
    .default(0)
    .description('Port on which the HTTP server will listen'),
}).values()

server.listen(PORT)

Oh hey, sorry I'm not very quick on noticing pull requests !
I like this one, thank you. I think it qualifies nicely as the next minor release. I'll let you know here when it's released. Gotta accept the #9 first an publish it as a patch.


https://boardgamearena.com/bug?id=92640

https://boardgamearena.com/bug?id=92653
https://boardgamearena.com/bug?id=92534
https://boardgamearena.com/bug?id=92773

These changes can't be merged cleanly into my latest big change, and some of these changes look a bit questionable to me, so I'm just going to pull out the fixes I need from this PR.

The only changes I have left to extract and review are Blackmail, Sabotage, and Surveillance from this PR.

Blackmail fix is now in main-4, so Sabotage and Surveillance are the only ones left from this MR.


HOCS-3286: remove foi data input stage

Please note the branch was rebased on to epic/foi-mvp yesterday to include the latest changes, hence why the other commits before the commit labelled HOCS-3286: removal foi data input stage are showing. All changes displayed are a part of this ticket.


Fix wasm check

Fixes https://github.com/MutinyWallet/mutiny-web/issues/246
Reproduce via google-chrome --js-flags="--jitless"

In your original code:
    try {
        if (
            typeof WebAssembly === "object" &&
            typeof WebAssembly.instantiate === "function"
        ) {
            const module = new WebAssembly.Module(
                Uint8Array.of(0x0, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00)
            );
            if (module instanceof WebAssembly.Module) {
                // continue
            } else {
                throw new Error("WebAssembly is not supported.");
            }
        }
    } catch (e) {
        console.error(e);
        throw new Error("WebAssembly is not supported.");
    }

You are first checking if WebAssembly is an object and if it has a method called instantiate. If either of these checks fails, it should not enter the if block and go straight to the catch block, where it would throw an error "WebAssembly is not supported".
However, if for some reason it still enters the if block (e.g., due to an unexpected JavaScript behavior or a browser bug), it will try to call new WebAssembly.Module, which can throw a ReferenceError if WebAssembly is not defined, because you're trying to access a property of an undefined object. This ReferenceError is then caught by the catch block, and it's this error that you're seeing.
In the revised code:
console.debug("Checking WebAssembly");
if (typeof WebAssembly === 'object' && WebAssembly.validate(Uint8Array.of(0x0, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00))) {
    // WebAssembly is supported
} else {
    throw new Error("WebAssembly is not supported.");
}

You are only checking if WebAssembly is an object and if it can validate a basic WebAssembly binary. The validate function is simpler to use than new WebAssembly.Module and it doesn't throw a ReferenceError if WebAssembly is not defined. If either of these checks fails, it will throw an error "WebAssembly is not supported", which should be caught by your checkBrowserCompat function.
This code should behave more predictably and avoid uncaught ReferenceErrors. It still properly checks for WebAssembly support and throws an error if it's not supported, but it does so in a safer way that avoids accessing properties or methods of undefined objects.

Verified works correctly on vanadium


Feature request: Let users change the default entity name "sensor.p_deferrableX" to a friendly name

I has been nice if users can change the default entity name  "sensor.p_deferrableX" to for instance the friendly name "sensor.heating_cable_kitchen". I think it can be done if the entity has a unique ID.
This entity ('sensor.p_deferrable0') does not have a unique ID, therefore its settings cannot be managed from the UI. See the [documentation](https://www.home-assistant.io/faq/unique_id) for more detail.

This was added in the latest release.
When using the publish-data endpoint just add some runtime parameters like this:
shell_command:
  publish_data: "curl -i -H \"Content-Type:application/json\" -X POST -d '{\"custom_load_forecast_id\": {\"entity_id\": \"sensor.p_load_forecast\", \"unit_of_measurement\": \"W\", \"friendly_name\": \"Load Power Forecast\"}}' http://localhost:5000/action/publish-data"

These keys are available to modify: custom_pv_forecast_id, custom_load_forecast_id, custom_batt_forecast_id, custom_batt_soc_forecast_id,  custom_grid_forecast_id, custom_cost_fun_id, custom_deferrable_forecast_id.
If you provide the custom_deferrable_forecast_id then the passed data should be a list of dictionaries, like this:
shell_command:
  publish_data: "curl -i -H \"Content-Type:application/json\" -X POST -d '{\"custom_deferrable_forecast_id\": [{\"entity_id\": \"sensor.p_deferrable0\",\"unit_of_measurement\": \"W\", \"friendly_name\": \"Deferrable Load 0\"},{\"entity_id\": \"sensor.p_deferrable1\",\"unit_of_measurement\": \"W\", \"friendly_name\": \"Deferrable Load 1\"}]}' http://localhost:5000/action/publish-data"

And you should be careful that the list of dictionaries has the correct length, which is the number of defined deferrable loads.

Thanks. I am going to try the new friendly name in emhass 3.0.1.


Simplify Expressions / Store / Load

In the abstract, the language contains three types of statement

"LocalAssign" which can either

Load from memory and store to a local
Store an expression to a local

"MemoryAssign" which stores an expression to memory (and does not load)
Assert / Assume / Nop

This proposal is to more cleanly separate this into statements that update the shared state and those which don't.

Make MemoryLoad and MemoryStore no longer expressions, so Expr only contains variables, literals, and Ops. I.e. cannot reference shared state.
Have 3 types of assign statement

LocalAssign ::= LocalVariable  := Expr
MemoryLoad ::= LocalVariable := MemoryLoad(expr, size)
MemoryStore ::= memory := MemoryStore(expr, expr, size)

This maintains the "A MemoryAssign statement never contains a load" invariant in the type system.
Note that a (shared / non-thread-local ) global variable is always accessed through memory stores and loads. As far as I understand the IR's notion of Scope is about boogie's procedure-local/global scope not concurrent sharing. While currently registers are marked global I don't think they should be marked global in the sense the information flow logic describes. Additionally  we should have a correct liveness analysis soon so should be able to go back to declaring them locally and passing them through procedure arguments.

I don't really follow this or the motivation behind it. By 'shared state' are you just referring to memory? Statements that can update memory are already cleanly separated - they are MemoryAssigns (memory stores). Nothing else can update memory.
Yes, Registers are global in terms of scope within the IR and Boogie, but are local in relation to threads which is what matters for the information flow logic. Those are separate concepts and the IR does not conflate them. There isn't really a specific concept of 'global variable' in the IR in terms of threads. There is just non-stack memory (which is shared between threads) and everything else (which is not shared between threads). Global/local for threads does not currently matter for any of the analyses.

Additionally we should have a correct liveness analysis soon so should be able to go back to declaring them locally and passing them through procedure arguments.

What would be the reason to do this? Changing the representation doesn't solve any problems for us.

By 'shared state' are you just referring to memory?

Yes but I'm also thinking about how we will move to the region representation, hopefully eventually "memory" means a set of global boogie variables, some of which are shared and some of which are not shared.

Statements that can update memory are already cleanly separated - they are MemoryAssigns (memory stores).

They are not cleanly separated because the value the MemoryAssign stores is an Expr, which is allowed to be a "MemoryLoad" expression. The fact this is malformed is not enforced by the type system, which is what this issue is about.
Furthermore, statements that read shared memory are not cleanly separated; a LocalAssign can either be a load or a purely local computation and store.

What would be the reason to do this? Changing the representation doesn't solve any problems for us.

I'm not proposing changing their representation in the IR per se, but it seems likely it would be easier for boogie to reason about locals than globals, I think I remember something about the cntlm example not terminating with R21 included? The cleanest way to achieve this might involve changing the IR representation.

hopefully eventually "memory" means a set of global boogie variables, some of which are shared and some of which are not shared.

Yes, that's what the Memory case class is for. Currently we just have Memory variables named "stack" and "mem", with "stack" being specifically treated as non-shared, but to better support multiple non-shared memories additional parameters or subclasses can be created.

They are not cleanly separated because the value the MemoryAssign stores is an Expr, which is allowed to be a "MemoryLoad" expression. The fact this is malformed is not enforced by the type system, which is what this issue is about.

We can safely assume that a store and a load do not happen in the same statement, but this is a separate issue to your original description of separating statements that modify shared state from those that do not. What is the advantage of enforcing this more strictly through the type system?
Your proposal to make MemoryLoad a separate type of statement would require creating many more temporary variables in order to separate out every time a statement loads a value from memory and then does something else with it (often just extending the size to fit the register it is assigned to).

Furthermore, statements that read shared memory are not cleanly separated; a LocalAssign can either be a load or a purely local computation and store.

Why is this important?

I'm not proposing changing their representation in the IR per se, but it seems likely it would be easier for boogie to reason about locals than globals, I think I remember something about the cntlm example not terminating with R21 included?

This isn't something that matters to Boogie and the case you're talking about would not be solved by changing that. Boogie just treats globals that are modified by a procedure call in the same way as locals that are used as both parameter and return value for a procedure call.

A change here I support is making it so MemoryStore is not an Expr, with its functionality being entirely merged with MemoryAssign.


Crash on /2/users/:id/tweets

Hi all! I'm starting to work with the Twitter v2 API, and I've hit a twurl crash:
$ twurl -v
0.9.6
$ twurl '/2/users/139199211/tweets?tweet.fields=attachments&author_id&conversation_id&created_at&entities&geo&id&in_reply_to_user_id&referenced_tweets&source&text'
/Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:175:in `escape': no implicit conversion of nil into String (TypeError)
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:175:in `block in escape_params'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:174:in `each'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:174:in `map'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:174:in `escape_params'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:165:in `block in extract_path!'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:160:in `each'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:160:in `each_with_index'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:160:in `extract_path!'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:108:in `parse_options'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/lib/twurl/cli.rb:17:in `run'
	from /Library/Ruby/Gems/2.6.0/gems/twurl-0.9.6/bin/twurl:4:in `<top (required)>'
	from /usr/local/bin/twurl:23:in `load'
	from /usr/local/bin/twurl:23:in `<main>'

I'm on macOS 12.3.1, Ruby 2.6.0.
Thanks for maintaining twurl, it's great!

I believe the syntax should be to comma separate the tweet.fields values, but I don’t have twurl handy to run this to check right now. Can you try replacing the & with , between the names of the fields (ie. ?tweet.fields=attachments,author_id,etc…).
Also note that twurl will support app-only bearer token authentication which works with several of the v2 endpoints; but at the moment, there are no plans to add full OAuth 2.0 support with the new user authentication and granular scopes.

Hah, true! That fixed it. Apologies, that URL was very obviously broken.
(You might still consider improving the error handling though, crashing is probably still not what you want here. 😁)


Weird timing in matrix multiplication and tensor cores

Hello,
I got a RTX 2070 and have been testing matrix multiplications too see how the performance improves. This is what I got:

(by  cuda I mean without tensor cores)
As you can see, sometimes the tensor cores are faster, mostly not. Another thing to notice is that with cuda sgemm, larger matrices are faster.
What is even more weird is that every time I restart the computer  I got a huge performance with tensor core, like 200 times faster than just cuda, but when I execute the script again I got the image above. Here is an example restarting the computer:
matrix size = 2000
cuda time = 0.0254831314087
tensor core time = 8.01086425781e-05
cuda time/tensor time =<PHONE_NUMBER>57
Is this normal or there is something going on?
Code I used:
`
m = size
n = size
k = size
w = np.float32(np.random.normal(0.0,1.0,(m,k)))
v = np.float32(np.random.normal(0.0,1.0,(k,n)))
z = np.float32(np.zeros((m,n)))
cublas.setMathMode(h, 0)
w_gpu = cp.array(w.T,copy=True)
v_gpu = cp.array(v.T,copy=True)
z_gpu = cp.array(z.T,copy=True)
t0 = time.time()
for counter in range(c):
cublas.sgemm(h, 0, 0, m, n, k, 1.0, w_gpu.data, m, v_gpu.data, k, 0.0, z_gpu.data, m)
t_cuda = time.time() - t0
#tensor core mode
cublas.setMathMode(h, 1)
w2 = np.float16(np.random.normal(0.0,1.0,(m,k)))
v2 = np.float16(np.random.normal(0.0,1.0,(k,n)))
z2 = np.float32(np.zeros((m,n)))
w2_gpu = cp.array(w2.T,copy=True)
v2_gpu = cp.array(v2.T,copy=True)
z2_gpu = cp.array(z2.T,copy=True)
t0 = time.time()
for counter in range(c):
cublas.sgemmEx(h, 0, 0, m, n, k, 1.0, w2_gpu.data, 0, m, v2_gpu.data, 0, k, 0.0, z2_gpu.data, 0, m)
t_tensor = time.time() - t0
print(size, t_cuda, t_tensor, t_cuda/t_tensor)
cublas.destroy(h)
`
CuPy Version          : 6.0.0
CUDA Root             : /usr/local/cuda-10.1
CUDA Build Version    : 10010
CUDA Driver Version   : 10020
CUDA Runtime Version  : 10010
cuDNN Build Version   : 7500
cuDNN Version         : 7500
NCCL Build Version    : 2402
NCCL Runtime Version  : 2402

I've solved the issue, for anyone interested, there are a couple of things going on here:

If your loop creates new matrices, make sure to create and destroy handles as well;
Use gemmEx instead of SgemmEx (the first one does better);
You only will have gains if you do the same operation many times (c large in the code above).


drivers: modem: add support for nrf9160

Added support for nRF9160 modem according to the Zephyr device driver model.
The implementation assumes Serial LTE Modem application by Nordic is running on the nRF9160.

Hi, new modem drivers should be implemented using the new modem subsystem, which you can find here https://github.com/zephyrproject-rtos/zephyr/tree/main/subsys%2Fmodem, you can draw inspiration from here https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/modem/modem_cellular.c and here  https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/gnss/gnss_quectel_lcx6g.c

Hi @bjarki-trackunit,
I had a look at the modem subsystem when i started implementing this driver and i noticed that it wasn't compatible with the nRF9160 as Nordic offers two separate applications to interface to it either using AT commands or PPP and the two are not meant to be used together. Besides that also CMUX is not supported by it.
I used as reference the other modem drivers available in zephyr that only use AT commands as that architecture was suitable for the nRF9160, but apparently is outdated.
Thanks for your reply,
i will be happy to update the driver if and when Nordic will updated the nRF9160 (or newer models) to be compatible with Zephyr's modem subsystem

@AlessioLei94 The new modem subsystem provides the modem backends, which abstract the ISR and Async UART APIs, and a command handling module, modem_chat. You would be using an instance of  modem_chat connected to an instance of modem_backend_uart` which interacts with the UART.
The GNSS subsystem is also based on the new modem subsystem, and does not use PPP or CMUX either :)

Hi @rerickson1, @bjarki-trackunit ,
thanks for the explanations!
I clearly misunderstood what i saw in the modem_cellular.c file, thinking PPP and CMUX were the only ways to go.
I found a couple of videos explaining the modem subsystem, I'll try to get a better understanding of how it should work and rework what i did to follow the modem subsystem architecture

Hi @rerickson1, @bjarki-trackunit , thanks for the explanations! I clearly misunderstood what i saw in the modem_cellular.c file, thinking PPP and CMUX were the only ways to go.
I found a couple of videos explaining the modem subsystem, I'll try to get a better understanding of how it should work and rework what i did to follow the modem subsystem architecture

Fantastic, reach out if you have any questions!

@bjarki-trackunit after having a better look i understand now how the modem_backend and chat works and how i am supposed to be using them.
I think i am just missing one last thing, for what concerns offloaded APIs (sockets, DNS etc..), is everything the same is in the drivers implemented using the old method?
Thanks again for helping me figure this out.

@bjarki-trackunit @rerickson1 after having a better look i understand now how the modem_backend and chat works and how i am supposed to be using them.
I think i am just missing one last thing, for what concerns offloaded APIs (sockets, DNS etc..), is everything the same is in the drivers implemented using the old method?
Thanks again for helping me figure this out.

The socket offloading is not part of the modem subsystem, that is part of the network subsystem, so it will be the same :)

@tomi-font Hi, very nice! I don't know if you are allowed to answer my question, but are you guys planning to implement PPP in the modem firmware? or will the application be offloading the PPP requests to the modems IP stack?
I have a dream that we could use IPC to set up channels instead of CMUX for the nrf91, and send PPP directly to the modem :)
Again, feel free to not answer :D

@tomi-font Do you have any indication about the timeline?

Are there any complications using this, or the upcoming thing @tomi-font hinted at, with silicon revision B0?
For nRF9160 revision B0 the latest modem firmware is v1.2.8, as v1.3.0 and later are targeted at revision B1 and newer. Now, it is not impossible to use modem firmwares v1.3.0 and later with B0 silicon, but it is explicitly recommended to do so for development purposes only.
So, does this and the upcoming work hinted at by @tomi-font work with modem firmware is v1.2.8?

The compatibility table between modem firmware and nRF Connect SDK versions shows that officially, the latest SDK version supported on modem firmware 1.2.8 is 1.5.2. Which is old. And because we are making changes to the application, they will only be available with NCS 2.6.0 or later. Which is definitely not (officially) compatible with modem firmware 1.2.8.
Now as to whether they (MFW 1.2.8 + NCS 2.6.0) could work in practice, well I think clearly not.
Backporting the Serial LTE Modem changes to an older NCS version is also not an option in my opinion because of the amount of work it would require.
So for being able to use the upcoming functionality that I talked about, you will need a recent enough modem firmware. Whether that's on an older HW revision (at your own risk) or a newer one.
Regarding what @AlessioLei94 did, I didn't look into it and don't know what the Serial LTE Modem application was like in older releases, though I'm tempted to say that it has a slightly higher chance to work if the application supports what the driver expects from it.
At best you may have to make changes to the driver and/or application to make up for things that are not supported. The risk is that it's too much work.
All in all I just don't recommend using such old versions.

@AlessioLei94 The modem_context is a hard no :) It has been replaced by the modem modules, modem_socket is not dependent on the modem_context, so you should be able to use it :)

Hi @bjarki-trackunit thanks for your reply. From what i see in the Kconfig file in drivers/modem the config to enable modem_socket  has a dependency on modem_context.
I don't really need modem_context for the driver implementation, but it seems like i have to enable the related config to be able to use the APIs available in modem_socket. Maybe my first question was a bit confusing, i hope this is a better explanation

@AlessioLei94 I believe that is a Kconfig bug, looking through the code, the modem_socket is not dependent. try just pushing MODEM_SOCKET Kconfigs down below endif # MODEM_CONTEXT and build it, should work fine. Then create a PR if it works ;)

@bjarki-trackunit you are right, it seem to be just a bug in the Kconfig file. I fixed it and created the PR

I updated the modem driver to use modem_chat and the uart_backend as @bjarki-trackunit suggested. Not sure if it's still of interest to merge this changes as Nordic is working on updating their application to add PPP and CMUX and add the nrf9160 support to Zephyr. But since i did the work and we are using this code i updated also the branch on which i created the PR

my understanding is that this would be superseded by #68981, correct @bjarki-trackunit ?

my understanding is that this would be superseded by #68981, correct @bjarki-trackunit ?

Yep :)

@bjarki-trackunit @tomi-font Is it known if the driver for nRF9160 will allow to use GNSS functionalities as well? It's very nice the driver that uses CMUX and PPP made by Nordic will be included in Zephyr 3.7.0 but for what i see at the moment it's only for modem functionalities and in our use-case we also need GNSS

We haven't talked about it much yet as the focus has been first on the IP side of things. But this is something should definitely be added rather sooner than later. Unfortunately I can't promise when this will be done, but I hope to be able to look into this relatively soon. (Please let me know if you have any plans on doing anything in this regard in case you need it really quickly so that we are on the same page.)
By the way, regarding what has been done already. Indeed in Zephyr the first version with the changes will be 3.7.0, but we have already cherry-picked them in nRF Connect SDK for the upcoming release (v2.6.0) that is planned for mid-March.
This means that NCS v2.6.0 will already have the modem driver with support for the nRF91 (minus the GNSS functionality, of course).

@tomi-font Thanks for your reply.
At the moment we are using the driver implementation that i made as it seems to be working fine and it also includes the GNSS functionalities. We would prefer to use the implementation included in Zephyr of course but we decided to transition to it once all the functionalities are in place, as it would be more work for us to add (again) GNSS driver to it.


Refactor the ratelimiting behavior out of the request handlers.

As I was browsing the code, I noticed that all get and post handlers had to check for ratelimits before handling the request.
This had been ported over to a ratelimit decorator that we use to wrap any http verb's callback function with the ratelimiting behavior.
I initially implemented this as a Mixin,  but wookie suggested that a per-handler decorator would be better, which makes sense, so it has been changed to that.

Thanks @wookie184 for the alternative approach idea :)

@wookie184 Good point, I'll make it a decorator instead of a mixin.

IMO a cleaner approach could be a per method decorator, as I think it makes more sense for ratelimits to be per method. Then you would have something like this:
class Lexer(Base):
    @ratelimit_endpoint(area="read")
    async def get(self) -> None:
        self.write(utility.list_languages())

Redid the commits to use a decorator instead of a mixin.

I also think that if the change is made here it should be applied to website.py for consistency. Not sure about api_curl or api_deprecated, they could probably be left as is.

I ended up applying it all over.

@shtlrs Awesome!!


Roaring Bitmap

https://github.com/RoaringBitmap/CRoaring

Respected Sir,
Can you please  say what type of help is required in this issue. I am ready to contribute something large in your repository


How to reset when user logout

I am using this architecture for the past six months and I love it.
The only question I have is how can I reset all view models of the app when users log out.
All the ViewModel are singleton so when the user logs out and another user logs in the data of the previous user are still loaded in all the ViewModel.
I face the problem continuously whenever are try to implement a bottom navigation bar with a persistent page.

What I did here was to unregister the LazySingleton when the user logs out. It might be a little dirty, considering this architecture.
 if (locator.isRegistered<MyLazySingleton>()) {
      locator.unregister<MyLazySingleton>();
      locator.registerLazySingleton(
        () => MyLazySingleton(),
      );
    }

I am also looking for a solution to this.

Hey, @paul-ube Here is what I am currently doing not so sure that we should do this in the production app.
I created one function resetLocator() and put it into CustomBaseview whenever a user logs out I will call this function.
resetLocator() async{
    await locator.reset(dispose: true);
    setupLocator();
    setupSnackBarUi();
    setUpBototmSheet();
    setupDialogUi();
  }

Does this answer your question?

Does this answer your question?

Sorry for the late reply.
Is there any better solution? then doing this
resetLocator() async{
    await locator.reset(dispose: true);
    setupLocator();
    setupSnackBarUi();
    setUpBototmSheet();
    setupDialogUi();
  }


Add Debian 12

In the past we waited with adding a new OS until puppet provides AIO packages for the platform. I don't mind adding Debian 12 already but then we need to ensure that we use the distro packages instead.

In the past we waited with adding a new OS until puppet provides AIO packages for the platform. I don't mind adding Debian 12 already but then we need to ensure that we use the distro packages instead.

They still… Okay…
How do I tell it to use distro packages, is that even in this repo? Do I really want to know?

It is in this repository: https://github.com/voxpupuli/puppet_metadata/commit/0dcad5388994a21805a3eaa5446bf61efc716ed0 is how it was done for Arch Linux.
It was in my wish list to support this at some point. We probably need some special casing here:
https://github.com/voxpupuli/puppet_metadata/blob/5ffbf7905b5b9ab1be5cf39d94291ba7b0f7a409/lib/puppet_metadata/github_actions.rb#L63-L67
We probably need something for Fedora too there.

We probably need something for Fedora too there.

https://github.com/voxpupuli/puppet_metadata/pull/104 does that. And I've taken the liberty of taking your PR and rebase it on top of it, doing the same for Debian 12.

Testing it out in https://github.com/voxpupuli/puppet-example/pull/37.

Dependencies to merge & release this:

https://github.com/voxpupuli/voxpupuli-acceptance/pull/70 & release as gem
https://github.com/voxpupuli/beaker_puppet_helpers/pull/37 & release as gem


ghc-mod crashes repeatedly

[Enter steps to reproduce below:]

point to an open buffer for a file (there is an error to report ...)
red crash information window pops up
close with escape
pops up again....

i use ghc. 8.0.2 with stack, the ghc-mod is compiled with same ghc version (stack build ghc-mod and stack install ghc-mod).
this is a show stopper - sorry to say!
andrew
here the log:
Atom Version: 1.13.1
Electron Version: 1.3.13
System: Debian GNU/Linux
Thrown From: haskell-ghc-mod package, v1.19.7
Stack Trace
Haskell-ghc-mod: ghc-mod interactive command type failed with error ghc-modi crashed
At caps: {"version":[5,7,0,0],"fileMap":true,"quoteArgs":true,"optparse":true,"typeConstraints":true,"browseParents":true,"interactiveCaseSplit":true,"importedFrom":false}
URI: /home/frank/Workspace8/atomtest/repo8/dove/Data/DoveRDF.hs
Args: -c,--,46,8
message:
log:
-25.21s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litText"
-25.21s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litText"
-25.21s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litText"
-25.209s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litText"
-25.209s: "Running ghc-modi command map-file","/home/frank/Workspace8/atomtest/repo8/litText/LitText/Text4nlp.hs"
-25.209s: "Writing data to stdin..."
-25.207s: "Got response from ghc-modi:\nOK\n"
-25.207s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litText/LitText/Text4nlp.hs","-c","--",43,15
-24.821s: "ghc-modi said: EXCEPTION: types:"
-24.82s: "ghc-modi said:            Not in scope: type constructor or class ‘Triples’"
-24.82s: "ghc-modi said:            Perhaps you meant ‘Triple’ (imported from LitText.Triple)"
-24.82s: "ghc-modi said:            Perhaps you want to add ‘Triples’ to the import list"
-24.82s: "ghc-modi said:            in the import of ‘Data.RDF’"
-24.82s: "ghc-modi said:            (/tmp/ghc-mod32143/Text4nlp336465782861021530.hs:37:1-44)."
-24.82s: "Got response from ghc-modi:\nOK\n"
-24.819s: "Running ghc-modi command unmap-file","/home/frank/Workspace8/atomtest/repo8/litText/LitText/Text4nlp.hs"
-24.819s: "Got response from ghc-modi:\nOK\n"
-24.819s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litText"
-24.818s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litText"
-24.818s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litText"
-24.818s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litText"
-24.818s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litText"
-24.818s: "Running ghc-modi command map-file","/home/frank/Workspace8/atomtest/repo8/litText/LitText/Text4nlp.hs"
-24.818s: "Writing data to stdin..."
-24.817s: "Got response from ghc-modi:\nOK\n"
-24.817s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litText/LitText/Text4nlp.hs","--","a"
-24.418s: "ghc-modi said: EXCEPTION: info:     Not in scope: ‘a’"
-24.417s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-24.417s: "Running ghc-modi command unmap-file","/home/frank/Workspace8/atomtest/repo8/litText/LitText/Text4nlp.hs"
-24.416s: "Got response from ghc-modi:\nOK\n"
-24.416s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litText"
-0.225s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/dove"
-0.225s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/dove"
-0.225s: "Spawning new ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/dove with",{"cwd":"/home/frank/Workspace8/atomtest/repo8/dove","env":{"ATOM_HOME":"/home/frank/.atom","NODE_PATH":"/usr/share/atom/resources/app.asar/exports","NODE_ENV":"production","LS_COLORS":"","XDG_MENU_PREFIX":"xfce-","LANG":"en_US.utf8","DISPLAY":":0.0","XDG_VTNR":"7","SSH_AUTH_SOCK":"/tmp/ssh-ftV7uTtJKboV/agent.1663","CLASSPATH":"pikes-tintop-1.0-SNAPSHOT-jar-with-dependencies.jar:Semafor-3.0-alpha-04.jar:models/stanford-corenlp-3.5.2-models.jar","GLADE_CATALOG_PATH":":","XDG_SESSION_ID":"4","XDG_GREETER_DATA_DIR":"/var/lib/lightdm/data/frank","USER":"frank","GLADE_MODULE_PATH":":","DESKTOP_SESSION":"lightdm-xsession","PWD":"/home/frank","HOME":"/home/frank","SSH_AGENT_PID":"1704","QT_ACCESSIBILITY":"1","XDG_SESSION_TYPE":"x11","XDG_DATA_DIRS":"/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share","XDG_SESSION_DESKTOP":"lightdm-xsession","GLADE_PIXMAP_PATH":":","DESKTOP_STARTUP_ID":"wrapper-1.0/|usr|share|atom|atom/1768-7-santafe_TIME16739029","GTK_MODULES":"gail:atk-bridge","SHELL":"/bin/bash","XDG_SEAT_PATH":"/org/freedesktop/DisplayManager/Seat0","XDG_CURRENT_DESKTOP":"XFCE","QT_LINUX_ACCESSIBILITY_ALWAYS_ON":"1","SHLVL":"1","XDG_SEAT":"seat0","LANGUAGE":"en_US:en","GDMSESSION":"lightdm-xsession","LOGNAME":"frank","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1010/bus","XDG_RUNTIME_DIR":"/run/user/1010","XAUTHORITY":"/home/frank/.Xauthority","XDG_SESSION_PATH":"/org/freedesktop/DisplayManager/Session0","XDG_CONFIG_DIRS":"/etc/xdg","GOOGLE_API_KEY":"AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q","PATH":"/home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin:/home/frank/.local/bin:/home/frank/.local/bin/:/home/frank/ghc-mod-sandbox/bin/:/home/frank/.cabal/bin:/home/frank/Debinstall83/deb9/amd9.bin:/home/frank/.bin:/home/frank/.bin/corenlp:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games","SESSION_MANAGER":"local/santafe:@/tmp/.ICE-unix/1714,unix/santafe:/tmp/.ICE-unix/1714","_":"/usr/bin/env"},"encoding":"utf-8","maxBuffer":null}
-0.225s: "Spawning new ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/dove with options = ",{"cwd":"/home/frank/Workspace8/atomtest/repo8/dove","env":{"ATOM_HOME":"/home/frank/.atom","NODE_PATH":"/usr/share/atom/resources/app.asar/exports","NODE_ENV":"production","LS_COLORS":"","XDG_MENU_PREFIX":"xfce-","LANG":"en_US.utf8","DISPLAY":":0.0","XDG_VTNR":"7","SSH_AUTH_SOCK":"/tmp/ssh-ftV7uTtJKboV/agent.1663","CLASSPATH":"pikes-tintop-1.0-SNAPSHOT-jar-with-dependencies.jar:Semafor-3.0-alpha-04.jar:models/stanford-corenlp-3.5.2-models.jar","GLADE_CATALOG_PATH":":","XDG_SESSION_ID":"4","XDG_GREETER_DATA_DIR":"/var/lib/lightdm/data/frank","USER":"frank","GLADE_MODULE_PATH":":","DESKTOP_SESSION":"lightdm-xsession","PWD":"/home/frank","HOME":"/home/frank","SSH_AGENT_PID":"1704","QT_ACCESSIBILITY":"1","XDG_SESSION_TYPE":"x11","XDG_DATA_DIRS":"/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share","XDG_SESSION_DESKTOP":"lightdm-xsession","GLADE_PIXMAP_PATH":":","DESKTOP_STARTUP_ID":"wrapper-1.0/|usr|share|atom|atom/1768-7-santafe_TIME16739029","GTK_MODULES":"gail:atk-bridge","SHELL":"/bin/bash","XDG_SEAT_PATH":"/org/freedesktop/DisplayManager/Seat0","XDG_CURRENT_DESKTOP":"XFCE","QT_LINUX_ACCESSIBILITY_ALWAYS_ON":"1","SHLVL":"1","XDG_SEAT":"seat0","LANGUAGE":"en_US:en","GDMSESSION":"lightdm-xsession","LOGNAME":"frank","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1010/bus","XDG_RUNTIME_DIR":"/run/user/1010","XAUTHORITY":"/home/frank/.Xauthority","XDG_SESSION_PATH":"/org/freedesktop/DisplayManager/Session0","XDG_CONFIG_DIRS":"/etc/xdg","GOOGLE_API_KEY":"AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q","PATH":"/home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin:/home/frank/.local/bin:/home/frank/.local/bin/:/home/frank/ghc-mod-sandbox/bin/:/home/frank/.cabal/bin:/home/frank/Debinstall83/deb9/amd9.bin:/home/frank/.bin:/home/frank/.bin/corenlp:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games","SESSION_MANAGER":"local/santafe:@/tmp/.ICE-unix/1714,unix/santafe:/tmp/.ICE-unix/1714","_":"/usr/bin/env"},"encoding":"utf-8","maxBuffer":null}
-0.211s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/dove"
-0.211s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/dove/Data/DoveRDF.hs","-c","--",46,8
-0.01s: "ghc-modi said: Error parsing targets: No local directories found as children of ."

Basically, ghc-mod crashes.
Honestly, I have no idea why. Running  ghc-mod "/home/frank/Workspace8/atomtest/repo8/dove/Data/DoveRDF.hs -c 46 8 manually might give more information. Make sure current working directory is /home/frank/Workspace8/atomtest/repo8/dove.
Sorry I can't me of more immediate help.

thank you for your immediate reaction. it should not touch the dove directory, the stack.yaml is later.
for the command ghc-mod "/home/frank/Workspace8/atomtest/repo8/dove/Data/DoveRDF.hs" -c -- 46 8 i get "invalid option -c. can you tell me what the command should look excatly  - i cannot see a -c option?
flags: {}
extra-package-dbs: []
packages:
- '.'
- litText
- litNLP
- rdf4store
- rdfhextension
- uniform/uniform-algebras/
- uniform/uniform-convenience/
- uniform/uniform-error/
- uniform/uniform-fileio/
- uniform/uniform-strings/
- uniform/uniform-time/
extra-deps:
- chatter-<IP_ADDRESS>
- data-easy-0.7.0
- fullstop-0.1.4
- hgal-<IP_ADDRESS>
- non-negative-0.1.1
- numeric-prelude-0.4.2
- posix-paths-<IP_ADDRESS>
- rdf4h-3.0.1
- test-invariant-<IP_ADDRESS>
- tokenize-0.3.0
resolver: lts-8.1

Oh, sorry, I forgot type. So the command should actually be
ghc-mod type "/home/frank/Workspace8/atomtest/repo8/dove/Data/DoveRDF.hs" -c -- 46 8

frank@santafe:~/Workspace8/atomtest/repo8/dove$ ghc-mod type "/home/frank/Workspace8/atomtest/repo8/dove/Data/DoveRDF.hs" -c -- 46 8
the reply then is
Error parsing targets: No local directories found as children of .
EXCEPTION: types:
           readCreateProcess: stack "build" "--only-dependencies" "." (exit 1): failed

the stack.yaml (in home/frank/Workspace/atomtest/repo8) you have above. i guess the point is that
there is no entry for dove because i do not work on this right now.
stack build on this directory gives the error message that ghc-mod is reporting, but stack build on the directory above does not enter the dove directory. i sense there might be a broad direction to work on all subdirectories (some *)  and not only on those in the stack.yaml.
thank you for your effort!

Well, there is a change in ghc-mod master that removes this particular call to stack build unless explicitly requested, but ghc-mod still needs to at least be able to configure the project, and in the absence of stack.yaml that could be tricky. But if you're not working on dove, I wonder why it tries to read an expression type? Do you just happen to have DoveRDF open?

i will check your suggestion next time i see this error. thank you for the help.

same setup, but i guess a different type of crash:
[Enter steps to reproduce below:]
i edit some variable names in Main.hs - save to check the changes - >

save a change in file litNLP/scr/Main (there are further errors in the code) -- there is no other file open
error pops up
(can be repeated, it pops up even if there are not haskell errors in the file)
same crash after a build.

the file missing (littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b) is in the outer (stackroot.stack-work) dir.
Atom Version: 1.13.1
Electron Version: 1.3.13
System: Debian GNU/Linux
Thrown From: haskell-ghc-mod package, v1.19.7
Stack Trace
Haskell-ghc-mod: ghc-mod command check failed with error Error
At caps: {"version":[5,7,0,0],"fileMap":true,"quoteArgs":true,"optparse":true,"typeConstraints":true,"browseParents":true,"interactiveCaseSplit":true,"importedFrom":false}
URI: /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs
Args: --
message: Command failed: /home/frank/.local/bin/ghc-mod check /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs --
ghc-mod: <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b
    (use -v for more information)

log:
-19.453s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.453s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.453s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.452s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.452s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","-c","--",53,44
-19.281s: "ghc-modi said: EXCEPTION: types:"
-19.281s: "ghc-modi said:            <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-19.28s: "ghc-modi said:                (use -v for more information)"
-19.28s: "Got response from ghc-modi:\nOK\n"
-19.28s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","--",""
-19.15s: "ghc-modi said: EXCEPTION: info:"
-19.15s: "ghc-modi said:                <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-19.149s: "ghc-modi said:                    (use -v for more information)"
-19.149s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-19.149s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","-c","--",52,52
-12.738s: "ghc-modi said: EXCEPTION: types:"
-12.738s: "ghc-modi said:            <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-12.738s: "ghc-modi said:                (use -v for more information)"
-12.738s: "Got response from ghc-modi:\nOK\n"
-12.737s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","--","implemented"
-12.621s: "ghc-modi said: EXCEPTION: info:"
-12.621s: "ghc-modi said:                <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-12.621s: "ghc-modi said:                    (use -v for more information)"
-12.621s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-12.621s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","-c","--",62,34
-5.063s: "ghc-modi said: EXCEPTION: types:"
-5.063s: "ghc-modi said:            <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-5.063s: "ghc-modi said:                (use -v for more information)"
-5.062s: "Got response from ghc-modi:\nOK\n"
-5.062s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","--","nlpstate"
-4.936s: "ghc-modi said: EXCEPTION: info:"
-4.936s: "ghc-modi said:                <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-4.936s: "ghc-modi said:                    (use -v for more information)"
-4.936s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-4.936s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-0.272s: "Running /home/frank/.local/bin/ghc-mod check,/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs,-- with opts = ",{"cwd":"/home/frank/Workspace8/atomtest/repo8/litNLP","env":{"ATOM_HOME":"/home/frank/.atom","NODE_PATH":"/usr/share/atom/resources/app.asar/exports","NODE_ENV":"production","LS_COLORS":"","XDG_MENU_PREFIX":"xfce-","LANG":"en_US.utf8","DISPLAY":":0.0","CHROME_DESKTOP":"Atom.desktop","XDG_VTNR":"7","SSH_AUTH_SOCK":"/tmp/ssh-ftV7uTtJKboV/agent.1663","CLASSPATH":"pikes-tintop-1.0-SNAPSHOT-jar-with-dependencies.jar:Semafor-3.0-alpha-04.jar:models/stanford-corenlp-3.5.2-models.jar","GLADE_CATALOG_PATH":":","XDG_SESSION_ID":"4","XDG_GREETER_DATA_DIR":"/var/lib/lightdm/data/frank","USER":"frank","GLADE_MODULE_PATH":":","DESKTOP_SESSION":"lightdm-xsession","PWD":"/home/frank","HOME":"/home/frank","SSH_AGENT_PID":"1704","QT_ACCESSIBILITY":"1","XDG_SESSION_TYPE":"x11","XDG_DATA_DIRS":"/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share","XDG_SESSION_DESKTOP":"lightdm-xsession","GLADE_PIXMAP_PATH":":","GTK_MODULES":"gail:atk-bridge","SHELL":"/bin/bash","XDG_SEAT_PATH":"/org/freedesktop/DisplayManager/Seat0","XDG_CURRENT_DESKTOP":"XFCE","QT_LINUX_ACCESSIBILITY_ALWAYS_ON":"1","SHLVL":"1","XDG_SEAT":"seat0","LANGUAGE":"en_US:en","GDMSESSION":"lightdm-xsession","LOGNAME":"frank","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1010/bus","XDG_RUNTIME_DIR":"/run/user/1010","XAUTHORITY":"/home/frank/.Xauthority","XDG_SESSION_PATH":"/org/freedesktop/DisplayManager/Session0","XDG_CONFIG_DIRS":"/etc/xdg","GOOGLE_API_KEY":"AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q","PATH":"/home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin:/home/frank/.local/bin:/home/frank/.local/bin/:/home/frank/ghc-mod-sandbox/bin/:/home/frank/.cabal/bin:/home/frank/Debinstall83/deb9/amd9.bin:/home/frank/.bin:/home/frank/.bin/corenlp:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games","SESSION_MANAGER":"local/santafe:@/tmp/.ICE-unix/1714,unix/santafe:/tmp/.ICE-unix/1714","_":"/usr/bin/env"},"encoding":"utf-8","maxBuffer":null}
-0.001s: "ghc-mod: <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b\n    (use -v for more information)\n"
-0.001s: "Running /home/frank/.local/bin/ghc-mod check,/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs,-- failed with ",{"killed":false,"code":1,"signal":null,"cmd":"/home/frank/.local/bin/ghc-mod check /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs --"}
0s: {"killed":false,"code":1,"signal":null,"cmd":"/home/frank/.local/bin/ghc-mod check /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs --"}

Error
    at /home/frank/.atom/packages/haskell-ghc-mod/lib/util.coffee:60:26
    at ChildProcess.exithandler (child_process.js:225:5)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Socket.<anonymous> (internal/child_process.js:334:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at Pipe._handle.close [as _onclose] (net.js:493:12)

Commands
     -9:36.4.0 ide-haskell:prettify-file (ol.tree-view.full-menu.list-tree.has-collapsable-children.focusable-panel)
 14x -9:08.5.0 core:close (input.hidden-input)
     -8:42.5.0 core:backspace (input.hidden-input)
     -0:38.8.0 core:copy (input.hidden-input)
     -0:35.9.0 core:save (input.hidden-input)
     -0:35.9.0 ide-haskell:prettify-file (atom-text-editor.editor.is-focused)
     -0:00.3.0 haskell-ghc-mod:check-file (input.hidden-input)

Config
{
  "core": {
    "automaticallyUpdate": false,
    "closeEmptyWindows": false,
    "destroyEmptyPanes": false,
    "packagesWithKeymapsDisabled": [],
    "projectHome": "ssh://ascona/stFolder/AF/ServerOnly/repo8.git",
    "telemetryConsent": "no",
    "themes": [
      "atom-light-ui",
      "atom-light-syntax"
    ]
  },
  "haskell-ghc-mod": {
    "additionalPathDirectories": [
      "/home/frank/.local/bin"
    ],
    "ghcModPath": "/home/frank/.local/bin/ghc-mod",
    "onSaveLint": false
  }
}

Installed Packages
# User
autocomplete-haskell, v0.7.2 (active)
git-plus, v7.3.2 (active)
haskell-ghc-mod, v1.19.7 (active)
ide-haskell, v1.9.4 (active)
ide-haskell-cabal, v1.7.5 (active)
language-haskell, v1.12.1 (active)
atom-dark-syntax, v0.28.0 (inactive)
atom-dark-ui, v0.53.0 (inactive)
atom-light-syntax, v0.29.0 (active)
atom-light-ui, v0.46.0 (active)
base16-tomorrow-dark-theme, v1.4.0 (inactive)
base16-tomorrow-light-theme, v1.4.0 (inactive)
one-dark-ui, v1.8.2 (inactive)
one-light-ui, v1.8.2 (inactive)
one-dark-syntax, v1.6.0 (inactive)
one-light-syntax, v1.6.0 (inactive)
solarized-dark-syntax, v1.1.1 (inactive)
solarized-light-syntax, v1.1.1 (inactive)
about, v1.7.2 (active)
archive-view, v0.62.0 (active)
autocomplete-atom-api, v0.10.0 (active)
autocomplete-css, v0.14.1 (active)
autocomplete-html, v0.7.2 (active)
autocomplete-plus, v2.33.1 (active)
autocomplete-snippets, v1.11.0 (active)
autoflow, v0.29.0 (inactive)
autosave, v0.23.2 (active)
background-tips, v0.26.1 (active)
bookmarks, v0.43.2 (active)
bracket-matcher, v0.85.1 (active)
command-palette, v0.39.1 (inactive)
deprecation-cop, v0.55.1 (active)
dev-live-reload, v0.47.0 (active)
encoding-selector, v0.22.0 (active)
exception-reporting, v0.40.0 (active)
find-and-replace, v0.204.5 (active)
fuzzy-finder, v1.4.0 (active)
git-diff, v1.2.0 (active)
go-to-line, v0.31.2 (inactive)
grammar-selector, v0.48.2 (active)
image-view, v0.60.0 (active)
incompatible-packages, v0.26.1 (active)
keybinding-resolver, v0.35.0 (active)
line-ending-selector, v0.5.1 (active)
link, v0.31.2 (inactive)
markdown-preview, v0.159.3 (active)
metrics, v1.1.3 (active)
notifications, v0.65.1 (active)
open-on-github, v1.2.1 (inactive)
package-generator, v1.0.2 (inactive)
settings-view, v0.244.0 (active)
snippets, v1.0.4 (active)
spell-check, v0.68.5 (active)
status-bar, v1.6.0 (active)
styleguide, v0.48.0 (active)
symbols-view, v0.113.1 (inactive)
tabs, v0.103.1 (active)
timecop, v0.33.2 (active)
tree-view, v0.211.1 (active)
update-package-dependencies, v0.10.0 (active)
welcome, v0.35.1 (active)
whitespace, v0.35.0 (active)
wrap-guide, v0.39.0 (active)
language-c, v0.54.0 (active)
language-clojure, v0.22.1 (active)
language-coffee-script, v0.48.1 (active)
language-csharp, v0.13.0 (active)
language-css, v0.40.1 (active)
language-gfm, v0.88.0 (active)
language-git, v0.15.0 (active)
language-go, v0.43.0 (active)
language-html, v0.47.1 (active)
language-hyperlink, v0.16.1 (active)
language-java, v0.24.0 (active)
language-javascript, v0.122.0 (active)
language-json, v0.18.3 (active)
language-less, v0.29.6 (active)
language-make, v0.22.2 (active)
language-mustache, v0.13.0 (active)
language-objective-c, v0.15.1 (active)
language-perl, v0.37.0 (active)
language-php, v0.37.3 (active)
language-property-list, v0.8.0 (active)
language-python, v0.45.1 (active)
language-ruby, v0.70.2 (active)
language-ruby-on-rails, v0.25.1 (active)
language-sass, v0.57.0 (active)
language-shellscript, v0.23.0 (active)
language-source, v0.9.0 (active)
language-sql, v0.25.0 (active)
language-text, v0.7.1 (active)
language-todo, v0.29.1 (active)
language-toml, v0.18.1 (active)
language-xml, v0.34.12 (active)
language-yaml, v0.27.1 (active)

# Dev
No dev packages

Okay, so this is trickier. Basically, ghc-mod can't find littext that your project uses. There could be a lot of reasons for that, but maybe that's just a problem with package-db paths (which we should probably fix on ghc-mod side of things, but it can get rather tricky, see https://github.com/DanielG/ghc-mod/issues/787). Could you post output of stack path run in /home/frank/Workspace8/atomtest/repo8/litNLP and the directory where superproject stack.yaml is located (I'm assuming /home/frank/Workspace8/atomtest/repo8)?
Thanks. And sorry you're running into these issues.

same setup, but i guess a different type of crash:
[Enter steps to reproduce below:]
i edit some variable names in Main.hs - save to check the changes - >

save a change in file litNLP/scr/Main (there are further errors in the code) -- there is no other file open
error pops up
(can be repeated, it pops up even if there are not haskell errors in the file)
same crash after a build.

the file missing (littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b) is in the outer (stackroot.stack-work) dir.
Atom Version: 1.13.1
Electron Version: 1.3.13
System: Debian GNU/Linux
Thrown From: haskell-ghc-mod package, v1.19.7
Stack Trace
Haskell-ghc-mod: ghc-mod command check failed with error Error
At caps: {"version":[5,7,0,0],"fileMap":true,"quoteArgs":true,"optparse":true,"typeConstraints":true,"browseParents":true,"interactiveCaseSplit":true,"importedFrom":false}
URI: /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs
Args: --
message: Command failed: /home/frank/.local/bin/ghc-mod check /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs --
ghc-mod: <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b
    (use -v for more information)

log:
-19.453s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.453s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.453s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.452s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.452s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","-c","--",53,44
-19.281s: "ghc-modi said: EXCEPTION: types:"
-19.281s: "ghc-modi said:            <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-19.28s: "ghc-modi said:                (use -v for more information)"
-19.28s: "Got response from ghc-modi:\nOK\n"
-19.28s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-19.279s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","--",""
-19.15s: "ghc-modi said: EXCEPTION: info:"
-19.15s: "ghc-modi said:                <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-19.149s: "ghc-modi said:                    (use -v for more information)"
-19.149s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-19.149s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.875s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","-c","--",52,52
-12.738s: "ghc-modi said: EXCEPTION: types:"
-12.738s: "ghc-modi said:            <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-12.738s: "ghc-modi said:                (use -v for more information)"
-12.738s: "Got response from ghc-modi:\nOK\n"
-12.737s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-12.737s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","--","implemented"
-12.621s: "ghc-modi said: EXCEPTION: info:"
-12.621s: "ghc-modi said:                <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-12.621s: "ghc-modi said:                    (use -v for more information)"
-12.621s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-12.621s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.201s: "Running ghc-modi command type","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","-c","--",62,34
-5.063s: "ghc-modi said: EXCEPTION: types:"
-5.063s: "ghc-modi said:            <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-5.063s: "ghc-modi said:                (use -v for more information)"
-5.062s: "Got response from ghc-modi:\nOK\n"
-5.062s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Trying to run ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Checking for ghc-modi in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Found running ghc-modi instance for /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Started interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-5.062s: "Running ghc-modi command info","/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs","--","nlpstate"
-4.936s: "ghc-modi said: EXCEPTION: info:"
-4.936s: "ghc-modi said:                <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b"
-4.936s: "ghc-modi said:                    (use -v for more information)"
-4.936s: "Got response from ghc-modi:\nCannot show info\nOK\n"
-4.936s: "Ended interactive action block in /home/frank/Workspace8/atomtest/repo8/litNLP"
-0.272s: "Running /home/frank/.local/bin/ghc-mod check,/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs,-- with opts = ",{"cwd":"/home/frank/Workspace8/atomtest/repo8/litNLP","env":{"ATOM_HOME":"/home/frank/.atom","NODE_PATH":"/usr/share/atom/resources/app.asar/exports","NODE_ENV":"production","LS_COLORS":"","XDG_MENU_PREFIX":"xfce-","LANG":"en_US.utf8","DISPLAY":":0.0","CHROME_DESKTOP":"Atom.desktop","XDG_VTNR":"7","SSH_AUTH_SOCK":"/tmp/ssh-ftV7uTtJKboV/agent.1663","CLASSPATH":"pikes-tintop-1.0-SNAPSHOT-jar-with-dependencies.jar:Semafor-3.0-alpha-04.jar:models/stanford-corenlp-3.5.2-models.jar","GLADE_CATALOG_PATH":":","XDG_SESSION_ID":"4","XDG_GREETER_DATA_DIR":"/var/lib/lightdm/data/frank","USER":"frank","GLADE_MODULE_PATH":":","DESKTOP_SESSION":"lightdm-xsession","PWD":"/home/frank","HOME":"/home/frank","SSH_AGENT_PID":"1704","QT_ACCESSIBILITY":"1","XDG_SESSION_TYPE":"x11","XDG_DATA_DIRS":"/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share","XDG_SESSION_DESKTOP":"lightdm-xsession","GLADE_PIXMAP_PATH":":","GTK_MODULES":"gail:atk-bridge","SHELL":"/bin/bash","XDG_SEAT_PATH":"/org/freedesktop/DisplayManager/Seat0","XDG_CURRENT_DESKTOP":"XFCE","QT_LINUX_ACCESSIBILITY_ALWAYS_ON":"1","SHLVL":"1","XDG_SEAT":"seat0","LANGUAGE":"en_US:en","GDMSESSION":"lightdm-xsession","LOGNAME":"frank","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1010/bus","XDG_RUNTIME_DIR":"/run/user/1010","XAUTHORITY":"/home/frank/.Xauthority","XDG_SESSION_PATH":"/org/freedesktop/DisplayManager/Session0","XDG_CONFIG_DIRS":"/etc/xdg","GOOGLE_API_KEY":"AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q","PATH":"/home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin:/home/frank/.local/bin:/home/frank/.local/bin/:/home/frank/ghc-mod-sandbox/bin/:/home/frank/.cabal/bin:/home/frank/Debinstall83/deb9/amd9.bin:/home/frank/.bin:/home/frank/.bin/corenlp:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games","SESSION_MANAGER":"local/santafe:@/tmp/.ICE-unix/1714,unix/santafe:/tmp/.ICE-unix/1714","_":"/usr/bin/env"},"encoding":"utf-8","maxBuffer":null}
-0.001s: "ghc-mod: <command line>: cannot satisfy -package-id littext-0.1.5-7nQiLhZ2W7HKKsiHrohk7b\n    (use -v for more information)\n"
-0.001s: "Running /home/frank/.local/bin/ghc-mod check,/home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs,-- failed with ",{"killed":false,"code":1,"signal":null,"cmd":"/home/frank/.local/bin/ghc-mod check /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs --"}
0s: {"killed":false,"code":1,"signal":null,"cmd":"/home/frank/.local/bin/ghc-mod check /home/frank/Workspace8/atomtest/repo8/litNLP/src/Main.hs --"}

Error
    at /home/frank/.atom/packages/haskell-ghc-mod/lib/util.coffee:60:26
    at ChildProcess.exithandler (child_process.js:225:5)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Socket.<anonymous> (internal/child_process.js:334:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at Pipe._handle.close [as _onclose] (net.js:493:12)

Commands
     -9:36.4.0 ide-haskell:prettify-file (ol.tree-view.full-menu.list-tree.has-collapsable-children.focusable-panel)
 14x -9:08.5.0 core:close (input.hidden-input)
     -8:42.5.0 core:backspace (input.hidden-input)
     -0:38.8.0 core:copy (input.hidden-input)
     -0:35.9.0 core:save (input.hidden-input)
     -0:35.9.0 ide-haskell:prettify-file (atom-text-editor.editor.is-focused)
     -0:00.3.0 haskell-ghc-mod:check-file (input.hidden-input)

Config
{
  "core": {
    "automaticallyUpdate": false,
    "closeEmptyWindows": false,
    "destroyEmptyPanes": false,
    "packagesWithKeymapsDisabled": [],
    "projectHome": "ssh://ascona/stFolder/AF/ServerOnly/repo8.git",
    "telemetryConsent": "no",
    "themes": [
      "atom-light-ui",
      "atom-light-syntax"
    ]
  },
  "haskell-ghc-mod": {
    "additionalPathDirectories": [
      "/home/frank/.local/bin"
    ],
    "ghcModPath": "/home/frank/.local/bin/ghc-mod",
    "onSaveLint": false
  }
}

Installed Packages
# User
autocomplete-haskell, v0.7.2 (active)
git-plus, v7.3.2 (active)
haskell-ghc-mod, v1.19.7 (active)
ide-haskell, v1.9.4 (active)
ide-haskell-cabal, v1.7.5 (active)
language-haskell, v1.12.1 (active)
atom-dark-syntax, v0.28.0 (inactive)
atom-dark-ui, v0.53.0 (inactive)
atom-light-syntax, v0.29.0 (active)
atom-light-ui, v0.46.0 (active)
base16-tomorrow-dark-theme, v1.4.0 (inactive)
base16-tomorrow-light-theme, v1.4.0 (inactive)
one-dark-ui, v1.8.2 (inactive)
one-light-ui, v1.8.2 (inactive)
one-dark-syntax, v1.6.0 (inactive)
one-light-syntax, v1.6.0 (inactive)
solarized-dark-syntax, v1.1.1 (inactive)
solarized-light-syntax, v1.1.1 (inactive)
about, v1.7.2 (active)
archive-view, v0.62.0 (active)
autocomplete-atom-api, v0.10.0 (active)
autocomplete-css, v0.14.1 (active)
autocomplete-html, v0.7.2 (active)
autocomplete-plus, v2.33.1 (active)
autocomplete-snippets, v1.11.0 (active)
autoflow, v0.29.0 (inactive)
autosave, v0.23.2 (active)
background-tips, v0.26.1 (active)
bookmarks, v0.43.2 (active)
bracket-matcher, v0.85.1 (active)
command-palette, v0.39.1 (inactive)
deprecation-cop, v0.55.1 (active)
dev-live-reload, v0.47.0 (active)
encoding-selector, v0.22.0 (active)
exception-reporting, v0.40.0 (active)
find-and-replace, v0.204.5 (active)
fuzzy-finder, v1.4.0 (active)
git-diff, v1.2.0 (active)
go-to-line, v0.31.2 (inactive)
grammar-selector, v0.48.2 (active)
image-view, v0.60.0 (active)
incompatible-packages, v0.26.1 (active)
keybinding-resolver, v0.35.0 (active)
line-ending-selector, v0.5.1 (active)
link, v0.31.2 (inactive)
markdown-preview, v0.159.3 (active)
metrics, v1.1.3 (active)
notifications, v0.65.1 (active)
open-on-github, v1.2.1 (inactive)
package-generator, v1.0.2 (inactive)
settings-view, v0.244.0 (active)
snippets, v1.0.4 (active)
spell-check, v0.68.5 (active)
status-bar, v1.6.0 (active)
styleguide, v0.48.0 (active)
symbols-view, v0.113.1 (inactive)
tabs, v0.103.1 (active)
timecop, v0.33.2 (active)
tree-view, v0.211.1 (active)
update-package-dependencies, v0.10.0 (active)
welcome, v0.35.1 (active)
whitespace, v0.35.0 (active)
wrap-guide, v0.39.0 (active)
language-c, v0.54.0 (active)
language-clojure, v0.22.1 (active)
language-coffee-script, v0.48.1 (active)
language-csharp, v0.13.0 (active)
language-css, v0.40.1 (active)
language-gfm, v0.88.0 (active)
language-git, v0.15.0 (active)
language-go, v0.43.0 (active)
language-html, v0.47.1 (active)
language-hyperlink, v0.16.1 (active)
language-java, v0.24.0 (active)
language-javascript, v0.122.0 (active)
language-json, v0.18.3 (active)
language-less, v0.29.6 (active)
language-make, v0.22.2 (active)
language-mustache, v0.13.0 (active)
language-objective-c, v0.15.1 (active)
language-perl, v0.37.0 (active)
language-php, v0.37.3 (active)
language-property-list, v0.8.0 (active)
language-python, v0.45.1 (active)
language-ruby, v0.70.2 (active)
language-ruby-on-rails, v0.25.1 (active)
language-sass, v0.57.0 (active)
language-shellscript, v0.23.0 (active)
language-source, v0.9.0 (active)
language-sql, v0.25.0 (active)
language-text, v0.7.1 (active)
language-todo, v0.29.1 (active)
language-toml, v0.18.1 (active)
language-xml, v0.34.12 (active)
language-yaml, v0.27.1 (active)

# Dev
No dev packages

here the stack path that you asked for - regarding the first issue.
do you think the second issue (comment above) is related or separate? if separate, delete or move to a new issue, please.
i wonder if i should add the solution form https://github.com/DanielG/ghc-mod/issues/787 ad. i think i can do this, if you believe that it would help (or clarify the issue)
in the root:
frank@santafe:~/Workspace8/atomtest/repo8$ stack path
stack-root: /home/frank/.stack
project-root: /home/frank/Workspace8/atomtest/repo8
config-location: /home/frank/Workspace8/atomtest/repo8/stack.yaml
bin-path: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin:/home/frank/.local/bin:/home/frank/.local/bin/:/home/frank/ghc-mod-sandbox/bin/:/home/frank/.cabal/bin:/home/frank/Debinstall83/deb9/amd9.bin:/home/frank/.bin:/home/frank/.bin/corenlp:/home/frank/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
programs: /home/frank/.stack/programs/x86_64-linux
compiler-exe: /home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin/ghc
compiler-bin: /home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin
local-bin: /home/frank/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb
local-pkg-db: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb
global-pkg-db: /home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/lib/ghc-8.0.2/package.conf.d
ghc-package-path: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb:/home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/lib/ghc-8.0.2/package.conf.d
snapshot-install-root: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2
local-install-root: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2
snapshot-doc-root: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/doc
local-doc-root: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/doc
dist-dir: .stack-work/dist/x86_64-linux-nopie/Cabal-<IP_ADDRESS>
local-hpc-root: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/hpc
local-bin-path: /home/frank/.local/bin
ghc-paths: /home/frank/.stack/programs/x86_64-linux

and in litNLP
frank@santafe:~/Workspace8/atomtest/repo8/litNLP$ stack path
stack-root: /home/frank/.stack
project-root: /home/frank/Workspace8/atomtest/repo8
config-location: /home/frank/Workspace8/atomtest/repo8/stack.yaml
bin-path: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/bin:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin:/home/frank/.local/bin:/home/frank/.local/bin/:/home/frank/ghc-mod-sandbox/bin/:/home/frank/.cabal/bin:/home/frank/Debinstall83/deb9/amd9.bin:/home/frank/.bin:/home/frank/.bin/corenlp:/home/frank/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
programs: /home/frank/.stack/programs/x86_64-linux
compiler-exe: /home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin/ghc
compiler-bin: /home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin
local-bin: /home/frank/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb
local-pkg-db: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb
global-pkg-db: /home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/lib/ghc-8.0.2/package.conf.d
ghc-package-path: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb:/home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/pkgdb:/home/frank/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/lib/ghc-8.0.2/package.conf.d
snapshot-install-root: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2
local-install-root: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2
snapshot-doc-root: /home/frank/.stack/snapshots/x86_64-linux-nopie/lts-8.1/8.0.2/doc
local-doc-root: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/doc
dist-dir: .stack-work/dist/x86_64-linux-nopie/Cabal-<IP_ADDRESS>
local-hpc-root: /home/frank/Workspace8/atomtest/repo8/.stack-work/install/x86_64-linux-nopie/lts-8.1/8.0.2/hpc
local-bin-path: /home/frank/.local/bin
ghc-paths: /home/frank/.stack/programs/x86_64-linux

i hope this is helpful.

Strangely enough, everything seems to be in order...
So here's an idea...

Close Atom.
Remove .stack-work from sub-projects (litText, litNLP in particular)
Run stack build in superproject (/home/frank/Workspace8/atomtest/repo8)
Run stack build ghc-mod in superproject (no need for stack install btw)
Run Atom in super- or sub-project.

I've tried with a simple a-b project (i.e. superproject references projects a and b, where b depends on a, no stack.yaml in sub-projects), and everything seems to work... If your project is opensource and available from github or something similar, I might test with it directly. If not, don't worry about it.
Also,  for good measure, run stack exec ghc-mod debug in litNLP and litText and post output here, maybe I'm missing something.

As for the relevance to the first issue... Well, frankly, first one is a non-issue honestly. Ghc-mod is not supposed to work when stack can't configure the project, and from what I understood, the project that threw an error is "disabled". So... yeah. Big scary red box just basically says "hey, ghc-mod can't handle this".
The second issue is different in this regard, as it should work, but for some obscure reason does not, and it's not related in any shape or form to the first one. Since github doesn't provide means for splitting issues, I'm just going to leave this as it is.

i followed you advice to delete all .stack-work (except in superproject) (and i have included the missing dove directory in stack.yaml - which is not recompiled, so no time lost). it works. Again, thank you for your patience!
nevertheless, i think if a subdirectory is not in the stack.yaml, then it should be ignored by ghc-mod.
ps.
i also tried to split the issues, but i am not certain i did this right and perhaps confused the whole, so i close this discusion.  feel free to close #201 and i will reopen, when i have a new case.

nevertheless, i think if a subdirectory is not in the stack.yaml, then it should be ignored by ghc-mod.

Problem is, stack doesn't report if a given project is not in stack.yaml. So only way to know is try to configure it and see if it fails. But it can fail for a huge number of other reasons. So... you know, we've opted for an obvious solution of "tell the user something went wrong". Better error messages should alleviate the problem somewhat, but that's pretty low on the priority list and let's say, it's trickier than it should be. I've toyed with the idea of improving ghc-mod's API to make this kind of thing easier, but it's pretty much in its infancy, and there are a lot of more pressing issues at the moment.


Create discussion entry for Concurrent programming

The proposal is in the file Announcements.md.

Forked form #205

#224; #225; #226; #227


LLVM Integration broke SPIR-V round tests.

The LLVM integration PR https://github.com/google/iree/pull/9610 broke the SPIRV tests for round.mlir. Seems related to https://github.com/google/iree-llvm-fork/commit/ce07b95610f7f8e70738790790a95e61a415e128 .
This bug is to track the re-enabling of these.

https://reviews.llvm.org/D129236 should fix the spirv issues


search_pubs - StopIteration

Describe the bug
After I run the code, I receive this error:

StopIteration                             Traceback (most recent call last)
 in <cell line: 8>()
6
7 search_query = scholarly.search_pubs("Advances in the diagnosis and treatment of small bowel lesions with Crohn's disease using double-balloon endoscopy")
----> 8 scholarly.pprint(next(search_query))
/usr/local/lib/python3.10/dist-packages/scholarly/publication_parser.py in next(self)
91             return self.next()
92         else:
---> 93             raise StopIteration
94
95     # Pickle protocol
StopIteration:
To Reproduce
from scholarly import scholarly, ProxyGenerator
pg = ProxyGenerator()
success = pg.FreeProxies()
scholarly.use_proxy(pg)
search_query = scholarly.search_pubs("Advances in the diagnosis and treatment of small bowel lesions with Crohn's disease using double-balloon endoscopy")
scholarly.pprint(next(search_query))
Expected behavior
I would like to give to Scholarly a title and then to have the url for the PDF as return, please.
Desktop (please complete the following information):

Proxy service: FreeProxies
python version: 3.10.12
Colab

Thank you in advance!

Any update? Still getting this issue @ipeirotis @papr @marcoscarpetta @guicho271828

You need a paid proxy for searching publications.

@Owaiskhan9654 , that was not the issue that OP @MatteoRiva95 posted.
The issue was with the exception StopIteration, which I don't think it has anything to do with Proxies.
First, consider this code:
from scholarly import scholarly

search_phrase = "massive MIMO"
search_query = scholarly.search_pubs(search_phrase)
search_query2 = scholarly.search_pubs(search_phrase, start_index=970)

You will get:
search_query.total_results --> 179000
search_query2.total_results --> 0 (it's 0 even if start_index= 10)
This is issue 1.
Issue 2:
When you iterate over the results using next(search_query).
search_query2 raises THAT exception (StopIteration) after 10 results or so.
What's going on? Any idea @ipeirotis?

Seems to be related to the anti-crawling mechanism of Google. The URL that we create seems to be flagged as unusual by Google and Google returns back an "error" page. I do not have a clear path how to fix this.


Arrow break positioning

Reproduction demo
https://codesandbox.io/s/9ljo697wzw
Steps to reproduce the problem

Commenting the arrow div change the positioning of the popper

What is the expected behavior?
Popper positioning is the same with and without arrow
What went wrong?
I didn't specify an absolute position for the arrow div.
Any other comments?
Packages versions

Popper.js:
react-popper: 1.3.3

I am seeing the same issue. Any investigation or any progress?

The arrow component should have position: absolute.
https://codesandbox.io/s/61ny1qp3zz

I agree, the arrow isn't the direct culprit. Generally with an arrow you use offset, I think the real problem is deeper with the positioning and when you have offsets. Investigating further to see if I am just implementing incorrectly or there is something wrong. computeStyle shows it takes into account offsets so there is something going on.

@FezVrasta yes I understood it after a couple of hours of investigation. I would suggest to write this somewhere in the doc. If I'm right it's not written.


Cyrillic support issue - BlazorHybridApp

FirstBlazorHybridApp - it is masterpiece for blazor developers <3, but we faced the problem of Cyrillic support
Can you help in that situation?
Cyrillic text: "Привет мир"

Note:  in Hybrid.Android / wwwroot/ index.html, outside < app > tag  cyrrilic text working

It is enough to convert .razor files to UTF-8

Yup that sounds right!


ACDC for a non-sequential list of lumis from MCFakeFile

Fixes #9149
Another patch on top of https://github.com/dmwm/WMCore/pull/9131 and #9148
Don't consider the MCFakeFile lumi list is contiguous, and adapt job creation based on ACDC documents according to the lumis found to be recovered. Which means, we might have a job processing 100 events in a single lumi, and another job processing 100 events in multiple lumis.
In short, new jobs - created from ACDC docs - keep the same amount of events to be processed (LastEvent - FirstEvent), while their lumi list may vary.
Tested with the unit tests and still need to push it upstream (fix #9147)

With this patch in, I see that JobCreator hasn't crashed again on the same workflow.

 Fix #9157 - ACDC for a non-sequential list of lumis from MCFakeFile

I applied this patch to all the agents before to avoid the mess becoming bigger.

Thanks, Kenyi. About the formatting, I'll have those fixed in my PR against master.


Document Plans API

@gerred it is unclear what this issue is...

@kensipe We have it now as of the docathon.


Add ability for dendrite to read AS registration files from blueprint

(I encountered this line today;
https://github.com/matrix-org/complement/blob/0e88861054556a734f40d5754d93499a7ac311c1/tests/federation_room_join_test.go#L531
So here's an issue to keep track of it.)

Please /assign this issue to me and any resource too in case it can help me solve this faster.


Add support for lowercase meridian indicator (%P for am/pm).

@benjaminoakes needed this mapping for a project we're working on. Hope it makes it in!
Thanks,
Jamie (@drlube)

please @benjaminoakes 🙏

Published to npm as v0.5.0.  Please let me know if you have any issues; npm publishing was acting up on me the other day.


Looking for open-vm-tools security update - CVE-2022-31676 for burmilla/os-openvmtools docker image

BurmillaOS Version: v1.9.2
Where are you running BurmillaOS? As Virtual appliance
Do you use some service(s) which are not enabled by default : open-vm-tools
Looking for open-vm-tools security update - CVE-2022-31676 for burmilla/os-openvmtools docker image . when the latest image will be available?
https://hub.docker.com/r/burmilla/os-openvmtools

Do I have permission to create branch and open PR. What is the process to get it in case required.

Fix included on https://github.com/burmilla/os-services/commit/90ba9e37420c3e79fdf4ce5d837d171ffba9ce91 but it will go to next (1.9.6) BurmillaOS version so I need to check what else need to be updated.
We are already behind of couple of Docker versions and looks that there will be new one quite soon after https://github.com/moby/moby/pull/44593 and https://github.com/moby/moby/pull/44597 merged.

Thank you very much Olli Janatuinen. I appreciate your help so much.

Included to just released v1.9.6 release:


Adds unitary testing for routed circuits

Adds utilitiy functions that tests whether two circuits define the same unitary up to permutation of qubits.

@tanujkhattar I've made the changes we discussed without the fallback strategy as a v1. I can follow up with that with another PR once we have a fully functioning basic routing implementation pushed to Cirq.


Install documentation no longer up-to-date

https://hevs-isi.github.io/gdx2d/doc/install/ relates to the old version. We now have many more projects in the src folder (see #125).

The install documentation and images should be updated to explain how to import the demos and the example project.
A corresponding release note should be done (https://hevs-isi.github.io/gdx2d/news/)

@pmudry thanks, I will update the website according to your comments.
I will take some screenshots tomorrow using the new environnement freshly installed ;)

You're amazing !
On Thu, 28 Apr 2016 at 21:48 Christopher<EMAIL_ADDRESS>wrote:

@pmudry https://github.com/pmudry thanks, I will update the website
according to your comments.
I will take some screenshots tomorrow using the new environnement freshly
installed ;)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/hevs-isi/gdx2d/issues/124#issuecomment-215541518

I added the installation guide and the release note on the website, see https://hevs-isi.github.io/gdx2d/news/release-121/ and https://hevs-isi.github.io/gdx2d/doc/install/