Bug: NormalizeRenderer incorrectly renders - > p

- > p renders - p, where I expect the NormalizeRenderer to render - > p

Yes, there are many stuffs not working in the NormalizeRenderer. There was an opened issue #155 and PR #184  to improve the support, but it has never been finished. No time to fix it or work on it.


Gcs on appscale

DO NOT MERGE

I know this PR is for a Python upgrade but I wanted to point out that on the Java side of things, the upgrade to GAE 1.8.4 appears to add some additional GCS support: https://github.com/AppScale/appscale/pull/1866/files


[Question] Support related for Nim wrapper

I am trying to implement an OpenCascade wrapper for the Nim programming language. So far I managed to do significant progress (given that I develop as a hobby), but I am struggling with the visualization part.
As a first step I am trying to implement a bare minimum example. For that regard, occt-ais-hello is becoming very useful for me. By minimum, I mean just showing a solid even if it does not react to events.
Right now I only get a window, but it displays nothing inside it:

The Nim code I am using is here. It is quite understandable.
I couldn't create a constructor. So I create an object based on AIS_ViewController with the fields myContext and myView. Then I create the function getContextAndView, which I used in this line in order to populate the fields in aViewer instance.
I am on OCCT 8.5, by the way, under ArchLinux.
Nim creates C++ code. In this case, the C++ file created is this one.
I know it is difficult, but can you spot any significant miss that prevents the box from being shown?

  #var anXDisplayPtr:Display = getDisplay( `*`(aDispConn) )
  while true:
    discard

main()

