2008-11-14

<hcarty> Ah
<hcarty> Or raise an uncaught exception or assert false
<hcarty> palomer: exit 0?
<hcarty> Camarade_Tux: Then everybody wins
<Camarade_Tux> hcarty, I know batteries depends on camlzip so that's really likely :)
<hcarty> I think camlzip is used for the existing (de)compression gzip support in Batteries so it doesn't add any new requirements
<Camarade_Tux> hcarty, right, good idea
<hcarty> Camarade_Tux: camlzip does support zip files and has an API for handling multiple files in a zip archive
<Camarade_Tux> hcarty, well, that'd mean the output of decompression will be a bit meaningless when using the general interface and having a multi-files archives
<hcarty> How would you indicate that a new file starts at the given position without adding tar (or similar) support?
<hcarty> You would need a different interface though, I would think
<Camarade_Tux> hcarty, separate interface will need more work =/
<hcarty> Camarade_Tux: That would probably be through a separate interface ... my understanding is that gzip is inherently single-file oriented
<hcarty> ertai: ping

2008-11-13

<hcarty> The camlp4+toplevel bug has been there since 3.10.0
<hcarty> Oh, definitely. 3.11 is still in beta I think.
<hcarty> It sounds like it was picking up another installation, but I could be wrong
<hcarty> Oh yes, I remember
<hcarty> Missing packages?
<hcarty> Or use godi
<hcarty> You could probably patch the Ubuntu deb sources and build it that way
<hcarty> s/from/with/
<hcarty> Which makes using camlp4 from the toplevel a royal pain
<hcarty> It's too bad this wasn't fixed sooner, since several fairly major distributions are releasing/have released with 3.10.x and they all have this bug
<hcarty> mbishop: Bugs #4495 and #4593, if you are at all interested
<hcarty> It is fixed in 3.11, and the relevant patch applies cleanly to 3.10.2 as well
<hcarty> It's a problem with the 3.10.x camlp4
<hcarty> That's an OCaml bug
<hcarty> mbishop:
<hcarty> |: works as well, and is perhaps less ugly
<hcarty> But I think they only cause problems when used in the syntax extension code
<hcarty> I'm not sure of the specific reasons why, but use of $ >> and a few other operators are frowned on. Something to do with camlp4 issues.
<hcarty> Something ugly like |/ would also work
<hcarty> +) 2)" will work as expected
<hcarty> As-is, though, some of the () can be removed for the example: "1 -- 10 |> map ((
<hcarty> I don't know if there is a suitable operator. There may be though.
<hcarty> I'm not sure if that can be done here without reverting to camlp4
<hcarty> olegfink: I suppose so
<olegfink> hcarty, so the 'fix' here would be to lower the priority of //?
<hcarty> mbishop: I think they use the forge bugtracker
<hcarty> olegfink: I have found |>'s low precedence to be a good thing in general, if not for this particular example
<hcarty> Or rather, a > b || b > c
<hcarty> The OCaml associativity in this case allows for (1 + 2 > 2 - 3) to work "as expected"
<hcarty> olegfink: Yes - the specific documentation is in the manual. Though I don't remember where

2008-11-11

<bluestorm> hcarty: hm, what's the link between batteries and pa-do ?
<hcarty> I'm planning on submitting the patches upstream some time in the next few days
<hcarty> The patches also make the extension work properly with a (patched) 3.10.2 toplevel or a 3.11.0 toplevel which already has several camlp4 + toplevel bugs fixed
<hcarty> bluestorm: Yoric[DT] said you are the one to talk to regarding camlp4 + Batteries. I have some patches for pa-do which add ocamlbuild support and expand the META file a bit if/when you integrate pa-do.
<hcarty> mbishop: Did you set your $PATH appropriately?
<hcarty> The documentation is an impressive (ab)use of ocamldoc
<hcarty> Batteries is looking very nice at this point and seems to have a promising roadmap. Thanks to those involved.
<hcarty> And it /has/ to be good if it takes 15 minutes to build :-)
<hcarty> thelema: This release is a bit more attractive than the last, with a selection of examples and better documentation to go along with it

2008-11-10

<hcarty> Yoric[DT]: Is the source fetched from a mirror that hasn't updated yet?

2008-11-09

