Dan Sugalski [EMAIL PROTECTED] writes:
At 6:53 PM +0100 4/8/04, Mark Sparshatt wrote:
I've got a couple of questions about Atrributes in Parrot.
PDD15 says that both classes and objects have a list of attributes and
it is possible to add or remove attributes to a class but not an
object.
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
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 example)
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.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28494
Attached patch:
*
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.
# New Ticket Created by Walter G
# Please include the string: [perl #28426]
# in the subject line of all future correspondence about this issue.
# URL: 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
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
if
# New Ticket Created by Jeff Clites
# Please include the string: [perl #28473]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 as
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]: ***
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 'invokecc'
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
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
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
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
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
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
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
is
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 onebyte
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
some of
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
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
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 currently
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
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 with,
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
# New Ticket Created by Adam Thomason
# Please include the string: [perl #28531]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28531
A handful of // comments are lingering around the tree. Patch fixes them to
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
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
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 +
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
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 for a bit,
I did
Aaron Sherman [EMAIL PROTECTED] wrote:
For example, in Perl5/Ponie:
@names=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,
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 at the top
43 matches
Mail list logo
