Re: MMD as an object.
Bob Rogers [EMAIL PROTECTED] wrote:
From: Leopold Toetsch [EMAIL PROTECTED]
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
If yes, who is creating it: the Perl6 compiler emits code to do so or
it's up to Parrot to do the right thing?
FWIW, Common Lisp specifies a generic function [1] that collects all
methods defined for a given operation name. (In Perl/Parrot, the
generic function name for your examples would be the string foo; in
Lisp, it would be the symbol FOO in some package, but the practical
difference should be slight.) The important thing is that the GF has
all the information required to make method dispatch decisions.
That sounds exactly like the MultiSub object that gathers a candidate
list of all subroutines with the same short name.
... But on the other hand, the CL community has
more than 15 years of experience with MMD, so I wanted to be sure
everyone was aware of it.
Yeah, that's really helpful.
2) namespaces of (multi) subs.
A non-multi method is in the classes' namespace. In Parrot terms that's
currently:
%globals{\0class_name}{method_name}
I'm not quite sure, if the method hash shouldn't live inside the class.
Is naming at this level really important here?
Well, the short name of the multi sub has to be stored somewhere.
... The operation itself
needs a name (so that people can call it), and classes need class names
(maybe), but all methods are implicitly named by the combination of
operation plus argument signature.
Yes. That's the long name in Perl6 design documents.
... Which would seem to mean that,
unlike perl5, the package in which a multimethod is defined doesn't
matter; all that is captured by the argument signature.
Yep. You can define a multi sub anywhere.
... Or is it
possible to have more than one method with the identical signature? And
if so, what does that mean?
There can be identical signatures in different scopes. Within one scope,
I don't know.
The long name is therefore a list of class names, which suggests
that the single-dispatch naming above is backwards. Of course, I'm
probably out of my depth here . . .
The long name contains the signature. The short name is the bare
foo.
A multi method is similar, except that their can be more then one
with the same short name (which probably means that there has to be a
MultiSub object holding the long names)
I'm not sure it is meaningful to give a sub a short name,
You call it by the short name.
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
This sounds right to me. Or perhaps
%globals{foo} -- MultiSub{[foo, 'A', 'B'] = Sub, ...}
Yep, something like that.
just to belabor the point a bit.
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Is this really different? After all, the operation foo should be just
a string in either case.
Sure. But the string foo has to live in some namespace. But, it it's
not marked as global it's probably in either a package or a module, so
again it has it's namespace.
-- Bob Rogers
leo
Re: MMD as an object.
Rod Adams [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
I don't think it's as esoteric as you might think. Consider:
package Foo;
use MMD::Random;
our bar is MMD::Random is export(DEFAULT);
multi sub bar ($x) {...};
multi sub bar ($x) {...};
Note that they all have the same signature. The Manhattan policy would
complain about this, since it's looking for the closest parameter match.
The Random policy does not care. It's going to randomly pick any member
method for each call.
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...} # same body as above
bar($x);
If you need an esoteric dispatcher roll your own :)
Since the main goal of treating multis as an object was to be able to
override the dispatch policy, I think how a user defined policy
interacts with different localities is very much on topic.
I don't think that the policy should be in the MultiSub object. You have
all methods and information to be able to do your own dispatch, if
needed. Your approach would very likely disable all possible
optimizations.
Anyway, that's far future.
What I'd like to know is more basic things:
Yes, still :-)
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
As for whether such a thing is visible at the Perl level, I think that
depends on if we allow user defined dispatch policies or not. If not,
it's just an introspection tool that could be addressed in other ways.
Don't think so. It's a problem of namespaces and how these multi subs
are managed. It touches Perl6 as well as Parrot.
Even without custom policies, p6c may decide to go the MultiSub object
route at the compiler level. But I can't speak to that, nor on the
Compiler - Parrot interaction.
It depends on what Parrot will get from the Perl6 compiler.
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
This can be seen as questioning how to keep track of what multi's are in
scope at any given point in time, because you must dispatch amongst all
the multi's visible, regardless of the differing scope.
Sure. But the dispatch scheme is described in A12. That is per se not
the problem.
However if you have multi's from a mix of different sources and scopes,
all with the same short name, which policy decides how to dispatch
amongst them at a given calling locality is very much at issue, and is
roughly where we are in the discussion.
Yes. The policy will be handled by a dispatcher object's dispatch
vtable, as far as I can currently see.
leo
Re: Junctions - feedback and desires
Rod Adams [EMAIL PROTECTED] wrote:
Well
if 10 $j 1 { ... }
if 10 $j { if $j 1 { ... }}
Could easily wind up with the same opcodes.
No. In the first case $j is evaluated just once. In the second case it's
evaluated twice.
leo
Re: Regarding status of Parrot and pure perl Perl6 compiler
Markus Laire wrote: I've been following the development of pugs (http://pugscode.org/), so I can give a short answer based on that. While pugs is currently written in Haskell, roadmap does mention the idea to eventually port pugs to perl6 if needed, which would give us a Perl 6 compiler written in Perl. (see http://svn.perl.org/perl6/pugs/trunk/docs/01Overview.html) The if needed means, I'd guess, that if no other implementation of perl6 compiler written in perl exists at that time, we can get one from the pugs project. Thank you for your reply. I am glad that this Perl 6 compiler has been implemented indeed. It will be good for many purposes, both to test the Perl 6 language and provide a bootstrap for a compiler written in Perl 6 itself ( I was wondering how they were going to bootstrap the language), and for using and getting a feel for the language while the architecture continues to be developed. Certianly I appreciate it. And of course we will eventually need working Parrot to compile perl6 into a Parrot-code, but I don't know much about that as I'm currently mainly interested about the development of pugs-project. Yes, we will want to be able to run Perl 6 on top of Parrot, and also allow Perl 5 modules to be used with Perl 6 modules and vice versa. I have written a lot of code in Perl 5 and I would like to be able to call it from Perl 6, and also be able to call Perl 6 code I write from Perl 5. Parrot is a pretty important project, as well as Ponie.
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Michal Jurosz [EMAIL PROTECTED] wrote:
Failed TestStatus Wstat Total Fail Failed List of Failed
[ 50 failing ]
imcc/t/imcpasm/opt1.# Failed test (imcc/t/imcpasm/opt1.t at line 626)
# got: '_main:
# set N0, 1.6e+022
# end
# '
# expected: '_main:
# set N0, 1.6e+22
The test could include C 0? .
--- imcc/t/syn/file.t, line 363
{ local $/; $err_msg = FOO; }
+$err_msg =~ s/\r//g;
Could you please provide one patch for items like above, thanks.
t/dynclass/pybuiltin.# Failed test (t/dynclass/pybuiltin.t at line 22)
dynclasses/* are currently failing on windows due to missing exported
symbols.
t/native_pbc/integer.# Failed test (t/native_pbc/integer.t at line 51)
# got: 'Parrot VM: Can't locate
c:/usr/parrot-t/t/native_pbc/integer_1.pbc, code 2.
# main: Packfile loading failed
Strange. Can you run that through a debugger?
t/op/spawnw.# Failed test (t/op/spawnw.t at line 57)
# got: 'return code: 0
# '
# expected: 'return code: 123
The win32:Parrot_Run_OS_Command could be the culprit (see
src/platform.c, which is constructed from various platform files
mentioned there as comments)
not ok 19 - constructor - diamond parents # TODO wrong init order?
# Failed (TODO) test (t/pmc/object-meths.t at line 519)
That's an TODO test, but already fixed in CVS.
# Failed (TODO) test (t/pmc/objects.t at line 1660)
TODO's are supposed to fail.
# --- t/pmc/sys ---
t/pmc/sys...# Failed test (t/pmc/sys.t at line 26)
# got: '. Not found ...
--- config_lib.pasm
- set P0[slash], /
+ set P0[slash], \\
$ parrot config_lib.pasm
No. This file is generated and should contain the current setting of
$Pconfig{slash} - see also lib/Parrot/Config.pm.
$ parrot.exe t/pmc/sys_1.imc
Hello, World!
0
So seems like Parrot_run_slash != MinGW_build_slash. Because I still
need Configure::Data-set( slash = '/' ); inside
config\init\mswin32.pl to properly build.
What is the difference between these two slashes - looks strange.
# --- Some other ideas: ---
$ perl -e print $^O
msys
--- config\init\hints.pl
sub runstep {
+ my $O = lc($^O);
+ $O = 'mswin32' if $O =~ /^(msys|mingw)/;
- my $hints = config/init/hints/ . lc($^O) . .pl;
+ my $hints = config/init/hints/ . $O . .pl;
This would make MinGW in all aspects identical to a native window build,
wouldn't it? Seems dangerous.
S pozdravem Michal Jurosz
Thanks for the detailed report,
It would be great if folks with windows installed could have a look at
these issues.
leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Matt Diephouse wrote: On Thu, 10 Mar 2005 22:23:07 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: Some of these same tests are failing on debian, fedora, and freebsd (fresh checkouts). It looks like someone broke something. Release or current CVS? Current CVS. Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 1 256 11 100.00% 1 Is there any chance that parrot picked up an old installed version of the shared libs? If you have done make install once and Configured with the defaults you continue running the installed version of the shared libs. Work around: either delete the installed tree or perl Configure.pl --prefix=$(pwd) leo
Re: MMD as an object.
[EMAIL PROTECTED] wrote:
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...} # same body as above
bar($x);
This is enough to make me completely happy. :)
Miro
[PUGS] patch - few hyperops
This patch adds these binary-hyperops to pugs: »+« »*« »/« »x« »xx«
This is my first patch ever, so could someone check if this is OK or
not. This only adds few hyperops, as I'm not 100% sure if this is the
right way to do it.
Also currently this code emits following warning while compiling:
src/Prim.hs:398:
Warning: Pattern match(es) are non-exhaustive
In the definition of `op2Hyper': Patterns not matched: _ _ _
because I'm not sure what op2Hyper should do if it gets invalid types.
First todo-test from t/op/hyper.t passes.
Also these examples now work:
(1,2,3) »x« 3-- ('111', '222', '333')
(1,2,3) »x« (3,2,1) -- ('111', '22', '3')
1 »x« (3,2,1)-- ('111', '11', '1')
(1,2,3) »xx« 3 -- ((1,1,1), (2,2,2), (3,3,3))
(1,2,3) »xx« (3,2,1) -- ((1,1,1), (2,2), (3)
1 »xx« (3,2,1) -- ((1,1,1), (1,1), (1))
(20,40,60) »/« (2,5,10) -- (10,8,6)
(1,2,3) »+« (10,20,30) »*« (2,3,4)-- (21,62,123)
((1,2,3) »+« (10,20,30)) »*« (2,3,4) -- (22,66,132)
--
Markus Laire
Jam. 1:5-6
Index: src/Prim.hs
===
--- src/Prim.hs (revision 586)
+++ src/Prim.hs (working copy)
@@ -366,6 +366,8 @@
op2 ^^ = op2Bool ((/=) :: Bool - Bool - Bool)
op2 // = op2Logical isJust
op2 !! = op2Bool (\x y - not x not y)
+-- NOTE: » == '\194':'\187'
+op2 ('\194':'\187':op) = op2Hyper $ init $ init $ op
-- XXX pipe forward XXX
op2 and= op2
op2 or = op2 ||
@@ -392,6 +394,14 @@
| otherwise = (x:piece, rest') where (piece, rest') = breakOnGlue glue
xs
op2 s= \x y - return $ VError (unimplemented binaryOp: ++ s) (App s []
[Val x, Val y])
+op2Hyper op x y
+| VList x' - x, VList y' - y
+= mapM (\(a,b) - op2 op a b) (x' `zip` y') = (return . VList)
+| VList x' - x
+= mapM ((flip (op2 op)) y) x' = (return . VList)
+| VList y' - y
+= mapM (op2 op x) y' = (return . VList)
+
op2Push f inv args = do
let array = vCast inv
rest = vCast args
@@ -691,6 +701,11 @@
\\n Scalarleft|| (Bool, Bool)\
\\n Scalarleft^^ (Bool, Bool)\
\\n Scalarleft// (Bool, Bool)\
+\\n List left»+« (Any, Any)\
+\\n List left»*« (Any, Any)\
+\\n List left»/« (Any, Any)\
+\\n List left»x« (Any, Any)\
+\\n List left»xx«(Any, Any)\
\\n List list, (List)\
\\n List spre== (List)\
\\n List left== (List, Code)\
Index: src/Parser.hs
===
--- src/Parser.hs (revision 586)
+++ src/Parser.hs (working copy)
@@ -448,8 +448,10 @@
, postOps ++ -- ++ preOps ++ -- -- Auto-Increment
, rightOps **-- Exponentiation
, preOps= ! + - ~ ? * ** +^ ~^ ?^ \\ -- Symbolic Unary
-, leftOps * / % x xx + + + ~ ~ ~ -- Multiplicative
-, leftOps + - ~ +| +^ ~| ~^ -- Additive
+, leftOps $
+»*« »/« »x« »xx« ++
+* / % x xx + + + ~ ~ ~ -- Multiplicative
+, leftOps »+« + - ~ +| +^ ~| ~^ -- Additive
, leftOps! -- Junctive And
, leftOps ^ | -- Junctive Or
, preOps unary-- Named Unary
Re: Parrot 0.1.2 with MinGW32 (some experimets)
On Fri, Mar 11, 2005 at 10:19:55AM +0100, Leopold Toetsch wrote: Matt Diephouse wrote: On Thu, 10 Mar 2005 22:23:07 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Diephouse [EMAIL PROTECTED] wrote: Some of these same tests are failing on debian, fedora, and freebsd (fresh checkouts). It looks like someone broke something. Release or current CVS? Current CVS. Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 1 256 11 100.00% 1 Is there any chance that parrot picked up an old installed version of the shared libs? If you have done make install once and Configured with the defaults you continue running the installed version of the shared libs. Work around: either delete the installed tree or perl Configure.pl --prefix=$(pwd) I dont think I have ever done a make install of parrot. I tried the above configure with a fresh checkout from cvs. The tests are still failing but not I get : I think this is the same behaviour I was getting with freebsd last night and on the machine I have connected to my tinderbox. The machine at work (which I did this compile on) has less memory than the freebsd or home pc. # '(cd . ./parrot --gc-debug # /tmp/foo/parrot/t/dynclass/pyint_22.imc)' failed with exit code 131 t/dynclass/pyint...NOK 22# Failed test (t/dynclass/pyint.t at line 548) # got: 'Parrot VM: PANIC: Out of mem! # C file src/memory.c, line 45 # Parrot file (not available), line (not available) # # We highly suggest you notify the Parrot team if you have not been # working on # Parrot. Use parrotbug (located in parrot's root directory) or send an # e-mail to [EMAIL PROTECTED] # Include the entire text of this error message and the text of the # script that # generated the error. If you've made any modifications to Parrot, # please # describe them as well. # # Version : 0.1.2-devel # Configured : Fri Mar 11 10:31:33 2005 # Architecture: i386-linux # JIT Capable : Yes # Interp Flags: (no interpreter) # Exceptions : (missing from core) # # Dumping Core... -- Our goal is to continually integrate world-class opportunities to allow us to synergistically network interdependent methods of empowerment to meet our customer's needs
Re: Junctions - feedback and desires
Leopold Toetsch wrote:
Rod Adams [EMAIL PROTECTED] wrote:
Well
if 10 $j 1 { ... }
if 10 $j { if $j 1 { ... }}
Could easily wind up with the same opcodes.
No. In the first case $j is evaluated just once. In the second case it's
evaluated twice.
You're right. I just dived through the archives and found that chained
operators are an exception. Sorry for missing that.
Which can be a mess explaining to someone how
if 0 $x$x 10 {...}
can be true when
if 0 $x 10 {...}
is false.
Though I suppose if we can extend this to a general rule of if it only
appears once, it can only be threaded once, it makes a certain amount
of sense.
-- Rod Adams
Re: Problem with Readonly and Devel::Cover
Kevin Scaldeferri wrote: Anyone seen this message with Readonly running under Devel::Cover: Invalid tie at (eval 22)[/usr/local/lib/perl5/site_perl/5.8.0/Readonly.pm:338] line 9 It's a little spooky... my tests used to be fine, but then I made a couple innocuous changes in one test file (changing log levels) and I starting getting this failure -- in a completely different test file!! Well, I guess those changes weren't so innocuous after all. On a couple of occasions people have reported to this and other lists that Devel::Cover picks up coding errors that perl allows to pass through. (It's as if Devel::Cover runs your code under 'use very strict;'.) Here's a case I posted a while back: http://groups-beta.google.com/group/comp.lang.perl.modules/msg/464c7d4d7483a339 ... and Leif Eriksen posted one on this list in January as 'failures under Devel::Cover only'. This may be a similar case. Given that line 338 in Readonly.pm is the beginning of a large eval block, I'm not surprised that this is the point where an error was detected. What is happening at line 9 in your input? Jim Keenan
Re: MMD as an object.
Leopold Toetsch wrote:
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...} # same body as above
bar($x);
If you need an esoteric dispatcher roll your own :)
That's certainly the doable with any language that provides sufficient
introspection, within limits. It's a matter of where you store your hand
rolled dispatcher.
If I were to need a different policy for a given method .bar, I would
likely create something called .bar much like your run_random_bar,
which then dispatches amongst methods I name something like ._bar .
I see some detractions to this approach:
1) Users wishing to add another multi to the mix must know that they
have to make it a ._bar instead of a .bar. This is a relatively minor
concern. It feels rather clumsy having two different names for what is
essentially a single set of multis.
2) What parameter signature do you give the wrapper method, so it does
not clobber the arguments, yet still has them to pass on to the
appropriate method? And at the same time, determine what signature the
wrapper was called with, to determine who to dispatch to... I hadn't
said it before, but I had assumed the dispatch method of the MultiSub
would have a signature of something like Str @types passed to it.
3) It does not allow more than one sub with the same signature and short
name to be in scope at the same time. There are cases more legitimate
than MMD::Random for this. For instance, dispatching based on return
type. Or off of some user defined trait the different methods have. Or
the most common case: on named arguments.
My understanding of the P6 Long Names is that if one creates a multi
with the same parameter signature as a previously defined multi of same
short name, it masks the previous one if in a tighter scope, or erases
the previous if the same scope.
The original thought was to have the policy take over the acceptance of
new multi's into the MultiSub as well as taking over dispatch, thus
allowing for such flexibilities.
Since the main goal of treating multis as an object was to be able to
override the dispatch policy, I think how a user defined policy
interacts with different localities is very much on topic.
I don't think that the policy should be in the MultiSub object.
I'm not sure if I think it should be there either. It just seemed to
allow some flexibility in having it there that is otherwise very
difficult to do.
And quite likely, the policy itself would not be in the MultiSub, but
the MultiSub would have a reference to which policy it's using.
Your approach would very likely disable all possible optimizations.
It's always been in the back of my head that this would be a performance
hit. How big of one I don't have a good feel for. I've been attempting
to get a feel for how much is gained in return for that hit. So far I am
inclined to agree that the benefits do not outweigh the costs, but I
like to know exactly what I'm giving up when making those decisions.
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
As for whether such a thing is visible at the Perl level, I think that
depends on if we allow user defined dispatch policies or not. If not,
it's just an introspection tool that could be addressed in other ways.
Don't think so. It's a problem of namespaces and how these multi subs
are managed. It touches Perl6 as well as Parrot.
What I meant to say was that yes, there does need to be management and
introspection capabilities at the Perl6 level, but they do not *require*
it to be a MultiSub object to happen. Some non-object solution could
likely be found.
With that mindset, the compiler could use a PMC object for it, but show
the Language something else, or it could show the Language something
that looks like an object, but use something different in Parrot. Those
are questions I am not able to answer.
Some of the management issues I see that need addressing are:
- How do I dynamically create a new multi with differing levels of
scope? For instance, add a package scoped multi from inside a sub of
that package?
- If I'm in a lexical scope which overrides a certain long name, how can
I call the package scoped version of that long name instead?
- Given a method returned from WALKMETH, what scope level is it defined at?
- Can I get a CODEREF that points to the short name as a whole, or do I
have to take a ref to a given multi?
- How can I tell if a given long name already exists?
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
This can be
Object patches summary
The first bunch of patches is in. The visible part is a new opcode: op get_mro(out PMC, in PMC) This returns the array reference of the MRO (Method Resolution Order) Array. This is basically the same as the list of ISA strings, except that the MRO array contains class PMCs and abstract base classes are omitted in MRO. The MRO array is valid for plain PMCs as well as for Parrot objects. It's the base for all operations that need some canonical ordering of a classes' parents like method resolution and initialization or destruction ordering. Internally the MRO array replaces the PCD_ALL_PARENTS array. The difference is that the former has the object's class in front and is available for PMCs too. leo
[PROPOSAL] MMD: multi sub syntax
I prefer test first programming. Therefore we need some syntax to get multi subs into the assembler. Albeit we even have two sets of MMD function registering opcodes (object.ops:mmd* , pmc.ops:mmdvt*) these are not adequate to implement a general MMD scheme. The opcodes allow just 2-dimensional MMD and second, the opcodes don't really help to define multi subs, as the MMD information should be attached to the Sub object itself and not be created from distance by some opcode, IMHO. Syntax proposal: .sub foo @MULTI .invocant Integer a .invocant Float b .param pmc c ... The @MULTI pragma goes along with the Cpcc_sub_proto, it just adds another flag bit. The C.invocant can easily be parsed in the Csub_params rule, the terminal C.invocant is already defined. The Ctype rule allows currently to specify only known types, this check can be skipped so that arbitrary class names can be specified. Comments welcome, leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
[EMAIL PROTECTED] wrote: Strangely all the tests ( well pyclass pycomplex and pyfunc so far ) pass on freebsd but do so very very slowly and parrot is eating memory like there is no tomorrow. Gets above 300meg during each of the tests. That's really strange. During make test top shows around 5 Meg for parrot here on my linux box. leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
On Fri, Mar 11, 2005 at 11:26:09AM +0100, Leopold Toetsch wrote: [EMAIL PROTECTED] wrote: Strangely all the tests ( well pyclass pycomplex and pyfunc so far ) pass on freebsd but do so very very slowly and parrot is eating memory like there is no tomorrow. Gets above 300meg during each of the tests. That's really strange. During make test top shows around 5 Meg for parrot here on my linux box. leo Probably should have tried this earlier but I have a little too much faith in compilers. When I use gcc-2.95 it works(well all tests pass) and memory is ok. With gcc-3.3 the tests fail and memory usage is way up. The freebsd gcc is also 3.3.3 so the problem doesn't seem to be debian/linux/bsd related but instead a compiler issue. -- Our goal is to continually integrate world-class opportunities to allow us to synergistically network interdependent methods of empowerment to meet our customer's needs
Re: Adding linear interpolation to an array
Doug McNutt wrote: A word of caution: Just as in vector operators had their names changed to pacify the mathematicians - thank you - there is a conflict in terms. Covariant and contravariant tensors are the meat of Einstein's formulation of relativity. It all has to do with transformations being in the same direction or the opposite direction as the coordinate differentials. Perhaps there is some similarity. Yes, that's what is meant by these two words. But of course the concrete meaning depends on the subject area. The above is from tensor algebra. Mine is from type theory. Einstein's presentation is a whole lot easier to understand than the one above. Sorry, I make a second attempt in another reply. -- TSa (Thomas Sandlaß)
Re: Adding linear interpolation to an array
HaloO David, you wrote: I appreciate you attempting to explain this, but it remains clear as mud, at least to me. Could you please try again, using very short, very non-technical words and not assuming a mathematical or scientific background on the part of your reader? Ok, second attempt! The : is the subtype relation operator. Saying Int : Num means Int is a subtype of Num. With generic types like the Array of ... the question is how this relation shall carry over to the Array type instances. Int @i; Num @n = @i; # type error? Regards, -- TSa (Thomas Sandlaß)
Re: MMD as an object.
Rod Adams [EMAIL PROTECTED] wrote: If I were to need a different policy for a given method .bar, I would likely create something called .bar much like your run_random_bar, which then dispatches amongst methods I name something like ._bar . I see some detractions to this approach: 1) Users wishing to add another multi to the mix must know that they have to make it a ._bar instead of a .bar. Not necessarily, AFAIK. You can define a lexical sub bar, which hides all outer multi subs. This bar can be used to dispatch to the multi subs. 2) What parameter signature do you give the wrapper method, so it does not clobber the arguments, yet still has them to pass on to the appropriate method? And at the same time, determine what signature the wrapper was called with, to determine who to dispatch to... Well, I presume, if you are writing such code, i.e. a bunch of mutli subs with the same signature, you are very well aware of what you are doing. So you'll know, how you call the dispatcher (and what funny effects you'll yield :) ... I hadn't said it before, but I had assumed the dispatch method of the MultiSub would have a signature of something like Str @types passed to it. I don't thing that the MultiSub does dispatch nor that it has a dispatch method. The MultiSub object is just a collection of multi Sub candidates for one of the scopes [lexical, package/module/class, global, builtin]. The current dispatcher has to collect a list of possible candidates from all the possible multis, and then decide, depending on the policy, which sub should actually be called. 3) It does not allow more than one sub with the same signature and short name to be in scope at the same time. That's mainly a Perl6 compiler problem. When the MultiSub is just a list of candidates, you can append whatever signature you like. There is no check for duplicates. It's only the dispatcher that will detect ambiguous signatures, if it cares about, like the default dispatcher. ... For instance, dispatching based on return type. Well, while there is a symmetry in call and return, when Parrot is concerned, dispatching on return types isn't easy, or better, it could just be done for the total static case, where all return results are known beforehand. For that case you could just call different subs in the first case. If the return type is just the runtime result, after the sub is run, you can do nothing in the dispatcher, which long before had called the sub. ... Or off of some user defined trait the different methods have. Or the most common case: on named arguments. A trait creates usually an anonymous subclass of the involved class and therefore has precedence over a not so specific class. MMD on named arguments isn't specified yet, or: ,--[ A12 ] | It is not likely that Perl 6.0.0 will support multiple dispatch on named | arguments, `- My understanding of the P6 Long Names is that if one creates a multi with the same parameter signature as a previously defined multi of same short name, it masks the previous one if in a tighter scope, or erases the previous if the same scope. As said, that's mainly a Perl6 compiler problem. The compiler can't emit two identical long names as one of these wouldn't be callabale then. The original thought was to have the policy take over the acceptance of new multi's into the MultiSub as well as taking over dispatch, thus allowing for such flexibilities. What policy is in effect, if you define somewhere a multi sub? I think, that can't work. And quite likely, the policy itself would not be in the MultiSub, but the MultiSub would have a reference to which policy it's using. No, I don't think so. The current (lexical) scope has the policy, according to A12. Some of the management issues I see that need addressing are: [ good questions for the compiler folks ] leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Leopold Toetsch [EMAIL PROTECTED] wrote: Is there any chance that parrot picked up an old installed version of the shared libs? If you have done make install once and Configured with the defaults you continue running the installed version of the shared libs. I have never run make install and this was built in a fresh directory. Work around: either delete the installed tree or perl Configure.pl --prefix=$(pwd) Configuring a prefix doesn't solve the problem. -- matt diephouse http://matt.diephouse.com
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Peter Sinnott [EMAIL PROTECTED] wrote: Probably should have tried this earlier but I have a little too much faith in compilers. When I use gcc-2.95 it works(well all tests pass) and memory is ok. With gcc-3.3 the tests fail and memory usage is way up. The freebsd gcc is also 3.3.3 so the problem doesn't seem to be debian/linux/bsd related but instead a compiler issue. I'm using gcc 3.3.4. -- matt diephouse http://matt.diephouse.com
Re: Adding linear interpolation to an array
On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote: : Int @i; : Num @n = @i; # type error? I think the naive user is going to expect that to work, and I also suspect the naive user is right to expect it, because it makes sense. This may be one of those areas where we can successfully hide the high-falutin' theory from mere mortals simply because it maps onto what they expect already. On the other hand, that's an assignment, which presumably copies value types. Binding is another matter--I wouldn't necessarily expect this to work: Num @n := @i; But these might be made to DWIM since copying is allowed: Num @n is copy := @i; Num @n is constant := @i; On the other hand, the plain rw binding *could* be made to work under the view that @n is providing a view of @i. It's just that @n could provide only the Int subset of semantics. As such, it's acting as a kind of tie on @n, so I expect it wouldn't be allowed unless you declared @n to be some kind of tyable that allows delegating @n to @i. Plus the variable type would have to capture the binding semantics and force the delegation past the compiler (presuming the compiler cares about the type mismatch). But it's okay to disallow some things now on the basis that they're just not implemented yet, as long as people don't mistake such restrictions for strong typing. Larry
Re: SEND + MORE = MONEY (works now in pugs with junctions!)
There's no doubt that the QM view of extended entanglement is very useful. After all, that's what the whole universe runs on. But most mortals will want the classical view to be the default, so we'll require some kind of explicit markup or pragma if you want to extend entanglement further out than comparisons. That's why junctions can't be passed into a function unless the function specifically allows it, for instance. (Then there's the matter of sneaky return values.) The only alternative is to autothread every conditional, and I don't think we'd survive the lynch mobs if we did that. Maybe there's some middle ground here that I don't see, but if so, I don't see it. And if I don't see it, all the other Pooh bears will have trouble with it too. Larry
Re: Parrot 0.1.2 with MinGW32 (some experimets)
Peter Sinnott wrote:
[ ~300 Meg memory in t/dynclasses used ]
Probably should have tried this earlier but I have a little too
much faith in compilers. When I use gcc-2.95 it works(well all
tests pass) and memory is ok. With gcc-3.3 the tests fail
and memory usage is way up. The freebsd gcc is also 3.3.3 so the
problem doesn't seem to be debian/linux/bsd related but instead
a compiler issue.
Yeah. I've now compiled it on my old linux notebook, which has gcc 3.3.3
- same problem.
What I've so far is:
(gdb)
mmd_register (interpreter=0x82dfce8, function=51, left_type=74,
right_type=74,
funcptr=0x81405a0 Parrot_default_bitwise_xors) at src/mmd.c:585
585 offset = table-x * right_type + left_type;
1: *table = {mmd_funcs = 0x83d7bb0, x = 75, y = 75,
default_func = 0x80e5000 mmd_fallback_stringxor_pmc, funcs_in_table
= 0}
(gdb)
586 table-mmd_funcs[offset] = funcptr;
1: *table = {mmd_funcs = 0x83d7bb0, x = 75, y = 75,
default_func = 0x80e5000 mmd_fallback_stringxor_pmc, funcs_in_table
= 0}
(gdb)
587 }
1: *table = {mmd_funcs = 0x83d7bb0, x = 75, y = 75,
default_func = 0x80e5000 mmd_fallback_stringxor_pmc, funcs_in_table
= 0}
(gdb)
Parrot_mmd_register_parents (interpreter=0x82dfce8, type=74,
mmd_table=0xb430, n=53)
at src/pmc.c:502
502 for (i = 0; i n; ++i) {
(gdb)
503 if (!mmd_table[i].right)
(gdb)
504 mmd_register(interpreter,
(gdb)
Breakpoint 3, mmd_register (interpreter=0x82dfce8, function=52,
left_type=74, right_type=74,
funcptr=0x81405c0 Parrot_default_bitwise_xors_str) at src/mmd.c:577
577 if ((INTVAL)table-x = left_type) {
1: *table = {mmd_funcs = 0x83dda90, x = 74, y = 262218,
default_func = 0x80e5070 mmd_fallback_stringxor_str, funcs_in_table
= 0}
This is during registering the Foo classes* MMDs, please note the value
of table-y in the last line. The value did change just between leaving
the last mmd_register and entering the failing mmd_register.
Remarkable is that this is the last (highest) function number, and that
there is no other memory allocation in betweeen. And it seems to happen
with --gc-debug only. Seems to be a memory corruption somewhere else.
More strange is, that my patch didn't touch any memory related things,
it just increased the vtable structure by on item.
Can someone run this through valgrind or some other memory debugger please.
Above gdb snippet is from:
(gdb) bac
#0 mmd_register (interpreter=0x82dfce8, function=52, left_type=74,
right_type=74,
funcptr=0x81405c0 Parrot_default_bitwise_xors_str) at src/mmd.c:577
#1 0x080aa1dc in Parrot_mmd_register_parents (interpreter=0x82dfce8,
type=74,
mmd_table=0xb430, n=53) at src/pmc.c:504
#2 0x4001d726 in Parrot_Foo_class_init (interp=0x82dfce8, entry=74,
pass=1) at foo.c:328
#3 0x4001d7a5 in Parrot_lib_foo_load (interpreter=0x82dfce8) at foo.c:362
#4 0x080e274e in Parrot_init_lib (interpreter=0x82dfce8,
load_func=0x4001d740 Parrot_lib_foo_load, init_func=0) at
src/dynext.c:258
#5 0x080e28b4 in Parrot_load_lib (interpreter=0x82dfce8, lib=0x8309208,
initializer=0x0)
at src/dynext.c:322
#6 0x080f9066 in Parrot_loadlib_p_sc (cur_opcode=0x8517320,
interpreter=0x82dfce8)
at core.ops:1149
You reach it by first setting a breakpoint at Parrot_load_lib, then
stepping over the actual library loading, then b mmd_register.
leo
Re: Parrot 0.1.2 with MinGW32 (some experimets)
On Fri, Mar 11, 2005 at 06:11:25PM +0100, Leopold Toetsch wrote: Peter Sinnott wrote: Can someone run this through valgrind or some other memory debugger please. I'm not sure if this test is the one you want. The fun output is near the end. $ valgrind ./parrot --gc-debug /home/nick/Parrot/parrot00/t/dynclass/foo_1.imc ==30839== Memcheck, a memory error detector for x86-linux. ==30839== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==30839== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==30839== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==30839== For more details, rerun with: -v ==30839== ==30839== warning: Valgrind's pthread_attr_destroy does nothing ==30839== your program may misbehave as a result ==30839== warning: Valgrind's pthread_attr_destroy does nothing ==30839== your program may misbehave as a result ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DD60E: trace_mem_block (dod.c:994) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839==by 0x80DF901: trace_system_areas (cpu_dep.c:98) ==30839==by 0x80DCF1A: Parrot_dod_trace_root (dod.c:362) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DD61C: trace_mem_block (dod.c:999) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839==by 0x80DF901: trace_system_areas (cpu_dep.c:98) ==30839==by 0x80DCF1A: Parrot_dod_trace_root (dod.c:362) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DD654: trace_mem_block (dod.c:1006) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839==by 0x80DF901: trace_system_areas (cpu_dep.c:98) ==30839==by 0x80DCF1A: Parrot_dod_trace_root (dod.c:362) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DD624: trace_mem_block (dod.c:999) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839==by 0x80DF901: trace_system_areas (cpu_dep.c:98) ==30839==by 0x80DCF1A: Parrot_dod_trace_root (dod.c:362) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB958: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC6EC: is_pmc_ptr (headers.c:540) ==30839==by 0x80DD633: trace_mem_block (dod.c:999) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB969: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC6EC: is_pmc_ptr (headers.c:540) ==30839==by 0x80DD633: trace_mem_block (dod.c:999) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB986: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC6EC: is_pmc_ptr (headers.c:540) ==30839==by 0x80DD633: trace_mem_block (dod.c:999) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839== ==30839== Use of uninitialised value of size 4 ==30839==at 0x80DCC49: pobject_lives (dod.c:196) ==30839==by 0x80DD648: trace_mem_block (dod.c:1004) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839==by 0x80DF901: trace_system_areas (cpu_dep.c:98) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DD65C: trace_mem_block (dod.c:1006) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839==by 0x80DF901: trace_system_areas (cpu_dep.c:98) ==30839==by 0x80DCF1A: Parrot_dod_trace_root (dod.c:362) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB958: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC642: is_buffer_ptr (headers.c:512) ==30839==by 0x80DD66B: trace_mem_block (dod.c:1006) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB969: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC642: is_buffer_ptr (headers.c:512) ==30839==by 0x80DD66B: trace_mem_block (dod.c:1006) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB958: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC69D: is_buffer_ptr (headers.c:517) ==30839==by 0x80DD66B: trace_mem_block (dod.c:1006) ==30839==by 0x80DF933: trace_system_stack (cpu_dep.c:117) ==30839== ==30839== Conditional jump or move depends on uninitialised value(s) ==30839==at 0x80DB969: contained_in_pool (smallobject.c:55) ==30839==by 0x80DC69D: is_buffer_ptr (headers.c:517) ==30839==by 0x80DD66B: trace_mem_block (dod.c:1006) ==30839==by 0x80DF933: trace_system_stack
Re: SEND + MORE = MONEY (works now in pugs with junctions!)
Larry Wall writes: There's no doubt that the QM view of extended entanglement is very useful. After all, that's what the whole universe runs on. But most mortals will want the classical view to be the default, so we'll require some kind of explicit markup or pragma if you want to extend entanglement further out than comparisons. That's why junctions can't be passed into a function unless the function specifically allows it, for instance. (Then there's the matter of sneaky return values.) The only alternative is to autothread every conditional, and I don't think we'd survive the lynch mobs if we did that. Maybe there's some middle ground here that I don't see, but if so, I don't see it. And if I don't see it, all the other Pooh bears will have trouble with it too. The collapsing behavior of Quantum::Entanglement (and what is being expressed as wanted here) is actually a sort of parallel logic programming. Instead of trying and backtracking, it's just doing it all at once. Instead of providing a collpasing junction type which will confuse the heck out of people, I think it's best to concentrate on how we will integrate logic programming in the language. And the best way to concentrate on that at this point might be not to think about it at all. But junctions might be our ticket into the world of logic programming. We'd have to change them, but there are some amazing parallels between what junctions currently do and what regexes do (regexes even use the same symbols) and what my Argument Patterns proposal does with junctive types, which are both logical programming frameworks. So let's put it in the back of our minds. It's going to be in the front of mine for the day, but I might not come up with anything. Luke
Parrot questions
I have already written this to perl6-all, but it seems, that it doesn't was send. I wanted to know, if any other scripting langue is plans to use parrot. Your plan of Parrot - as I have understood it - is to have not only a VM for Perl. You want to have a VM for diffeent languages, like the JavaVM (with the languages Nice and Groovy) and .net, but written esecialy for scripting-languages. But I see two problems: 1. the license Perl is licensed under the GPL and Artistic license. Python is licensed under the Python-license and Ruby is licensed under the GPL and its own license. So, it would be nice, if Parrot would be licensed under the GPL, Artistic license, Python-license and Rubys own license. I don't think, that Python would be public its package with something included, which is under an other license then the Python-license. 2. Parrot is written by Perl-people for Perl I think it would be better, if there existing a group of 2 Perl people, 2 Python people and 2 Ruby people or so, which disigned _together_ a VM for scripting languages and then support all this VM. At the moment only the Perl people have created it. And it is possible, that Python and Ruby don't using it, because they can not identify themself with it. So it would be a thought, to rewrite Parrot together with the other scripting people and then (and can be possible that the new Parrot-VM is incompatible to the existing one now) using it all together. I have red, that you create yourself a Python for Parrot. But that wille be not more supported by the Python-people like IronPython or Jython I think. It would be better to working with the Python and Ruby people together. And letting Parrot independent of any language. But it can also be possible, that I am wrong. Do you know, if people of the other scripting languages working on Parrot, too? And do you know, if any Python or Ruby will be in the future running on Parrot? Greatings theuserbl
Re: Strings - takers wanted
Leopold Toetsch wrote: 1) ICU should be optional If configured --without-icu the Makefile shouldn't contain ICU stuff, and function calls to ICU (mainly in string_primitives) should be wrapped inside #if PARROT_HAS_ICU. I'm gonna take this one (unless Steven Schubiger is already working on it). just as a generic hint, what should the #else (eg when PARROT_HAS_ICU is not defined) do? a) consider everything ASCII and use the corresponding stdlib function b) always return NULL (or some approximation of NULL) c) complain to STDERR about ICU not being there d) coredump cheers, Aldo
Re: Adding linear interpolation to an array
Larry Wall skribis 2005-03-11 8:45 (-0800): On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote: : Int @i; : Num @n = @i; # type error? I think the naive user is going to expect that to work, and I also suspect the naive user is right to expect it, because it makes sense. This may be one of those areas where we can successfully hide the high-falutin' theory from mere mortals simply because it maps onto what they expect already. It'd be great if this were a standard feature you can also use for your own objects. I believe $foo.Num in this case should return the Num-ified version of $foo. And maybe the int method numbers have is redundant, and should be spelled Int instead. Or, well, if this is the case, int should return an int (not Int) for consistency. Maybe +$foo even maps to $foo.Num, and ~$foo maps to $foo.Str and ?$foo maps to $foo.Bool? Hm, are charsets representable as classes/roles? my Str::utf8 $bar = ...; my Str::latin1 $foo = $bar; Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [PUGS] patch - few hyperops
Thanks, applied. :) -- Markus Laire Jam. 1:5-6
Re: [PUGS] patch - few hyperops
On Fri, Mar 11, 2005 at 12:53:45PM +0200, Markus Laire wrote: : This is my first patch ever, so could someone check if this is OK or : not. This only adds few hyperops, as I'm not 100% sure if this is the : right way to do it. It is good to have a general mechanism for wrapping any binary op up as a hyper op. We'll eventually have to extend that idea into the parser as well so that we don't have to dup all the operators, but first things first. Larry
Re: MMD as an object.
Leopold Toetsch wrote: Rod Adams [EMAIL PROTECTED] wrote: If I were to need a different policy for a given method .bar, I would likely create something called .bar much like your run_random_bar, which then dispatches amongst methods I name something like ._bar . I see some detractions to this approach: 1) Users wishing to add another multi to the mix must know that they have to make it a ._bar instead of a .bar. Not necessarily, AFAIK. You can define a lexical sub bar, which hides all outer multi subs. This bar can be used to dispatch to the multi subs. I sounds like a good plan, as long as it works. However, I'd want to create the sub at the same scope (most likely class/package) as the multi subs with the same name. I'm presently not clear if that's allowable. If I have to create a lexical method in each user to dispatch to my class, that seems sub optimal. I prefer to stick with .bar vs ._bar 2) What parameter signature do you give the wrapper method, so it does not clobber the arguments, yet still has them to pass on to the appropriate method? And at the same time, determine what signature the wrapper was called with, to determine who to dispatch to... Well, I presume, if you are writing such code, i.e. a bunch of mutli subs with the same signature, you are very well aware of what you are doing. So you'll know, how you call the dispatcher (and what funny effects you'll yield :) Consider the case where I wish to create several multi's with significantly different signatures, but you write each one twice, once with an is debug trait, and once with an is operational trait. I would have some runtime signal to determine if I need to be running the debug versions, or the operational versions. If you put too much onus on the caller function to get the call correct, you might as well just name all the methods something different and forget about MMD altogether. ... I hadn't said it before, but I had assumed the dispatch method of the MultiSub would have a signature of something like Str @types passed to it. I don't thing that the MultiSub does dispatch nor that it has a dispatch method. The MultiSub object is just a collection of multi Sub candidates for one of the scopes [lexical, package/module/class, global, builtin]. Currently you are likely correct. I was proposing to change that. The current dispatcher has to collect a list of possible candidates from all the possible multis, and then decide, depending on the policy, which sub should actually be called. I was offering the ability to change which policy does the decisions, after collecting the candidates. 3) It does not allow more than one sub with the same signature and short name to be in scope at the same time. That's mainly a Perl6 compiler problem. When the MultiSub is just a list of candidates, you can append whatever signature you like. There is no check for duplicates. It's only the dispatcher that will detect ambiguous signatures, if it cares about, like the default dispatcher. So you're saying that if I create a multi with the same scope and long name as a preexisting multi, that old multi will still be around in memory, even though it could never be called without a custom dispatcher? I was under the impression that defining two multi's with the same long name in the same scope clobbered one of the involved parties and triggered a redefinition warning. ... For instance, dispatching based on return type. Well, while there is a symmetry in call and return, when Parrot is concerned, dispatching on return types isn't easy, or better, it could just be done for the total static case, where all return results are known beforehand. For that case you could just call different subs in the first case. I was imagining dispatching based off the C want function, which I have no idea how it will be implemented at the Parrot level, but it's a defined part of Perl. If the return type is just the runtime result, after the sub is run, you can do nothing in the dispatcher, which long before had called the sub. Of course. ... Or off of some user defined trait the different methods have. Or the most common case: on named arguments. A trait creates usually an anonymous subclass of the involved class and therefore has precedence over a not so specific class. A trait added to an object instance creates an anonymous subclass, certainly. But I didn't think that adding a trait to a member of a class created a new subclass... MMD on named arguments isn't specified yet, or: ,--[ A12 ] | It is not likely that Perl 6.0.0 will support multiple dispatch on named | arguments, `- Indeed, that is the current case. My understanding of the P6 Long Names is that if one creates a multi with the same parameter signature as a previously defined multi of same
Re: Parrot questions
From one Perl6/Parrot lurker to another: On Fri, 11 Mar 2005 14:47:14 +, theUser BL [EMAIL PROTECTED] said: Your plan of Parrot - as I have understood it - is to have not only a VM for Perl. You want to have a VM for diffeent languages, like the JavaVM (with the languages Nice and Groovy) and .net, but written esecialy for scripting-languages. There is one VM - that is what Parrot is. Any language can be compiled for the Parrot VM, but it needs a compiler to create the Parrot byte code or even the Parrot assembly language. While the goal of JVM is to run Java on any platform and the goal of .Net is to run any language on Windows, Parrot's goal is to run any language on any platform that has a C compiler. But I see two problems: 1. the license Perl is licensed under the GPL and Artistic license. Python is licensed under the Python-license and Ruby is licensed under the GPL and its own license. So, it would be nice, if Parrot would be licensed under the GPL, Artistic license, Python-license and Rubys own license. I don't think, that Python would be public its package with something included, which is under an other license then the Python-license. I am not an expert on OSS licenses or the details of any of the developer communities, but I don't think it matters what the compilers are licensed as - the language specs are the only things that would be used when creating a Parrot compiler for Ruby/Python/Java/etc. 2. Parrot is written by Perl-people for Perl I think it would be better, if there existing a group of 2 Perl people, 2 Python people and 2 Ruby people or so, which disigned _together_ a VM for scripting languages and then support all this VM. At the moment only the Perl people have created it. And it is possible, that Python and Ruby don't using it, because they can not identify themself with it. So it would be a thought, to rewrite Parrot together with the other scripting people and then (and can be possible that the new Parrot-VM is incompatible to the existing one now) using it all together. Why? Parrot is just a virtual platform - the common target for compilers wanting to run under Parrot. It runs the bytecode and, on a lower level, parrot assembly. This has nothing to do with Perl, Ruby, Python, etc. I have red, that you create yourself a Python for Parrot. But that wille be not more supported by the Python-people like IronPython or Jython I think. It would be better to working with the Python and Ruby people together. And letting Parrot independent of any language. Parrot is not geared towards a specific language. That is the point. It interprets byte code that is generated from compilers compiling a specific language. Perl6 ToDo: http://www.parrotcode.org/todo
Codification of the defintion of time()
Hello, p6c-folks: As of about 5 minutes ago, time() in pugs was changed to give the number of seconds since Jan 1, 2000 rather then since Jan 1, 1970, based on Larry's post http://xrl.us/fet6. However, this doesn't appear in the Synopses, Apocalypses, or Exegeses at all. Can we get it stuck into the approps Syn? (This, of course, might be a bit of a problem; the best solution I can think of is to start on Syn 29). -=- James Mastros
Codification of the defintion of time()
Hello, p6c-folks: As of about 5 minutes ago, time() in pugs was changed to give the number of seconds since Jan 1, 2000 rather then since Jan 1, 1970, based on Larry's post http://xrl.us/fet6. However, this doesn't appear in the Synopses, Apocalypses, or Exegeses at all. Can we get it stuck into the approps Syn? (This, of course, might be a bit of a problem; the best solution I can think of is to start on Syn 29). -=- James Mastros
Re: Parrot questions
On Friday 11 March 2005 08:47 am, theUser BL wrote: I have already written this to perl6-all, but it seems, that it doesn't was send. I wanted to know, if any other scripting langue is plans to use parrot. Your plan of Parrot - as I have understood it - is to have not only a VM for Perl. You want to have a VM for diffeent languages, like the JavaVM (with the languages Nice and Groovy) and .net, but written esecialy for scripting-languages. But I see two problems: 1. the license Perl is licensed under the GPL and Artistic license. Python is licensed under the Python-license and Ruby is licensed under the GPL and its own license. So, it would be nice, if Parrot would be licensed under the GPL, Artistic license, Python-license and Rubys own license. Ack! That would be a huge legal mess, and I don't see what problem it would solve. The Artistic license alone is so full of holes that you might as well make your work public domain. I don't think, that Python would be public its package with something included, which is under an other license then the Python-license. 2. Parrot is written by Perl-people for Perl I think it would be better, if there existing a group of 2 Perl people, 2 Python people and 2 Ruby people or so, which disigned _together_ a VM for scripting languages and then support all this VM. At the moment only the Perl people have created it. And it is possible, that Python and Ruby don't using it, because they can not identify themself with it. So it would be a thought, to rewrite Parrot together with the other scripting people and then (and can be possible that the new Parrot-VM is incompatible to the existing one now) using it all together. Great idea (except don't rewrite--Parrot is off to a great start already, and it would be the height of foolishness to throw it all away). The trick is to attract developers from those communities with the experiance required to build a good VM. In Free Software development, we usually don't have the luxury of hiring developers--you have to get them interested enough to spend their free time on the project. pgpv5JKl1GelY.pgp Description: PGP signature
TAP and skip_rest
There is no skip_rest(), but skip_all() can do that job, with a tiny
enhancement
sub skip_all {
-if (@_) {
- print STDOUT 1..0 # Skipped: @_\n;
+if ($test == 1) {
+ if (@_) {
+ print STDOUT 1..0 \# Skipped: @_\n;
+ } else {
+ print STDOUT 1..0\n;
+ }
} else {
- print STDOUT 1..0\n;
+ # allow skipping all remaining tests
+ for ($test..$planned) {
+ print STDOUT $test++, \# skip @_\n;
+ }
}
exit(0);
}
Tested with:
#!./perl
chdir 't' if -d 't';
@INC = ('../lib','.');
require test.pl;
plan(42);
ok(1);
skip_all();
there are obviously ways to do it currently, but theyre suboptimal.
the patch above prints $planned - $test different lines,
IFF TAP allows it,
13..25 # skipped: various reasons
could be legitimate way to skip rest, at least when a plan is
established already.
13..0 # skipped
could also be legitimate
thus avoiding 12 boring skip lines.
I think this is open to interpretation, at least its not specifically
excluded in
http://www.petdance.com/random/tap.html#skipping_tests
The real goal is to test the waters for a similar addition to Test::More,
so that some test files can be simplified to
use_ok ( Foo );
$foo = new Foo;
isa_ok ($foo, 'Foo');
skip_all no Bar available unless eval require 'Bar';
...
Ok, not a particularly compelling example,
but I hate getting my skip-counts wrong just cuz I added a few tests.
Also, given that tests should ideally be order independent,
its good to use use_ok, isa_ok at the top of your test-scripts,
and thus skip_rest should be available.
So I just want to see if interpretations are locked down b4 I went down
a garden path.
Re: TAP and skip_rest
On Fri, Mar 11, 2005 at 03:40:41PM -0700, Jim Cromie wrote: There is no skip_rest(), but skip_all() can do that job, with a tiny enhancement I would really rather it be called skip_rest(). There's no reason to wedge two different bits of functionality into one function.
Re: TAP and skip_rest
On Fri, Mar 11, 2005 at 03:40:41PM -0700, Jim Cromie ([EMAIL PROTECTED]) wrote: I think this is open to interpretation, at least its not specifically excluded in http://www.petdance.com/random/tap.html#skipping_tests Eeek, let's not refer to that any more. http://search.cpan.org/dist/Test-Harness/lib/Test/Harness/TAP.pod instead. I agree w/Schwern on not overloading skip_all. skip_rest is the way to go. Also, it would need to be explicit the difference between a skip_rest and a bail_out. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Parrot questions
At 09:47 AM 3/11/2005, theUser BL wrote: (with the languages Nice and Groovy) and .net, but written esecialy for scripting-languages. True, Parrot is slanted toward dynamic scripting languages that recompile and eval themselves on the fly, but it does provide low-level registers and features that nice, statically bound languages without continuation passing style can call. I've already done this with a demo Java like language that only uses the low level numeric and string registers and uses the faster jump/bsr instructions rather than the continuation passing style. If you read my IMCC faq, you'll also see how I kludged OOP without using Parrot's dynamic class support. It results in very fast code that is well-JITable, compared to what Perl6 compiles to. Point is: You can do it how you want to, but if you want to cooperate with other languages on the Parrot VM, you'll need to use the Parrot conventions at least on the boundaries of your modules. But I see two problems: 1. the license Perl is licensed under the GPL and Artistic license. Python is licensed under the Python-license and Ruby is licensed under the GPL and its own license. So, it would be nice, if Parrot would be licensed under the GPL, Artistic license, Python-license and Rubys own license. I don't think, that Python would be public its package with something included, which is under an other license then the Python-license. Moot. You can write commercial compilers that target the Parrot VM and distribute it as you see fit. On top of that, if you don't use anything but what Parrot provides in its base PMC classes, you don't even have to distribute a runtime lib for your special language. 2. Parrot is written by Perl-people for Perl I think it would be better, if there existing a group of 2 Perl people, 2 Python people and 2 Ruby people or so, which disigned _together_ a VM for scripting languages and then support all this VM. The VM is designed and working, the VM boys have done the bulk of their job. Parrot can currently do things that the JVM cannot. Parrot's support library needs a lot of work, but this has never stopped compiler writers in the past. :) It is time for the compiler writers to start pulling the load. I have red, that you create yourself a Python for Parrot. But that wille be not more supported by the Python-people like IronPython or Jython I think. It would be better to working with the Python and Ruby people together. And letting Parrot independent of any language. Perl is probably the heaviest influence in the scripting world. I'd wait and watch what happens when Perl6 is for real and we start doing releases for the Parrot VM and see how many people follow. -Melvin
[Pugs] Should the int() function truncate or round?
Running this program with perl 5: my $i = int(1.9); print i=$i\n; produces the answer 1 (i.e. it truncates) while running it with Pugs produces the answer 2 (i.e. it rounds). Is this a bug or a feature? If a feature, how does one truncate with Pugs/Perl6? /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: [Pugs] Should the int() function truncate or round?
At 1:47 PM +1100 3/12/05, Andrew Savige wrote: Running this program with perl 5: my $i = int(1.9); print i=$i\n; produces the answer 1 (i.e. it truncates) while running it with Pugs produces the answer 2 (i.e. it rounds). Is this a bug or a feature? If a feature, how does one truncate with Pugs/Perl6? I would say that truncation is what should happen, as with Perl 5, unless Larry explicitly changed it to do rounding with Perl 6. Generally speaking, any behaviour should be the same as Perl 5 unless explicitly said to be different. -- Darren Duncan
Re: [Pugs] Should the int() function truncate or round?
On Sat, Mar 12, 2005 at 01:47:24PM +1100, Andrew Savige wrote: Running this program with perl 5: my $i = int(1.9); print i=$i\n; produces the answer 1 (i.e. it truncates) while running it with Pugs produces the answer 2 (i.e. it rounds). Is this a bug or a feature? It is a closed bug. :) Day 43: http://use.perl.org/~autrijus/journal/23524 The int primitive now properly truncates, instead of rounds, the operand. 6.0.11 will be out in a couple days that includes this fix. Thanks, /Autrijus/ pgp8Yhnus5Xap.pgp Description: PGP signature
Re: [Pugs] Should the int() function truncate or round?
--- Autrijus Tang wrote: It is a closed bug. :) Day 43: http://use.perl.org/~autrijus/journal/23524 The int primitive now properly truncates, instead of rounds, the operand. 6.0.11 will be out in a couple days that includes this fix. Thanks. In case you're interested, I stumbled across this when attempting to write my first perl 6 program: http://www.perlmonks.org/index.pl?node_id=438876 /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: [PUGS] patch - few hyperops
On Fri, Mar 11, 2005 at 12:25:28PM -0800, Larry Wall wrote: It is good to have a general mechanism for wrapping any binary op up as a hyper op. We'll eventually have to extend that idea into the parser as well so that we don't have to dup all the operators, but first things first. Yup, my thoughts exactly. I'll hyper-opify the parser this weekend, if Luke did not beat me to it. Oh, btw, is there some more documents for the statement: level parsing and handling somewhere, or at least a general overview of how those things are defined? :) Thanks, /Autrijus/ pgp98YRrUGL0K.pgp Description: PGP signature
Re: SEND + MORE = MONEY (works now in pugs with junctions!)
Sam Vilain wrote:
I've changed examples/sendmoremoney.p6 in the pugs distribution to use
junctions correctly to demonstrate that they *can* be used to solve these
sorts of problems, and that it is just a matter of semantics and writing
code correctly.
However, poor semantics can make the task of writing optimisers
unnecessarily difficult or impractical, as Bourne demonstrated.
in short, it seems people want this:
my $a = any(1..9);
my $b = any(1..9);
my $c = any(0..9);
if ( $a != $b $b != $c $a != $c
($a + $b == $a * 10 + $c) ) {
print $a + $b = $a$c;
}
To mean this (forgive the duplication of collapse() here):
sub collapse($x, $sub) { $sub.($x) }
sub collapse($x, $y, $sub) { $sub.($x,$y) }
my $a = any(1..9);
my $b = any(1..9);
my $c = any(0..9);
collapse($a, $b, - $a, $b {
($a != $b)
collapse($c, - $c {
if ( ( $b != $c ) ( $a != $c )
($a + $b == $a * 10 + $c) ) {
say $a + $b = $a$c;
}
});
});
(and YES THAT WORKS g).
Yes, it does work, given the current state of autothreading.
Well, you'd need a C use junctions; in order to store a junction in a
variable. And I'm not certain if that changes the autothreading behavior
of the closures or not. You might have to declare the collapses as:
multi sub collapse ($x is none(Junction), $sub) {...};
multi sub collapse ($x is none(Junction), $y is none(Junction),
$sub) {...};
to get it to thread correctly. I'm not sure. (Pretty sure you'd need the
'multi' in there).
It's also a perfect example of where my hyperthreader operator (it
hasn't been nailed down yet what the exact syntax is (or even if it
exists), I'm waiting for Damian to get back to continue that thread.) is
a better tool than junctions. Assuming we use my »« syntax,
SEND+MORE==MONEY could be written as:
sub test ($s, $e, $n, $d, $m, $o, $r, $y) {
if $s$e$n$d + $m$o$r$e == $m$o$n$e$y
all($s,$e,$n,$d,$m,$o,$r,$y) == one($s,$e,$n,$d,$m,$o,$r,$y)
{
say $s$e$n$d + $m$o$r$e == $m$o$n$e$y;
}
}
test(»1..9«, »0..9«, »0..9«, »0..9«, »1..9«, »0..9«, »0..9«, »0..9«);
Using Damian's every() syntax, the last line becomes:
test(every(1..9), every(0..9), every(0..9), every(0..9),
every(1..9), every(0..9), every(0..9), every(0..9));
It's extremely brute force and inefficient, but it works.
I have the philosophical problem with your use of junctions in this
context due to the fact that you are completely ignoring the predicate
of the junction. The C all(...) == one(...) is an excellent use of
junctions, that makes use of the predicates when the junctions are
evaluated. If you want threading without the predicate, I give you the
hyperthreader (well, I'm trying to).
I'll also point out that what you wrote above is a lot more readable as:
for 1..9 - $a {
for 1..9 - $b {
next unless $b == none($a);
for 0..9 - $c {
next unless $c == none($a, $b);
if $a + $b == $a * 10 + $c {
say $a + $b = $a$c
}
}
}
}
I mean, wouldn't it really be nice if you could write stuff like this:
my @users is persistent(users.isam);
my @accounts is persistent(accounts.isam);
my $r_user = any(@user);
my $r_account = any(@account);
if ( $r_account.user == $r_user ) {
say(That junction is:, $r_user);
}
I'm fairly certain that I'll be writing a Set class if no one beats me
to it.
use Sets;
my @users is persistent(users.isam);
my @accounts is persistent(accounts.isam);
my $s_validusers = set(@accounts».user) - @users;
for values $s_validusers - $user {
say $user is a valid user;
}
$r_user at that point represents only the users which have at least one
object in @accounts for which there exists an $r_account with a `user'
property that is that $r_user member[*].
The closure would then either be run once, with $r_user still a junction
(if the interpreter/`persistent' class was capable of doing so), or once
for every matching tuple of ($r_account, $r_user). We're still
talking in
terms of Set Theory, right?
If you want Set Theory.. use Sets. Or use some form of Logical
Programming which builds the sets implicitly for you, and does all the
filtering and backtracking you're asking for.
Both topics have been explored recently. The results of that exploration
can be summarized as:
- Sets would make a nifty module to have around.
- Integrating Logical Programming into Perl needs a lot more thought and
effort than will likely happen before 6.0.0. Modules grafting LP into
Perl and/or Parrot are welcome.
-- Rod Adams
