i'm just testing out a simple layer instead of the callback stuff we had before
@kephale i am getting
$ python scripts/python_basic.py
Traceback (most recent call last):
File "scripts/python_basic.py", line 43, in <module>
HashMap = jimport('java.util.HashMap')
File "C:\Users\ulrik\Software\miniconda3\envs\sciview\lib\site-packages\scyjava\__init__.py", line 150, in jimport
start_jvm()
File "C:\Users\ulrik\Software\miniconda3\envs\sciview\lib\site-packages\scyjava\__init__.py", line 45, in start_jvm
_, workspace = jgo.resolve_dependencies(
File "C:\Users\ulrik\Software\miniconda3\envs\sciview\lib\site-packages\jgo\jgo.py", line 426, in resolve_dependencies
os.makedirs(workspace, exist_ok=True)
File "C:\Users\ulrik\Software\miniconda3\envs\sciview\lib\os.py", line 223, in makedirs
mkdir(name, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\ulrik\\.jgo\\net.imagej\\imagej\\2.1.0+graphics.scenery-scenery-5de0b1e+ome-formats-bsd-6.1.1+ome-formats-gpl-6.1.1+org.jetbrains.kotlin-kotlin-stdlib-jdk8-1.4.20+org.jetbrains.kotlinx-kotlinx-coroutines-core-1.3.9+sc.fiji-bigdataviewer-core-10.1.1-SNAPSHOT+sc.iview-sciview-92add67'
(the jgo folder is empty)
(python 3.8.8, on miniconda, just fyi)
jgo is supposed to link files from m2 into the jgo directory
but i'll note that it was insanely slow to fetch the dependencies
especially given that they were already present in my m2
15 minutes or so
but your error looks like some os specific issue since it is failing on a mkdir call
i created that dir manually but it still fails
aha, found the issue
Error: Current working directory has a path longer than allowed for a
Win32 working directory.
okay, there seems to be a workaround: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd
now i get a hard crash in the c runtime :-D
nevertheless, there's a cpp exception uncaught:
Stack: [0x0000001459600000,0x00000014597f0000], sp=0x00000014597e7630, free space=1949k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [KERNELBASE.dll+0x34b59]
C [VCRUNTIME140.dll+0x4411]
C [ntdll.dll+0xa1406]
C [_jpype.cp38-win_amd64.pyd+0x392ce]
C [_jpype.cp38-win_amd64.pyd+0x3d3d2]
C [_jpype.cp38-win_amd64.pyd+0x32585]
C 0x000001abcfb1ef97
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.jpype.manager.TypeFactoryNative.newWrapper(JJ)V+0
j org.jpype.JPypeContext.newWrapper(J)V+16
v ~StubRoutines::call_stub
j org.jpype.manager.TypeFactoryNative.newWrapper(JJ)V+0
j org.jpype.JPypeContext.newWrapper(J)V+16
v ~StubRoutines::call_stub
j org.jpype.manager.TypeFactoryNative.newWrapper(JJ)V+0
j org.jpype.JPypeContext.newWrapper(J)V+16
v ~StubRoutines::call_stub
siginfo: EXCEPTION_UNCAUGHT_CXX_EXCEPTION (0xe06d7363), ExceptionInformation=0x0000000019930520 0x00000014597ec660 0x00007ff99217e7d0 0x00007ff992100000
i wonder if it could be the jvm version as well
and the jvm is the 11 azul jdk it's probably getting via conda
7 replies
and i'd argue that probably most or even all of scenery's deps need to be transitive
@kephale it should be possible to use the versions of @elect86's PRs in the python scripts too, right?
just essentially replace the commit hashes with those from the PRs
but i'd love to have it working with the gradle-based PRs
the ageratum one?
which is maven based
gradle has yet to work on update sites
due to the transitive dep stuff
which is another reason that i was trying to get this working in python since it seems to reproduce the transitive dep issue without requiring fiddling with update sites
so i guess getting it going on gradle has ultrahigh prio now :D
thats the idea
it is managed here https://github.com/scenerygraphics/sciview-update-sites
and when ageratum is stable we archive it to a branch and move on
gradle has so many obstacles that we needed something to actually work
glad that ageratum is finally being tested on windows