Skip to main content

hometown - Link to source

Got a bit of uxntal+drifblim confusion right now. As I add more anonymous label sections to my code, I start getting this error near the very end:

Symbol too far: _{

Is there an absolute limit on the number of anonymous labels I can use?

#uxntal #drifblim

#uxntal #drifblim
in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •
oh, I thought that was stated as a nesting limit. These aren't nested, just sequentially defined.
in reply to fluffysoft

Devine Lu Linvega
hometown - Link to source
Devine Lu Linvega
• •
each one still has to be unique, they're normal labels underneath, you could try using shorts for the lambdas ids instead of bytes if you need more than 256 : )
in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •
Are you suggesting an edit to driflim to change the lambda id generation? Seems like a good change for my style of coding.
in reply to fluffysoft

Devine Lu Linvega
hometown - Link to source
Devine Lu Linvega
• •
yeah, I never needed that many lambdas before so I never hit the boundary, but I think you're well equipped to make that change yourself, you got this.
in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •
@neauoire Ah yeah, that wasn't so bad. My updated drifblim seems to be working in ubal, but I'll check against the tests and send a patch tomorrow, if you like.
@Devine Lu Linvega
in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •

@neauoire I checked the binary diffs and they seemed reasonable, and I ran the test script, but I suspect there isn't test coverage for this change. It's working for ubal, however. I'm guessing we'd want to update the etc/drifblim.rom.txt file if this is accepted. I have the patch pasted here:

paste.sr.ht/~fluffysoft/f2d7b4…

0001-lambdas-now-have-16-bit-ids-so-we-can-have-thousands.patch — paste.sr.ht

paste.sr.ht
@Devine Lu Linvega
in reply to fluffysoft

Devine Lu Linvega
hometown - Link to source
Devine Lu Linvega
• •

this is perfect, yes, it has to be a change to core.tal, it'll propagate everywhere from there. Can you make a git email patch?
lists.sr.ht/~rabbits/public-in…

This patch is going to make @snufkin_vc happy.

~rabbits/public-inbox archives — lists.sr.ht

lists.sr.ht
@Snufkin
This entry was edited (4 hours ago)
in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •
@neauoire never done it before, but I've got the format right, so I think it's just a matter of getting my email server to send it?
@Devine Lu Linvega
in reply to fluffysoft

Devine Lu Linvega
hometown - Link to source
Devine Lu Linvega
• •
yep! If that's too much of a pain, don't worry I'll merge it as is, it would just be nice if the patch was signed to you.
in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •

@neauoire I think if you use git am to apply the patch from the paste, it'll have the right credit in the commit log, it just won't show up in the mailing list properly.

I was looking at the guide and my email provider is apparently one of the worst for this kind of thing.

@Devine Lu Linvega
in reply to fluffysoft

Devine Lu Linvega
hometown - Link to source
Devine Lu Linvega
• •

it fails for me with git am

error: patch failed: src/core.tal:260
error: src/core.tal: patch does not apply
Patch failed at 0001 lambdas now have 16-bit ids, so we can have thousands of them. we still have a limit of 255 for nested lambdas, however.

in reply to Devine Lu Linvega

fluffysoft
hometown - Link to source
fluffysoft
• •
@neauoire ah, sorry, I think there's some mangling of whitespace that happened in the paste. I'll see if I can get the actual contents into the paste.
@Devine Lu Linvega

Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.

⇧