t the pobj->cache.foo_val and
PMC_ptr1p/PMC_ptr2v macros ought to be treated as deprecated.
—
Gordon Henriksen
[EMAIL PROTECTED]
[* - Somewhat inadvisedly, I think. UnionVal is 8 bytes on a 32-bit
architecture, but bloats to 16 bytes on a 64-bit architecture. The
generic containers which use
Precedence.
print("day\n" xor "night\n");
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]
Sent: Friday December 10, 2004 13:28
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject
Dan Sugalski wrote:
> Gordon Henriksen wrote:
>
> > So, for GUI events, could calling into parrot and doing the
> > following from the OS event handler work to synchronously dispatch
> > an event?
> >
> > ... parrot-ify a mouse-moved event into $P5 ...
dispatch(in Pevent)
Invokes the registered event handler(s) for Pevent.
Which makes checkevent really this:
polleventq Py
isnull Py, .NO_EVENT
dispatch Py
.NO_EVENT:
—
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
ally
branching mid-expression.
> Given the semi-self-serving nature of these I think some discussion's
> in order first.
Doesn't seem self-serving at all if it helps make common code constructs
more amenable to the optimizer.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
I should point out that I do actually support
calling these events--so long as they're modified to play nice with OS
event loops. Upon reflection, that just requires a means to
synchronously dispatch an event to a handler chain from a C callback.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
Brent 'Dax' Royal-Gordon wrote:
> Gordon Henriksen wrote:
>
> >> Oh, it's worse than thatGUI commands need to be issued
> from the main
> >> thread, at least with OS X. (There's no actual requirement
> as to which
> >> thread
That's really and truly evil. I love it.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
On May 12, 2004, at 09.12, Dan Sugalski wrote:
At 2:59 PM -0400 5/11/04, Gordon Henriksen wrote:
As I pointed out in another post, this doesn't work for integrating
with at least two significant "event sources:" Windows and the Mac
OS. :) UI events need to be handled synch
d?
>
> Yep.
As I pointed out in another post, this doesn't work for integrating with
at least two significant "event sources:" Windows and the Mac OS. :) UI
events need to be handled synchronously on the thread to which they were
delivered, since the GUI APIs are not threadsafe.
of asynchronous
notification. It's far, far below what programmers will expect when
hearing the term "event."
.NET's thread pool is a very close match to what you're discussing. A
.NET "WaitHandle" is almost identical to your event source. (Right down
to the waitone/w
since PMCs have reference semantics). So long as the x=
operators are also available for native types, so that the the same AST
traversal algorithm can work for all register types.
--
Gordon Henriksen
[EMAIL PROTECTED]
On Saturday, April 17, 2004, at 02:17 , Gordon Henriksen wrote:
On Thursday, April 15, 2004, at 02:25 , Jeff Clites wrote:
For Unix platforms at least, you should be able to do this:
executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
That absolutely does not work, as already
(and non-portable) way to do
this on Mac OS X, since Carbon applications need to reliably open the
resource fork of the executable.
—
Gordon Henriksen
[EMAIL PROTECTED]
t this feature won't after all expect /opt/parrot to work after it
was mv'd.
As for the security concerns of trusting anything but one's current
binary*, parrot could adopt a cryptographic solution for verifying
integrity of resource files, if anybody's really all that worri
On Saturday, April 17, 2004, at 10:35 , Gordon Henriksen wrote:
Which suggests to me a linked list of resource resolvers. First one in
the chain to return a file handle to the data or PBC wins. The head of
parrot's own "system" chain would be available to be appended to any
ot
sensible and forward-thinking to me.
Which suggests to me a linked list of resource resolvers. First one in
the chain to return a file handle to the data or PBC wins. The head of
parrot's own "system" chain would be available to be appended to any
other chains that wanted it.
—
(YAY!)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]
> Sent: Thursday March 11, 2004 10:34
> To: [EMAIL PROTECTED]
> Subject: Dates. Or, rather, months
>
>
> Okay, unl
Edward,
Want to call strptime? Use NCI. No need for anything new in the core.
That's WHY it's the CORE.
—
Gordon Henriksen
[EMAIL PROTECTED]
Edward S. Peschko wrote:
> Gordon Henriksen wrote:
>
> > Leave parsing and formatting entirely to libraries.
> > Absolutely no need for that in the instruction set.
>
> well, I have a bit of a problem with that... As it was pointed out
> before, people have gone h
Jared Rhine wrote:
> Gordon Henriksen wrote:
>
> > gmclock(out Nx)
> > UTC clock in seconds since hrs Jan 1, 2000,
> > ignoring leap seconds.
> >
> > tolocal out Nx, out Iy, in Nz
> > x is set to z converted to
Nz = Nz * 60 # = 60 seconds per minute
Nx = Nx + Nz
# seconds
Nz = Py[0]
Nx = Nx + Nz
Leave parsing and formatting entirely to libraries. Absolutely no need
for that in the instruction set.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
On Friday, February 27, 2004, at 12:26 , Andrew Dougherty wrote:
On Fri, 27 Feb 2004, Gordon Henriksen wrote:
inet_pton is preferrable, as it supports IPv6.
That is, inet_pton should trump inet_aton if both are available.
Probably, but that would require testing to see if inet_pton is
e a program which will load the resultant DLL and run all methods
which have a TestCase attribute applied to them.
Am very, very sure of this terminology.
—
Gordon Henriksen
[EMAIL PROTECTED]
Andrew Dougherty wrote:
> On Fri, 27 Feb 2004, Gordon Henriksen wrote:
>
> > On Mac OS X, the preferred technique would be to weak link with
> > inet_pton and test for its availability at run-time. (inet_pton is
> > not available on 10.1, but is available on 10.3.) Th
another case
entirely.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Andrew Dougherty [mailto:[EMAIL PROTECTED]
> Sent: Friday February 27, 2004 11:52
> To: Perl6 Internals
> Subject: [PATCH] Configure test for inet_aton
have inet_pton?
(Sorry if this has already been discussed; catching up after being out
of down.)
Early versions of Mac OS X do not have inet_pton.
—
Gordon Henriksen
[EMAIL PROTECTED]
't block parrot until completion;
another thread might try to allocate memory before checking events.
Neither is insurmountable.
—
Gordon Henriksen
[EMAIL PROTECTED]
Leopold Toetsch wrote:
Gordon Henriksen wrote:
The patch is at the URL below, and I've split it into 4 for you. The
classes-include-lib patch must be applied before any of the other 3.
I've resolved the 3-4 conflicts that occurred since the patch was first
I've applied now
t's because the union contains two 16-byte
structs (64-bit ptr + 64-bit ptr = 128-bit struct = 16 bytes).
Shouldn't be any padding in UnionVal unless there's a 32-bit
architecture out there that wants to align 32-bit values to 64-
bit boundaries...
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
ked out when it didn't show up pronto.
—
Gordon Henriksen
[EMAIL PROTECTED]
, offsetof(struct xt, z));
return 0;
}
Mac OS X output is:
x : 0
i : 4
j : 8
z : 12
—
Gordon Henriksen
[EMAIL PROTECTED]
ccess to UnionVal in
general, since it was sometimes used outside of the context of a
pobj. [*]
The old syntax continues to work, and so nobody's patches will break
excl. those w conflicts. But the pobj->cache.foo_val and
PMC_ptr1p/PMC_ptr2v macros ought to be treated as deprecated.
Larry Wall wrote:
> Gordon Henriksen wrote:
>
> > I've submitted a patch to bugs-parrot, and it didn't seem
> > to get posted to RT or otherwise handled. Anyone know where it
> > might've gone?
>
> Did it have an executable attachment? :-)
Thanks
I've submitted a patch to bugs-parrot, and it didn't seem to get posted
to RT or otherwise handled. Anyone know where it might've gone?
<http://www.parrotcode.org/openpatches>
http://www.parrotcode.org/openpatches isn't working ("ERROR RETRIEVING
DATA")
tenured; this leaves the
nursery fragmented and complicates the very hot allocation code path.
Then there's the whole "PMCs don't move" guarantee. And there's also the
conservative tracing of system areas.
—
Gordon Henriksen
[EMAIL PROTECTED]
[1] To be that simple, all
Dan Sugalski wrote:
> And pointless. Let's just rename it to Parrot_Interp everywhere.
I've submitted a patch for this already.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
Leopold Toetsch wrote:
> Gordon Henriksen wrote:
>
> > Or, hell, put the flags directly in the VTABLE if it's not
> > necessary for them to vary across instances.
>
> No, flags are mutable and per PMC *not* per class.
Of course there are flags which must remain p
Leopold Toetsch wrote:
> Gordon Henriksen wrote:
>
> > ... in the multi-thousand-
> > line-diff it was, yet. :( Else you'd have the patch already
>
> 1) *no* multi-thousands line diffs
> 2) what is the problem, you like to solve?
Er? Extending to the rest of t
Dan Sugalski wrote:
> Gordon Henriksen wrote:
>
> > Leopold Toetsch wrote:
> >
> > > Gordon Henriksen wrote:
> > >
> > > > ... Best example: morph. morph must die.
> > >
> > > Morph is necessary. But please note: morph changes th
On Thursday, January 29, 2004, at 11:55 , Melvin Smith wrote:
At 11:45 PM 1/28/2004 -0500, Gordon Henriksen wrote:
On Wednesday, January 28, 2004, at 12:53 , Melvin Smith wrote:
At 12:27 PM 1/23/2004 -0800, Damien Neil wrote:
Java Collections are a standard Java library of common data
On Thursday, January 29, 2004, at 09:12 , Matt Fowles wrote:
I have been getting out of order messages from this list for months...
I just assumed that the internet was a mysterious thing...
Methinks the list is also manually moderated
—
Gordon Henriksen
[EMAIL PROTECTED]
mistake of automatic synchronization
with their original set of collections (incl. Vector). It was a major
design flaw, crippling the performance of early Java programs. Fixing it
for Java 2's class library was quite non-trivial, but because the VM was
powerful enough to allow it, more efficient unsynchronized collections
could be made available as a class library even for the earlier Java VMs.
—
Gordon Henriksen
[EMAIL PROTECTED]
Seiler Thomas wrote:
Gordon Henriksen wrote:
The Parrot_INTERP type from embed.c and embed.h serves no purpose.
[linking failures...]
mem_alloc_executable
mem_free_executable
mem_realloc_executable
[...]
Re-ran Configure.pl and these went away, in case anyone else has this.
inet_pton
Is a IPv6
On Sunday, January 25, 2004, at 07:08 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Speaking of cleaning and uniting, what is with this?
#define bufstart obj.u.b.bufstart
#define buflen obj.u.b.buflen
These are *currently* necessary macros, until the PMC/PObj lay
On Sunday, January 25, 2004, at 06:42 , Michael Scott wrote:
I see that t/src/io is now failing on OS X 10.3.2. Is anyone else
seeing this on another system?
Also on 10.1.5.
—
Gordon Henriksen
[EMAIL PROTECTED]
mples/benchmarks. If those programs are not at
all realistic, then more realistic benchmarks should be added.
Would be nice if there were a convenient way to run the lot of them and
collect the timing information, though.
—
Gordon Henriksen
[EMAIL PROTECTED]
On Sunday, January 25, 2004, at 03:44 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
All embedders see is this:
typedef struct Parrot_Interp *Parrot_Interp;
I don't do decisions on embedding or extending interfaces. But it seems
to be the time to decide (and
.h */
typedef struct Parrot_Interp {
...
} Interp;
—
Gordon Henriksen
[EMAIL PROTECTED]
Leopold Toetsch wrote:
Gordon Henriksen wrote:
I overstated when I said that morph must die. morph could live IF:
[ long proposal ]
Increasing the union size, so that each pointer is distinct is not an
option. This imposes considerable overhead on a non-threaded program
too, due its bigger
On Sunday, January 25, 2004, at 06:10 , Michael Scott wrote:
On 25 Jan 2004, at 00:50, Gordon Henriksen wrote:
[...]
Is there something so terribly wrong with English? How about a general
scheme of * ? So, respectively,
MixedArray
Array
FixedArray
StringArray
FixedStringArray
Array is what
ippets will wrap in
some mail programs.
And more than 69 and replies to messages containing patch snippets will
wrap in some mail programs.
ad infinitum...
—
Gordon Henriksen
[EMAIL PROTECTED]
Pete Lomax wrote:
Gordon Henriksen wrote:
It doesn't matter if an int field could read half of a double or v.v.;
it won't crash the program. Only pointers matter.
These rules ensure that dereferencing a pointer will not segfault.
In this model, wouldn't catching the segfault and
eeded opacity guards in place.
—
Gordon Henriksen
[EMAIL PROTECTED]
differentiating just by capitalization.
... okay, I'm beginning to agree with you. There's another name, Interp,
for the same structure, defined in parrot/interpreter.h. That, and
struct Parrot_Interp is a struct while Parrot_Interp is a pointer.
—
Gordon Henriksen
[EMAIL PROTECTED]
t violates my previous pricipal of "most useful = most convenient." I
don't think MixedArray will see much use, so FixedMixedArray doesn't
worry me too much. :)
I would definitely avoid the words mutable/immutable, as that will
certainly be read by many (me :) to pertain to
some
massively recursive algorithm to run at pointer assignment time, just as
the first one didn't require anything more than pointer assignment at
pointer assignment time.) Could probably be simplified with the addition
of pointer type to the definitions section.
Anyhoo.
—
Gordon Henriksen
[EMAIL PROTECTED]
Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
... Best example: morph. morph must die.
Morph is necessary. But please note: morph changes the vtable of the
PMC to point to the new data types table. It has nothing to do with a
typed union.
I overstated when I sai
On Saturday, January 24, 2004, at 09:23 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
... Best example: morph. morph must die.
Morph is necessary. But please note: morph changes the vtable of the
PMC to point to the new data types table. It has nothing to do with a
rmance standpoint. There will be
massive reader contention even on uniprocessors, and the bus pollution
on multiprocessors will be disastrous. Reader-writer locks are more
costly than mutexes.
Can I suggest an algorithm to completely eliminate that reader-writer
lock, replacing it with a form of coordination that's cheaper in
aggregate, and free in the common case? It's not simple, but I'd rather
one elephant than a billion mice. Might help with infant mortality, too.
—
Gordon Henriksen
[EMAIL PROTECTED]
P.S. - morph must die.
where it's going into and falls out of the transient
root set before the DOD traces over to it.
(Worse than that. It could come from any untraced location—or possibly
even be brand new, depending upon memory allocation details.)
—
Gordon Henriksen
[EMAIL PROTECTED]
f the most
performant strategy might differ for uniprocessors and multiprocessors.
—
Gordon Henriksen
[EMAIL PROTECTED]
threading as it is forking.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
dsafe.
+ Lock-free unless ATOMIC_ADD cannot be implemented without a mutex.
- There is copying overhead when the generation is exhausted.
- One could say that the generation is fragmented by garbage.
+ It is no more fragmented by garbage than a GC system which uses a
freelist allocator.
—
Gordon Henriksen
[EMAIL PROTECTED]
g the mark
phase.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
r than it can throw it. A
generational collector is a more likely means by which parrot might
reduce memory-related overhead.
—
Gordon Henriksen
[EMAIL PROTECTED]
On Monday, January 19, 2004, at 06:37 , Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all readers should be blocked as well.
True of non-moving collectors, too. [...]
Some of what I've written up addresse
because there's no real alternative.
But PMC implementations have to fall inside of the trusted environment,
so that's not really a failure. Of course uncooperative code can break
a cooperative algorithm. :)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
's okay. Just a design consequence
worth noting for everyone.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
What if control leaves the current code segment before you finish
patching it?
Ops that can leave the code segment have to explicitely check for
events.
Then no need to patch
X 10.1 does not.
—
Gordon Henriksen
[EMAIL PROTECTED]
ed by the
event receiver.
—
Gordon Henriksen
[EMAIL PROTECTED]
On Saturday, January 17, 2004, at 05:53 , Leopold Toetsch wrote:
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
Other threads than the target could be executing the same chunk of
JITted code at the same time.
No. JITed (and prederefed) code is thread-specific, because register
address
d completely to main memory before the thread blocks. It ensures
that other threads will see changes made by the thread, and visa versa,
so that data protected by the lock is always viewed in a consistent
state. On a PowerPC, the JVM just needs to store all
assigned-but-unstored variables and
t to acquire a lock on the entire
PMC for every read or write. Bye-bye performance: Acquire 2-3 locks to
add 2 PerlInts together? ... Or bad performance and poor concurrency:
Acquire 1 global lock whenever performing any PMC operation.
I'm tired
—
Gordon Henriksen
[EMAIL PROTECTED]
threads than the target could be executing the same chunk
of JITted code at the same time.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
curs. High-priority events are that mechanism
through which the code which will throw the exception can
interrupt normal program execution.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
word (in the interpreter, presumably) will stay in the
L1 or L2 cache, avoiding stalls.
No, it's not zero-overhead, but it's simple and easy enough to do
portably. Crazy platform-specific zero-overhead schemes can come later
as optimizations.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Jeff Clites [mailto:[EMAIL PROTECTED]
> Sent: Thursday January 15, 2004 01:28
> To: Gordon Henriksen
> Cc: [EMAIL PROTECTED]
> Subject: Re: JVM as a threading example (threads proposal)
>
>
> On Jan 12, 2004, at 10:03 AM, Gordon
$sth->bind_col(1, \my $b);
$sth->bind_col(2, \my $c);
while ($sth->fetch) {
print "a: $a, b: $b, c: $c\n";
}
So if you're going to basically go all out in emulating DBI's fetch_*
permutations, don't forget this one. :)
—
Gordon Henriksen
[EMAIL PROTECTED]
r required to transfer the contents of its working copy of
a variable into the master copy or vice versa.
This is very obliquely phrased, but it refers to the register file and
stack frame. Or, since the Java bytecode is stack-based, it refers to
the stack.
—
Gordon Henriksen
[EMAIL PROTECTED]
On Sunday, January 4, 2004, at 01:43 , Dan Sugalski wrote:
At 11:59 PM -0500 1/3/04, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock
On Sunday, January 4, 2004, at 03:17 , Jeff Clites wrote:
On Jan 3, 2004, at 8:59 PM, Gordon Henriksen wrote:
On Saturday, January 3, 2004, at 04:32 , Nigel Sandever wrote:
Transparent interlocking of VHLL fat structures performed
automatically by the VM itself. No need for :shared or lock
te make sense at the end of
the program? I say no based upon precedent; the cost is too high.
—
Gordon Henriksen
[EMAIL PROTECTED]
evel, it can collect garbage cycles even across
app domains (where normal RPC proxies would cause reference cycles).
The .NET design doesn't meet all of requirements Dan set forth, but it's
at least an interesting case study in a successful threading environment
for a high-performance virtual machine.
—
Gordon Henriksen
[EMAIL PROTECTED]
ng inter-thread
synchronization.
—
Gordon Henriksen
[EMAIL PROTECTED]
ort
both models well, and the above line of thought isn't doing threading
justice in my opinion.
—
Gordon Henriksen
[EMAIL PROTECTED]
-grained locks have both been adequately
proven antithetical to what is expected from threads: Lightweight,
low-overhead concurrency. Environment cloning is high-performance, but
high overhead. Fine-grained locks are low overhead, but low-performance.
—
Gordon Henriksen
[EMAIL PROTECTED]
hs that Perl programmers seem to be
willing go to in order to hide a function call or obscure the existence
of an object. :)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
? ".." is shorter than ["", "", ""],
and doesn't suggest to a compiler author's mind "keep a struct { char**;
char*; } around for each symbol reference.")
This would make Dan's example into:
find_global P1, "global.namespace.hierarchy.thingname"
shorthand for:
get_globals Py
find_sym P1, Py, "global.namespace.hierarchy.thingname"
and functionally equivalent to the wildly pedantic:
get_globals Py
find_onesym Py, Py, "global"
find_onesym Py, Py, "namespace"
find_onesym Py, Py, "hierarchy"
find_onesym P1, Py, "thingname"
Spelling aside, anyhow. (e.g., where find_onesym yada might be spelled
set yada[].)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
to work correctly on a "safe" core
but will seg fault on some other. Also, I see no reason not
to use PMCNULL in all cores now.
Okay, lets do this:
Add an isnull branch op:
isnull Px, destination
How about this to test if Px is really null?
null Py
eq_addr Px, Py
nt of PMCNULL, to fire an exception rather than having undefined
behavior?
—
Gordon Henriksen
[EMAIL PROTECTED]
ant load. It can
be checked by the callee with a single string compare instruction (if
the vararg list is actually static). It's easy to reflect, too.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Dan Sugalski [mailto:[E
the version number of any particular
product. -- But maintaining these puts a lot of faith in the library's
author.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
resource consumption. ->visit neatly
enables BOTH resource-consuming, threadsafe serialization AND
zero-resource, blocking serialization.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
core technology is amenable to use by various possible algorithms, and
so deciding upon those algorithms early becomes less vital.
Serialization simply becomes an easier problem with this in place.
I would venture, though, that DoD may well need a separate and heavily
optimized implementation, purely for efficiency's sake.
—
Gordon Henriksen
[EMAIL PROTECTED]
uld loop forever...
- This has a only very slightly stronger requirements than those of a
copying GC.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> * e.g. add_n_i_n => add_n_n_i
> * div_n_ic_n => div_n_nc_n
> * div_n_i_n => set_n_i ; div_n_n_n
> + * ge_n_ic_ic => ge_nc_ic
-+-+
| |
| |
_|_
ood, but either way I'd not wish it on anyone. :)
What's to read?
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
te paths or relative paths, it could easily rotate its
arguments
so the above-mentioned call would become concat_dirnames("/foo", "b").
That would be really silly.
I must agree. The only reasonable results of that are either (a) an
error [""] or (b) "/foo". (I'd go with [b].)
—
Gordon Henriksen
[EMAIL PROTECTED]
1 - 100 of 129 matches
Mail list logo