Your code doesn't implement any X11 event loop.
Try combining some X11 sample for nim (like [this] (https://github.com/nim-lang/x11/blob/master/examples/x11ex.nim)) with event loop from viewer sample (redirecting XNextEvent to Xw_Window::ProcessMessage)

Understood and thanks a lot for taking your time. Is there any equivalent for ProcessMessage for OpenCascade v8.5?

for OpenCascade v8.5?
Such version doesn't yet exist - the latest release is OCCT 7.7.
Without Xw_Window::ProcessMessage() you'll have to implement a plenty of routines for handling mouse / keyboard events on your own.

I don't recall a dedicated X11 sample for this - OCCT comes with samples using Qt and other GUI frameworks. A low-level X11 event handling could be found in ViewerTest implementation though in legacy OCCT versions.

Ooops, sorry I meant v7.5. In any case I updated the system (now on v7.6). I was reluctant to do so because the wrapping process is not automatic. I will have to fix some functions, but at least now I have ProcessMessage.

Hello again. I managed to wrap aspect and xw for v7.6. I had lot of difficulties to wrap ProcessMessage, but now it is compiling.
I am getting the following error message:
21
(myContext: (), myView: ())
()
17
(myContext: (), myView: ())
()
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  4 (X_DestroyWindow)
  Resource id in failed request:  0x1600002
  Serial number of failed request:  90
  Current serial number in output stream:  90
Error: execution of an external program failed: '/home/jose/src/nimlang/occt.nim/examples/viewer04 '

Any idea of where I should look at?
The Nim code is compiling. I echo the event type, aViewer and aWindow. So it looks I run the loop twice.
The generated C++ code is here.

Don't know what is actually wrong, but I see two potential issues with Nim code:

XSelectInput is not called from original C++ sample. It is required to activate mouse/keyboard/resize window events to be actually received by X11 event loop.
Methods OcctAisHello::ProcessExpose(), ::ProcessConfigure() and ::ProcessInput() in C++ sample override implementation of a base class AIS_ViewController, and this is really important for sample to work as expected. I have some doubts that OcctAisHello type definition and it's methods declaration like processExpose() in Nim language actually defines a true C++ subclass with corresponding overridden methods (and not duplicates or redeclarations).

I finally got it. I had to wait for an update in Nim supporting virtual and override:

THANKS A LOT FOR YOUR PATIENCE.


Socket grpc

Added GRPC variant to allow remote system access to broker-adapter.

This is a Python implementation that shows how to connect to the socket.
There is also a small integration test that connects to the socket once.

Hi. I found some more information on it. Seems indeed to be a eclipse thing.
From the documentation of os-maven-plugin:
Issues with Eclipse m2e or other IDEs
If you are using IntelliJ IDEA, you should not have any problem.
If you are using Eclipse, you need to install an additional Eclipse plugin because m2e does not evaluate the extension specified in a pom.xml.Download os-maven-plugin-1.5.0.Final.jarand put it into the <ECLIPSE_HOME>/pluginsdirectory.

https://github.com/trustin/os-maven-plugin/blob/master/README.md
On 3 Mar 2018 5:43 PM, John Collins<EMAIL_ADDRESS>wrote:@jecollins commented on this pull request.
In pom.xml:

                           <transformer

                                   implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">

                               <mainClass>org.powertac.samplebroker.core.BrokerMain</mainClass>

                           </transformer>

                       </transformers>

                   </configuration>

               </execution>

           </executions>

       </plugin>

       <!--GRPC generate files-->

       <plugin>

           <groupId>org.xolstice.maven.plugins</groupId>

           <artifactId>protobuf-maven-plugin</artifactId>

           <version>0.5.0</version>

           <configuration>

               <protocArtifact>com.google.protobuf:protoc:3.5.1-1:exe:${os.detected.classifier}</protocArtifact>

I'm running on Linux, Ubuntu 16.04 LTS. It's possible that Eclipse is the problem here, because it seems to build OK if I just do mvn clean test in a term window.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

So is the missing powertac.broker package the only remaining problem? Did you perhaps neglect to commit something?

Yes I originally called it like that because it seemed to make sense to call it as such but then I saw that all packages are in samplebroker even if it’s not really a “sample” but rather the core of most brokers developed by the teams. So I moved everything and I think the import has just not been cleaned up.

But I think there’s several imports that are messed up like that. Let me look into it tomorrow I can ssh home and get an IDE going right now I’m only on an iPad

Alright. It was all working, but the grpc proto file was set to generate the classes to a broker.adapter.grpc package instead of the samplebroker.grpc package. I changed that in the last commit.

I still have three unresolved imports in grpc.ControlEventHandler.java: org.powertac.samplebroker.grpc.Booly, org.powertac.samplebroker.grpc.ServerMessagesStreamGrpc, org.powertac.samplebroker.grpc.XmlMessage. Why these are imported is a mystery, because they are in the same package and are not referenced in the code. But there's still an unresolved type ControlEvent. So it still fails to build.

Alright, I cleaned those imports up (I added them via vi in ssh so I had no IDE support telling me which imports are unused) and added the import you mentioned. What really irritates me is the fact that it built all these times on my machine and I am starting to wonder where the differences lie in the way we build things. If there is a ressource that shows how exactly the environment looks like and how the artifacts are build that would be useful for me to avoid such errors in the future.
As a note. I build with the CLI doing a simple mvn clean package using:

maven 3.5.0
OpenJDK 1.8.0_151

The repo is in the exact state as the PR suggests except the broker.properties file which has different credentials. It’s really beyond me how mine succeeds but yours fails.
I ran this again in a clean container running the latest Ubuntu LTS.
[INFO] Building jar: /broker-adapter/target/broker-adapter-javadoc.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:54 min
[INFO] Finished at: 2018-03-07T11:07:18+00:00
[INFO] Final Memory: 32M/394M
[INFO] ------------------------------------------------------------------------
root@4a1295b03483:/broker-adapter# history
    1  sudo apt update
    2  apt update
    3  apt install default-jdk maven
    4  git
    5  apt install -y git
    6  git clone https://github.com/pascalwhoop/broker-adapter
    7  cd broker-adapter/
    8  ls
    9  mvn clean package
   10  history

That's very strange, because it builds here with maven as well. Disturbing.
In the longer run, I would like to do a bit of refactoring to undo the changes to broker-core, although I haven't yet thought it through. I don't like having to change broker-core to accommodate these kinds of changes. For example, a broker developer should be able to add command-line options or change message-handling without changing broker-core.

OK, but the commit still leaves two imports unresolved: org.powertac.samplebroker.grpc.Booly, and org.powertac.samplebroker.grpc.ControlEvent. It builds, but complains about unchecked or unsafe operations.

It seems these issues are being caused by generated code that's not seen by Eclipse. The imported classes are indeed present in target/generated-sources.

Updated pom.xml according to this issue and imports are now resolved in eclipse.

Original R broker fails because broker.properties specifies "xmlForwardType=SocketAdapter". I guess we should specify this in the command-line if we want to keep these two versions working in parallel.


all_tenants attribute in Beat Schedule

Hello,
This might be a very stupid question, but what does the all_tenants attribute do when creating a beat schedule?
For example, I want to create a task that runs at 5am everyday for each tenant, but I would like the tenant to be able to change the time as they please. Would I set all_tenants to true or false?
app.conf.beat_schedule = generate_beat_schedule(
    {
        "celery.backend_cleanup": {
            "task": "celery.backend_cleanup",
            "schedule": crontab("0", "4", "*"),
            "options": {"expire_seconds": 12 * 3600},
            "tenancy_options": {
                "public": False,
                "all_tenants": True,
                "use_tenant_timezone": True,
            }
        },
    }
)

Setting all_tenants to true will result in a periodic task being created for all tenants in their respective schemas. The configuration options will all be the same, so you can't change the time individually (apart from via the time zone setting). The generate_beat_schedule function is just a helper to save you having to duplicate a lot of the beat schedule dict. You can still manually add entries if you need more control. Check out the source for that function here.
You can also create and manage periodic tasks in the Django admin, which sounds like what you're after in this case. That allows admin users in each tenant to configure the scheduling as normal. See here. The app.conf.beat_schedule is a static definition of tasks that you know you want in advance, so it doesn't sound appropriate for your situation.


Support SQLite DROP TRIGGER

When using SQLite database the delete button in Trigger view is disabled (I guess not implemented); Pls add DROP TRIGGER funtionality.

Thanks for the report @rfbrooks


About configuring VSCode to interpret php

About configuring VSCode to interpret php
Hello my friend
Can you help me how to configure VSCode to interpret php
I need to point docker php to VSCode
It is possible ? Can you help me

I think it is possible and some people have done it and there is a script somewhere but it would be really cool if someone can come up with a step by step guide and how to get this done with Devilbox.

If you are talking about setting up XDebug with devilbox and VSCode: here you go

@mrbig00 Is this the same as setting up XDebug? I don't think so.
If we simply want VSCode to be able to access PHP inside the Devilbox container, what do we need to do? So regardless of project, just have VSCode "connect" to PHP inside the Devilbox container. How is that done please?

@mozgbrasil Did you find a solution? Do you use XDebug or just have PHP be "available" inside VSCode regardless of project?

Good Morning
I installed php on the operating system
And due to the operating system apache2 conflict with devilbox I'm using the practice of stopping apache
sudo service apache2 stop

@mozgbrasil
I am using Devilbox and Docker to keep my OS free of Apache, NGINX, PHP, etc.
Of course I could have installed it on the OS and simply connect VSCode to it.
@cytopia I am trying to "connect" PHP from inside the Devilbox container to VSCode on the OS.
What parts in the https://devilbox.readthedocs.io/en/latest/index.html might be able to point me in the right direction?
https://devilbox.readthedocs.io/en/latest/intermediate/configure-php-xdebug/linux/vscode.html#configure-php-xdebug-lin-vscode is for XDebug. But what if I just want to "connect" VSCode to PHP in the Devilbox container and not use XDebug?

if I just want to "connect" VSCode to PHP in the Devilbox container and not use XDebug?

What is the reason or what is this useful for, If I might ask.

Not sure if related but for me running tools like phpcs (php code fixer), I have currently them pointed at the OS php install which is not really correct. It should be linked to the container in case you are using a different php version than your OS

@cytopia What @Cipa wrote is one of the reasons exactly for example. Another reason would be to be able to use https://github.com/Automattic/VIP-Coding-Standards or https://github.com/squizlabs/PHP_CodeSniffer. In fact being able to do that would be truly awesome. On purpose I am keeping the host OS slim, fast and clean. Being able to use these tools inside VSCode through Devilbox, oh my, that would be really nice.

@mozgbrasil @robots4life @Cipa as this is very VSCode specific and I've never used it, I am unfortunately out of any help to you guys. I would suggest to get support directly at the relevant VSCode places:

https://stackoverflow.com/questions/tagged/vscode
https://github.com/Microsoft/vscode/issues
https://www.reddit.com/r/vscode/

@cytopia Ok, thank you.
Can you explain, if I wanted to make PHP available outside the Devilbox container, other than through the browser, would I need to open a port or do something similar like change the .env file? Not sure if this applies but what if I wanted to check i.e. the version of PHP inside the Devilbox container but from the host OS in a console. How could I pass such a command to inside the Devilbox container?
Where in the docs can I read up on the concept of making PHP available outside the Devilbox container? I guess this is more Docker specific, but if you have a topic in the docs that you think might be able to help even remotely, please let me know.
Thank you.

If you are in the Devilbox directory, you can use it as such:
docker-compose exec -T --user devilbox php php -v

Hi @robots4life, I am using the new VS Code Remote Development to accomplish this. Make sure you have one of the following extensions installed ms-vscode-remote.vscode-remote-extensionpack (package containing remote development for SSH, Containers and WSL) or ms-vscode-remote.remote-containers (for remote development in containers).
After installing these extensions all you need is a devcontainer.json file in a .devcontainer folder inside of your workspace. <project>/.devcontainer/devcontainer.json.
In case of Devilbox the file should look like the following:
// See https://aka.ms/vscode-remote/devcontainer.json for format details.
{
	// See https://aka.ms/vscode-remote/devcontainer.json for format details.
	"name": "Existing Docker Compose (Extend)",

	// Update the 'dockerComposeFile' list if you have more compose files or use different names.
	// The .devcontainer/docker-compose.yml file contains any overrides you need/want to make.
	"dockerComposeFile": [
		"../../../../docker-compose.yml" // Point to Devilbox's docker-compose.yml
	],

	// The 'service' property is the name of the service for the container that VS Code should
	// use. Update this value and .devcontainer/docker-compose.yml to the real service name.
	"service": "php", // Name of the service we want to remote to

	// The optional 'workspaceFolder' property is the path VS Code should open by default when
	// connected. This is typically a file mount in .devcontainer/docker-compose.yml
	"workspaceFolder": "/shared/httpd/<project-name>", // For example: /shared/httpd/my-website

	// Uncomment the next line if you want to keep your containers running after VS Code shuts down.
	// "shutdownAction": "none",

	// Uncomment the next line if you want to add in default container specific settings.json values
	// "settings":  { "workbench.colorTheme": "Quiet Light" },

	// Uncomment the next line to run commands after the container is created - for example installing git.
	// "postCreateCommand": "apt-get update && apt-get install -y git",

	// Add the IDs of any extensions you want installed in the array below.
	"extensions": [
            "eamodio.gitlens",
            "felixfbecker.php-debug",
            "felixfbecker.php-intellisense",
            "fterrag.vscode-php-cs-fixer",
            "atlassian.atlascode"
    ],
}

When the extensions are installed AND the devcontainer.json file is present in the appropriate folder VS Code will notify you about that it detected the file (upon reopening the workspace) and that you're able to reopen the project inside of the container.

After reopening the project inside of the container you're also able to fire commands inside of the container straight away. For example composer install etc.

@boumanb thanks for the detailed post. One more thing to sort is how to actually make the terminal start up as the devilbox user instead of root. The devilbox user has the same uid/gid as your local user and I suppose you rather want it to issue any commands to keep permissions between inside the Docker container and your host syncronized.

No problem. Glad I can contribute in some way, truly a great project. Glad to see you active again.
You're totally right. It's better to keep these permissions synchronized. However, I've not been able to find a solution for this. VS Code has some documentation on using a different user while developing remotely: https://code.visualstudio.com/docs/remote/containers-advanced#_adding-a-nonroot-user-to-your-dev-container
Apparently when using the approach described above, we have to define the user in the docker-compose.yml (docker-compose.override.yml in our case) like user: "devilbox" although this causes the php service to crash.
php_1      | [INFO] Changing group 'devilbox' gid to: 1000
php_1      | groupmod: Permission denied.
php_1      | groupmod: cannot lock /etc/group; try again later.

// Uncomment the next line to run commands after the container is created - for example installing git.
// "postCreateCommand": "apt-get update && apt-get install -y git",

Is this probably something where you could do: su - devilbox as a post command?

Normally, yes. But in my case Devilbox is running 24/7 in the background. The // "postCreateCommand": "apt-get update && apt-get install -y git", will only be executed when creating a new remote environment from image, Dockerfile or docker-compose for example. What I tell my VS Code with the configured devcontainer.json is to make use of the pre-existing environment.

@boumanb Thank you! I will give all this a try and report back either way.

Great, looking forward to your response!

@boumanb

Make sure you have one of the following extensions installed ms-vscode-remote.vscode-remote-extensionpack (package containing remote development for SSH, Containers and WSL) or ms-vscode-remote.remote-containers (for remote development in containers).

My workflow is such that I run node, npm, grunt, sass, etc. locally on the host in the project folder and like to do things like php coding standards or php code sniffer in the container.
First, would you see an advantage in running everything in the container, while having HOST_PATH_HTTPD_DATADIR pointing to a local folder with all my projects? Meaning in those local folders just have the files for the project and have tools etc. in the containers.
At the moment I am fine with having the tools mixed into the project folders. This  means I need to have node and npm on the host what sometimes leads to minor issues when updates or different versions are required.
I tried both ways and found that having things local is a bit faster. Would you see another advantage of running all the tools in the containers?
Then I am not sure what package to pick from the two you mention. Like I said I do all the development locally and would only need to run the php tools in the container. What package is better suited for that?

@boumanb Given I might not have grasped the concept of containers and working inside them you can disregard my previous message/question.
I guess I am close but it does not work. Here is what I have done.
First I installed this extension pack for VS Code.
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack
All my projects are on the hard drive in this folder /media/user/d/WWW/.
Inside that folder I also have /devilbox/. On the konsole (kubuntu) I can simply run docker-compose up -d and the devilbox will start. So far to good.
The .env file in the /devilbox/ folder contains this line.
HOST_PATH_HTTPD_DATADIR=/media/user/d/WWW/
This enables me to have access to all the projects I have in that folder when I open the devilbox shell for example. With this I can also create any new folder and have a project up and running fast. I add the entry for the project to the hosts file and it works.
So my VS Code workspace is the folder /media/user/d/WWW/ and inside that are multiple projects, all of which can use devilbox.
Now inside /media/user/d/WWW/, my workspace, I made a folder .devcontainer and inside that created the file devcontainer.json. That file has the following content.
{
  "name": "Existing Docker Compose (Extend)",

  "dockerComposeFile": ["/media/user/d/WWW/devilbox/docker-compose.yml"],

  "service": "php",

  "workspaceFolder": "/shared/httpd/",

  "shutdownAction": "none"
}

Now when I open VS Code and open the workspace being at /media/user/d/WWW/ I am greeted with the following messages.

Now when I click on Reopen in Container this happens.

So if you have any idea to what I can do different please let me know.
I am reading these docs https://code.visualstudio.com/docs/remote/remote-overview and hopefully I can find something there. Thank you @boumanb

Hi,
Sorry for not responding to your previous message. I'll get back to you this weekend!

No worries please. Do take your time. This is not time critical at all. Easy going here.. and thx.

Hi,
I can reproduce this exact same error message by not having devilbox up and running on reopening in container.
Could you verify that you have devilbox up and running upon reopening in container through VS Code?

First  removed the vscode-remote-extensionpack and closed VS Code.
Then I removed the .devcontainer folder and its content the devcontainer.json file.
Then I stopped Devilbox. Then I cleaned/removed Devilbox.
Then I made a new .devcontainer folder with devcontainer.json file in it with the exact content of above post.
Then I opened VS Code again and installed this again.
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack
Then I started the Devilbox. Then I started VS Code.
Then, while VS Code was starting up I could see a notification saying this.

I quickly clicked details and was presented with this log.
devcontainer.log
Then the terminal opens with Devilbox! Yes!

So in fact all I did was remove and add the pack, folder, file and then stop and start Devilbox. That did the trick. Thank you @boumanb
Now what about using the container sensibly? Do I understand this correct?
When I issue commands in that terminal, like npm init inside a project all that work will be done inside the container, right? So this is not touching the host OS any more, right? Well, assuming the default setting in the .env file has not been changed. Well in my case it is because I set HOST_PATH_HTTPD_DATADIR in the .env file to /media/user/d/WWW/. So the changes I make in the terminal that is connected to the Dev Container will be reflected on my local host. But the tools to run these packages/whatever will reside in the container. So this means I can have the local host clean and do the work in the container while also having the project files on the local host. That is quite neat in fact if I understand all that right.
Then what about this?

Now that I have the Dev Container connected, what should I put in the VS Code settings, meaning how can I tell VS Code where to find the PHP executable path now?
Then you mention some extension.
	"extensions": [
            "eamodio.gitlens",
            "felixfbecker.php-debug",
            "felixfbecker.php-intellisense",
            "fterrag.vscode-php-cs-fixer",
            "atlassian.atlascode"
    ],

These will be installed in VS Code I assume, right?
So this means I could also just install them normally, without running the Dev Container, but only once I have told VS Code where the PHP executable path is, no?
So once VS Code has that setting right I can in fact use vscode-php-cs-fixer or php-intellisense or do something like this https://tommcfarlin.com/php-codesniffer-in-visual-studio-code/ to then be able to use https://github.com/Automattic/VIP-Coding-Standards for example. Or would I need to add all this to the devcontainer.json file in the extensions key?
Last not least, what about the Devilbox user that you speak about above?
I don't run Devilbox 24/7, stop and start it as I do work. So I might be able to issue the postCreateCommand being su - devilbox in the devcontainer.json file or, like you say, add user: "devilbox" to the docker-compose.override.yml file, right?
I guess I am close to making a much much better use of Devilbox, with you kind help. Thank you!

Great to see you got it working! 😄 I do recommend to make a .devcontainer folder with devcontainer.json inside each of your projects instead of inside /media/user/d/WWW/ sometimes you may need to differ in the devcontainer.json settings for specific projects. I like to make a clear seperation there. Like so:
/media/user/d/WWW/project1/.devcontainer/devcontainer.json
/media/user/d/WWW/project2/.devcontainer/devcontainer.json
But using your whole /media/user/d/WWW/ as can come in handy too sometimes I guess. Maybe it's just a matter of taste haha.
So this means I can have the local host clean and do the work in the container while also having the project files on the local host. That is quite neat in fact if I understand all that right.
Spot on. That is exactly what it means. No dependencies on your host OS (node or PHP etc.). 😃
About interpreting
Did you get that notification when reopening in the container? For me it resolves the executablePath out of the box I guess, I may be wrong.. Will look into it monday.
About extensions
These will be installed in VS Code I assume, right?
So this means I could also just install them normally, without running the Dev Container, but only once I have told VS Code where the PHP executable path is, no?
The extensions that have dependencies like PHP will get install on the remote side. Which is the container in our case. Extensions that do not require any special dependencies live on the local side. See following image. Thereby you don't have to mention the PHP executable path, as stated before it should resolve itself because it's in the default PHP installation directory inside of devilbox

Or would I need to add all this to the devcontainer.json file in the extensions key?
Only the ones that you want to have installed automatticaly once you open the workspace in the container. You should play with it, you'll notice that you're also able to install extensions afterwards by simply going to the extensions menu and you'll notice texts like: Install local and Install remotely etc. Read more about it here
About the user
Yes, you might be able to do so. I settled with using root although I know it's bad. Haven't made a proof-of-concept yet where it is working as supposed. Sad. 😢
Please let me know if you find a way to login as devilbox.
I guess I am close to making a much much better use of Devilbox, with you kind help. Thank you!
That is exactly how I felt when I started experimenting with this a couple of months ago. At our organization we're all very happy (I suppose) with this new way-of-working, we're able to do everything from withing our IDE now. The developers using PHPStorm have also found a way to do so.

I do recommend to make a .devcontainer folder with devcontainer.json inside each of your projects. I like to make a clear separation there.

Ok yeah. I see what you mean. Also I think be default I am "abusing" the workspace setting of VS Code. I think also the workspace is just per 1 project. But yeah. When requirements change I can adjust this.

Did you get that notification when reopening in the container?

No, not any more. So that is good, very good in fact. Sorted.

The extensions that have dependencies like PHP will get install on the remote side. Which is the container in our case. Extensions that do not require any special dependencies live on the local side. See here https://code.visualstudio.com/docs/remote/containers#_managing-extensions

Perfect and thank you for the link and image. Fully understand now.

Please let me know if you find a way to login as devilbox.

Well, I tried with the postCreateCommand but that is not being issued when I open the terminal for some reason. What does work though is simply executing this command once you are in the shell. So just su - devilbox being inside the project that you like. That will change you to devilbox as user. So that could be a way, albeit not automatically. So if you have other postCreateCommands that run automatically they will most likely run as root.
I also tried with docker-compose-override.yml but quickly saw that I need to replicate most of the docker-compose.yml settings in it and would not know where to add the user:devilbox line in it. That is still something to look into.
Bottom line. Great. Now we can use Devilbox with VS Code in a Dev Container and benefit from all the tools/services running in the containers while keeping the host OS clean. Have a good start to the week and thank you indeed for your contribution @boumanb and of course @cytopia for the Devilbox.

@boumanb When I am in the Dev Container and install the extensions into the container the next time I start up Devilbox the extensions are gone. Do you know why this happens?
So I am in the Dev Container and in the extensions selection I install these two for example.

As you can see I install them from inside the "local - installed" panel. There are none in the "Dev Container" panel.
Once I have installed the extensions and they run in the Dev Container and I finished the work for the day I shut down the Devilbox.
For that I use docker-compose stop and then docker-compose rm -f.
Is it perhaps possible that the extensions are removed because I run docker-compose rm -f at the end?
In your example devcontainer.json above you mention.

Add the IDs of any extensions you want installed in the array below.

"extensions": [
    "eamodio.gitlens",
    "felixfbecker.php-debug",
    "felixfbecker.php-intellisense",
    "fterrag.vscode-php-cs-fixer",
    "atlassian.atlascode"
],

Does this list need to be in the devcontainer.json at all times and do the extensions need to be re-installed every time the Dev Container is started or does it have to do with the docker-compose rm -f command?

When I am in the Dev Container and install the extensions into the container the next time I start up Devilbox the extensions are gone. Do you know why this happens?
As shown in the diagram in my last reaction VS Code sets up a server on the remote OS and installs the extensions on the remote OS (the extensions that need an interpreter). When you shutdown Devilbox you'll also remove the installed VS Code server along with the extensions. Next time you'll bring up Devilbox and open a project leveraging the devcontainer VS Code needs to reinstall the VS Code server along with the extensions.
For that I use docker-compose stop and then docker-compose rm -f.
I think docker-compose down combines those two (stop and remove containers + networks).
Is it perhaps possible that the extensions are removed because I run docker-compose rm -f at the end?
Sure. The VS Code remote server along with the extensions gets removed by this I guess.
Does this list need to be in the devcontainer.json at all times
No it does not actually. I ended up putting them in the VS Code settings.json (global settings) like so:
"remote.containers.defaultExtensions": [
    "eamodio.gitlens",
    "felixfbecker.php-debug",
    "felixfbecker.php-intellisense",
    "fterrag.vscode-php-cs-fixer",
    "atlassian.atlascode"
],

and do the extensions need to be re-installed every time the Dev Container is started or does it have to do with the docker-compose rm -f command?
I think we've covered this already. So yes, I guess everytime we remove the containers VS Code remote along with the extensions gets removed. Using only docker-compose stop and docker-compose start may result in different behavior but I haven't tried.

@boumanb All good. So far I now have this in the VS Code workspace settings.
"remote.containers.defaultExtensions": [
      "formulahendry.auto-rename-tag",
      "streetsidesoftware.code-spell-checker",
      "oderwat.indent-rainbow",
      "sirtori.indenticator",
      "bmewburn.vscode-intelephense-client",
      "esbenp.prettier-vscode"
    ],

When I simply stop and start Devilbox without removing the containers the extensions are there. It all starts up super fast. Now exploring what useful extension I can use for PHP and JS development. Quite happy it all works out with Devilbox being able to use the VS Code terminal and have the host clean and fast. Thank you.

@cytopia @robots4life
About changing the user. While reading the documentation of VS Code today I ran into the solution regarding specifying the user you want to use inside of the container. It's so simple, probably read over it a thousand times. All you have to do is put the following into the devcontainer.json: "remoteUser": "devilbox",. Then restart VS Code and when starting a terminal inside of VS Code it should be logged in as the user devilbox.

@boumanb wow, great news, just saw this. Changed the file and it works! Thank you. :heart:
To confirm, we are advised to set the remote user to "devilbox", right? :question:
Because the rest of the Devilbox runs with that user, so that we can use all the tools, right?
I was doing some automated WP setup script and ran it under root. WP CLI was giving me a warning that I can then control all files on the server and that is dangerous. :scream:
So this "user" that we set, it has in fact nothing got to do with app accounts, but the underlying file system, right? So what implications has that on the app we are working on? What are solid patterns for the "user" at this level working with Devilbox?
I mainly do PHP work with Devilbox, sometimes also Node stuff. So far I did not have to change the user or rights when uploading to the host, perhaps they change file permissions automatically. So yeah, what is that "devilbox" user about?

To confirm, we are advised to set the remote user to "devilbox", right?

Correct. The general advise (good practice) on unix-like systems is to do your work as a non-root user. We elevate to root privileges when needed by prepending sudo to our commands. For example:
$ reboot
warning: must be root!
$ sudo reboot

I was doing some automated WP setup script and ran it under root. WP CLI was giving me a warning that I can then control all files on the server and that is dangerous.

Yes, running that script as root means that it runs under root privileges, which is dangerous (not always). One could add malicious commands such as sudo rm -rf /* --no-preserve-root which deletes all your files.

So this "user" that we set, it has in fact nothing got to do with app accounts, but the underlying file system, right?

The interacting with the system. Not solely filesystem.

So what implications has that on the app we are working on? What are solid patterns for the "user" at this level working with Devilbox?

Use devilbox and elevate using sudo when needed.

@boumanb Thank you for your explanation.

Use devilbox and elevate using sudo when needed.

The user on the local machine is devilbox. I understand that.
So when I do the work locally in the remote container with Devilbox under that user all is fine.
Now here comes. When I then upload the files to the live server, i.e. on a shared hosting where the hosting company already makes users and sets their permissions, will those files hold any reference in their file attributes or somewhere else in the file that says that these files have been created or edited with the devilbox user OR will the files be, well, just files and the hosting company has to take care of the user and the user permissions for that file?
I am asking, since when I work locally, I could also work as root since I am the only one working on this machine. No, I am not doing that of course, but this would help me understand better.
Meaning when working as root locally, i.e. with the WP CLI script I could theoretically disregard that message. This, because when those PHP, HTML, CSS, JS etc. files are uploaded to the live server, there the hosting company has to make the users and the user permissions, right?
The actual uploaded files will not hold a reference to the local root user and therefore be dangerous on the live server. The files are just files and depending on what system they reside on and what user and user permissions are set on that system those files will be dangerous or not. Is this correct? I mean it would be nut if user and user permissions could be passed with a simple file.
https://wordpress.org/support/article/changing-file-permissions/
https://stackoverflow.com/questions/18352682/correct-file-permissions-for-wordpress
For example when I FTP into a shared hosting with WordPress on it, it looks like this by default.

Long story short, the user and user permissions are not passed with the files from the system they came from but are always set on the system where the files currently are. Correct?

In general When you FTP files to a different machine, the owner will be set as your user account on that server.
If you want to confirm that, you can either see if there is a right click -> permissions option in your ftp client, or contact your hosting provider.

@science695 Perfect, thank you.

The developers using PHPStorm have also found a way to do so.

@boumanb Any chance you get those developers to share a few bullet points about their setup? I dont see any information on google about this.

@weitzman Ha. Just yesterday I looked into PHPStorm because I am going through the Symfony tutorials and using PHPStorm with that seems to be a real pleasure doing a lot of things automatically.
Having a quick look around I found https://blog.jetbrains.com/phpstorm/2018/08/quickstart-with-docker-in-phpstorm/ and https://medium.com/docker-captain/dockerized-php-development-with-phpstorm-f5d69fec133. Would that help any of us in case we have PHPStorm? I am asking since I am contemplating to get PHPStorm. :thinking:
@boumanb Haw are you doing? Hope fine! Things here are busy, learning Hapi.js and Symfony. So yeah, if you happen to have a link to a tut that does indeed make PHPStorm work with Devilbox, you know what to do. Happy greetings to ya. :smile:

@weitzman I showed this thread to my colleague and he is willing to share information about setting up PHPStorm to work with Devilbox. He told me he was going to try to respond tomorrow.
@robots4life I'm doing fine! How about you? Good to see you're learning new things. Regarding the tut, the colleague I was talking about told me he was planning on writing a blog post about it. Anyhow, knowing him, the information he'll supply you with in this thread is probably sufficient to get you up and running.
@cytopia I guess quite some people would like to see something about this in the documentation. I'll probably make a PR to add some documentation to intermediate/work-inside-the-php-container regarding configuring VS Code and PHPStorm to enable developers to work inside of the container from their IDE.

Hi, I'm The Colleague that @boumanb mentioned.
These are the steps to get Devilbox integration in PHPStorm. I use Linux, but I think these settings should also work on Windows.
Basic stuff
First, go to your .env file (located in your devilbox directory) and add the following to the bottom:
PHP_IDE_CONFIG=serverName=devilbox
Save and restart devilbox.
Next, open your project in PHPStorm and go to Languages & Frameworks > PHP in the settings. Click on the "..." next to "CLI Interpreter". In the popup window, click the plus sign in the upper left corner and choose "From Docker, Vagrant [..]".
In the next popup window, choose "Docker" at the radio buttons section at the top and click on the "New.." button. Give this server a name and choose "Unix socket". If everything went well you should see a "Connection successful" message at the bottom. Now click on OK to close the second popup window.
In the first popup window (named "Configure Remote PHP Interpreter") choose the "devilbox/php-fpm:[..]" image. In the "PHP interpreter path" field, enter "php". Now close this popup window with the OK button.
If you click on the reload icon next to the "PHP executable" field, you should get a message below it which states your PHP version. Now give this interpreter a name at the top en optionally uncheck the box next to "Visible only for this project" to make this interpreter available to other projects on your computer. Click OK to close the window.
Now click on the folder icon next to "Docker container". In the popup window that appears, set "Network mode" to "devilbox_app_net" and uncheck the "Disable network" and "Publish all ports" boxes if they're checked. Now in the "Volume bindings" section you should have an entry. Click that entry and then click on the pencil on the right to edit the entry.
In the popup window that appears, set the "Container path" to the path where your project is located in Devilbox (for example: "/shared/data/my_project") and set the "Host path" to the location of your project in Windows/Linux (for example: C:\devilbox\data\www\my_project). Uncheck the "Read only" box if it's checked and click the OK button to close the popup window and do the same for the "Edit Docker Container Settings" window.
Now go to Languages & Frameworks > PHP > Servers and click on the plus sign in the top left. For the name enter "devilbox" (this is not something you can choose, it has to be "devilbox"). Uncheck the box next to "Shared" because these settings will be different for every project. The "host" is the url to your project without the "www" and "https", so for example "my_project.local". The port should be "80" and the Debugger "XDebug". Next, check the box with the label "Use path mappings". In the section below that checkbox, you will see a collapsable part called "Project files". Click on the path in the "Absolute path on the server" column and enter the path to your project as it is in Devilbox, so for example "/shared/httpd/my_project". Now click the Apply button.
PHPUnit
Go to the Languages & Frameworks > PHP > Test Frameworks setting. Click on the plus sign to add a new framework. Choose "PHPUnit by remote interpreter".
In the new popup window choose the interpreter we created earlier and click OK to close the popup window. Now make sure that the "Path mappings" field is correct. For the "Docker container" field enter the following:
--net="devilbox_app_net" -v <Windows path to your project>:<Devilbox path to your project>
For example: --net="devilbox_app_net" -v C:\devilbox\data\www\my_project:/shared/httpd/my_project.
Click the "Path to phpunit.phar" radio button and enter the path to phpunit in Devilbox. You can find this path by starting an SSH session to Devilbox and entering the command which phpunit. Leave the "Path to script", "Default configuration file" and "Default bootstrap file" empty unless you need it. If you need a bootstrap file like me, be aware that you need to enter the Devilbox container path, not the Windows path.
Click on the refresh button and you should now see the message "PHPUnit version: " below the "Path to phpunit.phar" field. To test it, create a new unit test and try it out by right-clicking the file and choosing "Run  (PHPUnit)".
Xdebug
Go to the Languages & Frameworks > PHP > Debug setting and to the Xdebug section. Check all the checkboxes in this section and set the "debug port" to 9000 (no not over 9000, just 9000). Save with the Apply button at the bottom. Note: There is a link to validate your Xdebug settings at the top, but this isn't working for me. Xdebug works fine in PHPStorm though. You can test it by placing a breakpoint in your code by clicking in the gutter, next to the line number. A red dot should appear and it should halt on that line when you open the page in your browser.
PHPCS
Go to the Languages & Frameworks > PHP > Quality Tools setting, expand the PHP_CodeSniffer section and choose your interpreter in the "Configuration" dropdown. Now click the "..." button next to it.
In the popup window that appears, set the "PHP_CodeSniffer path" to phpcs and click the "Validate" button. A message should appear at the bottom of the popup window indicating that it found PHPCS. Click OK to close the popup window.
PHP Mess detector
Go to the Languages & Frameworks > PHP > Quality Tools setting, expand the Mess Detector section and choose your interpreter in the "Configuration" dropdown. Now click the "..." button next to it.
In the popup window that appears, set the "PHP Mess Detector path" to phpmd and click the "Validate" button. A message should appear at the bottom of the popup window indicating that it found PHPMD. Click OK to close the popup window.
PHP CS Fixer
Go to the Languages & Frameworks > PHP > Quality Tools setting, expand the PHP CS Fixer section and choose your interpreter in the "Configuration" dropdown. Now click the "..." button next to it.
In the popup window that appears, set the "PHP CS Fixer path" to php-cs-fixer and click the "Validate" button. A message should appear at the bottom of the popup window indicating that it found PHP CS Fixer. Click OK to close the popup window.

Thanks everyone for gathering this info together.

Thanks for the detailed post @insyht.
I'm specifically interested in using PHPStorm + VS Code Server. Is that what you are using? I'm using terminology per this diagram

I don't know if that's possible. What functionality of VS Code Server do you want to use in PHPStorm?

@insyht Man, excellent post up there about PHPStorm, thank you heaps! :+1: :zap: :rocket:

Hi @robots4life, I am using the new VS Code Remote Development to accomplish this. Make sure you have one of the following extensions installed ms-vscode-remote.vscode-remote-extensionpack (package containing remote development for SSH, Containers and WSL) or ms-vscode-remote.remote-containers (for remote development in containers).
After installing these extensions all you need is a devcontainer.json file in a .devcontainer folder inside of your workspace. <project>/.devcontainer/devcontainer.json.
In case of Devilbox the file should look like the following:
// See https://aka.ms/vscode-remote/devcontainer.json for format details.
{
	// See https://aka.ms/vscode-remote/devcontainer.json for format details.
	"name": "Existing Docker Compose (Extend)",

	// Update the 'dockerComposeFile' list if you have more compose files or use different names.
	// The .devcontainer/docker-compose.yml file contains any overrides you need/want to make.
	"dockerComposeFile": [
		"../../../../docker-compose.yml" // Point to Devilbox's docker-compose.yml
	],

	// The 'service' property is the name of the service for the container that VS Code should
	// use. Update this value and .devcontainer/docker-compose.yml to the real service name.
	"service": "php", // Name of the service we want to remote to

	// The optional 'workspaceFolder' property is the path VS Code should open by default when
	// connected. This is typically a file mount in .devcontainer/docker-compose.yml
	"workspaceFolder": "/shared/httpd/<project-name>", // For example: /shared/httpd/my-website

	// Uncomment the next line if you want to keep your containers running after VS Code shuts down.
	// "shutdownAction": "none",

	// Uncomment the next line if you want to add in default container specific settings.json values
	// "settings":  { "workbench.colorTheme": "Quiet Light" },

	// Uncomment the next line to run commands after the container is created - for example installing git.
	// "postCreateCommand": "apt-get update && apt-get install -y git",

	// Add the IDs of any extensions you want installed in the array below.
	"extensions": [
            "eamodio.gitlens",
            "felixfbecker.php-debug",
            "felixfbecker.php-intellisense",
            "fterrag.vscode-php-cs-fixer",
            "atlassian.atlascode"
    ],
}

This approach needs Devilbox to be up and running on forehand.
When the extensions are installed AND the devcontainer.json file is present in the appropriate folder VS Code will notify you about that it detected the file (upon reopening the workspace) and that you're able to reopen the project inside of the container.

After reopening the project inside of the container you're also able to fire commands inside of the container straight away from VS Code's built-in terminal. For example composer install etc.

Work Like Charm for me!

@CoffeeQuotes yeah indeed, not only Devilbox rocks, but this setup is really just so comfy and ace. It does not fill up the machine with unneeded data and if you want a fresh start you can just clean the containers out and have a fresh start. If you work with Node and write JS apps have a look at this https://github.com/cytopia/devilbox/issues/709, in that thread are configs for Gulp and Rollup.

I just tried the configuration quoted by @CoffeeQuotes and it is working, but it is so intensive on the CPU that I had to drop it... my workstation config is very good but somehow it seems to be preparing for launching like a rocket...

@masiorama a) Are you doing exactly what is mentioned here ? https://github.com/cytopia/devilbox/issues/628#issuecomment-558044181
b) What are you doing with the setup, what are you working on?
c) What are the specs of your box?
Mine are this, a laptop, and everything this butter smooth. I do not have Node, PHP or anything installed locally, just in containers, it works excellent, fast and box does not even hum when coding.

@robots4life yup, followed the steps, checked few times to be sure.
Indeed it is working, but it is somehow to much intensive on the CPU.
My notebook's specs are:
OS: Windows 10 Pro,
CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
RAM: 32,0 GB
I'm gonna try again in the next days, anyway.
Thanks!

@masiorama Please do check https://github.com/docker/for-win/issues/1936 and https://www.reddit.com/r/docker/comments/87uinr/docker_is_very_slow_on_windows_10/ and https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly, perhaps that might help.
Since I have the data I work with locally and mounted into the containers I can remove and clean all containers on a regular basis, or when I need to, to keep things spotless and fast. This is for the containers, not the images.
docker-compose stop
docker-compose rm -f

Docker for Windows is basically running a Linux VM to run the Linux Docker containers.

Hope this is somewhat helpful. If you find the cause and it has to do with Devilbox, please do let us know, thank you. :+1:

A note on using php-cs-fixer in VSCode in a remote Devilbox container. php-cs-fixer is listed as available tool here https://devilbox.readthedocs.io/en/latest/readings/available-tools.html#available-tools though it seems it is not installed.
Using the VSCode extension for php-cs-fixer https://github.com/junstyle/vscode-php-cs-fixer these steps are required to make things work in VSCode with the remote Devilbox container.
I have a local folder mounted to the container. For me this is simply /www/phptools/. In the remote container this resolves to /shared/httpd/phptools/.
Though for you this points to anything you set as value for HOST_PATH_HTTPD_DATADIR in your .env file.
Locally I made these steps to make php-cs-fixer available in the container.

Inside the /www/phptools/ folder or whatever folder you have pointed to HOST_PATH_HTTPD_DATADIR in the .env file do this.
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.18/doc/installation.rst
wget https://cs.symfony.com/download/php-cs-fixer-v2.phar -O php-cs-fixer

sudo chmod a+x php-cs-fixer

In the settings for the PHP CS FIXER extension for Remote and Workspace now simply put /shared/httpd/phptools/php-cs-fixer as value for the executable path and this error will go away and the extension will work.

Since I regularly remove stopped containers I opted not to add php-cs-fixer to the $PATH in the Devilbox container. However you are free to use other installation options and/or modify the Devilbox $PATHs.
Had a look in the documentation and have not found a setting how to persist changes to the Devilbox $PATH between removing stopped containers, is there something I could do to have paths that are added to $PATH in the Devilbox keep those changes between removing stopped containers?
Ideally in the Devilbox shell I would want to run
sudo cp /shared/httpd/phptools/php-cs-fixer /usr/local/bin/php-cs-fixer
and then
(https://unix.stackexchange.com/a/26059)
PATH=$PATH:/usr/local/bin/php-cs-fixer
and keep those changes and then be able to joint point the executable path in the remote and workspace extension settings to php-cs-fixer.

I have been following this thread closely.
Did you get PHPCS itself working (not php-cs)?
If so, what path did you pass as value in the vscode devcontainer settings for "phpcs.executablePath"?
I haven't had any luck with either of these:
"phpcs.executablePath": "/usr/local/bin/phpcs",
"phpcs.executablePath": "/home/devilbox/.composer/vendor/bin/phpcs",

I haven't got to php-cs yet, that's next on my list...
@cytopia is there a way to see the directory structure / locations for available tools inside the php container?

I have been following this thread closely.
Did you get PHPCS itself working (not php-cs)?
If so, what path did you pass as value in the vscode devcontainer settings for "phpcs.executablePath"?
I haven't had any luck with either of these:
"phpcs.executablePath": "/usr/local/bin/phpcs",
"phpcs.executablePath": "/home/devilbox/.composer/vendor/bin/phpcs",
I haven't got to php-cs yet, that's next on my list...
@cytopia is there a way to see the directory structure / locations for available tools inside the php container?

@CamdenGonzalez aight, I will give it a shot, took me some time to figure out the php-cs-fixer has to be installed, I was under the assumption it is available, as in, ready to use. Then I checked out phpcs and phpcbf and the VSCode extensions for it, but had to do some work so stopped "tooling". But since there is demand for this I will try and get this rocking.. :guitar:

@CamdenGonzalez du have you got a way to meet in chat, I have a feeling that could benefit both of us, the long term plan is to add documentation for how to use the available tools in a remote container in VSCode.
If chat is not an option, can you elaborate on how you, if I understand you correct, got xDebug working over the browser and phpcs / php-cs-fixer working locally ?

@robots4life Sure let me know what your preferred method for chat is and we can go form there.
I encountered limitations running vscode in a container (I'm sure those limitations are attributed to my lack of knowledge but for the sake of productivity I opted for a workable compromise).
When trying vscode in containers I opted to "attach" to the devilbox php container using the vscode remotes extension - specifically ms-vscode-remote.remote-containers.
This allowed me to run xDebug in CLI launch mode but caused all sorts of problems such as:

Blocking the browser from loading any of my local sites.
xDebug browser launch wouldn't run
phpcs appeared non-existent (i think... can't remember... and i did get it working in some container configuration but fail to remember which)
php-cs-fixer wouldn't function

So, I opted to run the following:

xDebug runs in the devilbox php container with custom php.ini settings - browser debug only with chrome debug extension
xDebug relies on boot persistent alias (as advised in devilbox docs) - this is then specified in the custom ini file
VSCode extension PHP Debug felixfbecker.php-debug only works locally (browser) with launch.json pathmapping
PHPCS runs from global composer install on macos
PHPCS Rulesets also run locally from global composer install on macos
php-cs-fixer runs from brew php install on macos

Okay, so this is how I setup xDebug
Setup Boot Alias
_https://devilbox.readthedocs.io/en/latest/howto/xdebug/host-address-alias-an-mac.html#howto-host-address-alias-on-mac_
# Run from outside container in linux/macos

sudo curl -o \
        /Library/LaunchDaemons/org.devilbox.docker_10254_alias.plist \
        https://raw.githubusercontent.com/devilbox/xdebug/master/osx/org.devilbox.docker_10254_alias.plist

# Enable without reboot

sudo launchctl load /Library/LaunchDaemons/org.devilbox.docker_10254_alias.plist

Create custom.ini
Create a new file inside - /devilbox/cfg/php-ini-*/
I named it custom.ini and added the following (took some trial and error)
[xdebug]
xdebug.mode = debug
xdebug.client_host = <IP_ADDRESS>
xdebug.client_port = 9003
xdebug.idekey = VSCODE
xdebug.log = /var/log/php/xdebug.log
xdebug.discover_client_host = Off
xdebug.cli_color = 1
xdebug.start_with_request = trigger

Create launch.json file

Opened project folder
Go to debug icon in left side panel of vscode
Created launch.json file
Added the following:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for xDebug",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        // Devilbox initial directory structure
        "/shared/httpd/": "${workspaceFolder}/htdocs",
        // Mirror cPanel directory structure,
        // "/shared/httpd/dev/public_html": "${workspaceFolder}",
      },
      "ignore": ["**/vendor/**/*.php"]
    },
    {
      "name": "Launch from current script",
      "type": "php",
      "request": "launch",
      "program": "${file}",
      "cwd": "${fileDirname}",
      "port": 9003,
      "ignore": ["**/vendor/**/*.php"]
    }
  ]
}

Listen for xDebug require the Chrome browser extension:
Xdebug Helper - _https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc?hl=en_
Launch from current script won't work unless vscode is running inside the devilbox container (or has access through some kind of binding... which is outside of my expertise)
Test xDebug

Check from inside the container by going to devil box folder
cd /path/to/devilbox

Enter the php container
./shell.sh

Tail the xDebug log
tail -f /var/log/php/xdebug.log

Then go to project workspace and locate a file to work on that you can open in browser

Set a breakpoint

Start browser debug on a file in vscode

Go to chrome and make sure to enable the "xdebug helper" extension

Refresh the page and it should switch to vscode

Lastly, I run live-server for live reloads whilst running devilbox which saves me having to browser refresh 3 million times a day.
It's all quite a hacky setup but it works...

How to get SvelteKit working with Devilbox. https://github.com/cytopia/devilbox/issues/797#issuecomment-843941126

Thank you for all these informations!
(Especially the detailed information from @boumanb helped me.)
Possibly this information would also be suitable for the devilbox documentation like:
https://devilbox.readthedocs.io/en/latest/intermediate/configure-php-xdebug.html
(even if it is not devilbox specific topic)
II will try in any case to take up this approach in our Contao documentation or to extend it ...

I will try in any case to take up this approach in our Contao documentation or to extend it ...

Cool. Let me know when its in and I can replicate it on the Devilbox documentation as well

Cool. Let me know when its in and I can replicate it on the Devilbox documentation as well

Check.
I will summarize the info and create a PR for the Contao doc. As soon as this is accepted I will let you know...

So I don't forget see:
https://github.com/contao/docs/issues/790

Unfortunately, I still have a question.
I had used VSCode with Xdebug, with this "PHP Debug" extension installed locally in VSCode.
Together with the information from the devilbox documentation it worked.
Now I have installed the "Visual Studio Code Remote Development" pack as described here. It works so far.
In the VSCode terminal I am inside the devilbox php container with the user "devilbox". Also e.g. "Intelephense" via this extension works.
But:
Now I have to install in VSCode, analogous to e.g. "Intelephense", also the "PHP Debug" extension in the container itself.
Now unfortunately it does not work anymore. I have tried various entries in the "devilbox\cfg\php-ini-7.4\xdebug.ini" and ".vscode\launch.json".

Windows 10 Pro / WSL 2 / current devilbox version (with PHP 7.4).
/shared/httpd/myphpdemo
devilbox/data/www/myphpdemo/htdocs
https;//myphpdemo.loc

Could anyone provide a working configuration/help for Xdebug usage in this environment?
Thanks a lot

