That depends if google properly supports "moderated" newsgroups.
Without knowing what they're doing, it's hard to guess what's going on
or where your message got eaten.
Your message _shouldn't_ show up on google unless it comes through a
proper newsfeed. This might mean that google's upstream (
> Sometimes, if the customer wants to do an audit, we have to process
> over a month's worth, so we are bound by the actual execution
> time of the Perl script and the access time of a Sleepycat (Berkeley DB)
> database. The Perl programs must be able to scale
> with call/message volume, and right
> On a platform with a halfway decent JIT, a pure-PASM implementation
> could be as fast as an op-based one, given liberal use of the non-PMC
> registers. Maybe faster--no need to transcode to ASCII, extract a C
> string, or hack around platform X's quirks. And I'd imagine that the
> Parrot s
Hi Brent,
Welcome back to p6i. ;)
At 08:12 PM 3/9/2004 -0800, Brent \"Dax\" Royal-Gordon wrote:
On a platform with a halfway decent JIT, a pure-PASM implementation
could be as fast as an op-based one, given liberal use of the non-PMC
Agree.
Besides, how fast does your date handling really need t
Edward S. Peschko wrote:
On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote:
Edward,
Want to call strptime? Use NCI. No need for anything new in the core.
That's WHY it's the CORE.
I think there is a misunderstanding here. I don't think that strftime by itself
in the core - which
On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote:
> Edward,
>
> Want to call strptime? Use NCI. No need for anything new in the core.
> That's WHY it's the CORE.
I think there is a misunderstanding here. I don't think that strftime by itself
in the core - which probably has sys
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]
> I don't think optimising for "X" is the reason. Parrot should have
> concise, necessary, complete opcode primitives upon which anything
> else can be built.
how about opcode formatting primitives? That is what I would argue
strftime and relatives are... generic low-level ways of turning strings
At 03:52 PM 3/9/2004 -0800, Edward S. Peschko wrote:
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib
> directory.
fair enough, but then where does the distinction lie? Why put gmtime, et al.
in opcodes? As well
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> 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...
On Tue, 2004-03-09 at 14:42, Aaron Sherman wrote:
> As far as methods go, I would think that the syntax would look exactly
> like method invocation, only you would provide an object on which to
> call the method, no?
Wow, that was a caffine overdose in progress please disregard that
incoherent
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 hogwild with the parsing and for
Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
Must be soemthing wrong here. Output is now totally messed up.
It's possible that your terminal isn't wide enough.
80 columns is wide enough for me ;)
Indeed, something needs to be modi
chromatic wrote:
On Tue, 2004-03-09 at 05:15, Luke Palmer wrote:
-system "$pathes{$names[$i]} $directory/"
- . "$benchmark.$suffixes[$i][$j]"
- . '>/dev/null';
File::Spec has a devnull() method. I'd use that to improve portability,
though
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 the local time zone. y <- 1
> > if Dayli
Leopold Toetsch wrote:
Sebastian Riedel <[EMAIL PROTECTED]> wrote:
The attached patch adds this, conf files now look so:
parrot: /home/sri/parrot/parrot: .pasm .imc
Good.
ruby: /usr/bin/ruby: .rb
python: /usr/bin/python: .py
python-C: /usr/bin/python -C: .py
^
That's
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> While we still need to nail down the final bits of namespace stuff,
> I'm running into the need for it in IMCC code, so its time to finally
> deal with it.
> I don't really care what the syntax looks like, so I'm proposing:
> .namespace [foo; bar; baz
On Tue, 9 Mar 2004, Leopold Toetsch wrote:
> Object instantiation is 40 % of the whole used time. Let's start to
> optimize object layout first.
I think there's definitely the potential for a big speed-up there.
For instance, simply replacing the Array that used to store the
class, classname
As far as methods go, I would think that the syntax would look exactly
like method invocation, only you would provide an object on which to
call the method, no?
Hmmm... I guess that brings up the question of signatures... are
signatures handled at the parrot level or the compiler level?
Pardon my
(
ps - on a side note, is the news gateway through google working in posting
to the list? I tried posting via google, and although it shows up on
google, it didn't show up in the archives...
)
> 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 hogwild with the parsing and formatting
routines, and its a bloodbath of modules on CPAN with diff
The Perl 6 Summarizer wrote:
> Parrotbug reaches 0.0.1
> Jerome Quelin responded to Dan's otherwise ignored request for a
> parrot equivalent of perlbug when he offered an implementation of
> parrotbug for everyone's perusal, but didn't go so far to add it to
> the distribution. I don't think i
Hi all,
The attached file has some helper functions to make object usage easier.
It is used by the new object orientated Data::Dumper implementation as well as
my EBNF parser generator.
I submit it as a standalone library to reduce code duplication. It might also
be useful for other developers t
It also hung for me on test 12 in extend. I opened another window and did
$ kill and it was able to complete the tests.
WinXP - full Cygwin installation up to date
Failed Test Stat Wstat Total Fail Failed List of Failed
---
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.
I don't really care what the syntax looks like, so I'm proposing:
.namespace [foo; bar; baz]
as a way to set the current namespace for subs
On Tue, 2004-03-09 at 05:15, Luke Palmer wrote:
> -system "$pathes{$names[$i]} $directory/"
> - . "$benchmark.$suffixes[$i][$j]"
> - . '>/dev/null';
File::Spec has a devnull() method. I'd use that to improve portability,
though I'm never sure how
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>>
>> Must be soemthing wrong here. Output is now totally messed up.
> It's possible that your terminal isn't wide enough.
80 columns is wide enough for me ;)
> Indeed, something needs to be modified to keep the output to 72 column
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi again,
> I just found another problem related to bytecode switching:
> *** switching to BYTECODE_library/Data/Dumper/Base.imc
> PC=-4501; OP=
Thanks, fixed.
> jens
leo
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Well done, looks really better!
Actually while digging hours through traces of EBNF, I wasn't really
happy with the output, so I changed it ;)
> I noticed that DOD runs are disturbing the output:
>495 null S31 -
>497 set P5, P6 - P5=#
Jens Rieks <[EMAIL PROTECTED]> wrote:
> I noticed that DOD runs are disturbing the output:
I haven't removed it, now it looks like:
2193 setprop P16, ".name", P17- P16=Sub= ...
DOD
2197 branch 14
Here the C did cause a DOD run.
leo
Leopold Toetsch writes:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Here's a patch that prettifies parrotbench's output. It also redirects
> > errors to /dev/null, and replaces them with !!! in the output. The
> > benchmarking program is not the correct place to debug errors.
>
> Must be soemth
Hi again,
I just found another problem related to bytecode switching:
*** switching to BYTECODE_library/Data/Dumper/Base.imc
PC=-4501; OP=
The first shown OP after a switch is always wrong.
jens
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Here's a patch that prettifies parrotbench's output. It also redirects
> errors to /dev/null, and replaces them with !!! in the output. The
> benchmarking program is not the correct place to debug errors.
Must be soemthing wrong here. Output is now totall
Hi,
On Tuesday 09 March 2004 15:55, Leopold Toetsch wrote:
> I've rearranged the output of parrot -t a bit. It should be more
> readable now e.g.:
>
> 0 set P16, P1 - P16=NULL, P1=NULL
> 3 set P17, P5 - P17=SArray=PMC(0x40304908),
> P5=SArray=PMC(0x40304908)
> 6 set I16
I've rearranged the output of parrot -t a bit. It should be more
readable now e.g.:
0 set P16, P1 - P16=NULL, P1=NULL
3 set P17, P5 - P17=SArray=PMC(0x40304908),
P5=SArray=PMC(0x40304908)
6 set I16, P17 - , P17=SArray=PMC(0x40304908)
9 newsub P16, 46, 5715 -
Here's a patch that prettifies parrotbench's output. It also redirects
errors to /dev/null, and replaces them with !!! in the output. The
benchmarking program is not the correct place to debug errors.
Luke
Index: tools/dev/parrotbench.pl
=
Sebastian Riedel <[EMAIL PROTECTED]> wrote:
> The attached patch adds this, conf files now look so:
> parrot: /home/sri/parrot/parrot: .pasm .imc
Good.
> ruby: /usr/bin/ruby: .rb
> python: /usr/bin/python: .py
> python-C: /usr/bin/python -C: .py
^
That's probably parrot-C, anyway:
> Outp
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I've been thinking about vtable and opcode functions written in
> bytecode, and I think that we need an alternate form of sub calling.
> (And yes, this *is* everyone's chance to say "I told you so")
I don't think that calling conventions are actually a pro
1) singleton PMCs like Random or Env got destroyed during DOD runs
2) and a really nasty one:
During (overridden vtable) method calls, the caller doesn't know that a
method is called, so the return continuation in P1 wasn't preserved in
the context - the caller just assumes, that its preserved. N
39 matches
Mail list logo
