From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Babel woes Date: Wed, 17 Aug 2011 15:51:39 +0200 Message-ID: <8039h0qh78.fsf@somewhere.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Andras, Andras Major wrote: > I've been trying to use org-mode for report generation lately, and > haven't really succeeded. Here's a list of issues I encounter: > > - Babel offers a way of generating a code block from the output or > value of a code block. That new block, however, is forced to the > same language as the original block -- that is doesn't allow me, for > example, to use a Haskell block to create an asymptote figure which > then generates an image in the HTML or PDF export version. Is there > a way around this limitation? I had the similar wish some months ago. See thread http://www.mail-archive.com/emacs-orgmode-mXXj517/zsQ@public.gmane.org/msg35290.html for another use case. No idea about the rest of your email... > - Ruby: is inf-ruby really required? Why can't I execute a ruby block > without it? > > - Haskell: there are at least two interpreters that babel will invoke, > depending on what is available (ghci and hugs), and those two are > incompatible in some areas (such as loading modules, where the > commands are different -- :add vs. :load). I haven't found a way of > + forcing the use of a specific interpreter; > + specifying command-line arguments to the interpreter (which would > eliminate the need for :add or :load). > This really makes using Haskell rather hit-and-miss, see below. > > - Haskell code usage is rather cumbersome: since Babel invokes an > interpreter rather than runghc, a Haskell block doesn't nearly have > the flexibility of a real Haskell program. In particular, one can > only make definitions (portably) in the Haskell code by creating a > separate block which is tangled but not executed. Another block, > which is executed, can then load the tangled module and use its > definitions (if it weren't for the problems described above and > below). > > - The handling of interpreted Haskell appears to be rather dodgy: If I > want to load a module (in ghci) and then evaluate some function, > then I run into real trouble. None of my tests run at all when > first loaded into emacs, but if I execute some tests in a certain > order, it all starts working. I haven't been able to figure out yet > what goes wrong and what "playing around" makes things work, but it > appears that > #+begin_src haskell > :add SomeModule > someFunction > #+end_src > will not work because the :add statement is ignored. If I put the > two lines in separate Haskell blocks and execute each one > separately, then things start to work. > > - I also tried using sbe to invoke a Haskell function from within a > table formula. Here I usually get an error "ERROR - Undefined > variable "x"", which sometimes goes away rather magically (I'm not > sure what makes it go away), after which things work just fine. > Emacs-lisp blocks written in the same manner work out of the box. > > - Haskell uses a static type system, and there is no such thing as > automatic casting if a variable has the wrong type for a given > function. Thus, if I evaluate the numbers of a table using Haskell > and sbe, and some values have a decimal dot and other (integer) ones > omit it, then one of these versions will throw an error. Is there a > way of converting the values beforehand to a given type (say, > Double), only to make Haskell happy? > > Can anyone give me a hint of why these things don't work and whether > I'm doing something wrong? > > Oh, I'm using emacs from Debian testing (23.2+1-7) and org from git > (cloned today). Best regards, Seb -- Sebastien Vauban