Darren New wrote:
> I was just after whether it was a strange logic error or something. It 
> works, it's just really slow, 

It turns out that using the Erlang equivalent of fscanf("%s",...) is 
much slower than using the erlang equivalent of fgets(). Like, an hour 
versus a couple seconds to read and process the file. I haven't any idea 
why yet.

And I figured out what is throwing me about finding documentation. The 
language defines "modules" and "functions", where a "module" is all the 
functions in one source file.

But the top-level documentation is organized in terms of "applications", 
wherein each "application" is a collection of modules distributed 
together, but for which there's no real direct equivalent in the 
language itself. The runtime interpreter parses configuration values 
based on the application name (e.g., you can set the xyz configuration 
to pdq for the abc application by starting erlang with
   % erl -abc xyz pdq
), so the runtime knows about applications, and the libraries do, but 
they're nowhere in the TOC for the language manual.

Sort of like if you had to figure out whether what you want is in 
stdlib, stdio, STL, Boost, or POSIX before you could look up strlen or 
open() or something like that in the manual.

Yes, there are other indexes in the manual pages, but the documentation 
itself refers to the applications, so before you figure this out, it's 
way confusing. Especially since "application" doesn't *really* mean just 
"application".  Like, is spawning a new process in the "erlang" 
application, the "kernel" application, or the "stdlib" application? Is 
the function to dynamically load code in one of those, or is it in the 
"code" application or the "compiler" application or the "primitives" 
application? :-)

And then you package up "applications" into "releases", so just because 
you have a monitoring program, a database, and a web server, those could 
be three "applications" that make up one thing-the-user-runs, whatever 
you want to call them.

It doesn't help that you can fiddle with the syntax via macros, not 
unlike LISP. Except that the syntax fiddling is apparently (as far as 
I've been able to figure out) caused by something outside your modules. 
That is, you don't have to say anything inside your source code to get 
it modified dynamically during compilation. Instead, the thing that 
implements the parsing transformations is apparently configured in 
outside the system. The compiler must be reading a file somewhere saying 
"this list of modules implements parsing transformations" or some such. 
I haven't quite tracked that down yet, but now that I know the words...

Babble mumble mutter. Don't mind me.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message