Addition:
Here is my working configuration when the VSCode "PHP debug" extension is installed locally within VSCode
(analogous to the devilbox documentation):
\devilbox\cfg\php-ini-7.4\xdebug.ini
xdebug.mode               = debug
xdebug.start_with_request = yes

xdebug.remote_handler   = dbgp
xdebug.remote_port      = 9000

xdebug.remote_connect_back = 0
;from vEthernet (WSL):
xdebug.client_host = <IP_ADDRESS>

xdebug.idekey           = VSCODE
xdebug.remote_log       = /var/log/php/xdebug.log

\devilbox\data\www\demo.vscode\launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9000,
      "pathMappings": {"/shared/httpd/demo/htdocs": "${workspaceRoot}/htdocs"}
    }
  ]
}

Hint:
Using Docker via WSL 2:
The entry for "xdebug.client_host" here according to the IPv4 address from "vEthernet (WSL)" (see ipconfig).
Using Docker via VM (Windows 10 Pro / Hyper-V):
The entry for "xdebug.client_host" here corresponding to the IPv4 address from "vEthernet (Default Switch)" (see ipconfig).

Now I need help with this procedure:
VSCode is asking me for relaunch according to this:
\devilbox\data\www\demo\.devcontainer\devcontainer.json
{
  "name": "Existing Docker Compose (Extend)",
  "dockerComposeFile": [
    "../../../../docker-compose.yml"
  ],
  "service": "php",
  "workspaceFolder": "/shared/httpd/demo",
  "remoteUser": "devilbox",
}

As already mentioned it works then regarding using VSCode terminal (inside the devilbox php container with the user "devilbox") or using the "Intelephense" extension for example.
The existing extension "PHP Debug" is now grayed out with the option to install it within the PHP container.
After installation, I am now trying to set a breakpoint and debug without any other changes:
Result:
_Error: listen EADDRINUSE: address already in use :::9000
I then tried different entries in "xdebug.ini" and "launch.json".
Unfortunately without further success.
Grateful for your suggestions ...

Does anyone know how to install Vercel, Netlify and GitHub CLI to the Devilbox so they work from VS Code and are possibly kept installed between shut down and start (not when removing containers) ?

https://devilbox.readthedocs.io/en/latest/autostart/custom-scripts-globally.html#custom-scripts-globally
In /devilbox/autostart I have created a file clis.sh with following content.
#! /usr/bin/env bash

# run this script
# chmod +x clis.sh
# ./clis.sh

npm i -g vercel

npm install netlify-cli -g

Remember to chmod +x clis.sh inside /devilbox/autostart so the script can be executed.
This will install Vercel and Netlify CLI globally in Devilbox and persist the installation as long as the clis.sh fils is kept inside /devilbox/autostart.
Per docs, i.e.
# Install grunt as devilbox user
# su -c "npm install grunt" -l devilbox

