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?
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
