On Mar 9, 2004, at 11:56 PM, Robert Spier wrote:
Edward S. Peschko wrote:
(
ps - on a side note, is the news gateway through google working in
posting
to the list? I tried posting via google, and although it shows up on
google, it didn't show up in the archives...
)
That depends if google
On Sat, 6 Mar 2004, Jared Rhine wrote:
It'd be great, if possible, to get a statement here from the DateTime
group sanctioning one or another particular Parrot clock interfaces as
efficient, complete, and preferred. I haven't poked over to see
if they are chatting about this Parrot issue.
A
On Sat, 6 Mar 2004, Jared Rhine wrote:
It'd be nice if the first item, gmclock wasn't defined in terms of
UTC. Regardless of the future fate of UTC leap seconds, any
UTC-based clock would need to account for leap seconds going back,
right? So it seems that GMT should be preferred in the
On Tue, 9 Mar 2004, Edward S. Peschko wrote:
This sort of creeping featuritis is why date formatting and especially
parsing do NOT belong as opcodes. It's too big a problem to solve in the
I agree.
And the more I think about it, the more I think this concern is misplaced.
Putting it
Hi,
On Tuesday 09 March 2004 21:17, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
The attached file has some helper functions to make object usage
easier. It is used by the new object orientated Data::Dumper
implementation as well as my EBNF parser generator. I submit it as
Proposal Cstat opcode and interface
1) ops
stat (out PMC, in STR, in INT)
stat (out PMC, in PMC, in INT)
Return a new array-like[1] PMC $1 with file stats from file (PIO or
string) $2,
or PerlUndef, if file doesn't exist, $3 are flags:
.PARROT_STAT_NO_FOLLOW_LINK
The array(-like) has
Sebastian Riedel [EMAIL PROTECTED] wrote:
Attached patch should fix that all.
Thanks, applied - just updated the sample conf.
leo
Jens Rieks [EMAIL PROTECTED] wrote:
Hi,
On Tuesday 09 March 2004 21:17, Leopold Toetsch wrote:
what about:
(retvals) = obj.methodname(...)
Yes that would be the best solution. I had a cursory look at the IMCC
sources, but found no obvious way to implement it.
I'll have a look at it.
Hi,
On Wednesday 10 March 2004 12:54, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
... It is usefull for constructor calling, to make sure that
all base classes are initialized in the proper order.
I've checked in a small change to objects. __init get's now called on
all
Hi all,
attached is an object orientated version of library/dumper.imc.
(it needs libraray/objecthacks.imc from yesterday)
I made the following changes:
- the third (optional) parameter of _dumper ('indent)' behaves a little bit
different. The string is now repeated for each indention level.
-
I have expanded the parser a bit:
obj.method(args)
ret = obj.method(...)
(retvals) = obj.method(...)
Cmethod is a label. It's not yet stored in the classes namespace. s.
imcc/t/syn/objects.t
And plain function calls work now with variables too:
.local pmc the_sub
the_sub = global
In an attempt to drain the swamp...
So far as I can see, we need, in descending order of importance (and
speed) (And if there's stuff missing, add them):
1) A timestamp value
2) A way to chop the timestamp to pieces
3) A way to turn the timestamp into a string
4) A way to turn pieces to a
At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.
I don't really care what the syntax looks like, so I'm
Time to nail down some method syntax for IMCC. So, what I'd like (and
this is open to discussion) is:
Calling a method:
object.variable(pararms)
object.literal name(params)
that is, if the method is referenced with a string register or .local
you use the first form and just name the
I have no opinion either way on this opcode or the date/time ones, but I
would like to remind folks about miniparrot- if we want it to work again,
there needs to be a smooth way to exclude opcodes or PMCs which are
not expecially portable on its platform (pure c89, no threads, etc).
This means
Josh Wilmes wrote:
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
Miniparrot, or something very much like it, is the final build system.
--
Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote:
While I see that's necessary it's not that simple ...
Oh, sure it is. :)
Well, from what I've seen so far, you're slamming all subs into the
base namespace, so that if I have IMCC code that does:
At 10:11 AM -0800 3/10/04, Brent \Dax\ Royal-Gordon wrote:
Josh Wilmes wrote:
It's also quite possible that miniparrot is a waste of time. I'm
pretty much of the opinion myself that it's an academic exercise at
this point, but one which keeps us honest, even if we don't use it.
Miniparrot, or
Dan Sugalski wrote:
Which, unfortunately, will end up making things a hassle, since there's
no platform-independent way to spawn a sub-process, dammit. :(
Unixen seem to support system(). So does Windows. I suspect that most
OSes we want to run on have something pretty equivalent, even if it
At 12:53 PM -0500 3/10/04, Josh Wilmes wrote:
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
Nope, not a waste of time at all. It is part of
At 11:12 AM -0800 3/10/04, Brent \Dax\ Royal-Gordon wrote:
Dan Sugalski wrote:
Which, unfortunately, will end up making things a hassle, since
there's no platform-independent way to spawn a sub-process, dammit.
:(
Unixen seem to support system().
D'oh! It's C89 standard. I'm getting stuck in the
Hi,
this time a funny bug :-)
1. create a file main.imc with the following content:
.sub _main
print A\n
load_bytecode hello.imc
print B\n
end
.end
2. create a file hello.imc with the following content:
.emit
.pcc_sub @LOAD _onload:
print foo\n
end
.eom
.sub _hello
That depends if google properly supports moderated newsgroups.
Sounds like they don't ...
In any case we don't currently support posting via nntp through
anything but nntp.perl.org.
Actually, I think we need to get the uunet.uu.net folks to setup some
entries for us. But I can't find
[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
It's an ongoing fight between the go get the libs and install them
folks and the self-contained distribution folks. I'm in the latter
category. :)
As Larry said, self-contained is good for users. For developers
(and CVS) go get the libs is
On Wed, Mar 10, 2004 at 10:58:14AM -0500, Dan Sugalski wrote:
: *) Times (create, modify, access)
Just a reminder that ctime on Unix is not create time, but time of
last inode change. I wish there were a create time on Unix, but there
ain't.
Larry
At 4:32 PM -0800 3/10/04, Larry Wall wrote:
On Wed, Mar 10, 2004 at 10:58:14AM -0500, Dan Sugalski wrote:
: *) Times (create, modify, access)
Just a reminder that ctime on Unix is not create time, but time of
last inode change. I wish there were a create time on Unix, but there
ain't.
Yup, that
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote:
: That means we can't convert to TAI, since that needs leap second info
: we don't have, so base time can't be TAI.
That part is only half true. Or maybe less than half, if UTC decides
to cut loose from astronomical time and ends up
We've gone back and forth on this before, and it's time to go for yet
another round.
Right now, we can create new PMCs by calling the class init method.
It takes no parameters which somewhat limits the utility of the thing
as a true initializer. There's an init vtable method that takes a
28 matches
Mail list logo
