tocwex / fund

A sovereign platform for peer-to-peer economic activity with on-chain settlement and trusted identity assessment of work completion.
GNU General Public License v3.0
1 stars 0 forks source link

Latest %fund does not compile on ~bitdeg #81

Closed pkova closed 1 week ago

pkova commented 1 month ago
[%error-building /app/fund/hoon]
[%error-building /web/fund/page/proj-view/hoon]
/web/fund/page/proj-view/hoon::[5 1].[547 3]>
/web/fund/page/proj-view/hoon::[6 1].[547 3]>
/web/fund/page/proj-view/hoon::[7 1].[547 3]>
/web/fund/page/proj-view/hoon::[138 3].[546 5]>
/web/fund/page/proj-view/hoon::[139 3].[546 5]>
/web/fund/page/proj-view/hoon::[140 3].[546 5]>
/web/fund/page/proj-view/hoon::[141 3].[546 5]>
/web/fund/page/proj-view/hoon::[142 3].[546 5]>
/web/fund/page/proj-view/hoon::[143 3].[546 5]>
/web/fund/page/proj-view/hoon::[145 3].[546 5]>
/web/fund/page/proj-view/hoon::[146 3].[546 5]>
/web/fund/page/proj-view/hoon::[147 3].[546 5]>
/web/fund/page/proj-view/hoon::[148 3].[546 5]>
/web/fund/page/proj-view/hoon::[149 3].[546 5]>
/web/fund/page/proj-view/hoon::[150 3].[546 5]>
/web/fund/page/proj-view/hoon::[151 3].[546 5]>
/web/fund/page/proj-view/hoon::[152 3].[546 5]>
/web/fund/page/proj-view/hoon::[153 3].[546 5]>
/web/fund/page/proj-view/hoon::[154 3].[546 5]>
/web/fund/page/proj-view/hoon::[155 3].[546 5]>
/web/fund/page/proj-view/hoon::[156 3].[546 5]>
/web/fund/page/proj-view/hoon::[157 3].[546 5]>
/web/fund/page/proj-view/hoon::[411 11].[544 10]>
/web/fund/page/proj-view/hoon::[412 7].[544 10]>
mint-nice

Running VERSION: [0 2 2]

sidnym-ladrut commented 1 month ago

Hey @pkova, thanks for letting us know. The text block referenced in the error is just a multi-line tape, which is building on all the other Zuse 411k ships we've encountered. Is ~bitdeg on any sort of edge kelvin release, or is there anything else about it that may make it parse multi-line tapes differently?

pkova commented 1 month ago

~bitdeg is on 411k-1 (%base hash 0v1v.7d11h.3r3uv.nf5q5.dmn7e.oh2k5.laq86.hpq3c.qdh77.dqicb.k6s76) so no pre-release stuff, %fund hash is 0v15.bs4mv.dn9e3.vopof.aelks.ngmkf.n0stg.6ecfe.ht9ov.vg96f.27b8t.

sidnym-ladrut commented 1 month ago

Affirmative; I'll try to reproduce this locally and will report back.

sidnym-ladrut commented 1 month ago

I booted a fresh comet using Vere 3.0 and ran |ota ~litzod and |install ~tocwex %fund and didn't encounter issues at the build step. My build hashes for %base and %fund match those you've provided.

Did ~bitdeg have the old %fund desk that was distributed by ~dalten? If so, I think that's the likely culprit. I can work with @thelifeandtimes to set up an environment where we can test that specific upgrade path.

thelifeandtimes commented 1 month ago

There was no old %fund desk to be installed, iirc. The way end users interacted with it was via a wrapper library around the desk for which we were fundraising (%wrdl, or %aera), and then only the escrow ship ran a ledger agent that kept track of the pledges. @pkova are you getting an infinite spinner in landscape when attempting to install? there seems to be some weird stuff going on with installs in some cases as I experienced this from some time trying to install %studio from ~tirrel and I know some people are running into issues installing desks from ~ridlyd (cc @hanfel-dovned)

sidnym-ladrut commented 2 weeks ago

@pkova and @joemfb debugged the build process by running vere with gdb. Based on the results, @joemfb suggested that the issue is an unbounded type refinement procedure for our long interpolated string that causes a stack overflow in some cases. In order to resolve the issue in the short term, @sidnym-ladrut will create a generator to experiment with string builder methods (e.g. via +zing and +weld) that cut back on interpolation and (consequently) reduce compile time. Once the compile time is sufficiently reduced, ~tocwex can push out another update to see if it fixes the issues on ~bitdeg.