Re: [MirageOS-devel] Camlp4 Stack_overflow

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Your approach is just fine as well -- in fact, with OCaml 4.02, there's
even more compile-time inlining and evaluation done to move more expressions
into the rodata section at compile time.  You've just hit the issue that
Camlp4 needs more stack space for some parse expressions that are
particularly long.

I've played around with _tags files and can't figure out how to convince
ocamlbuild (when using the -use-ocamlfind mode) to *remove* the -pp
flag for just one source file.  If anyone else has any ideas, feel free
to jump in...

-anil


On 8 May 2014, at 10:04, André Næss <andre.naess@xxxxxxxxx> wrote:

> The idea was to keep the application as simple as possible by moving
> all processing to compile time. It would avoid the startup cost of
> reading all the entries and thus make for simpler deployment, but I
> realise I may be taking it a bit too far :)
> 
> Using the crunch approach is probably more reasonable. I guess I just
> figured that my approach was even simpler since I wouldn't have to
> understand the crunch approach and how to read data back in the
> application.
> 
> On Thu, May 8, 2014 at 12:38 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> To address the camlp4 problem, you can use the _tags file to mark just
>> the one source file as not passing through camlp4 (via a '-' somewhere
>> to remove the tag -- will need to look up the details in the manual).
>> 
>> The easiest way to solve your problem would be just to have a crunched
>> file containing the information in CSV or S-expression format, and then
>> reading from it at application startup time to initialize your array.
>> 
>> The 'crunch' mode would compile all this into a standalone kernel, or
>> in Unix mode would be a filesystem passthrough for easier development.
>> Any reason you want it to be a 'hand written' OCaml file?
>> 
>> -anil
>> 
>> On 7 May 2014, at 14:06, André Næss <andre.naess@xxxxxxxxx> wrote:
>> 
>>> I've rewritten the generated code so that it creates an array and then
>>> assigns to indexes of the array, batching the assignments using
>>> multiple let () =
>>> 
>>> Compilation speed is a problem, and it still falls over at 50K entries.
>>> 
>>> I suppose I could somehow write the data to an image and read it back
>>> in at application startup, but I think I actually like my current
>>> approach. All of the work is done at compilation time. The rows are
>>> written in sorted order so a simple binary search can be used. The
>>> resulting application is entirely single-purposed.
>>> 
>>> Any ideas for other ways to do this? Bypass the compiler and "compile"
>>> the data myself? Does there exist tools to do something like that?
>>> 
>>> On Wed, May 7, 2014 at 1:40 PM, André Næss <andre.naess@xxxxxxxxx> wrote:
>>>> Hi
>>>> 
>>>> I'm trying something that might be a bit silly but it's just intended
>>>> as an internal demo of Mirage to my team. I'm writing a tiny HTTP
>>>> based application whose only purpose is to allow you to search a phone
>>>> book.
>>>> 
>>>> I've based my approach on the approach you've used for static websites
>>>> using crunch where you compile the web pages into the executable. In
>>>> my case that means I take the list of name and number pairs and stuff
>>>> them into an array. So part of my config.ml file emits a single Pb.ml
>>>> file which contains an array declaration like this:
>>>> 
>>>> let db = [|("Aaron Jaksic",1571268);
>>>> ("Aaron Mcdivitt",1454629);
>>>> ("Aaron Reuben",1765247);
>>>> ("Aaron Sardinha",1224806);
>>>> ("Abbey Gowens",1267083);
>>>> ("Abbey Hathcox",1309490);
>>>> ...
>>>> 
>>>> As the title say I'm running into problems compiling this when I
>>>> create a large phone book, the error being:
>>>> 
>>>> Camlp4: Uncaught exception: Stack_overflow
>>>> 
>>>> This happens with 25K entries, it works with 10K entries.
>>>> 
>>>> Is there some way I can prevent Camlp4 from being run on the Pb.ml
>>>> file? Or will I just have to generate a file that builds the array at
>>>> runtime somehow?
>>>> 
>>>> André
>>> 
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel