Will Coleda <[EMAIL PROTECTED]> wrote:
> Did the makefile change make it in?
Not the hacks to get it running. As said the way to go is to concatenate
the sources and chain the loadlib _load() functions. This has two
advantages: no platform dependent linker troubles to resolve symbols of
multiple s
Will Coleda <[EMAIL PROTECTED]> wrote:
> Here's an updated version of dynclasses/README that sums up recent
> notes, and PODifies the doc.
Thanks, applied (2nd version).
leo
Matt Fowles wrote:
> Dan~
>
> I know that you are not technically required to defend your position,
> but I would like an explanation of one part of this plan.
>
> Dan Sugalski wrote:
>
>>4) We will *not* use ICU for core functions. (string to number or number
>>to string conversions, for exa
On Apr 12, 2004, at 9:54 AM, Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #28494]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28494 >
Attached patch:
* adds a
Hi,
I am trying to implement the 'eval' macro im Parrot m4. The Parrot m4
interpreter is implemented in PIR. The 'eval' is a simple interpreter for
integer artithmetic and forms thus a micro language within a mini language.
For implementing the 'eval' macro I took following approach:
i. Implemen
# New Ticket Created by Walter G
# Please include the string: [perl #28426]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28426 >
Hi:
I downloaded the latest Parrot distribution via CVS
and installed it on my system. I
On Saturday 10 April 2004 15:13, Leopold Toetsch wrote:
> There is of course still the question: Should we really have ICU in the
> tree. This needs tracking updates and patching (again) to make it build
> and so on.
In the sake of platform independence I'd say to keep it there. It's far easier
i
# New Ticket Created by Jeff Clites
# Please include the string: [perl #28473]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28473 >
Here's a patch to make the location if ICU's data files configurable,
and also to cau
Hi,
I noted two more things connected to ICU building on different platforms.
One thing is that the ICU build process is quite keen on using "gmake" for
building, even localizing it and saying something like
"You must use /usr/local/bin/gmake to build ICU".
On OpenBSD, where I just used "make"
BTW, it doesn't compile on any platform at the moment, after a
realclean on
the first "make" it complains about
../data/locales/ja.txt:15: parse error. Stopped parsing with
U_INVALID_FORMAT_ERROR
couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR
make[1]: *** [../data/out/build/icudt26l_
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> I am trying to implement the 'eval' macro im Parrot m4. The Parrot m4
> interpreter is implemented in PIR. The 'eval' is a simple interpreter for
> integer artithmetic and forms thus a micro language within a mini language.
> Can I use 'invo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 12, 2004, at 9:54 AM, Leopold Toetsch (via RT) wrote:
> It looks very similar to what I had come up with. The only important
> differences are:
> 1) My version handles the case of code points > 0x as well. (The
> string_append_chr function enca
On Apr 12, 2004, at 4:40 AM, Marcus Thiesen wrote:
Another thing, which is not really bad but I run into at the moment is
that on
the system where I run my Cygwin tests the homedir actually is named
"/home/Gerd & Jutta", which are the names of my father and his
girlfriend who
own the machine and
just a confirmation...
my i386 debian linux gives the same error repeatedly after make
realclean,
if i make again, it compiles a broken parrot which fails (too) many
tests...
also it seems (to me) that parrot's configured choice of compiler,
linker, ... is not used in building icu?
does icu ha
At 10:42 AM +0300 4/13/04, Jarkko Hietaniemi wrote:
Matt Fowles wrote:
Dan~
I know that you are not technically required to defend your position,
but I would like an explanation of one part of this plan.
Dan Sugalski wrote:
4) We will *not* use ICU for core functions. (string to number or nu
At 2:54 PM +0200 4/8/04, Stefan Lidman wrote:
>Here's something for someone who wants to dig in a bit and needs a
place to start.
Many, but by no means all, of the ops are JITted right now. There's
code to mess about with the JITting in jit2h.pl. What would be nice
is if there was a way to get a
On Tuesday 13 April 2004 13:28, luka frelih wrote:
> just a confirmation...
> my i386 debian linux gives the same error repeatedly after make
> realclean,
> if i make again, it compiles a broken parrot which fails (too) many
> tests...
>
> also it seems (to me) that parrot's configured choice of co
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This looks quite nice and works as a standalone utility, so I'll put
> it in the repository as build_tools/list_unjitted.pl.
or tools/dev as it isn't quite required for building parrot?
leo
Jeff Clites <[EMAIL PROTECTED]> wrote:
> 1) My version handles the case of code points > 0x as well.
It's simple now to change that code to include this. I've not done it
yet to keep this patch smaller, which includes #28473 too. My version is
just smaller, cleaner, and faster ;)
So config s
On Apr 13, 2004, at 7:18 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
1) My version handles the case of code points > 0x as well.
It's simple now to change that code to include this. I've not done it
yet to keep this patch smaller, which includes #28473 too. My version
i
At 4:26 PM +0200 4/13/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
This looks quite nice and works as a standalone utility, so I'll put
it in the repository as build_tools/list_unjitted.pl.
or tools/dev as it isn't quite required for building parrot?
That works too--I don't
Jeff Clites <[EMAIL PROTECTED]> wrote:
> One other thing occurred to me, to save a few bytes: When upscaling,
> rather than passing clength, we can pass (result->strlen + number of
> bytes left in cstring).
If I read that correctly, s->strlen (or clength) is the desired length.
- on creation a on
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:26 PM +0200 4/13/04, Leopold Toetsch wrote:
>>
>>or tools/dev as it isn't quite required for building parrot?
> That works too--I don't really care as long as it's in. :) If you
> want to move it go ahead, that's fine. (I think I may take a shot at
>
At 5:52 PM +0200 4/13/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 4:26 PM +0200 4/13/04, Leopold Toetsch wrote:
or tools/dev as it isn't quite required for building parrot?
That works too--I don't really care as long as it's in. :) If you
want to move it go ahead, that
On Apr 13, 2004, at 8:35 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
One other thing occurred to me, to save a few bytes: When upscaling,
rather than passing clength, we can pass (result->strlen + number of
bytes left in cstring).
If I read that correctly, s->strlen (or clen
Marcus Thiesen wrote:
. Seems as if something doesn't get cleaned up in icu
with a parrot realclean.
Yep. I've removed cleaning icu from clean/realclean[1].
$ make help | grep clean
...
icu.clean: ...
And there is always "make cvsclean".
Have fun,
Marcus
leo
[1] If anyone puts that in
At 6:22 PM +0200 4/13/04, Leopold Toetsch wrote:
Marcus Thiesen wrote:
. Seems as if something doesn't get cleaned up in icu with a parrot
realclean.
Yep. I've removed cleaning icu from clean/realclean[1].
I think we need to put that back for a bit, but with this:
[1] If anyone puts that in again
Jeff Clites <[EMAIL PROTECTED]> wrote:
> ab\x{212b}de //clength is 12
> --^
> ... end up with is 5 (2 + 1 + 2)
Ok, ok. You are right. As the string goes into constants and isn't
changed, we'll do it right, which is, as metioned,
d + 1 + length_todo
> [Note: _string_upscale is curren
Ok, I'm still lost on the language thing. I'm not arguing, I just don't
get it, and I feel that if I'm going to do some of the things that I
want to for Perl 6, I'm going to have to get it.
On Mon, 2004-04-12 at 11:43, Dan Sugalski wrote:
> Language
>
> *) Provides language-sensitive man
At 1:55 PM -0400 4/13/04, Aaron Sherman wrote:
Ok, I'm still lost on the language thing. I'm not arguing, I just don't
get it, and I feel that if I'm going to do some of the things that I
want to for Perl 6, I'm going to have to get it.
On Mon, 2004-04-12 at 11:43, Dan Sugalski wrote:
Language
=
Dan Sugalski wrote:
> 1) Parrot will *not* require Unicode. Period. Ever.
My old 8MB Visor Prism thanks you.
> *) Transform stream of bytes to and from a set of 32-bit integers
> *) Manages byte buffer (so buffer positioning and manipulation by code
> point offset is handled here)
What's wrong wit
At 12:44 PM -0700 4/13/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
1) Parrot will *not* require Unicode. Period. Ever.
My old 8MB Visor Prism thanks you.
:) As does my gameboy.
*) Transform stream of bytes to and from a set of 32-bit integers
*) Manages byte buffer (so buffer positioni
# New Ticket Created by Adam Thomason
# Please include the string: [perl #28531]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28531 >
A handful of // comments are lingering around the tree. Patch fixes them to use /*
On 12 Apr 2004, at 17:43, Dan Sugalski wrote:
IW: Mush together (either concatenate or substr replacement) two
strings of different languages but same charset
TP: Checks to see if that's allowed. If not, an exception is thrown.
If so, we do the operation. If one string is manipulated the languag
At 10:44 PM +0200 4/13/04, Michael Scott wrote:
On 12 Apr 2004, at 17:43, Dan Sugalski wrote:
IW: Mush together (either concatenate or substr replacement) two
strings of different languages but same charset
TP: Checks to see if that's allowed. If not, an exception is
thrown. If so, we do the ope
On 13 Apr 2004, at 22:48, Dan Sugalski wrote:
Note that the language might be "Dunno". :) There'll be a default
that's assigned to input data and suchlike things, and the language
markers in the strings can be overridden by code.
Would this be right?
English + English = English
English + Chine
At 11:28 PM +0200 4/13/04, Michael Scott wrote:
On 13 Apr 2004, at 22:48, Dan Sugalski wrote:
Note that the language might be "Dunno". :) There'll be a default
that's assigned to input data and suchlike things, and the language
markers in the strings can be overridden by code.
Would this be rig
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> I really see no reason to store strings as UTF-{8,16,32} and waste CPU
> cycles on decoding it when we can do a lossless conversion to a format
> that's both more compact (in the most common cases) and faster.
The default format now isn't UTF8
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:22 PM +0200 4/13/04, Leopold Toetsch wrote:
>>Marcus Thiesen wrote:
>>>. Seems as if something doesn't get cleaned up in icu with a parrot
>>>realclean.
>>
>>Yep. I've removed cleaning icu from clean/realclean[1].
> I think we need to put that back fo
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> For example, in Perl5/Ponie:
> @names=;
> print "Phone Book: ", sort(@names), "\n";
> In this example, I don't see why I would care that NAMES might be a
> pseudo-handle that iterates over several databases, and returns strings
> in the 7
Thanks for your response. I'm not sure that you and I are speaking about
exactly the same things, since you state that the logical extensions, if
not outright goals, of an alternate approach would be an exclusionary
monoculture. I'm not sure that's quite right
On Tue, 2004-04-13 at 15:06, Dan
On Sat, Apr 10, 2004 at 01:49:37PM +0300, Jarkko Hietaniemi wrote:
> >
> > (We've learnt the hard way with Perl5 modules names that more words are good.
>
> And more words that mean something... "Data" ranks right up there as the
> worst possible names for anything.
(Nah, "Sys" and "System" are
A few days ago I briefly discussed with Nicholas Clark (current perl 5.8
pumpking) about making perl5 code forward-compatible with perl6. A
quick look through the mailing list archives didn't turn up anything
obvious, and I don't recall any mechanism being presented in any of the
Apocalypses, so .
On 2004-04-13 at 13:16:02, David Cantrell wrote:
> Perl 6, we are promised, will try to run "legacy" code unchanged. How
> will it spot such legacy code?
My understanding has been that perl6 will assume a program is Perl 5 unless
it sees a Perl 6 keyword such as 'module' or 'class'.
--
Mark
Mark J. Reed wrote:
On 2004-04-13 at 13:16:02, David Cantrell wrote:
Perl 6, we are promised, will try to run "legacy" code unchanged. How
will it spot such legacy code?
My understanding has been that perl6 will assume a program is Perl 5 unless
it sees a Perl 6 keyword such as 'module' or 'c
David Cantrell skribis 2004-04-13 13:16 (+0100):
> Perl 6, we are promised, will try to run "legacy" code unchanged. How
> will it spot such legacy code? Doing this reliably is a hard problem,
> but we can make it easier. I suggest that people put:
> use perl5;
Why change what already works?
On Tue, Apr 13, 2004 at 02:27:08PM +0200, Juerd wrote:
> David Cantrell skribis 2004-04-13 13:16 (+0100):
> > Perl 6, we are promised, will try to run "legacy" code unchanged. How
> > will it spot such legacy code? Doing this reliably is a hard problem,
> > but we can make it easier. I suggest t
I have confused assignement and initialisation in my previous
mail. Because they are two different operations, there is no
problem they have different semantics. A6 described both
operations. It described pairs as arguments used to initialize
parameters and pairs in assignement.
--
stef
Matthew Walton wrote:
Mark J. Reed wrote:
On 2004-04-13 at 13:16:02, David Cantrell wrote:
Perl 6, we are promised, will try to run "legacy" code unchanged. How
will it spot such legacy code?
My understanding has been that perl6 will assume a program is Perl 5
unless
it sees a Perl 6 keywo
Thomas A. Boyer wrote:
Matthew Walton wrote:
That could be problematic, because if Perl 6 sees something like:
my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?
It's going to think 'ahah', perl 5'. Because it doesn't contain any Perl
6 keyword (su
David Cantrell writes:
> A few days ago I briefly discussed with Nicholas Clark (current perl 5.8
> pumpking) about making perl5 code forward-compatible with perl6. A
> quick look through the mailing list archives didn't turn up anything
> obvious, and I don't recall any mechanism being presented
At 4:07 PM +0100 4/13/04, Matthew Walton wrote:
Thomas A. Boyer wrote:
Matthew Walton wrote:
That could be problematic, because if Perl 6 sees something like:
my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?
It's going to think 'ahah', perl 5'. Be
Matthew Walton wrote:
Thomas A. Boyer wrote:
Matthew Walton wrote:
That could be problematic, because if Perl 6 sees something like:
my %myhash;
%myhash{'foo'} = 'bar';
It's going to think 'ahah', perl 5'. Because it doesn't contain any
Perl 6 keyword (such as 'module' or 'class'), as Mark sai
Thomas A. Boyer wrote:
The original question was "how do I label my code as Perl 5?" The
correct answer, according to Apocalypse 1, is to start your source with
"package." If you didn't want to put your code in a package, then start
it with "package main".
The other question was "how do I label
On Tue, 2004-04-13 at 11:16, Thomas A. Boyer wrote:
> Here is the relevant paragraph from the apocalypse:
> I hereby declare that a |package| declaration at the front of a
> file unambiguously indicates you are parsing Perl 5 code. If
> you want to write a Perl 6 module or class, it'll start
On Tue, Apr 13, 2004 at 09:16:21AM -0600, Thomas A. Boyer wrote:
> The original question was "how do I label my code as Perl 5?" The
> correct answer, according to Apocalypse 1, is to start your source with
> "package." If you didn't want to put your code in a package, then start
> it with "pack
56 matches
Mail list logo
