Will Coleda <[EMAIL PROTECTED]> wrote:
> What should this PASM sub look like? I tried doing a simple wrapper of
> an existing compiler, ala:
> .sub main
>newsub $P1, .Sub, foo_compiler
^
That has to be "_foo_compiler". Labels used by C et al have to
be global labels.
W
# New Ticket Created by chromatic
# Please include the string: [perl #28134]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28134 >
Hi,
Here's a patch to improve the string exception thrown when subclassing
goes awry.
On Tue, 2004-03-30 at 01:05, Jens Rieks wrote:
> Why are you using an underscore in front of all method and label names? They
> are indicating global labels; it is not necessary to use them for method
> names.
Habit. It's necessary for 'new', but none of the others. I'll change
it.
Allison a
> >about to cvs checkout parrot:
> >/home/perlcvs: no such repository
>
> Ah, that's finally gone away. The repository path is /cvs/publoc.
> What you're using's very old, though there was a temporary symlink in
> for a while.
It's been gone for months and months.
And you mean /cvs/public.
Hi,
has the attached code any errors? It does not work if I split the code into
two files (at ## coro.imc ##) and uncomment the load_bytecode.
jens
Ok. I'm looking at switching tcl over from an interpreter to a compiler.
I'll probably do this by using generating PIR, then doing using the
compile opcode, ala:
.sub main
$P1 = compreg "PIR"
$S1 = ".sub joe\nprint \"Woof\\n\"\n.end\n"
$P2 = compile $P1, $S1
invokecc $P2
end
.end
This
Hi all!
I propose the following because the current IMCC reimplementation seems to
make no progress.
## first part ##
Create a (bytecode) class "PIR" that can be used (by compilers written in
bytecode) as an standardized interface to IMCC.
A first implementation of that class can just create a
[EMAIL PROTECTED] (Leopold Toetsch) writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> Remember how Leo wanted an example of how continuations were used?
>
> Great example - I don't understand how it wotks though :) - but I
> understand, why the PIR code might fail:
>
>> .sub _choose
>
> [ ...
All~
There was some discussion a while ago about having a whole class of
array pmc, some for each type as well as some that auto expand and
others that don't. I am about to go on a trip and will thus have time
on the plane to implement such things; however, I do not recall any
official decisi
At 10:43 PM +0100 3/31/04, Jens Rieks wrote:
Hi,
On Wednesday 31 March 2004 20:42, Dan Sugalski wrote:
*) Get continuations all nailed down. There seems to be some
lingering problems in the system I'd like identified with tests and
fixed
*) Get lexical pad operations spec'd out and possibly wo
Hi,
On Wednesday 31 March 2004 20:42, Dan Sugalski wrote:
> *) Get continuations all nailed down. There seems to be some
> lingering problems in the system I'd like identified with tests and
> fixed
> *) Get lexical pad operations spec'd out and possibly working
> *) Fix hash.c. (Though it may not
Hi,
On Wednesday 31 March 2004 23:27, Tim Bunce wrote:
> Is IMCC method call syntax spec'd, implemented, and reasonably stable?
I think yes. But the method (and sub) declaration stuff needs a bit work.
For example, you can not declare a "new" or "end" method at the moment.
> Tim.
jens
At 10:27 PM +0100 3/31/04, Tim Bunce wrote:
On Wed, Mar 31, 2004 at 01:42:30PM -0500, Dan Sugalski wrote:
Or something equally manager-speaky.
It's time to be looking towards a 0.1.1 release. There's been some
overhaul of the internals and fleshing out of some features, so I
think we're well-w
At 10:59 PM +0200 3/31/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Or something equally manager-speaky.
Ok all ...
*) Fix hash.c. (Though it may not be broken. Signs are good, though)
which indications do you have that something is broken here?
I'm not sure, but folks have
On Wed, Mar 31, 2004 at 01:42:30PM -0500, Dan Sugalski wrote:
> Or something equally manager-speaky.
>
> It's time to be looking towards a 0.1.1 release. There's been some
> overhaul of the internals and fleshing out of some features, so I
> think we're well-warranted to be thinking about anothe
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Remember how Leo wanted an example of how continuations were used?
Great example - I don't understand how it wotks though :) - but I
understand, why the PIR code might fail:
> .sub _choose
[ ... ]
> store_lex 1, "cc", P1
You aren't allowed to do
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Or something equally manager-speaky.
Ok all ...
> *) Fix hash.c. (Though it may not be broken. Signs are good, though)
which indications do you have that something is broken here?
leo
Or something equally manager-speaky.
It's time to be looking towards a 0.1.1 release. There's been some
overhaul of the internals and fleshing out of some features, so I
think we're well-warranted to be thinking about another point
release. What I'd like to do this time is:
*) Get continuation
Remember how Leo wanted an example of how continuations were used?
Well, I ported the following Scheme code to PIR. (The PIR is appended
to this message...
;;; Indicate that the computation has failed, and that the program
;;; should try another path. We rebind this variable as needed.
(de
Dan Sugalski wrote:
> That'd be about three to four for the CPU you've got, and when you
> throw in swapping I can see the compile time for that module hitting
> 15-20 minutes.
At least. FYI, I ran into the same problem some months ago. I had 128 Mb
on my P4 1.3GHz Linux box. The total compile ti
At 7:01 PM +0200 3/31/04, K Stol wrote:
hi,
I have trouble compiling the current distribution of parrot.
I checked it out from cvs, that didn't work, so I decided to
download a snapshot (latest, 31/3).
Compiling on my winXP computer is going ok (P3/450mhz), but while
compiling on my linux
serve
hi,
I have trouble compiling the current distribution of parrot.
I checked it out from cvs, that didn't work, so I decided to download a
snapshot (latest, 31/3).
Compiling on my winXP computer is going ok (P3/450mhz), but while
compiling on my linux
server (amd k6-2/233 mhz), it hangs on core_o
Nick Kostirya <[EMAIL PROTECTED]> wrote:
> Another question.
> Do enable link with PTH into config/init/hints/netbsd.pl for NetBSD 1.x
> always or only in the presence PTH, or to build without threads by default?
If we get it running with PTH and PTH is there, we should enable it.
> Nick.
leo
> On Wed, Mar 31, 2004 at 01:54:35PM +0200, Leopold Toetsch said:
> > > Probably select have been called without timeout.
> >
> > Yes that's true. But the event thread wakes up the io_thread (s.
> > stop_io_thread). This seems to fail with PTH as it doesn't preempt.
> >
> > Looking at the code, thi
> >> Could you attach a debugger and look, where it hangs?
>
> > nick_vm: {93} gdb ./parrot
>
> Please try this:
>
> $ parrot hangs.pasm
>
> [ second console ]
> $ ps axw | grep [p]arrot
> $ gdb parrot
> gdb> thread 1
> gdb> bac
> gdb> thread 2
But gdb on NetBSD don't support threads.
nick_vm:
On Wed, Mar 31, 2004 at 01:54:35PM +0200, Leopold Toetsch said:
> > Probably select have been called without timeout.
>
> Yes that's true. But the event thread wakes up the io_thread (s.
> stop_io_thread). This seems to fail with PTH as it doesn't preempt.
>
> Looking at the code, this seems to h
At 4:31 PM -0500 3/30/04, Abhijit A. Mahabal wrote:
Tinderbox "aniani" is not working with the latest copy. I checked the
other boxes and they seem fine.
Part of the log:
==
about to cvs checkout parrot:
/home/perlcvs: no such repository
Ah, that's finally gone away. The re
Nick Kostirya <[EMAIL PROTECTED]> wrote:
>> > I have built Parrot on NetBSD with GNU Portable Threads.
>> > All (except SKIP) threads.t tests is successful,
>> > BUT "interp identity" and "thread - kill".
>>
>> > Test "interp identity" sleep perpetual after printing ok1 and ok2.
>>
>> Strange. Actu
> > I have built Parrot on NetBSD with GNU Portable Threads.
> > All (except SKIP) threads.t tests is successful,
> > BUT "interp identity" and "thread - kill".
>
> > Test "interp identity" sleep perpetual after printing ok1 and ok2.
>
> Strange. Actually no PASM thread is started here.
And why GD
Dan Sugalski sent the following bits through the ether:
> "A (Grand?) Unified Theory of Storage Reclamation"
Slides here: http://www.research.ibm.com/people/d/dfb/talks/Bacon04Grand.ppt
Leon
--
Leon Brocard.http://www.astray.com/
scribot...
30 matches
Mail list logo