- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 17 2020
platform is output with Sys.info(); linux and Mac systems are equal and windows may differ
good idea!
otherwise you could use a platform dependent expect_equal but I think your idea is sufficient
After investing several hour trying different encodings, e.g. using raw strings, I still don't find a way to make this work. I also don't see a way of changing the source message, because it's originating from another package.
We should definitely keep it in the README.
would mention it there at least though because bootstrapping may be time consuming
don't think its necessary. there is anyway ordering applied to it in later stages.
otherwise ranking step (rank.aggregated.list()) could always do the ordering directly (then the test would check whether ordering is working). As mentioned before I avoided such change before the release because of (very unlikely) risk of breaking something in the first level hierarchy
Is the order of the rows relevant in any processing step? If not, the tests can be removed. Currently, I don't see a way making it work for both systems I have available for testing (Win10, R 3.6.3 and Ubuntu 18.04, R 4.0.3).
I do see those as well on Mac
R 4.0.2.
testthat previously 2.3.2, now 3.0.1.
the issue is however not connected to test_that I see that in the first 2 tests in aggregate-then-rank the ordering in the data set is not used but sorted
The platform might not be the (only) reason.
@wiesenfa: Which version of R and testthat are you using?
Ok, we can keep them in this release.
Discussed with @wiesenfa that this issue is not critical for release v1.0.
Dec 16 2020
Recap: The initially chosen license (GPLv3) is not compatible with GPLv2 only licenses of dependencies (e.g. ggplot2, relations)
as name property, the name of the RT node is provided correctly.
I created a working example with Pic3D for comparison.
Looking at both caaaaa.xml files, the only difference I notice is that the corrupted one is encoded with UTF-8 but otherwise it looks similar (as far as I see).
Which node is it? you can look up the name if you look into caaaaa.xml
<?xml version="1.0" encoding="UTF-8"?>
<Version Writer="C:\Development\MITK-dev\src\Modules\SceneSerialization\src\mitkSceneIO.cpp" Revision="$Revision: 17055 $" FileVersion="1"/>
sorry just saw the message. I put it in the shared folder.
Dec 15 2020
could you provied (e.g. via nextcloud) such an invalid scene file?
As Ralf pointed out, it is actually not related to the GenericProperty as such but it seems that the scene does not even contain any nrrd files after saving and that is why it breaks
Dec 14 2020
seems to not fail on windows machines. but does on my Mac (and thus might also on linux). minor issue, defer to post 1.0.0
Do you have still problems with crashes? If yes, this is almost certainly not due to the GenericProperty thing, as they have no relevance for dose visualization and scenes without dose do not crash but also cannot load the GenericProperty.
GenericProperty associated to key 'MITK.IO.reader.DICOM.PixelSpacingInterpretation'
GenericProperty associated to key 'MITK.IO.reader.DICOM.ReaderImplementationLevel'
GenericProperty associated to key 'dicomseriesreader.PixelSpacingInterpretation'
GenericProperty associated to key 'dicomseriesreader.ReaderImplementationLevel' still need to be changed
The idea of the web app is to lower the entry level for users that are not familiar with and/or don't want to install R (as this is already a hurdle for some of them).
Closed. @neher or who ever might stumple upon the prolem again, is welcome to open it again and provide data. :)
Since solution 1 worked well for me and seems to be more generic, I would vote for 1.
In T22412#93055, @kislinsk wrote:Also crashes with normal 4D images. In Multilabel segmentation 2D region crowing, too.
Can D447 landed and this issue closed? If nothing speaks against it, it would be good, before I turning the rest of the seg tools upside down. Thanks.