Interestingly:
Removing the -O1 or -fPIC arguments allow for successful compilation.
For @flypigg, it was O2 causing the issue.
Interestingly:
Removing the -O1 or -fPIC arguments allow for successful compilation.
For @flypigg, it was O2 causing the issue.
Just wanted to add that I really enjoy the format and the effort put in, than you @flypig !
This seems to be even more adventurous than porting SFOS to a new device, and it will have a much wider impact when it succeeds!
I want to take some time to point out that this is indeed a burnout-prone activity and that you should space out your progress as much as you need.
There are 17 updates in the last 17 days. but nobody would bat an eye if there will be 10 updates in the next 30 days or even less. So please take care of yourself. I have made a livecasting of porting notes of ~60 days and it spanned half a year.
What you should do is just keep the branch(es) up to date. As you can see, in this project’s case, there is no specific device needed for someone to reproduce the same errors as you. So there are chances some might (as they already have:)
Also, I would like to turn the tables on Mozilla and, when this has a conclusion, write them that the qtmozembed we use really should be pushed back in, using your effort as a stance. There is really no way one man can follow tens of people over tens of years refactoring, as was not easy for even a small company such as Jolla to do.
Anyway, really great stuff. I personally appreciate you explainig the reasoning and your knowledge or lack of it for every step.
Hats off!
Just in case you haven’t already found it: there’s a page mapping the commands between the Sailfish SDK and the Platform SDK: SDK ↔ Platform SDK Command Map | Sailfish OS Documentation
That might help you get familiar with the Platform SDK.
I’m happy to hear you’re enjoying them @vlagged! Thank you for your consideration and the useful advice, which I will take it on board.
So far progress is slow but steady, and I’d love to get to the point where we can maintain gecko on a more rolling basis, but I think we’re still a way from that unfortunately. Any way we can persuade Mozilla to make it easier for us will generate dividends in the long run.
I have made a livecasting of porting notes
Were they recorded? If so, could you share a link?
They’re here on the forum. But nowhere near your clarity. I did used them to get back to where I made some decision or skipped resolving a problem. Or really just remembering a command.
I am linking to them just so you notice the pace change of the dates, or the taking of breaks:)
Is there really no way to test your code earlier? Always starting a full build and effectively waiting a day is immense painful.
I would have hoped there is a way to build a smaller chunk only that is way faster.
(I already feel massively crippled if my code-unittest cycle is longer than 60s. )
You raise a good point @thigg. I am doing incremental builds which are quicker than full builds, but as you can tell from my diary they can still take a while to run. I should probably be using partial builds more effectively. This has always been one of the challenging aspects of gecko development.
Today will be day 40! Thanks for doing this journey and writing about this!
Thanks for following along @thigg! You’re right, it’s day 40, but it’s not yet reached the end of Stage 1 (of 3) yet, so no stopping any time soon!
I hope your burnout detector is still running very well. If you take time off, do it with a feeling of great accomplishment please!
I am impressed by the work you’re doing besides your daily work. (and very glad you are writing about it)
I have one tiny suggestion for the blog. Always thought it was problem with esr78, but even on desktop some lines don’t fit in the code blocks (or maybe they do in 4k?), I would suggest changing pre’s white-space to ‘break-spaces’ in bokeh.css, seems to preserve the rest of formatting while also wrapping the super long ones (at least on desktop, not sure how to test on phone). Thanks a ton for the daily read!
Thanks for suggesting this @throwaway69, it’s a nice idea. I try to break lines at 80 characters in all the preformatted blocks, but that’s still way too wide on smaller displays.
After making this change I’m a bit concerned that things may look a bit messy, but let’s see how it goes.
Thank you so much for this work flypig
Yeah, I might’ve not thought that through, in portrait this could extend all code blocks by quite a bit if it ends up applying to each row (or most)… I’ll try to find a way to test some options on-device
Edit: maybe keeping the previous option as was and just adding: overflow-x: auto, overflow-y: hidden; will do the trick, this generates scrollbar for boxes that have long lines without extending them unnecessarily
@flypig Congratulations! I’ll celebrate with you today!
please think about if there is anything we can help you with on the next stages
To illustrate the process:
(created with bing&dall-e with “A pig with wings dressed as a doctor fixing the limb of a gecko with a bandage on a surgery table. Comic style”)
… Did i specify pig without legs…?
Oh wow, I agree with @ohnonot, this deserves waaay more than just the one heart I’m allowed to give! I think I’m going to have to print this out to put on my wall Thank you @thigg, this is so great!
As for the offer to help, Stage 2 has some parallel pieces so I’m going to put some issues up on the sailfish-browser git repo this week. It would be wonderful if others are able to get involved with them.
I jumped out of my chair from excitement when I saw you got the browser to run and load pages! Keep up the good work, I love reading through your daily posts (but make sure you don’t overdo it please!)
While the shorthand to enable C++17 doesn’t seem to work, you can still use QMAKE_CXXFLAGS += -std=c++17
.