On Jan 15, 2004, at 9:52 AM, Dan Sugalski wrote:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
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
opco
Damien Neil <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
>> I don't see any advantage of such a model. The more as it doesn't
>> gurantee any atomic access to e.g. long or doubles. The atomic access to
>> ints and pointers seems to rely on the archit
Chromatic <[EMAIL PROTECTED]> wrote:
> On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
>> I tried that as well, it spits out identical PASM each time but on the
>> odd occasion I need to use CTRL-C to get back to the shell.
> I'm seeing the same thing on Linux PPC -- odd hangs from time to time
I don't know, if we should depend on that, but it would definitely help.
Could some Windows guys have a look at:
http://www.microsoft.com/windows/sfu/
[Interoperability. Integration. Extensibility.]
Windows Services for UNIX (SFU) 3.5 provides the tools and environment
that IT professionals and
On Jan 15, 2004, at 8:26 PM, Benjamin K. Stuhl wrote:
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
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 co
On Thu, 2004-01-15 at 23:26, Leopold Toetsch wrote:
> Could you attach gdb to the hanging parrot?
This time, it's hanging at t/op/00ff-dos.t:
(gdb) bac
#0 0x0fd0e600 in sigsuspend () from /lib/libc.so.6
#1 0x0ff970ac in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x0f
Jeff Clites writes:
> On Jan 15, 2004, at 8:26 PM, Benjamin K. Stuhl wrote:
>
> >Thus wrate Dan Sugalski:
> >>At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
> >>>Short version: I was originally going to argue for fully
> >>>hierarchical namespaces, identified as above, but after turning this
> >>
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Damien Neil <[EMAIL PROTECTED]> wrote:
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic
access to
in
On Jan 15, 2004, at 10:42 PM, chromatic wrote:
On Sun, 2004-01-04 at 12:09, Harry Jackson wrote:
I tried that as well, it spits out identical PASM each time but on the
odd occasion I need to use CTRL-C to get back to the shell.
I'm seeing the same thing on Linux PPC -- odd hangs from time to time
Should a thread function be always non-prototyped or do we allow
prototyped ones too?
On preparing a thread, the parameters of the thread function are
copied/cloned into the new thread interpreter. So I'd like to know,
which registers get the state from the calling interpreter (all or
accordin
At 19:52 -0500 1/15/04, Melvin Smith wrote:
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
I can see some potential problems to solve with regards to some
languages where variables are dynamic and can be "undefined",
such as Perl6, but the optimization would certainly work for
constants in all lan
They're already commited.
On 16 Jan 2004, at 00:21, chromatic wrote:
On Thu, 2004-01-15 at 15:02, Michael Scott wrote:
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
all the pod errors and done a rudimentary html tree.
Do you have patches to fix the errors in CVS or are the
Chromatic <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-01-15 at 23:26, Leopold Toetsch wrote:
>> Could you attach gdb to the hanging parrot?
> This time, it's hanging at t/op/00ff-dos.t:
> (gdb) bac
> #0 0x0fd0e600 in sigsuspend () from /lib/libc.so.6
> #1 0x0ff970ac in __pthread_wait_for_restart
Chromatic <[EMAIL PROTECTED]> wrote:
> This time, it's hanging at t/op/00ff-dos.t:
I've checked in now:
* terminate the even loop thread on destroying of the last interp
* this could help against the spurious hangs reported on p6i
Could you please check if that helps.
Thanks,
leo
Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> If you're thinking about this, then maybe a better heuristic would be
> to group globals into groups that are _only_ referenced within a
> specific scope and fetch them on scope entry and store them on scope
> exit. But then, anything like eval"" o
Maybe we can use someone else's solution...
http://lists.ximian.com/archives/public/mono-list/2003-November/
016731.html
On 16 Jan 2004, at 00:33, Jonathan Worthington wrote:
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 15
I did a little benchmark test today that had some enlightening results.
I'll explain what my goal was, then show you said results, and finally a
patch (not meant to be committed) and the benchmark programs themselves.
I dearly wanted real Continuations to be faster, because I loathe
RetContinuatio
PMCs use Vtables for almost all their functionality *and* for stuff that
in Perl5 term is "magic" (or they should AFAIK).
E.g. setting the "_ro" property of a PMC (that supports it[1]) swaps in
the Const$PMC vtable, where all vtable methods that would change the PMC
thrown an exception.
Or: set
Event handling currently works for all run cores[1] except JIT.
The JIT core can't use the schemes described below, but we could:
1) explicitely insert checks, if events are to be handled
1a) everywhere or
1b) in places like described below under [1] c)
2) Patch the native opcodes at these places
Here's my proposal:
* Basics:
Parrot uses nested hashes for namespaces (like perl does).
The high-level language splits namespace strings using whatever
its separator is ('::', '.' etc) to generate an array of strings
for the namespace lookup.
* Relative roots:
Namespace lookup starts from a
IMHO we need some more information in the ops files:
1) If an INT argument refers to a label/branch destination
2) For the event-checking code
3) For the safe run core
ad 1) e.g.
inline op eq(in INT, in INT, inconst INT) {
inline op eq(in INT, in INT, in_branch_const INT) {
The C translates during
Luke Palmer wrote:
I did a little benchmark test today that had some enlightening results.
First of all: did you compile Parrot optimized?
Because:
I thought the problem might be in the small object allocator,
You actually have a similar thing, but mainly inlined. Object allocation
and DOD need
Tim Bunce <[EMAIL PROTECTED]> wrote:
> Here's my proposal:
> * Basics:
> Parrot uses nested hashes for namespaces (like perl does).
> * Relative roots:
> Namespace lookup starts from a 'root' namespace (think root directory).
> Here the P2 argument holds the root namespace to start the lookup
On Fri, Jan 16, 2004 at 12:49:09PM +0100, Leopold Toetsch wrote:
> Tim Bunce <[EMAIL PROTECTED]> wrote:
> > Here's my proposal:
>
> > * Basics:
>
> > Parrot uses nested hashes for namespaces (like perl does).
>
>
> > * Relative roots:
>
> > Namespace lookup starts from a 'root' namespace (thin
On Thu, Jan 15, 2004 at 06:27:52PM -0500, Melvin Smith wrote:
> At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote:
> >At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
> >>At 15:51 -0500 1/15/04, Melvin Smith wrote:
> >>>Comments & questions welcome.
> >>
> >>Why am I thinking of the "register
hello
i noticed that harry jackson is writing a postgres interface to wrap
the nci functions. i'd like him to show what he's written so far and
give his comments
guess i'm not the only one hoping to test it
LF
At 9:30 AM +0100 1/16/04, Elizabeth Mattijsen wrote:
At 19:52 -0500 1/15/04, Melvin Smith wrote:
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
I can see some potential problems to solve with regards to some
languages where variables are dynamic and can be "undefined",
such as Perl6, but the optim
[EMAIL PROTECTED] (Dan Sugalski) writes:
>if ($foo > 10) {
> print $foo;
>}
> This is mainly because of the possibility of tied or
> overridden namespaces, which would argue for a refetch on each use.
No, come on, Dan. It's far worse than that.
It'll be possible, from Perl-space to o
Tim Bunce <[EMAIL PROTECTED]> wrote:
> Aren't constant strings going to be saved in a way that lets the
> address of the saved string be used to avoid string comparisons?
Constant strings get an entry in the constant_table. So for comparing 2
constant strings of the *same* code segment, strings di
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> +++ nci.pmc 16 Jan 2004 13:29:52 - 1.22
> +STRING* name () {
> +return SELF->vtable->whoami;
All classes inherit the C method from default.pmc.
Did it now work without this addition?
leo
At 12:45 PM -0500 1/15/04, Dan Sugalski wrote:
What I'd like is for a volunteer or two to manage the todo queue.
Nothing fancy, just be there to assign todo list items to the folks
that volunteer, make sure they're closed out when done, and reassign
them if whoever's handling a task needs to bai
At 3:51 PM -0500 1/15/04, Melvin Smith wrote:
While sitting on IRC with Dan and Jonathan discussing how to
optimizer a certain construct with how we handle globals/package
variables, etc. I came to the conclusion that it would be valuable
to not have to fetch each and every global, lexical or packa
At 12:49 PM +0100 1/16/04, Leopold Toetsch wrote:
Tim Bunce <[EMAIL PROTECTED]> wrote:
Here's my proposal:
* Basics:
Parrot uses nested hashes for namespaces (like perl does).
* Relative roots:
Namespace lookup starts from a 'root' namespace (think root directory).
Here the P2 argument h
At 10:40 AM +0100 1/16/04, Michael Scott wrote:
Maybe we can use someone else's solution...
http://lists.ximian.com/archives/public/mono-list/2003-November/016731.html
Could be handy. We really ought to detect a system-installed ICU and
use that rather than our local copy at configure time, if it
At 11:00 PM -0800 1/15/04, Jeff Clites wrote:
A key part of my argument (and it's find if you understood this, and
disagree--just wanted to make sure that it was clear) is that I
think we shouldn't try to do any sort of cross-language unification.
I saw that and wasn't really looking to deal with
Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Dan Sugalski) writes:
>>if ($foo > 10) {
>> print $foo;
>>}
>> This is mainly because of the possibility of tied or
>> overridden namespaces, which would argue for a refetch on each use.
> No, come on, Dan. It's far worse th
At 11:07 AM + 1/16/04, Tim Bunce wrote:
Here's my proposal:
I like it all except for the backlink part, and that only because I'm
not sure the names are right. I'm tempted to use reasonably
unavailable characters under the hood (yeah, I'm looking at NUL
(ASCII 0) and maybe SOH (ASCII 1) for
At 2:37 PM + 1/16/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
if ($foo > 10) {
print $foo;
}
This is mainly because of the possibility of tied or
overridden namespaces, which would argue for a refetch on each use.
No, come on, Dan. It's far worse than that.
At 12:21 AM + 1/16/04, Tim Bunce wrote:
On Thu, Jan 15, 2004 at 05:15:05PM -0500, Dan Sugalski wrote:
At 2:39 PM -0500 1/15/04, Dan Sugalski wrote:
>At 8:31 PM +0100 1/15/04, Michael Scott wrote:
>>Is this relevant?
>>http://oss.software.ibm.com/icu/userguide/formatNumbers.html
>>
>>I'm s
At 3:07 PM +0100 1/16/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
+++ nci.pmc 16 Jan 2004 13:29:52 - 1.22
+STRING* name () {
+return SELF->vtable->whoami;
All classes inherit the C method from default.pmc.
Did it now work without this addition?
Ah, t
At 4:02 PM +0100 1/16/04, Leopold Toetsch wrote:
Honestly an overridden op could insert new rules in the code and
recompile everything. If we have to always check for such nasty things,
then we can forget all performance and optimizations.
That, at least, we don't have to worry about. None of the e
At 3:34 AM -0700 1/16/04, Luke Palmer wrote:
I dearly wanted real Continuations to be faster, because I loathe
RetContinuations. They suck. Honest.
There really ought be no difference between a regular continuation
and a return continuation. (I certainly can't think of a reason they
should be d
At 9:13 AM +0100 1/16/04, Leopold Toetsch wrote:
Should a thread function be always non-prototyped or do we allow
prototyped ones too?
On preparing a thread, the parameters of the thread function are
copied/cloned into the new thread interpreter.
I'm not sure I want to do it that way. (Actually,
At 12:15 PM +0100 1/16/04, Leopold Toetsch wrote:
IMHO we need some more information in the ops files:
1) If an INT argument refers to a label/branch destination
2) For the event-checking code
3) For the safe run core
ad 1) e.g.
inline op eq(in INT, in INT, inconst INT) {
inline op eq(in INT, in IN
At 2:59 PM +0100 1/16/04, LF wrote:
hello
i noticed that harry jackson is writing a postgres interface to wrap
the nci functions. i'd like him to show what he's written so far and
give his comments
guess i'm not the only one hoping to test it
:)
Harry, if you're OK with this, go ahead and chec
On Jan 15, 2004, at 3:33 PM, Jonathan Worthington wrote:
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 15, 2004 8:09 PM
Subject: Unicode, internationalization, C++, and ICU
Now, assuming there's still anyone left reading this
>
>
> This page give instructions for building on Windows--it doesn't seem to
> require installing bash or anything:
>
> http://oss.software.ibm.com/cvs/icu/~checkout~/icu/
> readme.html#HowToBuildWindows
>
> I assume that on Windows you don't need to run the configure script.
>
Thanks for that, I
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:15 PM +0100 1/16/04, Leopold Toetsch wrote:
>>op event_after sleep()
> Works as well. (Though we need to change sleep to wait on an event to
> wake up, but that's separate)
I thought so too. Its mainly a workaround until we have all the events
done,
Well, that's sort of how I imagined this would play out. And from a
code writers ascii-centric outlook I agree it makes sense to have
unicode as a special case brought in only when the pesky data requires
it. What about using the icu api to make things easier when the
formatter changes?
Mike
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:49 PM +0100 1/16/04, Leopold Toetsch wrote:
>>
>>find_global P1, P2 ['global'; 'namespace'; 'hierarchy'; "thingname" ]
> No. The thing will be a separate parameter.
Why? Nested keys get you down the key chain until there is no more key.
This can
On Fri, 2004-01-16 at 01:07, Leopold Toetsch wrote:
> I've checked in now:
>
> * terminate the even loop thread on destroying of the last interp
> * this could help against the spurious hangs reported on p6i
>
> Could you please check if that helps.
Yes, that's better. (Upgrading glibc didn't
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #24922]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=24922 >
We need to revamp the ops file parsers to allow easier addition of
ops metadata and par
Hi,
The attached patch fixes a problem in imcc/TestCompiler.pm which was causing
all imcpasm tests to fail on Win32.
Jonathan
imcpasmtests.patch
Description: Binary data
At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
Event handling currently works for all run cores[1] except JIT.
The JIT core can't use the schemes described below, but we could:
1) explicitely insert checks, if events are to be handled
1a) everywhere or
1b) in places like described below under [
Dan Sugalski wrote:
At 2:59 PM +0100 1/16/04, LF wrote:
hello
i noticed that harry jackson is writing a postgres interface to wrap
the nci functions. i'd like him to show what he's written so far and
give his comments
guess i'm not the only one hoping to test it
Just something to bear in min
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> 2) Those that explicitly check for events
...
> Ops like spin_in_event_loop (or whatever we call it) or checkevent is
> in category two. They check events because, well, that's what they're
> supposed to do. Compilers should emit these with some frequen
Hi,
On cygwin, the final link fails with the following error:-
gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o
blib/lib/libparrot.a -lcrypt
blib/lib/libparrot.a(io_unix.o)(.text+0x87e): In function `PIO_sockaddr_in':
/home/Jonathan/parrot_test/io/io_unix.c:468: undefined reference to
`_ine
At 11:53 AM +0100 1/16/04, Leopold Toetsch wrote:
PMCs use Vtables for almost all their functionality *and* for stuff
that in Perl5 term is "magic" (or they should AFAIK).
E.g. setting the "_ro" property of a PMC (that supports it[1]) swaps
in the Const$PMC vtable, where all vtable methods that
At 5:58 PM +0100 1/16/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'd also like to have the ability to add in some other parameters to
the ops file, so if when we're digging in we could wedge in callouts
that by default are ignored, that'd be great.
Takers wanted. Its ma
At 1:45 PM -0500 1/16/04, Michal Wallace wrote:
On Fri, 16 Jan 2004, Dan Sugalski wrote:
2) Those that explicitly check for events
...
Ops like spin_in_event_loop (or whatever we call it) or checkevent is
in category two. They check events because, well, that's what they're
supposed to do. C
Leopold Toetsch wrote:
> Event handling currently works for all run cores[1] except JIT.
>
> The JIT core can't use the schemes described below, but we could:
> 2) Patch the native opcodes at these places with e.g. int3 (SIG_TRAP,
> debugger hook) cpu instruction and catch the trap. Running the
I've used non-hierarchical file systems in the distant past, and
it wasn't pleasant. I think aliases (symlinks) work much better in
a hierarchy. So do inner packages, modules, and classes, which we
plan to have in Perl 6. And package aliasing will be the basis for
allowing different versions of
On Fri, 16 Jan 2004, Dan Sugalski wrote:
> >I don't understand that part. Why the compiler?
>
> Because we don't have the sort of control of the async environment
> that hardware does to deal with interrupts.
>
> And, realistically, all code has to deal with the possibility of
> interrupts. Even
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtable has a link to the next in
the chain. It *also* means that each call into a vtable function
Michal,
> But rather than always monitoring for that, I'd want
> to register a listener and then have parrot handle the
> polling for me.
This is precisely what's being discussed.
> This is probably a dumb question but: what if signals
> threw exceptions instead?
I'd hope that the event handle
At 3:33 PM -0500 1/16/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for
size:
Vtables are chained. That means each vtable has a link to the next
in the chain. It
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:38 AM +0100 1/16/04, Leopold Toetsch wrote:
>>Event handling currently works for all run cores[1] except JIT.
> What I'd planned for with events is a bit less responsive than the
> system you've put together for the non-JIT case, and I think it'll be
Chromatic <[EMAIL PROTECTED]> wrote:
> Yes, that's better. (Upgrading glibc didn't help -- I was worried that
> this was an NPTL issue that Parrot couldn't fix.)
Cool.
> Now it hangs on t/pmc/timer:
> 0x10090b30 in Parrot_del_timer_event (interpreter=0x10273e88,
Ah yep. When committing the fi
On Fri, 2004-01-16 at 12:42, Leopold Toetsch wrote:
> Ah yep. When committing the first (trial) fix, I thought about such
> a problem, which is related:
> - if it seems to hang on a condition variable (still AFAIK: it shouldn't)
It reminds me of a problem I'm having with MySQL, actually.
> - b
Michal Wallace <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Jan 2004, Dan Sugalski wrote:
>> interrupts. Even if they aren't doing any IO at all they're still
>> potentially watching for keyboard (or other OS-initiated)
>> breaks/interrupts.
> I see your point. In python if you press ^C, it should
> ra
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> 2) Patch the native opcodes at these places with e.g. int3
> I don't think that bytecode-modifying versions should fly; they're not
> threadsafe,
Why? The bytecode is patched by a different thread *if* an event is due
(which
Hi
First of all,
yet_another_shy_lurker++;
> On cygwin, the final link fails with the following error:-
>
> gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o
> blib/lib/libparrot.a -lcrypt
> blib/lib/libparrot.a(io_unix.o)(.text+0x87e): In function
> `PIO_sockaddr_in': /home/Jonathan/parrot_
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
> On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
> >Yes, that's what I'm saying. I don't see an advantage of JVMs
> >multi-step
> >variable access, because it even doesn't provide such atomic access.
You're missing the point of th
I'm attempting to update Configure.pl --help to include all the
options. I parsed the files in config so I reckon I have all the
options, I'd just be grateful if anyone can point out any
misunderstandings. The expnetwork option defines EXP_NETWORKING in
config.h, but this is unused. Should it b
Leopold Toetsch wrote:
> Why? The bytecode is patched by a different thread *if* an
> event is due (which in CPU cycles is rare). And I don't see a
> thread safety problem. The (possibly different) CPU reads an
> opcode and runs it. Somewhere in the meantime, the opcode at
> that memory positi
Hi,
The attached patch adds support to configure for building ICU with MSVC++,
as recommended in:-
http://oss.software.ibm.com/cvs/icu/~checkout~/icu/readme.html#HowToBuildWindows
Unfortunately, the VC++ project/workspace files are missing from our ICU
tree in CVS, see:-
http://oss.software.ibm.
From: "Seiler Thomas" <[EMAIL PROTECTED]>
>
> First of all,
> yet_another_shy_lurker++;
Welcome. :-)
> > On cygwin, the final link fails with the following error:-
> >
> > gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o
> > blib/lib/libparrot.a -lcrypt
> > blib/lib/libparrot.a(io_unix.o)(.
From: "Jonathan Worthington" <[EMAIL PROTECTED]>
>
> The attached patch...
Which I forgot to attach. Sorry.
Jonathan
icuwin32.patch
Description: Binary data
On Jan 16, 2004, at 1:01 PM, Damien Neil wrote:
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Yes, that's what I'm saying. I don't see an advantage of JVMs
multi-step
variable access, because it even doesn't provide such atomic ac
On Jan 16, 2004, at 1:20 PM, Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
2) Patch the native opcodes at these places with e.g. int3
I don't think that bytecode-modifying versions should fly; they're not
threadsafe,
Why? The bytecode is patched by a d
On Friday, January 16, 2004, at 02:58 , Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Damien Neil <[EMAIL PROTECTED]> wrote:
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any ato
On Friday, January 16, 2004, at 08:38 , Jeff Clites wrote:
On Jan 16, 2004, at 1:01 PM, Damien Neil wrote:
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Yes, that's what I'm saying. I don't see an advantage of JVMs
multi-step
82 matches
Mail list logo
