Re: Autothreading generalization
Luke Palmer writes: Craig DeForest writes: Yeah, the sigils do get in the way for small placeholder variables like these. @C[ $i; $j; $k; $l ] = @A[ $i; $j ] * @B[ $k; $l ] Losing the carets doesn't do much for us (and would force us to use the explicit syntax, whatever that might be). Hmm, on the other hand, ^ doesn't mean anything in term context yet. I feel uncomfortable about allowing ^ as a shorthand for $^, since every other variable in the whole damn language has one of the four standard sigils. What about adding fifth sigil into the language? To be used only with placeholder-variables? That way ^ (or whatever char we choose) wouldn't be shorthand for $^, but part of the actual variable name, as are other sigils. That char should be selected based on it's readibility in expressions like these. Would placeholder variables be used often enough to varrant their own sigil? Luke -- Markus Laire Jam. 1:5-6
Re: introduction
Comrade Burnout wrote: I remember seeing that the list-joining thingie mentioned an introduction once someone joined, so here it is: I'm geektron on perlmonks, and Brian Clarkson IRL. I've talked a bit to Mr. Lester and Mr. Kinyon about tests, and decided that learning some good testing skills while doing something useful added up to joining this list and the Phalanx project. I'm not sure where to start other than this. So hi and stuff. Re: Phalanx: If you're interested in working on this in an F2F manner (other hoplites in the same room!), sign up on the HereToHelp page of the Phalanx kwiki (http://phalanx.kwiki.org/index.cgi?HereToHelp) and indicate what city or metro area you live in. Or hook up with one of the local Perlmonger groups listed on the kwiki home page if you're in one of those areas. Jim Keenan
[Repost] Building with VS.NET 2003 and ICU 2.8 on Win32
If you've already seen this through the Google Groups interface, sorry! I'm
kind of confused about the syncing between the Google interface and this
list - and it seems that my posts never made it here. The original is here
(http://groups-beta.google.com/group/perl.perl6.internals/browse_thread/thre
ad/dd3cb5e94f1eb835/74b248bf61c2f1f6?_done=%2Fgroup%2Fperl.perl6.internals%3
F_doneTitle=Back+to+topics_doneTitle=Backd#74b248bf61c2f1f6).
I'm reproducing all 3 posts below
Post #1
---
I'm a Parrot newbie so forgive me if this has already been a-ddressed.
I'm trying to build Parrot (from CVS) on Win XP Sp2 with VS.-NET 2003.
1.The current build scripts for ICU refer to 'msdev'. 'msdev-' was the
executable for Visual Studio 6 . The executable, the command-line switches
as well as the file format have changed for VS.NET -2002 and
2003.Unfortunately, my unfamiliarity with Perl means that I -cannot submit a
patch :(
2. After downloading the latest ICU source from IBM's site, -I built that
from source (they have updated their src distribution t-o support building
using VS 2003).
Now, the Readme files says that you have to set icushared an-d icuheader -
but even after I set both to point to my ICU bui-ld, the build broke the
first time it tried to run parrot.exe (durin-g the nmake itself).
The offending piece of code is this (in string.c)
data_dir = Parrot_getenv(PARROT_ICU_DATA_DIR, free_data_d-ir);
if (data_dir == NULL) {
const char *prefix;
char *p, *build_path;
build_path = data_dir = const_cast(DEFAULT_ICU_D-ATA_DIR);
/*
* if the installed --prefix directory exists th-en use it
*/
prefix = Parrot_get_runtime_prefix(interpreter, -NULL);
if (prefix) {
p = strstr(build_path, blib);
assert(p);
--p;/* slash or backslash */
data_dir = mem_sys_allocate(strlen(prefix) +- strlen(p)
+ 1);
strcpy(data_dir, prefix);
strcat(data_dir, p);
free_data_dir = 1;
}
The first time I tried building it, the strstr call returned- a bad pointer.
Some investigation showed that the ICU data directo-ry was an empty string.
So this time, I tried building again, by passi-ng icudatadir to
Configure.pl.
The assert call wasn't being executed at all - must be somet-hing with the
compiler options.
It again crashed at the same spot - this time because the bu-ild_path
variable contained the ICU data dir -but there is no blib -anywhere
in it, making the strstr call fail.
Am I missing something pretty basic here?
Post #2
I managed to get it to build finally. I built ICU 2.8 and co-py-pasted
the data output to the blib folder.I don't think this is the- way to do
it - but hey..it works :)
Post #3
--
Yet another Win32 + VS 2003 update.
My 'nmake test' was failing with a liner error about nci_dlv-ar_vv.
After removing that from libnci_test.def, I was able to atle-ast run the
tests. Dynclass and nci tests failed - and at the end, got a- weird
error about perl.exe. Here's the output
Failed TestStat Wstat Total Fail Failed List o-f Failed
t\dynclass\pybuiltin.t5 1280 65 83.33% 1-2 4--6
t\dynclass\pyclass.t 6 1536 66 100.00% 1-6
t\dynclass\pycomplex.t1 256 11 100.00% 1
t\dynclass\pyfunc.t 4 1024 44 100.00% 1-4
t\dynclass\pyint.t 25 640025 25 100.00% 1-25
t\pmc\nci.t 55 1408056 55 98.21% 1-55
7 tests and 64 subtests skipped.
Failed 6/133 test scripts, 95.49% okay. 96/2166 subtests fai-led, 95.57%
oka
NMAKE : fatal error U1077: 'D:\Perl\bin\perl.exe' : return c-ode '0xff'
Stop.
Thanks,
Sriram
Re: lib/Make.pm obsolete?
Matt Diephouse [EMAIL PROTECTED] wrote: Since no one has said anything to the contrary, would someone remove it? Done. leo
Re: [perl #34002] [PATCH] 'const' for ParrotIOLayerAPI instances
François PERRAD [EMAIL PROTECTED] wrote: All instances of ParrotIOLayerAPI could be declared as 'const' in the IO subsystem. Thanks, applied. leo
Re: [perl #33995] [BUG] Configure warning on gdbmhash
Bernhard Schmalhofer via RT [EMAIL PROTECTED] wrote: I have changed dynclasses.in to use the CONDITIONED_LINE hack. So there is no longer a need to access a potentially undefined config value. Thanks, applied. leo
Re: [perl #33171] Error When Reading Past EOF
Matt Diephouse [EMAIL PROTECTED] wrote: The attached patch changes the error to: Cannot read line from empty filehandle Done. It also changes the function used to raise the exception from real_exception to internal_exception We've to change a lot of internal_exceptions to real ones eventually and print better diagnostics, so no. leo
Re: cvs commit: parrot/t/pmc object-meths.t
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
+else if (p-vtable-base_type == enum_class_NCI) {
It was requested[1] that I not add any Python specific methods to the
NCI method... accordingly, the majority of Python methods are morphed to
a PyNCI class which subclasses the base NCI class.
Well, I know that the above test isn't quite right. It should be:
if (VTABLE_isa(INTERP, p, CONST_STRING(INTERP, NCI)))
But that needs still more work - better PMC class inheritance in that
case. I've proposed to add an mro array to PMCs to simplify
inheritance checks.
[ for now, I've put in above line - should work ]
But then you effectively morph the resulting bound method into a NCI
instead of a PyNCI with the following line of code:
bound_meth-vtable = Parrot_base_vtables[enum_class_Bound_NCI];
Delegation is more appropriate in this instance, and would be able to
handle both NCIs and PIR methods with equal ease.
- Sam Ruby
Re: bound methods
Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: The common cases I want to optimize for are common functions being called as common functions. And common methods being called as methods. Yep, that's very reasonable. The easiest way to optimize for the common methods being called as methods is if the current object is not passed as the first argument. Why so? Python methods don't have a notion of an object - it's just the first argument passed into a function. So I don't quite understand your conclusion. In the case of x.y(z) The caller is passing one argument. The recipient is expecting two. The recipient defines what is expected as the first argument (in class methods it is the class, in instance methods it is the instance). So, in the general case, the callee is responsible for inserting a parameter at the beginning of the PMC parameters. Insertion by setting a value into P2 is cheaper than insertion by shifting and then setting a value into P5. Yes, copying will be required in cases where functions are called as methods. How do you detect this case and when are arguments shifted then - note: I prefer the term shifting as copying is done anyway in all sub calls (see src/sub.c:copy_regs). I agree that shifting is a more appropriate term. At definition time, the PyFunc PMC has a number of properties (or flags) which are set defining names of the formal arguments, defaults, and the like. A similar approach can be used to define whether the first parameter is expected in P2 or P5. Note: this is not yet implemented for Python on Parrot. Note: different languages may chose different strategies as to when to shift. What is important is that we come to an agreement on what is expected of the caller. - Sam Ruby
Re: [Repost] Building with VS.NET 2003 and ICU 2.8 on Win32
Sriram Krishnan [EMAIL PROTECTED] wrote: I'm trying to build Parrot (from CVS) on Win XP Sp2 with VS.-NET 2003. Please folks with Windows installed: have a look at these issues. leo
Re: bound methods
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Why so? Python methods don't have a notion of an object - it's just the first argument passed into a function. So I don't quite understand your conclusion. In the case of x.y(z) The caller is passing one argument. The recipient is expecting two. The recipient defines what is expected as the first argument (in class methods it is the class, in instance methods it is the instance). Yes. Let's start at the called sub/method. Specifically a user function y would looks this: 1) .sub y .param pmc x .param pmc z as this is the general translation of the user code y. If you know that it's a method, you currently could translate it like: 2) .sub y method .param pmc z x = interpinfo .INTERPINFO_CURRENT_OBJECT But at the caller site you don't know anything about y - so with your proposed argument passing the code in y would need a prologue to handle both cases in both callee variants, right? So, in the general case, the callee is responsible for inserting a parameter at the beginning of the PMC parameters. That's not all. Case 2) above - the method - can in all our target languages be called with a sub call syntax - AFAIK: y(x, z) This is the normal call syntax for Perl6 multi-subs. With two different schemes for the callee, we got two variants that would work w/o further argument adaption and two variants that need either shifting arguments up or down. But this prologue would be needed in every function or method. ... Insertion by setting a value into P2 is cheaper than insertion by shifting and then setting a value into P5. Already optimizing? - SCNR. Anyway: src/sub.c:copy_regs() already copies registers from the caller's register frame to the callee. Implementing argument shifting there is cheap - if it's still needed. By defining that all subs or methods get the arguments (including the object) passed in P5, P6 ... we'd only have half of the mis-matching argument orderings. At definition time, the PyFunc PMC has a number of properties (or flags) which are set defining names of the formal arguments, defaults, and the like. Yes, more complications. ... A similar approach can be used to define whether the first parameter is expected in P2 or P5. Sure. But why should we go the more complicated way in the first place? Note: different languages may chose different strategies as to when to shift. What is important is that we come to an agreement on what is expected of the caller. From the caller's POV its quite clear if it's a method or a function call. But if the other end has two incarnations, things get messy. - Sam Ruby leo
Re: cvs commit: parrot/t/pmc object-meths.t
Sam Ruby [EMAIL PROTECTED] wrote: But then you effectively morph the resulting bound method into a NCI instead of a PyNCI with the following line of code: bound_meth-vtable = Parrot_base_vtables[enum_class_Bound_NCI]; Yes. That's a general problem in all places, where the Parrot core creates a PMC that might be overridden in a specific HLL. I've proposed that we should have a table of core PMC = HLL mappings so that depending on the current language a correct PMC class is created. This is probably more important for scalar types, as basic math operations are usually the same, then in object-ish code, where differences tend to be bigger. Delegation is more appropriate in this instance, and would be able to handle both NCIs and PIR methods with equal ease. How should default.pmc:get_attr_str() look like? - Sam Ruby leo
hello all
I just skimmed the perl.com article about Phalanx, http://www.perl.com/pub/a/2005/01/13/phalanx.html and this project looks to be right up my alley. Anyhow, I've got a bit more reading to do on the project before setting out to make a contribution, but I figured I'd say a brief hello just for starters. Hello! -- = Shaun Fryer = http://sourcery.ca/ ph: 416-544-9461 =
[OT] post-structuralist object oriented system
For your entertainment: Luas Story of O http://alt.textdrive.com/lua/19/lua-story-of-o Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/
Re: [perl #34002] [PATCH] 'const' for ParrotIOLayerAPI instances
Layer and layer API members may be changed at runtime. Yes, the current structure members are all static, but they don't have to be. I would reverse this patch. -Melvin At 06:26 AM 1/31/2005, via RT wrote: # New Ticket Created by François PERRAD # Please include the string: [perl #34002] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34002 All instances of ParrotIOLayerAPI could be declared as 'const' in the IO subsystem. I hope that it's an improvement (better safer code) and not a problem for future feature. François Perrad
Re: Autothreading generalization
On Tuesday 01 February 2005 01:18 am, Markus Laire wrote: Luke Palmer writes: Yeah, the sigils do get in the way for small placeholder variables like these: @C[ $i; $j; $k; $l ] = @A[ $i; $j ] * @B[ $k; $l ] ... Would placeholder variables be used often enough to varrant their own sigil? Can't say for sure. This style of explicit threading was tried in PDL but turned out to not be as important as robust implicit threading, and the explicit threading (handled by block-scoped thread variables that you would declare before using them) never got robust enough to be considered a production feature. The current threading engine in PDL uses positional dimension slots to work out what is what: active dimensions have to be at the start of the dimension list, and thread dimensions have to be at the end. In principle, this is a Bad Thing since you sometimes have to transpose arrays just to get the dims in the right slots; but it turns out to be a Good Thing: it is the right optimization for nearly all of the expressions that ever get written. For example, with PDL-style threading, Luke's expression (written by someone paranoid) would be: $c = $a(:,:,*1,*1) * $b(*1,*1,:,:); # perl5/PDL 4-D outer product where the names have been replaced by dimensional positions. That still turns out to be more concise than the named version. Most of the threading ops I do in PDL turn out to have zero active dimensions (scalar op, being looped over). A few of them are vector ops (e.g. lookup into a table), and a lot are just matrix multiplication. I have only had a few opportunities to use 5-D constructs (e.g. a collection of i x j image tiles that are themselves arrayed in an n x m matrix, with 3 colors). I suspect that these sorts of higher dimensional operations will turn out to be ignored by virtually everyone -- but that they will turn out to be devilishly useful for a handful of brilliant people.
Re: [Repost] Building with VS.NET 2003 and ICU 2.8 on Win32
Leopold Toetsch wrote: Sriram Krishnan [EMAIL PROTECTED] wrote: I'm trying to build Parrot (from CVS) on Win XP Sp2 with VS.-NET 2003. Please folks with Windows installed: have a look at these issues. I'm running Windows XP, VS.NET 2003 and (precompiled) ICU 3.0, and can confirm the offending nci_dlvar_vv and the failed tests. Failed TestStat Wstat Total Fail Failed List of Failed --- t\dynclass\pybuiltin.t5 1280 65 83.33% 1-2 4-6 t\dynclass\pyclass.t 6 1536 66 100.00% 1-6 t\dynclass\pycomplex.t1 256 11 100.00% 1 t\dynclass\pyfunc.t 4 1024 44 100.00% 1-4 t\dynclass\pyint.t 25 640025 25 100.00% 1-25 t\pmc\nci.t 5 1280565 8.93% 3 8 46 51-52 7 tests and 64 subtests skipped. Most, if not all, tests fail b/c of Illegal PMC enum (0) in new. Should I file bug reports for every different looking problem, and start looking for what's going wrong? On a personal note, I (still) really like to help in win32, though it's quite hard for me to get a grip on this collaboration thingy. I am not sure what things are known (expected?) to broken, or who else is already working on which problem (avoid racing for patches, or patching something someone is already working on). I guess I am asking for a gentle push in the right direction here, to bring me up to speed. Ron
[perl #31921] Win32 streams test failure - tests 14 18
I guess this one can be closed. t\library\streamsok All tests successful. Files=1, Tests=20, 8 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Tested on win32-ms-cl_13.10.3077 (WinXP, VC.NET, ICU 3.0) (PS: Sorry for the duplicate comments on this issue.)
[perl #31921] Win32 streams test failure - tests 14 18
Closed, per Ron.
Re: Building with VS.NET 2003 and ICU 2.8 on Win32
Ron Blaschke writes: Should I file bug reports for every different looking problem, and start looking for what's going wrong? Yes please. email to parrotbug at parrotcode.org for each new issue. On a personal note, I (still) really like to help in win32, though it's quite hard for me to get a grip on this collaboration thingy. *looks around* Apparently, you're not the only one. =-) I am not sure what things are known (expected?) to broken, Check RT: http://rt.perl.org/rt3/NoAuth/parrot/Overview.html has a list of tickets broken out by platform, including mswin32 and Win32 (no clue why those are different). See also PLATFORMS and README.win32 in the top level of the distro. or who else is already working on which problem (avoid racing for patches, or patching something someone is already working on). In general, I don't think we have anyone working actively on win32 issues. If you wish to claim a ticket in RT, we can get you access. Do you have a perl.org account? In the meantime, simply post a followup to the ticket that you're looking into it. I guess I am asking for a gentle push in the right direction here, to bring me up to speed. I would recommend going through all the old tickets in RT and seeing which of them are still relevant. Cleaning out the cruft will allow us to focus on the remaining items that are actually issues. Also, any updates you may have to README.win32 as you move forward would be greatly appreciated. Regards.
Re: [perl #34002] [PATCH] 'const' for ParrotIOLayerAPI instances
MrJoltCola [EMAIL PROTECTED] wrote: Layer and layer API members may be changed at runtime. Yes, the current structure members are all static, but they don't have to be. Please note: only the layer API was changed. I would reverse this patch. A xxx_layer_api seems rather const to me, constituted from a bunch of well defined functions. A different set of functions would create a different API - probably. -Melvin leo
Re: cvs commit: parrot/t/pmc object-meths.t
[EMAIL PROTECTED] wrote:
+else if (p-vtable-base_type == enum_class_NCI) {
It was requested[1] that I not add any Python specific methods to the
NCI method... accordingly, the majority of Python methods are morphed to
a PyNCI class which subclasses the base NCI class.
- Sam Ruby
[1] http://xrl.us/exsu
Re: bound methods
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
... But that doesn't
work fur user methods, especially if there is no indication that a user
function is used as a method in the first place.
def find(s, sub):
...
In Python, this is statically determinable. If that sequence is
directly nested inside a class, it is a method, otherwise it is a
function.
No, we had that several times. You did show examples, where this isn't
true. Here is another one:
def add(l, r):
print in add
return 42
class C(object):
__add__ = add
c = C()
print c + 1
add is just a plain function. There is no indication whatsoever that
it might be used as a method, when add is compiled. But as infix+ is
a method call l.__add__(r) this doesn't work, if the object is in P2.
I've proposed several times that arguments including the object should be
passed from P5 up. The invocant - if any - can still be reachable with
the Cinterpinfo opcode, but it'll be probably used just in calls to SUPER
or next_method or such.
Less shifting will be required if the object is passed in P2.
That's only true for NCI methods. And IIRC, your arguments were the same
some time ago. How do you compile the add above, when the object is in
P2?
Notes: at the moment, every Python method call creates a bound object,
and shifts PMC arguments.
This shouldn't be necessary for normal method calls like:
s.f(r)
But this translates into two VTABLE calls. find_method and invoke.
find_method needs to return a bound method.
Why don't you just use the callmethodcc opcode? That's exactly what is
happening here.
A find_method_and_invoke VTABLE entry (or more simply call_method) would
not need to return the intermediary bound method.
There is no need for an intermediate object, if it's a plain method
call.
If there were a call_method VTABLE entry and if P2 were passed into
methods, all of this would be unecessary in the majority of cases.
A separate vtable slot doesn't really help. Code that looks like a
function call can actually be a method call (and vv). Separating the
call into two vtables will just duplicate the call sequence. But let's
first convince Dan that all arguments are passed from P5 up, then we'll
see what we have.
Less shifting will be required if the object is passed in P2.
See above.
And why are you duplicating object arguments into P5, if the object
should go into P2?
,--[ dynclasses/pyint.pmc ]---
| METHOD PMC* __hex__(PMC *self) {
`-
You are inventing an additional self argument here just to work around
the problem that the object is passed in P2. The actual object pmc is
ignored:
,--[ dynclasses/pyint.c ]---
| PMC*
| Parrot_PyInt___hex__(Interp* interpreter, PMC* pmc, PMC *self)
`---
As said in another message, there is no problem with NCI methods. It's
just a matter of translating the O signature char.
The problem are user functions. There might be an indication that's a
method (like a definition inside a class block) - but not always. And if
the latter is the case *only once*, we just have to call all methods
with plain function call argument passing. Or prepend *all* functions
with an argument check wrapper that shift arguments around, if the call
was actually a method call.
The current CVS is in a state of transition.
I originally implemented to the current set of PDDs. Unhappy with the
amount of copying of PMC registers, I optimistically converted over to
the pass self as P5 approach that you suggested. I found that that
simply moved the problem to other places, and copying was unavoidable.
In fact, it generally made things worse.
Given that copying is unavoidable, what I would like to do is to
optimize for what I consider the most common cases, and make all the
remaining cases work properly.
The common cases I want to optimize for are common functions being
called as common functions. And common methods being called as methods.
The easiest way to optimize for the common methods being called as
methods is if the current object is not passed as the first argument.
Yes, copying will be required in cases where functions are called as
methods.
- Sam Ruby
Re: cvs commit: parrot/t/pmc object-meths.t
Sam Ruby [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
+else if (p-vtable-base_type == enum_class_NCI) {
It was requested[1] that I not add any Python specific methods to the
NCI method... accordingly, the majority of Python methods are morphed to
a PyNCI class which subclasses the base NCI class.
Well, I know that the above test isn't quite right. It should be:
if (VTABLE_isa(INTERP, p, CONST_STRING(INTERP, NCI)))
But that needs still more work - better PMC class inheritance in that
case. I've proposed to add an mro array to PMCs to simplify
inheritance checks.
[ for now, I've put in above line - should work ]
- Sam Ruby
leo
Re: bound methods
Sam Ruby [EMAIL PROTECTED] wrote: The common cases I want to optimize for are common functions being called as common functions. And common methods being called as methods. Yep, that's very reasonable. The easiest way to optimize for the common methods being called as methods is if the current object is not passed as the first argument. Why so? Python methods don't have a notion of an object - it's just the first argument passed into a function. So I don't quite understand your conclusion. This isn't a python-only problem. Perl5 doesn't have an object either. Perl6 multi-methods provide both features: foo($a, $b);# probably a MMD call on both $a.foo($b); # a method call on 1st invocant The function or multi-sub foo can be basically anything in the first case including a lexical function foo and not a method at all. As long as we have different calling conventions for these 2 variants we have just a better chance for a mismatch IMHO. Yes, copying will be required in cases where functions are called as methods. How do you detect this case and when are arguments shifted then - note: I prefer the term shifting as copying is done anyway in all sub calls (see src/sub.c:copy_regs). - Sam Ruby leo