asks for a password that I don't know and that is not the host password.
But the CLIs are installed as the devilbox user since in devcontainer.json I have the line "remoteUser": "devilbox",.
https://github.com/cli/cli/blob/trunk/docs/install_linux.md
The GitHub CLI has a different approach to install and since git is pretty much the only tool I have on the host I am happy installing the GitHub CLI on the host as well.

Ive been using Devilbox for all of 2 hours, so Im not sure if I came up with a really simple way to solve this, or a terrible way, you be the judge, but it seems to be working for me 😂
All I did was :

Log into the php container using the shell.sh
ln -s /usr/local/bin/php php

This creates a symlink to the php binary, which is now also available on the host machine under your devilbox/data/www folder. I then
4. Edit VS Code settings.json
5. Set the path of the php.validate.executablePath attribute
Phenomenal project @cytopia thanks a mill, Im loving it so far.

I subsequently found the following warning here in the documentation:
Do not create any symlinks inside your project directories that go outside the data dir. Anything which is outside this directory is not mounted into the container.
Considering Im doing the opposite, and adding the symlink inside the container, Im not sure if this warning is applicable, since my solution seems to work for me, and the PHP binary is available from my host system 🤷♂
Im still learning docker, but it seems the most correct solution would be to create a read-only mount point to the appropriate target in the container, in the same way as the project folder is mounted. This would be to expose the PHP binaries (or any other desired binaries for that matter) more safely via a dedicated mounted directory?

@patrict what are you trying to achieve ? Do you want VS Code to "connect" to Devilbox and work with Devilbox inside VS Code ? Happy to give you a quick "up and running" tour on how to get that working with VS Code, if that is what you want to do.

@patrict are you on Linux or Windows? On Windows (+ WSL2) I was able to make things to work, while I have direct experience on native Linux.

@patrict are you on Linux or Windows? On Windows (+ WSL2) I was able to make things to work, while I have direct experience on native Linux.

@masiorama option C - Mac M1 😄
Just to clarify, my symlink did work, so I was just sharing my solution for comment, in case anyone had a better/alternative method

Hi @patrict
Thanks for your info you posted. It may be pointing me in the correct direction but I am wanting to take this a step further.
My setup:
Fedora 38
Devilbox v3.0.0-beta-0.3 (2023-01-02)
My startup script:
#!/usr/bin/env sh

cd /home/$USER/.devilbox/

case "$1" in
  restart)
    echo "Stopping services..."
    docker compose stop
    echo "Services stopped."

    echo "Removing containers..."
    docker compose rm -f
    echo "Containers removed."

    echo "Starting services..."
    docker compose up -d php php81 php74 httpd mysql bind elastic logstash kibana redis
    echo "Services started."
    ;;
  stop)
    echo "Stopping services..."
    docker compose stop
    echo "Services stopped."

    echo "Removing containers..."
    docker compose rm -f
    echo "Containers removed."
    ;;
  *)
    echo "Usage: $0 {restart|stop}"
    exit 1
    ;;
esac

My default PHP is 8.2 and as you can see I am also loading PHP 7.4 and 8.1
In VSCode I want to take advantage of workspaces for each project and be able to set the interpreter for PHP to the PHP version that that workspace uses.
This is something that is easy to do in vscode per workspace via the settings.
Based on your symlink, would it be possible to enter into each php docker container and symlink each php docker container like this:
PHP 8.2: ln -s /usr/local/bin/php php
PHP 8.1: ln -s /usr/local/bin/php php81
PHP 7.4: ln -s /usr/local/bin/php php74
Then in vscode settings.json set:
php.validate.executablePath="php"
php.validate.executablePath="php81"
php.validate.executablePath="php74"
Depending on the workspace?

Hmm, it does not seem to work for me. What I did:
Using VSCode Docker extension, I attached the devilbox/php-fpm:8.1-work-0.150 container to a shell.
Ran ln -s /usr/local/bin/php php81
ls shows php81 symlink in /shared/httpd/
On Fedora host machine:
cd /home/brent/Development/www/
ls shows php81
php81 -v does not work.

So I have the symlink working as long as I am inside the container:
<EMAIL_ADDRESS>in /shared/httpd $ ln -s /usr/local/bin/php /shared/httpd/php81
<EMAIL_ADDRESS>in /shared/httpd $ /shared/httpd/php81 -v
PHP 8.1.14 (cli) (built: Jan  8 2023 00:49:17) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.14, Copyright (c), by Zend Technologies
    with Xdebug v3.2.0, Copyright (c) 2002-2022, by Derick Rethans

However, outside the container it still fails:
[brent@fedora www]$ ls -lha
total 4.0K
drwxr-xr-x. 1 brent brent 24 May  4 23:02 .
drwxr-xr-x. 1 brent brent 26 May  4 05:54 ..
lrwxrwxrwx. 1 brent brent 18 May  4 23:02 php81 -> /usr/local/bin/php
drwxr-xr-x. 1 brent brent 30 May  4 06:59 xenforo
[brent@fedora www]$ /home/brent/Development/www/php81 -v
bash: /home/brent/Development/www/php81: No such file or directory

I am guessing I am missing something though not sure how @patrict got it working unless it is something specific to MacOS.

Hello,
I'm using Google Translate, so I apologize in advance for any writing errors.
To solve this problem, simply create a file called php in the root directory of your project and insert this code:
#!/bin/bash
docker exec -it devilbox php $@

Then make it executable:
~$ chmod +x php
And in VSCode settings, assign this value:
"php.validate.executablePath": "./php",
CREDITS: How to setup VSCode with PHP inside docker

I just recorded a video explaining how to solve this problem and I even added a bonus that helps start shell.sh automatically when opening VSCode.
LINK: https://youtu.be/rWt4xQTSBAE


[Bug]: Netlify deployment fails with message: "Cannot find module '@gatsbyjs/reach-router/lib/utils'"

Summary
After updating my site to Gatsby 5, I can no longer use this plugin in my configuration.
Steps to reproduce

Install and use Gatsby 5.2.0
Install the plugin through the Netlify plugins directory or activate it through the netlify.toml file
Follow the provided setup instructions in the documentation

A link to a reproduction repository
No response
Plugin version
3.4.8
More information about your build

[ ] I am building using the CLI
[X] I am building using file-based configuration (netlify.toml)

What OS are you using?
None
Your netlify.toml file

`netlify.toml`
[build]
  base = "/"
  command = "yarn build"
  publish = "public/"

[build.processing.css]
  bundle = true
  minify = false
[build.processing.js]
  bundle = true
  minify = false
[build.processing.html]
  pretty_urls = true
[build.processing.images]
  compress = true

[[plugins]]
package = "@netlify/plugin-gatsby"

[[headers]]
  for = "/rss.xml"
  [headers.values]
    Cache-Control = "no-cache"

[[redirects]]
  from = "/feed"
  to = "/rss.xml"
  status = 200
  force = true

Configuration

`gatsby-config.ts` and options
import type { GatsbyConfig } from "gatsby";
import { rssQuery, serialize } from "./src/utils/rss";

const environment = process.env.NODE_ENV;
const isProduction = environment === "production";

const config: GatsbyConfig = {
    siteMetadata: {
        language: `en`,
        title: `Blog | Niko Heikkilä`,
        author: {
            name: `Niko Heikkilä`,
        },
        description: `A blog by Niko Heikkilä. Powered by coffee, VS Code, and Gatsby.`,
        siteUrl: `https://nikoheikkila.fi`,
    },
    trailingSlash: "always",
    flags: {
        PRESERVE_FILE_DOWNLOAD_CACHE: true,
        FAST_DEV: true,
        DEV_SSR: false,
    },
    plugins: [
        `gatsby-plugin-image`,
        `gatsby-transformer-sharp`,
        `gatsby-plugin-sharp`,
        {
            resolve: `gatsby-transformer-remark`,
            options: {
                plugins: [
                    {
                        resolve: `gatsby-remark-images`,
                        options: {
                            maxWidth: 960,
                        },
                    },
                    {
                        resolve: `gatsby-remark-autolink-headers`,
                        options: {
                            icon: false,
                        },
                    },
                    `gatsby-remark-copy-linked-files`,
                    `gatsby-remark-smartypants`,
                ],
            },
        },
        {
            resolve: `gatsby-source-filesystem`,
            options: {
                path: "./content",
                name: `blog`,
            },
        },
        {
            resolve: `gatsby-source-filesystem`,
            options: {
                path: "./src/assets",
                name: `assets`,
            },
        },
        {
            resolve: `gatsby-plugin-feed`,
            options: {
                query: `{
                    site {
                        siteMetadata {
                            title
                            description
                            siteUrl
                            site_url: siteUrl
                        }
                    }
                }`,
                feeds: [
                    {
                        serialize,
                        query: rssQuery,
                        output: `/rss.xml`,
                        title: `RSS Feed | Niko Heikkilä`,
                        match: `^/blog/`,
                    },
                ],
            },
        },
        {
            resolve: `gatsby-plugin-manifest`,
            options: {
                name: `Niko Heikkilä`,
                short_name: `nikoheikkila`,
                start_url: `/`,
                background_color: `#ffffff`,
                theme_color: `#663399`,
                display: `standalone`,
                icon: `src/static/favicon.png`,
                crossOrigin: `use-credentials`,
            },
        },
        {
            resolve: `gatsby-plugin-robots-txt`,
            options: {
                policy: [{ userAgent: "*", allow: "/" }],
                output: `/robots.txt`,
            },
        },
        {
            resolve: `gatsby-plugin-typescript`,
            options: {
                isTSX: true,
                allExtensions: true,
            },
        },
        {
            resolve: `gatsby-plugin-sass`,
            options: {
                sassOptions: {
                    includePaths: ["./src/styles"],
                },
            },
        },
        `gatsby-plugin-sitemap`,
        `gatsby-plugin-netlify`,
    ].concat(
        // Load the PWA service worker only in production to enhance development experience.
        isProduction ? [`gatsby-plugin-offline`] : []
    ),
};

export default config;

Environment

Environment
  System:
    OS: macOS 12.6.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 2.92 GB / 64.00 GB
    Shell: 3.5.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 18.12.1 - ~/Library/Caches/fnm_multishells/12047_1670673446030/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.1.1 - ~/Library/Caches/fnm_multishells/12047_1670673446030/bin/npm
  Browsers:
    Chrome: 105.0.5195.102
    Safari: 16.1
  npmPackages:
    @netlify/plugin-gatsby: 3.4.8 => 3.4.8

Gatsby info

gatsby info
  System:
    OS: macOS 12.6.1
    CPU: (10) arm64 Apple M1 Max
    Shell: 3.5.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 18.12.1 -