<Yoric[DT]> hcarty: I'll take a look.
<hcarty> I use those functions most often for function argument checks. I'm not sure where they would go in Batteries though, if they are of interest
<hcarty> Along with a ( |? ) operator which I have found useful for handling default values for option types
<hcarty> Yoric[DT]: If you are interested, the verify (bool -> exn -> unit) function I asked about yesterday is pasted here: http://ocaml.pastebin.com/m14da9488
<Yoric[DT]> hcarty: it should be source-to-source compatible.
<hcarty> Or, the docs on the web do not seem to at least
<hcarty> The documentation does not seem to cover the Standard module
<hcarty> thelema: A list of what is exported by default from Batteries
<thelema> hcarty: you want a list of the symbols you've defined that clash with batteries?
<hcarty> Is this information listed in the Batteries documentation?
<hcarty> Like ( --- ) which I was using for floating point enums ... (1.0, 0.1) --- 2.0
<hcarty> I need to dig through what Batteries provides in its Standard library as well - I think there are some clashes with things I have defined locally
<hcarty> thelema: That's what I would expect. I'm just trying to see how difficult the switch will be since, for example, Enum.t for ExtLib is different as far as OCaml is concerned than Enum.t for Batteries.
<thelema> hcarty: batteries should replace extlib quite completely.
<hcarty> Yoric[DT]: Does using Batteries require switching completely away from ExtLib, since it embeds its own version?

2008-11-08

<Smerdyakov> hcarty, you don't have to choose unique messages. You get file and position information printed when the assertion fails.
<Smerdyakov> hcarty, then I recommend using [assert] instead.
<hcarty> But if a simple function or two come out of this and end up being useful elsewhere then so much the better
<hcarty> Smerdyakov: Not really. The code is related to my own research.
<Smerdyakov> hcarty, is this meant for library code, where clients would mind if you used [assert] instead?
<hcarty> Smerdyakov: Even better, thanks
<hcarty> Smerdyakov: Yes, though that doesn't hold for most other exceptions. In this case it helps a bit though.
<Smerdyakov> hcarty, you can already use [Pervasives.invalid_arg] to shorten it a little bit.
<hcarty> Smerdyakov: So, perhaps for this case at least, a "bool -> ()" would be better
<hcarty> Smerdyakov: I'm looking to shorten phrases like "... let () = if Array.length a = Array.length b then () else raise (Invalid_arg "crap!") in ..."
<Smerdyakov> hcarty, versions specialized to particular exceptions seem best.
<Smerdyakov> hcarty, but I suppose that might allocate a closure, too.
<Smerdyakov> hcarty, you might want to replace [exn] with [unit -> exn], to avoid allocating unused exceptions.
<Yoric[DT]> hcarty: don't hesitate to submit it :)
<hcarty> Yes, I want something more generic. It's simple to write, so I'll add it myself.
<hcarty> Thanks.
<hcarty> Yoric[DT]: Does Batteries include a general assert-like function? Something along the lines of "val verify : bool -> exn -> ()" which raises exn if bool is false?
<hcarty> It suggests "make byte opt doc install"
<hcarty> Perhaps the README should be updated then
<hcarty> Yoric[DT]: Ah, ok thanks
<Yoric[DT]> hcarty: we're using GODI policies here.
<Yoric[DT]> hcarty: oh, it's actually not an error :)
<Yoric[DT]> hcarty: that's true.
<hcarty> Yoric[DT], thelema: "make byte opt" does not seem to build pa_batteries, but a plain "make" does
<Yoric[DT]> hcarty: that's Batteries-specific.
<hcarty> thelema: Does this sound like an error on my end, or a Batteries bug/problem?
<hcarty> "Ocamlbuild knows of no rules that apply to a target named src/main/threads/Extlib_threads.odoc." with screens of "Failed to build all of these:" entries
<hcarty> Then a very long error from ocamlbuild
<hcarty> Lots of "Warning: Element File.open_out not found" and similar warnings
<hcarty> hcarty: Default branch? I git clone'd http://git.ocamlcore.org/batteries/batteries.git
<thelema> hcarty: which branch?
<hcarty> thelema: For someone who wants to try out Batteries, would you recommend the version in GODI or git? "make doc" is failing for me on git, but otherwise it seems to work properly
<hcarty> thelema: Thanks
<thelema> hcarty: batteries specific
<hcarty> Yoric[DT]: Regarding your blog-comment discussion with JDH, is the collection of open IO handles Batteries-specific, or part of OCaml?

