kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
_whitelogger has joined #sandstorm
frigginglorious has quit [Read error: Connection reset by peer]
<ocdtrekkie>
isd: I am usually at a Windows machine when I review Docs PRs.
<ocdtrekkie>
Anything I can upload to a Sandstorm server makes me happy.
<isd>
Makes sense. By contrast, I am never at a windows machine when reviewing prs.
<isd>
I'm looking at reworking static publishing to use the powerbox.
<isd>
I have a rough sense of how I think this is going to look. But, frankly, hacking on C++ that needs to talk to both a (potentially malicious) app and the network, in non trivial ways, scares me.
<isd>
I kinda wish sandstorm was written in rust or something right about now...
<isd>
I'm half tempted to suggest writing new chunks of code in Rust, though there's obviously an integration headache, and it's yet another build dependency, and there's the question of how it's going to talk to the rest of the system.
<isd>
The answer to the latter bit can probably mostly be "capnproto."
<isd>
...it feels silly in some ways. But I would genuinely sleep better at night if more of the code I was writing was memory safe.
<xet7>
isd: If there is general opinion about adding more rust code, I could think about adding some rust to Wekan
<isd>
I don't think rust makes sense everywhere, and I probably wouldn't use it for web apps generally. I'm thinking specifically in place of things that would otherwise be C++.
<xet7>
isd: That would mainly mean, that I would need to build that rust code for x64/arm64/s390x etc
<isd>
Apps can be written in whatever; for wekan you should do what you think makes sense for that project.
<isd>
I'm more thinking in terms of Sandstorm itself.
<xet7>
Well, I don't know rust and capnproto so I'm not qualified to answer to that...
<xet7>
I'm not sure is it correct, but some blogposts and webpages claim that Go is safe because of carbage collection etc
<xet7>
garbage
<xet7>
Although, I tried Go at work once, it was a nice way to shoot directly to foot
<isd>
If I were you I would not start re-writing parts of wekan.
<xet7>
Sure, all of my re-write attempts have failed. I have just kept using Javascript.
<xet7>
And Meteor
<isd>
I mean, is there a reason you're tempted to re-write it?
<xet7>
Well, there would be some nice-to-haves, like single exe instead of 30k Javascript files. Extracting 30k files .zip bundle does crash ReactOS filesystem. Meteor does build Wekan for about 30 minutes. It would be nice to support some other databases. But, I don't even know am I capable of doing a real rewrite. Bugs in Meteor most likely will be fixed sometime by Meteor community.
<xet7>
Most likely those are just too nerdy niche reasons.
<xet7>
For current Wekan, it's mostly finished product, in global wide use, and integrated to countless of other systems.
<xet7>
It's mainly adding some more features, bugfixes, updates etc
<xet7>
Current trend is going to direction of having options to hide features that are not used actively, to make it easier to use. Like current Wekan Board Settings / Card Settings to hide some fields at cards.
<isd>
For the too-many-files thing, could you use something like webpack or rollup to bundle it up into one file?
<isd>
Also, what kind of hardware are you building on? For sandstorm at least, Meteor doesn't take anywhere near that long to build on my laptop (which is a bit over a year and a half old), but abliss has had much more trouble I know (including running out of memory...).
<xet7>
Some options are: a) mounting .zip file b) adding those files to .iso file c) looking at nexe or similar tools, do they work
<xet7>
Well, sometime I did build Wekan on bare metal server that has about 300 GB RAM, 50 CPU cores and 3 TB NVME disk. It did still take a long time. Currently I build Wekan on a little less powerful bare metal server, or on my i5 desktop that has 24 GB RAM and SSD disk.
<xet7>
On Ubuntu Linux or Debian
<isd>
Ok, that desktop is a beefier machine than what I'm building it on. It's probably possible to improve build times without ditching meteor, if you investigate what's actually going on.
<isd>
Like, the meteor bits of sandstorm take me like a minute tops (which is still way slower than I think is reasonable for an ostensibly interpreted language, but it's a lot better).
<xet7>
Wekan does build a little faster with newest Meteor by excluding legacy and cordova: WITH_API=true RICHER_CARD_COMMENT_EDITOR=false ROOT_URL=http://192.168.0.2:4000 meteor run --exclude-archs web.browser.legacy,web.cordova --port 4000
<xet7>
But anyway, when building Wekan, spinner freezes for some long time, and later continues
<TimMc>
What is it spending all that time *doing*?
<ill_logic>
Ian Denhardt: Did you say there was a particular doc I should look at to set up Sandstorm core dev?
<ill_logic>
And I think you said that the one I'm looking at isn't really even a core issue, but still I'm not sure how setup works.
<ill_logic>
I see info on code reviews for core, that's about it.
<isd>
You mean the storage usage indicator? It's "sandstorm core" but doesn't require hacking on the C++, maybe that's what you're thinking of.
<isd>
I may have mentioned the 'dev-shell' command, which is useful, but kentonv pointed out you still have to build it once.
<isd>
We really should point to those instructions from somewhere people are likely to look if they're planning on hacking on sandstorm itself. In the middle of N ways of installing is not where I would look
<isd>
I guess we do have a link in CONTRIBUTING.md
frigginglorious has quit [Read error: Connection reset by peer]