~/Library/Caches/fnm_multishells/12047_1670673446030/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.1.1 - ~/Library/Caches/fnm_multishells/12047_1670673446030/bin/npm
  Languages:
    Python: 3.11.0 - /Users/niko.heikkila/.pyenv/shims/python
  Browsers:
    Chrome: 105.0.5195.102
    Safari: 16.1
  npmPackages:
    gatsby: 5.2.0 => 5.2.0
    gatsby-plugin-feed: 5.2.0 => 5.2.0
    gatsby-plugin-image: 3.2.0 => 3.2.0
    gatsby-plugin-manifest: 5.2.0 => 5.2.0
    gatsby-plugin-netlify: 5.1.0 => 5.1.0
    gatsby-plugin-offline: 6.2.0 => 6.2.0
    gatsby-plugin-robots-txt: 1.8.0 => 1.8.0
    gatsby-plugin-sass: 6.2.0 => 6.2.0
    gatsby-plugin-sharp: 5.2.0 => 5.2.0
    gatsby-plugin-sitemap: 6.2.0 => 6.2.0
    gatsby-plugin-typescript: 5.2.0 => 5.2.0
    gatsby-remark-autolink-headers: 6.2.0 => 6.2.0
    gatsby-remark-copy-linked-files: 6.2.0 => 6.2.0    gatsby-remark-images: 7.2.0 => 7.2.0
    gatsby-remark-smartypants: 6.2.0 => 6.2.0
    gatsby-source-filesystem: 5.2.0 => 5.2.0
    gatsby-transformer-remark: 6.2.0 => 6.2.0
    gatsby-transformer-sharp: 5.2.0 => 5.2.0

Your _redirects file

