On Wed, Jul 13, 2005 at 17:23:28 -0600, John Williams wrote:
The proposals so far have dealt mostly with the SQL itself, and
supporting database-neutral layers on top of DBI.
Personally, I don't mind writing the SQL myself, I rarely need to make
a particular statement work on two databases
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote:
Certainly. The problem is that there are too many viable alternatives,
and half of everyone hates half of the alternatives.
You will know I'm no longer a benevolent dictator when I start to enjoy
watching people squirm every time I change my
On Jul 12, 2005, at 15:59, Will Coleda wrote:
Hey, Allison - you drafted up the project plan for TPF grant for
parrot, neh?
Yup. With a good deal of input from Dan, Leo, Patrick and others.
Are you the defacto Project Manager for parrot? Or is that position
unfilled?
Indeed I am. Parrot
On Wed, 13 Jul 2005, Ingo Blechschmidt wrote:
no, if I understood Larry correctly, you can of course write a nice
grammar-modifying module, but other modules you use() still use
Perl 6's standard grammar. E.g.:
Ah, then of course I would have never expected things to be different at
all.
# New Ticket Created by jerry gay
# Please include the string: [perl #36530]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36530
make failure using win32--msvc-7.1--perl-5.8.6. the last few lines of
the build
# New Ticket Created by jerry gay
# Please include the string: [perl #36531]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36531
t\src\manifest.ok 2/5
t\src\manifest.NOK 4#
Applying the attached patch (Nick Glencross's changes to
dynclasses_pl.in modified by Matt Diephouse's suggestion and then
cargoculting H.Merijn Brand's voodoo for working around some weirdness
that caused Test::Harness to completely empty @INC) to 0.2.2 lets me
build and limp through make test.
Larry Wall [EMAIL PROTECTED] writes:
On Tue, Jul 12, 2005 at 08:48:41PM +0300, Gaal Yahas wrote:
: I propose to throw away the filesystem coupling, and map from a more
: general name of the bit of code we are requiring to a more general
: description of which instance of it we actually got.
The permission denied message stems from the DLLs not having execute
permissions, which is the same as the existing problem with HP-UX.
http://rt.perl.org/rt3/Ticket/Display.html?id=36119
I did actually manage to get most of the dynclasses to pass 'make test'
by partly hacking Makefiles and
On Tue, 2005-07-12 at 14:00 -0700, Michael G Schwern wrote:
I've also
attempted to contact the Inventors listed on the patent (valid email
addresses are difficult to find these days) in the hopes of discussing
this
programmer-to-programmer and cut through the legal BS. Haven't heard
back
On Thu, Jul 14, 2005 at 01:45:11PM +0300, George Nistorica wrote:
My guess is that you could add a comment here:
http://gauss.ffii.org/PatentView/EP1170667/Comments?action=editbackto=PatentView/EP1170667
and express your point of view.
I hope this patent will not be granted ...
Its already
On Thu, 2005-07-14 at 03:52 -0700, Michael G Schwern wrote:
On Thu, Jul 14, 2005 at 01:45:11PM +0300, George Nistorica wrote:
My guess is that you could add a comment here:
http://gauss.ffii.org/PatentView/EP1170667/Comments?action=editbackto=PatentView/EP1170667
and express your point of
Guys,
As suggested, here are some manual steps which can get a few more tests
passing on cygwin. The 'problem' is that the dynclass DLLs when loaded
cannot access symbols in the parrot executable, so libparrot.dll needs
building and the dynclasses linking against it.
If there turns out to
One final note. Unlike 'make dynclasses-test', 'make test' will spot
that libparrot.a has been deleted and rebuild it and parrot.exe.
You might want to finish up with:
11. make
12. Repeat step 4.
13. make test
All very hacky, I know.
Cheers,
Nick
Nick Glencross wrote:
Guys,
On Jul 14, 2005, at 3:15 AM, Allison Randal wrote:
On Jul 12, 2005, at 15:59, Will Coleda wrote:
Hey, Allison - you drafted up the project plan for TPF grant for
parrot, neh?
Yup. With a good deal of input from Dan, Leo, Patrick and others.
Are you the defacto Project Manager
On Thu, Jul 14, 2005 at 10:26:54AM -0400, Will Coleda wrote:
I have a .. few.. questions for you. Hopefully none of them are
*overly* snarky. Some progress has been made dealing with issues like
Being snarky on a public mailing list is not a good way to win friends an
influence people. You
As of r8617, the GC bug that ParTcl occasionally tickled has been
fixed. This is a relief as it caused some odd behavior and many hours
were spent by Will Coleda and Leo trying to debug.
Thanks to both of them for their efforts and thanks to Leo for finally
catching the bug!
--
matt diephouse
Greg Bacon wrote:
Applying the attached patch (Nick Glencross's changes to
dynclasses_pl.in modified by Matt Diephouse's suggestion and then
cargoculting H.Merijn Brand's voodoo for working around some weirdness
that caused Test::Harness to completely empty @INC) to 0.2.2 lets me
build and limp
Nicholas Clark wrote:
There were some PMC vtable changes recently. Are any more expected, or is
the vtable size/disposition expected to remain unchanged from here on?
I expect some additional PMC-only vtable functions needed for representing:
*) $n = +$x;
*) $s = ~$x;
*) $b = ?$x;
We
Nicholas Clark wrote:
However, I'm still stuck on:
#define ponie_pmc(pmc) ??? here ???
pmc-vtable-flags PONIE_BIT?
Nicholas Clark
leo
Nicholas Clark wrote:
Is the PMC layout likely to remain stable? There's been talk of minimal
PMC heads (data, vtable) in relation to the generational garbage collector
proposals. Is this likely to happen? Related to this there has been talk of
variable sized bodies.
I'd like to have a small
On 7/14/05, Juerd [EMAIL PROTECTED] wrote:
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation, let me just
give up my baby to the other woman by saying:
* It's
If this were a straw poll, I'd say...
1. Meaning of $_
.method should mean $_.method always. Making it into a runtime
error is extremely awkward; a compile-time error with detailed
explanataion is acceptable but suboptimal.
2. Topicalization of $?SELF
Neutral on this -- I can
On 7/14/05, Sam Vilain [EMAIL PROTECTED] wrote:
Of course it will be entirely possible to layer support for this sort of
thing atop any DBI interface;
Exactly my point. Please be so kind as to implement your ideas in a
DBI extension. Time and community will prove whether you are right by
using
Nicholas Clark wrote:
I'd like to be able to provide this as a non-singleton PMC class, with the
addition of a value lookup, and (possibly) iteration. But cut and paste is
evil.
Well, the more general question is: how can we parameterize our
aggregates. We already have tons of arrays with
Nicholas Clark wrote:
What is the state of signals and events support? As far as I can tell from
watching which perl 5 regression tests fail or hang under parrot, currently
parrot can't behave as a passive embedding target - it assumes that it needs
to take ownership of all signals.
Parrot
# New Ticket Created by Simon Marlow
# Please include the string: [perl #36548]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36548
Hi,
I've been trying in vain over the last day or so to reproduce the
following
chromatic wrote:
On Wed, 2005-07-13 at 15:41 +0100, Nicholas Clark wrote:
Did anything come of this? Or is chromatic still waiting in the wings for
confirmation that this is the right way to go?
I'm still waiting for confirmation. I can send my existing (needs
polish) patch if that will
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: Manhattan distance is
better.
Damian writes:
Similarly, since the number of potential variants is the
On Wed, 13 Jul 2005, Juerd wrote:
Dave Whipp skribis 2005-07-13 8:44 (-0700):
Within a method or submethod, C.method only works when C$_ =:=
$?SELF.
C.method is perfectly legal on *any* topic anywhere that $?SELF
doesn't exist.
Just to be clear, this includes any method/submethod
On Thu, Jul 14, 2005 at 11:09:40AM +0100, Piers Cawley wrote:
: So long as there's some way of asking the garbage collector for everything in
: the live set so you can grep through them I'm sure you're right. Because
almost
: everything is extensible at runtime a class is going to need some way
On Thu, Jul 14, 2005 at 09:19:29AM +0800, Autrijus Tang wrote:
: Within perl 5, there is an extremely easy way to write that, namely
: coderef in @INC that provides line-based filtering:
:
: http://search.cpan.org/dist/Acme-use-strict-with-pride/pride.pm
:
: Are we to discontinue use of
On Jul 14, 2005, at 17:31, Leopold Toetsch wrote:
Could folks with some windows fu and ci permissions please take care
of win32 patches. I can't test it.
Another note: if you (aka a windows hacker, person-unspecific) don't
have svn ci permissions, and can test and manage windows related
On Jul 14, 2005, at 7:26, Will Coleda wrote:
MUahahahahaha, my trap has been sprung! Perfect. I've been looking for
you since before we lost Dan. =-)
Had I know this at the conference, I would have had a much longer
conversation with you. =-)
I can't say I've ever made any secret of the
In message [EMAIL PROTECTED],
Nick Glencross via RT writes:
: One final note. Unlike 'make dynclasses-test', 'make test' will spot
: that libparrot.a has been deleted and rebuild it and parrot.exe.
:
: You might want to finish up with:
:
: 11. make
:
: 12. Repeat step 4.
:
:
This is more a note to collective 'self' question than one I expect the
answer to right now. (The answer I expect right now is a glib it will)
How will the perl6 compiler cope with people creating threads inside
BEGIN blocks?
Whatever the docs say, people do it in Perl 5 as soon as someone CUses
I have uploaded asynchronous::universal::ready and
asynchronous::universal::set_callback
to CPAN. They are both entirely trivial packages with a mess of
documentation. The
idea behind them is to support asynchonous frameworks in which the
immediate result
of passing away a message is a
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote:
On 7/14/05, Juerd [EMAIL PROTECTED] wrote:
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation,
Nathan Gray skribis 2005-07-14 12:55 (-0400):
Autrijus joked? about $?.method once (instead of ./method), in case we
need any more bad alternatives for $?SELF.method. But I also trust
@larry, or %larry, or even $larry, to make a decent choice that will
serve the community well.
Would this
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
: currently is:
:
: From inside another method or submethod:
:
: - a submethod should only be called from the class which defines it.
This doesn't sound right to me.
Ah, thank you for your quick reply!
On Jul 14, 2005, at 2:56 PM, Allison Randal wrote:
On Jul 14, 2005, at 7:26, Will Coleda wrote:
MUahahahahaha, my trap has been sprung! Perfect. I've been looking
for you since before we lost Dan. =-)
Had I know this at the conference, I would have
On 7/14/05, Nicholas Clark [EMAIL PROTECTED] wrote:
This is more a note to collective 'self' question than one I expect the
answer to right now. (The answer I expect right now is a glib it will)
How will the perl6 compiler cope with people creating threads inside
BEGIN blocks?
A glib it
Hi,
Luke Palmer wrote:
On 7/14/05, Nicholas Clark [EMAIL PROTECTED] wrote:
This is more a note to collective 'self' question than one I expect
the answer to right now. (The answer I expect right now is a glib it
will)
How will the perl6 compiler cope with people creating threads inside
On Thu, Jul 14, 2005 at 12:14:57PM -0600, John Williams wrote:
: Actually I took his question to be:
:
: If I explicitly name my invocant in the method signature, does that give
: the compiler enough assurance that I'm not going to use .method to mean
: $?SELF.method, and it will allow me to
On Thu, Jul 14, 2005 at 03:27:53PM +1200, Sam Vilain wrote:
: Can I present an alternative way of viewing them, which I don't think
: contradicts with what I've understood of them so far from the
: Apocalypses and Synopses documents.
:
: First a couple of definitions;
:
: A runtime class is a
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: A submethod is simply a method that says These
: aren't the droids you're looking for if you call it via either SMD
: or MMD dispatch and the first invocant isn't of the exact run-time
: type of the lexical class. In other words,
On Thu, Jul 14, 2005 at 04:32:13PM +0100, Nicholas Clark wrote:
: How will the perl6 compiler cope with people creating threads inside
: BEGIN blocks?
Probably break, if they meant INIT. I can't think of a static way
to detect that offhand, so I'm okay if we just call it erroneous.
Or maybe
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK!
Larry Wall skribis 2005-07-14 13:39 (-0700):
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous.
Thus it never means $?SELF.foo without $_ being
Yuval Kogman skribis 2005-07-15 1:09 (+0300):
use dot;
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
Agreed.
I don't want to be using a language
Leopold Toetsch [EMAIL PROTECTED] wrote:
I'd be glad if folks can go through the failing tests (one exception tests
hangs) and change old PASM call syntax to new.
It's a drop in the ocean, but attached patch fixes one that's been missed.
Here's the test output on Win32 with MSVC++ for the
Haskell has this very nice consistency I'll diverge into perl
terms...
The 'Show' role provides consistent stringification semantics for
any type that does the role. It can even 'derive' the role, getting
a method autogenerated.
The 'Ord' role provides semantics for ordered types. A typical
I'd like to document the optimization pipeline thing I brought up in
the hackathon...
The intent is to plan how to balance throughput with responsiveness
for a language that has such a broad range of dynamic to static
typing as Perl 6 will is.
With such behavior the amount of optimization you
Luke wrote:
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: Manhattan distance is
better.
That was never my *argument*, merely my statement-of-position.
Yuval Kogman wrote:
- optimizers stack on top of each other
- the output of each one is executable
- optimizers work in a coroutine, and are preemptable
- optimizers are small
- optimizers operate with a certain section of code in mind
...
Optimizers
There may be some tie-in with STM here too, where a particular
optimization doesn't commit if the optimization gives up in the middle,
or is preempted before it gets done. But maybe it's all done with
cooperative multitasking. (But maybe STM is how they cooperate...)
Just a half-baked thought.
On Thu, Jul 14, 2005 at 06:06:24PM -0700, Dave Whipp wrote:
: Yuval Kogman wrote:
:
: - optimizers stack on top of each other
: - the output of each one is executable
: - optimizers work in a coroutine, and are preemptable
: - optimizers are small
: - optimizers operate
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote:
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the
On Fri, Jul 15, 2005 at 02:38:22AM +0300, Yuval Kogman wrote:
As I see it == is the generic comparison, and 'eq' is == with
coercing parameters (in Haskell it'd be
eq :: (Show a) = a - a - Bool or so... Isn't that lovely?)
There is a new generic comparison operator known as ~~.
The dispatch
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote:
Nathan Gray skribis 2005-07-14 12:55 (-0400):
Autrijus joked? about $?.method once (instead of ./method), in case we
need any more bad alternatives for $?SELF.method. But I also trust
@larry, or %larry, or even $larry, to make a decent
64 matches
Mail list logo
