Melvin Smith <[EMAIL PROTECTED]> wrote:
> Since that is my comment I'll comment.
> When I wrote the allocator, I oriented it around a basic block, and I
> figured a basic block would never have more than a few hundred symbols, so
> the N x N array was the fastest possible data structure for keepi
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> The unmanagedstruct tried to dereference unaligned pointers.
Thanks, applied, as well as #30996, #30100
leo
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> The Float PMC is checking for thruth with the default implemation of
> get_bool()
Thanks, applied.
leo
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #31012]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31012 >
With the perl #30995 we no more need to skip the one subtest
of t/pmc/managestru
The Perl 6 Summary for the six days ending 2004-08-06
Another short week and the rollover point is now set to Friday nights in
preparation for September when I'll almost certainly not have weeknights
free. (Of course, I don't expect the summary will be coming out any
earlier in the
At 1:26 PM +0100 8/9/04, The Perl 6 Summarizer wrote:
Spilling problems
The thing about writing naive compilers for naive languages is you end
up with rather large Parrot subroutines. Dan's work project is
generating ~6000 line subs.
That was only for a program triggering degenerate b
I don't remember if I posted this to the list, but I almost gave a
talk to the Boston ACM on some of the source mangling we do with
parrot's internals back in June. I've annotated the slides and put
the PDF up for folks who might be interested:
http://www.sidhe.org/~dan/presentations/Parrot_Imp
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> With the perl #30995 we no more need to skip the one subtest
> of t/pmc/managestruct.t, at least not on little-endian 64-bit.
> Patch attached.
Thanks, applied.
leo
I'm looking at writing Parrot support for a vendor library: IBM MQ
(Message Queueing, aka "MQSeries", aka "WebSphere MQ"). The current
perl module (which I maintain) uses XS code and Parrot's NCI should
simplify this a lot.
I have two questions though:
- MQ has some data structures that are a ta
On 08/03/04 Leon Brocard wrote:
> IIRC the mono people wrote their own, but with the ICU data files.
> Apart from license issues, this might be an interesting thing to look
> at.
We use some of the ICU data files for locale info like day/month names,
date/time formats etc. We have a tool that take
On 08/09/04 Leopold Toetsch wrote:
> Dan posted some numbers: P 26951, S 2099, I 8878 for "evil program". The
> program dies because of memory shortage when setting up the register
> life information.
Some time ago I used a 16 bit unsigned int to represent virtual
registers in the mono JIT. Well,
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #31018]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31018 >
tru64/alpha gets a core dump at roughly every tenth run of threads6_pasm.
I sus
At 4:40 PM +0200 8/9/04, Paolo Molaro wrote:
If people are interested, we might be able to cooperate to develop a
library which does just that (unicode string collation) and which
could be imported and used both in mono and parrot (with minimal or no
changes).
From the mono point of view, the licen
At 1:13 PM +0200 8/8/04, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
You can verify this step by running -v:
$ parrot -v inv_mod.imc 2>&1 | grep symb
build_reglist: 5783 symbols
allocate_non_interfering, now: 2205 symbols
It really should help.
It did. I'm not sure how long t
Andy Lester wrote:
> t/op/sleep.t doesn't actually check to see how long it's slept for. The
> test takes sleep()'s word for it.
>
> I also modernized it to use Test::More and its convenience functions.
Thanks, applied as change 23206.
Since we're running into Ponie issues with this, which means we'll
run into Apache issues as well as any number of other systems
When Parrot's being embedded I can see the following functions
needing overriding by the embedder:
*) Memory: malloc, realloc, calloc, free
*) Signals: handler re
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #31021]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31021 >
Also the ld needs to be CC -64, duh.
--
Jarkko Hietaniemi <[EMAIL PROTECTED]>
On Mon, Aug 09, 2004 at 08:53:27AM -0400, [EMAIL PROTECTED] wrote:
> - MQ has constants. Thousands of them. In the perl module, these get
> mapped to perl XS subroutines (which bloats the symbol table no
> end). For parrot, I'd prefer to use two big hash tables of the type
As in at load ti
On Sat, 7 Aug 2004, Chia-Liang Kao wrote:
> I've just setup a Subversion mirror of the parrot cvs repository with
> svk. Will try to keep it in sync until Robert have time to do similar
> setup on perl.org.
> So you could now use the Subversion repository (readonly) at:
>
>svn://svn.clkao.org
Since this has been a sore spot lately, and one
we need to deal with. Might as well formally
define what that is.
We must be able to:
*) Load in string data from an IO source,
regardless of its encoding, and treat it as
Unicode string data
*) write string data to an IO source in any Unicode en
On Mon, Aug 09, 2004 at 01:18:32PM -0400, [EMAIL PROTECTED] wrote:
> Not sure. I'm not lookig for advice on evolving this module for
> perl5; it's gross and cumbersome, but I am not about to make deep
> changes to it. I'd much rather do it right for parrot, specially
> since I won't have to supp
On Mon, Aug 09, 2004 at 02:14:46PM -0400, Dan Sugalski wrote:
> We don't care about on-screen rendering or date/time/money formatting.
And whilst every language out there might need these functions available
to its apps, this sounds like a module for the Comprehensive PIR Archive
Network. (ie I a
At 7:17 PM +0100 8/9/04, Nicholas Clark wrote:
The code is messy and needs refactoring so that it can be subclassed to
generate lookup tables that return other sorts of structures, such as
potentially the token lookup in the perl5 core, and the NCI signature
lookup in nci.c, which is currently a li
On Mon, 9 Aug 2004 13:14:26 -0400 (EDT), Andy Dougherty
<[EMAIL PROTECTED]> wrote:
> On Sat, 7 Aug 2004, Chia-Liang Kao wrote:
>
> > I've just setup a Subversion mirror of the parrot cvs repository with
> > svk. Will try to keep it in sync until Robert have time to do similar
> > setup on perl.org
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #31026]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31026 >
Right now the master function in nci.c that figures out if we have a
thunking functi
On Mon, 2004-08-09 at 11:36, Dan Sugalski wrote:
> Right now the master function in nci.c that figures out if we have a
> thunking function for a given function signature does a linear search
> looking for a match. This is pretty nasty and gets slower the more
> functions are in the search list
At 11:57 AM -0700 8/9/04, chromatic wrote:
On Mon, 2004-08-09 at 11:36, Dan Sugalski wrote:
Right now the master function in nci.c that figures out if we have a
thunking function for a given function signature does a linear search
looking for a match. This is pretty nasty and gets slower the mor
hi all...
I've been working on something a bit and wanted to run it by people here to
see if folks think it's a project worthy of persuing. basically the below
bit from the README kinda sums it up for me - locally wrapping lots of
routines is getting quite tedious (specifically sockets at the mom
On Mon, 9 Aug 2004, Bryan Donlan wrote:
> On Mon, 9 Aug 2004 13:14:26 -0400 (EDT), Andy Dougherty
> <[EMAIL PROTECTED]> wrote:
> > On the minus side, it's still slow (initial checkout took 41 minutes,
> > compared to 8 for CVS, though I can't say for sure how much of that was
> > due to the diffe
Geoff,
This sounds like mock objects basically
(http://www.mockobjects.com/FrontPage.html), although maybe on a
smaller/more-directed scale. I do like the idea of building a mock
object repository of sorts, I am sure that would come in handy.
Steve
On Aug 9, 2004, at 3:42 PM, Geoffrey Young wr
At 11:22 AM 8/9/2004 -0400, Dan Sugalski wrote:
At 1:13 PM +0200 8/8/04, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
You can verify this step by running -v:
$ parrot -v inv_mod.imc 2>&1 | grep symb
build_reglist: 5783 symbols
allocate_non_interfering, now: 2205 symbols
It rea
stevan little wrote:
> Geoff,
>
> This sounds like mock objects basically
> (http://www.mockobjects.com/FrontPage.html), although maybe on a
> smaller/more-directed scale.
hrmph. now that you mention it, yeah, it does. and there's already
Test::MockObject (which I've heard about but obviously
--- Geoffrey Young <[EMAIL PROTECTED]> wrote:
> hi all...
>
> from the docs Hook::Lexwrap just seems to be way too much for testing.
Hi Geoff,
What an interesting coincidence. I recently came to the same conclusion, so I uploaded
Sub::Override to the CPAN a few days ago.
http://search.cpan.o
On Mon, 2004-08-09 at 13:12, Melvin Smith wrote:
> DSWEPIC
>
> Dan Stop Writing Evil Pathological Intermediate Code.
Technically, that should be CWSWCTWEPIC, or Compiler Writers Stop
Writing Compilers That Write Evil Pathological Intermediate Code.
Automating the process of shuddering while rea
On Mon, 2004-08-09 at 13:18, Geoffrey Young wrote:
> hrmph. now that you mention it, yeah, it does. and there's already
> Test::MockObject (which I've heard about but obviously haven't actually used
> yet :)
The author is very handsome, too.
> yeah, that was the real goal. perhaps a subclass o
--- stevan little <[EMAIL PROTECTED]> wrote:
> Geoff,
>
> This sounds like mock objects basically
> (http://www.mockobjects.com/FrontPage.html), although maybe on a
> smaller/more-directed scale. I do like the idea of building a mock
> object repository of sorts, I am sure that would come in h
--- chromatic <[EMAIL PROTECTED]> wrote:
> Test::MockObject::Extends comes to mind. It's often what people want
> instead of T::MO. Fortunately, they're in the same distribution.
Sweet. I never noticed that one. That solves a niggling issue I've had with
Test::MockObject.
Thanks!
Cheers,
Ov
At 4:12 PM -0400 8/9/04, Melvin Smith wrote:
At 11:22 AM 8/9/2004 -0400, Dan Sugalski wrote:
At 1:13 PM +0200 8/8/04, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
You can verify this step by running -v:
$ parrot -v inv_mod.imc 2>&1 | grep symb
build_reglist: 5783 symbols
alloc
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #31029]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31029 >
Things like this
(int*)&something_not_int
just aren't cool. The attac
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #31030]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31030 >
We need to provide a way to access and change a class' inheritance
hierarchy. Also,
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #31031]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31031 >
We need a way to get a handle on a class object's namespace or,
alternately, a schem
At 1:52 PM -0700 8/9/04, Jarkko Hietaniemi (via RT) wrote:
Things like this
(int*)&something_not_int
just aren't cool. The attached patch does a horrible hack for
build_nativecall.pl to introduce the necessary temp variables.
With this patch IRIX64 is now passing all but one of the nci.t.
At 12:04 PM -0400 8/9/04, Dan Sugalski wrote:
Since we're running into Ponie issues with this, which means we'll
run into Apache issues as well as any number of other systems
When Parrot's being embedded I can see the following functions
needing overriding by the embedder:
*) Memory: malloc
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #31032]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31032 >
After the [perl #31029] this one failure remains in IRIX64 (big-endian,
intval a
Dan~
On Mon, 9 Aug 2004 17:22:18 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:04 PM -0400 8/9/04, Dan Sugalski wrote:
> >Since we're running into Ponie issues with this, which means we'll
> >run into Apache issues as well as any number of other systems
> >
> >When Parrot's being emb
As has been pointed out to me, we're falling really behind with our
embedding scheme. We have two *big* problems:
1) We've a sane, if unfinished API but no tests (besides Ponie, which
is a bit big) to make sure we actually implement the routines right
and don't mess things up.
2) We're not pre
At 5:44 PM -0400 8/9/04, Matt Fowles wrote:
Dan~
On Mon, 9 Aug 2004 17:22:18 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 12:04 PM -0400 8/9/04, Dan Sugalski wrote:
>Since we're running into Ponie issues with this, which means we'll
>run into Apache issues as well as any number of other sys
These are the details for the encoding API. This is the layer that
mediates between parrot, which sees strings as a sequence of
codepoints, and the low-level buffer, which is filled with bytes.
Note that the charset layer lives above this, but since I've not
finished that part yet I figure bett
Dan Sugalski wrote:
Since we're running into Ponie issues with this, which means we'll run
into Apache issues as well as any number of other systems
When Parrot's being embedded I can see the following functions needing
overriding by the embedder:
*) Memory: malloc, realloc, calloc, free
*)
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #31036]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31036 >
When parrot runs it doesn't strip out the switches that it eats from
the command lin
On Mon, Aug 09, 2004 at 05:47:21PM -0700, Dan Sugalski wrote:
: Parrot needs to strip out all the switches
: it understands from the command line and leave argv[0] as the name of
: the invoked program.
I'd go a bit further and say simply that any unrecognized switch before
the invoked program is
Dan Sugalski wrote:
> There's a GPL COBOL compiler, TinyCOBOL (1).
>
> If anyone wants to take a shot at giving it a
> PIR back end... (And yes, this would actually be
> very useful. Imagine using Parrot as a way to migrate
> legacy COBOL apps to, well, almost anything else.
> This would be a Good
> "DE" == David Essex <[EMAIL PROTECTED]> writes:
DE> Dan Sugalski wrote:
>> There's a GPL COBOL compiler, TinyCOBOL (1).
>>
>> If anyone wants to take a shot at giving it a
>> PIR back end... (And yes, this would actually be
>> very useful. Imagine using Parrot as a way to migrat
> "DE" == David Essex <[EMAIL PROTECTED]> writes:
DE> Uri Guttman wrote:
>> ...
>> what about the runtime libraries for those cobols? i worked on PL/I
>> libraries and they have many similar features to cobol (as pl/i was a
>> genetic monster of cobol/algol/fortran). stuff such as is
54 matches
Mail list logo
