mrnobo1024 (via RT) wrote:
# New Ticket Created by mrnobo1024
# Please include the string: [perl #18876]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18876 >
Currently imcc.y has a label called "OUT"
Thank you,
appli
I've renamed the brainfuck directory to bf, per Dan's request.
I _did not_ do the usual magic I do to keep both the old and new names
valid.
Thus - according to CVS, the brainfuck directory never existed, only
one called bf.
I updated the MANIFEST, but did not update anything else.
-R
--
# New Ticket Created by mrnobo1024
# Please include the string: [perl #18876]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18876 >
Currently imcc.y has a label called "OUT" in the command-line argument
parsing code. This
At 11:16 AM -0800 12/4/02, Michael G Schwern wrote:
On Wed, Dec 04, 2002 at 02:03:06PM -0500, Dan Sugalski wrote:
>> DOS isn't an intended compilation target, no.
>
>Not even djgpp?
Hadn't planned on it. What advantage does it give over windows?
It'll compile C programs on a 386/SX, 20M of
On 12/4/02 2:16 PM, Michael G Schwern wrote:
> On Wed, Dec 04, 2002 at 02:03:06PM -0500, Dan Sugalski wrote:
DOS isn't an intended compilation target, no.
>>> Not even djgpp?
>>
>> Hadn't planned on it. What advantage does it give over windows?
>
> It'll compile C programs on a 386/SX, 20M o
On Wed, Dec 04, 2002 at 02:03:06PM -0500, Dan Sugalski wrote:
> >> DOS isn't an intended compilation target, no.
> >
> >Not even djgpp?
>
> Hadn't planned on it. What advantage does it give over windows?
It'll compile C programs on a 386/SX, 20M of disk, 4megs of RAM and some
form of DOS.
Dunno
At 10:01 AM -0800 12/4/02, Michael G Schwern wrote:
On Wed, Dec 04, 2002 at 10:32:41AM -0500, Dan Sugalski wrote:
At 6:58 AM -0800 12/4/02, Mr. Nobody wrote:
>There are some files in parrot that have names common in the first 8
>characters. This will cause problems if someone tries to compile
On Wed, Dec 04, 2002 at 10:32:41AM -0500, Dan Sugalski wrote:
> At 6:58 AM -0800 12/4/02, Mr. Nobody wrote:
> >There are some files in parrot that have names common in the first 8
> >characters. This will cause problems if someone tries to compile Parrot on
> >DOS. Is DOS an intended target, or sho
[EMAIL PROTECTED] wrote:
All --
Before I go changing the Jako compiler, I'd like some feedback.
.sub dummy
goto main
_fact:
...
ret
main:
..
call _fact
...
.end
"goto"s to other subs are not subject of address fixup (though this
could be changed).
leo
On Mardi 3 Décembre 2002 23:24, Nicholas Clark wrote:
> The perl foundation was able to provide some grants towards work on
> this project and perl6. However, fund raising wasn't sufficient to
> keep grants going full time.
About two months ago, I asked the perl foundation about the grants, and
K
At 11:41 AM -0500 12/4/02, Andy Dougherty wrote:
On Wed, 4 Dec 2002, Dan Sugalski wrote:
It's not our language to rename, though, so either the creator OKs it
or it goes. If there's an acceptable alternative spelling, we can use
that too.
The web site in the README in the parrot sources use
On Wed, 4 Dec 2002, Dan Sugalski wrote:
> It's not our language to rename, though, so either the creator OKs it
> or it goes. If there's an acceptable alternative spelling, we can use
> that too.
The web site in the README in the parrot sources uses 'bf', as does at
least one of the sites refer
If memory serves me right, Leopold Toetsch wrote:
> Yes, but I think, that incompatible changes shouldn't be necessary any
> more - sorry for breaking things.
No problemo ... I just hate working on the same things again ...
> SymReg *r = mk_ident(char *name, char type)
> iANY("add", R3(r0,r
[EMAIL PROTECTED] wrote:
And just ignore the spurrious 'ret' instructions imcc generates to
"properly"
terminate each of the "subroutines" (
These "ret" ins are remnants from the ret => .end change - they will go
away.
leo
All --
Before I go changing the Jako compiler, I'd like some feedback. There are
three files
below. First is fact.jako, the factorial algorithm expressed as a Jako
subroutine with
some mainline code that calls it. Then comes fact.imc, which I produced by
hand-
editing the fact.pasm file that ja
Andy Dougherty (via RT) wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18862]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18862 >
The original style was clearer but this at least comp
Dan Sugalski wrote:
At 9:35 AM +0100 12/4/02, Leopold Toetsch wrote:
Doese odd twiddling include the Buffer/PMC unification?
Yup. This'd be a good time to do that.
So the question is, how should the final "Parrot Object" look like. I
did send a test program on Oct. 25th which got warnoc
Thanks for the tip.
I think I can use that to work around the limitation. It makes it
unnatural to
have a script with the pattern:
some code
some subroutine definitions
some more code, calling the subroutines.
Which Jako permits.
It looks like I can wrap all the bits of miscella
[EMAIL PROTECTED] wrote:
All --
I thought that something like what follows:
goto _foo
end
_foo:
print "Howdy!\n"
end
Works fine *if* you insert your example into ".sub" ... ".end":
..sub _test
goto _foo
end
_foo:
print "ok 1\n"
end
..end
Regards,
-- Gregor
leo
At 6:58 AM -0800 12/4/02, Mr. Nobody wrote:
There are some files in parrot that have names common in the first 8
characters. This will cause problems if someone tries to compile Parrot on
DOS. Is DOS an intended target, or should we not worry about this?
DOS isn't an intended compilation target,
At 9:35 AM +0100 12/4/02, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay, I've finally stopped waffling. The current PMC structure is
now officially frozen, modulo the odd twiddling to it.
Doese odd twiddling include the Buffer/PMC unification?
Yup. This'd be a good time to do that.
...
At 10:26 PM -0800 12/3/02, Brent Dax wrote:
Andy Dougherty:
# On Thu, 21 Nov 2002, Leon Brocard wrote:
#
# > ps You might be concerned about the name. Well, CPAN has a module
# >which matches /fuck/ too. However, if everyone really thinks
# >it is a problem, I don't see a problem with s/fu
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> ..sub main
> ..end
Except without those extra dots. Stupid mailer.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- [EMAIL PROTECTED] wrote:
> I thought that something like what follows:
>
> goto _foo
> end
> _foo:
> print "Howdy!\n"
> end
>
> would be legal imcc input
IMCC requires you to put everything in .subs. So it should be something like
..sub main
goto _foo
end
_foo:
print "H
All --
I thought that something like what follows:
goto _foo
end
_foo:
print "Howdy!\n"
end
would be legal imcc input, but I get:
last token = [(null)]
(error) line 1: parse error
Didn't create output asm.
instead of happiness. I'm trying to learn enough IMCC th
Mr. Nobody wrote:
> There are some files in parrot that have names common in the first 8
> characters. This will cause problems if someone tries to compile Parrot on
> DOS. Is DOS an intended target, or should we not worry about this?
my vote is NO. let us bury 8.3 very, very deep in the ground.
There are some files in parrot that have names common in the first 8
characters. This will cause problems if someone tries to compile Parrot on
DOS. Is DOS an intended target, or should we not worry about this?
/core_ops*.c
/docs/packfile*.pod
/examples/assembly/benchmarks/gc*.pasm
/icu/source/dat
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18862]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18862 >
Without the following patch, Sun's cc compiler complained:
"jit.c", line 504: non-con
On Tue, 3 Dec 2002, Brent Dax wrote:
> Andy Dougherty:
> # Well, I'll speak up. I find the name needlessly crude and
> # offensive. I see no reason to use such a name and would
> # strongly prefer that Parrot didn't. Parrot is a collective
> # project representing a community of developers,
Steve Fink (via RT) wrote:
- The .local directive requires a type. I fixed the documentation.
- The lexer allows an optional dot in front of a parrot op or
identifier, but then seems to assume that the dot is not there. So I
took it off.
- A few trivial things: parenthesized a macro arg for s
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
Is there any other way to feed imcc code other than via writing to a
file and running it ?...
Not currently.
Dan was saying something like a C interface to IMCC which bypasses the
parser and lexer phases was possible ?
Yes
I agree that it seems wrong to change the name of an already established
language. However, I also don't like the fact that something with the name
"Brainfuck" comes with the core of parrot. What if we moved its
distribution out of CVS and just put it on the webpage, or something of that
nature?
Dan Sugalski wrote:
Okay, I've finally stopped waffling. The current PMC structure is now
officially frozen, modulo the odd twiddling to it.
Doese odd twiddling include the Buffer/PMC unification?
... As such, I've added a
pmc.ops file and I'm starting to add in ops to read and write bits o
33 matches
Mail list logo
