Disappearing cells in merged layout

[lukasc-ubc]

Dear @klayoutmatthias

I had the unfortunate experience of receiving a chip that was manufactured with missing thousands of components. I traced the problem to the merging of layouts I did using KLayout 0.26.5, specifically where (not always) KLayout removed Array Instances (and only kept one of the elements in the array).

Example GDS file:

Here are images of the original GDS: https://www.dropbox.com/s/njerj6fvpjl01n3/EBeam_LukasChrostowski_20200307_2340.gds?dl=1

and screenshot:

Here are the steps to reproduce the problem, which results in the screenshot below:

• open the above GDS
• In the Cell window, right click and Copy, then Deep.
• create a new layout
• Paste
• then notice that one of the Instances disappears.

The disappearing isn't consistent. When I merged thousands of circuits, approximately 50% of them failed.

Also, I just downloaded the latest KLayout (LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg), and the problem persists there too. This is a pretty big problem...

I can also confirm that this wasn't an issue in KLayout 0.26.3 (the Python2 version), as I am fixing my layout using the older working version...

Thank you
Lukas

[klayoutmatthias]

Hi Lukas,

I'm sorry to hear this.

But I'm even more sorry, I can't reproduce it neither on Windows nor Linux (0.26.6). I have created a small movie to show what I did: https://youtu.be/p39kwyZygYs - I followed your instructions without being able to reproduce it.

As these cells probably were PCells maybe the problem is related to this. You're sure you can reproduce the problem with the static cells of the file you uploaded?

Otherwise the problem might be related to Mac build (again?).

Matthias

[lukasc-ubc]

Dear @klayoutmatthias

Thank you for investigating. Too bad this problem only occurs on the Mac version.

I just tried on another Mac computer, running Catalina 10.15.5, using the same Anaconda3 build, LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg. I get the same problem.

The previous computer (MacBook Pro) was running the older Mac OSX, Mojave, 10.14.6.

Note that the GDS I uploaded above does not contain PCells, and is regular GDS.

I saved the GDS as a GDS TXT file, turning off the PCell option: https://www.dropbox.com/s/0siychmpzimvqji/EBeam_LukasChrostowski_20200307_2340.txt?dl=1

I get the same problem.

Digging further, after copying the layout, I saved it as a TXT GDS. https://www.dropbox.com/s/6a76659ih4ke8vw/EBeam_LukasChrostowski_20200307_2340_copied.txt?dl=1

Here is the (problematic) difference between the two files:

AREF 
SNAME TE1550_SubGC_neg31_oxide_WB90
COLROW 1 2 
XY 138000: 103000
138000: 103000
138000: 357000
ENDEL 

AREF 
SNAME TE1550_SubGC_neg31_oxide_WB90
COLROW 1 2 
XY 38000: 103000
38000: 103000
38000: 357000
ENDEL 

AREF 
SNAME TE1550_SubGC_neg31_oxide_WB90
COLROW 1 2 
XY 138000: 103000
138000: 103000
138000: 357000
ENDEL 
SREF 
SNAME TE1550_SubGC_neg31_oxide_WB90
XY 38000: 103000
ENDEL 

For some reasons it is dropping the AREF and turning it into an SREF.

@Kazzz-S: could you please check on your Mac computer if you get this problem?

I also turned on "noisy" debug level while doing the copy and paste operation:

Renamed layout from  to EBeam_LukasChrostowski_20200307_2340.gds
Created layout EBeam_LukasChrostowski_20200307_2340.gds
Loading: started
Loading file: /Users/lukasc/Downloads/EBeam_LukasChrostowski_20200307_2340.gds with technology: EBeam
File read: started
File read: 0 (user) 0 (sys) 0.002 (wall) 0.00M (mem)
Sorting: started
Updating relations: started
Updating relations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Topological sort: started
Topological sort: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Updating bounding boxes: started
Updating bounding boxes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting shapes: started
Sorting shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting instances: started
Sorting instances: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Memory usage per master category:
  Layout info    : 7735 (used) 8132 (reqd)
  Cell info      : 1828 (used) 1828 (reqd)
  Instances      : 608 (used) 608 (reqd)
  Shapes info    : 5556 (used) 7444 (reqd)
  Total          : 15727 (used) 18012 (reqd)
