Re: new parrot version?
Andy Dougherty [EMAIL PROTECTED] wrote: Here's another small update to README. This goes on top of [perl #30095]. Thanks. Applied: #30095 PLATFORMS update this one Abn removed the Configure hint WRT non-standard Perl5 types, which shouldn't be needed any more. leo
Re: [perl #31729] [BUG] Garbage collection bug tickled by Tcl?
Try again, please. In addition to fixing the incomplete commit below, I've committed the build runtime library with parrot ticket as well, so you'll need to do a re-configure build. On Tue, Sep 28, 2004 at 02:49:45PM +0200, Leopold Toetsch wrote: Will Coleda [EMAIL PROTECTED] wrote: oolong:~/research/parrot coke$ ./parrot languages/tcl/tcl.pbc [EMAIL PROTECTED]:~/src/parrot-leo/languages/tcl] $ make make: *** No rule to make target `lib/commands/unset.imc', \ needed by `lib/tcllib.pbc'. Stop. leo
Re: [perl #31752] [PATCH] 'dlvar' should not panic, test 'dlvar'
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: this patch adds two tests of the opcode 'dlvar' to t/pmc/nci.t. When a non-existing symbol is requested from a shared library, then 'dlvar' should not panic. Thanks, applied. leo
Re: Namespaces, part 1 (new bits)
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so we've got two points of dispute: 1) Jeff doesn't think the sigil should be part of the variable name Which isn't practicable. We can't strip off the sigil for perl5. It's part of the variable name, $foo and @foo are different items. If you want to use a perl5 module from Python which has both $foo and @foo exported, we can just pitch a fit. Everything else can be handled by the import module. And: we can't attach hints to the namespace lookup because you just don't know, if Python wants the scalar foo or the array foo. There is exactly one foo object that Python can use, that's it. Python allows only bare names in the import statement: from a import foo [ as a_foo ] but not: from a import @foo [ as a_foo ] 2) Both Jeff and Jonathan have pointed out that languages we care about *do* have a combined function/varname store. (Though class names/namespaces seem to be separate) No. Python just has names. Assigning something to a name binds that thingy to that name. At bytecode level there is almost no indication that you are working with classes except for the CBUILD_CLASS opcode (not shown below). E.g.: class A(object): def foo(self): pass a = A() a.foo() a = 7 The object instantiation is this: 5 22 LOAD_NAME1 (A) 25 CALL_FUNCTION0 28 STORE_NAME 2 (a) That's the method call: 6 31 LOAD_NAME2 (a) 34 LOAD_ATTR3 (foo) 37 CALL_FUNCTION0 And that's destroying the object by placing the object int(7) into the name slot a: 7 41 LOAD_CONST 2 (7) 44 STORE_NAME 2 (a) The tricky part of Python objects is now to create real Parrot objects out of it, which might be impossible for the general case. But for normal cases the method call translates to a real Parrot method call, with a method foo in namespace A. Such methods would be usable from Perl6 or other languages that use Parrot's object model. Internally CPython passes the object to the method implicitely as Perl5 does - as the first argument of the function. The only thing we can do is separate namespaces from names in it, so that the namespace A doesn't collide with the class A from the example above. But that's already Parrot internal, *if* the method foo is translated to: .namespace [A] .sub foo method ... .end Python per se doesn't have such a concept. It's more a matter of the HLL compiler that translates Python or Perl5 then anything else. leo
Re: Namespaces, part 1 (new bits)
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT If you want to use a perl5 module from Python which has both $foo and LT @foo exported, we can just pitch a fit. Everything else can be handled LT by the import module. LT And: we can't attach hints to the namespace lookup because you just LT don't know, if Python wants the scalar foo or the array foo. There LT is exactly one foo object that Python can use, that's it. LT Python allows only bare names in the import statement: LT from a import foo [ as a_foo ] LT but not: LT from a import @foo [ as a_foo ] you could use a priority ordering if two foo items are exported. something like code, scalar, array, hash, etc. not many cpan modules currently (AFAIK) export 2 things with the same basename. and since python is oo they would hopefully expect no imports at all (except for maybe constants which isn't pure oo then). or you can still pitch a fit. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Namespaces
Okay, after seeing all the back and forth, here's what we're going to do. Namespaces are going to be *simple*. They do two things, and only two things. 1) They provide a hierarchy for other namespaces 2) They bind names to PMCs That's it. No typing, no classification, no nothing. If languages want to do that, then they'd better darned well do it themselves. Yes, this is going to make interoperability a pain at the variable level, but it's pretty clear that we're just not going to be able to do that. The next step, then, is to sketch out ops to query, read, and write name/PMC bindings and query/read/write/overlay hierarchies. (Which, I realize, many languages just won't use, and that's fine) I think it's best to go with a unified hierarchy/variable namespace, so we'll postpend a NUL to the end of non-variables. Printing NULs is a pain, so we should make sure that we've got good general-purpose binary printing routines people can use. Yes, I know, we could do better. If anyone wants to do so, go lock Larry, Matz, and Guido in a room together. When they hash out the language semantics we'll let 'em out and then do better. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #31765] Failure related to ncurses
# New Ticket Created by Andy Dougherty # Please include the string: [perl #31765] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31765 With the recent root Makefile patch to build stuff in runtime/parrot/library, I'm now getting the following failure (split to avoid long lines) ./parrot -o runtime/parrot/library/ncurses.pbc \ runtime/parrot/library/ncurses.imc Couldn't load 'runtime/parrot/libncurses': \ ld.so.1: ./parrot: fatal: runtime/parrot/libncurses: \ open failed: No such file or directory The biggest problem with the message is that it never tells you exactly *which* file was not found. In this case, the problem turns out to be the statement in runtime/parrot/library/ncurses.imc: loadlib $P1, 'libncurses' which *assumes* that my 'curses' library is called 'libncurses'. It's not. On Solaris, for example (and probably on most SVR4-related systems), it's simply 'libcurses'. Where and how to fix this is a bit of a problem. Obviously, it's a Configure.pl issue to figure out which library to use. But beyond that, it's unclear to me exactly where to put that new information and what to do with it. In the runtime/parrot/library/ directory, the string 'libncurses' appears in three different files: ncurses.declarations:libncurses.so ncurses.imc:loadlib $P1, 'libncurses' ncurses.pasm:loadlib P1, 'libncurses' Changing it in one has no obvious affect on the others. I can't find any documentation about the .declarations file at all, nor how (or whether) the .imc and/or .pasm files are generated from the .declarations file. Are all of them needed? If so, then the .declarations file also needs to be changed to have a more general suffix instead of just .so. Or should we just skip it for now as we skip SDL and postgres? In any case, a better error message would sure help tracking down things like this. -- Andy Dougherty [EMAIL PROTECTED]
System ICU
Hi all, Configure.pl should now detect a system ICU installation. It uses the icu-config script to gather the neccessary information. If icu-config is not in your path, you can use the --icu-config=/path/to/icu-config configure option. You do not need to specifiy any other ICU related options in this case. You can use --icu-config=none if you want do disable the autodetect feature. jens
System ICU
Hi all, Configure.pl should now detect a system ICU installation. It uses the icu-config script to gather the neccessary information. If icu-config is not in your path, you can use the --icu-config=/path/to/icu-config configure option. You do not need to specifiy any other ICU related options in this case. You can use --icu-config=none if you want do disable the autodetect feature. jens
globals
Currently, Parrot_find_global throws and internal_exception, which is IMO not good. I have a patch ready that adds a void *next parameter to - Parrot_find_global - Parrot_store_global and adds - Parrot_find_global_nspmc (PMC *namespace instead of STRING *namespace) - Parrot_store_global_nspmc (PMC *namespace instead of STRING *namespace) Instead of an internal_exception, a real_exception is used. void *next points to the next instruction that is executed if the exception is resumed. The problem is that next is NULL in most cases. I am not sure if it is better add a seldom used parameter, or to implement distinct functions with and without a next parameter. The first variant is implemented and ready to be committed. jens
Re: Namespaces
On Wed, Sep 29, 2004 at 10:25:29AM -0400, Dan Sugalski wrote: : best to go with a unified hierarchy/variable namespace, so we'll : postpend a NUL to the end of non-variables. Well, I'd prepend the null just to reduce confusion (or rather, to force the confusion earlier), but guess I really don't care. Name mangling namespace variables is not going to be in anyone's inner loop all that terrible often. Perl folks could in theory just install a %foo:: variable that aliases to the namespace, but that only gives us easy access to our own namespaces. Mangling will let anyone get at anyone else's namespaces using their own notation. Larry
Re: System ICU
--- Jens Rieks [EMAIL PROTECTED] wrote: Hi all, Configure.pl should now detect a system ICU installation. It uses the icu-config script to gather the neccessary information. If icu-config is not in your path, you can use the --icu-config=/path/to/icu-config configure option. You do not need to specifiy any other ICU related options in this case. This broke for me: c++ -o parrot.exe -s -L/usr/local/lib imcc/main.o blib/lib/libparrot.a -lcrypt -lgmp -lpthread -lm -L/usr/local/lib -licui18n -licuuc -licudata -lpthread -lm /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld: cannot find -licui18n I would propose that if Configure.pl does see any other icu config flags that it not attempt to auto configure. You can use --icu-config=none if you want do disable the autodetect feature. That's what I am doing for now jens Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Re: System ICU
On Wednesday 29 September 2004 18:40, Joshua Gatcomb wrote: cannot find -licui18n I am not sure, is this library used by parrot? I would propose that if Configure.pl does see any other icu config flags that it not attempt to auto configure. Done. Thank you for your proposal! jens
Re: System ICU
--- Jens Rieks [EMAIL PROTECTED] wrote: On Wednesday 29 September 2004 18:40, Joshua Gatcomb wrote: cannot find -licui18n I am not sure, is this library used by parrot? I have no idea - first I have seen it other than when I built ICU many moons ago. I would propose that if Configure.pl does see any other icu config flags that it not attempt to auto configure. Done. Thank you for your proposal! Thanks/Welcome jens Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Re: globals
Jens Rieks [EMAIL PROTECTED] wrote: Currently, Parrot_find_global throws and internal_exception, which is IMO not good. Where? The Parrot_find_global() function returns NULL in failure case. Parrot_get_global() throws a real execption. I have a patch ready that adds a void *next parameter to - Parrot_find_global That's what Parrot_get_global() already has. - Parrot_store_global Parrot_store_global() shouldn't really fail. and adds - Parrot_find_global_nspmc (PMC *namespace instead of STRING *namespace) - Parrot_store_global_nspmc (PMC *namespace instead of STRING *namespace) Let's wait for namespace implementation after 0.1.1 is out. jens leo
Real/internal Exceptions
Hello, Just wondering (again), in order to be able to follow discussion on matters: What is the difference between an internal exception and a real exception (as if the first one isn't a real exception...). I suspect a real exception is a exception object that a user program also can create (so try/catch/finally blocks translate to Real Exceptions being thrown). Thanks, Klaas-Jan
Threads on Cygwin
Up until a couple of weeks ago, all the threads tests were passing on Cygwin. I had submitted a patch some time ago that never got applied enabling tests for threads, timer, and extend_13 that never got applied. I figured there was good reason so I didn't say anything about the tests failing except an occasional that's weird on #parrot. So today I decide to look at threads_2.pasm It says at the bottom that the output could appear in reversed order and so I am guessing the sleep statement is to ensure that it comes out in the proper order. So - why is the test failing? Because the second print statement never makes it to the screen. If I remove the print statement entirely, I see both things in the reverse expected order. If I place the sleep statement after the main thread print then all I get to the screen is the that and not the print statement from thread 1 It is almost as if by the time the time the second print happens, the filehandle is already closed So - since threads aren't officially supposed to be working on Cygwin - is this something I should care about or not? Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Re: Threads on Cygwin
--- Joshua Gatcomb [EMAIL PROTECTED] wrote: Up until a couple of weeks ago, all the threads tests were passing on Cygwin. I had submitted a patch some time ago that never got applied enabling tests for threads, timer, and extend_13 that never got applied. I figured there was good reason so I didn't say anything about the tests failing except an occasional that's weird on #parrot. So today I decide to look at threads_2.pasm It says at the bottom that the output could appear in reversed order and so I am guessing the sleep statement is to ensure that it comes out in the proper order. So - why is the test failing? Because the second print statement never makes it to the screen. If I remove the print statement entirely, I see both things in the reverse expected order. If I place the sleep statement after the main thread print then all I get to the screen is the that and not the print statement from thread 1 It is almost as if by the time the time the second print happens, the filehandle is already closed So - since threads aren't officially supposed to be working on Cygwin - is this something I should care about or not? Cheers Joshua Gatcomb a.k.a. Limbic~Region In summary, all code in all threads runs to completion but whichever thread finishes last can't print to the screen $ perl t/harness --gc-debug --running-make-test -b t/pmc/threads.t Failed 7/11 tests, 36.36% okay (less 2 skipped tests: 2 okay, 18.18%) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/pmc/threads.t7 1792117 63.64% 2-3 5-9 2 subtests skipped. Failed 1/1 test scripts, 0.00% okay. 7/11 subtests failed, 36.36% okay. __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Parakeet 0.3
Parakeet is an object-oriented Forth-like stack language for the Parrot VM. It is written in PIR and compiled its code directly to PIR. Parakeet lets you do logical, numeric and string operations and comparisons, conditionals and loops, define variables, functions, classes methods, create instanciate and call methods on objects. Parakeet is Forth-like, but not anything like standard Forth, it is very machine specific to Parrot, building directly upon Parrot's machine semantics, not on those of late-80s micro-processors. Parakeet, for example, provides no words '@' and '!' as direct access to memory does not exist in Parrot. Data is stored and retrieved by holding references to objects like in many other OO languages. 0.3 is a major rewrite over previous versions of Parakeet. In particular, the code is much leaner now due to me removing a key design stupidity in my inline code generation. The entire language, README, and test script gzips into less than 10K. Parakeet is to the point now (I hope) where people can use it to experiment with and experience Parrot from a different perspective. The interactive PIR and opcode tracing is a particularly effective way of playing almost directly with the Parrot VM. To start playing with an interactive Parakeet interpreter, unzip the tarbal somewhere where parrot can find the 'parakeet.imc' file execute that file with the Parrot interpreter. -Michel -- Note: I use Active Spam Killer. That means the first time you send me an email, you will get a confirmation message that you must reply to in order for your mail to be delivered to me. http://www.paganini.net/ask/ parakeet0-3.tgz Description: application/compressed-tar
Re: Namespaces
On Sep 29, 2004, at 7:25 AM, Dan Sugalski wrote: Okay, after seeing all the back and forth, here's what we're going to do. Namespaces are going to be *simple*. They do two things, and only two things. 1) They provide a hierarchy for other namespaces 2) They bind names to PMCs That's it. No typing, no classification, no nothing. By postpending a null character, below, you _are_ doing typing/classification, of course. And, what about subs? If languages want to do that, then they'd better darned well do it themselves. Yes, this is going to make interoperability a pain at the variable level, but it's pretty clear that we're just not going to be able to do that. The next step, then, is to sketch out ops to query, read, and write name/PMC bindings and query/read/write/overlay hierarchies. (Which, I realize, many languages just won't use, and that's fine) I think it's best to go with a unified hierarchy/variable namespace, so we'll postpend a NUL to the end of non-variables. Printing NULs is a pain, so we should make sure that we've got good general-purpose binary printing routines people can use. As Larry said, it's best to prepend it. And then we can call it a sigil. And since we're name mangling, pick a printable character like : for the prefix, since we'll know the initial character is always really a throw-away encoding of the syntactic category. Then we're back to _exactly_ my scheme, with the syntactic category names as single characters, and as an implementation detail shoving the category and name together in a single string instead of keeping them separate. And of course this will all be awkward for languages with distinct syntactic categories, but without natural name mangling. And it will probably result in more intermediate strings being allocated. This is exactly like open(IN, file) v. open(IN, , file), and we're deciding that the former is vastly superior. And of course, you do realize that in Perl5, this: $data[1] refers to the variable @data, so that even for Perl5 there will be name-mangling (not just the ability to use the literal sigil-plus-namae as seen in the source). Yes, I know, we could do better. If anyone wants to do so, go lock Larry, Matz, and Guido in a room together. When they hash out the language semantics we'll let 'em out and then do better. :) We don't need Larry, Matz, and Guido to agree on anything here. I explained a scheme which would work for all of their languages, as well as Scheme, Common Lisp, Objective-C, Java, C, and probably anything else. It just requires acknowledging that different languages have different sets of syntactic categories, rather than pretending things are simpler than they are. JEff
Re: Namespaces, part 1 (new bits)
On Sep 29, 2004, at 2:53 AM, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, so we've got two points of dispute:
1) Jeff doesn't think the sigil should be part of the variable name
Which isn't practicable. We can't strip off the sigil for perl5. It's
part of the variable name, $foo and @foo are different items.
Those statements don't follow from one another. :)
First off, Perl5 doesn't describe itself that way. The Camel states,
Note that we can use the same name for $days, @days, and %days without
Perl getting confused. I'm asserting that it works perfectly well (and
seems to have been the original intent) to say that Perl allows for a
scalar, a hash, and an array all named foo, and the grammar always
makes it clear which one you mean (mostly, via sigils).
So it's true that $foo and @foo are different items, but that can be
stated as, the scalar 'foo' and the array 'foo' are different items,
with the same names. (Just like there can be both a person named
April and a month named April in English.)
Here are some further demonstrations that the seeming intent of Perl5
is not to treat the sigil as actually part of the name, but as a
feature of the grammar which indicates the syntactic category of the
name:
$hello and ${hello} are the same thing, but $hel{lo} is not -- the
name can separate from the sigil
$array[1] refers to @array, not $array -- the sigil changes depending
on context, even for a given item
Secondly, Perl just clouds the issue, since it _could_ work either way.
For other languages, you have distinct syntactic categories, but
without the name decoration. For example, in Common Lisp, this:
(foo foo)
means, call the function foo, and pass the variable foo as an
argument. So if the function foo doubles numbers, and the variable
foo is set to 11, then the above evaluates to 22.
The reason I'm taking this as important, despite Common Lisp's not
being a target language for Parrot, is that it's pointing out that
namespaces across languages have the concept of dealing with multiple
syntactic categories, though the number of such categories varies
between languages. Ruby and Python are simple--they have unified
namespaces, or so it seems--and Perl has a syntax which allows us to
pretend that it has a unified namespace, although I think that's
stretching the truth. (And, I think there's still an issue with
namespace names and sub names, since they don't have sigils in the
grammar--at least not as normally written.) But other languages aren't
so simple, and if we oversimplify our treatment of namespaces, then we
end up with something less elegant and less flexible that we could
have.
If you want to use a perl5 module from Python which has both $foo and
@foo exported, we can just pitch a fit.
We should be able to handle accessing either, if Python provides a
syntax for doing so.
And: we can't attach hints to the namespace lookup because you just
don't know, if Python wants the scalar foo or the array foo. There
is exactly one foo object that Python can use, that's it.
That's not accurate, and it's not a hint, it's a demand--the programmer
should know exactly which one he wants (which is especially true if you
are trying to think of the sigil as part of the name). Possible
syntaxes within Python:
a = lookupPerlScalar(foo);
b = lookupPerlSub(foo);
c = lookupPerlArray(foo);
or its:
a = lookupFromPerl(scalar, foo);
or it's:
a = lookupInParrotNamespace(Perl, scalar, foo);
Since Python deals in references only, assignment syntax could work
just fine for this, but if someone wanted a more aliasing-like syntax,
it could work like what Chip suggested in another thread:
parrot_alias(a, 'b', # dest: Python is unified, no need
for a category here
a, 'b', 'scalar') # src: Perl is not unified, so
source category is required
parrot_alias(a, 'c',
a, 'c', 'array')# here's a different category, to
get '@c'
or some such. Yes it's ugly. But if we can't fix a ditch, the least
we can do is put a big friendly warning sign on it.
I've lost hope for transparent aliasing, but it would work partially so
say, imports from Perl to Python can automatically alias scalars to
Python variables of the same name, but arrays and hashes you have to
pull in manually, and alias to an explicitly-specified name on the
Python side.
It will never just work for all things, since this is a valid
identifier in Common Lisp: *foo-foo*
So to exploit the full power of Parrot, languages will need to have
syntaxes/functionality/API to access foreign namespaces, but things
could be made transparent for at least a subset of variables. (And as
an example, not _all_ identifiers in Common Lisp are so exotic.)
Python allows only bare names in the import statement:
from a import foo [ as a_foo ]
but not:
from a import @foo [ as a_foo ]
This seems to make things worse for treating the sigil as part of the
name,
Re: System ICU
Jens - Thanks for putting this in. (ah, if only I had a system ICU to take advantage of!) FYI, the line `icu-config --exists`; generates a message to stderr, which un-prettifies the configure output: Testing snprintf .done. Configuring ICU if requested..Can't exec icu-config: No such file or directory at config/gen/icu.pl line 42. done. Joshua Gatcomb wrote: --- Jens Rieks [EMAIL PROTECTED] wrote: On Wednesday 29 September 2004 18:40, Joshua Gatcomb wrote: cannot find -licui18n I am not sure, is this library used by parrot? I have no idea - first I have seen it other than when I built ICU many moons ago. I would propose that if Configure.pl does see any other icu config flags that it not attempt to auto configure. Done. Thank you for your proposal! Thanks/Welcome jens Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Re: Namespaces again
[Argh...]
Chip Salzenberg [EMAIL PROTECTED] wrote:
parrot_alias(a, 'b', # dest: Python is unified, no need for a
category here
a, 'b', 'scalar') # src: Perl is not unified, so source category
is required
parrot_alias(a, 'c',
a, 'c', 'array')# here's a different category, to get '@c'
or some such. Yes it's ugly. But if we can't fix a ditch, the least
we can do is put a big friendly warning sign on it.
It seems to me that a much easier way to handle this would be to
mangle Perl variables to something that most languages *can* access:
$foo=s_foo
@foo=a_foo
%foo=h_foo
foo=f_foo (for function)
::foo=n_foo (for namespace)
Yes, n_File.n_Path.f_new() is uglier than File.Path.new, but at least
there's no ambiguity.
Another way to do it would be to have each category actually be a
namespace. In other words, Perl's namespaces are structured like
this:
File = package {
ns = package {
Find = package {
sub = package {
find = { ... }
}
},
Path = package {
sub = package {
BUILD = { ... },
DESTROY = { ... }
}
}
...
},
scalar = package {
some_idiot = put a variable in this package
}
}
And Python would access them like so:
File.ns.Path.sub.new()
Not perfect, certainly, but it would work, and be reasonably elegant.
(This does pose a problem going the other way, but I suspect Perl
could simply mark its own packages in some way, and fall back to a
simpler scheme, such as ignore the sigil, when it's munging another
language's namespaces.)
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
