By popular demand, I've put my ongoing list of tasks for the concurrency
implementation branch on the wiki. Mark a task you start to work on with
your initials, so we know you're working on it:
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks
Allison
On Thu, 03 Apr 2008 12:21:56 -0700
Mark Glines via RT [EMAIL PROTECTED] wrote:
On Thu, 03 Apr 2008 12:18:47 -0700
James Keenan via RT [EMAIL PROTECTED] wrote:
Datestamps in the filename (e.g., MMDD)? Or somewhere inside
the
file?
Datestamps in the file, something like in the Perl 6
Will Coleda wrote:
Allison Randal wrote:
Will Coleda wrote:
The current tickets involve removing:
- type* vtables
I'm not sure what you mean by this.
These four VTABLE entries are deprecated.
INTVAL type()
INTVAL type_keyed(PMC* key)
INTVAL type_keyed_int(INTVAL key)
INTVAL
Joshua McAdams wrote:
The dorms that we have this year have large common areas that we have
24x7 access too. I can investigate them more if I need too.
This would be excellent. If the hackathon is the weekend before
YAPC::NA, will the dorms and common areas be available then?
(I.e.,
Patrick R. Michaud wrote:
On Tue, Apr 01, 2008 at 03:22:28PM -0500, Joshua McAdams wrote:
Allison wrote:
Also, we're planning a hackathon the weekend before YAPC::NA,
June 14-15, for core hacking, language implementation, and cage cleaning.
The YAPC::NA wiki [1] currently says that the
For a bit of background: the goal is to someday eliminate type IDs
entirely from Parrot. They're fundamentally broken, because they assume
a static class set in a flat namespace. They assume that the type ID
assigned to a class will be identical when you freeze and thaw bytecode,
which isn't
Andy Lester wrote:
Excellent. Where? On the IIT campus?
Location to be determined. Likely either on campus, or at the conference
hotel, depending on where the majority of Parrot hackers are staying.
Allison
James E Keenan wrote:
1. Why is grapheme normalization form abbreviated as NFG rather than GNF?
The Unicode normalization forms are NFC, NFD, NFKC, and NFKD, so this
fits with the standard naming scheme.
2. If a character set is officially a deprecated term (by whom?),
won't our use of it
Will Coleda wrote:
- Which language targeting parrot requires graphemes? You say, A
grapheme is our concept., but then say, Parrot must support
languages which manipulate strings grapheme-by-grapheme ... but if
it's our own concept, surely there aren't any languages that can be
forcing us to
Gianni Ceccarelli wrote:
(Here follows various comments and opinions on PDD28 draft, written
while reading it)
As has been pointed out, the expression «A grapheme is our concept» is
not really clear. I think «The term grapheme in this document
defines a concept local to Parrot» or some such.
Mark J. Reed wrote:
As a ref point, AppleScript 2.0 (not that I know if anyone wants to
port that to Parrot) characters are defined as Unicode grapheme
clusters, e.g. the base grapheme and its diacriticals... Is that
similar to the concept of a Parrot_Rune?
That's straight from the Unicode
Leopold Toetsch wrote:
1) The Parrot internal character type
«Strings in Parrot's native string format will probably be an array of
Parrot_Runes.»
or iso-8859-1 or UCS-2.
To be more accurate: Parrot has *no* native string format. It stores
strings in whatever format you give it
James Keenan via RT wrote:
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did its thing
I'm currently taking the architect and editor pass through the PDD, and
am integrating the comments from the list.
Thanks!
Allison
The first of Klaas-Jan Stol's tutorials on writing compilers with the
Parrot Compiler Toolkit went up this week on http://parrotblog.org.
Also, we're planning a hackathon the weekend before YAPC::NA, June
14-15, for core hacking, language implementation, and cage cleaning.
Allison
Launched in r26309.
François, your fix to Lua in r26308 went in after I started working on
resolving conflicts in the merge, so I merged those changes after the
rest in r26310.
The pdd17pmc branch can now be considered dead.
Allison
I'll merge the pdd17pmc branch back into trunk tomorrow morning, if I
don't hear any show-stoppers by then.
Allison
François Perrad wrote:
I think the problem is in the wmlsbytecode.pmc (a singleton PMC with
only one method 'load'), because the following command has no output :
parrot wmlsd.pir t/examples_1.wmlsc
The script wmlsd.pir is a disassembler that loads a WMLScript bytecode
and dumps it.
François Perrad wrote:
After reverting commit 26097 ([core] Implement does_pmc and ...),
Why revert it? The behavior wasn't quite right, but we fixed it in the
pdd17pmc branch.
The compiler generates :
- a call to VTABLE_neg (in luaany.pmc) when print(-nil)
- a call to METHOD len (in
chromatic wrote:
... I have to ask, if we switched to METHOD instead of PCCMETHOD, why
do we have PCCRETURN instead of RETURN? =-)
Hysterical raisins, as far as I know.
Largely because I forgot to mention PCCRETURN in that step of the
migration plan. Committed fix in r26268.
Allison
Alright, I set up a windows box with MSVC and ActivePerl and did a
binary search. The commit that caused the breakage is r25266, when we
updated the PMC struct. Tomorrow I'll experiment with reverting parts of
that commit.
The problem was in the conversion of pobj_t to the new flattened
structure for PDD17. I've reverted that part of r25266 for now (in
r26254). The problem is probably an incomplete conversion, with some
parts of the code still expecting the multi-level structure. I'll work
on a more complete
Andrew Parker via RT wrote:
On Thu Jun 28 16:34:17 2007, [EMAIL PROTECTED] wrote:
While comparing pdd15_objects compared to the tests located in
t/pdd15oo we cannot find evidence the following tests exist:
callmethodsupercc
callmethodnextcc
newclass
get_class
removeparent
removeattribute
chromatic wrote:
On Sunday 24 February 2008 18:41:23 Bob Rogers wrote:
Granted, and it's tough to make a PMC truly read-only until after it's
completely initialized . . .
There's a similar problem for accessors and setters. Again, that's
solveable with more code or more cleverness.
Jonathan Worthington wrote:
Hi,
We have for testing isa relationships both:
INTVAL isa_pmc(PMC* lookup)
INTVAL isa(STRING* _class)
However for the does test, we have just:
INTVAL does(STRING* method)
I'm thinking we should have a does_pmc variant too?
Sensible. Make it so.
Also, I'm not
Unfortunately, I'll miss it. I had already scheduled something in
Seattle Sunday afternoon before the hackathon was announced.
I'm hallway hackathoning today.
Allison
Jeff Horwitz wrote:
I *should* be there, though IIRC, Allison will not.
On Thu, 14 Feb 2008, Andy Lester wrote:
I see that
Will Coleda (via RT) wrote:
# Local Variables:
# mode: pir
# fill-column: 100
# End:
# vim: expandtab shiftwidth=4 ft=pir:
Note the added 'ft' directive.
We need to choose one of:
1) ruthlessly eliminate this upstart coda[2]
2) update all other PIR codas, the test, and the PDD to match
James Keenan via RT wrote:
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote:
Does C_LIBS have -lreadline included?
No, it does not.
C_LIBS = -lm -lgmp
Which is not surprising. If you recall, the result set by
auto::readline in the spewing case was 'no'. So with your patch
James Keenan via RT wrote:
[...]
However, the spewing problem occured at auto::readline -- one step
*before* the first superfluous addition of a flag.
Okay, so (summarizing) at the point of running auto::readline, -L/sw/lib
and -I/sw/include are all set appropriately.
Does C_LIBS have
James Keenan via RT wrote:
Okay, I figured out how to do that ... but no better results.
[parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4
[...]
Setting the environmental variable apparently didn't stick.
I can duplicate the failure when I use your startup script. First, try
setting the
James Keenan via RT wrote:
I first tried setting the environmental variable, then using my startup
script in test mode:
$ echo $MACOSX_DEPLOYMENT_TARGET
10.3
#!/bin/sh
CC=/usr/bin/gcc-3.3
CX=/usr/bin/g++-3.3
/usr/local/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX \
--ld=$CX
James Keenan via RT wrote:
Nope.
[parrot] 521 $ ./myconfigure.sh
MACOSX_DEPLOYMENT TARGET is 10.3
There seems to be a missing underscore in MACOSX_DEPLOYMENT TARGET,
but that's probably just your debug message.
Did you try 'export'? Configure spawns its own processes which may be
The attached patch removes '-flat_namespace' and consistently uses
'-undefined dynamic_lookup'. It also restricts the changes to just the
darwin config hints file, which seems like a more appropriate place. It
resolves all the test failures related to undefined symbols on OS X.
(t/src/intlist.t is
On Sun Jan 27 09:19:32 2008, [EMAIL PROTECTED] wrote:
Allison: I have 3 different patches from you in this thread in the last
day. Which one or which combination do you most want tried out?
Test the most recent one, darwin_full_dynamic_symbol_lookup.patch.
(moi: ppc-darwin 10.4.11)
James Keenan via RT wrote:
Determining what C compiler and linker to use...
ccflags: -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
-fno-common -Wno-long-double
/usr/bin/gcc-3.3 -fno-common -no-cpp-precomp -pipe -I/usr/local/include
-pipe -fno-common -Wno-long-double
Update:
Nat Torkington wrote a test case for the features we're using (compiling
a dynamic library, and compiling an executable that uses that library),
which I've attached. The test case works, and is fundamentally the same
as what Parrot is doing. I've been stepping through the differences
The attached patch allows 'make' to complete on my OS X box, and passes
'make test'. It gets a segfault when running 'make perl6', at the point
where it runs 'pbc_to_exe perl6.pbc'. The segfault appears to be a
standard GC-style error attempting to access reclaimed memory, and not
related to
Andy Dougherty via RT wrote:
+
+unless osname == 'darwin' goto not_darwin
+ link .= '-undefined dynamic_lookup '
+not_darwin:
+
I understand and sympathize with wanting to just get past this problem,
but this looks to me like layering more magic to undo the bad magic
applied
It also works as a shared binary if I append the following to the
compile line (pretty much exactly the contents of $O_FILES in the Makefile):
c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib
-L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib
From http://osdir.com/ml/lib.libtom/2005-01/msg00010.html:
By default common symbols are not included in static
archive table of contents. If you use the ranlib(1) -c
option you can get Linux behavior.
And from 'man ranlib' on 10.4.11:
-c Include common symbols as definitions with respect
On Tue Jan 22 15:38:11 2008, [EMAIL PROTECTED] wrote:
Are you building a static or a shared binary? Did this problem only
show up after Coke switched the default to shared?
Shared. I don't know the exact timing of the change in relation to the
failure starting. But, changing
chromatic via RT wrote:
Does this happen after a 'make realclean' and recompilation?
In fact, it only happened when I ran 'make realclean' and recompiled.
I'd been happily running 'make' with no problems. I was surprised to see
the error pop up on the pdd17pmc branch after I merged, so went
chromatic wrote:
On Friday 18 January 2008 20:25:16 Allison Randal wrote:
It's true that the generalized solution for varying callback signatures
doesn't exist yet, but it's easy enough to create your own C callback
layer, with a separate C function for each callback you need. (Note, not
one
chromatic wrote:
Here's my crazy idea.
When you register a callback into PIR from C, you need to pass a few
arguments: the interpreter into which to call, the PMC Sub to call, and the C
signature of the C function which gets called from C.
I presume that the PIR function will get called
I've launched the GC PDD out of draft. Comments and suggestions welcome.
Allison
Looks good. I'm surprised some of those are still used. do_init_call,
get_init_meth, Parrot_single_subclass, Parrot_class_lookup, and
Parrot_class_lookup_p are all part of the old implementation. Oh, I see.
Parrot_class_lookup and Parrot_class_lookup_p are only used by the
deprecated getclass
Geoffrey Broadwell wrote:
On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote:
I am starting to implement a GLUT and OpenGL binding for Parrot.
[...]
I don't often get concentrated time
to help out with Parrot and Perl 6, but I have some now. If this is
going to be blocked indefinitely, my
Simon Cozens wrote:
I think this means we need a strings programming PDD. If this is a
good idea, I'll write one, but I will need help.
But really, really, I honestly think we need to start sorting this
out early, before it becomes endemic and we get so stuck in the *s++
mindset it's
Cleaned up copyright, after talking to Gregor (who is sending in a
signed contributor agreement). Resolved in r24885.
Klaas-Jan Stol wrote:
Was there a programming perl book for Perl 1? Or any other books?
For now I'm kinda stuck, because I don't know the exact semantics of each
construct of Perl 1.
I ran into the same thing. The first edition of Programming perl
wasn't until Perl 4. The best you're going
Klaas-Jan Stol wrote:
Unless I misunderstood the Yacc/bison manual, the /order/ in which the
operator associativity is declared, defines the precedence, from top to
bottom in increasing order. So:
%left '+' '-'
%left '*' '/' '%'
means that *, / and % take precedence over + and -.
Aye, but
Supplied through 'inspect' and 'inspect_str' vtable functions.
All PDD tickets and all found design tickets moved to Launchpad. Please
submit design requests to https://blueprints.launchpad.net/parrot/.
chromatic, go ahead and apply this in the pdd17pmc branch. Was already
updated in docs/dev/pccmethod.pod. I'm noting the change in DEPRECATED.pod.
General idea approved, pending review of implementation changes.
On Mon Oct 22 09:34:51 2007, ptc wrote:
In src/pmc/default.pmc:get_attr_str() there is the todo item:
/* let's look for props first
* XXX do we need that in the default object system?
We require an answer to this question, and quite possibly further
development depending upon the
In the old METHODs I'm converting on the pdd17pmc branch, a number of
them have a void return signature (now simply no return value), and use
void returns to bail out early on exceptional conditions. As in:
if (!foo)
return;
But, PCCMETHODs don't currently provide a way of handling
[EMAIL PROTECTED] wrote:
A possible scheme might be a directory hierarchy matching the OS/CPU
combination, e.g. Linux/x_86, Linux/i_64, Solaris/Sparc, containing dummy
files whose names match the processes NOT to be run for that environment.
(The precise structure would depend on which
Rafael Garcia-Suarez wrote:
That assumes that tests are skipped per file, which is not always the
case (sometimes you want to skip only one test, sometimes even to work
around an OS bug that appears only in one specific version). But
reorganizing platform-dependent tests might be a good idea.
Gabor Szabo wrote:
[darwin]
t/pmc/foo.t 3 5-7 9 # platform doesn't support libfoo
t/pmc/bar.t 1 42
...
This seems to be too obvious to be a real question but what if someone
adds a new test
in the middle of bar.t ?
Will she have to remember to update the numbers in the central config file?
In the Python test suite, there's a single global location to declare a
list of test files that are expected to be skipped on a particular
platform. This has a much cleaner feel than our own motley collection of
skip and todo markers in various test files.
Something to consider after the 1.0
Klaas-Jan Stol wrote:
- Update all method definitions in all PMCs to be PCCMETHODs instead of
METHODs.
To allow for a standard deprecation cycle, we're breaking it into two
stages: first update all method definitions and calls so they use the
standard form currently flagged with
chromatic wrote:
Regarding the function signatures in the vtable section: these should match
the calling conventions in PDD 07. I'm happy to patch them.
Go for it.
Regarding the mark vtable entry:
This method does not have
to call the mark method on any PMCs it marks--the
Bram Geron wrote:
The simplest thing I can imagine to create CL/Perl behavior is to
initialize $P0 with nil/undef. But it Doesn't Feel Right(tm) to me doing
this every time. What's your opinion?
Other question: what should compilers do for languages that don't
support multiple values? If such
James Keenan via RT wrote:
FWIW: This test was consistently passing for me on Linux up thru Dec
29. Along with several other tests, it was failing for me on Linux on
Dec 31 -- but it was *not* hanging and preventing 'make test' from
proceeding. That hanging began yesterday (Jan 3) and has
chromatic wrote:
This bug is the primary thing I've been
working on the past couple of days, and I'll let you know when I check
in a fix for you to test.
I've checked in an update that fixes two bugs. Jim, please let me know
if these fixes resolved the persistent hang.
There are,
Andy Lester wrote:
I've started a wiki page for problems with builds/tests that are known
to be problems.
http://www.perlfoundation.org/parrot/index.cgi?build_status
This way we have a canonical place to look, rather than wondering Hmm,
did this t/stm/*.t file pass before, or did I break it?
Agreed that PCCMETHODs need to be optimized, and they will be. (One of
the first optimizations will be making it so a PCCMETHOD call doesn't
have to check whether it's calling an old METHOD.)
But the old METHODs aren't sufficient to support the dynamic languages
we're targeting. They don't
James Keenan via RT wrote:
The test file itself has not been substantively changed in several
months, so it's not the test itself that's causing the problem.
It's been doing this off and on for months. It's intermittent. If you
kill the test, and run it again, it'll pass.
(That said, I'm
François and I have been writing over each other's commits on
src/atomic/gcc_x86.c, so before I edit again, let's figure out the right
way to edit.
Andy, the headerizer dies with an error when src/atomic/gcc_x86.c has
two functions that are marked with both PARROT_API and PARROT_INLINE. Am
I
James Keenan via RT wrote:
What is very puzzling to me is that after 'make realclean;svn update',
it's continuing to fail on my Debian server, but it's passing on an
Ubuntu box. I've never had a test results discrepancy between the two.
What version of Debian? I can set up a chroot instance
chromatic wrote:
Conjecture: the number of cores/processors/available threads between in the
various machines differs.
That does play a part in this particular bug. Though, I'm getting
intermittent hangs on a dual core Mac and a single core Ubuntu box.
Allison
Alan Rocker wrote:
I've attached a quickie shell script, in case that's what you want. It's a
naive little thing, but I think you'll be amused by its presumption.
Good start. Committed in r24479, with a small change to run it from the
top-level directory instead of tools/dev. A little extra
James E Keenan wrote:
For portability reasons, however, shouldn't it be converted to Perl 5? I
don't think we proceed on the assumption that all our target OSes can
handle shell.
The difference here is that you can only generate Debian packages on a
Debian-based system, so portability to
Allison Randal wrote:
Thanks all for the reports. I see two common trouble spots in hellgrind
and the test output. One is a possible race condition if two threads add
tasks to the concurrency scheduler at exactly the same moment. The other
is the fact that PCC uses globals in the interpreter
Thanks all for the reports. I see two common trouble spots in hellgrind
and the test output. One is a possible race condition if two threads add
tasks to the concurrency scheduler at exactly the same moment. The other
is the fact that PCC uses globals in the interpreter to store invocation
Now correctly adds debian_packaging_guide.pod to the MANIFEST. New
directory structure good. Resolving.
Allison
Andy Lester wrote:
It
says that time_struct below is not initialized before use, and I sure
don't see that it isn't.
Was an incorrect change, now reverted.
Allison
In the concurrency work I'm about to check in, I have some tests that
fail intermittently because they test for something like:
1
alarm1
2
alarm2
3
alarm3
alarm1
alarm3
4
alarm3
alarm3
alarm3
5
done.
When the actual output is something like:
1
2
alarm1
3
alarm2
4
alarm3
alarm1
5
alarm3
done.
Just an FYI that intermittent test failures are to be expected after
r24346 in the following files:
t/pmc/nci.t 1 256651 50
t/pmc/task.t1 256 31 3
t/run/options.t 1 256261 23
t/stm/basic_mt.t3 768 4
Ovid wrote:
I got this error on the latest version from svn:
parrot $ perl Configure.pl
Base class package Parrot::Configure::Compiler is empty.
(Perhaps you need to 'use' the module which defines that package
first.)
at lib/Parrot/Configure.pm line 44
I have the same problem,
Patrick R.Michaud (via RT) wrote:
Currently the most frequently asked question (by far) about perl6
is how can I just get an executable that I can use to run Perl
6 programs?
At present this isn't possible, the best we can offer is
/path/to/parrot/parrot
Will Coleda wrote:
Yes, it would be specified as Int/Str/Num in the signature. But
then invoking the multi with an I register or integer constant
should recognize 'Int' as being a match, and not just 'Integer'.
My concern here is HLL interop. I think it would be cleaner to specify
the base
Patrick R.Michaud (via RT) wrote:
Whenever a PAST::Op node gets a non-PAST child, PCT currently
throws a cryptic exception message like:
Method 'named' not found for invocant of class 'Perl6::Grammar'
A better exception message would be something like:
Perl6::Grammar (2) child of PAST::Op
Bob Rogers wrote:
The attached patch adds decoding of call/return registers to the
disassembler, and also fixes a segfault; both are byproducts of a long
and otherwise fruitless debugging session. Please let me know what you
think.
Looks good. Go ahead and commit. Better abstraction for
Klaas-Jan Stol wrote:
Earlier I read over this, thinking: there's probably a good reason for that
(the need for being contiguous), but I haven't figured it out yet.
For sake of documentation, could you please explain why this is so?
so, why would it not be possible to write this:
sub foo
Andy Lester wrote:
What about when you want to implement things like, element -1 gets the
last element of the array? That's the case in some languages, I
believe...
Yes, but we're talking about returning the number of elements in a PMC.
That should never be negative.
Unless someone
Klaas-Jan Stol wrote:
In order to solve that, adding a :invocant('any') (* a special marker would
be more convenient, maybe someone would like to define a class 'any' (you
never know :-) but that's beside the pointnow *)
By adding these markers, what effectively happens is that all :invocant
chromatic wrote:
Don't reject this out of hand. The C executables generated from pbc2c link
against libparrot, so they have the full Parrot runtime environment
available. Basically, this code replaces src/main.c with src/perl6pbc.c and
a few lines that create a new Parrot interpreter and
Klaas-Jan Stol wrote:
we just removed the .pcc_ prefix... (i know, only from some other
directives...) :-P
anyway, the .invocant, .arg , .result and other directives are grouped
together already by the .begin_call/.end_call directives. IMHO, we don't
need a prefix to indicate such a grouping.
Bob Rogers wrote:
Thought so. I ask because Common Lisp has provision for anonymous
classes, and I was wondering how I might support that some day. But my
interest is just academic curiosity at this point, because I'm (still)
nowhere near implementation.
CLOS dispatches on anonymous
Allison Randal wrote:
.param pmc a :invocant(['Foo'; 'Bar'])
And this has me wondering, for languages that do strict type-checking,
will they want to be able to specify the types of non-invocant
parameters? So, maybe that should be:
.param pmc a :type(['Foo'; 'Bar']) :invocant
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
Agreed. (It's worth noting that the problem existed before :invocant was
added.) Adding :invocant, and giving it a string parameter, means we
could do away with the list of types on the :multi flag (we'd
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
With autoboxing/unboxing, there's not really a need to differentiate
between the PMC Integer/String/Float types and the I/S/N registers.
Coming into this discussion from the middle (and having not read
Klaas-Jan Stol wrote:
I guess you're right :-) I was thinking of ambiguity, like
sub foo :multi(Integer, Integer)
.param pmc i :invocant
.param pmc j
.param pmc k :invocant
end
sub foo :multi (Integer, Integer)
.param pmc j :invocant
.param pmc k :invocant
end
but I guess parrot will see
Bob Rogers wrote:
I notice that this doesn't allow for anonymous classes, since provision
is made only for named classes. Is anonymous class support in prospect?
You can't use an anonymous class as a type for multisub dispatch because
they don't have a name to dispatch on. A case could be
Klaas-Jan Stol via RT wrote:
On Sun Dec 16 21:11:34 2007, coke wrote:
From PDD 19:
NOTE: The use of C:: in identifiers is deprecated.
what exactly does this mean?
I take it that :: can still appear in typenames, as in PAST::Op
Yes, that's still fine. In fact, any character that can be
Patrick R. Michaud wrote:
Optional string parameter to C:namespace : Anytime there's a
namespace or class parameter, I think we have to consider the
possibility of a keyed argument, since the general case is
that namespaces are given by keys, not strings.
Ah, you're reading :namespace as
François Perrad wrote:
In Lua, I started to replace (see r23367) :
[ 'Lua::io' ]
by
[ 'Lua'; 'io' ]
Also a good change. This gains you the benefits of true hierarchical
namespaces, and means that different languages that use different
characters as class name separators can use your
On Fri, Dec 21, 2007 at 01:30:42AM -0700, Kevin Tew wrote:
I've added parsing of :namespace to imcc, now I'm trying to figure out
what I'm suppose to do differently when :namespace is present in a
methods prototype.
I thought I was suppose to add the :method to a namespace, but that
seems to
201 - 300 of 845 matches
Mail list logo
