As noted, the new assembler is now in place. There isn't much
resemblance to the old assembler, excepting the fact that they both
(almost) read the same .pasm files. The new macro syntax is documented
in assemble.pl and can be read with perldoc, but I'll summarize things
later in the message.
The
At 23:25 on 05/31/2002 -, Simon Glover (via RT)
<[EMAIL PROTECTED]> wrote:
> This patch adds tests for the index, depth & intdepth ops, as well
> as adding an extra test for intsave/intrestore.
>
> Simon
Committed, daddio.
--Josh
Nearly two years ago, a great debate was begun on this mailing list about
when to inline code and when not to, as well as the actual merits of
inlining in the first place. I will attempt to summarize here, becuase
this debate was never concluded and we now are at a point where some
things are inl
At 23:25 on 05/31/2002 -, Simon Glover (via RT)
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Simon Glover
> # Please include the string: [netlabs #645]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=645
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #645]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=645 >
This patch fixes a few "No previous prototype..." warnings in
packfile.h, and corr
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #644]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=644 >
This patch adds tests for the index, depth & intdepth ops, as well
as adding an ex
At 4:15 PM -0400 5/29/02, Josh Wilmes wrote:
>At 15:22 on 05/29/2002 EDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> I think we'll be safe using longjmp as a C-level exception handler.
>> I'm right now trying to figure whether it's a good thing to do or
>> not. (I'd like to unify C and Parrot
On Sat, Jun 01, 2002 at 02:20:15AM +0900, Dan Kogai wrote:
> >2) If not, would a Encode::ICU be wise?
> I'm not so sure. But if I were the one to implement Encode::ICU, it
> will not be just a compiled collection of UCM files but a wrapper to all
> library functions that ICU has to offer. I, f
> On Fri, May 31, 2002 at 06:18:55AM +0900, Dan Kogai wrote:
>actually adopted. Useful it may be I found raw ICM too Big and too
>Blue :)
Whats that mean, too Blue? :)
-Melvin
On Saturday, June 1, 2002, at 12:34 AM, Autrijus Tang wrote:
> On Fri, May 31, 2002 at 06:18:55AM +0900, Dan Kogai wrote:
>> As a matter of fact GB18030 is ALREADY supported via Encode::HanExtra
>> by
>> Autrijus Tang. The only reason GB18030 was not included in Encode main
>> is sheer size of t
On Fri, May 31, 2002 at 06:18:55AM +0900, Dan Kogai wrote:
> As a matter of fact GB18030 is ALREADY supported via Encode::HanExtra by
> Autrijus Tang. The only reason GB18030 was not included in Encode main
> is sheer size of the map.
Yes, partly because it was not implemented algorithmically.
Melvin Smith:
# The common way is to define our own INLINE definition and
# have Configure check for it, define it null if needed, and
# conditionally include it into a file as extern if so.
#
# Sounds like a job for. BrentDax++!
We already *have* an INLINE, and it's done with #ifdefs. :^
On Fri, 31 May 2002, Melvin Smith wrote:
>
> The common way is to define our own INLINE definition and have Configure
> check for it, define it null if needed, and conditionally include it
> into a file as extern if so.
>
> Sounds like a job for. BrentDax++!
Also some compilers (like SUN Wor
The common way is to define our own INLINE definition and have Configure
check for it, define it null if needed, and conditionally include it into a
file
as extern if so.
Sounds like a job for. BrentDax++!
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
14 matches
Mail list logo
