[urbit] Did someone say they wanted a moon on their iPhone?

[Wim Looman]

So, I just spent a couple of days hacking this together. Obviously there’s still something going wrong, but I’m pretty happy to get it to a state where it actually seems to be attempting to run some Hoon code and not just blowing up without any error messages. Full log is available at https://gist.github.com/Nemo157/3d8726229b3994ffa2ef, if anyone has a hint on where to look to fix whatever’s failing I’d be glad for it, for now I’m going to try and work out how to actually clean up the changes enough to open a branch.

[Raymond Pasco]

Pretty cool stuff. Off the top of my head (sleep emailing again...), I'm not sure if daemon mode actually works - could that be an issue?
Yours,
r

[c***@gmail.com]

Yeah, as far as I know no one has tried to use daemon mode in, like,
forever. ~zod and ~doznec are DO servers that can be ssh'd into, so user
input isn't a problem. Not sure how it would act even if it did manage to
background itself.

Are you just using yebyen's rpi fork for building for iOS, or does
something fancier need to be done?

Post by Wim Looman
So, I just spent a couple of days hacking this together. Obviously there’s
still something going wrong, but I’m pretty happy to get it to a state
where it actually seems to be attempting to run some Hoon code and not just
blowing up without any error messages. Full log is available at
https://gist.github.com/Nemo157/3d8726229b3994ffa2ef, if anyone has a
hint on where to look to fix whatever’s failing I’d be glad for it, for now
I’m going to try and work out how to actually clean up the changes enough
to open a branch.

[c***@gmail.com]

The fact that it's only mapping 512mb for a loom and bailing from an
overflow doesn't look good, either...does it just crash with a bigger slab
allocated? Does iOS have a swapfile you can provide?

Post by c***@gmail.com
Yeah, as far as I know no one has tried to use daemon mode in, like,
forever. ~zod and ~doznec are DO servers that can be ssh'd into, so user
input isn't a problem. Not sure how it would act even if it did manage to
background itself.
Are you just using yebyen's rpi fork for building for iOS, or does
something fancier need to be done?

Post by Wim Looman
So, I just spent a couple of days hacking this together. Obviously
there’s still something going wrong, but I’m pretty happy to get it to a
state where it actually seems to be attempting to run some Hoon code and
not just blowing up without any error messages. Full log is available at
https://gist.github.com/Nemo157/3d8726229b3994ffa2ef, if anyone has a
hint on where to look to fix whatever’s failing I’d be glad for it, for now
I’m going to try and work out how to actually clean up the changes enough
to open a branch.

[Curtis Yarvin]

Cool!

Although I'm not sure how much of an endgame there is for Urbit proper on
iOS, because we do download code over the network and that's a no-no. I
think the general mobile strategy from our perspective is to talk to either
(a) a browser, or (b) more optimally, something like a React Native client,
but using the same HTTP APIs as a browser client. We actually have a
pretty decent general-purpose gateway between Urbit messaging and HTTP,
such that your planet doesn't even know it's talking to a web client (for
instance, if you've used web :talk, there are exactly 0 lines of
web-specific code in the :talk appliance).

That definitely seems like a stack overflow. Or at least, the "dig: over"
message is what's supposed to be displayed when a stack overflow is
detected. We are certainly heavier stack users than most iOS apps. But
that doesn't mean it's not a pathological condition that manifested as a
stack overflow...

Post by c***@gmail.com
The fact that it's only mapping 512mb for a loom and bailing from an
overflow doesn't look good, either...does it just crash with a bigger slab
allocated? Does iOS have a swapfile you can provide?

Post by c***@gmail.com
Yeah, as far as I know no one has tried to use daemon mode in, like,
forever. ~zod and ~doznec are DO servers that can be ssh'd into, so user
input isn't a problem. Not sure how it would act even if it did manage to
background itself.
Are you just using yebyen's rpi fork for building for iOS, or does
something fancier need to be done?

