I have noticed that SUMO's marouter uses multi-threading (--routing-threads XX) when re-routing or when using marouter to define the vehicle's routes macroscopically. This works when the routes are searched for incrementally (--assignment-method incremental), not however, when running UE or SUE.
Any ideas why not?
I am running SUMO 1.1.0 on Windows.
For anyone else wondering about the same issue. According to the developers, this is a current bug.
See here for updates:
https://github.com/eclipse/sumo/issues/5370
Related
as shown below:
I don't understand why, the syntax and format is correct, it's extremely confusing.
I review my code carefully but can't figure out
this seems to be a bug with VS Code. This could be because VS Code is not updated, or an extension that is not supported anymore.
first, try ctrl + shift + p and running >Developer: Reload Window this should reload your current environment and the error should be fixed.
If that doesn't work, try a different extension. I currently use Vetur, and Prettier.
And don't forget to make sure your VS Code is up to date. go to the bottom left and click the settings cog, then check for update or updates.
My answer is, "Start from scratch, and record your steps." I'm happy to share my notes on what is presently working: https://github.com/TheAutomaTom/VsCodeSettings-Vue3
My personal machine had been in that spot for some weeks, so I took a step back and dump out your cornucopia of extensions and their dependencies.
Only run pertinent language services. This is a tall order given how much a Vue + Typescript + Tailwind on Vite app covers. I am suspicious of generalized HTML/CSS/JS packs though, because they may not be built to parse Vue SFCs. Every new release of a services intended for other frameworks, like Angular or React, are still possible culprits (and moving targets).
I gave up getting Prettier and ESLint on stable ground. For a non-workplace thing, I feel okay about that. You may be having issues with a global package, if you've been experimenting. I've tossed out a couple branches following different tutorials. I intend to revisit this one since it has some example projects: rvest.vs-code-prettier-eslint
I've noticed the Volar team seems to let oddities squeak out a little more frequently than I remember in Vetur.... but we love them just the way they are. Sometimes I downgrade just to check if I've gone crazy, yet.
I would like to take a screenshot of a web site using WebGL. I don't have to use GPU to open that site. Using emulation is enough for me.
At the beginning, I already tried headless-chrome to do this. That can take screenshot of ordinal web sites. But, It not works for WebGL canvases.
I think one of possibility is using OSMesa or something to emulate OpenGL.
I have used all of my strategy for overcoming this. Is this actually possible to do?
If yes, please tell me how to do that. If no, I would like to know why.
Thanks.
Yes it is possible!
You need the right combination of:
headless-chromium binary
libosmesa.os binary (in same directory)
launch chrome headless with the right flags, such as (see link for full details): ['--use-gl=osmesa', '--enable-webgl', '--ignore-gpu-blacklist', '--homedir=/tmp', '--single-process', '--data-path=/tmp/data-path', '--disk-cache-dir=/tmp/cache-dir']
This thread on the serverless-chrome github project discusses the issue and provides some binaries which I have used to capture screenshots of WebGL content on AWS Lambda using Page.captureScreenshot().
https://github.com/adieuadieu/serverless-chrome/issues/108#issuecomment-416494572
(See comment by #apalchys on 28th August)
This particular example uses SwiftShader which seems to be the preferred option going forward.
Note, however, that I was unable to create PDFs using Page.printToPDF() using this version - WebGL content just appears blank/white. However, I was able to also get Page.printToPDF() using an earlier version which uses osmesa, see https://github.com/adieuadieu/serverless-chrome/issues/108#issuecomment-371199530
I'm working on a package that relies on the Config facade.
The code itself works fine, but I'm encountering issues when testing.
Initially, I was using this code:
Config::shouldReceive('foo.bar')
->andReturn(true);
As many others, I bumped into some issues.
I later read that mocking the Config facade isn't encouraged.
To get around it, most people tend to suggest to use the following instead:
Config::set('foo.bar', true);
Which I reckon works fine, if you're testing from Laravel/Lumen.
But my issue is, I'm not. I just rely on a few Illuminate packages, so that won't work since I get:
RuntimeException: A facade root has not been set.
At this point, some might suggest that I should just inject the Config repository dependency, but I'm using the Config facade in a trait which is used by an Eloquent model, so DI won't work.
Is there any other way I can tackle this?
Thanks!
PS: This question has also been posted on Laracasts
I faced to the same issue. Lumen 5.4
using Config::set('key', 'value') was not worked. So I had to use this way.
//test
use Illuminate\Support\Facades\Config;
Config::shouldReceive('get')
->once()
->with('key')
->andReturn('value');
,
//code
use Illuminate\Support\Facades\Config;
Config::get('key'); //instead config('key');
For those running into a similar issue, I've finally found the correct way to address this problem.
Testing Laravel packages is just what the Testbench package is for.
From the documentation:
To use Testbench Component, all you need to do is extend Orchestra\Testbench\TestCase instead of PHPUnit\Framework\TestCase.
This way, setting a configuration value is just a matter of calling Config::set() as you would on a full Laravel install. No more Mockery issues.
We are currently using Ruby 1.9.3, Rails 3.1 (i know, we're working hard to upgrade all our applications).
We're using a module (let's call it 'OurModule' to add a method (let's call it 'OurAddOnMethod' to a model defined in a gem (let'd call that 'GemModel'). We have that module file living in the 'config/initializers' directory.
That file defines the module, and then calls this to include it in the model:
# Include the extension
GemModel.send(:include, OurModule)
When developing, things work well mostly, but periodically we will get an error that basically says "Undefined method 'OurAddOnMethod' in 'GemModel'". Restarting the server resolves the issue (for a while).
I'm assuming this is happening because the models are reloaded periodically with changes made in the development environment, and it appears that the initializers do not also get reloaded at that time..? It seems like this may not be the best way to set things up; it is quite frustrating to deal with.
Can anyone enlighten me on a better way to achieve this?
I ended up using wrapping the code in the following, and keeping it in initializers:
ActionDispatch::Callbacks.to_prepare do
# configure stuff or initialize
end
I feel really bad, i completely missed this question that seems to completely cover mine (linking to the answer that i used):
https://stackoverflow.com/a/8636163/287516
I find myself frequently developing new Julia modules while at the same time using those modules for my work. So I'll have an IPython (Jupyter) notebook, with something like:
using DataFrames
using MyModule
Then I'll do something like:
x = myfunction(7, 3)
But I'll have to modify that function, and unfortunately by that point I can't simply do
using MyModule
again. I'm not really sure why; I thought that calling using simply declares available modules in order to make the global scope aware of them, and then when a name is actually needed, the runtime searches for the definition among the currently loaded modules (starting with Main).
So shouldn't using MyModule simply just refresh the definitions of the items in the already declared module? Why do I have to completely stop and restart the kernel in order to use my updated functions? (Is it because names are bound only once to functions that are declared using the function keyword?)
I've looked at Julia Workflow Tips, but I don't find the whole Tmp, tst.jl system very simple or elegant... at least for a notebook.
Any suggestions?
I think there's a lot of truth in this statement attributed to one of the Juno developers: Jupyter notebook is for working with data. Juno IDE is for working with code.
Jupyter is great for using modules in a notebook style that the output you're getting is reproducible. Juno and the REPL have less overhead that let you keep starting new sessions (faster testing, and fixes the problem you noted), have multiple tabs open to follow code around a complex module, and can use the debugger (in v0.5). They address different development issues for difference stages of use. I think you're pushing against the tide if you're using the wrong tool for the wrong job.