Re: The last shall be last
John Williams writes: On Sun, 5 Sep 2004, Matt Diephouse wrote: Don't say -1st is the first from last. If last is the opposite of first, I would expect 1st to mean first from first, which would mean the second. Say first from the end. It matches up with perl5 C$array[-1] and is a workable interpretation of negative ordinals. So I could think that way too. @ary[ 1st .. -1st ]# hmm... But it doesn't match up. In Perl 5 the first element is indexed with zero, not 1st, and the indices wrap round -- which is convenient in some circumstances, especially when representing grids of things. Using 1st and -1st means that there's a 'gap': the wrapping-round misses a number out, which then has to be dealt with as special case. (But personally I'm quite happy with zero-based arrays, so as long as -1 continues to work for those I'm not too bothered what happens with other cases.) Smylers
Re: [perl #31424] [RESOLVED] PATCH: Fix for parrot linking issue on Solaris 8
Andy Dougherty [EMAIL PROTECTED] wrote: On Sun, 5 Sep 2004, Clayton O'Neill wrote: This adds support for setting triggers on specific config variables. I'd be inclined to call that particular routine solaris_gccversion_cb, Should the patch go in? Thanks. Andy Dougherty[EMAIL PROTECTED] leo
Re: [PATCH] dynamic pmc libraries
Steve Fink [EMAIL PROTECTED] wrote: This patch introduces something that feels suspiciously like libtool, despite the fact that libtool has never been very kind to me. But for now I am targeting this only at the dynamic PMC generation problem; this solution could be expanded to ease porting of other parts of the build procedure, but I think other people are already working on that. Looks good. I am not committing this patch directly because I know that other people are currently actively working on the dynamic PMC stuff and the build system, and I didn't want to step on anyone's toes. So please give it a try. Thanks, leo
Re: new examples
Jens Rieks [EMAIL PROTECTED] wrote: Hi all, there are now two new examples: Great. Minesweeper freezes after you have created some new fields (by clicking onto the smiley). I think it is a GC bug, because minesweeper does not even start with --gc-debug. Repeatedly clicking the smiley seems to go into some recursive calls in the stopwatch code (the timer gets started first and then reset). On the sixth or so click the timer starts running and the program stops with a Maximum recursion depth exceeded exception (the limit is at 1000). Removing the watch.start() at field.imc:1007 seems to cure this problem. Running it with --gc-debug takes already ~27000 DOD runs during initialization. Drawing the whole field takes a ~minute here, but it succeeds finally. --gc-debug isn't usable for programs doing real work. jens leo
Perl5 Bug Summary
[ We're down a handful this week... but not by much... thanks to Steve
Peters for going through some of the old ones and identifiying things
that can be closed. ]
Perl5 Bug Summary
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
Generated at Mon Sep 6 13:00:02 2004 GMT
---
* Total Issues
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Total Issues
Open Tickets: 1905
---
New Issues
New issues that have not been responded to yet
7-14 days old
31300 PerlIO::via UTF8 method
14-21 days old
31227 perldoc -f, -q ignores extra arguments with no notice
Over 21 days old (trimmed)
30051 Minor copy-paste bug in File::Spec::Win32-splitpath()
30123 foreach (, a..zz) confuses range optimizer
30296 localizing $? loses exit status from die()
30377 sort SUBNAME LIST
30406 File Find anomaly under windows
30424 BUG REPORT PERL / CGI ...: CGI / mod_perl / $query-defaults('defaults')
30507 FindBin::Bin 1.44 returns path with terminating slash
30563 [PATCH] Storable::dclone fails for tied elements
30576 Test::More thinks eq undef in hash value
30584 Test::More is_deeply bug
30622 -e tests not reliable under Win32
30633 Perl's do operator with a variety of absolute paths under Cygwin
30660 Repeated spaces on shebang line stops option parsing
30661 sort function @args will not autoload
30673 Missing getmagic in Digest::MD5
30715 IPC::Open3 child may return in the child process
30774 Encode::decode doesn't support CHECK=FB_CROAK
30807 Misleading error message from Storable
30811 build fail, perl 5.8.4, ia64-unknown-linux-gnu, gcc 3.3.4
30858 -wi but no file
30933 free to wrong memory pool using DBI, FetchHashKeyName and
selectall_hashref
30978 make test op/write failure
31028 perl -i fails on Win32 unless a backup string is provided for -i option
31080 make failure report plea for assistance
31089
---
Overview of Open Issues
Operating System Severity Type Perl Version
aix 28 abandoned 1 5005threads 0 1.00
All6 fatal 2 bounce0 5.000 0
bsdos 6 High 146 Bug 1 5.002 0
cygwin20 low 755 compiler 0 5.003 0
cygwin_nt 0 medium413 configure 1 5.004 0
darwin10 none 13 core581 5.004_00 0
dec_osf 16 Normal 2 dailybuild0 5.004_01 0
dgux 0 unknown 0 docs 15 5.004_02 0
dos2 Wishlist 14 duplicate 0 5.004_03 0
dynixptx 0 install 54 5.004_04 0
freebsd 48 library 252 5.004_05 1
generic 47 notabug 86 5.005 0
gnu0 notok 8 5.005_01 0
HPUX 29 ok0 5.005_02 1
irix 10 Patch 2 5.005_03 41
irix64 0 regex 6 5.005_04 1
Linux571 sendToCPAN1 5.6.0186
lynxos 0 Todo 1 5.6.1213
mac0 unknown 287 5.6.2 1
machten1 utilities30 5.7.0 24
macos 0 wontfix 0 5.7.1 7
MacOS X1 5.7.2 28
mswin32 88 5.8.0257
netbsd11
Re: What Requires Core Support (app packaging)
Simon Cozens wrote: For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't trust things which are self-declared scary hackery to be stable, you probably shouldn't be using Perl until Perl 6 comes out. And probably not until then. Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. Look, we're not going to agree on this. Should we just drop the subject? I know I've seen more than I wanted to. Dan
Re: Semantics for regexes - copy/snapshot
Just across the hall from m// is s/// ... Considering the semantics of m// and especially s/// at the user level, we'll probably[*] want to take snapshots of dynamic strings (think P5's FETCH or overload ''), and apply all the pattern operations to that snapshot. *However*, in the usual case of applying the pattern to a simple string, we want to avoid the overhead of making a copy. This may imply an API requirement. For Topaz, Scalar's interface included a function that would basically open the Scalar's hood, giving you a Buffer you could manipulate; then when you were done working with the Buffer, its modifications (if any) were propagated back down into the Scalar. In the case of a simple string, the Buffer in question was the actual guts of the string, so the propagation was a nop; for magical Scalars, the Buffer was a mortal result of a FETCH-analogue, and after the Buffer was done being manipulated it was STORE-analogued back into the Scalar and destroyed. Now Parrot could just punt on this by doing all the logic of snapshotting and copying as part of the implementation of the language-level feature, not down at the byte code. But it's hard. From the outside of a PMC, how can you reasonable ask the question are you a basic string? Does that question always *have* an answer? So we might think of open up and say 'h' as a string feature necessary for efficient regex work with minimal copying. [*] Unless it's a _feature_ that given tied $a, ($a = aaa) =~ s/a/b/g would call STORE four times (aaa, baa, bba, bbb). -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] Persistence in one opinion has never been considered a merit in political leaders. --Marcus Tullius Cicero
RE: Perl5 Bug Summary
31028 perl -i fails on Win32 unless a backup string is provided for -i option Should that really be a bug? You can't delete open files on Win32 so what is perl supposed to do? Yves
Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (Dan Hursh) writes: Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. They may need to write their own operating system if they want to avoid the dodgy software rot entirely. :) -- If you give a man a fire, he'll be warm for a day. If you set a man on fire, he'll be warm for the rest of his life.
Re: No-C, no programming project: Some configure investigation
On Tuesday 07 September 2004 07:52, Robert Schwebel wrote: Would autoconf/automake be an option for the C part of parrot? No, its only available on a few systems. Some months ago, I tried to cross compile Parrot to ARM (Zaurus), and to compile Parrot directly on the Zaurus, with no success (mostly due to lack of time). jens
Re: No-C, no programming project: Some configure investigation
On Tue, Sep 07, 2004 at 02:00:14PM +0200, Jens Rieks wrote: On Tuesday 07 September 2004 07:52, Robert Schwebel wrote: Would autoconf/automake be an option for the C part of parrot? No, its only available on a few systems. How do you mean that? You surely don't want to run the compiler directly on the target system, won't you? Besides that, autoconf runs on every platform which has a working shell, so if you have a bash on your PXA and if you run the compiler stuff on your target it should work anyway. Autoconf has the advantage that it has solved all the problems which will surely come up with a makefile system sooner or later, and it is established technology for nearly all possible platforms if it is done right. At the moment we have the situation that cross compilation doesn't work at all. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Re: TODOish fix ops
At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote: We still have a lot of unhooked ops w/o a definite opcode number. These are mainly the non-branching compare opcodes currently located in ops/experimental.ops. These opcodes have some limited usefullness for e.g. bool_val = (a b) (c d) i.e. for expressions that do not branch on the compare result. If a branch is done, the AST or whatever optimizer always can convert such sequences to our branching compare opcodes. I've found very little usage of these opcodes during translating Python bytecode or AST, albeit some code looks better with these opcodes and I have used these ops. They're useful in larger programs -- they significantly cut down on the number of branches and labels in languages that define comparisons to return a 0 or 1, and that cuts down on compilation time significantly. So first: - do we keep these opcodes? Yes. If yes some permutations are missing. Yeah. I'd as soon leave them out until we need them. For the rest of the opcodes in that file (gcd, rand) I don't think, that these should be opcodes. Both gcd and rand are e.g. supported in the GMP library too. The limited range of the existing opcodes and missing PMC variants precludes better implementations. Going with PMCs and vtables too seems like overkill to me. These can move into the standard library. Rand's probably a good candidate for a PMC, but that's a separate thing. I think, we need to make such functionality available as library functions. Please also remember that each opcode gets multiplicated into every runcore we have, with the whole function body duplicated. I'm thinking of putting these functions into e.g. ext/math.c and make it available as: math = get_namespace [math] gcd = math.gcd(...) Time to talk about namespaces and stake out the ones we want. I'll do that in the next message so we can keep the threads separate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Namespaces
Time to nail this. We need namespaces. Duh. We talked about this in the past. So, here's what I'm proposing. It'll be formalized into a PDD once we hash things out. *) Namespaces are hierarchical So we can have [foo; bar; baz] for a namespace. Woo hoo and all that. It'd map to the equivalent perl namespace of foo::bar::baz. *) Namespaces and sub-spaces can be overlaid or aliased So code can, for example, throw a layer over the ['foo'; 'bar'; 'baz'] part of the namespace that gets looked at first when searching for something. These layers can be scoped and shifted in and out, which means its possible to have two or more [IO] namespaces that have completely (or partially) different contents depending on which space is in use. It's also possible to hoist a sub-space up a few levels, so that the [IO] space and the [__INTERNAL; Perl5, IO] namespace are the same thing *) The top-level namespace [__INTERNAL] is taken. It's ours, don't touch in user code. Alternate names are fine. I'm seriously tempted to make it [\0\0] *) Each language has its own private second-level namespace. Core library code goes in here. So perl 5 builtins, for example, would hang off of [__INTERNAL; perl5] unless it wants something lower-down *) Parrot's base library goes into [_INTERNAL; Parrot] If this is fine, we can then go on to fight^Wdiscuss the standard aliases and such. I think it's time to start the parrot library project back up, which means we ought to deal with library versioning and such too. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Namespaces
Time to nail this. We need namespaces. Duh. We talked about this in the past. So, here's what I'm proposing. It'll be formalized into a PDD once we hash things out. *) Namespaces are hierarchical So we can have [foo; bar; baz] for a namespace. Woo hoo and all that. It'd map to the equivalent perl namespace of foo::bar::baz. *) Namespaces and sub-spaces can be overlaid or aliased So code can, for example, throw a layer over the ['foo'; 'bar'; 'baz'] part of the namespace that gets looked at first when searching for something. These layers can be scoped and shifted in and out, which means its possible to have two or more [IO] namespaces that have completely (or partially) different contents depending on which space is in use. It's also possible to hoist a sub-space up a few levels, so that the [IO] space and the [__INTERNAL; Perl5, IO] namespace are the same thing *) The top-level namespace [__INTERNAL] is taken. It's ours, don't touch in user code. Alternate names are fine. I'm seriously tempted to make it [\0\0] *) Each language has its own private second-level namespace. Core library code goes in here. So perl 5 builtins, for example, would hang off of [__INTERNAL; perl5] unless it wants something lower-down *) Parrot's base library goes into [_INTERNAL; Parrot] If this is fine, we can then go on to fight^Wdiscuss the standard aliases and such. I think it's time to start the parrot library project back up, which means we ought to deal with library versioning and such too. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Namespaces
At 9:17 AM -0400 9/7/04, Dan Sugalski wrote: Time to nail this. Dammit! Eudora's autocompletion feature bites me again. :( Should've gone to l6i. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Semantics for regexes - copy/snapshot
Chip Salzenberg [EMAIL PROTECTED] wrote: For Topaz, Scalar's interface included a function that would basically open the Scalar's hood, giving you a Buffer you could manipulate; then when you were done working with the Buffer, its modifications (if any) were propagated back down into the Scalar. The get_string() and set_string_native() vtable methods should do the right thing. The former returns a COWed copy of the string. If these functions are overloaded they'll implement magic of some kind. From the outside of a PMC, how can you reasonable ask the question are you a basic string? Does that question always *have* an answer? Well, the question is probably: how lazy are strings? Is it reasonable to implement regexen in terms of iteration? [*] Unless it's a _feature_ that given tied $a, ($a = aaa) =~ s/a/b/g would call STORE four times (aaa, baa, bba, bbb). I'd expect two stores here. One for the initial setting of the value and one for the final result of the global subst. leo
Re: Semantics for regexes - copy/snapshot
At 10:59 PM -0400 9/6/04, Chip Salzenberg wrote: Just across the hall from m// is s/// ... Considering the semantics of m// and especially s/// at the user level, we'll probably[*] want to take snapshots of dynamic strings (think P5's FETCH or overload ''), and apply all the pattern operations to that snapshot. *However*, in the usual case of applying the pattern to a simple string, we want to avoid the overhead of making a copy. This may imply an API requirement. Yeah, we need a bit more information tacked onto PMCs -- whether they can return a STRING that properly represents them or not. (PMC strings with pieces in different encodings, or with annotated text, wouldn't be able to) The plan here is for PMCs which can provide a STRING to do so, with the regex code then grovelling over it. On completion we call the set_string vtable method to put the resulting string back. PMCs which can't then get iterated over much more slowly, probably pulling characters out one by one. For these, the example you gave: [*] Unless it's a _feature_ that given tied $a, ($a = aaa) =~ s/a/b/g would call STORE four times (aaa, baa, bba, bbb). would call STORE four times. (Though I think all of perl 5's tied variables would be able to return a string rep, so you'd get STORE, FETCH, STORE called_ I think in all cases we'd get a new string out of a PMC, but since it's a COW version it'd be reasonably quick to do so. OTOH, I can certainly see the utility of returning the actual underlying string if we can, to avoid having to copy data. Hrm. Gotta think on how that should look a bit. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Namespaces
Dan Sugalski writes: Time to nail this. We need namespaces. Duh. We talked about this in the past. So, here's what I'm proposing. It'll be formalized into a PDD once we hash things out. *) Namespaces are hierarchical So we can have [foo; bar; baz] for a namespace. Woo hoo and all that. It'd map to the equivalent perl namespace of foo::bar::baz. *) Namespaces and sub-spaces can be overlaid or aliased Can you say, in [foo; bar; baz], toss in a different namespace implementation for [foo; bar] and have that call some function with baz? Will this work if it's [foo; bar; baz; quux]? Luke
Re: PMC instantiation
At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote: Pclass = getclass, Foo Pobjnew = Pclass.__new(args) # Pnew is an OUT argument and that be special-cased to call VTABLE_new according to calling conventions. Still don't like __new, but otherwise that works out OK. It'd call VTABLE_init_extended or whatever we'd name the entry. Ok. It is actually new_extended now. It's creating new objects, so init_extended didn't totally match the behaviou?r. Oh. This isn't right. The extended stuff's extended initialization, just like init is now. It works on the PMC it's attached to, rather than allocating a new PMC from the pool. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: TODOish fix ops
Dan Sugalski [EMAIL PROTECTED] wrote: At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote: - do we keep these opcodes? Yes. Ok. If yes some permutations are missing. Yeah. I'd as soon leave them out until we need them. Well, the asymmetry makes it harder for compilers to emit proper code. Is that variant already implemented. So I'd rather have it complete. These can move into the standard library. Rand's probably a good candidate for a PMC, but that's a separate thing. It *is* a PMC. The opcodes got added later. leo
Approach to testing code that sends emails
Hi,
Maybe someone will be interested in what I came up with to test sending
emails. Usually I use Mail::Mailer, but obviously I don't want to send
real emails during testing - at best, they won't go anywhere, and at
worst, they will go to real users and confuse them.
Now, I use in my code My::Mail::Mailer instead. It has the same API, and
actually dispatches all the calls to the real Mail::Mailer if it's
running in the production environment. However, if it's running tests,
it dispatches all the calls to an instance of My::Mail::FakeMailer. In
my code, testing and production environments are distinguished by the
value of $ENV{SERVER_NAME}.
The FakeMailer class stores each email in a separate instance, which
later can be accessed. For example, under the Test::Unit framework:
My::Mail::FakeMailer-flushInstances;
#Run code that sends emails...
my $mailer = My::Mail::FakeMailer-instances-[0];
$self-assert_equals('[EMAIL PROTECTED]', $mailer-hdrs-{To});
$self-assert_equals('[EMAIL PROTECTED]', $mailer-hdrs-{Cc});
$self-assert_equals('Correct subject', $mailer-hdrs-{Subject});
I had to use IO::WrapTie to correctly catch filehandle-like access, so
this is slightly non-trivial.
Any feedback is, of course, appreciated.
Simon
--
Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED]
http://www.simonf.com
Terrorism is a tactic and so to declare war on terrorism
is equivalent to Roosevelt's declaring war on blitzkrieg.
Zbigniew Brzezinski, U.S. national security advisor, 1977-81
package My::Mail::Mailer;
#Tue Sep 7 10:55:11 EDT 2004
#Simon Ilyushchenko
#In production environment call the real Mail::Mailer, in testing call FakeMailer.
use strict;
use Mail::Mailer;
use My::Mail::FakeMailer;
sub new
{
my ($class, @args) = @_;
my $instance;
if ($ENV{SERVER_NAME} eq test)
{
$instance = My::Mail::FakeMailer-new_tie(@args);
}
else
{
$instance = new Mail::Mailer(@args);
}
return $instance;
}
1
package My::Mail::FakeMailer;
#Tue Sep 7 10:55:11 EDT 2004
#Simon Ilyushchenko
#Mimicking the normal Mail::Mailer so that we could test sending emails.
use strict;
use IO::WrapTie;
use base IO::WrapTie::Slave;
my @instances;
sub instances
{
return [EMAIL PROTECTED];
}
sub flushInstances
{
my ($self) = @_;
@instances = ();
}
sub open {
my($self, $hdrs) = @_;
$self-{hdrs} = $hdrs;
}
sub close {
}
sub TIEHANDLE {
my $class = shift;
my $self = bless {}, $class;
push @instances, $self;
return $self;
}
sub PRINT {
my ($self, $string) = @_;
$self-{body} .= $string;
}
sub hdrs
{
my ($self, $val) = @_;
$self-{hdrs} = $val if $val;
return $self-{hdrs};
}
sub body
{
my ($self, $val) = @_;
$self-{body} = $val if $val;
return $self-{body};
}
1;
Re: [perl #31424] [RESOLVED] PATCH: Fix for parrot linking issue on Solaris 8
On Tue, 7 Sep 2004 10:50:49 -0400 (EDT), Andy Dougherty [EMAIL PROTECTED] wrote: Still, it's probably a good step forward. We might eventually decide we need pre- and post- triggers or other enhancements, but this is probably a good basis to start with. Pre and post triggers would be pretty easy to add, if there is any need. I didn't want to get into anything too complicated unless there was interest. With the patch I submitted, you can still change the values by calling set again, you just have to make sure you handle case in your callback. I'm not sure how well that would work with multiple callbacks though, that could get gross.
Re: Namespaces
Dan Sugalski [EMAIL PROTECTED] wrote: *) Namespaces are hierarchical What do we do against collisions? During Pie-thon hacking I came along this problem: class C(): pass c = C() C ought to be now a global classname (that's what the bytecode indicates) and it should be its own namespace for holding class methods. But the hash slot at C can only be used once. Or similiar: .namespace [foo ; bar ] prohibits any foo global in the top-level namespace. leo
Re: PMC instantiation
Dan Sugalski [EMAIL PROTECTED] wrote: At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote: Pclass = getclass, Foo Pobjnew = Pclass.__new(args) # Pnew is an OUT argument and that be special-cased to call VTABLE_new according to calling conventions. Still don't like __new, but otherwise that works out OK. It'd call VTABLE_init_extended or whatever we'd name the entry. Ok. It is actually new_extended now. It's creating new objects, so init_extended didn't totally match the behaviou?r. Oh. This isn't right. The extended stuff's extended initialization, just like init is now. It works on the PMC it's attached to, rather than allocating a new PMC from the pool. I was always talking about a class method that returns new objects like in the example above. If we need extended initialization too, then that's a different set of opcode/vtable. The Cnew_extended matches nicely Python's object construction, like: c = complex(1,2) where complex actually is a class. leo
Re: [perl #31424] [RESOLVED] PATCH: Fix for parrot linking issue on Solaris 8
Andy Dougherty [EMAIL PROTECTED] wrote: imcc/imcc.l, line 852: warning: improper pointer/integer combination: arg #2 Is already fixed. Still, it's probably a good step forward. Ok. leo
Re: Namespaces
On Tue, Sep 07, 2004 at 09:26:14AM -0400, Dan Sugalski wrote: Time to nail this. We need namespaces. Duh. We talked about this in the past. I've reordered these to put the simple/fundamental things first: *) Namespaces are hierarchical *) The top-level namespace [__INTERNAL] is taken. *) Each language has its own private second-level namespace. *) Parrot's base library goes into [_INTERNAL; Parrot] I presume you've looked at this thread again: http://groups.google.com/groups?hl=enlr=ie=UTF-8safe=offthreadm=20040116110746.GA38383%40dansat.data-plan.com Anything you disagree with there? I think a filesystem analogy is a very helpful one. Many of the issues are similar and there's a lot of experience with how to address them in creative ways. I'd suggest adding: *) Each interpreter has a current root namespace from which namespace searches start. (Analogous to chroot() in unix.) Apart from enabling functionality analogous to chroot() in unix, it also avoids having to prepend [_INTERNAL; language] to all namespace lookups and avoids the overhead of then traversing through those two levels. *) ...something here about namespace objects and how namespace traversal is performed (methods/vtable foo)... *) Namespaces and sub-spaces can be overlaid or aliased So code can, for example, throw a layer over the ['foo'; 'bar'; 'baz'] part of the namespace that gets looked at first when searching for something. These layers can be scoped and shifted in and out, which means its possible to have two or more [IO] namespaces that have completely (or partially) different contents depending on which space is in use. I'd be interest to know your thoughts on how that that might be implemented. Seems like you'd need a 'sparse tree' of proxy namespace objects that you'd start searching first and that would fallback to the corresponding real namespace object at the point no match was found. But it doesn't seem worthwhile going into much detail till the namespace traversal bullet above is filled out. (I'm reminded of the translucent filesystem (TFS), but it's effect is globally visible.) It's also possible to hoist a sub-space up a few levels, so that the [IO] space and the [__INTERNAL; Perl5, IO] namespace are the same thing Not actually move, but make visible at? Like a symbolic or hardlink in a filesystem. Tim.
Re: What Requires Core Support (app packaging)
John Siracusa wrote: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. We can support this in several ways. We can say that core perl also supports the above if the file is a gzipped tar file, and contains a main.pl (including adding the archive to @*INC). We can ship a script with perl, and have the user use the #! mechinisim to run it, with the actual file being specified to be a #! line, ending with some combination of CR and LF, then a tarball. This is probably a lot more work for perl core, but would be quite nice. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. Parrot supports this well enough that it will be hard for perl6 to mess it up. Parrot, indeed, already supports... 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to bootstrap community implementations. Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The others require standard-library support, but all the major bits are things that should already be in the standard library (because a front-end to C6PAN should come with, and that means extracting some sort of .tar.gz files -- calling out to external utilities doesn't cut it too often). -=- James Mastros PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's and postfix:'th? It's 80s and postfix:th!
Re: What Requires Core Support (app packaging)
On Tue, 7 Sep 2004, James Mastros wrote: PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's Maybe in the 80's is like at the Jones's. Not that I care, mind you. and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. $foo = 3; @array[ $foo'th ];
mod_parrot progress
i've made some good progress on mod_parrot. since so much has changed in the past year, i decided to rewrite the thing from scratch. here's what i've been able to implement so far: * rewrite for apache 2 (might as well start with the latest) * per-process interpreter persistence (using prefork MPM) * ability to call individual subroutines (good for handlers) it's at the point where you can set mod_parrot as the handler for a location, and it will call a location-specific subroutine when invoked. this is more for proof-of-concept than anything else, but it is quite promising nonetheless. i'm currently working on the apache 2 PMC and ops, which, like most things in apache 2, will require some relearning. once those are stable enough, i'll clean things up and throw the code out there for people to play with. -jeff
Re: Perl 6 compilers list
On Tue, Sep 07, 2004 at 04:11:18PM +, Herbert Snorrason wrote: So ... it's actually happening? There's really going to *be* a Perl6? It's not just an april fool's gone wrong, like Parrot? ;) Mark my words: There will be a Perl 6. Pm
more ordinal discussion
On Tue, 7 Sep 2004, Juerd wrote: John Williams skribis 2004-09-07 11:37 (-0600): and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. @array[ $foo'th ]; Maybe what I'm saying now is a really bad idea, because it doesn't make sense, but can't we just have an adverb that changes an integer into an ordinal? 4 :th $foo :th No. Adverbs modify verbs (operators or functions), not terms like 4 or $foo. Obviously, the : should be optional for literal integers: 4th 3th Yes, because 3 and th parse as different tokens.
Re: more ordinal discussion
John Williams skribis 2004-09-07 12:49 (-0600): 4 :th $foo :th No. Adverbs modify verbs (operators or functions), not terms like 4 or $foo. Then perhaps a method? Number::th? 4.th $foo.th I really dislike the apostrophe. Juerd
Re: Namespaces
On Tue, 2004-09-07 at 09:26, Dan Sugalski wrote: *) Namespaces are hierarchical So we can have [foo; bar; baz] for a namespace. Woo hoo and all that. It'd map to the equivalent perl namespace of foo::bar::baz. [...] It's also possible to hoist a sub-space up a few levels, so that the [IO] space and the [__INTERNAL; Perl5, IO] namespace are the same thing This sounds fine, except for the higher level question of who controls the root. That is, does a module Python decide to define its bits in the Python space AND export them to the root? The other way to go is to say: #!/usr/bin/perl6 use __Python::os; Which has the interesting result that no one ever need touch the root. There's simply a search path that each language uses that would default to [] and its own [__Internal;$language]. Alternate names are fine. I'm seriously tempted to make it [\0\0] Heehee. I don't think __INTERNAL is so bad. *) Each language has its own private second-level namespace. Core library code goes in here. So perl 5 builtins, for example, would hang off of [__INTERNAL; perl5] unless it wants something lower-down Ok, so that's where split would go, right? Does that mean that if, in Python, I wanted to use Perl 5's split, I'd just have to: import __INTERNAL.perl5 list = split '\\ba(?=b)', the_string, 5 ? That's some nifty beans! Sounds great, Dan. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs
Re: What Requires Core Support (app packaging)
James Mastros wrote: We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. Only [this] requires Cperl support, and that support is very minimal. I Agree. This is much simpler than what i came up during the recent discussion about app packaging: I touhght that it be nice to let module writers somehow associate their module with a file extention. This could also be useful for Modules that change the standart Perl 6 Syntax. The module that contains these macros could associate itself with a extension (e.g. *.klingonpl / *.kpl) In that way, its immediately clear that some macros are at work. Maybe this helps in other cases aswell, where the header is somehow predefined and its not possible to add some shebang magic or a use- clause to indicate some special treatement... Would such a feature be useful at all ? Thomas Seiler
Re: No-C, no programming project: Some configure investigation
On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote: Seriously, I've never come across any system that lacked autoconf support AND which a high level language like those that would target Parrot, ran on. If you're referring to the number of systems that have autoconf supports Win32? Nicholas Clark
Re: What Requires Core Support (app packaging)
Thomas Seiler skribis 2004-09-07 20:23 (+0200): I touhght that it be nice to let module writers somehow associate their module with a file extention. Most worlds don't use file extensions, except for humans. In the Windows world, file extensions do matter, because it decides which program to use to run the file, how to extract the icon from the file and often even whether to scan it for viruses or not. In my world (Linux, commandline), I only use .pl to remind me to use the file with perl. I could just as well have used .sh, .c, .exe or even [EMAIL PROTECTED]:\%% ~*?#$ @$^%. In fact, it does not need an extension at all, because the . isn't special. I can use any character except \0 and /. If I want, I can use _ to separate base name from extension, because my operating system has no idea that the . that some files have, has a special meaning to me. I have many text files without any extension, many executable files with extensions. I have some text files ending in .txt and many executables with no extension at all. Even if perl wanted to associate a module with a file extension, I doubt there would be any way to make this work with all platforms it's going to run on. In fact, I don't doubt that perl will work an platforms without a filesystem :) Juerd
Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Generator-0.22.tar.gz
Hi!
You can read various infos and look at some data in my use.perl journal:
http://use.perl.org/~domm/journal/20771
On issue I'd like to ask is: We (Gabor Szabo and I) are thinking of renaming
the distribution from Module::CPANTS to CPANTS. Do you think that this
is a good idea?
IMO CPANTS doesn't fit very well into the Module-Namespace as it's not about
a Module, but about a lot of Modules/Distributions, about metadata, Kwalitee
and CPAN...
Any comments?
- Forwarded message from PAUSE [EMAIL PROTECTED] -
Date: Tue, 7 Sep 2004 21:47:39 +0200
Subject: CPAN Upload: D/DO/DOMM/Module-CPANTS-Generator-0.22.tar.gz
To: Thomas Klausner [EMAIL PROTECTED]
From: PAUSE [EMAIL PROTECTED]
The URL
http://domm.zsi.at/download/Module-CPANTS-Generator-0.22.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DO/DOMM/Module-CPANTS-Generator-0.22.tar.gz
size: 14098 bytes
md5: 99715e765d303e272141c406b2352e83
No action is required on your part
Request entered by: DOMM (Thomas Klausner)
Request entered on: Tue, 07 Sep 2004 19:46:43 GMT
Request completed: Tue, 07 Sep 2004 19:47:38 GMT
Thanks,
--
paused, v460
- End forwarded message -
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
GC bug triggered in examples/streams?
Hi, the examples in examples/streams are not working with --gc-debug, FileLines.imc crashes even without it. Any idea why? jens
Re: Reverse .. operator
Hmm, this would suggest that in P6 the comment that unlike ++,
the -- operator is not magical should no longer apply.
On Fri, Sep 03, 2004 at 08:09:23AM -0400, Joe Gottman wrote:
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 02, 2004 8:41 PM
To: Perl6
Subject: Re: Reverse .. operator
On Thu, Sep 02, 2004 at 08:34:22PM -0400, Joe Gottman wrote:
: Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? I know you
can
: go
:
: @foo = reverse (1 ..5);
:
: but this has the major disadvantage that it cannot be evaluated lazily;
: reverse has to see the entire list before it can emit the first element
of
: the reversed list.
I don't see any reason why it can't be evaluated lazily. The .. produces
a range object that gets shoved into the lazy list that gets bound to
the slurp array of reverse(). If you pop that, there's no reason it
couldn't go out and ask the end of the lazy list for its last element.
Just have to make .. objects smart enough to deal off either end of
the deck.
I get it. One way to implement this would to give the .. object a
.reverse member iterator that lazily iterates from right to left, and have
the reverse subroutine call the .reverse member on the list that was passed
to it (if this member exists). The advantage of this is that it can be
extended for other types, or even to arrays returned from functions. For
instance,
multi sub grep(Code $f, [EMAIL PROTECTED] does reverse) returns (Array does
reverse {grep $f, @array.reverse;}) #reverse input
multi sub map(Code $f, [EMAIL PROTECTED] does reverse) returns (Array does reverse
{map {reverse $f($_)} @array.reverse;}) #reverse input and result of each
call to $f
If it isn't possible to overload a multi sub on a .does property, we can
achieve the same effect by creating a ReversableArray class that inherits
from Array and overloading on that.
Joe Gottman
--
Re: more ordinal discussion
Juerd wrote: John Williams wrote: 4 :th $foo :th No. Adverbs modify verbs (operators or functions), not terms like 4 or $foo. Then perhaps a method? Number::th? 4.th $foo.th Again, with a bit of magic where the dot is optional when the object in question is an integer literal: 4th =:= 4.th - and probably with special synonyms for th when the literal is any of (1 or -1, 2 or -2, 3 or -3) - Number::st, Number::nd, and Number::rd, respectively. Mind you, these wouldn't _really_ be methods, since they would only be valid when used within the arguments of a list's postcircumfix:[] operator. And while I like the notion that 0th has a valid meaning and that its meaning fits into a scheme that parallels the wraparound behavior of standard lists (i.e., perl 5's 0-based contiguous lists), I can see the arguments for both 1st referring to the first element and -1st referring to the last argument (which, if both are accepted, would leave 0th out in the cold). Of the two, 1st =:= first is the more compelling argument; and if one of the two arguments has to be rejected, I'd rather it be the -1st =:= last one. So we've come up with two mutually exclusive schemes for ordinal indices, depending on which of 0th or -1st refers to the last element of a list. There's a third option where the last element isn't given an ordinal at all; but I doubt that anyone would prefer this, even as a second choice. The pros and cons of each approach have now been discussed at length, and it appears that we've reached an impasse of sorts. So let me just summarize the positions, and ask for Larry's thoughts on the issue. 0th =:= last: Lists using this type of ordinals would behave exactly like a perl 5 list, except that [$n.th] would correspond to [$n-1] rather than to [$n]. You'd read non-positive ordinals as offsets from the last element, which isn't quite symmetric with the way that positive ordinals would be read. -1st =:= last: This type of ordinal index maintains a symmetry between positive and negative indices, treating the sign of the ordinal as an indication of which end of the list to start at. C0th would be undefined, which makes some intuitive sense; but you'd have to watch out for such things as (1 + $n).th, which would throw an error if $n was -1, and would work differently for $n -1 and $n -1. Either way, I'd be in favor of being able to use Clast as a synonym for the ordinal corresponding to the last element in a list (and, for symmetry, Cfirst as a synonym for 1.th or 1.st); it's at worst one character longer than the ordinal in question, and its meaning is clear and unambiguous. The only problem with it is when you're dealing with sparse arrays: [last - 1] won't neccessarily do what you want it to, depending on what you want it to do. To avoid confusion in the discussion, let's look at the other end (where we're pretty much agreed on the meaning of 1st and first): if we want to look at the next existing element, we can say (1 + 1).th; if we want to look at the element whose index is one higher than the first index, we can say 1.st + 1. With Cfirst, we can do the latter but not the former. = Jonathan Dataweaver Lang ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
Re: What Requires Core Support (app packaging)
On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) This work was completed as a result of a TPF grant that Daniel Grunblatt received last year: http://www.perlfoundation.org/gc/grants/2003_q2.html Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The and as you say all this really isn't about perl 6 the language. Nicholas Clark
Re: Bundles
From perl6-language (Matt Diephouse essentially suggested that this issue be brought here). Smylers wrote: John Siracusa writes: To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. Yes, it's great to be able to roll your own solution, but forcing the issue by providing nothing but the most basic features required to bootstrap a custom solution leads to too much variety and confusion. For some features, familiarity and standardization are more important. That only works if the 'core' feature is unquestionably 'right' and can't be improved upon by somebody else (or indeed by the same person, but later). John is correct in this case, though. Even if someone can come in after and provide a better solution, unless it is actually part of the base implementation of Perl 6, it will not accomplish the ultimate goals of having a bundling system. The bundling system needs to simply _be there_. A developer needs to know that anywhere they find Perl 6 on a system that has some concept of 'files' their bundle will run (unless of course the bundle contains platform dependent libraries now, *that* is a problem for a external module (or is it?)). Even if the ultimate choice of a built-in bundling system is utterly wrong, it is hardly less wrong that having none at all. Besides, if we implement a bundling system that cannot be trivially expanded into something more glorious than we have definitely gotten it wrong. (So let's not do that.) I think a minimalist approach is best. James Mastros suggested something that seems to be be unquestionably 'right'. James Mastros wrote: We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. He expounds beyond that on how to include support for archives. This solution seems to give us the best of both worlds. The user can easily expand this mechanism to use something like PAR (if not 'PAR for Perl 6' itself), or any module they like. And the basic bundling system gives them the ability to bundle their bundling system into the bundle! ( so I can bundle in my platform dependent library extension ) For most applications, James solution is more than adequate. For anything more complicated than that, including it in the official implementation might be a mistake. Then again, it might not. The more I think about it, the greater the benefit there seems to be in having a standardized way to include multi-platform C libraries in a perl bundle. The Mac OS X bundles work this way (though no one really uses this feature). But that can of worms is so large that despite its utility I cannot (quite) justify the cost. Application distribution is a pain. Let's make Perl application distribution easier. Gregory Keeney
Re: Bundles
Nicholas Clark wrote: On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) But that does not eliminate the desire for a bundling mechanism though any bundling mechanism should be able to take advantage of this. Suppose I have resource files I wish to include in my bundle although they _could_ be built into the executable that is not always desirable (especially if you want to be able to alter the resource files on the fly). and as you say all this really isn't about perl 6 the language. Nicholas Clark Thus, I reply to perl6-compiler. grin / Gregory Keeney
Re: No-C, no programming project: Some configure investigation
On Tue, 2004-09-07 at 11:59, Andrew Dougherty wrote: Both autoconf and metaconfig assume a unix-like environment. Ambitious plans for parrot's configure include non-unix environments too, such as VMS and all the ports where perl5 uses a manually-generated config.* template. autoconf assumes m4 and shell and some other primitive tools, all of which have GNU ports to just about everything I've had to touch. VMS is the bastard child of autoconf right now, but back when VMS was a platform that folks used, it certainly was supported (as late as 1999 it worked great). I don't think it's the UNIXishness of the platform as much as the popularity of the platform that guides autoconf support (e.g. any platform for which patches are contributed). The guy who tried to update the autoconf 1.x version this year kind of kicked the autoconf guys in the shins verbally and got nowhere as a result. He then forked it and has since apparently dropped support. That said, if you have a manually generated template as you do for Perl 5, you can do the same for autoconf, no? I'm not advocating autoconf here, just exploring the lay of the land. Personally, I think Parrot should do whatever makes it easiest for maintainers. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs
Re: Bundles
At 2:48 PM -0700 9/7/04, Gregory Keeney wrote: Nicholas Clark wrote: On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) But that does not eliminate the desire for a bundling mechanism - though any bundling mechanism should be able to take advantage of this. Suppose I have resource files I wish to include in my bundle - although they _could_ be built into the executable that is not always desirable (especially if you want to be able to alter the resource files on the fly). And so, we recreate NeXTStep App bundles. Wheee! :) and as you say all this really isn't about perl 6 the language. Nicholas Clark Thus, I reply to perl6-compiler. grin / Though it really ought to be on perl6-internals, since it's not really a perl thing at all, rather a parrot thing. I don't think I've the cycles to think about it for a while, though. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
No Autoconf, dammit!
This argument's old. Very old, so it may be unfamiliar to many people. The subject generates enough heat that I don't want to go there again. We are not using autoconf. Period. Parrot's build process, when shipped will be: *) Person building runs platform-specific script *) Script builds miniparrot, which assumes ANSI C89 functionality only *) Miniparrot runs provided configure program, which is in bytecode *) Configure probes environment *) Full parrot is built *) Full parrot is then invoked to complete the build process, which is driven by a program written in a parrot language and provided as bytecode -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Bundles
Dan Sugalski wrote: Though it really ought to be on perl6-internals, since it's not really a perl thing at all, rather a parrot thing. I don't think I've the cycles to think about it for a while, though. Sounds like I need to dig through the mail archives, RFC's, etc. and try to come up with a coherent picture of the state of Perl 6 app bundling. I suspect it is not an issue for Parrot only or perl only or Perl only, but something that all three will have to play nice about. I will try to work out a nice summary for everyone to argue over. (Maybe John Siracusa will be willing to look it over before I post it; he is good with this kind of stuff.) Gregory Keeney
A note on constant strings
Or, rather, the const_string function. Simple thing, looks like: STRING *foo = const_string(interpreter, c-style string constant); Easy, right? Yeah. Easy. What it does is create a new parrot string, set to the constant C string you pass in. Handy. Even marks the string as constant and external, and reuses the string constant data for the body of the string. (So there's no actual data copying for the string) All this is cool, but... parrot doesn't garbage collect constant strings. Nor does const_string do any sort of constant string pooling, so if you call, say, const_string multiple times: foo = const_string(interpreter, a); foo = const_string(interpreter, a); you've just leaked string headers. Two of 'em. (Woohoo!) Which, if you were looking to get a string which is a real parrot constant, shared across, well, everything... you didn't get one. Not that const_string isn't useful -- it is, very much so. Just in a limited set of circumstances, such as building the string constant table. I believe Leo came up with a partial solution at one point, though it looks like it may not be generally applicable, and we could do some hash lookups in the constant string creation, though I'm not sure we'd want to pay that cost for each constant string. (But, then, maybe we would, I dunno) As a partial workaround, I've added a string_from_const_cstring function, which is much like the string_from_cstring function, only it assumes you pass in a persistent, non-moving string, so it does the I set my buffer pointer to your contents, woohoo! thing to skip the copying step. It does *not* mark the resulting string as constant, so if you twiddle it then the string'll do the COW thing as it ought. The patch'll get checked in as soon as its done being tested and I sync up with any collisions with what Leo's been doing today. (This note brought to you by the letter pi, the number e, and the ten hours I burned today trying to figure out why my reports were chewing up massive amounts of memory as they ran, but showed no PMC or buffer leakage in the GC stats. Parrot was leaking one string header per bytecode vtable method call. That adds up after a while...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Bundles
Dan Sugalski wrote: You've got things a bit turned around I think. Parrot's the engine. It provides the services, runs the code, handles the environment, and generally manages stuff. If you want, think of it as a combination CPU, OS, low-level debugging tools, and standard system libraries that compilers for all the languages use. Since you're likely going to want to package up bytecode, resources, library modules, and possibly multi-language source, it's Parrot's problem to make it work right, and set up a base so that everyone does it the same way. So, bundling is a Parrot problem. Parrot's solution will dictate certain requirements / benefits to perl. Perl, on the other hand, is largely agnostic to all this. Makes sense. Sorry for the confusion. My understanding the exact nature of the symbiosis between the future perl 6 implementation and parrot is still weak learning what there is to know about the current state of bundling should correct that. (I was thinking of parrot simply running the code and perl dealing with all the other stuff. Now that I think about it I realize that that doesn't even make all that much sense (writing device drivers messes with your head).) Gregory Keeney
Re: No-C, no programming project: Some configure investigation
On Tuesday 07 September 2004 03:47 pm, Nicholas Clark wrote: On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote: Seriously, I've never come across any system that lacked autoconf support AND which a high level language like those that would target Parrot, ran on. If you're referring to the number of systems that have autoconf supports Win32? Those win32 systems with a shell, C compiler, and the other various UNIX trappings that autoconf requires, yes ;) Andrew
Re: Semantics for regexes - copy/snapshot
On Tue, 7 Sep 2004, Leopold Toetsch wrote: [*] Unless it's a _feature_ that given tied $a, ($a = aaa) =~ s/a/b/g would call STORE four times (aaa, baa, bba, bbb). I'd expect two stores here. One for the initial setting of the value and one for the final result of the global subst. So how many stores do we expect for ($a = xxx) =~ s/a/b/g and which of the possible answers would be more useful? -- War against Terrorism is an oxymoron
Re: Bundles
On 9/7/04 6:31 PM, Gregory Keeney wrote: Dan Sugalski wrote: Though it really ought to be on perl6-internals, since it's not really a perl thing at all, rather a parrot thing. I don't think I've the cycles to think about it for a while, though. Sounds like I need to dig through the mail archives, RFC's, etc. and try to come up with a coherent picture of the state of Perl 6 app bundling. I suspect it is not an issue for Parrot only or perl only or Perl only, but something that all three will have to play nice about. I will try to work out a nice summary for everyone to argue over. (Maybe John Siracusa will be willing to look it over before I post it; he is good with this kind of stuff.) I just want to make sure that people are thinking about it on all levels, not just the Parrot level. An ideal solution spans all levels. Unfortunately, in the absence of a design for such a solution (or even a concrete set of requirements) its hard to know what each part has to do. In these situations, it's best to just make sure the topic is in play, and then let the geniuses stew on it for a while :) The the Parrot folks go really nuts, they could end up implementing 90% of the solution, in which case the perl 6 executable support is simple and the stdlib and third party library ecosystem follow naturally. At that point, the only remaining debate is which lib, if any, is the 'default' or 'official' lib? Anyway, I think I need to think about it some more too. And being the bottom-up kind of guy that I am (witness my religious reading of per6-internals despite the fact that I loathe C and a lot of the discussion goes over my head) I think I'll have a better picture of what's possible when Dan finally does get around to giving it some thought (and then having his thoughts endure the crucible that is p6i :) -John
Re: Synopsis 9 draft 1
On Fri, Sep 03, 2004 at 11:20:05AM -0700, Larry Wall wrote: On Fri, Sep 03, 2004 at 11:41:05AM +0100, Tim Bunce wrote: : And that a pointer would be... what? Some platforms has odd : sizing issues for pointers. Perhaps a voidp type is needed? : (Which would just be an intN where N is sizeof(void*)*8.) Eh, pointer? I don't see any pointers around here...but then I haven't looked very hard on purpose... The Honeywell 6000 (which is still around as a machine from Bull with a 6 in its name, I believe) was a word addressed machine. (Words were 36 bits long and could hold 4 9-bit characters packed into each one.) Pointers used a few high-order bits to encode the byte-number within the word for languages like C which thought that character addresses were a meaningful part of the language. (So did old Control Data machines, come to think of it - 60-bit words containing 6-bit and/or 12-bit characters.) If a int1 (or int2 or nybble or other sub-addressable sized value) is being referred to, a similar issue arises since most machines these days have byte addressing, but do not have bit addressing. If you can't refer directly to it, the value will have to be extracted and re-inserted to provide is rw access. --
Re: Progressively Overhauling Documentation
Mark Overmeer [EMAIL PROTECTED] writes:
Oops, someone starts the holy war (again). Wether you put the docs
in begin or end of the file, or intermixed with the code has a lot
to do with your personal background.
Sorry for the late reply, but I can't let this stand without further
elaboration: intermixing the POD with the functions is something some
of us would really like to do, but in Perl5 the evil stupid whitespace
rules of POD make it impracticable, because it horks over the
indentation (and thus the legibility) of the whole program.
If we fix nothing else about POD in Perl6, it is *imperative* that it
become possible to indent the POD to at least the same level as the
code. Otherwise POD will never become a viable substitute for the
extensive comment blocks it ought to displace.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Synopsis 9 draft 1
On Tue, Sep 07, 2004 at 10:34:33PM -0400, John Macdonald wrote: : If a int1 (or int2 or nybble or other sub-addressable sized : value) is being referred to, a similar issue arises since most : machines these days have byte addressing, but do not have bit : addressing. If you can't refer directly to it, the value will : have to be extracted and re-inserted to provide is rw access. Well, sure. Is this any more of a problem than vec() in Perl 5? Larry
Re: more ordinal discussion
Juerd wrote: Jonathan Lang skribis 2004-09-07 14:12 (-0700): if we want to look at the next existing element, we can say (1 + 1).th; if we want to look at the element whose index is one higher than the first index, we can say 1.st + 1. I read this three times, but don't get it. Can you please explain what the difference is between the element after the 1st and the element whoso index is one higher than the 1st's? I think (correct me) what he's getting at here is a sparse array 1=a, 3=b, 4=c where 2nd is 'b' (the second item) but 1st+1 is undefined (there is no index 2). I don't know how well that scheme works from a comprehension point of view though, it seems a little confusing. -Michael
SDL usage broken?
When I try to run one of the SDL examples (any of them), I get: SDL::fetch_layout warning: layout 'Pixels' not found! Segmentation fault When I edit runtime/parrot/library/SDL.imc and add the call to _set_Pixels_layout in at line 60, I remove that warning, but still get the seg-fault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -150897856 (LWP 15959)] 0x08161133 in ins_writes2 (ins=0x8985c20, t=75) at imcc/instructions.c:138 138 if (ins-opnum == w_special[i + (strchr(types, t) - types)]) (gdb) bt #0 0x08161133 in ins_writes2 (ins=0x8985c20, t=75) at imcc/instructions.c:138 #1 0x08162fd4 in analyse_life_block (interpreter=0x879d008, bb=0x8aeff98, r=0x8983398) at imcc/cfg.c:583 #2 0x08162e3f in analyse_life_symbol (interpreter=0x879d008, unit=0x897ed48, r=0x8983398) at imcc/cfg.c:523 #3 0x08162d86 in life_analysis (interpreter=0x879d008, unit=0x897ed48) at imcc/cfg.c:499 #4 0x08164137 in imc_reg_alloc (interpreter=0x879d008, unit=0x897ed48) at imcc/reg_alloc.c:172 #5 0x0815efdc in imc_compile_unit (interp=0x879d008, unit=0x897ed48) at imcc/imc.c:111 #6 0x0815ef33 in imc_compile_all_units (interp=0x879d008) at imcc/imc.c:68 #7 0x0815edc6 in compile_file (interp=0x879d008, file=0x8b3ff90) at imcc.l:920 #8 0x0816cb8b in imcc_compile_file (interp=0x879d008, s=0x897e4d0 library/SDL/Surface.imc) at imcc/parser_util.c:574 #9 0x081fb259 in pcf_p_It (interpreter=0x879d008, self=0x893b0c8) at src/nci.c:1862 #10 0x081d16a4 in Parrot_Compiler_invoke (interpreter=0x879d008, pmc=0x893b0c8, code_ptr=0x8926e50) at classes/compiler.c:56 #11 0x080a38f8 in Parrot_load_bytecode (interpreter=0x879d008, filename=0x8976de0 library/SDL/Surface.imc) at src/packfile.c:3103 #12 0x080ede8c in Parrot_load_bytecode_sc (cur_opcode=0x8980b70, Hope this helps! -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: No Autoconf, dammit!
Dan, sorry, although I'm a long term perl user I'm not that familiar with the internals of the perl development process that I know all the old stories ;) The plan looks good, but some things are still unclear to me: *) Person building runs platform-specific script Platform specific means also cross-platform specific? For example, I would like to build Perl/Parrot on i686-unknown-linux-gnu and build for arm-softfloat-linux-gnu. So the miniparrot you outlined is used during the build process and must be compiled for i686, whereas the real runtime engine has to be built for arm. Autoconf handles this for example with --host and --build, using CC and CC_FOR_BUILD in the Makefiles. I assume the variant you propose will have similar functionality? *) Configure probes environment How do you probe a cross environment? The build process will in this case run on i686. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Re: [PATCH] dynamic pmc libraries
On Sep-07, Leopold Toetsch wrote: Steve Fink [EMAIL PROTECTED] wrote: This patch introduces something that feels suspiciously like libtool, despite the fact that libtool has never been very kind to me. But for now I am targeting this only at the dynamic PMC generation problem; this solution could be expanded to ease porting of other parts of the build procedure, but I think other people are already working on that. Looks good. I am not committing this patch directly because I know that other people are currently actively working on the dynamic PMC stuff and the build system, and I didn't want to step on anyone's toes. So please give it a try. Ok, it's in. See dynclasses/README for brief usage instructions. I'll probably be committing a couple of dynamic PMCs soon (when I can figure out why they're complaining about not having a destroy() defined, when they don't have the active_destroy flag set.)