Post by Wim Looman
So, I just spent a couple of days hacking this together. Obviously
there’s still something going wrong, but I’m pretty happy to get it to a
state where it actually seems to be attempting to run some Hoon code and
not just blowing up without any error messages. Full log is available at
https://gist.github.com/Nemo157/3d8726229b3994ffa2ef, if anyone has a
hint on where to look to fix whatever’s failing I’d be glad for it, for now
I’m going to try and work out how to actually clean up the changes enough
to open a branch.
--

You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Wim Looman]

Yeah, I doubt this would ever be allowed on the App Store, but they're opening up slightly in terms of self installing.

The reason I'm looking at this at the moment is that I'm spending a lot of time without network access on my phone currently, so having a syncing distributed file system like clay would be very nice for allowing apps to record data whilst offline then syncing it back to the planet when coming back online automatically.

--
Wim Looman

Cool!
Although I'm not sure how much of an endgame there is for Urbit proper on iOS, because we do download code over the network and that's a no-no. I think the general mobile strategy from our perspective is to talk to either (a) a browser, or (b) more optimally, something like a React Native client, but using the same HTTP APIs as a browser client. We actually have a pretty decent general-purpose gateway between Urbit messaging and HTTP, such that your planet doesn't even know it's talking to a web client (for instance, if you've used web :talk, there are exactly 0 lines of web-specific code in the :talk appliance).
That definitely seems like a stack overflow. Or at least, the "dig: over" message is what's supposed to be displayed when a stack overflow is detected. We are certainly heavier stack users than most iOS apps. But that doesn't mean it's not a pathological condition that manifested as a stack overflow...

The fact that it's only mapping 512mb for a loom and bailing from an overflow doesn't look good, either...does it just crash with a bigger slab allocated? Does iOS have a swapfile you can provide?

Yeah, as far as I know no one has tried to use daemon mode in, like, forever. ~zod and ~doznec are DO servers that can be ssh'd into, so user input isn't a problem. Not sure how it would act even if it did manage to background itself.
Are you just using yebyen's rpi fork for building for iOS, or does something fancier need to be done?

Post by Wim Looman
So, I just spent a couple of days hacking this together. Obviously there’s still something going wrong, but I’m pretty happy to get it to a state where it actually seems to be attempting to run some Hoon code and not just blowing up without any error messages. Full log is available at https://gist.github.com/Nemo157/3d8726229b3994ffa2ef, if anyone has a hint on where to look to fix whatever’s failing I’d be glad for it, for now I’m going to try and work out how to actually clean up the changes enough to open a branch.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

[Wim Looman]

Should have reply-alled this...

--
Wim Looman

Date: 23 October 2015 at 20:35:15 GMT+3
Subject: Re: Did someone say they wanted a moon on their iPhone?
I don't believe so, I can map 2GB in the simulator so I can probably try and get that going first to ensure any issues aren't the small loom.
The biggest change was in building all the libraries for multiple targets and creating fat libs for them. I've done that manually for now so that's what's going to take the most time in re-working out exactly how I did that for each library and writing a script to do that. Other than that it was just creating iOS versions of the ifdef'd sections and setting up stdout/stderr redirection so I could show the log in a text field.
The main reason I was using daemon mode was for disabling of the interactive terminal stuff so I could use that redirection nicely.
--
Wim Looman

The fact that it's only mapping 512mb for a loom and bailing from an overflow doesn't look good, either...does it just crash with a bigger slab allocated? Does iOS have a swapfile you can provide?

Yeah, as far as I know no one has tried to use daemon mode in, like, forever. ~zod and ~doznec are DO servers that can be ssh'd into, so user input isn't a problem. Not sure how it would act even if it did manage to background itself.
Are you just using yebyen's rpi fork for building for iOS, or does something fancier need to be done?

Post by Wim Looman
So, I just spent a couple of days hacking this together. Obviously there’s still something going wrong, but I’m pretty happy to get it to a state where it actually seems to be attempting to run some Hoon code and not just blowing up without any error messages. Full log is available at https://gist.github.com/Nemo157/3d8726229b3994ffa2ef, if anyone has a hint on where to look to fix whatever’s failing I’d be glad for it, for now I’m going to try and work out how to actually clean up the changes enough to open a branch.