[Ur] Rough edges.

[Michael Stone]

On 3/9/10, Adam Chlipala <adamc at impredicative.com> wrote:
> Michael Stone wrote:
>> I've continued playing with Ur/Web over the last few days and I'm
>> fairly happy with the results I'm getting. The manual and demos have
>> both been exceptionally helpful.
>>
>> Now, for what they're worth, here is a report of a few of the rough
>> edges that I've bumped up against recently, in case you're interested
>> in polishing a few of them off.
>>
>
> I sure am!  Several of these issues are covered in the manual, which I
> know is an impractical thing to read through and digest in full.  I'll
> try to point to the manual sections relevant to the different issues.

It's darn good, as manuals go. Along with the demos and the source
code, it has given me enough ideas that I haven't gotten truly stuck
yet.

Also, thanks for the citations below. I imagine that they will make
future FAQ and example development quite a bit easier.

Regards,

Michael

---------------------------------

>> script tags
>> :    I wanted to use the jQuery "quicksearch" library. The natural way
>> to do this seemed to be to add a few script tags to my document. To do
>> this, I added a script tag admissible in the "head" context with a
>> "src : url" attr. (I don't need bodies for to do what I want.)
>>
>
> I think what you're looking for is the "script" .urp directive, as
> described in 3.1.

This might work. I'll try it.

However, the reasons why I turned to a script tag may be instructive:

  a) the jQuery documentation suggested that I use a script tag, so
that's what I was thinking about

  b) I wanted my scripts to modify a single page, rather than all
pages in the module, so I was thinking about "what do I put in my
function to solve this problem?" rather than "what do I put in my
build configuration to solve this problem?"

  c) there are no examples demonstrating usage of the script directive.

>> documentation of the { eqNullable' (SQL table.Field) xyz } construction
>> :    An additional demo would have helped here.
>>
>
> Does reading the function's implementation help explain it?  Is the
> issue with the (SQL ...) syntax?

The (SQL table.Field) was the main confusion.

The implementations (and signatures) did help me to distinguish
eqNullable from eqNullable'.

>> ability to COUNT( table.Field ) vs. COUNT( * )
>> :    this is mainly a source of confusion; thus far, it's been easy to
>> work around with views
>>
>
> I'd been thinking that these forms are equivalent, but now I've read the
> Postgres manual and seen the error of my ways.  I'll add the first form
> in the basis library for the next release.
>
>> syntax for specifying indices on tables
>> :    I can post-process the generated SQL, but this will eventually get
>> annoying
>>
>
> My current model is that indices are added in an out-of-band way, but I
> know that doesn't play so well with modularity, if you think of the
> presence of an index as an important part of the module.  For now,
> though, I'm not planning to add any support for this, since adding
> indices manually doesn't seem like that big of a deal, and is probably
> even the optimal solution for many applications with changing data
> distributions and performance requirements.

Okay.

>> compiler/build flags for debug outputs
>> :   It would be easier to understand the compiler internals if I could
>> see the output of each phase. I'm particularly interested in the
>> output of the earliest phases.
>>
>
> I do this sort of thing in SML/NJ, as described in 2.

I see the reference now; thanks.

> I hope that looking at src/compiler.sig suffices for learning about the relevant
> instrumentation.

This makes sense now, at least at a high level. Adding a page to the
manual showing off an interactive session with the compiler (e.g.,
dumping the output of an intermediate stage) would have made this
clear to me.

>> an API for reading files
>> :    I'm basically working on a syntax highlighter and statistics
>> viewer for the contents of a small file system
>> :    At the moment, I'm using a combination of a pre-seeded database
>> (to inform the web-app of the contents of the filesystem) and a C FFI
>> module (to read the files) to work around this.
>>
>
> I expect folks to use the C FFI for this sort of thing.  I don't want to
> provide a conventional "file IO library" out of the box, because this
> isn't so compatible with the transactional world-view.
>
> Ur/Web programs _will_ break horribly if you use the FFI to execute actions that aren't
> rolled back on failure.

Examples, both of what to do and of what not to do, would be helpful.

A definition or citation in the manual of "transactional" as you're
using it would also be appreciated.

>> error-handling idioms in the C FFI
>> :    While writing my C module, I need to ensure that I close files
>> that I open. This makes the raw uw_error() primitive hard to use
>> safely. Is there, for example, a way to hook into urweb's region-based
>> control flow logic?
>>
>
> I suggest uw_register_transactional(), as documented in 11.1.  This is
> assuming you only open a few files per HTTP request and don't mind
> having them all open until the request is fully processed.  (Though you
> could also include an explicit close function in your FFI module.)

I'll try this out. I skipped it on my first attempt due to the lack of
an example.

>> uw_malloc
>> :   uw_malloc is doing something that I don't understand, in that the
>> following approximate snippet:
>>
>>      size_t len = ...
>>      char* c = uw_malloc(ctx, len);
>>      if (!c) uw_error(ctx, FATAL, "couldn't allocate %d bytes", len);
>>      memset(c, 0, len);
>>
>> sometimes segfaults on the memset. (I was able to work around this
>> problem by using a fixed-size stack-allocated array.)
>>
>
> That is definitely not supposed to happen.  Would you mind reducing this
> to a minimal example that still exhibits the problem and then submitting
> the source code in a Mantis bug report?

I'll try.

---------------------

One other comment that I thought of while writing up this reply
concerns my early struggles to operate the development environment:

In my first few hours, I frequently left off or various scope-closing
devices like "end" keywords, </xml> tags, and closing parentheses. I
also mixed up closing </td> and </tr> tags, until I started putting
them on separate lines.

Unfortunately, the compiler error message(s) that result, e.g.,

   /home/mstone/src/ur/urweb/foor/bar.ur:69:7-69:11: Begin and end
tags don't match

didn't tell me enough to let me immediately figure out what was going
on because it didn't mention the specific start tag whose end tag
didn't match.

(I later learned that these messages are somewhat more useful when you
receive them through "M-x compile" than through "make" in a separate
terminal. However, being new to emacs, this also wasn't particularly
apparent.)

(I also eventually learned that the column numbers cited above count
tabs as 1 character and that the selected region of text contained the
beginning tag whose ending tag was missing/misplaced.)