Loading: 0 (user) 0 (sys) 0.006 (wall) 0.00M (mem)
PaintEvent: started
Preparing to draw
Preparing to draw: started
Preparing to draw: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: started
Drawing decorations
Drawing decorations: started
Drawing decorations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Drawing layer: 
Drawing layer: started
Drawing layer: 0.01 (user) 0 (sys) 0.002 (wall) 0.00M (mem)
Cell cache: TE1550_SubGC_neg31_oxide_WB90 (1:r0 *0.00228106852 0,0) 77 x 49 -> 4 hits
Cell cache: ROUND_PATH$3 (1:r0 *0.00228106852 0,0) 53 x 157 -> 2 hits
Cell cache: ROUND_PATH$2 (1:r0 *0.00228106852 0,0) 133 x 293 -> 2 hits
Cell cache: Compact_YBranch_open (1:r180 *0.00228106852 0,0) 37 x 16 -> 2 hits
Cell cache: Compact_YBranch_open (1:r0 *0.00228106852 0,0) 37 x 16 -> 2 hits
Cell cache: EBeam_LukasChrostowski_v5 (2:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: _EBeam_LukasChrostowski_v5 (3:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (4:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (4:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski_v5 (2:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: _EBeam_LukasChrostowski_v5 (3:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (4:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing frames and guiding shapes
Drawing frames and guiding shapes: started
Drawing frames and guiding shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: 0.01 (user) 0 (sys) 0.004 (wall) 0.00M (mem)
PaintEvent: 0.01 (user) 0 (sys) 0.015 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.002 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0.01 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
Created layout L3
Sorting: started
Updating relations: started
Updating relations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Topological sort: started
Topological sort: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting instances: started
Sorting instances: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
PaintEvent: started
Preparing to draw
Preparing to draw: started
Preparing to draw: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: started
Drawing decorations
Drawing decorations: started
Drawing decorations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Drawing frames and guiding shapes
Drawing frames and guiding shapes: started
Drawing frames and guiding shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
PaintEvent: 0.01 (user) 0 (sys) 0.005 (wall) 0.00M (mem)
Sorting: started
Updating relations: started
Updating relations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Topological sort: started
Topological sort: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Updating bounding boxes: started
Updating bounding boxes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting shapes: started
Sorting shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting instances: started
Sorting instances: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting: started
Updating relations: started
Updating relations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Topological sort: started
Topological sort: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Updating bounding boxes: started
Updating bounding boxes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting shapes: started
Sorting shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Sorting instances: started
Sorting instances: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
Sorting: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: started
Preparing to draw
Preparing to draw: started
Preparing to draw: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: started
Drawing decorations
Drawing decorations: started
Drawing decorations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (1:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (1:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (1:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing frames and guiding shapes
Drawing frames and guiding shapes: started
Drawing frames and guiding shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: 0.01 (user) 0.01 (sys) 0.013 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.004 (wall) 0.00M (mem)
PaintEvent: started
Preparing to draw
Preparing to draw: started
Preparing to draw: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: started
Drawing decorations
Drawing decorations: started
Drawing decorations: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0.002 (wall) 0.00M (mem)
Cell cache: Compact_YBranch_open (1:r180 *0.00228106852 0,0) 37 x 16 -> 2 hits
Cell cache: Compact_YBranch_open (1:r0 *0.00228106852 0,0) 37 x 16 -> 2 hits
Cell cache: ROUND_PATH$2 (1:r0 *0.00228106852 0,0) 133 x 293 -> 2 hits
Cell cache: ROUND_PATH$3 (1:r0 *0.00228106852 0,0) 53 x 157 -> 2 hits
Cell cache: TE1550_SubGC_neg31_oxide_WB90 (1:r0 *0.00228106852 0,0) 77 x 49 -> 3 hits
Cell cache: EBeam_LukasChrostowski_v5 (2:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: _EBeam_LukasChrostowski_v5 (3:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (4:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (4:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing layer: 
Drawing layer: started
Drawing layer: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
Cell cache: EBeam_LukasChrostowski_v5 (2:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: _EBeam_LukasChrostowski_v5 (3:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Cell cache: EBeam_LukasChrostowski.gds_20200307_2340 (4:r0 *0.00228106852 0,0) 1383 x 938 -> 1 hits
Drawing frames and guiding shapes
Drawing frames and guiding shapes: started
Drawing frames and guiding shapes: 0 (user) 0 (sys) 0 (wall) 0.00M (mem)
Redrawing: 0 (user) 0.01 (sys) 0.003 (wall) 0.00M (mem)
PaintEvent: 0.01 (user) 0.01 (sys) 0.013 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.002 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.001 (wall) 0.00M (mem)
PaintEvent: started
PaintEvent: 0 (user) 0 (sys) 0.002 (wall) 0.00M (mem)

Nothing too obvious here, except for the lines that show Cell cache: TE1550_SubGC_neg31_oxide_WB90 with 4 hits, then down to 3 hits.

[lukasc-ubc]

@klayoutmatthias @Kazzz-S

My student (Hossam) and I found that the problem does not exist on the version HW-klayout-0.26.6-macOS-Catalina-1-qt5Brew-RsysPhb37.dmg (Catalina (10.15) HomeBrew-Python3 included - experimental).

The version that I found the problem in is LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg (Catalina (10.15) Anaconda3-environment based - experimental / needs the corresponding development environment).

I haven't tried the other Mac OSX builds, especially not the Python 2 ones, but I suspect that they work.

[Kazzz-S]

Dear @lukasc-ubc,

Here are the steps to reproduce the problem, which results in the screenshot below:

• open the above GDS
• In the Cell window, right click and Copy, then Deep.
• create a new layout
• Paste
• then notice that one of the Instances disappears.

I have followed the above steps with EBeam_LukasChrostowski_20200307_2340.gds using the four packages below.

1. HW-klayout-0.26.6-macOS-Catalina-1-qt5Brew-RsysPhb37.dmg (embedded Homebrew Python 3.x)
2. LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg (shares Anaconda3 env.)
3. LW-klayout-0.26.6-macOS-Catalina-1-qt5Brew-Rhb27Phb37.dmg (shares Homebrew env.)
4. ST-klayout-0.26.6-macOS-Catalina-1-qt5MP-RsysPsys.dmg (OS-bundled Python 2.7)

I have repeated several times; however, unfortunately, I could not reproduce the problem in all four.
The reason could be that I've used the same machine on which I built those packages.

Regards,
Kazzz-S

[Kazzz-S]

Dear @lukasc-ubc,

I've tested the two packages below on virtual machines that are different from the real machine used for building the packages. The problem did not reproduce, either.

• LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg (shares Anaconda3 env.)
• LW-klayout-0.26.6-macOS-Catalina-1-qt5Brew-Rhb27Phb37.dmg (shares Homebrew env.)

Regards,
Kazzz-S

[klayoutmatthias]

Dear all, @Kazzz - thanks a lot for testing too! I've tried to do a fresh build on the Catalina (10.15.1) VirtualBox I was also using for debugging. No luck either. The configuration I used was 0.26.6 with Qt: Qt5Brew, Ruby: sys, Python: sys. I'll try LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg now. Apart from the empirical search I went through the changes from 0.26.3 to 0.26.6 without finding anything that could explain the vanishing of AREFs. Technically that's a loss of a particular C++ object, Often a machine dependent bug is an indication of some code weakness (e.g. non-initialized storage or memory corruption). So I'm interested in debugging the topic. On the other hand, I've had a couple of compiler issues creating similar problems on Windows already. I'll keep looking. Matthias

…

On 19.06.20 13:41, Kazunari Sekigawa wrote: Dear @lukasc-ubc <https://github.com/lukasc-ubc>, I've tested the two packages below on virtual machines that are different from the real machine used for building the packages. The problem did not reproduce, either. * LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg (shares Anaconda3 env.) * LW-klayout-0.26.6-macOS-Catalina-1-qt5Brew-Rhb27Phb37.dmg (shares Homebrew env.) Regards, Kazzz-S — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#589 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEHQCOKRRE72RQBYLD2XMLRXNFFLANCNFSM4OCCWL3Q>.

[klayoutmatthias]

Update: I can reproduce the problem with the downloaded LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg

Next step is to produce my own binary with Anaconda.

BTW: I faced some installation issues because Anaconda by default will install into /Users/matthias/opt/anaconda3 and the KLayout binary expects it at /Applications/anaconda3. Creating a link solved the issue. This is for the records in case someone else faces this issue.

Matthias

[Kazzz-S]

Dear @klayoutmatthias,

Update: I can reproduce the problem with the downloaded LW-klayout-0.26.6-macOS-Catalina-1-qt5Ana3-Rana3Pana3.dmg
Next step is to produce my own binary with Anaconda.

Thank you for testing with Anaconda3.

BTW: I faced some installation issues because Anaconda by default will install into /Users/matthias/opt/anaconda3 and the KLayout binary expects it at /Applications/anaconda3. Creating a link solved the issue. This is for the records in case someone else faces this issue.

Yes, this symbolic link is required to build the tool, too.
I'll update the associated document accordingly.

Regards,
Kazzz-S

[lukasc-ubc]

Outstanding. Having one other person be able to reproduce the problem (which I have on two machines) confirms that its not just me. Thank you both for looking into this. Ensuring the tool is bug-free on such a key functionality (AREFs) is important.

[klayoutmatthias]

Sure .. AREFs have to work.

It's never a person causing an issue, those are always the conditions. I'm just facing too many combinations to stay in control of them. With Linux I can deploy a hive of docker images for testing, with Windows there are less variations. MacOS is dark matter to me.

I'm trying to debug now, but Anaconda is not providing debug versions of the Qt libraries ...

Matthias

[lukasc-ubc]

Thanks @klayoutmatthias, I am grateful for your support for Mac OSX. I can appreciate it is not easy especially now with the many versions such as LW, HW, Brew, Anaconda3.

fyi. in my edX course, we had about 100 design submissions. About 20% were Mac OSX, 80% Windows, and a couple using Linux.

[klayoutmatthias]

Dear @lukasc-ubc and @Kazzz,

I got to the spot, but it's not easy.

It looks to be one the weird RTTI issues. This is the line which fails:

dbArray.h, 268++:

    basic_repository::iterator f = r->find ((ArrayBase *) &base);
    if (f != r->end ()) {
      return dynamic_cast <basic_array<Coord> *> (*f);    //  <--- "dynamic_cast" returns 0 but it must not
    } else {
      basic_array<Coord> *bb = base.clone ();
      bb->in_repository = true;
      r->insert (bb);
      return bb;
    }
  }

RTTI in shared objects is an old nemesis of mine.

C++ keeps type information in a thing called vtable to implement polymorphism. The vtable tells an object where to actually find the implementation of a virtual method. This way, derived classes can provide different implementations for a virtual method by employing a different version of the vtable.

As the vtable is not modified, it's usually not created at run time but statically at compile time. The C++ object now keeps a pointer to this static table and uses this pointer to find the function pointers it needs to use when a virtual method is called. This works nicely so far.

But the vtable is also used to identify a type. The value of the vtable pointer can basically be used as an efficient class identifier. So if you want to know whether an object is of a particular type you just need to compare the vtable pointer against the one of the class you look for. This is a very efficient operation and one of the implementation details that make C++ that efficient. This concept is called RTTI (run time type information).

dynamic_cast takes this concept somewhat further: by looking not only for a specific pointer but also for the vtable pointers from derived objects, dynamic_cast can decide whether a specific object is a subclass of the requested one and cast the object pointer properly or return 0 if this is not the case.

The whole thing works well in single-binary scenarios. In shared object scenarios however, the C++ runtime needs to play dirty tricks. The reason is that in these scenarios, the same class instantiated in different shared objects has different vtable pointers. So just comparing vtable pointers for the purpose of identifying classes isn't sufficient anymore. To maintain the efficiency, the compilers have to do some magic and this is when trouble starts. In our case this magic somehow fails and the dynamic_cast delivers crap.

I've had such cases in the past more than once. Without deep assembler-level debugging it's difficult to pinpoint the true cause, but one big issue is ABI incompatibility of shared objects. This means when mixing shared objects from different compilers there is a certain chance that the RTTI tables of the different compile units are not compatible and this problem happens. Specifically Qt libraries are susceptible to this issue and I'm kind of suspecting that taking Qt from Anaconda is causing the problem here. If Anaconda Qt is made with a different compiler or version, the ABI might not be compatible. This would explain why other combinations work.

For the solution I'm not sure what to propose. It may be possible to fix the particular line by somehow avoiding a dynamic_cast. But RTTI is that basic - we surely will see other issues at well. So right now, my conclusion is only to discourage use of the Anaconda Qt variant. Still we don't have a proof if there is a stable package.

I've tried to run the testsuite with the result of many fails (331 failing tests, 313 on my good variant with HomeBrew/system Ruby+Python). There seem to be some systematic issues in the hierarchical data processing domain which is responsible for the majority of the fails the problem we discuss here. I need to see if I can fix this (#493).

After this I can check whether the testsuite is susceptible to our issue here after I fixed the systematic issues. If that is, continuous integration with automatic test suite runs was a way to indicate the quality of a package - at least on the same level than Linux or Windows.

There is Travis offering MacOS support for continuous integration, but the usable (unlimited in terms of CPU) variant isn't for free and I don't have the resources to support another platform myself.

I need to say that debugging on MacOS is really painful, specifically with the VirtualBox VM. This only gives me a 640x480 screen and the keyboard and mouse mapping is driving me mad (XCode won't give me the backslash character for example, no chance). I don't want to continue this longer than necessary.

Matthias