Re: Ord, v0.3, and ideas on chr
On Tue, Oct 23, 2001 at 03:02:09AM -0400, James Mastros wrote: > + /* FIXME: How should I report this error? If someone's failed to implement ord, that's grounds for a segfault. > 74658072 Not portable. :( > output_is( <<'CODE', <
Ord, v0.3, and ideas on chr
Hey all.
This is a much nicer implementation of ord, which does it properly as a
string encoding "method".
The only real uglyness I see is the "I have no mouth and I must scream"
problem. I could take a Perl_Interpreter * parameter, but the only reason I
need it is to fire off exceptions.
WARNING: This only implements the encoding method for strnative. This
isn't really so much a problem, since it's impossible to make strings in
other encodings, and I wanted to get this off to see if the style is good
before I figure out utf8 and utf16 versions of this (utf32 should be
trivial). There is a halfharted attempt to make it die cleanly if this
happens, but there's nothing to guarantee that the compiler will put a NULL
there.
Please tell me any problems you see with this.
I don't see what chr() should look like, though. What's the interface to
multiple encodings on the opcode level? I'd like to just say that chr
always creates a utf32 string. String encodings don't have fixed numbers in
a plugable-encoding world (and I assume that's where we're going), so I
can't take an i|ic parameter for that. String encodings are an enum, so I
can't take the name of the encoding as an s|sc parameter. Ideas?
-=- James Mastros
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.17
diff -u -r1.17 core.ops
--- core.ops2001/10/22 23:34:47 1.17
+++ core.ops2001/10/23 06:47:57
@@ -991,6 +991,18 @@
$1 = string_substr(interpreter, $2, $3, $4, &$1);
}
+
+
+=item B(i, s)
+=item B(i, sc)
+
+Set $1 to the codepoint of the first character in $2.
+
+=cut
+
+AUTO_OP ord(i, s|sc) {
+ $1 = string_ord($2);
+}
=back
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c,v
retrieving revision 1.15
diff -u -r1.15 string.c
--- string.c2001/10/22 23:34:47 1.15
+++ string.c2001/10/23 06:47:57
@@ -168,6 +168,24 @@
return (ENC_VTABLE(s1)->compare)(s1, s2);
}
+/*=for api string string_ord
+ * get the codepoint of the first char of the string.
+ * (FIXME: Document in docs/strings.pod)
+ */
+INTVAL
+string_ord(STRING* s) {
+ /* FIXME: How should I report this error?
+* Should I require an interpreter param just so that I can
+* raise an exception properly?
+*/
+ if (ENC_VTABLE(s)->ord != NULL)
+ return (ENC_VTABLE(s)->ord)(s);
+ else {
+ printf("I have no mouth and I must scream: no ord() for encoding %d!\n",
+s->encoding->which);
+ exit(-1);
+ }
+}
+
/*
* Local variables:
* c-indentation-style: bsd
Index: strnative.c
===
RCS file: /home/perlcvs/parrot/strnative.c,v
retrieving revision 1.19
diff -u -r1.19 strnative.c
--- strnative.c 2001/10/22 23:34:47 1.19
+++ strnative.c 2001/10/23 06:47:57
@@ -105,6 +105,14 @@
return cmp;
}
+/*=for api string_native string_native_ord
+ returns the value of the first byte of the string.
+ */
+INTVAL
+string_native_ord (STRING* s) {
+ return (INTVAL)*(char *)(s->bufstart);
+}
+
/*=for api string_native string_native_vtable
return the vtable for the native string
*/
@@ -118,6 +126,7 @@
string_native_chopn,
string_native_substr,
string_native_compare,
+string_native_ord,
};
return sv;
}
Index: include/parrot/string.h
===
RCS file: /home/perlcvs/parrot/include/parrot/string.h,v
retrieving revision 1.8
diff -u -r1.8 string.h
--- include/parrot/string.h 2001/10/22 23:34:48 1.8
+++ include/parrot/string.h 2001/10/23 06:47:57
@@ -45,6 +45,7 @@
string_iv_to_string_t chopn;/* Remove n characters from the end of a
string */
substr_t substr;/* Substring operation */
two_strings_to_iv_t compare;/* Compare operation */
+string_to_iv_t ord;/* Return the codepoint of the first
+character of the string */
};
struct parrot_string {
@@ -55,7 +56,7 @@
INTVAL strlen;
STRING_VTABLE* encoding;
INTVAL type;
-INTVAL lanugage;
+INTVAL language;
};
@@ -73,6 +74,8 @@
string_substr(struct Parrot_Interp *interpreter, STRING*, INTVAL, INTVAL, STRING**);
INTVAL
string_compare(struct Parrot_Interp *, STRING*, STRING*);
+INTVAL
+string_ord(STRING*);
/* Declarations of other functions */
INTVAL
#! perl -w
use Parrot::Test tests => 1;
output_is( <<'CODE', <
Re: Revamping the build system
On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote: > 1) Build minimal perl 6 with default parameters using platform build tool But "platform build tool" is going to be 'make' - the alternative is that we maintain and ship every flavour of batch or shell script we can think of. I don't think much of that. And if we have to use make, then we're back with the very problems of portably calling compilers and so on that this supposed new build system was meant to avoid. -- Britain has football hooligans, Germany has neo-Nazis, and France has farmers. -The Times
RE: Revamping the build system
>> Ant is different. Instead of a model where it is extended with shell based
>commands, it is
>> extended using Java classes. Instead of writing shell commands, the
>configuration files
>> are XML based calling out a target tree where various tasks get executed.
>Each task is run
>> by an object which implements a particular Task interface.
Ant is really Java centric, as well as somewhat verbose due to it's
XMLness, if i remember correctly from my brief look at it.
I'm going to propose something (once I have time to write it up
properly[1]) that might look something like this:
[pardon the imaginary filenames]
use PerlBuild;
my @o = Obj( "perl.c",
"string.c",
"george.c",
[ OPTIMIZE => 'MAX',
DEFINE => [qw(USEDEVEL THREADS ITHREADS)]]);
my $so = SharedLib( "libperl", @o, [ SOVERSION => "6.0.0" ]);
InstallFile("/usr/lib/$so", $so );
...
Platform specific defaults would be set somewhere in the build
objects, or in platform classes. The values in the DEFINE example
above would be replaced by something based on some arrgument, the user
wouldn't have to edit the PerlBuildFile, of course.
That's the general idea. Things are built out of objects which talk
to each other, to build a full description of what to make. Once you
have that description, the easy part begins (really), which is getting
the proper order and then executing the commands.[2]
If anyone else is interested in working on the front end, (with this
kind of interface or not) I've got a backend pretty much ready to go.[3]
-R [4]
Footnotes:
[1] Unless this gets shot down now :)
[2] This objecty syntax may seem weird to people used to Make, but a
few weeks of research at $day_job found that it was very hard to
cleanly express cross platform things in a clean Make-like syntax.
Make does lots of things really well, but dealing with platform
specific things in a clean manner isn't one of them.
[3] The current state is that it parses make-like files, does some
simple variable substitutions, and thats it. Not based on any
pre-existing perl make-code. Oh yes, on unix, it supports a simple
parallel building. (i.e. -j)
[4] Abusing footnote-mode, and not totally sold that we can't "make
make" work for us. (Or a subset of it.)
PackFile_unpack in pdump.c is missing the first arg
I get a the following error when I do a 'make' with a fresh checkout. pdump.c: In function `main': pdump.c:63: warning: passing arg 1 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 2 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 3 of `PackFile_unpack' makes pointer from integ er without a cast pdump.c:63: too few arguments to function `PackFile_unpack' make: *** [pdump.o] Error 1 Host info. [ /home/peterc/parrot/parrot]uname -a Linux goip 2.2.16 #1 Wed Aug 2 20:22:26 GMT 2000 i686 unknown [ /home/peterc/parrot/parrot]gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) It looks like PackFile_pack wants a 'struct Parrot_Interp *interpreter' that it's not getting from pdump.c Just tryin' to help, Peter C.
Re: [perl6]Re: Resync your CVS...
At 05:00 PM 10/22/2001 -0700, Zach Lipton wrote: >On 10/22/01 3:44 PM, "Dan Sugalski" <[EMAIL PROTECTED]> wrote: > > > On Tue, 23 Oct 2001, Tom Hughes wrote: > > > >> In message <[EMAIL PROTECTED]> > >> Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> > >>> On Mon, 22 Oct 2001, Sam Tregar wrote: > >>> > Fresh checkout won't compile on Redhat Linux 7.1: > >>> > >>> Damn. It compiled cleanly before I checked it in. I'll patch up again and > >>> see what I missed. Probably some odd dependency or timing issue > >>> somewhere. (It's emacs fault! Yeah, that's the ticket! :) > >> > >> I'd already patched it up, so I've just committed my fix... > > > > Thanks. I swear, if I keep this up I'm going to have to yank my own > > checkin privs... :) > > > > Dan > > >This is why we have tinderbox... What, to automagically yank my checkin privs? Keen! :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl6]Re: Resync your CVS...
On 10/22/01 3:44 PM, "Dan Sugalski" <[EMAIL PROTECTED]> wrote: > On Tue, 23 Oct 2001, Tom Hughes wrote: > >> In message <[EMAIL PROTECTED]> >> Dan Sugalski <[EMAIL PROTECTED]> wrote: >> >>> On Mon, 22 Oct 2001, Sam Tregar wrote: >>> Fresh checkout won't compile on Redhat Linux 7.1: >>> >>> Damn. It compiled cleanly before I checked it in. I'll patch up again and >>> see what I missed. Probably some odd dependency or timing issue >>> somewhere. (It's emacs fault! Yeah, that's the ticket! :) >> >> I'd already patched it up, so I've just committed my fix... > > Thanks. I swear, if I keep this up I'm going to have to yank my own > checkin privs... :) > > Dan > This is why we have tinderbox... Zach
Re: Resync your CVS...
On Tue, 23 Oct 2001, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > On Mon, 22 Oct 2001, Sam Tregar wrote: > > > > > Fresh checkout won't compile on Redhat Linux 7.1: > > > > Damn. It compiled cleanly before I checked it in. I'll patch up again and > > see what I missed. Probably some odd dependency or timing issue > > somewhere. (It's emacs fault! Yeah, that's the ticket! :) > > I'd already patched it up, so I've just committed my fix... Thanks. I swear, if I keep this up I'm going to have to yank my own checkin privs... :) Dan
Re: Resync your CVS...
In message <[EMAIL PROTECTED]> Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Mon, 22 Oct 2001, Sam Tregar wrote: > > > Fresh checkout won't compile on Redhat Linux 7.1: > > Damn. It compiled cleanly before I checked it in. I'll patch up again and > see what I missed. Probably some odd dependency or timing issue > somewhere. (It's emacs fault! Yeah, that's the ticket! :) I'd already patched it up, so I've just committed my fix... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Resync your CVS...
On Mon, 22 Oct 2001, Sam Tregar wrote: > Fresh checkout won't compile on Redhat Linux 7.1: Damn. It compiled cleanly before I checked it in. I'll patch up again and see what I missed. Probably some odd dependency or timing issue somewhere. (It's emacs fault! Yeah, that's the ticket! :) Dan
Re: Resync your CVS...
Fresh checkout won't compile on Redhat Linux 7.1: string.c: In function `string_compare': string.c:161: warning: passing arg 1 of pointer to function from incompatible pointer type string.c:161: too few arguments to function string.c:164: warning: passing arg 1 of pointer to function from incompatible pointer type string.c:164: too few arguments to function make: *** [string.o] Error 1 -sam
Schedule of things to come
Okay, here's a tentative list 'o stuff that is in the works for Parrot 0.03 (and possibly 0.04): *) Scalar PMCs *) Simple I/O *) Multiple interpreter & thread creation *) A simple arena allocation system *) Garbage collection So in the next week or three we should be able to read and write files (gasp!), jam data into and out of real variables, and chew up great gobs of memory while we do it. :) A week or three after that we should stop chewing up the memory, and that'll be A Keen Thing. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Resync your CVS...
I just finished the skeleton of the PMC/string (and soon bigint/bigfloat) allocation system and checked it in. This meant a lot of changes to stuff all over the place. (As a side-effect, we lost the standalone string testing) I think we're now in a position to start dealing with our own memory allocator and PMCs, and I'll start in on that soonish. Please note that until we actually *get* an arena allocation system with GC, parrot will leak. (A lot... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Memory management!
Okay folks, a quick heads up. *Any* function in the parrot core that allocates a parrot-managed structure (such as a string or PMC) *must* have a valid interpreter structure hanging around. I'm in the middle of rejigging everything so we can start allocating PMCs & string structures, and properly GC things. It's just *loads* of fun. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Languages in the core source tree?
On Sun, Oct 21, 2001 at 12:45:14PM -0400, Dan Sugalski wrote: > Okay, we've now got minimal: > > *) Parrot assembly > *) Perl > *) Python > *) JVM > *) Scheme > *) Jako > *) Ruby? (Do we? I can't remember for sure) > > support for Parrot. This is a cool thing, but it brings up the questions: > > 1) Do we put them all in the parrot CVS tree Yes, most definitely yes. > 2) Do we require them to meet the same levels of quality as the core > interpreter? Sort of. Those little languages represent the closest thing to a practical application we have for Parrot at the moment. More importantly, you don't have to be an assembly programmer to use them. As each new feature of Parrot is added, the little languages quickly make use of them. If they're widely distributed (ie. with Parrot) people can quickly make use of the little languages, seeing just how much they can get away with in such a small space. So Parrot and the interpreters will grow in parallel. This means more people beating on Parrot sooner and with more and more varied sticks. However, the author(s) of each individual interpreter should be responsible for their own language. Basically, a mini-pumpinking. This means they *do* have to stand up to the same standards as Parrot because, essentially, they're acting as very practical test cases. If the mini-Scheme interpreter works on Linux but not on VMS, then it's likely exposed a bug inside Parrot. Whether or not a release should be held up because a given language is broken is up to Simon. So yes, put them in the default Parrot tree. Later on when they've matured they can branch off into seperate projects and go their own way. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Nature is pissed. http://www.unamerican.com/
Re: [PATCH] Register Window Base Macros
At 06:37 PM 10/19/2001 -0400, Jason Gloudon wrote: >Here is the patch (again) to use the appropriate bitmask determined by >Configure for the different register chunks. Applied. Thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Languages in the core source tree?
At 07:15 AM 10/22/2001 -0700, Wizard wrote: > > 1) Do we put them all in the parrot CVS tree > >I think it would be good for the languages to be in tree, but I would like >to have it under a different mechanism for cvs checkout. In other words, the >default cvs checkout of parrot does NOT check out the languages tree, but a >separate checkout is required for the languages. I'll ask Ask and see what we can do for that. > > 2) Do we require them to meet the same levels of quality as the core > > interpreter? >At some point they should need to meet same criteria as the parrot. Right >now, I think the priority is parrot and should remain such. I think the >language implementations are just an experiment, and should not be held to >the same criteria (that should be stated somewhere). However, at some >predetermined point, some resources should be redirected to testing and >refining all of the subtrees (including docs). Yeah, I think you're right here. It'll be one thing when we have fully-working ports of other languages to Parrot but for now most of these should be considered interesting tangents. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Shared objects and handoffs (was Re: Parrot's threading model)
On Tue, 16 Oct 2001, Dan Sugalski wrote: > An interpreter can get access to a shared PMC in another interpreter > only at interpreter clone time, or if explicitly passed in via an (as > yet undetermined) handoff method. One thing I'd really like to be able to do in Parrot/Perl 6 is to be able to take groups of objects and pass them between threads (but not necessarily have them be shared) instead of having several individual mutex-protected objects. Maybe an extension on the compartments idea: Allow a parrot program to declare a new PMC container. Then when the program creates an object you can choose which compartment to stick it into. Then use the undetermined handoff method to move the whole compartment between threads (see below for hadnoff method idea). An access to a compartment that is not held by the current thread would be an error, as would be making references between compartments. Then all you need to implement this is one mutex per compartment that is held by whichever thread "owns" that compartment. You don't even ever have to unlock it if the thread never gives up ownership of the compartment. This would be great for daemons that need to be state-aware since they could store state information in a compartment and pass that compartment to whichever thread is handling it. Also, here's a handoff method idea: Make a (base?) type for object queues. These queues would be shared according to the rules you stated above. Define an enqueue and dequeue method that can move object compartments. Anyway, that's my idea. Now what the Perl 6 semantics would be for all this stuff I have no idea. :-) - D <[EMAIL PROTECTED]>
RE: Languages in the core source tree?
> 1) Do we put them all in the parrot CVS tree I think it would be good for the languages to be in tree, but I would like to have it under a different mechanism for cvs checkout. In other words, the default cvs checkout of parrot does NOT check out the languages tree, but a separate checkout is required for the languages. > 2) Do we require them to meet the same levels of quality as the core > interpreter? At some point they should need to meet same criteria as the parrot. Right now, I think the priority is parrot and should remain such. I think the language implementations are just an experiment, and should not be held to the same criteria (that should be stated somewhere). However, at some predetermined point, some resources should be redirected to testing and refining all of the subtrees (including docs). Grant M.
RE: Revamping the build system
Hi, > > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > There's nothing really past what make does. The reason for having our own is: > *) Make isn't everywhere (like windows) > *) Make on various platforms has different syntax (VMS, Windows, and Unix > are all different) > *) Not speaking for anyone else, but I find make's gotten rather creaky > a round the edges--after 20+ years presumably we can make things a bit better > *) Having the full power of perl in the build tool should give us a big > boost in utility. (Consider the difference between C macros and Perl source > filters) > *) It'll be really unfamiliar to everyone, which'll stop folks from falling > into old, non-portable habits. If there is going to be a new build tool for perl6, i would suggest using something similar to Ant (http://jakarta.apache.org/ant/) Ant is not suitable for parrot of course (it requires Java) but its design is quite good imho. >From its webpage: > Ant is different. Instead of a model where it is extended with shell based commands, it is > extended using Java classes. Instead of writing shell commands, the configuration files > are XML based calling out a target tree where various tasks get executed. Each task is run > by an object which implements a particular Task interface. It tries to avoid executing shell commands (which is good if you want to be portable to places like Windows) and instead it comes with a predefined set of tasks (remove files, compile, etc..). that can be extended programming your own Task classes. This article: http://www.onjava.com/pub/a/onjava/2001/02/22/open_source.html does a very good job at giving you a feeling of how it works. In my limited expierence, this is something very similar to what we would need for parrot/perl6. Just my half a cent, Angel Faus [EMAIL PROTECTED] vLex.com
