Leopold Toetsch wrote:
On Jun 18, 2006, at 2:02, Vishal Soni via RT wrote:
I am just wonedring if it would make sense to seperate out code for each
supported operating system under a directory structure. At the time
of build the specific code for target operating system is added to the
sour
Hi Leo,
That sounds great. One quick question would it make sense to start defining
a generic platform interface that that all supported platforms need to
implement. A quick example of a similar abstraction would be the Apache
Portable Runtime (http://apr.apache.org/).
Let me know what your thou
On Jun 19, 2006, at 19:30, Vishal Soni wrote:
So do we need to change os.pmc to leverage this infrastructure and get
rid of the platform specific code( currently implemented via IFDEF)
from os.pmc?
I think that all platform-specific code should be factored out, i.e.
the existing methods sho
Hi Leo,
So do we need to change os.pmc to leverage this infrastructure and get rid
of the platform specific code( currently implemented via IFDEF) from os.pmc?
-Vishal
On 6/19/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
On Jun 18, 2006, at 2:02, Vishal Soni via RT wrote:
> I am just won
On Jun 18, 2006, at 2:02, Vishal Soni via RT wrote:
I am just wonedring if it would make sense to seperate out code for
each
supported operating system under a directory structure. At the time
of build the specific code for target operating system is added to the
source tree.
Yep. Actuall
I'd vote for that being the default method that can be overridden on a
per platform basis with a more functional/efficient version.
-J
--
On Thu, Jan 12, 2006 at 12:07:33PM +, Alberto Manuel Brand?o Sim?es wrote:
> I'm not implementing copy at the moment as I lack knowledge. I might
> just w
On Thu, Jan 12, 2006 at 06:27:11AM -0800, jerry gay wrote:
> On 1/12/06, Alberto Manuel Brandão Simões <[EMAIL PROTECTED]> wrote:
> > I'm not implementing copy at the moment as I lack knowledge. I might
> > just write the default open/while(){write}/close method for cases when
> > everything else f
At 18:03 03/01/2006 -0800, you wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #38146]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38146 >
OS.pmc should provide both a:
and
rename
On 1/12/06, Alberto Manuel Brandão Simões <[EMAIL PROTECTED]> wrote:
> I'm not implementing copy at the moment as I lack knowledge. I might
> just write the default open/while(){write}/close method for cases when
> everything else fails.
>
> BTW, it will go for File.pmc accordingly with Leo.
>
sinc
I'm not implementing copy at the moment as I lack knowledge. I might
just write the default open/while(){write}/close method for cases when
everything else fails.
BTW, it will go for File.pmc accordingly with Leo.
Joshua Juran wrote:
On Jan 11, 2006, at 7:02 PM, Chip Salzenberg wrote:
On We
On Jan 11, 2006, at 7:02 PM, Chip Salzenberg wrote:
On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote:
Since before System 7 (approaching two decades ago), Mac OS has had a
system call that exchanges the contents of two files. The purpose of
this call is to implement a 'safe save' s
On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote:
> Since before System 7 (approaching two decades ago), Mac OS has had a
> system call that exchanges the contents of two files. The purpose of
> this call is to implement a 'safe save' strategy ...
Is this still a system call in Mac
On Jan 10, 2006, at 10:29 PM, Chip Salzenberg wrote:
On Sat, Jan 07, 2006 at 01:04:29PM -1000, Joshua Hoblitt wrote:
... More sophisticated behavior, like metadata replication, should
be left to another method (perhaps syscopy()) that has platform
specific
behavior(s).
My first thought was
An aside: I suspect that OS.pmc is going to grow beyond maintainability
(and fast loading) in the manner of Perl's POSIX module. But for now,
it's absolutely great that we're collecting each portability hack into
a single implementation.
On Sat, Jan 07, 2006 at 01:04:29PM -1000, Joshua Hoblitt wr
I think it's prudent that OS.pmc's default copy() method behaves in the
same way as File::Copy::copy() as this is likely the lowest possible
common denominator across platforms (note that I said behavior, not
implementation). This is sufficient for the majority of file copy tasks
and will make pre
Bob Rogers wrote:
From: Joshua Isom <[EMAIL PROTECTED]>
Date: Fri, 6 Jan 2006 23:53:51 -0600
On Jan 6, 2006, at 10:17 PM, Joshua Juran wrote:
> On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
>
>> This needs some more discussion. If we look to Perl, for instance, it
From: Joshua Isom <[EMAIL PROTECTED]>
Date: Fri, 6 Jan 2006 23:53:51 -0600
On Jan 6, 2006, at 10:17 PM, Joshua Juran wrote:
> On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
>
>> This needs some more discussion. If we look to Perl, for instance, it
>> doesn't have a
On Jan 6, 2006, at 10:17 PM, Joshua Juran wrote:
On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
This needs some more discussion. If we look to Perl, for instance, it
doesn't have a built-in copy. You should use either a module, or open
both files, copy contents, and close both files
On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
[coke - Tue Jan 03 18:03:31 2006]:
OS.pmc should provide both a:
copy(source_file,target)
And a
copy(array_of_source_files,targetDir)
This needs some more discussion. If we look to Perl, for instance, it
doesn't have a built-in copy.
19 matches
Mail list logo
