You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello there @Teknomancer! ("BiPolar" here, from the old BeShare days)
There was some comments regarding BeConverter over the Haiku forums, and that prompted me to try to build BeConverter under Haiku beta4 (64 bits).
I've noticed that there seems to be no makefiles/BeIDE projects/etc, so I've added a generic makefile-engine, and started to do minor patches trying to make it build.
But the last error is due to the missing implementation of the things defined in XEvaluator.h. That I can't easily patch :-D
If you ever find the time/will to search again among your backups... it would be nice if you could find the missing pieces!
Thanks in advance! And nice to contact you again after SO many years!
I tried searching the backup I had and can't seem to find the missing file.
Looks like it might need to be re-written. It's a bit of work but should be doable. Just need to fit the evaluator the existing interface in the header or would need some alterations to the users of the interface as well.
Unfortunately, I don't think I would have time right now to look into this but will try to find some time to do it. My PC at home died so to speak, so working from an older laptop for a few weeks now so don't even have access to my Haiku VM yet (where I used to do some updates on Beezer a year or so ago).
btw, another thing that's missing are the units themselves. These are files with BFS attributes. They can be re-created once there's something compiling.
The units cannot be checked into the Git repo directly as we'd lose the BFS attributes, so they would need to be zip'd and commited to the repo. They will have to be unpacked during the build process and cleaned up on make clean stage.
Thanks a bunch for taking the time to look into this, and for the further details, Ram! No worries regarding time-frames, of course! We Haiku users know to be patient!
Thanks again. and always know that BeOS/Haiku people loved (and still love) your apps!
Hi. Sorry I'm a bit late to the party! Just in case it's not clear, I have all theUnits files -- with Attributes of course. I'll make a zip archive so they can be added here.
I added a skeleton XEvaluator.cpp in caecddc just to see how it compiles and runs. Ofc, without a function evaluator nothing will actually work but that's the next step.
Seems to compile fully and the GUI isn't too badly messed up in Haiku. Looks like it will need a bit of work switching to the layout kit etc. but doesn't look unusably bad.
@OscarL any particular reason the makefile you commited uses ../BeConverter as the app name? The binary file ends up in the Source/ folder. Until the directory structure is sorted out further, maybe we should let the executable be along with the other object files in objects.<xyz>?
Heh... You beat me to it! That was going to be my project for today...
I figured I could do that quickly and would be a useful check. Glad
to know it compiles. Thanks!
any particular reason the makefile you commited uses ../BeConverter as the app name
Just because it was more convenient from a HaikuPorter's recipe point of view. That way the binary ends ups in a "known location" (as the name of the object folder changes depending on which compiler we're using when building the recipe: 64 vs 32 bits, GCC2 vs newer GCC11).
That way, the "recipe" can just copy it from there to the install location after calling make, and create the .hpkg afterwards.
No other particular reason. There might be a better way, I'm stll a newb regarding build systems and HaikuPorts recipes, so feel free to change as you think it's best.
Heh... You beat me to it! That was going to be my project for today... I figured I could do that quickly and would be a useful check. Glad to know it compiles. Thanks!
Ah, sorry wasn't aware you were planning to work on it.
any particular reason the makefile you commited uses ../BeConverter as the app name
Just because it was more convenient from a HaikuPorter's recipe point of view. That way the binary ends ups in a "known location" (as the name of the object folder changes depending on which compiler we're using when building the recipe: 64 vs 32 bits, GCC2 vs newer GCC11).
That way, the "recipe" can just copy it from there to the install location after calling make, and create the .hpkg afterwards.
No other particular reason. There might be a better way, I'm stll a newb regarding build systems and HaikuPorts recipes, so feel free to change as you think it's best.
Okay, I tried playing with OBJ_DIR, OBJDIR in the Makefile but to no effect, but I'll worry about this later. For now, it can probably be the way it is but should be changed to a defined, statically named location in the future (to help with Haikuports/recipe). It also helps with adding it to .gitignore as well.
On Fri, Dec 30, 2022 at 08:40:13PM -0800, Teknomancer wrote:
> Heh... You beat me to it! That was going to be my project for today... I figured I could do that quickly and would be a useful check. Glad to know it compiles. Thanks!
Ah, sorry wasn't aware you were planning to work on it.
(:-)) No problem! It was just something I suddenly realized I could do.
You could probably do it even faster than I could!
Activity
Teknomancer commentedon Dec 29, 2022
Hi Oscar (been a long time 😃 👋 )
I tried searching the backup I had and can't seem to find the missing file.
Looks like it might need to be re-written. It's a bit of work but should be doable. Just need to fit the evaluator the existing interface in the header or would need some alterations to the users of the interface as well.
Unfortunately, I don't think I would have time right now to look into this but will try to find some time to do it. My PC at home died so to speak, so working from an older laptop for a few weeks now so don't even have access to my Haiku VM yet (where I used to do some updates on Beezer a year or so ago).
Teknomancer commentedon Dec 29, 2022
btw, another thing that's missing are the units themselves. These are files with BFS attributes. They can be re-created once there's something compiling.
The units cannot be checked into the Git repo directly as we'd lose the BFS attributes, so they would need to be zip'd and commited to the repo. They will have to be unpacked during the build process and cleaned up on make clean stage.
OscarL commentedon Dec 29, 2022
Thanks a bunch for taking the time to look into this, and for the further details, Ram! No worries regarding time-frames, of course! We Haiku users know to be patient!
Thanks again. and always know that BeOS/Haiku people loved (and still love) your apps!
Teknomancer commentedon Dec 30, 2022
@OscarL I've provided write access for you to this repo, let me know if you didn't get the invite.
OscarL commentedon Dec 30, 2022
@Teknomancer, got it, thanks!
PeteCA commentedon Dec 30, 2022
Hi. Sorry I'm a bit late to the party! Just in case it's not clear, I have all theUnits files -- with Attributes of course. I'll make a zip archive so they can be added here.
Teknomancer commentedon Dec 30, 2022
I added a skeleton XEvaluator.cpp in caecddc just to see how it compiles and runs. Ofc, without a function evaluator nothing will actually work but that's the next step.
Seems to compile fully and the GUI isn't too badly messed up in Haiku. Looks like it will need a bit of work switching to the layout kit etc. but doesn't look unusably bad.
Teknomancer commentedon Dec 30, 2022
@OscarL any particular reason the makefile you commited uses
../BeConverteras the app name? The binary file ends up in theSource/folder. Until the directory structure is sorted out further, maybe we should let the executable be along with the other object files inobjects.<xyz>?PeteCA commentedon Dec 30, 2022
OscarL commentedon Dec 31, 2022
@Teknomancer:
Just because it was more convenient from a HaikuPorter's recipe point of view. That way the binary ends ups in a "known location" (as the name of the object folder changes depending on which compiler we're using when building the recipe: 64 vs 32 bits, GCC2 vs newer GCC11).
That way, the "recipe" can just copy it from there to the install location after calling make, and create the .hpkg afterwards.
No other particular reason. There might be a better way, I'm stll a newb regarding build systems and HaikuPorts recipes, so feel free to change as you think it's best.
Teknomancer commentedon Dec 31, 2022
Ah, sorry wasn't aware you were planning to work on it.
Okay, I tried playing with
OBJ_DIR,OBJDIRin theMakefilebut to no effect, but I'll worry about this later. For now, it can probably be the way it is but should be changed to a defined, statically named location in the future (to help with Haikuports/recipe). It also helps with adding it to.gitignoreas well.PeteCA commentedon Dec 31, 2022