Re: Angle quotes and pointy brackets
On Thursday, December 2, 2004, 10:08:31 AM, you (mailto:[EMAIL PROTECTED]) wrote: > On Tue, 30 Nov 2004, Austin Hastings wrote: >> How about just having C< system() > return a clever object with .output and >> .err methods? > interesting... > Michele Prior art of this on Windows... http://msdn.microsoft.com/library/en-us/script56/html/wslrfExecMethod.asp (the respective properties on the returned WshScriptExec instance being .StdOut and .StdErr.) -- Richard mailto:[EMAIL PROTECTED]
Re: Protocols
On Thursday, July 24, 2003, 5:45:33 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Thursday, July 24, 2003, at 08:49 AM, David Wheeler wrote: > No, I think Java interfaces are a kluge to get around copying a broken > type system and the lack of multiple inheritance. There are other alternatives... In typeless languages it is a runtime error; or there is the .NET solution, to use delegates. See http://www.gotdotnet.com/team/dbox/default.aspx?key=2003-07-21T08:36:33Z For a blog entry that talks about exactly this point. -- Richard mailto:[EMAIL PROTECTED]
Re: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
On Thursday, January 30, 2003, 7:44:42 PM, you (mailto:[EMAIL PROTECTED]) wrote:
> On Thu, 2003-01-30 at 13:13, Garrett Goebel wrote:
> Let me switch that one around for you:
> class MyContainer {
> method index($object) { ... } # index by any scalar object
> method index(int $ind) { ... } # index by a number
> }
> my MyContainer $x;
> $x.index($!);
> What does *that* do? Ultimately, C<$x[$!]> is no different, and if we
> have a resolution for one, we have a resolution for the other.
> What's more, even if we do decide not to unify arrays and hashes (as I'm
> assuming we will), I'm pretty sure we still need to answer this
> question.
> Options include:
> * Run-time error
> * Default to most generic type with warning
> * Default to most generic type without warning
> * Default to most specific type (huh?) with warning
> * Default to most specific type without warning
> I'm not sure what I meant by "most specific", but it sounded like that
> should be one of the options. Can anyone else read my mind better than I
> can? :)
While I wouldn't claim to know anyone's mind (I have enough problems with my own
:-), I think the "huh?" there is quite correct. Having looked at the C++
solution to this (for both overloading and template (partial) specialisation
resolution I don't think it would be a good idea to go anywhere near this. In
fact we should all run away very fast. Very very fast.
However just defaulting to the most generic (i.e. typed) is likely to lead to
action at a distance if the set of overloads is changed... so a warning would be
a really good idea.
--
Richard
mailto:[EMAIL PROTECTED]
Re: L2R/R2L syntax
On Friday, January 17, 2003, 6:35:47 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: >> [EMAIL PROTECTED] (Mr. Nobody) writes: >> > I have to wonder how many people actually like this syntax, and how many only >> > say they do because it's Damian Conway who proposed it. And map/grep aren't >> > "specialized syntax", you could do the same thing with a sub with a prototype >> > of (&block, *@list). >> >> Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, >> adding syntax for the sake of syntax, doesn't do anything for the readability >> of code, and doesn't really actually gain very much anyway. > That I will agree with to some extent. But mainly because I think > that IF a pipe-like syntax is added then it should do just that, > pipe. What has been proposed is not a pipe, unless each part gets > converted to a co-routine and its arguments are really an interator > that calls the previous stage to get the next argument. Actually I think this is a *very* good idea (and far more important that arrays). If . pretty much all the operations proposed for arrays and/or lists are actually operations on iterators. . arrays and lists convert to iterators freely . lazy lists are just an iterator without an end point then a whole pile of complexity and special cases can be removed. After all, grep (etc.) just keep asking the iterator for more elements until one matches the condition, when it has been asked by the next upstream element to generate the next element. Thus lazy lists become the norm and the only time the whole pipeline is actually processed is when something forces it (like printing it out, or getting the size of the resultant list). The only real exception is that an infinite iterator (as created by 1..inf) would need to generate an error in this case. -- Richard mailto:[EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Friday, January 10, 2003, 9:05:42 PM, you (mailto:[EMAIL PROTECTED]) wrote: > Universe 2 (pro-unicode): "If we had a Unicode 'squiggly arrow' operator, > then however it looks on everybody's display, it ought to at least look like > some kind of squiggly arrow." U+21DC "Leftwards Squiggle Arrow" and U+21DE "Rightwards Squiggle Arrow" would seem to fit the bill rather well maybe the ascii <~ and ~> are merely aliases of the true symbols? -- Richard mailto:[EMAIL PROTECTED]
Re: how to code a lazy pipeline?
On Tuesday, December 10, 2002, 1:26:41 PM, you (mailto:[EMAIL PROTECTED]) wrote:
> On 12/10/2002 4:54 AM, Me wrote:
>> How would one most nicely code what I'll call
>> a lazy pipeline, such that the first result
>> from the final element of the pipeline can
>> appear as soon as the first result has been
>> processed from the intervening elements?
> I belive the short answer is "make sure all elements of your pipeline
> return a lazy list". Exactly how one does this, and the distinction
> between a lazy list and an iterator, I belive is still somwhat up in the
> air.
I think the answer here will be make a lazy list an iterator constructor. This
would also be the case for something like a grep in the pipeline (in effect an
iterator adaptor -- to use a C++ term -- on the previous iterator).
I.e. in a "lazy context", grep would return an object with implementation
something like:
sub GrepIterator.atEnd {
return $inputIt.atEnd;
}
sub GrepIterator.Next(): boolean {
while ($inputIt.Next() and $inputIt.Value() !~ $myPattern) {}
if .atEnd() {
return 0;
}
$myCurrent = $inputIt.Value();
return 1;
}
sub GrepIterator.Value() {
return $myCurrent();
}
(Which of course misses all the edge cases.)
--
Richard
mailto:[EMAIL PROTECTED]
Re: Numeric Literals (Summary 2)
On Monday, November 25, 2002, 7:59:01 PM, you (mailto:[EMAIL PROTECTED]) wrote: >> you'll have to write the code so that compiler knows how to handle >> it. While not overly hard, I think its a little much for something >> that should be provided in the core. I think the design team should >> at least account for the fact that someone will want to do this, >> even if it is uncommon. If floating point radii doesn't make its >> way in the core language, I think it should at least be possible >> through a pragma. > Once again, or a module. We don't want the Perl 6 core to be > minimal. We don't want it to be maximal either; that's CPAN's job. > It seems to me (as Simon has pointed out many a-time) that too much is > going into the core. I guess a lot of this stuff that's being talked > about is going to be in modules anyway... so I'm less worried than > when I started writing this paragraph :). Surely this is when grammars will come in if you want the full and total range of possible numeric literals (so you can specify your constants in base 61); then a module could change the grammar to enable these extra forms. I would suggest that the core supports enough to be fully functional (e.g. all possible double values can be specified, and that bit fields can be entered easily), but doesn't need to do everything out of the box. -- Richard mailto:[EMAIL PROTECTED]
Re: Numeric Literals (Summary 2)
On Wednesday, November 20, 2002, 6:16:41 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Monday, November 18, 2002, at 08:34 PM, Martin D Kealey wrote: >> On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote: >>> - floating point becomes allowed in explicit radix (and 0b,0c,0x) >> >> How can one have floating point if "E" is a valid digit? >> >> 0x1.0e1 # 1.054931640625 or 16 ? > Oops, sorry. I meant radix-point-but-not-exponential. It still seems > exponential notation in bases other than 10 is not possible, because of > "e". We could adopt the C99 version and use "p" or "P" for hex decimal values (this, reportedly, allows certain values not expressible in decimal for floats to be specified). Thus 0x.4Ap10 0xA.BCDp-15 (The exponent cannot be in hex in C99). However this clearly cannot generalise for all bases <= 36... -- Richard mailto:[EMAIL PROTECTED]
Re: Streams vs. Descriptors
On Tuesday, July 16, 2002, 5:42:28 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote: >> And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they >> should be reasonably available on most UNIXen. > Are the aio* calls available on Windows? No, but since it would seem helpful, here is the quick version of asynchronous IO on windows. NB. Windows NT/2000/XP supports async io on HDDs as well as sockets, pipes, ...; Win 9x/ME doesn't do it for HDDs. Basically there are three methods of performing asynchronous io on Windows, and these are essentially the same whatever you are reading from/writing to (including accepting connections on sockets). 1. Callback function. 2. Signal an event 3. IO Completion The first two are linked to individual IO operations (ReadFile(Ex), WriteFile(Ex)) if the handle was opened with the appropriate flag. In the first case the function is passed to the IO call, in the second an "OVERLAPPED" structure is passed containing the handle of an event. When using an event you can then wait for the event to be signalled (in much the same way that other kernel objects are signalled). Additionally there is a method for polling for completion. The third way involves associating the file (or whatever) handle with an IOCompletion port, you then have one or more threads sitting in a blocking call to PostQueuedCompletionStatus which returns as the various IO operations complete). The whole area shares a lot with the thread APIs and generally is not too hard to use once you get the hang of the style... however quite how compatible with the POSIX/Mac/... style I have no idea. (For more information see http://msdn.microsoft.com and follow the link to the library, File IO comes under Windows Base Services.) -- Richard mailto:[EMAIL PROTECTED]
Re: Tasks for the interested
On Tuesday, June 18, 2002, 9:33:55 PM, you (mailto:[EMAIL PROTECTED]) wrote: > Okay, here are some tasks for the interested. They're all related (I > expect you'll see the pattern), but independent anyway. [...] > 5) .NET (same as #4, a link to a good reference is fine) Couldn't find any specific MSIL tutorial or reference, however the following should be useful: MS' C#/CLR standardisation page: http://msdn.microsoft.com/net/ecma/ (includes links to various PDF's of the (draft) standards. The ECMA versions of the docs are available here (CLR): http://www.ecma.ch/ecma1/STAND/ecma-335.htm and here (C#): http://www.ecma.ch/ecma1/STAND/ecma-334.htm The EMCA CLR technical group: http://www.ecma.ch/ecma1/MEMENTO/TC39-G3.HTM#Programme%20of%20work: More specifically, the MSIL opcodes are documented in the .NET Class library class System.Reflection.Emit.OpCodes' fields: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemReflectionEmitOpCodesClassTopic.asp?frame=true Also some information in the ILDasm (intermediate language disassembler tutorial): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorials/html/il_dasm_tutorial.asp -- Richard mailto:[EMAIL PROTECTED]
Re: The Perils of set and PMCs
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Simon Cozens) wrote:
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value of the other, so let's write it as
>
> set P1, P2
>
> Excellent. Until, of course, we have to implement it. We'll implement
> it by calling some vtable method on P1, that much is obvious. But which
> one?
Actually I don't think that it is obvious at all.
I see three cases.
Both $a and $b are untyped ("my $a;"). This is easy, duplicate $b and its
dynamic type (e.g. $b is a reference to a hash, then $a becomes another
reference to that hash; $b holds an int then $a will hold a copy of that
int).
Both $a and $b and typed, with the same type, this is the other easy
case---copy the value again.
However if $a and $b are of difference types (e.g. $a is an int and $b in
untyped, or $a is a string and $b is an reference to an array of snafu).
There could be two ways of writing this: $a does the conversion (has a
"set_from_" method), or $b does it (has a "get_as_" method). Given
dynamic loading and adding extra types, the types may not know about each
other when those types were implemented.
In the worst case, types created independently without any knowledge of
the other we can only do something like "stringise and unstringise" or
raise a "don't know how to convert error" (quite possibly at compile
time).
If one type knows about the other then it should be possible to ask it to
do the conversion (and some sort of arbitrary "assignee's conversion wins"
in case of both ways possible). Thus given:
my snafu $a = Something();
my foobar $b;
$b = $a;
the compiler tries:
does foobar have a set P1, P2, "snafu" method?
yes -> use it
does snafu have a get_as "foobar" method?
yes -> use it
else see above (go via some intermediate type or error)
The trick is likely to be balancing complex rules about conversions (look
at C++98 for an example of how complex this can be and what to avoid)
while DWIM to a sufficient degree (for some definition of sufficient).
The point of this messaging really being, that we need to allow
types/classes to define how they convert to other types and since this is
not known at the time of creation of the other type (let alone Perl6) we
need a certain degree of "see what the types will do".
Richard
--
[EMAIL PROTECTED]
Re: What can be hyperoperated?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Simon Cozens) wrote:
>
> On Sat, Jan 26, 2002 at 04:52:53PM -0800, Larry Wall wrote:
> > Perhaps we shouldn't be using ; for this.
>
> Given hyperoperators, I wonder if we can actually drop map.
Something like
@res = ^{ DoSomething($a) }, @source -> $a;
?
But that's put the block first again...
--
[EMAIL PROTECTED]
Re: Apoc4: The loop keyword
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Jonathan Scott Duff) wrote:
> On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
> > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
> >
> > >What we're cleaning up is the ickiness of having things declared
> > outside
> > >the braces be lexical to the braces. *That's* hard to explain to
> > beginners.
> >
> > But it's handy. And that was, until now, what mattered with Perl.
>
> No, handiness still matters with Perl. It's just that the balance has
> tipped a wee bit towards the consistency/regularity/simplicity/whatever
> side of the scale.
>
> Besides no one has commented on Steve Fink's (I think it was him) idea
> to store the result of the most recently executed conditional in $?. I
> kinda like that idea myself. It makes mnemonic sense.
>
> But then I'm sure that someone will come out of the woodwork and say
> "What about if ((my $a = foo()) && ($b < 4)) ?" or something. To
> which I'd say "Fooey!" I personally don't think that an extra set of
> curlies are too high a price for getting rid of weird scoping rules.
> But that's just me.
As someone how comes from the C++ world, I'm really glad that C99 saw
sense and added
if (int i = x()) {
// i in scope here
...
}
// i not in scope here
and therefore was really disappointed that Larry wants to take it out of
Perl. The argument about consistency ("only variables declared in a block
go out of scope at the end of that block") is valid, but of course Perl6
will not always be following that rule anyway.
The exception is function declarations, named parameters will be declared
outside the statement block that forms the body of the function; yet will
be scoped to that block.
For example, I really don't think that &closure and @fileList are expected
to have file scope (for want of a better term), after declaring a function
such as:
sub attempt_closure_after_successful_candidate_file_open
(&closure, @fileList) {
#...
}
(From about half way through Apoc4).
If we already have one case where the rule is actually "only variables
declared in a block or in its 'controlling statement' go out of scope at
the end of that block", so why not make that the general rule and allow
code such as
while (defined(my $line = $file.readline())) {
# ...
}
not to interfere with code elsewhere in the block that may use a variable
called $line (it certainly makes maintenance easier to add a variable with
out extraneous braces but to have a tightly contained scope).
--
[EMAIL PROTECTED]
Re: restarting the discussion: parrot build system
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jarkko Hietaniemi) wrote: > My preference still is rely on *NOTHING* except an ANSI C compiler, > and a way to execute the executable. Which is fine, but how do you pass the source files to the compiler? What other options does it need. What about calling the linker. There is no standard way of doing any of this. Thus the simplistic, but platform specific, batch file would work (and could pass down options saying what platform it was, thus bootstrapping the full configure). -- [EMAIL PROTECTED]
RE: Taking bakcups of a files in directory structure
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brent Dax) wrote: > krish: > # I am a beginner in Perl and have a very trivial query. I have > # some .expect [...] > > This is the wrong group for this sort of question. perl6-internals is s/internals/language/ but the rest does apply (it's surprising there are not more such mis-targetted messages). -- [EMAIL PROTECTED]
Re: Win32 build and WINVER
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(James Mastros) wrote:
> On Sun, Nov 04, 2001 at 01:38:58PM -0500, Dan Sugalski wrote:
> > Currently, I don't want to promise back before Win98, though if Win95
> > is no different from a programming standpoint (I have no idea if it
> > is) then that's fine too. Win 3.1 and DOS are *not* target platforms,
> > though if someone gets it going I'm fine with it.
There is relatively little difference amongst Win95 thru ME. Some extras,
but in practice I don't think we're going to want them (not in the core in
any case).
> I'd tend to say that we should support back to win95 (original, not
> sp2).
> AFAIK, there's nothing that changed that should effect core perl/parrot.
> The one big exception is Unicode support, NT-based systems have much
> better
> Unicode. Specificly, you can output unicode to the console. However,
> only
> targeting NT machines is absolutly not-an-option, for obvious reasons.
No and yes. No, in that the UNICODE[1] support in NT[2] is all pervasive
(i.e. the ascii APIs are translated into UNICODE to be passed into the
kernel).
> It might be that we end up with an NT binary with support for printing
> Unicode to the console, and a generic binary without. (Come to think
> of it,
> the only thing that should care is the opcode library that implements
> print(s|sc).) There's a lot of other differences, of course, but for
> everything the win95 versions should be sufficent. (For example, if we
> want
> to set security properties on open, we need to use APIs that won't work
> on
> 95,98, or Me. But so long as we don't care, the security descriptor
> parameter can be NULL, and it will work fine on both.)
I would think (given Perl's roots) that's exactly where Perl can gain an
advantage, the ability to programmatically manipulate ACLs without having
to take the security APIs full on is going to be a big win (oops:).
The one big benefit an NT only build is that it could use UNICODE (but see
[1]) as its native character set and avoid all the ASCII <-> UNICODE
conversions in the APIs; however this may not be a really big gain in
practice (however I can only speak as someone who rarely uses the upper
codes of Latin-1, let alone all the other sets than UNCICODE provides --
e.g. to create filenames[3]).
The answer I think is to move as much UNICODE enabled functionality into
modules, the selecting of which would switch in the native UNICODE support
and only be supported on NT. The other alternative might be "Microsoft
Layer for Unicode" which emulates much of the NT Unicode support on
Win9x/ME, however I need to finished reading the info on this (and since
it's rather new...)
Once I'm caught up on these messages and a few others I'll put together a
patch to setup the defines before including windows.h to limit us to be
Win95 compatible in the core.
> I should note, BTW, that I don't write windows programs when I can
> manage
> not to, and I don't run NT.
[OT] If you're going to run Windows then 2k is a far easier environment
(once working) than 9x (except for most games that is).
> -=- James Mastros
>
>
[1] Strictly speaking UNICODE assuming USC-2, i.e. pre-V3.0 with the
extension beyond 64k code points.
[2] That is NT, 2000 and XP (at the time of writing).
[3] For example (this is C++, or IIRC C99):
#include
#include
int wmain() { // UNICODE entry point, like main for ASCII
wchar_t fn[2];
fn[0] = 0x4f09; // Some CJF Unified Ideograph
fn[1] = 0;
HANDLE h = CreateFileW(fn, GENERIC_WRITE, 0, 0, CREATE_ALWAYS,
0, 0);
if (INVALID_HANDLE_VALUE == h) {
wprintf(L"Couldn't create file %ld\n", GetLastError());
} else {
CloseHandle(h);
}
return 0;
}
works fine... and displays quite nicely (once I had selected a typeface
with the symbol in it.)
--
[EMAIL PROTECTED]
[PATCH] Set Windows Target Version (1/1)
Sets defines to ensure that post Win95 functions are not defined in windows.h. Richard -- [EMAIL PROTECTED] win32_h_WINVER.diff Description: Binary data
Win32 build and WINVER
Currently for a Win32 build WINVER is not being set, this leads to it being set in Windef.h (included by Windows.h) to 0x0500, or "build for Windows 2000". This is OK, until (for whatever) reason a Win2k only API is called, at which point the built exe will not run on earlier versions of Windows. Thus I think this should be set somewhat lower (and a couple of other defines as well to go along with it). If code that is version dependent is used, the newer windows only API's need to be dynamically loaded (and thus checked at run time). This of course leads to the question of what is the earliest Win32 version that Perl6 will support? -- [EMAIL PROTECTED]
RE: [Patch] Win32 Parrot_floatval_time Improved (1/1)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brent Dax) wrote: > Richard J Cox: > # Firstly, 8am code this morning builds on Win32 without > # problem, other than > # configure.pl not knowing that link is the linker (which > # appears to be down > # to ActiveState not knowing). > > Does it have to know? If so, set it in the hints file > (hints/mswin32.pl). It seems it doesn't (however once we get into creating dll's etc. it will, cl and link take different options). Richard BTW, just tested with VC++ 7 (part of VisualStudio.Net Beta 2) and all also compiles OK and tests pass (well, same set of warnings about no return values in classes\intclass.c). -- [EMAIL PROTECTED]
Re: Beginning of dynamic loading -- platform assistance needed
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Andy Dougherty) wrote: > On Fri, 2 Nov 2001, Jason Diamond wrote: > > > Then we could have a "driver" for each platform that consisted of > > nothing > > but #include's of other .c files. Making a directory for each > > platform might > > be appropriate if we do this. I bet that most of the posix "platform" > > source > > files would be #include'ed into each of the more specific drivers. > > But one big problem is you can't even name all the platforms! New > platforms appear all the time that you never heard of, and Parrot might > work perfectly well on them, but you don't even know of the platform's > existence at release time. > > Certainly platform-specific files are needed sometimes, but I've not > seen > anything that convinces me that a linux.c file does anything but open > the > floodgates to a maintenance job of maintaining lots of nearly-identical > files. I think the answer is not to assume 2 files (.c&.h) for each platform[1]. Rather a pool of files which configure picks from for the local platform (i.e. something has to know that Ynix uses Solaris like async-io while Znix uses Sys5 like async-io). For some platforms more will be needed (VMS being an obvious example) for others (*ix) fewer. On a previous project this is what I ended up with (some aspects of the systems were very different, some quite close). Which brings me around to the initial build of miniperl (to drive the full configure) which surely doesn't need most of the system dependent functions (e.g. no async-io, only the most simple of time/date functions). Having got a "largely platform independent build" perl we can then perform some data driven operations to work out (1) which modules to include, (2) build some headers (e.g. "platform.h" that includes the selected headers) and (3) what tools and options to use for the build. The question is where to draw the line between the different sub-platform files. (And quite possibily part of the answer is to share files where there are just minor differences[2]). [1] This also avoids having huge files for supporting platforms which need substantial code to achieve Perl6's common "OS abstraction layer". [2] E.g. Use RIO_FAST on one platform and R_IOFAST on another, but used in the same way. -- [EMAIL PROTECTED]
[Patch] Win32 Parrot_floatval_time Improved (1/1)
Firstly, 8am code this morning builds on Win32 without problem, other than configure.pl not knowing that link is the linker (which appears to be down to ActiveState not knowing). Thanks to Hong Zhang ([EMAIL PROTECTED]) for pointing out the GetSystemTimeAsFileTime API. Also adjusts zero time to 1970-01-01T00:00:00 (I can easily create the const for other time is something else is more appropriate). -- [EMAIL PROTECTED] win32_c.diff Description: Binary data
RE: Building on Win32
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Andy Dougherty) wrote: > Could someone on Win32 also compare this to the perl5 version in > ext/Time/HiRes.xs? There's no reason to have the perl community running > two different versions. In particular, the perl5 version Sorry... don't have a copy of that... > 1. has the correct return type (int instead of void) What values are returned and when? > 2. subtracts EPOCH_BIAS (no, I don't know what that is, but it > looks > like it might be important.) As I suspected there's a difference at what time is called 0 (seemed unlikely that *nix uses the same as Win32). If someone will let me know when 0 time is for the gettimeofday perl6 is assuming, I can work out the appropriate fiddle factor for Win32. Also, note that Hong Zhang ([EMAIL PROTECTED]) has pointed out a simplification (1 API call rather than 2)... and given I think I've found a working Gnu Diff for Win32 I may be able to submit a real patch (but it'll be the morning before I get sorted out). Richard -- [EMAIL PROTECTED]
Building on Win32
Current get fails to build on Win32[1]
There are a host of problems (not the least being the object files not
going where the linker is expecting them), then aside the first is the
lack of a gettimeofday function. This is used in time_n.
Here's my Win32 version:
void gettimeofday(struct timeval* pTv, void *pDummy);
{
SYSTEMTIME sysTime;
FILETIME fileTime; /* 100ns == 1 */
LARGE_INTEGER i;
GetSystemTime(&sysTime);
SystemTimeToFileTime(&sysTime, &fileTime);
/* Documented as the way to get a 64 bit from a FILETIME. */
memcpy(&i, &fileTime, sizeof(LARGE_INTEGER));
pTv->tv_sec = i.QuadPart / 1000; /*10e7*/
pTv->tv_usec = (i.QuadPart / 10) % 100; /*10e6*/
}
Given a suitable definition of struct timeval for the prototype (there is
a definition in windows.h[2]) but making Windows.h a header across all the
builds causes its own problems (with BOOL for a start).
I'm not sure what a timeval of {0, 0} nominally represents, the above will
give seconds since 1 Jan 1601, so a fiddle factor is likely to be needed.
(I'm not sure what the best way to incorporate this is... for my test I
added an extra .c with a special include, but I think some form of common
OS abstraction layer is going to be needed rather than assuming one
ABI/API and then emulating elsewhere.)
[1] Windows 2000, Visual Studio 6 SP5 & MS Platform SDK (Feb 01 edition)
[2] Well, more correctly in winsock2.h which windows.h includes.
--
[EMAIL PROTECTED]