2008-11-06

<hcarty> I'm not sure about that
<hcarty> flux: Ah, I see what you mean
<flux> hcarty, isn't it supposed to say Unbound value instead?
<hcarty> flux: That's how it is supposed to work, as I understand it
<flux> hcarty, I happened to have old code around that didn't use CalendarLib yet..
<flux> hcarty, yes
<hcarty> flux: module T = CalendarLib.Time_Zone;; works as expected though
<hcarty> Reference to undefined global `Time_Zone'
<flux> hcarty, so what happend when you enter #require "calendar";; module T = Time_Zone in the toplevel?
<hcarty> But I have noticed that it "pollutes" the ocamlbrowser interface somewhat
<hcarty> flux: I haven't had any trouble with the calendar package in godi through findlib

2008-11-03

<_zack> hcarty: that would be interesting indeed
<hcarty> I haven't taken the time to submit a request or patch
<hcarty> GODI may be willing to change, I don't know
<hcarty> _zack: Locally, I install a "compatibility" package zip which is just a META file requiring camlzip
<hcarty> _zack: camlzip
<_zack> hcarty: how is it called in GODI?
<hcarty> _zack: Sounds good. I'm just curious, as I've run up against the problem locally
<_zack> hcarty: I wasn't aware of that, but it can be handle at source configuration time
<hcarty> Yoric[DT] and _zack: How are you/are you handling the different findlib names for ocamlzip between GODI and Debian+Fedora?
<hcarty> palomer: PCRE?

2008-10-31

<Camarade_Tux> hcarty, *all* the examples show the same structure, I guess the filesystems have to be hierarchical, and that's exactly what I wanted to know, thanks :)
<hcarty> Fuse::DBI in particular
<hcarty> http://fuse.sourceforge.net/wiki/index.php/DatabaseFileSystems -- This has some examples which may be useful?
<Camarade_Tux> hcarty, from what I've seen, in fuse you give functions to read folders, open files, close them, ... so it would need folders
<hcarty> But having never programmed with fuse, this is mostly speculation on my part
<hcarty> Camarade_Tux: Given something like sshfs (I think that's the name?), there should be some mechanism for using non-file source material to populate the FS.
<hcarty> Actually, I'd be surprised if that weren't possible
<hcarty> Map tables to directories and such
<hcarty> But it may be possible to make, say, a database browser through fuse
<hcarty> I think it has to be mapped to files and folder from the user's perspective...
<Camarade_Tux> hcarty, LFS iirc
<hcarty> It was implemented in a way that the directory hierarchy acted as a search, IIRC
<hcarty> Camarade_Tux: There was a post on the mailing list about a filesystem implemented using OCaml + ocamlfuse some time ago

2008-10-28

<flux> hcarty, I suppose it _could_ work if the code works just as well with 31- and 63-bit integers
<hcarty> That's mostly speculation on my part... I don't know how that is handled in bytecode
<hcarty> They may not be 32 <-> 64bit cross-platform though

2008-10-27

<gildor> hcarty: in fact, this is the pointer dereferencement that make my program stopped
<hcarty> gildor: I ran in to something similar a while ago, but found out the CAMLparamX and CAMLreturnX requirements before I tracked down anything relating to ocaml_oldify_local_root or similar
<gildor> hcarty: I was stuck in ocaml_oldify_local_root from time to time
<hcarty> gildor: What were/are the problem and solution?

2008-10-26

<Camarade_Tux> hcarty, ok, thanks a lot
<hcarty> Compiling 3.10.2's labltk and related tools didn't work for me against 8.5 a while ago
<hcarty> Camarade_Tux: One of the Changelog notes for 3.11 is tcl/tk 8.5 compatibility, so I would guess no

2008-10-25

<hcarty> I've found camlidl to be most useful for "easy" functions - parameters which are no more complicated than multi-dimensional arrays
<hcarty> Camarade_Tux: Probably not without some hand-holding
<hcarty> So that could act as a base.
<hcarty> camlidl-produced output does require a (LGPL+linking exception, I think) runtime library
<hcarty> I've been able to work around most of the boundaries I've come across. But sadly the easiest way generally seems to just bind the problem function(s) by hand.
<hcarty> Or camlidl + CIL + things not written yet
<hcarty> flux: I think it has that internally
<hcarty> Sadly, none of these do much for callbacks from what I understand
<hcarty> And camlidl is helpful, despite it's occasional problems
<hcarty> Something like ciml (http://friggeri.net/blog/2008/02/26/ciml-c-in-ocaml) plus some project-specific code is probably a good start to an Easier OCaml C FFI (tm)
<hcarty> Yes, 2005 and OCaml 3.08.0. Though I don't know if that makes a difference for this project.
<hcarty> Ah, it's Saffire - http://www.cs.umd.edu/~furr/saffire/
<hcarty> It looks like it is rather invasive to use though. And I don't know how outdated it is.
<hcarty> flux: There is a project to check the type-safety of OCaml-C interfaces. I think it's called Saphire or something similar.

2008-10-24

<hcarty> I just started with lablgtk and GUI programming in general, so I'm still getting the hang of it
<doy> hcarty: the situation i'm having is that on my computer, i don't see any issues at all, but other people are getting duplicate button_press events
<hcarty> doy: Or, rather, I was. I think it was for entry and exit events.
<hcarty> doy: Regarding your earlier question, I think I may be getting doubled events in lablgtk on occasion, but I'm not sure if it's my fault or something else
<hcarty> Axle: I think that may be in one of the ocamlfind/findlib FAQs. I'm not sure though.

2008-10-21

<hcarty> palomer: I agree with Camarade_Tux -- why is that weird?
<hcarty> palomer: If it were illegal, then how would modules be extended?
<hcarty> I'm not sure why
<hcarty> Camarade_Tux: It doesn't seem to quit cleanly in the toplevel, whereas a well-behaved vanilla lablgtk app does
<Camarade_Tux> hcarty, I think that'd be more than enough, for advanced GUIs, you'd probably want more control and could build your own abstraction without spending much time (proportionnaly speaking) anyway
<hcarty> It looks like it would be relatively easy for a very simple GUI. I don't know how well it would work for anything advanced.
<Camarade_Tux> hcarty, have you looked at the test program source yet ?
<hcarty> Camarade_Tux: Indeed :-)
<hcarty> And now the FrGui test program builds! Nifty.
<hcarty> Camarade_Tux: I certainly will :-)
<hcarty> The problems are as much or more with GODI + camlp5, as no META file is installed by GODI
<Camarade_Tux> hcarty, nice ! pleeeaaase tell us about your experience when you've got a first application :)
<hcarty> With some massaging, Fr and FrGui build with GODI + OCaml 3.10.2 + Camlp5 3.08
<hcarty> At least, not through GODI
<hcarty> camlp5 does not seem to have ocamlfind support though
<hcarty> pos_cnum allowed Fr to compile
<hcarty> flux: If you have any idea, that is...
<hcarty> flux: Which of these elements do you think it should be? http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lexing.html#TYPEposition
<hcarty> flux: I hope so
<flux> hcarty, well, looks like simple to fix?
<hcarty> File "pa_fr.ml", line 24, characters 39-55:\nThis expression has type Lexing.position but is here used with type int
<hcarty> flux: I'm not sure? But it's used in the library code
<hcarty> The pa_fr extension does not compile as-is with camlp5 either, sadly
<hcarty> Curses. Old camlp4 is apparently part of the base Fr library.
<hcarty> Glade isn't as straightforward as I had hoped, so I'm using "raw" GUI building in the code. FrGui looks like it would be a potentially cleaner option.
<hcarty> I'm attempting a GUI with lablgtk (and Gtk+ in general) for the first time
<hcarty> flux: Yes, I'm considering it /if/ the task is relatively straightforward :-)
<hcarty> Has anyone here used FrGui from http://code.google.com/p/ocamlrt/ ? Specifically, is it usable with the latest lablgtk2 release(s)?
<hcarty> Congratulations to bluestorm, then :-)
<Yoric[DT]> hcarty: he was just admitted in the best Grande École in France, it may take him some time to get settled :)
<hcarty> Yoric[DT]: Ah, ok. I have not seen bluestorm around #ocaml in a while
<Yoric[DT]> hcarty: bluestorm is in charge of everything Camlp4 for Batteries.
<hcarty> Yoric[DT]: I have a few patches to submit upstream - but are you interested in/planning on including pa-do in Batteries?
<hcarty> Yoric[DT]: Since ertai has fixed the camlp4 + toplevel bugs (at least the ones that were giving me trouble), I have been playing with pa-do some more

2008-10-20

<Camarade_Tux> hcarty, I don't know yet how I'll deal with those packages, I'm making a livecd and nearing completion, my biggest problem is with some godi packages being unreachable at times though
<hcarty> Camarade_Tux: I've pulled them from source packages before. But as flux said, META files are generally very simple to write once you have done it a few times
<Camarade_Tux> hcarty, as far as I've seen, it's the case, however, I'm not using distribution packages
<hcarty> GODI, Fedora and Debian include META files for all of the libraries they have packaged, as I understand
<Camarade_Tux> hcarty, yes, second option I had in mind ;)
<Camarade_Tux> hcarty, lol, that's terribly true, I hadn't though of it :p
<hcarty> Camarade_Tux: Or ocamlfind + zsh, since "ocamlfind -list" gives you a list of package names usable in completion
<hcarty> Camarade_Tux: It may be easier to write the META file to make a library ocamlfind compatible than to add zsh expansion...
<hcarty> I haven't checked the specific numbers in a while
<hcarty> And probably a similar amount of bandwidth
<hcarty> mbishop: I provide a mirror. It's a few hundred megabytes of space
<Camarade_Tux> hcarty, afaik it's only fallback
<hcarty> Camarade_Tux: There are others, but I'm not sure how the selection logic works

2008-10-19

<hcarty> flux and thelema: I think ExtLib.List has a of_enum or similar function

2008-10-16

<hcarty> You can add the "-newer" option to only rebuild packages with newer versions available
<hcarty> postalchris: It's explained in the man page
<hcarty> postalchris: There is a "mark all upgradable" or similar option from within godi_console. I don't know the command line equivalent.
<hcarty> postalchris: What's the package, out of curiosity?
<hcarty> postalchris: And Camarde_Tux is right, you would have to update the outdated package yourself and submit it to a GODI maintainer, or request an update on the GODI mailing list
<hcarty> postalchris: I think the GODI docs have instructions on how to run each stage of the build process manually from the command line. That may help.
<postalchris> hcarty: that's right, the upstream version is more recent than the GODI version
<hcarty> postalchris: Or do you mean that there is a newer version available elsewhere than what is shown in GODI?
<hcarty> postalchris: Flag it for updating in godi_console?
<hcarty> -r = Put all words seen on in- and output on the completion list
<hcarty> flux: Yes
<hcarty> -D = History with duplicate lines eliminated
<hcarty> -c = Complete filenames
<hcarty> alias oc='rlwrap -r -c -D 2 ocaml'
<flux> hcarty, how do you activate it?
<hcarty> Just words that it has already seen
<hcarty> But it is not OCaml specific
<hcarty> kushal and flux: rlwrap does have some limited autocomplete support

2008-10-15

<rwmjones_> hcarty, no ... currently the C code is staticly linked
<hcarty> rwmjones_: Are the .so stubs used in native code OCaml binaries?
<hcarty> rwmjones_: Ok, thanks. I thought it was something like that
<rwmjones_> hcarty, these symbols are satisfied from the ocamlrun binary itself
<hcarty> Now if I can find out why to relieve their concerns
<hcarty> rwmjones_: But it seems to be normal for OCaml-related .so files
<hcarty> rwmjones_: I'm working on the PLplot bindings, and one of the library devs is concerned about the fact that the dllplplot_stubs.so has these missing symbols listed
<rwmjones_> hcarty, basically it's the same on a debian machine ... not sure if it's precisely the same symbols, but it looks very similar
<hcarty> rwmjones_: Specifically, all of the "undefined symbol: caml_*" lines
<hcarty> rwmjones_: Just a confirmation that is is more or less the same would be enough
<hcarty> rwmjones_: If possible, that would be great
<rwmjones_> hcarty, I think I've got a debian machine around if you want that too?
<hcarty> rwmjones_: That's plenty, thanks :-)
<rwmjones_> hcarty, I don't want to post the whole thing or freenode will kick me off for flooding :-(
<hcarty> rwmjones_: Thanks
<rwmjones_> hcarty, hey ... just a sec
<hcarty> in the output
<hcarty> I'm using godi and want to check something
<hcarty> Is someone here using the Debian or Fedora OCaml packages willing to paste the output from "ldd -r dllbigarray.so" for the dllbigarray.so (or any other C stub from the standard lib) to a pastebin?
<hcarty> I get them for all of the dll*_stubs.so files in my godi install - core libs, godi packages, and manually installed libraries
<hcarty> Are "undefined symbol: caml_alloc" and similar messages from "ldd -r dllsome-ocaml-c_stubs.so" normal?
<hcarty> Quadrescence: That's good to hear :-)
<Quadrescence> hcarty: Hehe, this seems to be working a lot nicer.
<hcarty> The user which will be using the godi install
<hcarty> Set the prefix to something in your home directory, and do everything as your user
<hcarty> Quadrescence: No, I would recommend installing as your user
<hcarty> It makes package management, for both godi and manually installed packages, simpler
<hcarty> I have it installed under ~/Applications/godi/ and added ~/Applications/godi/bin and sbin/ to $PATH
<hcarty> It isn't really designed for a "build as me, install as root" compilation and installation pattern
<hcarty> Unless you plan on sharing the install with several users on a system
<hcarty> Quadrescence: I'd recommend installing godi somewhere under $HOME
<hcarty> Quadrescence: Post them to a pastebin site and hopefully I or someone else here can help
<hcarty> Quadrescence: Yes

2008-10-14

<hcarty> ertai: And it should remove the need for workarounds for at least a few extensions (mikmatch, pa-do)
<hcarty> ertai: You are quite welcome. Thanks again for the fix! It has already helped me out
<ertai> hcarty: thanks for the testing!
<ertai> hcarty: only if 3.11 cause too much issues
<hcarty> ertai: Ok, I'll stick with my patched 3.10.2 for now then
<ertai> hcarty: No, a 3.10.3 release should not happen
<hcarty> Yoric[DT]: I think it's "camlzip" under godi and just "zip" in Debian and Fedora
<hcarty> I have a "fake" package I install under godi to match the Debian naming
<hcarty> Very, sadly
<Yoric[DT]> hcarty: gasp.
<hcarty> Yoric[DT]: An annoying problem, though, is that godi and Debian/Fedora use different ocamlfind names
<Yoric[DT]> hcarty: ok, good to know.
<hcarty> Yoric[DT]: ocamlzip is packaged for Fedora. I don't remember the package name though.
<hcarty> zbrown: Though that gives "true" on an empty string, which may not be what you want.
<hcarty> zbrown: String.fold_left (fun accu c -> accu && c = 'A') true "AAA";; maybe?
<zbrown> hcarty: ya something like that is what I have
<hcarty> zbrown: String.iter wrapped with try ... with ... ?
<Yoric[DT]> hcarty: probably extension code, although quotations/anti-quotations could be used as simple DSLs inside regular OCaml.
<hcarty> Yoric[DT]: Does it break extension code, or code written using camlp4 extensions?
<hcarty> Small tests seem to work, but I've only toyed around with it
<Yoric[DT]> hcarty: anti-quotations.
<hcarty> Yoric[DT]: I've heard that you can't use ( $ ) b/c of camlp4, but what does it break?
<Yoric[DT]> hcarty: great.
<hcarty> Yoric[DT]: ertai was kind enough to fix the #use "foo.ml";; + camlp4 toplevel-breaking bug in CVS HEAD. So syntax extensions seem to work properly in the toplevel now, with the patch applied.
<hcarty> ertai: Perhaps this change could make it in to 3.10.3, if there is such a release?
<hcarty> ertai: I also rebuilt my godi install with the patched 3.10.2, somewhere between 30 and 35 packages, with the patched 3.10.2 without issue. This includes the Jane St. sexplib and Martin Jambon's mikmatch.
<hcarty> ertai: The CVS unified diff applied pulled from the OCaml anonymous CVS web interface applied to 3.10.2, with the only broken piece being the revision comment at the start of the diff
<hcarty> ertai: Under OCaml 3.10.2 I have not run in to any errors. I have tested less (pa_do, standard and revised syntaxes) with CVS HEAD because of some godi/library issues that I have not had time to look in to
<hcarty> ertai: I've tried the Jane St. OSP pa-do project, pa_openin, other small extensions written by myself and others and the revised and standard syntax extensions from the toplevel and compiled code
<ertai> hcarty: Have you tried some more complex usage examples ?
<hcarty> ertai: You are quite welcome. Thank you! This is a huge help.
<ertai> hcarty: thanks!