Re: [Therion] A wtherion update
Hello Nice work! I have an idea, how about replacing XTherion with a Visual Studio Code extension? Let's skip the part where we develop a whole new editor, we could just use an existing editor, and enhance it with a capability to run Therion compilation and with an integrated wtherion for scrap editing. Do you think it would be possible to run wtherion in such a way? Matěj po 15. 4. 2024 v 22:26 odesílatel Csongor Zih napsal: > > Hi everyone! > > I have an update to share regarding wtherion, which you hopefully > remember is my project for a web-based Therion map editor to replace > XTherion's map editing capabilities: > https://github.com/daem-on/wtherion > > I just spent the last two weeks rewriting the UI of wtherion, which > was originally a fork of a vector editing application, migrating the > parts that used jQuery to Vue. The canvas library and most of the > editing logic are the same, this change just means the editor UI can > be even more dynamic, complex and useful than before. This eliminated > a lot of unnecessary or overly complex code left from the vector > editor, and I hope in the future this will make it easier to maintain > and add new features to. > > Some of the more visible changes include: > - New layout and new UI styles > - Shortcuts icons for common actions > - Keybinds can be configured (this is not persisted yet) > - All select lists (including points/symbols) have preview images > - UI language can be changed at runtime > - New rendering capabilities > > This last one I'm especially happy about, it's a step towards actual > WYSIWYG editing, although that is not planned for this project. > Currently you can see, in real time, while editing, what your 'slope', > 'pit' or 'overhang' lines might look like when compiled. The main > limiting factor here is performance, since I don't know how capable > the average user's hardware will be, I tried to keep it optimised, and > I added a toggle for it in the toolbar. > > I'm planning on releasing a 1.0 version of wtherion in the future, but > I would like to hear feedback on this development version, which can > be reached at beta.wtherion.daemonw.com (this is also linked in the > GitHub repo). If you have suggestions on how it should work > differently, if it's not working well for your workflow, or if you > find a bug, please let me know here, or create an issue on GitHub. > > I can't make any guarantee as to the timeline of development, or how > quickly I'll respond. Admittedly, I haven't worked on this project > very actively in the last two years, but right now I want to spend > more time on it. > > The scope of the project hasn't really changed, but I'd be interested > to work on other projects that plan to replace the whole of XTherion, > or even replace text based editing. > > Csongor > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Problems building latest Therion in Fedora 37: missing pdfetex.ini
Hi, I see that my response was not delivered due to the problem with the mailing list. Try to just reinstall texlive and all related packages. In my previous comment at https://github.com/therion/therion/pull/474#issuecomment-1353245276 you can see that I had to install texlive packages separately, because otherwise texlive would end up being broken. Matěj čt 11. 5. 2023 v 23:53 odesílatel Rodrigo Severo via Therion napsal: > > Hi, > > > I am having trouble building ThBook in latest Therion in Fedora 37. I am > getting the following error: > > [ 98%] Generating thbook.pdf > This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021) (preloaded > format=pdftex) > restricted \write18 enabled. > > kpathsea: Running mktexfmt pdftex.fmt > mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence > order): > mktexfmt: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf > mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing > changes: > mktexfmt: /home/rodrigo/.texlive2021/texmf-config/web2c/fmtutil.cnf > mktexfmt [INFO]: writing formats under > /home/rodrigo/.texlive2021/texmf-var/web2c > mktexfmt [INFO]: --- remaking pdftex with pdftex > mktexfmt [WARNING]: inifile pdfetex.ini for pdftex/pdftex not found. > mktexfmt [INFO]: not selected formats: 19 > mktexfmt [INFO]: failed to build: 1 (pdftex/pdftex) > > To my untrained eyes it seems that a "pdfetex.ini" file is missing. > > Any ideas on how to solve this issue? > > > Regards, > > Rodrigo Severo > > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Problem compiling Therion 6.1.7 on Fedora 38
Hi, I see that my response was not delivered due to the problem with the mailing list, but for the record I'll reply again now. Arithmetic problems now should be fixed in the latest release, only 32-bit builds on Windows were affected. Matěj po 15. 5. 2023 v 18:56 odesílatel Bill Gee napsal: > > Arithmetic problems?!?! If it's not one thing, it's another! > > Thanks for your efforts. I will be patient and see how things develop. > For now I have a working installation of Therion 6.1.6, and I have no > active cave map projects. > > === > Bill Gee > > On 5/15/23 10:38, Matěj Plch wrote: > > It should be fixed in the master branch now, the problem was caused by > > the new version of GCC 13.1. However, with the same compiler there is > > an issue with floating-point arithmetics, so Therion now computes > > different results, we are investigating how to fix this. > > > > so 13. 5. 2023 v 0:12 odesílatel Matěj Plch napsal: > >> > >> Looks like there are for some reason missing includes, I will fix and test > >> this on Fedora over the weekend. > >> > >> Dne pá 12. 5. 2023 20:12 uživatel Bill Gee napsal: > >>> > >>> Thanks! That made a difference. I still get an error, but it happens > >>> later in the process. This happens after a bunch of other g++ commands > >>> have run. > >>> > >>> == Paste text = > >>> g++ -c -DIMG_API_VERSION=1 -Wall -DTHLINUX -O2 -DPROJ_VER=9 > >>> -I/usr/include -Iextern -Iextern/shapelib -Iextern/quickhull -std=c++17 > >>> -o thdb1d.o thdb1d.cxx > >>> In file included from extern/quickhull/QuickHull.hpp:10, > >>>from thdb1d.cxx:53: > >>> extern/quickhull/Structs/Mesh.hpp:41:30: error: ‘uint8_t’ in namespace > >>> ‘std’ does not name a type; did you mean ‘wint_t’? > >>> 41 | std::uint8_t > >>> m_isVisibleFaceOnCurrentIteration : 1; > >>> | ^~~ > >>> | wint_t > >>> extern/quickhull/Structs/Mesh.hpp:42:30: error: ‘uint8_t’ in namespace > >>> ‘std’ does not name a type; did you mean ‘wint_t’? > >>> 42 | std::uint8_t m_inFaceStack : 1; > >>> | ^~~ > >>> | wint_t > >>> extern/quickhull/Structs/Mesh.hpp:43:30: error: ‘uint8_t’ in namespace > >>> ‘std’ does not name a type; did you mean ‘wint_t’? > >>> 43 | std::uint8_t > >>> m_horizonEdgesOnCurrentIteration : 3; // Bit for each half edge assigned > >>> to this face, each being 0 or 1 depending on whether the edge belongs to > >>> horizon edge > >>> | ^~~ > >>> | wint_t > >>> extern/quickhull/Structs/Mesh.hpp: In constructor > >>> ‘quickhull::MeshBuilder::Face::Face()’: > >>> extern/quickhull/Structs/Mesh.hpp:50:42: error: class > >>> ‘quickhull::MeshBuilder::Face’ does not have any field named > >>> ‘m_isVisibleFaceOnCurrentIteration’ > >>> 50 | > >>> m_isVisibleFaceOnCurrentIteration(0), > >>> | > >>> ^ > >>> extern/quickhull/Structs/Mesh.hpp:51:42: error: class > >>> ‘quickhull::MeshBuilder::Face’ does not have any field named > >>> ‘m_inFaceStack’ > >>> 51 | m_inFaceStack(0), > >>> | ^ > >>> extern/quickhull/Structs/Mesh.hpp:52:42: error: class > >>> ‘quickhull::MeshBuilder::Face’ does not have any field named > >>> ‘m_horizonEdgesOnCurrentIteration’ > >>> 52 | > >>> m_horizonEdgesOnCurrentIteration(0) > >>> | > >>> ^~~~ > >>> make: *** [Makefile:151: thdb1d.o] Error 1 > >>> End of pasted text > >>> > >>> When I built therion 6.1.6 on Fedora 37, I used cmake instead of make. > >>> Trying that process, I get yet another error! > >>> > >>> == Begin pasted text === > >>> /home/bgee/Installs/therion-6.1.7/loch/lxFile.cxx: In member function > >>> ‘bool lxFile:
Re: [Therion] Problem compiling Therion 6.1.7 on Fedora 38
It should be fixed in the master branch now, the problem was caused by
the new version of GCC 13.1. However, with the same compiler there is
an issue with floating-point arithmetics, so Therion now computes
different results, we are investigating how to fix this.
so 13. 5. 2023 v 0:12 odesílatel Matěj Plch napsal:
>
> Looks like there are for some reason missing includes, I will fix and test
> this on Fedora over the weekend.
>
> Dne pá 12. 5. 2023 20:12 uživatel Bill Gee napsal:
>>
>> Thanks! That made a difference. I still get an error, but it happens
>> later in the process. This happens after a bunch of other g++ commands
>> have run.
>>
>> == Paste text =
>> g++ -c -DIMG_API_VERSION=1 -Wall -DTHLINUX -O2 -DPROJ_VER=9
>> -I/usr/include -Iextern -Iextern/shapelib -Iextern/quickhull -std=c++17
>> -o thdb1d.o thdb1d.cxx
>> In file included from extern/quickhull/QuickHull.hpp:10,
>> from thdb1d.cxx:53:
>> extern/quickhull/Structs/Mesh.hpp:41:30: error: ‘uint8_t’ in namespace
>> ‘std’ does not name a type; did you mean ‘wint_t’?
>> 41 | std::uint8_t
>> m_isVisibleFaceOnCurrentIteration : 1;
>>| ^~~
>>| wint_t
>> extern/quickhull/Structs/Mesh.hpp:42:30: error: ‘uint8_t’ in namespace
>> ‘std’ does not name a type; did you mean ‘wint_t’?
>> 42 | std::uint8_t m_inFaceStack : 1;
>>| ^~~
>>| wint_t
>> extern/quickhull/Structs/Mesh.hpp:43:30: error: ‘uint8_t’ in namespace
>> ‘std’ does not name a type; did you mean ‘wint_t’?
>> 43 | std::uint8_t
>> m_horizonEdgesOnCurrentIteration : 3; // Bit for each half edge assigned
>> to this face, each being 0 or 1 depending on whether the edge belongs to
>> horizon edge
>>| ^~~
>>| wint_t
>> extern/quickhull/Structs/Mesh.hpp: In constructor
>> ‘quickhull::MeshBuilder::Face::Face()’:
>> extern/quickhull/Structs/Mesh.hpp:50:42: error: class
>> ‘quickhull::MeshBuilder::Face’ does not have any field named
>> ‘m_isVisibleFaceOnCurrentIteration’
>> 50 |
>> m_isVisibleFaceOnCurrentIteration(0),
>>|
>> ^
>> extern/quickhull/Structs/Mesh.hpp:51:42: error: class
>> ‘quickhull::MeshBuilder::Face’ does not have any field named
>> ‘m_inFaceStack’
>> 51 | m_inFaceStack(0),
>>| ^
>> extern/quickhull/Structs/Mesh.hpp:52:42: error: class
>> ‘quickhull::MeshBuilder::Face’ does not have any field named
>> ‘m_horizonEdgesOnCurrentIteration’
>> 52 |
>> m_horizonEdgesOnCurrentIteration(0)
>>|
>> ^~~~
>> make: *** [Makefile:151: thdb1d.o] Error 1
>> End of pasted text
>>
>> When I built therion 6.1.6 on Fedora 37, I used cmake instead of make.
>> Trying that process, I get yet another error!
>>
>> == Begin pasted text ===
>> /home/bgee/Installs/therion-6.1.7/loch/lxFile.cxx: In member function
>> ‘bool lxFile::HasAnyWalls()’:
>> /home/bgee/Installs/therion-6.1.7/loch/lxFile.cxx:1345:30: error: no
>> match for ‘operator!=’ (operand types are ‘lxFileSize’ and ‘’)
>> 1345 | if (shi->m_sectionType != LXFILE_SHOT_SECTION_NONE) {
>>| ~~ ^~
>>|||
>>|lxFileSize
>> /home/bgee/Installs/therion-6.1.7/loch/lxMath.h:77:6: note: candidate:
>> ‘bool operator!=(const lxVec&, const lxVec&)’
>> 77 | bool operator != ( const lxVec& p, const lxVec& q );
>>| ^~~~
>> /home/bgee/Installs/therion-6.1.7/loch/lxMath.h:77:33: note: no known
>> conversion for argument 1 from ‘lxFileSize’ to ‘const lxVec&’
>> 77 | bool operator != ( const lxVec& p, const lxVec& q );
>>|~^
>> make[2]: *** [loch/CMakeFiles/common-utils.dir/build.make:76:
>> loch/CMakeFiles/common-utils.dir/lxFile.cxx.o] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:3821:
>> loch/CMakeFiles/common-utils.dir/all] Error 2
>> make: *** [Makefile:146: all] Error 2
>>
>> === End pasted text =
Re: [Therion] Problem compiling Therion 6.1.7 on Fedora 38
Looks like there are for some reason missing includes, I will fix and test
this on Fedora over the weekend.
Dne pá 12. 5. 2023 20:12 uživatel Bill Gee napsal:
> Thanks! That made a difference. I still get an error, but it happens
> later in the process. This happens after a bunch of other g++ commands
> have run.
>
> == Paste text =
> g++ -c -DIMG_API_VERSION=1 -Wall -DTHLINUX -O2 -DPROJ_VER=9
> -I/usr/include -Iextern -Iextern/shapelib -Iextern/quickhull -std=c++17
> -o thdb1d.o thdb1d.cxx
> In file included from extern/quickhull/QuickHull.hpp:10,
> from thdb1d.cxx:53:
> extern/quickhull/Structs/Mesh.hpp:41:30: error: ‘uint8_t’ in namespace
> ‘std’ does not name a type; did you mean ‘wint_t’?
> 41 | std::uint8_t
> m_isVisibleFaceOnCurrentIteration : 1;
>| ^~~
>| wint_t
> extern/quickhull/Structs/Mesh.hpp:42:30: error: ‘uint8_t’ in namespace
> ‘std’ does not name a type; did you mean ‘wint_t’?
> 42 | std::uint8_t m_inFaceStack : 1;
>| ^~~
>| wint_t
> extern/quickhull/Structs/Mesh.hpp:43:30: error: ‘uint8_t’ in namespace
> ‘std’ does not name a type; did you mean ‘wint_t’?
> 43 | std::uint8_t
> m_horizonEdgesOnCurrentIteration : 3; // Bit for each half edge assigned
> to this face, each being 0 or 1 depending on whether the edge belongs to
> horizon edge
>| ^~~
>| wint_t
> extern/quickhull/Structs/Mesh.hpp: In constructor
> ‘quickhull::MeshBuilder::Face::Face()’:
> extern/quickhull/Structs/Mesh.hpp:50:42: error: class
> ‘quickhull::MeshBuilder::Face’ does not have any field named
> ‘m_isVisibleFaceOnCurrentIteration’
> 50 |
> m_isVisibleFaceOnCurrentIteration(0),
>|
> ^
> extern/quickhull/Structs/Mesh.hpp:51:42: error: class
> ‘quickhull::MeshBuilder::Face’ does not have any field named
> ‘m_inFaceStack’
> 51 | m_inFaceStack(0),
>| ^
> extern/quickhull/Structs/Mesh.hpp:52:42: error: class
> ‘quickhull::MeshBuilder::Face’ does not have any field named
> ‘m_horizonEdgesOnCurrentIteration’
> 52 |
> m_horizonEdgesOnCurrentIteration(0)
>|
> ^~~~
> make: *** [Makefile:151: thdb1d.o] Error 1
> End of pasted text
>
> When I built therion 6.1.6 on Fedora 37, I used cmake instead of make.
> Trying that process, I get yet another error!
>
> == Begin pasted text ===
> /home/bgee/Installs/therion-6.1.7/loch/lxFile.cxx: In member function
> ‘bool lxFile::HasAnyWalls()’:
> /home/bgee/Installs/therion-6.1.7/loch/lxFile.cxx:1345:30: error: no
> match for ‘operator!=’ (operand types are ‘lxFileSize’ and ‘ enum>’)
> 1345 | if (shi->m_sectionType != LXFILE_SHOT_SECTION_NONE) {
>| ~~ ^~
>|||
>|lxFileSize
> /home/bgee/Installs/therion-6.1.7/loch/lxMath.h:77:6: note: candidate:
> ‘bool operator!=(const lxVec&, const lxVec&)’
> 77 | bool operator != ( const lxVec& p, const lxVec& q );
>| ^~~~
> /home/bgee/Installs/therion-6.1.7/loch/lxMath.h:77:33: note: no known
> conversion for argument 1 from ‘lxFileSize’ to ‘const lxVec&’
> 77 | bool operator != ( const lxVec& p, const lxVec& q );
>|~^
> make[2]: *** [loch/CMakeFiles/common-utils.dir/build.make:76:
> loch/CMakeFiles/common-utils.dir/lxFile.cxx.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3821:
> loch/CMakeFiles/common-utils.dir/all] Error 2
> make: *** [Makefile:146: all] Error 2
>
> === End pasted text ===
>
> ===
> Bill Gee
>
> On 5/12/23 12:40, Matěj Plch wrote:
> > Hi, Therion 6.1.7 does not include internal copy of fmt library, you
> > need to install package fmt-devel.
> >
> > Dne pá 12. 5. 2023 17:03 uživatel Bill Gee > <mailto:b...@campercaver.net>> napsal:
> >
> > I gave it a shot today to see if I could duplicate Rodrigo's
> > problem. I
> > got a completely different error:
> >
> > ===
> > [bgee@main2 build]$ cmake ..
> > CMake Error at cmake/Depende
Re: [Therion] Problem compiling Therion 6.1.7 on Fedora 38
Hi, Therion 6.1.7 does not include internal copy of fmt library, you need to install package fmt-devel. Dne pá 12. 5. 2023 17:03 uživatel Bill Gee napsal: > I gave it a shot today to see if I could duplicate Rodrigo's problem. I > got a completely different error: > > === > [bgee@main2 build]$ cmake .. > CMake Error at cmake/Dependencies.cmake:8 (find_package): >By not providing "Findfmt.cmake" in CMAKE_MODULE_PATH this project has >asked CMake to find a package configuration file provided by "fmt", but >CMake did not find one. > >Could not find a package configuration file provided by "fmt" with any > of >the following names: > > fmtConfig.cmake > fmt-config.cmake > >Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set > "fmt_DIR" >to a directory containing one of the above files. If "fmt" provides a >separate development package or SDK, be sure it has been installed. > Call Stack (most recent call first): >CMakeLists.txt:18 (include) > === > > This is Fedora 38. The compile of 6.1.6 on Fedora 37 worked correctly > for me. 6.1.6 still works after the upgrade to Fedora 38. I did not > recompile it. > > > > -- > === > Bill Gee > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion > ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
Hi, I think that the problem is caused by this line: rv.prjname = thcs_get_label(params).c_str(); because rv.prjname now contains a pointer to a temporary (and already destroyed) string. st 14. 10. 2020 v 23:04 odesílatel Benedikt Hallinger napsal: > > I just made a new issue ticket: > https://github.com/therion/therion/issues/278 > > > Am 2020-10-14 22:53, schrieb Benedikt Hallinger: > > Hi there, > > i performed a git bisect (the very first in my lifetime, and that is > > really a nice and easy tool to search such things!!!). > > > > The commits at and before c7d41d9 compiled the cave sucessfully 10 of > > 10 times. > > > > 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit > > commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 > > Author: mbudaj > > Date: Wed Aug 19 07:25:53 2020 +0200 > > > > dynamically load EPSG/ESRI labels in Proj>=6 > > > > https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 > > > > This compiles unstable like described before. > > > > > > > > Am 2020-10-14 22:32, schrieb Wookey: > >> On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote: > >>> OK, now i got something. > >>> > >>> Guess what - one of about 5 compiles runs trough. > >>> This leads me to think that there is a race condition or something > >>> else > >>> somewhere, overwriting memory of the to-be-checked string. > >>> I'm pretty sure now that this is not a problem with the dataset per > >>> se, but > >>> some memory issue of the compiled therion program. > >>> > >>> The following pattern resulted in several runs with 5.5.2 (n=failed, > >>> y=ok): > >>> nnnynnynnynynynynnny > >> > >> Oh dear. This could be fun to track down > >> > >> Better check 5.5.1 always works, not just more often. But if it does > >> then careful examination of what changed is in order. Maybe send some > >> others the dataset to see who can reproduce (windows/linux/macOS)? > >> > >> Wookey > >> ___ > >> Therion mailing list > >> Therion@speleo.sk > >> https://mailman.speleo.sk/listinfo/therion > > ___ > > Therion mailing list > > Therion@speleo.sk > > https://mailman.speleo.sk/listinfo/therion > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
