[Ur] Rough edges.

Adam Chlipala adamc at impredicative.com
Tue Mar 9 17:46:09 EST 2010


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.

> 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.

> 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?

> 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.

> 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 hope that 
looking at src/compiler.sig suffices for learning about the relevant 
instrumentation.

> 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.

> 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.)

> 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?



More information about the Ur mailing list