[PATCH] usleep, sleep(num)
Hi,
I was inspired by Time::HiRes to create 2 new simple ops for parrot:
usleep(int), and sleep(num), to behave a bit more like the float version
of the time op.
I've attached a patch made off of the 0.0.6 source tree that works *for
Linux* as a proof of concept to try and spark some discussion.
Regards,
+--
Steve Purkis <[EMAIL PROTECTED]>
diff -rc parrot_0.0.6/ChangeLog parrot_0.0.6-usleep/ChangeLog
*** parrot_0.0.6/ChangeLog Tue Mar 19 23:03:05 2002
--- parrot_0.0.6-usleep/ChangeLog Sun Jul 14 02:10:42 2002
***
*** 1,3
--- 1,6
+ 2002-07-14 02:05 spurkis
+ * added usleep(INT) and sleep(NUM) for linux
+
2002-03-19 22:54 nicholas
* docs/running.pod: Patch from Simon Glover <[EMAIL PROTECTED]>:
diff -rc parrot_0.0.6/config/gen/platform/generic.c
parrot_0.0.6-usleep/config/gen/platform/generic.c
*** parrot_0.0.6/config/gen/platform/generic.c Fri May 24 07:32:06 2002
--- parrot_0.0.6-usleep/config/gen/platform/generic.c Sat Jul 13 23:48:53 2002
***
*** 47,52
--- 47,63
/*
+ ** Parrot_usleep()
+ */
+
+ void
+ Parrot_usleep(unsigned int microseconds)
+ {
+ usleep(microseconds);
+ }
+
+
+ /*
** Parrot_setenv()
*/
diff -rc parrot_0.0.6/config/gen/platform/generic.h
parrot_0.0.6-usleep/config/gen/platform/generic.h
*** parrot_0.0.6/config/gen/platform/generic.h Fri May 24 07:32:06 2002
--- parrot_0.0.6-usleep/config/gen/platform/generic.h Sat Jul 13 23:48:53 2002
***
*** 17,22
--- 17,23
*/
void Parrot_sleep(unsigned int seconds);
+ void Parrot_usleep(unsigned int microseconds);
INTVAL Parrot_intval_time(void);
FLOATVAL Parrot_floatval_time(void);
void Parrot_setenv(const char *name, const char *value);
diff -rc parrot_0.0.6/core.ops parrot_0.0.6-usleep/core.ops
*** parrot_0.0.6/core.ops Wed Jun 5 02:56:08 2002
--- parrot_0.0.6-usleep/core.opsSun Jul 14 01:58:19 2002
***
*** 3313,3328
Sleep for $1 seconds
=cut
inline op sleep(in INT) {
if ($1 < 0) {
! internal_exception(NEG_SLEEP, "Cannot go back in time");
}
Parrot_sleep((UINTVAL)$1);
goto NEXT();
}
###
--- 3313,3352
Sleep for $1 seconds
+ =item B(in NUM)
+
+ Sleep for $1 fractional seconds
+
+ =item B(in INT)
+
+ Sleep for $1 microseconds
+
=cut
inline op sleep(in INT) {
if ($1 < 0) {
! internal_exception(NEG_SLEEP, "Cannot sleep back in time");
}
Parrot_sleep((UINTVAL)$1);
goto NEXT();
}
+ inline op sleep(in NUM) {
+ if ((FLOATVAL) $1 < (FLOATVAL) 0.0) {
+ internal_exception(NEG_SLEEP, "Cannot sleep back in time");
+ }
+ Parrot_usleep((UINTVAL) ($1 * (FLOATVAL) 100.0));
+ goto NEXT();
+ }
+
+ inline op usleep(in INT) {
+ if ($1 < 0) {
+ internal_exception(NEG_SLEEP, "Cannot sleep back in time");
+ }
+ Parrot_usleep((UINTVAL)$1);
+ goto NEXT();
+ }
+
###
Only in parrot_0.0.6-usleep/examples/assembly: sleep.pasm
diff -rc parrot_0.0.6/platforms/generic.c parrot_0.0.6-usleep/platforms/generic.c
*** parrot_0.0.6/platforms/generic.cSun Jun 2 05:10:13 2002
--- parrot_0.0.6-usleep/platforms/generic.c Sat Jul 13 23:48:53 2002
***
*** 45,50
--- 45,57
}
+ void
+ Parrot_usleep(unsigned int microseconds)
+ {
+ usleep(seconds);
+ }
+
+
/*
** Parrot_setenv()
*/
diff -rc parrot_0.0.6/platforms/generic.h parrot_0.0.6-usleep/platforms/generic.h
*** parrot_0.0.6/platforms/generic.hFri Mar 8 04:37:25 2002
--- parrot_0.0.6-usleep/platforms/generic.h Sat Jul 13 23:48:53 2002
***
*** 17,22
--- 17,23
*/
void Parrot_sleep(unsigned int seconds);
+ void Parrot_usleep(unsigned int microseconds);
INTVAL Parrot_intval_time(void);
FLOATVAL Parrot_floatval_time(void);
void Parrot_setenv(const char *name, const char *value);
diff -rc parrot_0.0.6/t/op/time.t parrot_0.0.6-usleep/t/op/time.t
*** parrot_0.0.6/t/op/time.tSat Jun 1 04:54:19 2002
--- parrot_0.0.6-usleep/t/op/time.t Sun Jul 14 01:58:38 2002
***
*** 1,6
#! perl -w
! use Parrot::Test tests => 4;
output_is(<<'CODE', <<'OUTPUT', "time_i");
timeI0
--- 1,6
#! perl -w
! use Parrot::Test tests => 8;
output_is(<<'CODE', <<'OUTPUT', "time_i");
timeI0
***
*** 65,73
done
OUTPUT
! output_is(<
PARROT QUESTIONS: Use the source, Luke
I'm trying to pay attention to the difficulties I have understanding parrot so
I can give some decent n00b feedback before I know the code like the back of
my hand.
First, test_main.c is a totally non-obvious location for parrot.exe's main().
I dismissed it out of hand when I did grep ^main. I only believed it was real
when I looked at the linker arguments. Is there a reason for the test_
prefix? It's really misleading if you're actually using it.
I'm also a little disturbed by *everything* having Parrot_ in front of it.
Namespace friendliness is nice, but having the internal functions with the
same prefix as the embed.c functions is unkind. I'd like to see _Parrot_ or
Parrot__ for the internal functions (hell, just the opcodes) and Parrot_
reserved for the visible API. _Parrot_ would be better, since source grepping
for ^Parrot wouldn't list them. Grepping for ^Parrot_new (the first function
called in main(), and the first function anyone reading from the top would
search for) was painful.
There's no pointers between source and documentation. embed.c is a direct
implementation of embed.pod, but neither mentions the other. Any place
documentation and implementation exist, they should point to each other.
Until the documentation is good enough that you don't need to look at the
source to see how to use it, the documentation needs to give the location of
the source. :)
test_main.c and embed.c have no comments. They are the starting-point of the
parrot interpreter but there's no guidance as to where to go from there. In
the case of embed.c, I would definitely like to see each function specify
what files their implementation can be found. A gushing amount of inline
documentation would be good too, but even as little as this:
struct Parrot_Interp *
Parrot_new(void)
{
if (!world_inited) {
world_inited = 1;
init_world(); /* global_setup.c */
}
return make_interpreter(NO_FLAGS); /* interpreter.c */
}
I had to cut&paste&grep the source countless times to find anything.
A pointer from test_main.c to embed.c and embed.pod would've been helpful as
well.
What the heck is parrot.c doing empty? I expected it to have... something. I
don't know. Being empty is Wrong. I would've expected the functions which are
actually in embed.c to be in there ala. perl5's perl.c at least. If it's not
going to have source, it definitely needs a comment saying "this is not the
file you are looking for, see test_main.c and embed.c".
I think that's all for today,
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Use the source, Luke
Hrm, I had intended to put my questions at the end. I hit Send early. Questions: 1. Why is test_main.c not named main.c? 2. What does having a Parrot_ prefix signify, considering both the opcodes and the embed api use it? It's hard to distinguish between them. 3. What source files implement what docs? 4. Where can I find out what embed.c is doing? 5. Why is parrot.c empty? Ashley Winters
Re: Parrot contribution - #parrot stream parser.
On Sat, Jul 13, 2002 at 05:00:42PM -0400, Jim Cromie said: > can we could invent a super-lightweight markup language > that #parrot-eers would type into the stream to put meta-info into it ? Might it be worth using something like http://usefulinc.com/chump/ (as seen in use at http://pants.heddley.com/index.html) ? It's written in Python but there's a Perl replacement (to stem the PR nightmare), which is 99% complete, lurking around which was written by #perl denizen blech. -- : it was a good game - the rules were simple
RE: PARROT QUESTIONS: Use the source, Luke
Ashley Winters:
# 1. Why is test_main.c not named main.c?
Because parrot.exe was originally named test_prog.exe, so at the time it
made sense for it to be called test_main.c.
# 2. What does having a Parrot_ prefix signify, considering
# both the opcodes and
# the embed api use it? It's hard to distinguish between them.
It signifies one of the following:
-This function is externally visible.
-This function belongs to Parrot at large, and not any particular
subsystem (e.g. Parrot_sprintf and friends).
-This function has an identical name to a C library function because it
emulates it for certain platforms (e.g. Parrot_dlopen (?)).
-This function is autogenerated, so we're going to be paranoid about
naming conflicts.
For functions in the last category, I'd suggest we use
subsystem-specific names, e.g. Op_ for the opcodes.
# 3. What source files implement what docs?
It's a mess.
# 4. Where can I find out what embed.c is doing?
Try looking in my brain. :^) I'll see what I can do about documenting
it more thoroughly.
# 5. Why is parrot.c empty?
It was originally supposed to serve the role of test_main.c, but that
didn't ever happen for some reason. Ask Simon if you really want to
know.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
PARROT QUESTIONS: Keyed access
I've been trying to make sense of the current status of keyed access at all levels, from the assembler through the ops to the vtables and it has to be said that the harder I look the more confused I seem to become... It all seems to be a bit of a mess at the moment, and I'd like to have a go at cleaning it up but first of all I need to work out how it is all supposed to work. It is clear that the encoding currently used by the assembler does not match that specified by PDD 8 as the following examples show: Instruction PDD 8 Encoding Actual Current Encoding set P1["hi"], 1234 set_p_kc_ic set_keyed_p_sc_ic set P1[S1], 1234set_p_r_ic set_keyed_p_s_ic set P1[1], 1234 set_p_kc_ic set_keyed_integer_p_ic_ic set P1[I1], 1234set_p_r_ic set_keyed_integer_p_k_ic set P1[S1], P2[S2] set_p_r_p_r set_keyed_p_s_p_s set P1[I1], P2[S2] set_p_kc_p_rset_keyed_keyed_integer_p_i_p_s Obviously this is a complete nonsense. To be honest I suspect that both encodings have problems, The PDD 8 encoding uses kc and r (why not kc and k?) to encode the keys regardless of their type so the op has no way of knowing what sort of argument it is dealing with. The currently implemented system distinguishes the operand types OK but trys to differentiate between ops with an integer key and those with other types of keys which all falls apart when you have a combination of integer and non-integer keys in the same instruction. Once we get to multi-component keys things just get even worse. If we believe PDD 8 then the syntax should be: set P1[I1;I2], I3 But what is currently implemented is this: set P1[k;I1;I2], I3 In addition it appears that the current implementation would turn that instrucion into this encoding: set_keyed_integer_p_k_k_i Where each component of the key becomes a separate argument, thereby requiring an infinite number of ops to cope with an infinite number of possible key components. There is a suggestion in PDD 8 that this should be encoded as this: set_p_kc_i With the key constant actually referring to an entry in the constant table that encodes the key. Moving on the from the assembler I'm not sure how the recent addition of the _keyed_int vtable methods interacts with all this - they appear to be at odds with PDD 8 anyway which appears to want to avoid the kind of vtable explosion that they promote. Anyhow, that's probably enough for now... If anybody can elighten me about how all this is supposed to work then I'll try and knock it all into shape, starting with making sure that PDD 8 is accurate. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
[perl #813] [PATCH] update IMCC to use keyed ops
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #813]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=813 >
- updates IMCC to use keyed ops for spilling
- fixes a spelling error (n_spill vs. n_spilled)
- removes parameter from simplify(), having it use the global
interference_graph instead. NOTE: this is the same as the change in
ticket 770.
/s
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3816/3537/e5c315/imcc.patch
? imcc
? imcparser.c
? imcparser.h
? imclexer.c
? blah
? a.pbc
? foo.imc
? a.pasm
? bar.imc
? imcparser.output
? foo.p6
? imcc2.patch
? imcc.patch
Index: imc.c
===
RCS file: /cvs/public/parrot/languages/imcc/imc.c,v
retrieving revision 1.9
diff -u -r1.9 imc.c
--- imc.c 4 Jul 2002 02:58:30 - 1.9
+++ imc.c 14 Jul 2002 15:59:04 -
@@ -180,9 +180,11 @@
*
*/
-int simplify (SymReg **g){
+int simplify (){
int changes = 0;
int x;
+
+SymReg ** g = interference_graph;
for(x = 0; x < n_symbols; x++) {
if (g[x]->simplified) {
@@ -406,7 +408,7 @@
if (needs_fetch && !after_spilled) {
- sprintf(buf, "set %s, P31, %d #FETCH", "%s", n_spilled); /*ouch*/
+ sprintf(buf, "set %s, P31[%d] #FETCH", "%s", n_spilled); /*ouch*/
new_instructions[j++] = mk_instruction(
buf, new_symbol, NULL, NULL, NULL, IF_r1_write);
@@ -415,7 +417,7 @@
if (!needs_spilling && after_needs_store) {
- sprintf(buf, "set P31, %d, %s #STORE", n_spilled, "%s"); /*ouch, ouch*/
+ sprintf(buf, "set P31[%d], %s #STORE", n_spilled, "%s"); /*ouch, ouch*/
new_instructions[j++] = mk_instruction(
buf, new_symbol, NULL, NULL, NULL, IF_r1_write);
Index: imc.h
===
RCS file: /cvs/public/parrot/languages/imcc/imc.h,v
retrieving revision 1.8
diff -u -r1.8 imc.h
--- imc.h 4 Jul 2002 02:58:30 - 1.8
+++ imc.h 14 Jul 2002 15:59:04 -
@@ -36,7 +36,7 @@
char *str_cat(const char *, const char *);
int IMCC_DEBUG;
-int n_spill;
+int n_spilled;
SymReg** interference_graph;
Index: instructions.c
===
RCS file: /cvs/public/parrot/languages/imcc/instructions.c,v
retrieving revision 1.1
diff -u -r1.1 instructions.c
--- instructions.c 4 Jul 2002 02:58:30 - 1.1
+++ instructions.c 14 Jul 2002 15:59:04 -
@@ -82,7 +82,7 @@
void emit_flush() {
int i;
-if (n_spill > 0) {
+if (n_spilled > 0) {
printf("new P31, .PerlArray\n");
}
Re: Parrot contribution - #parrot stream parser.
At 8:06 AM +0100 7/14/02, Leon Brocard wrote: >Jim Cromie sent the following bits through the ether: > >> can we could invent a super-lightweight markup language >> that #parrot-eers would type into the stream to put meta-info into it ? > >OK, I'll finally join this discussion. Yes, IRC is handy for realtime >questions like (just an example as it happened last night): Yup. That's why I try and be on #parrot with some regularity. (The schedule's 1-5 EST Wednesday, IIRC) While it's no substitute for e-mail, and not as good a realtime communication method as face to face communication, it's better than no realtime communication at all. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot contribution - #parrot stream parser.
At 10:09 AM +0100 7/14/02, Simon Wistow wrote: >On Sat, Jul 13, 2002 at 05:00:42PM -0400, Jim Cromie said: >> can we could invent a super-lightweight markup language >> that #parrot-eers would type into the stream to put meta-info into it ? > >Might it be worth using something like > >http://usefulinc.com/chump/ > >(as seen in use at http://pants.heddley.com/index.html) >? > >It's written in Python but there's a Perl replacement (to stem the PR >nightmare), which is 99% complete, lurking around which was written by >#perl denizen blech. Could we get something like this lurking on #parrot? I don't care if it's in perl or python (or ruby, or scheme, or...) just as long as its hanging about and useful. At some point I suppose I'll have to try my hand at an IRC bot of some sort. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] usleep, sleep(num)
At 9:36 PM -0500 7/13/02, Steve Purkis wrote: >Hi, > >I was inspired by Time::HiRes to create 2 new simple ops for parrot: >usleep(int), and sleep(num), to behave a bit more like the float version >of the time op. > >I've attached a patch made off of the 0.0.6 source tree that works *for >Linux* as a proof of concept to try and spark some discussion. I like this, and want it to go in--I think it's a capability we should provide. However... Until it works on Win32 we need to wait. Can someone running a Win box grab this and get a win version going? When we have that, this can get committed. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] rx.dev
Hello everyone,
I've only been involved with parrot since last week,
but I've been learning quickly from all the
documentation. With the recent activity about lack of
documentation, I thought I'd try to help out as best I
could. I've attached a file for an rx.dev candidate.
Some parts may be wrong, and at some points I even ask
questions, but there isn't much to rx.[ch], so overall
it should be a decent rough draft. Below are my
questions, copied right out of the attached document:
1) The rx_is_number_character function breaks the
abstraction and uses the following expression to test
the argument:
if (ch >= '0' && ch <= '9')
It explains that it is "faster to do
less-than/greater-than"
My question is: Doesn't this restrict the ability for
adding different character encodings and languge
support? What about languages that don't use arabic
numerals?
2) In the rxinfo struct:
opcode_t *substfunc;
My first guess was that that is a pointer to the first
opcode the regex uses, but then I got confused by the
name 'substfunc.' So basically ... what is it used
for?
Thanks!
Stephen Rawls
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
rx.c / rx.h
rx.c and rx.h set up functions to be used by the regular expression engine. They also
define internal helper functions that add a layer of abstraction to rx_is_x family of
functions. Please also see rx.ops, rxstacks.c, and rxstacks.h.
rx_alloacate_info
Initializes a regular expression object and allocates the memory.
rx_is_word_character
rx_is_number_character
rx_is_whitespace_character
rx_is_newline
These functions check if the character passed as an argument is a word_character,
number_character, whitespace_character, or a newline, respectively. They each use
bitmaps to add a layer of abstraction. All a bitmap is in this case is a collection
of characters. Instead of manually looking at a string these functions create a
bitmap of allowable characters (using predefined constants, like RX_WORDCHARS), and
call the function C, which checks if the supplied character is in the
bitmap.
NOTE: The rx_is_number_character function breaks the abstraction and uses the
following expression to test the argument:
if (ch >= '0' && ch <= '9')
It explains that it is "faster to do less-than/greater-than"
My question is: Doesn't this restrict the ability for adding different character
encodings and languge support? What about languages that don't use arabic numerals?
bitmap_make
This function makes a bitmap from its argument (of type STRING*). Let us examine two
cases, one is a character is one byte, the other is it is more.
One byte
First of all, (255 >> 3) = 31. The code uses this for a little efficiency in
storage/speed. An internal array is created with 32 elements (each byte-sized). If
you take the input character and right shift it by 3, you will get a number between 0
and 31, it just so happens that exactly 8 numbers between 0 and 255 map to the same
number between 0 and 31. Then, each element in this array is a bitfield, with a 1 or
0 in each bit to indicate if a particular character is in the bitmap or not. So, (ch
>> 3) takes us to the right element in the array for ch, but how do we get to the
right element in the bitfield? The code is 1 << (ch & 7). This will give us a unique
power of two for each character that maps to that particular bitfield in the array.
More than one byte
Here each character is appended to the internal string bigchars (of type STRING*).
bitmap_make_cstr
This is the same thing at bitmap_make, except it is called with a const char*
argument. Because of this, it knows there will be no bigchars, so it is only
concerned with byte-sized characters.
bitmap_add
This function takes a bitmap and a single character, and adds that character to the
bitmap. The code for adding the character is the same as in bitmap_make.
bitmap_match
This functions takes a bitmap and a single character, and checks to see if that
character is in the bitmap. If the character is more than one byte, then the function
searches the bigchars string linearly (one by one). If it is a byte-sized character
than it checks the appropriate bitfield, as specified in bitmap_make.
bitmap_destroy
This deallocates the memory for the bitmap.
rx.h
Here is the definition for rxinfo (all comments are mine)
typedef struct rxinfo {
STRING *string; //This is the string the regex tests to see if it matches or
not
//(At least that is what I guess, I couldn't find that
anywhere)
INTVAL index; //This is the current spot in string we are checking
INTVAL startindex; //This is where the regex started checking
INTVAL success; //This is just a flag to see if the regex matched or not
rxflags flags; //This is a set of flags to see what modifiers were used in
the regex
UINTVAL minlength; //The min
Re: PARROT QUESTIONS: Keyed access
At 03:54 PM 7/14/2002 +0100, Tom Hughes wrote: >I've been trying to make sense of the current status of keyed access >at all levels, from the assembler through the ops to the vtables and >it has to be said that the harder I look the more confused I seem to >become... I think we all have... FWIW, I have a large patch from Sean O'Rourke in response to my request for someone to cleanup the set/set_keyed stuff. I'll commit it later today, it does clean it up a bit, and removes some of the older versions of set (3 arg). It at least reduces the noise. -Melvin
Re: Parrot contribution - #parrot stream parser.
Simon Wistow said: > Might it be worth using something like > > http://usefulinc.com/chump/ > > (as seen in use at http://pants.heddley.com/index.html) > ? > > It's written in Python but there's a Perl replacement (to stem the PR > nightmare), which is 99% complete, lurking around which was written by > #perl denizen blech. The guys from London.pm wrote Scribot (http://www.scribot.com/) wich could be more useful...
Re: PARROT QUESTIONS: Keyed access
In message <[EMAIL PROTECTED]> Melvin Smith <[EMAIL PROTECTED]> wrote: > At 03:54 PM 7/14/2002 +0100, Tom Hughes wrote: > >I've been trying to make sense of the current status of keyed access > >at all levels, from the assembler through the ops to the vtables and > >it has to be said that the harder I look the more confused I seem to > >become... > > FWIW, I have a large patch from Sean O'Rourke in response to my > request for someone to cleanup the set/set_keyed stuff. I'll commit > it later today, it does clean it up a bit, and removes some of the > older versions of set (3 arg). It at least reduces the noise. I was going to some work on that request, but I reached the point where I decided there was no point trying to do anything until it was clear what the target was that I was trying to reach... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
RE: [PATCH] rx.dev
Stephen Rawls:
# I've only been involved with parrot since last week,
# but I've been learning quickly from all the
# documentation. With the recent activity about lack of
# documentation, I thought I'd try to help out as best I could.
# I've attached a file for an rx.dev candidate.
# Some parts may be wrong, and at some points I even ask
# questions, but there isn't much to rx.[ch], so overall it
# should be a decent rough draft. Below are my questions,
# copied right out of the attached document:
#
# 1) The rx_is_number_character function breaks the
# abstraction and uses the following expression to test
# the argument:
# if (ch >= '0' && ch <= '9')
# It explains that it is "faster to do
# less-than/greater-than"
# My question is: Doesn't this restrict the ability for
# adding different character encodings and languge
# support? What about languages that don't use arabic
# numerals?
It's a speed hack. I'm well aware that it won't work on some languages,
but I figured we can always change it later.
# 2) In the rxinfo struct:
# opcode_t *substfunc;
#
# My first guess was that that is a pointer to the first
# opcode the regex uses, but then I got confused by the
# name 'substfunc.' So basically ... what is it used
# for?
It's unused; originally I was planning to have the regex engine handle
substitutions (and you would pass in a label to call to get the
replacement string), but I changed my mind. Apparently that never
disappeared.
Overall, well done on the file--I think you explained bitmaps better
than I could have. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
[perl #814] [PATCH] fix PMC type morphing
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #814]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=814 >
PerlString sets the PMC_is_buffer_ptr_FLAG flag in pmc->flags, but none of
the other Perl types do. The GC uses this flag to tell whether or not to
look for a buffer pointer in the PMC. Certain operations currently change
a PMC from one type to another simply by updating its vtable pointer.
Since they don't update the flag, this causes problems in collection. The
problem I saw was a buffer not being marked, but the opposite could
happen as well -- interpreting a former-String PMC as a buffer pointer
could cause a seg fault or memory leak.
So we need to set the flag if we're turning something into a PerlString,
and clear it if we're turning something that is a string into something
else. This patch adds a macro to do these things, in a file
include/parrot/perltypes.h.
/s
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3818/3540/dd0935/pmcs.patch
-- attachment 2 --
url: http://bugs6.perl.org/rt2/attach/3818/3541/0c7fbb/perltypes.h
Index: classes/perlint.pmc
===
RCS file: /cvs/public/parrot/classes/perlint.pmc,v
retrieving revision 1.24
diff -u -r1.24 perlint.pmc
--- classes/perlint.pmc 12 Jun 2002 22:12:18 - 1.24
+++ classes/perlint.pmc 14 Jul 2002 19:47:45 -
@@ -11,6 +11,7 @@
*/
#include "parrot/parrot.h"
+#include "parrot/perltypes.h"
pmclass PerlInt {
@@ -80,12 +81,12 @@
}
void set_number (PMC * value) {
-SELF->vtable = &(Parrot_base_vtables[enum_class_PerlNum]);
+ CHANGE_TYPE(pmc, PerlNum);
SELF->cache.num_val = value->cache.num_val;
}
void set_number_native (FLOATVAL value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlNum]);
+ CHANGE_TYPE(pmc, PerlNum);
SELF->cache.num_val = value;
}
@@ -94,7 +95,7 @@
}
void set_number_same (PMC * value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlNum]);
+ CHANGE_TYPE(pmc, PerlNum);
SELF->cache.num_val = (FLOATVAL)value->cache.int_val;
}
@@ -125,33 +126,33 @@
}
void set_string (PMC* value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlString]);
+ CHANGE_TYPE(pmc, PerlString);
SELF->data = value->data;
}
void set_string_native (STRING* value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlString]);
+ CHANGE_TYPE(pmc, PerlString);
SELF->data = value;
}
void set_string_unicode (STRING* value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlString]);
+ CHANGE_TYPE(pmc, PerlString);
SELF->data = value;
}
void set_string_other (STRING* value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlString]);
+ CHANGE_TYPE(pmc, PerlString);
SELF->data = value;
}
void set_string_same (PMC* value) {
- SELF->vtable = &(Parrot_base_vtables[enum_class_PerlString]);
+ CHANGE_TYPE(pmc, PerlString);
SELF->data = value->data;
}
void add (PMC* value, PMC* dest) {
if(value->vtable == &Parrot_base_vtables[enum_class_PerlNum]) {
- dest->vtable = &Parrot_base_vtables[enum_class_PerlNum];
+ CHANGE_TYPE(dest, PerlNum);
dest->vtable->set_number_native(INTERP, dest,
SELF->cache.int_val +
value->vtable->get_number(INTERP, value)
@@ -161,14 +162,14 @@
FLOATVAL f = value->vtable->get_number(INTERP, value);
INTVAL i = value->vtable->get_integer(INTERP, value);
if(f != i) {
- dest->vtable = &Parrot_base_vtables[enum_class_PerlNum];
+ CHANGE_TYPE(dest, PerlNum);
dest->vtable->set_number_native(INTERP, dest,
SELF->cache.int_val +
value->vtable->get_number(INTERP, value)
);
}
else {
- dest->vtable = &Parrot_base_vtables[enum_class_PerlInt];
+ CHANGE_TYPE(dest, PerlInt);
dest->vtable->set_integer_native(INTERP, dest,
SELF->cache.int_val +
value->vtable->get_integer(INTERP, value)
@@ -176,7 +177,7 @@
}
}
else {
- dest->vtable = &Parrot_base_vtables[enum_class_PerlInt];
+ CHANGE_TYPE(dest, PerlInt);
dest->vtable->set_integer_native(INTERP, dest,
SELF->cache.int_val +
value->vtable->get_integer(INTERP, value)
@@ -197,7 +198,7 @@
voi
Re: Parrot contribution - #parrot stream parser.
On Sun, Jul 14, 2002 at 08:54:30PM +0300, Iacob Alin said: > The guys from London.pm wrote Scribot (http://www.scribot.com/) wich could > be more useful... Yeah I know - Leon wrote the original and then I patched it :) http://thegestalt.org/simon/perl/scribot2.html Leon's done another revision recently but I can't remember where he stashed the source.
Re: Parrot contribution - #parrot stream parser.
Simon Wistow said: > Might it be worth using something like > > http://usefulinc.com/chump/ > > (as seen in use at http://pants.heddley.com/index.html) > ? > > It's written in Python but there's a Perl replacement (to stem the PR > nightmare), which is 99% complete, lurking around which was written by > #perl denizen blech. The guys from London.pm wrote Scribot (http://www.scribot.com/) wich could be more useful...
Re: [perl #814] [PATCH] fix PMC type morphing
Foor for thought... There currently is a 'morph' vtable entry, which I believe is intended to morph from one vtable type to another. I think it'd be better to implement this function properly than to use macros (talk to Robert ;), especially considering that certain vtables might have special morphing requirements, such as setting PMC_is_buffer_ptr_FLAG. Of course, morph seems to be unimplemented, and my attempt at implementing it ran into a problem, which I brought up here: http:[EMAIL PROTECTED]/msg09317.html There are two problems: a) morph will break horribly when we deal with tied variables, since it will have to reimplement *every* PMC method to avoid any morphing. b) Since it's possible that dest == src, we need to make a copy of our data (be it a buffer ptr, or regular number) on the local stack, call morph() to morph the PMC and initialize data, and then set the new value. This pattern is currently utilized in the string PMC methods, but not with the number-related methods. So in conconclusion, while I don't have any reservations about your patch, I do have a preference that it be done differently. :) Mike Lambert
Streams vs. Descriptors
For file I/O (in core.ops, not io.ops), do we want to use file descriptors or streams? open uses fopen(), close uses fclose(), but read uses read(), and write uses write(). And all the comments say descriptors. Any opinions one which way the code should be patched? -- Bryan Logan
Re: Streams vs. Descriptors
I changed io.ops and pretty much the rest of parrot to always go through PIO, which has streams. (or at least "handles"). I left core.ops alone because I didn't know what the intent was. Are those ops meant to be superseded by the ones in io.ops? IMHO, all IO in parrot should go through PIO, so file descriptors should not be used at all. --Josh At 18:33 on 07/14/2002 CDT, Bryan Logan <[EMAIL PROTECTED]> wrote: > For file I/O (in core.ops, not io.ops), do we want to use file descriptors = > or streams? > open uses fopen(), close uses fclose(), but read uses read(), and write use= > s write(). And all the comments=20 > say descriptors. > > Any opinions one which way the code should be patched? > -- > Bryan Logan >
Re: coders: add doco
I'm still catching up on backlogged mailing list mail here, but just to try to be helpful- Like many folks who lurk on this list, I have limited time to do detailed work on parrot internals, much as I would like to. But I am always excited when there's an opportunity to do simple, menial tasks that help our more active contributors to be more productive. If someone can tell me what the documentation standards should be, i'll be happy to either devise a program to try to check it (like check_source_standards.pl does for our coding standards) or manually review and prod folks to help get our documentation up to standards. But before I can do that I need to know what the end goal is. In general, Are we shooting for literate code, or separate documentation from code? Along the same lines, what documents are we looking to generate? Per-file docs? One big developers guide? (If so, how is it divided up) Are POD directives to be used for things other than strictly docmentation? (=for API? did that go anywhere?) Do we want POD for every function? Every non-static function? Are there simple guidelines we can use to programatically identify trouble spots? - a certain comments/line of code metric - a readability metric (Lingua::EN::Fathom) for our comments? Etc.. IMHO, all this needs to either go into pdd07 or into a new pdd. I hate to bounce this back to the designers, but I don't think I have enough experience, perspective, or authority to make any of these decisions in a vacuum. --Josh
Re: PARROT QUESTIONS: Use the source, Luke
Brent, Good stuff. Didn't you also send out a draft PDD about how types should be named and managed in parrot at one point? I, for one, would love to see a PDD that described C-level nanming and namespace management in general. --Josh At 3:11 on 07/14/2002 PDT, "Brent Dax" <[EMAIL PROTECTED]> wrote: > # 2. What does having a Parrot_ prefix signify, considering=20 > # both the opcodes and=20 > # the embed api use it? It's hard to distinguish between them. > > It signifies one of the following: > -This function is externally visible. > -This function belongs to Parrot at large, and not any particular > subsystem (e.g. Parrot_sprintf and friends). > -This function has an identical name to a C library function because it > emulates it for certain platforms (e.g. Parrot_dlopen (?)). > -This function is autogenerated, so we're going to be paranoid about > naming conflicts. > > For functions in the last category, I'd suggest we use > subsystem-specific names, e.g. Op_ for the opcodes. >
Re: Streams vs. Descriptors
IMHO, there's no way to find out quite like trying to use it :) In my experiences with it thus far, it all seems to work fine. Melvin has indicated that its API and internal structure may need some changes at some point, but the basic functionality does seem to be there today, at least enough for the moment. --Josh At 18:22 on 07/14/2002 PDT, Stephen Rawls <[EMAIL PROTECTED]> wrote: > --- Josh Wilmes <[EMAIL PROTECTED]> wrote: > > IMHO, all IO in parrot should go through PIO, so > > file descriptors should > > not be used at all. > > >From io.ops: > "This will go away when print ops are all migrated to > use ParrotIO instead of STDIO. Right now ParrotIO is > not stable enough to replace STDIO." > > Maybe someone with more knowledge than me can explain > what is unstable? > > Thanks, > Stephen Rawls > > __ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com
RE: PARROT QUESTIONS: Use the source, Luke
Brent Dax wrote: > > 2. What does having a Parrot_ prefix signify, considering > > both the opcodes and the embed api use it? > > It signifies one of the following: > -This function is externally visible. > -This function belongs to Parrot at large, and not any particular > subsystem (e.g. Parrot_sprintf and friends). > -This function has an identical name to a C library function because > it emulates it for certain platforms (e.g. Parrot_dlopen (?)). > -This function is autogenerated, so we're going to be paranoid about > naming conflicts. Maybe I'm just being naive... but it seems to me that if there are four different meanings, there should be four different actual prefixes. -- John Douglas Porter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: [perl #814] [PATCH] fix PMC type morphing
On Sun, 14 Jul 2002, Mike Lambert wrote:
> There currently is a 'morph' vtable entry, which I believe is intended to
> morph from one vtable type to another. I think it'd be better to implement
> this function properly than to use macros (talk to Robert ;), especially
> considering that certain vtables might have special morphing
> requirements, such as setting PMC_is_buffer_ptr_FLAG.
The macro is my way of saying "I don't know how this should be done, but
adding a bunch of if's around every place where we change something's type
is definitely _not_ the way." It's not a permanent solution, but it's a
solution that will fix the immediate problem without changing the way
things are done, and which can easily be changed if we decide to do
something different -- just re-define the macro to call your Function du
Jour.
> Of course, morph seems to be unimplemented, and my attempt at
> implementing it ran into a problem, which I brought up here:
> http:[EMAIL PROTECTED]/msg09317.html
In that thread you bemoan our lack of multi-dispatch, which appears to be
changing...
> a) morph will break horribly when we deal with tied variables, since it
> will have to reimplement *every* PMC method to avoid any morphing.
To me this is the killer -- what's the point of a morph method if you give
the object no data, but just a desired type? I agree with you, Mike, that
it's easier at that point to just create a new PMC of the type you want.
What would be nice is some sort of PMC->accept(PMC * thing) method, so you
could create a temporary value, then throw it at the target. By default,
this would replace the target by the temporary. I suspect we'll be using
multiple dispatch to deal with this, so whatever is done in the short term
may be moot. In any case, just reaching in and modifying someone else's
vtable is bad.
While we're on the subject of gripes... What do you think this code
sequence should do:
new P0, .PerlUndef
new P1, .PerlUndef
set P0, 1.5
set P1, 1
lt P1, P0, LESS
gt P0, P1, GREATER
branch ITS_A_WASH
That's right -- (!(P1 < P0) && (P0 > P1)), because the lt truncates P0's
value, but the gt turns P1 into a float. Blech. And if one of them
happens to be a string, things get even more interesting. I've got a
patch to promote everything to FLOATVAL before doing numeric comparisons,
which solves at least some cases. Is it worth putting in, when we know it
will come right back out once multiple dispatch is in? In any case, I've
attached a test to compare what parrot's Perl* types do with what Perl
does, just so we know where we stand.
/s
#! perl -w
use Parrot::Test tests => 36;
use strict;
my %things;
BEGIN {
$things{PerlString} = ['"1"', '"1"', '"1.5"', '"-3"', '"banana"'];
$things{PerlNum} = ['1.', '1.1', '2.34', '1.499', '-3.1',
'.1'];
$things{PerlInt} = ['1', '2', '4', '0', '-3'];
}
foreach my $types ([qw(PerlNum PerlInt)],
[qw(PerlNum PerlString)],
[qw(PerlNum PerlNum)],
[qw(PerlInt PerlInt)],
[qw(PerlInt PerlString)],
[qw(PerlInt PerlNum)]) {
foreach my $op (qw(gt lt ge le eq ne)) {
my ($code, $output) = gen_test($op, @$types);
output_is($code, $output, "operator $op");
}
}
my %ops;
BEGIN { %ops = qw(gt > lt < ge >= le <= eq == ne !=); }
sub gen_test {
no warnings 'numeric';
my ($op, $a, $b) = @_;
my @as = @{$things{$a}};
my @bs = @{$things{$b}};
my $code;
my $reg = 0;
for (@as) {
$code .= <
[perl #815] [PATCH] fix assembler's floating-point constant RE
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #815]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=815 >
Should handle things like "1e8", but it now requires a decimal point.
/s
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3822/3548/fe63c3/assembler.patch
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.77
diff -u -r1.77 assemble.pl
--- assemble.pl 4 Jul 2002 18:36:17 - 1.77
+++ assemble.pl 15 Jul 2002 02:16:47 -
@@ -714,7 +714,8 @@
my $bin_re = qr([-+]?0[bB][01]+);
my $dec_re = qr([-+]?\d+);
my $hex_re = qr([-+]?0[xX][0-9a-fA-F]+);
- my $flt_re = qr([-+]?\d+\.\d+([eE][-+]?\d+)?);
+ my $flt_re = qr{[-+]?\d+ (?:(?:\.\d+(?:[eE][-+]?\d+)?)
+ | (?:[Ee][+-]?\d+))}x;
my $str_re = qr(\"(?:[^\\\"]*(?:\\.[^\\\"]*)*)\" |
\'(?:[^\\\']*(?:\\.[^\\\']*)*)\'
)x;
RE: PARROT QUESTIONS: Use the source, Luke
John Porter:
# Brent Dax wrote:
# > > 2. What does having a Parrot_ prefix signify, considering
# > > both the opcodes and the embed api use it?
# >
# > It signifies one of the following:
# > -This function is externally visible.
# > -This function belongs to Parrot at large, and not any particular
# > subsystem (e.g. Parrot_sprintf and friends). -This function has an
# > identical name to a C library function because it emulates it for
# > certain platforms (e.g. Parrot_dlopen (?)). -This function is
# > autogenerated, so we're going to be paranoid about naming
# conflicts.
#
# Maybe I'm just being naive... but it seems to me that if
# there are four different meanings, there should be four
# different actual prefixes.
Well, let's go over the justifications for the first three meanings
having Parrot_...
-External visibility: This is something we want to have unequivocally
identified with Parrot. Also, we don't want unnecessary stuff added on
(which is why we don't want Parrot_extern_ or something).
-General functions: This is something that doesn't belong to any
particular category, so we don't want to prefix it and artificially
categorize it.
-C library wrappers: This is Parrot's version of the function, so it
makes sense to prefix it with Parrot_.
The third category I can see having a prefix of plat_ (for platform) or
some such, and perhaps the second could have misc_, but I foresee that
becoming annoying. (Which seems better to you, Parrot_sprintf or
misc_sprintf?)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: PARROT QUESTIONS: Use the source, Luke
On Monday 15 July 2002 02:25 am, Brent Dax wrote: > -C library wrappers: This is Parrot's version of the function, so it > makes sense to prefix it with Parrot_. > > The third category I can see having a prefix of plat_ (for platform) or > some such, and perhaps the second could have misc_, but I foresee that > becoming annoying. (Which seems better to you, Parrot_sprintf or > misc_sprintf?) c. parrot_sprintf Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
RE: PARROT QUESTIONS: Use the source, Luke
[EMAIL PROTECTED]:
# Good stuff. Didn't you also send out a draft PDD about how
# types should
# be named and managed in parrot at one point? I, for one,
At one point I sent out a patch to PDD7 that handled type naming.
# would love to
# see a PDD that described C-level nanming and namespace
# management in general.
I'd be happy to draw up guidelines if someone can tell me what they
should cover (naming of functions and data structures--anything else?)
and if people will read and review when I've finished it.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
Ashley Winters:
# On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > -C library wrappers: This is Parrot's version of the
# function, so it
# > makes sense to prefix it with Parrot_.
# >
# > The third category I can see having a prefix of plat_ (for
# platform)
# > or some such, and perhaps the second could have misc_, but
# I foresee
# > that becoming annoying. (Which seems better to you,
# Parrot_sprintf or
# > misc_sprintf?)
#
# c. parrot_sprintf
Lowercase is always the hallmark of struct names, i.e. parrot_string_t.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: Perl6 grammar (take V)
[no longer sent to perl6-internals because it's not relevant there]
I see a problem . . whether the problem's with me or the grammar, that's
for you people to decide.
Do I read this part of the grammar correctly?
> sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
> | '{' hv_seq '}'<
> | '[' av_seq(?) ']'
> |
>
> hv_seq: /,?/
>
> term: '<' expr(?) '>'
> | subscriptable subscript(s?)
> | /$CONTEXT/o term
> | sv_literal <
> | class
> | closure<
A "term" can be either a scalar literal ("sv_literal") (which might be a
hash reference literal), or a closure (which might be a block).
Both of those could be written "{ stuff }", for various values of stuff,
but it looks like the current disambiguation rule is "if it's nothing
but a sequence of "pair"s, then it's a hash ref, otherwise it's a
closure.
My perl5 sensibilities tell me that that's likely to cause a problem
when I want to do something like this:
$hashref = { function_returning_hash() };
because I won't get the function's return values put into a hash,
because the stuff inside the { ... } isn't a list of pairs. Instead
I'll get a (reference to) a closure, not at all the same thing.
Of course, in perl5, the requirement that "sub" prefix any
closure-as-a-term nicely disambiguates that, but I understand that this
is being phased out for perl6 (the grammar backs that up).
How does perl6 distinguish between:
$hashref = { function_returning_hash() };# call sub, get hash ref
and
$subref = { function_returning_hash() }; # make closure, don't call sub yet
?
(I hope the answer isn't "white space" . . )
[Hi, I'm new around here, so I'll give you the three-line introduction.
I teach Perl at Monash Uni, my office is in the same corridor as
Damian's, and I like cats, chocolate, and curry. (Not all at once.) ]
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Ambivalent? Well, yes and no. - button slogan
RE: Perl6 grammar (take V)
Deborah Ariel Pickett:
# [no longer sent to perl6-internals because it's not relevant there]
#
# I see a problem . . whether the problem's with me or the
# grammar, that's for you people to decide.
#
# Do I read this part of the grammar correctly?
#
# > sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
# > | '{' hv_seq '}'<
# > | '[' av_seq(?) ']'
# > |
# >
# > hv_seq:/,?/
# >
# > term: '<' expr(?) '>'
# > | subscriptable subscript(s?)
# > | /$CONTEXT/o term
# > | sv_literal <
# > | class
# > | closure<
#
# A "term" can be either a scalar literal ("sv_literal") (which
# might be a hash reference literal), or a closure (which might
# be a block).
#
# Both of those could be written "{ stuff }", for various
# values of stuff, but it looks like the current disambiguation
# rule is "if it's nothing but a sequence of "pair"s, then it's
# a hash ref, otherwise it's a closure.
#
# My perl5 sensibilities tell me that that's likely to cause a
# problem when I want to do something like this:
#
# $hashref = { function_returning_hash() };
#
# because I won't get the function's return values put into a
# hash, because the stuff inside the { ... } isn't a list of
# pairs. Instead I'll get a (reference to) a closure, not at
# all the same thing.
#
# Of course, in perl5, the requirement that "sub" prefix any
# closure-as-a-term nicely disambiguates that, but I understand
# that this is being phased out for perl6 (the grammar backs that up).
#
# How does perl6 distinguish between:
# $hashref = { function_returning_hash() };# call sub,
# get hash ref
# and
# $subref = { function_returning_hash() }; # make
# closure, don't call sub yet
# ?
When Perl can't disambiguate, you have to do it instead:
$hashref = hash { function_returning_hash() };
$subref = sub { function_returning_hash() };
Of course, there may be other ways for Perl to disambiguate--this one
comes to mind:
my HASH $hashref;
my CODE $subref;
As for the above grammar, I suspect that the is misplaced. It
should probably be allowed to fall through to the closure.
(Alternatively, always parse it as a closure and afterwards run through
the parse tree, checking all the closures and converting those that only
contain pairs.)
# (I hope the answer isn't "white space" . . )
#
#
# [Hi, I'm new around here, so I'll give you the three-line
# introduction. I teach Perl at Monash Uni, my office is in the
# same corridor as Damian's, and I like cats, chocolate, and
# curry. (Not all at once.) ]
Well, any friend of Damian's... :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
Brent Dax wrote: > Ashley Winters: > > c. parrot_sprintf > > Lowercase is always the hallmark of struct names, i.e. > parrot_string_t. Ehhh... you yourself said something about plat_ and misc_ as (theoretical) alternatives. Anyway, it's a silly rule. Upper-case (and lower-case) are going to have to do multiple duty. Here's four: Parrot parrot _Parrot _parrot Here's two more: __Parrot __parrot Public API clearly should be Parrot. Any decisions regarding the rest should be for the benefit and convenience of us the developers. Right? Why make things harder for ourselves? -- John Douglas Porter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Streams vs. Descriptors
At 09:55 PM 7/14/2002 -0400, Josh Wilmes wrote: >IMHO, there's no way to find out quite like trying to use it :) > >In my experiences with it thus far, it all seems to work fine. Melvin has >indicated that its API and internal structure may need some changes at >some point, but the basic functionality does seem to be there today, at >least enough for the moment. It works for now. We need to make the IO PMC official, as in put it in the PMC table, and implement a few methods in its vtable. Right now it is an anonymous PMC with a null vtable. Since I haven't tinkered with the IO code in months, I'm actually sort of foggy on what needs to be done. I know the buffering layer does need to be finished. I also have the net api ops to commit. I think what IO needs is some discussion first. That is the main reason I sort of stopped work on it. There were unanswered questions but since December I think maybe some of those have been answered, such as whether we are using real threads (yes), and could we fake async with threads on platforms without an aio api. We need to discuss/design: 1) Async support. The IO system needs to be asynchronous and re-entrant at the core, whether by threads or by use of the platform's async support. Other things like callbacks assume other features of Parrot to be finished, like subs/methods. 2) Filters (or IO disciplines) - People have different opinions on what these even mean. To me it means a "layer" that can be pushed onto an IO stack that may filter or transform the data and/or perform opaque actions, while representing the IO handle as a standard stream with a standard API. Also think about how IO layers can be implemented completely in Parrot. 3) Discussion needs to be done on what Parrot IO in general will be. What shall the Parrot IO API deliver as a contract? What flags, constants, etc. do we use. Do we make our own "standardized" constants, or expose platform specific constants, or both? All of this needs to be outlined and documented before going too much further on the IO subsystem, codewise, and I'm more than happy to let someone else take the lead. -Melvin
RE: PARROT QUESTIONS: Use the source, Luke
John Porter:
# Brent Dax wrote:
# > Ashley Winters:
# > > c. parrot_sprintf
# >
# > Lowercase is always the hallmark of struct names, i.e.
# > parrot_string_t.
#
# Ehhh... you yourself said something about plat_ and misc_
# as (theoretical) alternatives.
#
# Anyway, it's a silly rule. Upper-case (and lower-case) are
# going to have to do multiple duty.
Here's the rules, roughly as they stand right now:
-Functions start with Parrot_[a-z] or just [a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with PARROT_[A-Z] or just [A-Z].
-Struct names are of the form parrot_[a-z_]+_t.
Perhaps we should change the rules to this:
-Public functions start with Parrot_[a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with PARROT_[A-Z] or just [A-Z].
-Struct names are of the form parrot_[a-z_]+_t.
-Private functions start with parrot_[a-z] or just [a-z].
If people want that scheme, speak now or forever hold your peace. :^)
# Here's four:
#
# Parrot
# parrot
# _Parrot
# _parrot
#
# Here's two more:
#
# __Parrot
# __parrot
The last four are reserved by various C and C++ standards.
# Public API clearly should be Parrot. Any decisions regarding
# the rest should be for the benefit and convenience of us the
# developers. Right? Why make things harder for ourselves?
That means deciding what's harder and what's easier. Personally, I find
Parrot_ easier than plat_ to remember.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
At 09:27 PM 7/14/2002 -0700, Brent Dax wrote: Wow, Brent lives! :) >Here's the rules, roughly as they stand right now: > > -Functions start with Parrot_[a-z] or just [a-z]. > -Typedefed names start with Parrot_[A-Z] or just [A-Z]. > -Macros and constants start with PARROT_[A-Z] or just [A-Z]. > -Struct names are of the form parrot_[a-z_]+_t. > >Perhaps we should change the rules to this: > > -Public functions start with Parrot_[a-z]. > -Typedefed names start with Parrot_[A-Z] or just [A-Z]. > -Macros and constants start with PARROT_[A-Z] or just [A-Z]. > -Struct names are of the form parrot_[a-z_]+_t. > -Private functions start with parrot_[a-z] or just [a-z]. > >If people want that scheme, speak now or forever hold your peace. :^) > ># Here's four: ># ># Parrot ># parrot ># _Parrot ># _parrot ># ># Here's two more: ># ># __Parrot ># __parrot > >The last four are reserved by various C and C++ standards. I always hear this, but in real life it is never much of a problem. Especially with a namespace like [Parrot] Honestly, reserved identifier's are one area I will always be admittedly ignorant about. C is not changing much nowadays, and the odds of there ever being a POSIX or ANSI api using any form of *Parrot* are, well, 0. So, I say use Parrot, _Parrot, or __Parrot with abandon and forever put this ANSI/POSIX collision argument to bed. >That means deciding what's harder and what's easier. Personally, I find >Parrot_ easier than plat_ to remember. I'll go along with either of your schemes, as long as we standardize on one and stick to it. That also means cleaning up all of the current names to match one or the other. -Melvin
RE: PARROT QUESTIONS: Use the source, Luke
Brent Dax wrote: > If people want that scheme, speak now or forever hold your peace. Sounds reasonable to me. (FWIW) > > _Parrot > > _parrot > > __Parrot > > __parrot > > The last four are reserved by various C and C++ standards. Damn, I forgot about that. I'm a C coder from Way Back; still don't have a good hold on these Newfangled Standards. > Personally, I find Parrot_ easier than plat_ to remember. Well, I41 wouldn't have suggested plat_... -- John Douglas Porter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
PARROT QUESTIONS: The PDDs
I decided my next step should be to take a look at the PDDs so I know what's going on. I would expect them to be like a writer's canon for a TV show. I'll write my impressions as I go on. PDD00: Does PDD still mean 'Perl Design Document', or should it mean 'Parrot ...'? The documents seem to all refer to the interpreter. While I'm thinking about it, where will 'Parrot' leave off and 'Perl6' begin? At some point, it will be inappropriate to discuss the Parrot interpreter on a Perl6 list, since Perl6 might have JVM/CLR backends, and Parrot might have Python/Ruby frontends. PDD01: Perl Design Documents Question: PerlIO subsystem? Is it PIO now or something? A description of what level of I/O handling will be available to language implementers would be nifty. I never bothered to read up on what PerlIO did, anyways. Lots of use of the word 'Perl' everywhere. s:ie /perl/parrot/ PDD02: Common vtable format for all variables Nice. Question: Why is the key param for keyed_int vtable functions a pointer? Considering I have to implement all those functions to add a PMC... seems odd to be passed a pointer to a value which is guaranteed to be non-NULL. Is every parameter for every vtable function IN? Err, I just found the add_* functions. Answer: no. For a specification like this, perhaps in/out could be added to parameters or something? It's loathesome non-C clutter, I know. You don't have to put it in, I can live without it. :) Question: set_string_(native|unicode|other) specifies source or dest format? I'd assume the string type is the destination's type. It does coercion from the source STRING*'s format to the $1 format, right? Where's keyed_bignum, anyways? Don't have a heart attack! Just kidding. I don't see any mention of thunking /(.*)(_keyed.*)/ functions to $1(get_pmc$2()). Question: Are thunked _keyed methods provided by default for PMC implementors? vtables.pod says there are 'sensible' defaults, but it seems to have been written pre-keyed-PMCs. Overall, very informative and intimidating. PDD03: Parrot Calling Conventions Definitely a must-read for every assembly-writing parrot coder! Question: Prototypes aren't specified in Parrot code? I see no pointer to a yet-to-be-written calling-convention-specifiying-prototype PDD. PDD04: Perl's internal data types Huh? A bunch of stuff about Perl's IV, UV, NV, and some big* structs. From the title, I expected a description of INTVAL, FLOATVAL, BIGINT, BIGNUM, and STRING. Instead, I see internal details of big* and string implementation which I would guess don't match what's being done. I don't see the point. Question: What should I have gotten from reading this PDD? PDD05: Opcode Function specs It took me a second to realize this was a specification of the *.ops file functions. It seems obvious now, but it wasn't explicitly stated. Question: How does JIT work with this? Whoa, this document is using IV/NV. Needs updating to INTVAL or something. Umm... the example is totally inconsistent with what's actually in the opcode functions. This PDD doesn't need a rewrite; it needs to be superceded. PDD06: Parrot Assembly Language Can't really judge it, but based on age alone I'd guess it's for the best I didn't try to remember it. No offense. PDD07: Conventions and Guidelines for Perl Source Code Coding standard part works for me. As long as it's specific, you can define whatever standard you want as long as it's applied consistently. Naming convention part is obsolete. Probably needs it's own, new PDD. PDD08: Indexing Aggregate PMCs I had to read very closely. I don't know if it will ever be simple to explain. Question: What's @foo["a";12;$hi] trying to do? That's a streamed iterator thingy or something in Perl6, if I recall. I've actually read the Apocalypses, and I don't see what kind of machine support is needed for that. If keyed ops are really implementing @foo["a"][12][$hi], that would be multi-dimensional as stated in the PDD. I can kinda see how someone implementing a vector class would want to know all the dimensions at once, but most classes (like PerlArray & PerlHash, I assume) will just dereference the first KEY* and send (if non-null) key->next to that element's _keyed vtable function, right? PDD09: Garbage Collection and Dead Object Detection This reminds me of the time I implemented a copying GC... I suppose this is good enough for a PDD. Is there a document on how to actually do stuff, though? How to allocate memory, get it hooked up to the root set through various mechanisms? Do I need to implement the mark vtable entry to attach memory to my PMC? Answers like that. Question: How do I allocate memory? Question: How do I make sure my memory gets marked while I need it? Question: Is the GC really implemented in resources.c? It's a non-obvious name, and the top-of-file comment doesn't say so. Okay, that's all of the PDDs. I learned quite a bit from them, hopefully some of it was accurate
[COMMIT] The assembler doesn't use XS anymore.
The assembler doesn't use the XS stuff anymore, just committed a patch build from Jeff's code. Let's hope to see some more tinderboxes green. Daniel Grunblatt.
RE: Perl6 grammar (take V)
On Sun, 14 Jul 2002, Brent Dax wrote:
> Deborah Ariel Pickett:
> # My perl5 sensibilities tell me that that's likely to cause a
> # problem when I want to do something like this:
> #
> # $hashref = { function_returning_hash() };
> #
> # because I won't get the function's return values put into a
> # hash, because the stuff inside the { ... } isn't a list of
> # pairs. Instead I'll get a (reference to) a closure, not at
> # all the same thing.
You've got a point. There's an easy way to say "I want a sub":
my $sub = -> { ... }
But I can't think of a similarly punctuation-intensive way to say "I want
a hash." (someone please step in and correct me).
> # that this is being phased out for perl6 (the grammar backs that up).
I wouldn't take the grammar too seriously -- it's more or less one
person's interpretation of the Apocalypses, Exegeses, and recent mailing
list traffic.
> my HASH $hashref;
> my CODE $subref;
So if I have the above two declarations, and do this later:
$hashref = { ... };
$subref = { ... };
It does "the right thing"? This could work up to a point, but Perl can do
crazy things like this:
$foo ?? $hashref :: $subref = { ... };
and propagate context differently to different branches of the ternary
(try doing $x ? @y : $z = (2,3,4) sometime -- very cool!). And while we
could interpret the block differently on each branch, that seems a bit too
scary.
> (Alternatively, always parse it as a closure and afterwards run through
> the parse tree, checking all the closures and converting those that only
> contain pairs.)
Or use context to try and figure it out. Unfortunately, from the outside
I think either would just look like "a reference". Maybe if the compiler
could figure out that your function would return pairs, it could fix
things up so that turns into a hash-ref. But then you can get into
trouble with a function that returns pairs only in non-hash-ref
contexts...
/s
Re: Perl6 grammar (take V)
On Monday 15 July 2002 06:57 am, Sean O'Rourke wrote:
> On Sun, 14 Jul 2002, Brent Dax wrote:
> > Deborah Ariel Pickett:
> > # My perl5 sensibilities tell me that that's likely to cause a
> > # problem when I want to do something like this:
> > #
> > # $hashref = { function_returning_hash() };
> > #
> > # because I won't get the function's return values put into a
> > # hash, because the stuff inside the { ... } isn't a list of
> > # pairs. Instead I'll get a (reference to) a closure, not at
> > # all the same thing.
>
> You've got a point. There's an easy way to say "I want a sub":
>
> my $sub = -> { ... }
>
> But I can't think of a similarly punctuation-intensive way to say "I want
> a hash." (someone please step in and correct me).
I nominate:
$() == scalar()
%() == hash()
@() == array()
For the above function:
$hashref = %(function_returning_list_which_needs_to_be_hashified());
That would make %() a hash constructor, just like {}.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