`_redirects`
/* /404.html 404

Builds logs (or link to your logs)

Build logs
See here

Function logs

Function logs
# Paste logs here

Also ran into the same issue deploying a new project with Gatsby 5, did you manage to fix it somehow?

@nikoheikkila, we have some work going in soon to support Gatsby v5. See #547. It might not be related to the missing module, but give it a go after #547 gets released.

@nikoheikkila, we have some work going in soon to support Gatsby v5. See #547. It might not be related to the missing module, but give it a go after #547 gets released.

Thanks! I can confirm that plugin version 3.5.0 works with Gatsby 5. 👍🏼

@nikoheikkila, we have some work going in soon to support Gatsby v5. See #547. It might not be related to the missing module, but give it a go after #547 gets released.

Thanks! I can confirm that plugin version 3.5.0 works with Gatsby 5. 👍🏼

Hi, how did you make it working ?
Netlify keep using 3.4.8 version... I tried UI install & .toml file

Loading plugins
4:37:30 PM:    -<EMAIL_ADDRESS>from netlify.toml


DRC failed with Local interconnect spacing < 0.17um (li.3)

Description

I got DRC failed when harden the wrapper. and got Local interconnect spacing < 0.17um (li.3), should I ignore it and submit it to MPW-7?
Expected behavior

DRC clean
Environment

Kernel: Linux v<IP_ADDRESS>-microsoft-standard-WSL2
Distribution: ubuntu 22.04
Python: v3.10.4 (OK)
Container Engine: docker v20.10.17 (OK)
OpenLane Git Version: f9b5781f5ef0bbdf39ab1c2bbd78be8db11b27f2
pip: INSTALLED
pip:venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

f9b5781 2022-07-01T16:04:31+02:00 Fix a bug with `-overwrite` (#1171) - Anton Blanchard -  (grafted, HEAD, tag: 2022.07.02_01.38.08)

Reproduction Material

Logs

DRC style is now "drc(full)"
Loading DRC CIF style.
[INFO]: COUNT: 3622786
[INFO]: Should be divided by 3 or 4
[INFO]: DRC Checking DONE (/mnt/r/work/Rift2Go_2330/openlane/user_project_wrapper/runs/22_09_12_12_04/reports/signoff/drc.rpt)
[INFO]: Saving mag view with DRC errors (/mnt/r/work/Rift2Go_2330/openlane/user_project_wrapper/runs/22_09_12_12_04/results/signoff/user_project_wrapper.drc.mag)
[INFO]: Saved

And Part of drc.rpt
----------------------------------------
Local interconnect spacing < 0.17um (li.3)
----------------------------------------
 162.450um 180.550um 162.605um 180.635um
 162.620um 180.465um 162.775um 180.550um
 162.450um 180.465um 162.605um 180.635um
 163.395um 180.550um 163.550um 180.635um
 163.395um 180.465um 163.550um 180.635um
 163.225um 180.465um 163.380um 180.550um
 168.690um 180.550um 168.845um 180.635um
 168.860um 180.465um 169.015um 180.550um
 168.690um 180.465um 168.845um 180.635um
 169.635um 180.550um 169.790um 180.635um
 169.635um 180.465um 169.790um 180.635um
 169.465um 180.465um 169.620um 180.550um
 174.930um 180.550um 175.085um 180.635um
 175.100um 180.465um 175.255um 180.550um
 174.930um 180.465um 175.085um 180.635um
 175.875um 180.550um 176.030um 180.635um
 175.875um 180.465um 176.030um 180.635um
 175.705um 180.465um 175.860um 180.550um
 181.170um 180.550um 181.325um 180.635um
 181.340um 180.465um 181.495um 180.550um
 181.170um 180.465um 181.325um 180.635um
 182.115um 180.550um 182.270um 180.635um
 182.115um 180.465um 182.270um 180.635um
 181.945um 180.465um 182.100um 180.550um
 160.995um 178.885um 161.150um 179.055um
 160.825um 178.885um 160.980um 179.055um
 187.410um 180.550um 187.565um 180.635um
 187.580um 180.465um 187.735um 180.550um
 187.410um 180.465um 187.565um 180.635um
 188.355um 180.550um 188.510um 180.635um
 188.355um 180.465um 188.510um 180.635um
 188.185um 180.465um 188.340um 180.550um
 165.020um 178.885um 165.175um 179.055um
 164.850um 178.885um 165.005um 179.055um
 167.235um 178.885um 167.390um 179.055um
 167.065um 178.885um 167.220um 179.055um
 193.650um 180.550um 193.805um 180.635um
 193.820um 180.465um 193.975um 180.550um
 193.650um 180.465um 193.805um 180.635um
 194.595um 180.550um 194.750um 180.635um
 194.595um 180.465um 194.750um 180.635um
 194.425um 180.465um 194.580um 180.550um
 171.260um 178.885um 171.415um 179.055um
 171.090um 178.885um 171.245um 179.055um
 173.475um 178.885um 173.630um 179.055um
 173.305um 178.885um 173.460um 179.055um
 199.890um 180.550um 200.045um 180.635um
 200.060um 180.465um 200.215um 180.550um
 199.890um 180.465um 200.045um 180.635um
 200.835um 180.550um 200.990um 180.635um
 200.835um 180.465um 200.990um 180.635um
 200.665um 180.465um 200.820um 180.550um
 177.500um 178.885um 177.655um 179.055um
 177.330um 178.885um 177.485um 179.055um
 179.715um 178.885um 179.870um 179.055um
 179.545um 178.885um 179.700um 179.055um

config.zip

Issue template is mandatory for filing github issue to understand your current OpenLane setup:
 This part is incredibly important:

    Please run the following shell command in the OpenLane root folder:

        python3 ./env.py issue-survey

    Then copy and paste the ENTIRE output between the triple-backticks below. (```)

    If the command does not succeed, you are using an out-of-date version of
    OpenLane, and it is recommended that you update.

Its continuation of #1353.
You've to add GRT_OBS for the SRAM macros.

How to set GRT_OBS?
I didn't find it in doc

Issue template is mandatory for filing github issue to understand your current OpenLane setup:
 This part is incredibly important:

    Please run the following shell command in the OpenLane root folder:

        python3 ./env.py issue-survey

    Then copy and paste the ENTIRE output between the triple-backticks below. (```)

    If the command does not succeed, you are using an out-of-date version of
    OpenLane, and it is recommended that you update.

complete this issue template to know which OpenLane currently you're using.

i have updated，haven't I？

https://openlane-docs.readthedocs.io/en/rtd-develop/configuration/README.html#routing
GLB_RT_OBS

I failed again by adding
set ::env(GLB_RT_OBS)  "
	                li1   40 3150  361  3308,\
	                met1  40 3150  361  3308,\
	                met2  40 3150  361  3308,\
                    met3  40 3150  361  3308,\
                    met4  40 3150  361  3308,\

	                li1   2560 3150 2881 3308,\
	                met1  2560 3150 2881 3308,\
	                met2  2560 3150 2881 3308,\
                    met3  2560 3150 2881 3308,\
                    met4  2560 3150 2881 3308,\

                    li1   430 3150 1434 3372,\
                    met1  430 3150 1434 3372,\
                    met2  430 3150 1434 3372,\
                    met3  430 3150 1434 3372,\
                    met4  430 3150 1434 3372,\

	                li1   1470 3150 2474 3372,\
	                met1  1470 3150 2474 3372,\
	                met2  1470 3150 2474 3372,\
                    met3  1470 3150 2474 3372,\
                    met4  1470 3150 2474 3372,\

	                li1   40  80  361 238,\
	                met1  40  80  361 238,\
	                met2  40  80  361 238,\
                    met3  40  80  361 238,\
                    met4  40  80  361 238,\

                    li1   2560  80 2881 238,\
                    met1  2560  80 2881 238,\
                    met2  2560  80 2881 238,\
                    met3  2560  80 2881 238,\
                    met4  2560  80 2881 238,\

                    li1   430  80  1434 302,\
	                met1  430  80  1434 302,\
	                met2  430  80  1434 302,\
                    met3  430  80  1434 302,\
                    met4  430  80  1434 302,\

                    li1   1470  80 2474 302,\
                    met1  1470  80 2474 302,\
                    met2  1470  80 2474 302,\
                    met3  1470  80 2474 302,\
                    met4  1470  80 2474 302
	                "

I see it report that li.3 is interconnect
user_project_wrapper
----------------------------------------
Local interconnect spacing < 0.17um (li.3)
----------------------------------------
 162.450um 180.550um 162.605um 180.635um
 162.620um 180.465um 162.775um 180.550um
 162.450um 180.465um 162.605um 180.635um

but I cannot see li3 at openroad gui mode, I only see li1.
So, what should I modify next?
@vijayank88

As per slack channel discussion if you're using SRAM macros, user will skip magic DRC check with set ::env(QUIT_ON_MAGIC_DRC_ERROR) 0.
Still you need to attach test case for this error to debug.
Wait for @RTimothyEdwards to look into this issue.

I upload the whole project to github
make user_proj_sramout2
make user_project_wrapper

can see the DRC failed.
However, it will cost you too much time, is there any faster ways?

skip magic DRC check will failed the MPW-preCheck

skip magic DRC check will failed the MPW-preCheck

hi,have you got the solution?

@LvmhZhD Not yet. For the MPW-7 is closed, I am focused on improving my design now. But I have found a solution in slack chn. I am not sure whether will it work, and whether will it work for self-design SRAM. I will try that when MPW-8 opened.

@LvmhZhD Not yet. For the MPW-7 is closed, I am focused on improving my design now. But I have found a solution in slack chn. I am not sure whether will it work, and whether will it work for self-design SRAM. I will try that when MPW-8 opened.

Ok,  thank you


Add support for sparse vectors

Hi there -- first of all, this extension is fantastic and I am very excited about using DuckDB as a vector search solution. Thanks for your hard work!
One currently missing feature I'd love to see added is support for "sparse" vectors (e.g. SPLADE, BGE-M3, BM25), which would support hybrid search use cases.
This is a feature that is supported by a lot of the major providers (pg_vector, Pinecone, Qdrant, Milvus, etc.).
Is it on the roadmap for you all? I think even providing a standardized sparse similarity function would be great, even if building fast indices, etc. proves more challenging.

For anyone else considering DuckDB for sparse vectors, it is possible to do some things with just the built in list and map functions.
The macro below, while quite ugly, is actually reasonably performant. It assumes you are storing your sparse vectors in a MAP column as {index:value} pairs.
CREATE OR REPLACE MACRO map_dot_product(map1, map2) AS (
    list_dot_product(
        flatten(list_transform(
            list_intersect(map_keys(map1), map_keys(map2)),
            x -> map_extract(map1, x)
        ))::DOUBLE[],
        flatten(list_transform(
            list_intersect(map_keys(map1), map_keys(map2)),
            x -> map_extract(map2, x)
        ))::DOUBLE[]
    )
);

Suggestions/improvements welcome :)


python3Packages.qnap-qsw: init at 0.3.0

Motivation for this change
Python library to interact with the QNAP QSW API
https://github.com/Noltari/python-qnap-qsw
This could become a Home Assistant dependency.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] 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/)
21.11 Release Notes (or backporting 21.05 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

1 package built:

python39Packages.qnap-qsw


Fix the issue if the anchor view is picked from the middle of the flex line.

The anchor view should be the view which has the

minimum start position for the start anchor
maximum end position for the end anchor

but if the view in the middle of the first visible flex line (or last visible
flex line for the end anchor) had the minimum start position, the anchor
position wasn't picked correctly.
This PR fixes the issue.

@yaraki  could you take a look?


help

Hello, I saw the reviewer's question to you: Which part of your model promotes lightweighting?
Did adding an RA module parameter to your model, which was modified on ShadowFormer, make it smaller?
I would like to know:

If RA is removed
If RA is replaced with window attention,
what are the changes in parameter size in these two cases.
By the way, your ablation experiment was too simple.

If you have a clear understanding of the transformer, you would realize that the attention reweighting design in ShadowFormer is sub-optimal, since it only encourages interaction within the shadow area. Our RA module is based on the vanilla window attention instead of SIA. Thanks to the effectiveness of regional attention, we can shrink the parameter count in convolution layers to reach a reasonable level of accuracy.
We are glad to see that you read the OpenReview page. There are more detailed explanations in the supplementary file and our author-rebuttal file. It should be noted that our ablation experiment successfully supports our claim, as recognized by reviewers and area chairs.
As a kindly reminder, you should note that nobody is obligated to respond to questions, especially those with clear answers in the code release, paper, and supplementary files. If you insist on asking, just be polite and remain grateful since we have spent our time explaining your question, amid the heavy workload we are facing with.

Thank you for your excellent work!
Could you further explain the difference between the Neighborhood Attention and the Regional Attention? I apologize, but I couldn't fully understand your explanation above.
Additionally, have you considered incorporating or integrating the SIA mechanism from Shadowformer?


Using with minimal API

Hello, im trying use on my minimal api on net 6.0. I cant figure out, i tried some things but not work. Anybody know working way ?

Can you give some sample code that isn't working?

Hello again, when i tried access to "HttpProxyAsync" cant find any method because this extension of BaseController. Minimal API not using controller then i added app.UseProxies its working but swagger cant find endpoint of proxies and i needed that. My endpoint like that;
app.MapGet("test", async (HttpContent ctx) =>
{
   // I Cant figure what i need write
   // return ctx.HttpProxyAsync("http://example.com");
   // My expectation like this. I couldn't find anything about usage with minimal api on your wiki.
});

I see.  We just need to expose an extension method for that.  Adding now.

"Minimal API" is a totally new approach from Microsoft, starting in .net6.0. You should really implement this, as it is a very very fast api framework. (which is not done by just implementing an interface method, to my knowledge)

@delasource, the performance improvements in .NET 6 apply across the board, regardless of whether or not you use minimal API.
Minimal API does two primary things, as far as I can tell:

Reduces cognitive overhead of creating controller-based APIs since controller-based APIs tend to have more boilerplate code, and
Somewhat reduces the dependency footprint when using only minimal APIs.

In this case, this fix addressed (1).  This library can be used in a minimal API context now.
It does not address (2), but I would love to see the data on what, exactly, the dependency footprint delta is.
From a performance standpoint, it should be the same as long as I add net6.0 as a target, which I can do fairly quickly.  I will add this to the next release.


discussion: improve project layout and etc...

now youtube have more code and functions than before. To improve readability and maintainability, we would like to reorganize project layout, some plans are under discussion:

project layout: change to cmd/pkg(internal)/etc
reorganize errors
move some functions from youtube to own package

Thanks for any suggestion in advance.

closed by  v2


Promiscuous Versions

This is a meta issue to track mods which have versions that are compatible with far future versions of KSP. Steps are:

Find all of them.
Determine why they're available.
Determine if they should be fixed or not.
Fix all those that need to be fixed.

The List
1. No ksp_version, ksp_version_min, nor ksp_version_max

[ ] ActiveTextureManagement-x86-* (5-0)
[ ] BananaForScale-*
[x] CrewManifest (0.5.10-26) #638 #640
[ ] EntchenFlag (1.0)
[ ] FusTek-SharedAssets (1.0)
[x] KerbalAlarmClock (v<IP_ADDRESS>) #641
[ ] ModuleAnimateEmissive (v1.4)
[ ] NavHud (1.2.1)
[ ] OkramSA (1.0)
[ ] PartMapper (0.3.0)
[ ] SDHI-SharedAssets (1.0)
[x] SmartStage (v2.3.1) #642
[ ] SolverEngines (v1.4)
[x] ThermalMonitor (1.0) #643
[ ] TransferWindowPlanner (v<IP_ADDRESS>)
[ ] VNG-*

2. ksp_version_min without a ksp_version_max

[ ] AIESAerospace-Unofficial (1.5.1)
[ ] AMEG (1.1)
[ ] AnimatedDecouplers-x86 (1.1.4)
[ ] AstronomersPack-* (Interstellar.V2)
[x] ColorCodedCans (0.9) #636
[ ] CustomAsteroids-* (v1.1.0)
[x] DockingPortAlignmentIndicator (4.0) #636
[x] EditorExtensions (2.2) #624
[ ] EnvironmentalVisualEnhancements-* (7-4)
[x] HyperEdit (1.4) #644
[x] ImprovedChaseCamera (1.4.0) #636
[ ] JSIPartUtilities (v0.3) #636
[ ] KDEX (v1.04)
[ ] KerbalFoundries (Beta_1.8g) #636
[x] LargeStructuralComponents (10) #636
[ ] LSPFlags (v1.9)
[ ] ModularRocketSystem (1.7.2)
[ ] NavBallTextureExport (1.3)
[x] Proton-Bobcat (1.0) #636 KSP-CKAN/NetKAN#1705
[x] PunishTheLazy (0.01) #636
[x] RasterPropMonitor-Core (v0.19.1)
[ ] ReflectionPlugin (1.2)
[x] RocketdyneF-1 (1.2) #636
[x] SovietEngines (1.1) #636 KSP-CKAN/NetKAN#1705
[x] SpaceFacotry-Vostok-unofficial (1.0) #636
[x] SpaceFactory-Voskhod-unofficial (2.0) #636
[ ] SpaceY-Lifters (0.17.2)
[x] StripSymmetry (v1.6) #636 KSP-CKAN/NetKAN#1705
[ ] surfacelights (1.0)
[ ] Tantares (29) #645
[ ] TantaresLV (12.1)
[ ] TCShipInfo (0.3)
[ ] xScience (4.6)

3. ksp_version of any

[ ] DogeCoinFlag (v1.02)
[ ] KSP-AVC (<IP_ADDRESS>)
[ ] LandingHeight (1.4)
[ ] MiniAVC (<IP_ADDRESS>)
[x] RCSLandAid (2.1) #646
[ ] Sarkomand (v1.0)

4. ksp_version of 1.0 but newer version is more restrictive

[x] BULB (1.1) #627
[x] CraftHistory (1.4) #627
[x] HotRockets (1.0) #627
[x] KerbalScienceExchange (1.1) #627
[x] PlanetShine (<IP_ADDRESS>) #625
[x] RecoverAll (1.2) #627
[x] ScienceFunding (1.1) #627
[x] TacFuelBalancer (v2.5) #627
[x] TweakableEverything (1.9.1) #627 #633

Both Reasons 2 and 3

[ ] kribubble (1.1)
[ ] krispeeder1 (1.0)
[ ] MOVAP (1.0)

I'd argue a ksp_version of 1.0 to also be promiscuous, especially if more recent versions of the mod have more specific versions.  An example is PlanetShine <IP_ADDRESS> which is currently displayed as compatible with KSP 1.0.4 when actual most recent version is PlanetShine <IP_ADDRESS> which is only compatible with KSP 1.0.2.

PlanetShine <IP_ADDRESS> is also erroneously indicating it is compatible with 1.0.4.

@SkyMarshal I have those listed under reason 4.

Fantastic.  I'd help more but I've commitments tonight.
On Jun 26, 2015 5:00 PM, "Dwayne Bent"<EMAIL_ADDRESS>wrote:

@SkyMarshal https://github.com/SkyMarshal I have those listed under
reason 4.
—
Reply to this email directly or view it on GitHub
https://github.com/KSP-CKAN/CKAN-meta/issues/623#issuecomment-115922096.

Literally every version of AnimatedDecouplers since v1.0.1 has had the ksp_version_min tag set to 1.0 with no max tag.  No idea what to do about those.  Also: Some of the others in reason two have ONLY one version indexed.  No idea what should be done there.

FFFFF- Why are there so many mods from kerbalstuff with crapped up versions?

[x] Science! is a good example.  The KSP-AVC file has only a  "KSP_VERSION" line and that somehow became ksp_version_min

Alright, I think every instance of there being an old promiscuous version when a non-promiscuous newer version exists has been fixed.
Next I'll look for versions where the mod author has actually specified version restrictions that we're not reflecting.

Are we assuming flags will stay safe in perpetuity? Even if the methods for mod flags change (which they shouldn't), it's just an image file being installed and shouldn't have any negative effect.

@plague006 : I think we're pretty safe that flags will remain platform independent. If flags somehow change radically in the future we can re-address then.

AIESAerospace-Unofficial confirmed for 1.0.0.

You missed RealPlume in "4. ksp_version of 1.0 but newer version is more restrictive"
#881

You also missed RemoteTech-Config-RSS in KSP_Min with no KSP-Max -  #906 sorts it out, since RSS now handles it with a ModManager file (much better).

The only 2 outstanding mods are ksp-avc and mini-avc and if there's an issue with those we'll get 1,000 reports per minute anyway.
Calling this complete.