Re: news gateway through google not working?
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 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. - ask -- http://www.askbjoernhansen.com/
Re: Dates and Times
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 few of us have already offered opinions... What we would like for DateTime.pm is an epoch that is _absolutely_ fixed across all platforms. perl does not provide this so we are dependent on the behavior of time(), gmtime(), and Time::Local to make up for this. I have already suggested that Parrot include an op that returns TAI but I would happily settle for gettimeofday(2). What ever is decided upon Parrot should commit to making it consistent across _all_ platforms. -J --
Re: Dates and Times
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 core, with any > UTC calculations being performed at the language or module level. No necessarily GMT but at least an integer number of seconds since some epoch. > Daylight savings time calculation seems appropriate to stay in the > core, but perhaps additional opcodes are need to set the clock's > understanding of the time zone used for DST calculations? Properly handling DST realistically (time zones are really hard) means a dependency on the Olson DB. We have to ship the entire thing in DateTime::TimeZone as we can't depend on tz/zoneinfo being available. -J --
Re: Dates and Times
On Tue, 9 Mar 2004, Edward S. Peschko wrote: > On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote: > > "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib > > directory. > > fair enough, but then where does the distinction lie? Why put gmtime, et al. > in opcodes? As well as addmonth? Returning the current time since epoch x should be an opcode as this is a very common and latency sensitive operation. I believe an awful lot of code only wants to determine the elapsed amount of time by subtracting to subsequent timestamps. Date and time manipulation is complicated and belongs at a much higher level. > If you are optimising for simplicity and , it surely makes sense to put these in > the standard library. Only if it's a _correct_ implementation. There is no reason why DateTime.pm couldn't be ported to Parrot after object support settles down a bit. > If you are optimising for speed, then it makes sense to put them in opcodes. Bloating the core doesn't count as an optimization. > But I don't see the 'creeping featuritis' that you see. As well as the > memory imprint problems that you see. Is parrot going to link with libc? > > If so, you get a ton of functionality for (almost) free, just by doing an > intelligent wrapper around strftime. As well as providing much of your > localization support. And you get a natural boundary on what functionality should > be put (in the core) versus what should be put in a module. We all know how consistent the nice vendors are with there libc implementations. :) Do we really want to expose the platform specific strftime() extensions? -J --
Re: Dates and Times
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 in an opcode will make it *harder* to do this type of thing, not easier. > In perl5 land, backwards - and forwards - compatibility is a big concern. There will > be a large tendency to stabilize any implementation that occurs here. So why do you think time manipulation is about the only thing left out of the x86 ISA? :) -J --
Re: [NEW] library/objecthacks.imc
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 a > > standalone library to reduce code duplication. It might also be useful > > for other developers too. Please refer to the POD of this library for > > more information about it. > > Good. I've seen these functions :) They are fine, except for one: > >=item (retvals) = __call( obj, methodname, ... ) > > > > set S0, S5 > > set P2, P5 > > [ snipped a lot more reg moves ] > > This isn't really looking good. > > 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. > Melvin would that be ok? It *should* be a simple extension of the > current function call syntax. We need to emit above two lines > additionally and C instead of C, that's all, > AFAIK. Is there a way to get the parent (one should be enough for now) of a ParrotClass? I attached the parent ParrotClass as a property in __new_class, but that does not work anymore because its now possible to use the function with the name of the class to subclass from. Is it possible to get a ParrotClass if the name is known, without having to instantiate an object of that type and using the getclass op on it? If I know how to do that I can add a "__multicall" function that calls the specified method on all base classes, starting with the root baseclass. It is usefull for constructor calling, to make sure that all base classes are initialized in the proper order. > leo jens
[PROPOSAL] C opcode and interface
Proposal C 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 keyed access with these keys
.PARROT_STAT_FILE_SIZE
.PARROT_STAT_FILE_SIZE_LO
.PARROT_STAT_FILE_SIZE_HI
.PARROT_STAT_MODE a bitmask with these bits:
.PARROT_STAT_MODE_ISDIR
.PARROT_STAT_MODE_ISFILE
[ more platform-unspecific bits ]
.PARROT_STAT_PERM a bitmask with these bits
.PARROT_STAT_PERM_IS_READABLE
.PARROT_STAT_PERM_IS_WRITABLE
.PARROT_STAT_PERM_IS_EXECUTABLE
.PARROT_STAT_MTIME modified time
.PARROT_STAT_OS_TYPE a constant defining the os-specific
part that follows
.PARROT_STAT_stat
.PARROT_STAT_stat64
...
.PARROT_STAT_OS_SPECIFIC
A (Un)?ManagedStruct PMC with OS-specific data like a
struct stat64
2) Interface
PMC* Parrot_stat_s(Interp*, STRING* file, INTVAL flags);
PMC* Parrot_stat_p(Interp*, PMC*pio, INTVAL flags);
3) Interface to platforms
INTVAL Parrot_stat_os_s(Interp*, Parrot_stat*, STRING* file, INTVAL
flags);
INTVAL Parrot_stat_os_p(Interp*, Parrot_stat*, PMC*pio, INTVAL
flags);
typedef struct _parrot_stat {
size64_t size;
UINTVAL mode;
UINTVAL perm;
FLOATVAL mtime; // in Parrot units
UINTVAL os_stat_type;
union {
struct stat;
struct stat64;
...
} u;
} Parrot_stat;
4) Notes
The information in the first few fields should not be platform
specific. If platforms have more in common then above bits, the
structure should be expanded.
[1] it needs just these vtables implemeted: I0 = P0[i], N0 = P0[i],
i.e. get_{integer,number}_keyed_int
Comments, improvements, and implementations thereafter welcome
leo
Re: A Perl Task - Benchmarking
Sebastian Riedel <[EMAIL PROTECTED]> wrote: >> > Attached patch should fix that all. Thanks, applied - just updated the sample conf. leo
Re: [NEW] library/objecthacks.imc
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. > Is there a way to get the parent (one should be enough for now) of a > ParrotClass? No. And what about multiple parents? For SI it's simple. But we could return the immediate parent in seach order. > Is it possible to get a ParrotClass if the name is known, without having to > instantiate an object of that type and using the getclass op on it? The C opcode does return the class PMC. > If I know how to do that I can add a "__multicall" function that calls > the specified method on all base classes, starting with the root > baseclass. It is usefull for constructor calling, to make sure that > all base classes are initialized in the proper order. This should be done inside objects.c. > jens leo
Re: [NEW] library/objecthacks.imc
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 parent classes in reverse search order. Then __init on the class is called. > jens leo
Re: [NEW] library/objecthacks.imc
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 parent classes in reverse search order. Then __init on the class > is called. Works great, thank you! I'll write a test for it later today. > > jens > > leo jens
Data::Dumper test version
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.
- Unknown PMC are tested for a '__dumper' method, if it has one it is invoked
with the dumper and it's own name (as stored in the cache) as parameters. See
dumper.t test 12 for more information.
The attached archive contains the following files:
- t/pmc/dumper.t.patch
small test adjustments
- library/dumper.imc
a compatibility interface
- library/Data/Dumper.imc
the Data::Dumper class
- library/Data/Dumper/Base.imc
base class for Dumper frontends
- library/Data/Dumper/Default.imc
default Dumper frontend
Comments welcome!
jens
dumper.tgz
Description: application/tgz
[CVS ci] PIR method calls
I have expanded the parser a bit: obj.method(args) ret = obj.method(...) (retvals) = obj.method(...) C 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 "_sub" the_sub(10, 20) ... .sub _sub leo
Dates and times again
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 timestamp 5) A way to turn the string into a timestamp All of which is confounded by the joys of timezones and platform limitations. As far as I can tell, the only thing we can absolutely count on are: asctime, ctime, difftime, gmtime, localtime, mktime, strftime We can't even count on timegm, unfortunately. Neither can we count on getting fractional time. (Or even really count on getting a GMT time that's actually GMT, as far as that goes, but that's user-misconfiguration and there's a limit to what I'm willing to care about) Nor strptime for time parsing, though a case could be made there that we could do our own. (Cases to be made for that should be accompanied by unencumbered source to do the parsing ;) Can't even count on the full range of output when splitting the time up--if you check the CVS logs you'll see I yanked out a few elements because they're not C89 and there wasn't any way to synthesize them easily that I know of. 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. From what I can tell from the interfaces and long painful experience we can't convert to and from anything other than the current system timezone. (Maybe. I'm not 100% sure that's reliable either) Right now, you can get a black-box integer timestamp that's fixed to GMT time, and you can disassemble that timestamp into day/month/year pieces. I adjusted the year to be a real year, but I haven't adjusted the month. We can do that, though. We can easily: *) Give a float timestamp *) Adjust the timestamp to various base dates (I've already made my preferences clear :) My general rule-of-thumb for ops is that they must: *) Be something we want to guarantee behaviour on everywhere *) Require C code *) Have a fixed signature Being primitive isn't necessary as such, but doesn't hurt. Having to be required present at all times isn't necessary either, though we should nail down lexical oplibs if we want to start talking about secondary libraries of this stuff. Anyway, given the restrictions on what we have to work with, the first question is: *) Is what we're providing correct *) What *aren't* we providing that we must to allow full and proper date processing in modules without much pain? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Namespaces in IMCC
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 proposing: .namespace [foo; bar; baz] While I see that's necessary it's not that simple ... Oh, sure it is. :) > as a way to set the current namespace for subs to foo::bar::baz. Any sub defined from that point on in the current source file will go into that namespace, unless the namespace is explicitly changed later on. ... because, what does it mean: "Any sub [..] will go into that namespace"? 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: .pcc_sub foo .end there's a foo entry in the base namespace. Which is fine. What I want the .namespace (or whatever) thing to do is alter the default namespace that's used. Anway, whe should really define, what are the duties of the PIR assembler towards variable names, name mangling, lexical scopes, namespaces, globals, and all that related stuff. We need it. It's not defined. Fair enough. Generally I don't want the PASM/PIR assemblers to do a whole lot, since I'm not sure it's a good idea. I was going to put this off a bit longer, but I see it's past time to do that. This also gets into the decisions of what metadata goes into the bytecode files and what the bytecode loader is responsible for doing, unfortunately. So we get to revisit bytecode and metadata too. Wheee -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] C opcode and interface
At 11:39 AM +0100 3/10/04, Leopold Toetsch wrote: Proposal C opcode and interface While we need to do this, what you've got here's far too platform-specific. From long, hard, unpleasant experience I can guarantee that starting with a Unix view of this is going to generate vast amounts of pain in the future. :( Before we dig into the implementation maybe we better take a bit to work out the information we want. From memory, I can think of: *) File size *) Permissions (read, write, execute, delete, enter (for dirs)) and that's for owner, group, everyone, and root *) Times (create, modify, access) *) ACL information (All horribly platform and filesystem specific IIRC) *) Information (file, dir, softlink, hardlink, block dev, char dev, socket, named pipe, semaphore) *) user & group of file *) File version (And not just for VMS -- my OS X manpages list this) Some of this information will have to be synthesized on every platform, but with a few exceptions (times, mainly) it's all doable. If there's anything else that needs adding to this list, well, we should do it now. As you've probably noted I'd rather not re-implement and expose 35 years worth of "Whoops, that turned out to be a bad idea" crud. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Methods and IMCC
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 register or local. On the other hand, making a method call with an actual literal string you put the method in quotes. Method declarations: .pcc_sub foo prototyped, method .param pmc foo .param pmc bar .end That is, you add a method on the end of the sub declaration line. If you do so, the local self refers to the object pmc register. (I am OK with unconditionally doing this, in which case we should define some other guaranteed aliases) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] C opcode and interface
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 one or more of the following will need to be done:
- all non-c89 code in config/gen/platform
- extra flag in the .ops files to identify ops to be excluded
- extra file to list explicitly which ops should be INcluded in
miniparrot, with all others left out.
- more #ifdef MINIPARROTs.
Personally i'm leaning towards the third option, but I think we should be
clear what the policy is with regard to config/gen/platform and functions
which aren't part of standard C (but which are available on most
platforms).
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.
--Josh
--Josh
At 11:39 on 03/10/2004 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Proposal C 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 keyed access with these keys
>
>.PARROT_STAT_FILE_SIZE
>.PARROT_STAT_FILE_SIZE_LO
>.PARROT_STAT_FILE_SIZE_HI
>
>.PARROT_STAT_MODE a bitmask with these bits:
> .PARROT_STAT_MODE_ISDIR
> .PARROT_STAT_MODE_ISFILE
> [ more platform-unspecific bits ]
>
>.PARROT_STAT_PERM a bitmask with these bits
> .PARROT_STAT_PERM_IS_READABLE
> .PARROT_STAT_PERM_IS_WRITABLE
> .PARROT_STAT_PERM_IS_EXECUTABLE
>
>.PARROT_STAT_MTIME modified time
>
>.PARROT_STAT_OS_TYPE a constant defining the os-specific
> part that follows
> .PARROT_STAT_stat
> .PARROT_STAT_stat64
> ...
>
>.PARROT_STAT_OS_SPECIFIC
>A (Un)?ManagedStruct PMC with OS-specific data like a
> struct stat64
>
> 2) Interface
>
> PMC* Parrot_stat_s(Interp*, STRING* file, INTVAL flags);
> PMC* Parrot_stat_p(Interp*, PMC*pio, INTVAL flags);
>
> 3) Interface to platforms
>
> INTVAL Parrot_stat_os_s(Interp*, Parrot_stat*, STRING* file, INTVAL
> flags);
> INTVAL Parrot_stat_os_p(Interp*, Parrot_stat*, PMC*pio, INTVAL
> flags);
>
> typedef struct _parrot_stat {
>size64_t size;
>UINTVAL mode;
>UINTVAL perm;
>FLOATVAL mtime; // in Parrot units
>UINTVAL os_stat_type;
>union {
> struct stat;
> struct stat64;
> ...
> } u;
> } Parrot_stat;
>
> 4) Notes
> The information in the first few fields should not be platform
> specific. If platforms have more in common then above bits, the
> structure should be expanded.
>
> [1] it needs just these vtables implemeted: I0 = P0[i], N0 = P0[i],
> i.e. get_{integer,number}_keyed_int
>
> Comments, improvements, and implementations thereafter welcome
> leo
Re: [PROPOSAL] C opcode and interface
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. -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia. [Ugh.]
Re: Namespaces in IMCC
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: >.pcc_sub foo >.end > there's a foo entry in the base namespace. Which is fine. What I want > the .namespace (or whatever) thing to do is alter the default > namespace that's used. Silly me. Of course. Should be ratber simple to implement. Tomorrow. leo
Re: Methods and IMCC
Dan Sugalski <[EMAIL PROTECTED]> wrote: > 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) Ok. > object."literal name"(params) A currently already implemented variant is: object.label(params) where label is an unquoted string. I'll do the other two variants tomorrow, if they aren't done - seems simple now:) > Method declarations: > .pcc_sub foo prototyped, method >.param pmc foo >.param pmc bar > .end > That is, you add a method on the end of the sub declaration line. If > you do so, the local self refers to the object pmc register. (I am OK > with unconditionally doing this, in which case we should define some > other guaranteed aliases) alternative syntax: .self me # declare PMC P2 as var me so .pcc_sub foo prototyped, method is .pcc_sub foo prototyped ... .self self which is actually .local pmc self self := P2 leo
Re: [PROPOSAL] C opcode and interface
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 something very much like it, is the final build system. Yep. We need to make sure it always works. Which, unfortunately, will end up making things a hassle, since there's no platform-independent way to spawn a sub-process, dammit. :( -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] C opcode and interface
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 doesn't have the exact same name. (Except for Palms, but Palms are always cross-compiled to. Although I *did* see one C compiler that ran on the Palm...) I think that, in this particular area, it's okay to introduce a bit of platform dependence into Miniparrot via #ifdefs. It's a critically important function for Miniparrot to do its job, and if we're careful about what programs we call and what sort of I/O redirections we try to use, the portability concerns aren't too daunting. Remember, the real thing won't be using 'perl -e', so quoting constructs may not even come into play. The plan was always *three*-step: platform specific shell script -> miniparrot -> full parrot The shell scripts (or batch files, or...) in the first steps can pass a couple extra -Ds to Miniparrot if they're really necessary. -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: [PROPOSAL] C opcode and interface
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 the big plan, and as such is really, really important. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] C opcode and interface
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 80s with the multitude of exec variants. Yeah, with that issue taken care of it's a lot more doable. Nevermind... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[BUG] load_bytecode can print hello world
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 print "blah blah string\n" load_bytecode "hello, world!\n" end .end 3. run main.imc jens
Re: news gateway through google not working?
> > > > 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 a contact address. -R
Re: [DOCS] Documentation tools
[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 appropriate. A script can assemble the user distribution(s) with pre-defined versions of the libs to include. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [PROPOSAL] C opcode and interface
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
Re: [PROPOSAL] C opcode and interface
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 I know. Other, less broken filesystems have real create times for files. :-P I don't expect access time to be available for most files either, even on systems that support it, because of the pretty massive overhead it tends to incur. Still, it's there to be had in many cases, so... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and times again
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 tracking TAI exactly from now on. But we *do* know the mappings in the past. (Well, for the recent past, anyway. :-) : Right now, you can get a black-box integer timestamp that's fixed to : GMT time, and you can disassemble that timestamp into day/month/year : pieces. I adjusted the year to be a real year, but I haven't adjusted : the month. We can do that, though. We can easily: : : *) Give a float timestamp That would seem like good future proofing. Someday every computer will have decentish subsecond timing. I hope to see it in my lifetime... : *) Adjust the timestamp to various base dates (I've already made my :preferences clear :) 0 on 1/1/2000 works out very well if it turns out we don't do UTC leaps seconds any more. Then TAI and UTC only go nonlinear before 2000, and so far that's in the past, which is generally easier to predict afterwards, given enough historical evidence. And if they do add leaps to UTC in the future, then at least TAI and GMT always march in lockstep, and we'll be no worse off than we are now. :-) "It will be very good if the fate of leap seconds is decided well before POSIX has to consider how to store time after that date in 2038." --http://www.ucolick.org/~sla/leapsecs/onlinebib.html My guess is that eventually they'll decide to put a moratorium on leap seconds, with the recommendation that the problem be revisited just before 2100, on the assumption that we'll add all of a century's leap seconds at once at the end of each century. That would let civil time drift by at most a minute or two before being hauled back to astronomical time. More to the point, it would put the problem off till another day (not to mention another generation). So that's my prediction. But then, I'm terrible at time estimation... : *) Is what we're providing correct I'd say what's missing are the error bars. I don't mind if the timestamp comes back integral on machines that can't support subsecond timing, but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. : *) What *aren't* we providing that we must to allow full and :proper date processing in modules without much pain? Snap-to-grid semantics for when the clock inevitably gets off by a second or two from somebody's idea of the correct time. (But that should be solved in your levels two through five, not in the timestamp.) The basic idea is I can add 86400 seconds to yesterday and I get the same time today, even if there was a leap second. One would have to request such a "snap" explicitly, I expect, because you'd have to communicate to it that you don't actually care about sub-minute times, or whatever your "grid" specifies. But that's how graphics programmers solve the mouse jitter problem, and I think we can learn from them. Larry
Objects, init, and vtable limits
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 property PMC, but that's kind of awkward. Now, we've three real options here. We can: 1) Treat the init method as an allocator, and leave initialization to an explicit sub/method call 2) Have one single vtable method that has a different set of calling conventions from every other method and sub available from bytecode 3) Make new use the registers and obey the calling conventions Now, I don't really like #3, as it's damned inconvenient. #2 has this nasty inconsistency to it that I'm not thrilled with either, though I can definitely live with it. #1 leaves us with the possibility of split allocation and initialization and I've been warned about that as a Bad Idea. (OTOH we're at a low-enough level that it's arguably OK) I'm up for discussion on this, as well as other options, so... have at it. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
