Re: References to hash elements?
Simon Cozens [EMAIL PROTECTED] writes: Arthur Bergman: I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right. I would have thought that a hash element would itself be a PMC rather than an immediate value, so a reference to that should be treated just like any other reference to a PMC. I believe the correct name for this is 'Pair' isn't it?
Re: Mr Parrot's Neighborhood
Michal Wallace [EMAIL PROTECTED] wrote:
A .pcc_sub isn't an object, just a little segment of the list of
instructions.
A pcc_sub *is* an object:
find_global P0, _the_sub
invokecc
print back\n
end
.pcc_sub _the_sub:
print in sub\n
invoke P1
You can store it away, pass it around and so on.
My problem is that I don't know what a Control stack, pad stack,
user stack, and warnings are.
Here's my guess:
ControlStack {
This is another set of smaller papers. One box each.
if Mr. Parrot meets a ret op, he takes the
top sheet and goes to whatever address is on it.
Yes, its used for C-like function calls, where the return address is on
the control stack. But more importantly: the control stack has exception
handlers on it. If you install an exception handler, its pushed onto the
control stack. If an exception is thrown, the handler is popped off that
stack and control transfers to the handler subroutine.
When we call a Sub, we write the return address on
the top sheet. Same with a closure.
No. Subs and Closures are invoked, no control stack is involved
** I don't understand what happens here when we call
a continuation.
Same here.
PadStack {
Hmm. Does this mean lexical pads?
Yep. C { my $i; } would create/push a new lexical pad with that
variable name inside.
UserStack {
By process of elimination, this would be the eight
register stacks?
No. Its an intermediate store to save registers. Its used:
a) for C-style function calls
b) to get at return results, if the caller did save all 32 registers:
pushp # save P0..P31 to register frame
invoke # call a sub - result in P5
save P5 # save P5 onto user stack
popp# restore P0-P31 from register frames
restore P5 # pop off result from user stack
Warnings {
** Beats me. Is this for holding exception handlers?
This are the warning flags. When you call a sub and that turns off
warnings, the warning flags are restored to the original state, when the
sub returns.
Final questions:
What's a context?
The context holds pointers to all these stacks and structures. The
semantics of the different Sub types define, how to deal with items in
the context. E.g. a Closure has the callers pad stack in its context, so
that a Closure can access lexicals of the caller.
How would I picture Eval? Does that involve building new houses?
A new street with new houses.
For a sub, he just writes a return address on the control stack
No, not for Parrot Calling Conventions. A Sub is an object.
Again: We have 2 calling conventions:
1) C-style
2) PCC
Only 1) is using return addresses pushed onto the Control Stack.
The class tree in subs.pod is confusing to me:
Sub
Closure
Continuation
Coroutine
Eval
RetContinuation
These are all for 2) - no pushed return address is involved.
Michal J Wallace
leo
Re: find_global failing
Jonathan Worthington [EMAIL PROTECTED] wrote: Hi, I currently have a file named win32.pasm containing the following:- saveall loadlib P1, 'user32' dlfunc P2, P1, 'MessageBoxA', 'llttl' store_global 'MessageBox', P2 # MANY MORE LINES LIKE THIS restoreall I compile that file to a .pbc file, which works out OK. In then have an imc file that starts like this:- .sub _MAIN # Load Win32 library. load_bytecode win32.pbc # Look up MessageBox function. find_global $P1, MessageBox Executing that results in the following error:- Global 'MessageBox' not found in file '(unknown file)' near line -1 The loaded byte code isn't executed. Its not like .include win32.pasm. We don't have automagic _init or _load functions yet, but finally it could be: .pcc_sub _init: loadlib P16, 'user32' dlfunc P17, P16, ... store_global ... P17 ... invoke P1 That is after load_bytecode C_init is invoked, if its present in the loaded file. For now, you have to call such initialisation manually. That is above init code and: load_bytecode ... find_global P0, _init pushtopp invokecc poptopp leo
Re: [PATCH] Small register stack fix
Luke Palmer [EMAIL PROTECTED] wrote: +PObj_COW_CLEAR((PObj*)buf); Applied, thanks. leo
Re: yield op?
Michal Wallace [EMAIL PROTECTED] wrote: Hey all, When you invoke a Coroutine, it calls swap_context() Register frames are now properly swapped too. Your given example is working now. I've checked in a slightly modified version as a test. leo
Re: Continuations don't close over register stacks
Dan Sugalski [EMAIL PROTECTED] wrote: [ stack layout ] I'd rather not have the store statically inside the hunk: - small objects code currently has an upper limit for sized header pools Doesn't mean we have to use them, honestly. A separate arena for them is fine. Each sized item (a Buffer_like header of one size class) has its own arena. This isn't the problem. But the more different arenas we have, the more we have to walk during DOD. - more and differently sized pools impose negative effects on DOD times While true, we're already walking the stack frame areas, so I'm not sure it'll work out that way. Yes. But only one arena. With the register frames in place, we would have at least 2 more arenas with (1024+x) and (2048+x) bytes for x=12 currently (32-bit systems). And the question is: should we unify other stacks (Pad, User, Control) with the register frame stacks? stacks.c's implementation has additionally a stack-next pointer which keeps a spare junk against thrashing and it has a stack-limit to guard against wild running user code. leo
Segmentation fault
Hello, I've just started trying to experiment with parrot, and I keep getting segmentation faults, eg when running the following one-liner: set I0, 7 I'm using gcc 2.95.4 on linux, and it says all the tests are passing when I run make test. gdb gives the following: --- [New Thread 16384 (LWP 16833)] [New Thread 32769 (LWP 16834)] [New Thread 16386 (LWP 16835)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16833)] 0x0807f9ec in runops_slow_core (interpreter=0x823bc90, pc=0x827ed34) at src/runops_cores.c:116 116(pc = ((interpreter-op_func_table)[*pc])(pc,interpreter)); - If I change the input file to set I0, 7 set I0, 7 then it appears to run fine (well, I don't get any unexpected output...). Any odd number of these lines seems to cause the problem. Also, if I use the -o option to save the bytecode, and then run that, I don't get any problems. Am I doing something wrong or is it a problem with parrot? I also noticed what seems to be inconsistent behaviour with regard to supplying options to parrot. parrot -r -o file file.pasm and parrot -o file -r file.pasm do different things, as the code that handles the -o option overwrites the -r option: case 'r': ++run_pbc; break; ... case 'o': run_pbc = 0; output = str_dup(opt.opt_arg); break; I assume this isn't deliberate, but I'm not sure what the desired behaviour is. Chris.
Re: Segmentation fault
Chris Allan [EMAIL PROTECTED] wrote: Hello, I've just started trying to experiment with parrot, and I keep getting segmentation faults, eg when running the following one-liner: set I0, 7 end is missing. Program flow just continues with executing garbage. I also noticed what seems to be inconsistent behaviour with regard to supplying options to parrot. parrot -o file -r file.pasm I assume this isn't deliberate, but I'm not sure what the desired behaviour is. This is ok. If -r is given, it has to be after -o to turn on again the run_flag. Chris. leo
Re: Docs and releases
Paul Cochrane wrote: If there are any shy lurkers out there please speak now or forever hold your peace. I'll admit to being a shy lurker... (and have rudimentary C knowledge, but a bit low on the elbow grease atm :-/) Another one, we are getting more and more of them pop up from all over the place, so come on you lot speak up and I might compile a list of things to do if its any help. This also gives me an opportunity to mention to anyone with more time (and possibly ability) than me, that parrot is having problems on LinuxPPC. The specifics are: - parrot hangs on t/op/arithmetics when doing make test I had this exact same error. I still have no idea what caused it but thanks for confirming I am not going crazy. I tried all of the following deleted the source tree and started again nope Upgraded gcc --- nope Upgraded Perl --- nope reinstalled every perl module I could think of - nope Replaced redhat AS with Debian - yep The last item was a last resort because I had spent to much time faffing around trying to find out what caused the error at that time thinking it was local to my machine/me, obviously not. Here's some more info that may help. $ uname -a Linux 2.4.19-r6 #7 Tue Apr 22 16:54:53 EST 2003 ppc 740/750 GNU/Linux $ gcc --version 2.95.3 $ perl --version This is perl, v5.8.0 built for powerpc-linux I was on 5.6.1 when I got the arithmetic error. I hope any of this helps, and if it's possible for me to contribute, even some reasonably trivial task (something possibly like what Melvin mentioned earlier in the week re: macros) would be ok. Well it certainly made me feel better. I'm really impressed with the amount of work people are doing on parrot and related stuff. Keep up the good work! :-) I don't know where some of them get the time. Harry
This week's summary
The Perl 6 Summary for the week ending 20040111
It's Monday. People have been talking about Perl 6, Parrot and the
European Union Constitution. Let's find out what they've been saying
about Parrot first shall we?
Threads
Threads were discussed some more. Dan's deadline is coming up soon,
hopefully soon after that discussion will move from Holy Skirmishes
about architecture and on to meaningful discussions of a real
implementation.
Hmm... that came out rather more dismissive than I intended.
Continuation problems
Luke Palmer found a problem with Parrot's continuations. A continuation
is supposed to encapsulate the interpreter's control state, in other
words the position of the program counter and the state of the register
stacks, and a pointer to the previous continuation. However, it turns
out that a Parrot continuation just contains the program counter and a
pointer to the previous continuation. There was some discussion of why
this was so (Melvin Smith seemed to claim that it was both his fault and
not his fault).
Everyone agreed that this needed to be fixed pretty promptly and it
wasn't long before Luke posted a patch.
http://tinyurl.com/2jzv2
http://tinyurl.com/3for3
A problem with threads
In a change from the discussions of thread philosophy, Jeff Clites
posted about a problem he was having with Parrot's current threads
implementation which was causing problems when trying to join multiple
threads. Between them, Jeff and Leo Tötsch tracked down a possible cause
of the problem and Jeff offered up a patch which Leo applied.
http://tinyurl.com/yssjs
The PPC JIT gets fixed
Jeff Clites also posted a patch which cleans up the last problems with
the JIT on PPC. Leo applied it. Us Apple users cheered.
http://tinyurl.com/2pyft
Luke Palmer gets his act together
Luke Palmer decided to get his act together (given the level of his
contribution to the Perl 6 lists so far, I'm almost scared to find out
what he's going to be like now...) and finish up his 'Priority DOD'
rethink of the Garbage Collector. I confess I'm not really qualified to
discuss what's different about it, beyond the claim of a 10,000% speed
up when there were no 'eager' PMCs about (things that need immediate
cleanup on scope exit; the canonical example being a Perlish file
handle) and only a 5% slowdown when there were.
Luke and Leo discussed the patch a bit before Leo applied it.
http://tinyurl.com/2afyc
http://tinyurl.com/235ak -- Luke explains the patch
IMCC speed issues
Dan posted some timings he'd made of IMCC compiling some large subs,
which were not the most wonderful timings I've ever seen. A 41 minute
compile isn't generally what one wishes to see. Melvin Smith had a few
ideas about what was causing it, as did Leo (it seems that IMCC's
register allocation is very slow in the presence of spilling and Live
analysis increases with the product of the number of lines and variables
in a segment. Leo recommended redoing the sub to reduce the number of
(and avoid long lived) PIR variables (ie. registers) by using lexicals
or globals instead.
http://tinyurl.com/2wb6l
References to hash elements
Arthur Ponie Bergman had some questions about how references to hash
elements would be done. Consider the following Perl code:
my %hash;
$foo = \$hash{key};
$$foo = bar;
print $hash{key}; # Prints bar
Arthur wondered how this could be made to work with the current vtable
setup, specifically in the presence of tying. Simon Cozens thought that
there should be a special HashElement PMC which would handle fetching
the actual value from the hash (or writing it back to the hash) as
appropriate. Dan agreed with him, so it looks like this might be the way
forward.
http://tinyurl.com/2hop4
Instantiation?
Michal Wallace asked how to instantiate objects from Parrot. Luke Palmer
supplied the answer, but pointed out that, at present, classes can only
have integer attributes. It turns out that, for Michal's purposes, he
can probably get by with using properties instead, so that's all right.
Stéphane Payrard did the decent thing and implemented the other
attribute types. He even wrote tests.
http://tinyurl.com/3dul5
http://tinyurl.com/ywgvo
Creating 'proper' interpreters in Parrot
Simon Cozens wondered what was left to do to allow parrot to be embedded
in an interpreter and have PIR fed directly to it. Leo pointed him at
his own YAL.
http://tinyurl.com/2smrp
http://toetsch.at/yal/ -- Yet Another Language
yield op?
Michal Wallace was uncomfortable with the workings of Parrot Coroutines
and posted a sample of parrot code which demonstrated why. Leo promised
to fix it once he'd applied Luke's
Re: Docs and releases
Ooh, ooh, a chance to leave shy lurker status behind and work on one of the coolest software projects out there, count me in. I have some rudimentary C skills and I'm sure there's some elbow grease around here somewhere... Jeff On Mon, Jan 12, 2004 at 05:58:18PM +, Harry Jackson wrote: Robert Eaglestone wrote: Yes, I'm a shy lurker. Are there any more, don't be shy, there might be a lot of barking but no one bites at least I have not had anyone bite me _yet_. Is there anyone on the list who wants to help but does not know where to start. If you are really that shy email me off list. I can think of at least one simple task that needs doing and all it requires is some rudimentary C and a generous helping of elbow grease. Harry
Re: Docs and releases
On Monday 12 January 2004 17:58, Harry Jackson wrote: Robert Eaglestone wrote: Yes, I'm a shy lurker. Are there any more, don't be shy, there might be a lot of barking but no one bites at least I have not had anyone bite me _yet_. Is there anyone on the list who wants to help but does not know where to start. If you are really that shy email me off list. I can think of at least one simple task that needs doing and all it requires is some rudimentary C and a generous helping of elbow grease. Harry I guess, I fit the bill... Lurker type present and ready to be counted. -- Vishal Vatsa Dept. of Computer Sc. NUI Maynooth
Shy Lurking
Well, I may be shy, and I may lurk, but I'm willing and able to contribute. I've coded C professionally, on and off, since 1992, and I like to tinker with things, and I'm not too terrible at documentation. I think a good place to start digging in would be updating docs, though I can be turned to other directions, too. Anyone have suggestions? Rob
Re: Shy Lurking
Robert Eaglestone wrote: Well, I may be shy, and I may lurk, but I'm willing and able to contribute. I've coded C professionally, on and off, since 1992, and I like to tinker with things, and I'm not too terrible at documentation. I think a good place to start digging in would be updating docs, though I can be turned to other directions, too. Anyone have suggestions? Rob If you want to flex some C muscle you could start by finishing this doc http://www.parrotcode.org/docs/strings.pod.html If you scroll to the bottom it has a work in progress and it will also introduce you to how parrot works with strings. I relied on it quite heavily just recently and a finished document would be very hand particularly with example of usage etc. Harry
Re: find_global failing
- Original Message - From: Leopold Toetsch [EMAIL PROTECTED] To: Jonathan Worthington [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 13, 2004 9:13 AM Subject: Re: find_global failing Jonathan Worthington [EMAIL PROTECTED] wrote: Hi, I currently have a file named win32.pasm containing the following:- saveall loadlib P1, 'user32' dlfunc P2, P1, 'MessageBoxA', 'llttl' store_global 'MessageBox', P2 # MANY MORE LINES LIKE THIS restoreall I compile that file to a .pbc file, which works out OK. In then have an imc file that starts like this:- .sub _MAIN # Load Win32 library. load_bytecode win32.pbc # Look up MessageBox function. find_global $P1, MessageBox Executing that results in the following error:- Global 'MessageBox' not found in file '(unknown file)' near line -1 The loaded byte code isn't executed. Its not like .include win32.pasm. We don't have automagic _init or _load functions yet, but finally it could be: .pcc_sub _init: loadlib P16, 'user32' dlfunc P17, P16, ... store_global ... P17 ... invoke P1 That is after load_bytecode C_init is invoked, if its present in the loaded file. For now, you have to call such initialisation manually. That is above init code and: load_bytecode ... find_global P0, _init pushtopp invokecc poptopp Thanks, that works great. I now have a .pbc with loadlibs and dlfuncs for pretty much the entire Win32 API. The next thing I want to look at is constants. At first I thought I could do something like:- .constant MB_YESNOCANCEL 3 But when I compile the pasm file containing that to a .pbc to use with load_bytecode, these constants appear to just get dropped. I've determined this through grepping the .pbc for the identifier associated with the constant (nothing found), and also by observing that no matter how many .constant lines I have in the source .pasm file, the size of the resultant .pbc is the same. So, is .constant not working correctly, or (more likely) not the Right Thing to use in this situation? How should I go about storing the constants for use with the APIs? Thank you, Jonathan
Shy Lurkers
Ok. So far we have had 7 replies to the shy lurker post, oops another one just posted, in the word of Mr. Burns excellent. As to how much elbow grease we can muster between us is open for debate. If you have sent me a message and did not receive a reply please resend the message. We all agree that trying to get started with Parrot is a fairly daunting process. This is in part due to several reasons. 1. Documentation is aimed at someone who already has some experience with Parrot. 2. A lot of the docs are out of date. As an excuse this is partly due to the fluid nature of this project. Its like building houses on quicksand at the moment so trying to keep them up to date is probably chasing rainbows but there is a pot of gold beneath it if we get it. That is not to say they cannot be improved or brought up to speed a bit, in fact this is rather an important task for the next release. 3. There are no TODO lists that people can get their teeth into. Sorry, there is a TODO list but I find it rather terse. Proposal. If no one objects I don't mind starting a TODO list for newcomers or people who just want to get their feet wet. I will try and supply a list of simpler stuff that needs doing and some pointers as to where they should start. If people do not want to post to the parrot list then they can email me direct for information or help. So if you have a job that you think would be good for a newcomer then send it in and I will make a list. I have thrown together a page as an example of what could be done. Don't bookmark it or anything daft like that, its a _demo_. http://www.thingthong.co.uk/ Any ideas sugestions abuse welcome. Incentives. What advantage is there to doing helping with Parrot other than stories to scare your grandchildren with. Serious incentives 1. You will get a feel for how Perl6 will operate at a base level. For anyone contemplating making money as a perl developer this is probably a very good incentive. 2. You get to take part in one of the most cutting edge projects currently alive today. 3. You can say that you are an open source contributor. I am sure there are more reasons, some personal, some not and I imagine everyone on the list have their own reasons for doing it. So if you are lurking and want to help then post to the list with the sort of thing you would like to do and I am sure there are a few who be able to muster up something for you. Harry
RE: Docs and releases
I'm also a shy lurker but would love to help in any way I can. I have twenty+ years experience in C/C++/OOP. Is there a reasonable place to start? Mark Solinski [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Docs and releases
Mark Solinski wrote: I'm also a shy lurker but would love to help in any way I can. I have twenty+ years experience in C/C++/OOP. Is there a reasonable place to start? Bloody hell man, what took you so long ;-). With that amount of experience, take your pick. http://www.parrotcode.org/todo Harry
Re: nci
On Mon, Jan 12, 2004 at 01:01:58PM -0600, Garrett Goebel wrote: Tim Bunce wrote: Tim Bunce wrote: I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see Garrett Goebel quotes Bruno Haible saying I could agree to the LGPL license. Perl could then use ffcall as a shared library (linked or via dlopen) And I see http://www.parrotcode.org/docs/faq.pod.html says Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this. So it seems there's no licensing issue preventing parrot using libffi. Is that right? Are there any others? My bad. In my comments on Dan's blog, I confused libffi with ffcall. Both do roughly the same thing... The libffi was originally produced by Cygnus, but is now part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE ffcall was produced by Bruno Haibel as part of his CLISP package. http://www.haible.de/bruno/packages-ffcall.html ffcall used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not is that libffi is more actively maintained. From mailing lists and csv logs, it looks like both are actively maintained... And since it seems both are usable for parrot from a licencing perspective we're free to use whichever suits best on a given platform - assuming someone implements the relevant interface code. Tim.
Re: Mr Parrot's Neighborhood
On Tue, Jan 13, 2004 at 10:01:32AM +0100, Leopold Toetsch wrote: Michal Wallace [EMAIL PROTECTED] wrote: Here's my guess: [lots of good stuff from leo] Is there a Parrot Architecture Overview document that summarises this kind of high-level view with links to the deeper docs? If not it would be great to have. Tim.
Re: find_global failing
Jonathan Worthington [EMAIL PROTECTED] wrote: Thanks, that works great. I now have a .pbc with loadlibs and dlfuncs for pretty much the entire Win32 API. Fine. ... The next thing I want to look at is constants. At first I thought I could do something like:- .constant MB_YESNOCANCEL 3 But when I compile the pasm file containing that to a .pbc to use with load_bytecode, these constants appear to just get dropped. Yep. Just generate Fruntime/parrot/include/win32.pasm or such and put the constants there. Then C.include the file in main. Jonathan leo
OT: Cost of O'Reilly OSCON?
Sorry for the off-topic post, but I'm having trouble finding anything about the likely cost of registration for the 2004 OSCON. Anyone have any guesses based on past experience? Thanks! =) --TWH
Re: Shy Lurkers
Harry Jackson wrote: If no one objects I don't mind starting a TODO list for newcomers or people who just want to get their feet wet. I will try and supply a list of simpler stuff that needs doing and some pointers as to where they should start. If people do not want to post to the parrot list then they can email me direct for information or help. So if you have a job that you think would be good for a newcomer then send it in and I will make a list. I have thrown together a page as an example of what could be done. Don't bookmark it or anything daft like that, its a _demo_. http://www.thingthong.co.uk/ Any ideas sugestions abuse welcome. Hi, I suggest to use the Twiki on http://www.vendian.org/parrot/wiki/. This would also be a good place for improving the documentation. Nice things there are the 'RecentChanges' page and the change history of the documents. CU, Bernhard -- ** Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Some namespace notes
Here are some notes on namespaces, picking up a thread from about a
month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opcodes. If we're going hierarchic, and we want to separate out the
name from the namespace, that would seem to argue that we'd want it to
look like:
find_global P1, ['global', 'namespace', 'hierarchy'], thingname
That is, split the namespace path from the name of the thing, and make
the namespace path a multidimensional key.
I definitely agree that we should have separate slots for namespace and
name, as you have above. So I think the discussion boils down to
whether a namespace specifier is logically a string or an array of
strings.
Short version: I was originally going to argue for fully hierarchical
namespaces, identified as above, but after turning this over in my head
for a while, I came to the conclusion that namespaces are not
conceptually hierarchical (especially as used in languages such as
Perl5 and Java, at least), so I'm going to argue for a single string
(rather than an array) as a namespace identifier.
Here's my framing of the general problem. I think there are 3 basic
options:
1) No namespaces. That would mean we might have variables named
Foo::Bar::baz, but to parrot that would just be a variable with a
funny name (it wouldn't infer any sort of nesting of variables or
namespaces).
2) Two-level namespaces. That would mean that parrot has the concept of
look up variable 'baz' in namespace 'Foo::Bar', but no concept of
nested namespaces--Foo::Bar is just a funny namespace name (no
nesting of namespaces inferred).
3) Full hierarchical namespaces. So parrot knows how to look up
variable baz inside namespace Bar inside namespace Foo. Parrot would
never need to see the syntax (:: v. . v. whatever) used by
different languages to specify nested namespaces--their compilers would
assemble these as arrays, as in Dan's example above.
(Also, (2) v. (1) is what Tim was indicating with :
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
in his post in the previous thread, I believe.)
I think that probably most agree that (1) is out--so the question is
(2) v. (3).
I think there are 2 considerations:
A) What does a hierarchy give us?
B) What kind of cross-language compatibility do we need?
As to (A), I don't think the hierarchy actually matters much. What I
mean is, that I don't think it's actually significant to say that the
namespace A::B::C is inside of the namespace A::B. For instance,
$A::B::C::var won't fall back to finding $A::B::var -- they're really
just separate namespaces which would have worked just the same if
they'd been called ABC and AB or Foo and Bar. The hierarchy is
only used to conceptually organize things (for humans), not really at
runtime. Notably, this is the viewpoint taken by Java and I believe by
Perl5. (For instance, Java has a com.sun.media.sound namespace, but
not a com namespace.)
So unless I'm missing some uses of a hierarchy, I think that (A)
doesn't argue for (3) over (2), so it boils down to consideration (B).
For (B), what I mean is: Do we want the following to refer to the same
package/namespace:
in Perl:
use Foo::Bar::Baz;
in Java:
import Foo.Bar.Baz;
If we do, then I say we should go with (3), and use the array-based
method of specifying a namespace which Dan indicated above. Then, it's
up to the individual compilers to pick apart this syntaxes into the
same arrays: ['Foo', 'Bar', 'Baz']
On the other hand, maybe we don't want this. Maybe we want these to
refer to different packages/namespaces. In Perl, if I want to actually
instantiate a java.lang.String, maybe it's clearer to just really treat
the class name as java.lang.String. I actually think it should be up
to the individual language implementers to decide if they want to
normalize during compilation to a common syntax for specifying
package names, but I think it makes more sense for them to _not_
normalize, and in Perl just use java.lang.String to pull in that Java
package.
So I'm arguing for (2), which says: Namespaces don't conceptually nest.
Now, that said, this really just argues that most languages actually
use 2-level namespaces in their syntax--that Foo::Bar::Baz doesn't
really indicate nesting. But, we can certainly _allow_ namespace
nesting--it just wouldn't have a one-line syntax. What I'm thinking of
here is having ops like this:
-
# shortcut for lookup of thingnane in global namespace
find_global P1, thingname
-
# lookup thingname in namespace MyPackage::Foo; really, this is:
find namespace MyPackage::Foo inside global namspace, and lookup
thingname in that, so it's still a shortcut
find_global P1, MyPackage::Foo, thingname
-
# here's an alternate, more explicit way to do the same thing. This
might be slower for a single lookup (the one-step method may be able to
Re: Mr Parrot's Neighborhood
At 11:18 PM 1/12/2004 -0500, Michal Wallace wrote: On Mon, 12 Jan 2004, Luke Palmer wrote: A continuation is one snapshot -- it never changes, it never runs. To invoke the continuation is to take you back to that snapshot and start running from there. To invoke it a second time is exactly like invoking it the first time. Thanks. I'd heard this a million times but putting it this way made it click for me. One important addition: While continuations are snapshots of execution context (execution path and variables), they are not snapshots of values. References to globals or lexicals will be restored as the snapshot, but their values can change. -Melvin
Re: This week's summary
TP6S == The Perl 6 Summarizer [EMAIL PROTECTED] writes: TP6S Congratulations Dan TP6S Melvin Smith offered his congratulations to Dan for the TP6S first commercial use of Parrot. I think I can safely say we TP6S all echo those congratulations. shouldn't that be production use? i don't recall ever hearing about a non-commercial but production use of parrot. anyhow, that is something that needs to be publicized somehow. parrot squawks in real life, code at 11! uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Parrot String Doc
OK, I'm looking at the Parrot String documentation, and I've got questions. It's not like the docs are a total mess, they just need some fleshing out. Yeah, that's it. So here I go. Here's the page I'm looking at: http://www.parrotcode.org/docs/strings.pod.html And here are my questions. Or, rather, notes which have questions in them. * OK, I'm game, is 'String' a new thing that's been added to C in the last ten years? I can't find it defined anywhere; my brain must have gone to mush. * Does it help to mention that the source code for string functions is include/parrot/string.h and string.c? * Suppose I add some example code to the doc, creating a string and fooling around with it? Perhaps using code from a string test routine (hint, hint)? I'd do something like this, maybe: INTVAL encoding = where/what are the encoding values? /* is this legal? */ STRING* foo = string_make( pi, foobar, 6, encoding, 0, 0 ); /* foo is foobar */ /* It's a pity we don't have a shorter constructor. */ STRING* bar = string_chopn( foo, 3 ); /* bar is foo */ /* It's also sort-of a pity we don't have this one. */ STRING* baz = string_chop( foo ); /* baz is fo */ * Finally, at the bottom of the doc, I see all these undocumented functions. I think I ought to document them. Any new stuff since this page was last edited? -Rob
Re: Docs and releases
Well, there is always up-to-date documentation, your debugger output ... 0x4C56 Who says that the copy-paste antipattern is bad?
Re: Parrot String Doc
Le Tue, Jan 13, 2004 at 03:06:18PM -0600, le valeureux mongueur Robert Eaglestone a
dit:
OK, I'm looking at the Parrot String documentation, and I've
got questions. It's not like the docs are a total mess, they
just need some fleshing out. Yeah, that's it. So here I go.
Here's the page I'm looking at:
http://www.parrotcode.org/docs/strings.pod.html
And here are my questions. Or, rather, notes which have
questions in them.
* OK, I'm game, is 'String' a new thing that's been added to
C in the last ten years? I can't find it defined anywhere;
my brain must have gone to mush.
STRING, CString are different names for a Cstruct
parrot_string_t. Strings are garbage collected. All garbage
collected entities are accessible thru a pointer to a Cstruct
pobj_t that is an union discriminated by the member Cflags.
Relevant code in Finclude/parrot/pobj.h:
typedef union UnionVal {
...
struct parrot_string_t * string_val;
}
typedef struct pobj_t {
UnionVal u;
Parrot_UInt flags;
}
typedef enum PObj_enum {
...
PObj_is_string_FLAG = 1 8,
}
But this is mostly irrelevant to the string user that will use
the API you document. If you care about internals, see more info
about garbage collection in Fdocs/memory_internals.pod.
--
stef
Re: Parrot String Doc
Stéphane Payrard wrote: Le Tue, Jan 13, 2004 at 03:06:18PM -0600, le valeureux mongueur Robert Eaglestone a dit: OK, I'm looking at the Parrot String documentation, and I've got questions. It's not like the docs are a total mess, they just need some fleshing out. Yeah, that's it. So here I go. Here's the page I'm looking at: http://www.parrotcode.org/docs/strings.pod.html And here are my questions. Or, rather, notes which have questions in them. * OK, I'm game, is 'String' a new thing that's been added to C in the last ten years? I can't find it defined anywhere; my brain must have gone to mush. STRING, CString are different names for a Cstruct parrot_string_t. Strings are garbage collected. All garbage collected entities are accessible thru a pointer to a Cstruct pobj_t that is an union discriminated by the member Cflags. I did notice that they refer to the same struct which is something I found confusing. I noticed them being used interchangeably in places and was wondering if the we should just be using just STRING as per instructions in the documentation and change all references of String to reflect this. Harry
Re: Parrot String Doc
Le Tue, Jan 13, 2004 at 10:34:14PM +0100, le valeureux mongueur Stéphane Payrard a dit:
Le Tue, Jan 13, 2004 at 03:06:18PM -0600, le valeureux mongueur Robert Eaglestone a
dit:
OK, I'm looking at the Parrot String documentation, and I've
got questions. It's not like the docs are a total mess, they
just need some fleshing out. Yeah, that's it. So here I go.
Here's the page I'm looking at:
http://www.parrotcode.org/docs/strings.pod.html
And here are my questions. Or, rather, notes which have
questions in them.
* OK, I'm game, is 'String' a new thing that's been added to
C in the last ten years? I can't find it defined anywhere;
my brain must have gone to mush.
STRING, CString are different names for a Cstruct
parrot_string_t.
I forgot to mention.
You will find the definitions in Finclude/parrot/string.h.
typedef struct parrot_string_t String;
...
#define STRING struct parrot_string_t
etags or ctags (depending if you are an emacs or vi user) is your
friend. I use the following to avoid gathering definitions outside
the core of parrot.
etags `find -name '*.pmc' -o -name '*.c' -o -name '*.h' | grep -v languages/ | grep
-v icu/`
Strings are garbage collected. All garbage
collected entities are accessible thru a pointer to a Cstruct
pobj_t that is an union discriminated by the member Cflags.
Relevant code in Finclude/parrot/pobj.h:
typedef union UnionVal {
...
struct parrot_string_t * string_val;
}
typedef struct pobj_t {
UnionVal u;
Parrot_UInt flags;
}
typedef enum PObj_enum {
...
PObj_is_string_FLAG = 1 8,
}
But this is mostly irrelevant to the string user that will use
the API you document. If you care about internals, see more info
about garbage collection in Fdocs/memory_internals.pod.
--
stef
Re: Parrot String Doc
You'll find some diagrams here which might help. http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDiagramsString On 13 Jan 2004, at 22:06, Robert Eaglestone wrote: OK, I'm looking at the Parrot String documentation, and I've got questions. It's not like the docs are a total mess, they just need some fleshing out. Yeah, that's it. So here I go. Here's the page I'm looking at: http://www.parrotcode.org/docs/strings.pod.html And here are my questions. Or, rather, notes which have questions in them. * OK, I'm game, is 'String' a new thing that's been added to C in the last ten years? I can't find it defined anywhere; my brain must have gone to mush. * Does it help to mention that the source code for string functions is include/parrot/string.h and string.c? * Suppose I add some example code to the doc, creating a string and fooling around with it? Perhaps using code from a string test routine (hint, hint)? I'd do something like this, maybe: INTVAL encoding = where/what are the encoding values? /* is this legal? */ STRING* foo = string_make( pi, foobar, 6, encoding, 0, 0 ); /* foo is foobar */ /* It's a pity we don't have a shorter constructor. */ STRING* bar = string_chopn( foo, 3 ); /* bar is foo */ /* It's also sort-of a pity we don't have this one. */ STRING* baz = string_chop( foo ); /* baz is fo */ * Finally, at the bottom of the doc, I see all these undocumented functions. I think I ought to document them. Any new stuff since this page was last edited? -Rob
Re: Docs and releases
Harry Jackson wrote: Harry Jackson If there are any shy lurkers out there please speak now or forever hold your peace. Alright, that's me too. I've been lurking for a couple years, actually, and have only made one post on perl6-language, I think. I just downloaded parrot again last week after a year or so of just reading the list. I have a basic C knowledge and good perl skills. If I can find something to do, I'd like to donate some time to the project. matt diephouse - http://matt.diephouse.com
Re: Questions about abstract pmcs
At 09:55 PM 1/12/2004 +0100, Stéphane Payrard wrote: On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote: Which brings up a question. What's the difference between .local and .sym? -- Currently, there is none. So I went for the shortest: grep -n -e LOCAL imcc.l imcc.l:181:.sym return(LOCAL); imcc.l:206:.localreturn(LOCAL); Its a relic. I had planned to make .sym usable at varying scope levels (as opposed to .local). I've now come to the conclusion that .sym is not very descriptive and I will probably use .global and other more specific names rather than changing .sym In any case, its there now and will probably stay for imcc hackers who prefer variety. :) -Melvin
[PATCH] Updatecc fix
In the spirit of getting real continuations working Just Right, this modifies IMCC's PCC implementation to emit the updatecc *after* the pushtop, so that the redundant pushtop isn't necessary when returning with a real continuation. I'm also thinking that updatecc should cow_copy_context, not save_context. Right? Luke Index: imcc/pcc.c === RCS file: /cvs/public/parrot/imcc/pcc.c,v retrieving revision 1.39 diff -u -r1.39 pcc.c --- imcc/pcc.c 16 Dec 2003 08:53:34 - 1.39 +++ imcc/pcc.c 14 Jan 2004 06:09:31 - @@ -997,13 +997,13 @@ /* * if we reuse the continuation, update it */ +ins = insINS(interp, unit, ins, savetop, regs, 0); if (!sub-pcc_sub-nci) if (!need_cc) ins = insINS(interp, unit, ins, updatecc, regs, 0); /* * emit a savetop for now */ -ins = insINS(interp, unit, ins, savetop, regs, 0); ins = insINS(interp, unit, ins, need_cc ? invokecc : invoke, regs, 0); ins-type |= ITPCCSUB; /*
