[Ur] A (simple) project and some thoughts.

Tue Mar 3 16:04:06 EST 2015

Sorry for the response delay; big research-paper deadline last week, and 
I submitted a paper about the Ur/Web compiler!

On 02/21/2015 10:11 AM, Evan Danaher wrote:
> After several partial projects, I finally made one simple enough that I
> actually finished it before getting frustrated with Ur/web's quirks and
> lack of documentation.  Ur/web is tremendous overkill for this project,
> but it was a good learning experience.

I'm not sure if the above is praise or condemnation or both for Ur/Web, 
but thanks for sharing your experiences! :-D

> All it does is look at the San Francisco and San Jose sports schedules,
> and if there's a game at a time that will cause lots of people to ride
> Caltrain, say so and change the color.  (If you're in the right
> timezone, that is...)
>
> http://willcaltrainsucktoday.com/
> https://github.com/edanaher/willcaltrainsucktoday
>
> (It's a bit silly; as the about page says, it's a takeoff of
> http://isthereagiantsgametoday.com/ based on a silly tweet)

Do you mind if I add a link from the page of users?

> I do like Ur/web very much in theory, and now that I've done a decent
> working example of simple SQL, RPC, and FRP, I hope I'll be able to use
> it for beefier projects in the future.

OK, so it sounds like you weren't scared off, after all.  Great. :)

> Some thoughts/issues I had doing this (in no particular order):
>
> 1. Timezone handling is annoying if the client and server are in
> different timezones.  Initially, everything was server-side, and it was
> great.  Then I moved some of the computation client-side, and suddenly
> it broke on my remote server, since I'm now on Eastern time, while this
> assumes Pacific time.  I'm not sure of a clean way to fix this in
> general, but since this really only makes sense if you're in California,
> I didn't try that hard.

Values of the [time] type should be transparently portable across client 
and server, at least.  Rendering as strings, etc., will indeed depend on 
time-zone settings.

Suggested API changes would be much appreciated.

> 2. To set the color, I wanted to set a class on the <body> that
> everything else could then work from.  Unfortunately, dynclass on body
> didn't work.  I don't see any theoretical reasons why this wouldn't
> work, but I certainly haven't investigated too deeply.

Ah, that was an oversight in the compiler.  It's fixed now in the public 
Mercurial repo.

> 3. I had some issues with multiply-used signals giving bizarre errors;
> see https://github.com/edanaher/willcaltrainsucktoday/tree/master/signal_test.
> It seems like using a signal object multiple times leads to "TSignal
> remains" errors.  The simple workaround is to think the creation of the
> signal so that it's not reused, but it makes the code uglier, and I'm
> mystified as to what the problem is (having not really thought about how
> signals might be implemented).

The general problem is that server-side code isn't allowed to produce 
[signal] values.  The small change in your example disables inlining 
that moves the [sg] definition from server to client.  When possible, 
try to avoid writing any [signal]-y code outside of an HTML event 
handler, etc.

(I hope a future Ur/Web version uses a type system to enforce this kind 
of property, but I hope it at least makes sense what the property is.  
The server shouldn't be computing with signals.)

> 4. Generated JS onclick handlers appear to always return false,
> preventing the event from propagating.  I wanted to onclick the main
> body to close the menu, but this prevented links from working because
> the body ate the click first.  Changing it to onmousedown worked, but it
> would be nice to be able to specify whether the event should propagate.

Hm... I'm not entirely sure how this event propagation works in 
JavaScript across browsers.  At some point, someone asked to add the 
built-in function [stopPropagation] to stop event propagation.  Is 
'return false' having that effect for some but not all events?

I'm happy to tweak the behavior to allow what you want, but I need some 
tips on JavaScript first.

> 5. URL whitelisting is prefix only; I wanted to use
> mailto:comments-[timestamp]@... for spam-blocking purposes.  But to
> allow this link, I had to whitelist mailto:comments-*.  This isn't a
> huge deal, but I'm wondering if there's any deep reason for this or if
> it just handles the common URL case, so was never improved.

It's just about handling the common case, and I'll look into adding more 
general '*' stuff.  But do you really want to allow any text in the 
blank above?  What if the text contains an '@'?  I think of 'mailto:' 
links as pretty innocuous, so not so important to filter precisely.

> 6. Maybe I've done too much Haskell, but I kept being lazy about let val
> versus let fun (particularly when thunking the signals for (3) above).
> The initial error message "This is an expression but not a pattern." is
> extremely confusing, especially as it tends to point at an apparently
> unrelated line.  The second error, "syntax error: inserting  REC", is
> more helpful, but occasionally I managed to confuse the parser far
> enough that I didn't even get that.

That is a particularly painful parse error message (that is, the first 
one is) that shows up because of the support for patterns to the left of 
[<-].  I don't know how to coerce ml-yacc to say better things, but 
suggestions would be appreciated.

> 7. Generating a dynamic link (such as on/[year]/[month]/[day]) requires
> generating the whole link tag dynamically instead of just substituting
> the link in.  I found a reference online that this is because the
> function name in the link needs to be used to generate the URL; this
> makes sense, but seems to be an annoying limitation.

I don't understand what you mean by "dynamic link."  Can you give an 
example?