Having read all of this thread to date, I'll state a solution which should be
elegant and which I'm not sure has been stated yet.
I propose that the concept of "current working directory" in Perl be a
completely internal, virtual concept, and each Perl thread has its own "current
working direc
Hello everybody,
I'm about to rewrite major parts of one of my projects (currently
written in C); because of that rewrite I'm thinking about using
perl6 for the most parts, and write only the most performance
sensitive parts in C.
I was just on #perl6, and got the tip to write a feature request
f
On Tue, Aug 18, 2009 at 7:03 PM, Mark J. Reed wrote:
> The OS-level chdir() and getcwd() are not thread-safe. The usual
> advice is to ignore them completely in multithreaded programs, in
> favor of absolute paths (or relative paths from a fixed location,
> never calling chdir()). This is part of
The OS-level chdir() and getcwd() are not thread-safe. The usual
advice is to ignore them completely in multithreaded programs, in
favor of absolute paths (or relative paths from a fixed location,
never calling chdir()). This is part of the a reason that Apache2
recommends fastcgi for non-prefork
Author: wayland
Date: 2009-08-19 03:57:49 +0200 (Wed, 19 Aug 2009)
New Revision: 28026
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S32/IO] put in canonpath and realpath, as promised
[S16] Things including:
* Made defaults more sensible (lax vs. stric
See this link.
http://archive.netbsd.se/?ml=perl6-language&a=2008-11&t=9170058
In particular, I thought Tom Christiansen's long message had some
relevant info about filename literals.
:)
-
| Name: Tim Nelso
Ok, here's a fairly significant point posted on IRC.
wayland76: the point of using $*CWD would be (and would *have* to
be, given how context vars work) to give each thread its own working
directory, independent of the process as a whole
Now, given that chdir is an OS concept that a
Author: lwall
Date: 2009-08-19 02:08:06 +0200 (Wed, 19 Aug 2009)
New Revision: 28024
Modified:
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[IO.pod] fix bogon-infested named parameter syntax
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
==
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #68652]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=68652 >
rakudo: role Self[Self] {}
rakudo 0d4fe0: OUTPUT«set_pmc_keyed() not implemented in
cl
On behalf of the Parrot team, I'm proud to announce Parrot 1.5.0
"TEH PARROTZ!." Parrot (http://parrot.org/) is a virtual machine aimed
at running all dynamic languages.
Parrot 1.5.0 is available on Parrot's FTP site, or follow the
download instructions at http://parrot.org/download. For those wh
On Tue, Aug 18, 2009 at 10:37 AM, Jan Ingvoldstad wrote:
>> It's not that unreasonable.
>
> I disagree, and I think I've explained why, and perhaps we won't get much
> further.
I'm not claiming that it's a good idea for bash to adopt this
behavior, only that it's a reasonable expectation tohave up
I don't think python is the only one with that problem, try saving a file with
non utf8 chars in subversion and see what happens.
We should be liberal in what we accept and strict in what we send as we really
don't know the filesystem will return to us. I guess a file read from the
filesystem coul
Leon Timmermans wrote:
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. [...]. I don't want to deal with Windows'
strange restrictions on characters when I'm working on Linux. I don't
want
2009/8/19 Timothy S. Nelson :
>
> Ok, so suppose we only allowed direct assignment to absolute paths?
>
That would be currently how it works.
--
Carlin
On Tue, Aug 18, 2009 at 3:52 PM, Mark J. Reed wrote:
> On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstad
> wrote:
> > You think it's a bug that PWD="/etc" doesn't change your working
> directory
> > to /etc in bash?
> >
> > Please tell me you're joking.
>
> It's not that unreasonable.
I disagree
On Tue, Aug 18, 2009 at 01:10:58PM +0200, Jan Ingvoldstad wrote:
> On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsen
> wrote:
> > Besides that, a simple check on Unix for what the locale is set to might
> > also be
> > nice, so we don't write UTF8 files on a filesystem where the rest for th
On Tue, Aug 18, 2009 at 15:20, Carl Mäsak wrote:
> Leon (>):
>> Reading this discussion, I'm getting the feeling that filename
>> literals are increasingly getting magical, something that I don't
>> think is a good development. The only sane way to deal with filenames
>> is treating them as opaque
On Tue, Aug 18, 2009 at 10:26 AM, Timothy S.
Nelson wrote:
> Ok, so suppose we only allowed direct assignment to absolute paths?
Is there an echo in here? :)
--
Mark J. Reed
On Wed, 19 Aug 2009, Carlin Bingham wrote:
2009/8/19 Timothy S. Nelson :
So, if P5 does it for some global (note: global != environment)
variables, then why not do it for some in P6?
Because if (for some reason) I do:
$> = 5; # Which calls setuid(5);
print $>; # 5
Whereas:
$*CWD =
On 2009-Aug-18, at 7:05 am, Mark J. Reed wrote:
On Tue, Aug 18, 2009 at 6:59 AM, Carlin Bingham> wrote:
2009/8/18 Timothy S. Nelson :
On Tue, 18 Aug 2009, Mark J. Reed wrote:
It's not in the revised spec, but I think that, even though
we've
revived chdir, we should still have it so tha
2009/8/19 Timothy S. Nelson :
>
> So, if P5 does it for some global (note: global != environment)
> variables, then why not do it for some in P6?
>
Because if (for some reason) I do:
$> = 5; # Which calls setuid(5);
print $>; # 5
Whereas:
$*CWD = '..'; # which hypothetically calls chdir
On Tue, 18 Aug 2009, Leon Timmermans wrote:
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making any
On Tue, 18 Aug 2009, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 2:33 PM, David Green wrote:
Huh. Thank you, I did not know that. It makes "sense" (in that I
understand what's going on now that I see it, and indeed it seems almost
obvious), but I certainly couldn't call it "expected" be
On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstad wrote:
> You think it's a bug that PWD="/etc" doesn't change your working directory
> to /etc in bash?
>
> Please tell me you're joking.
It's not that unreasonable. Given a variable that magically changes
depending on your working directory, having
+1
Carl Mäsak wrote:
Very nicely put. We can't predict the future, but in creating
something that'll at least persist through the next decade, let's not
do elaborate things with lots of moving parts.
Let's make a solid ground to stand on; something so stable that it
works uphill and underwater.
On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak wrote:
>
> Let's make a solid ground to stand on; something so stable that it
> works uphill and underwater. People with expertise and tuits will
> write the facilitating modules.
>
> To quote Kernighan and Pike: Simplicity. Clarity. Generality.
> I
On Tue, Aug 18, 2009 at 2:33 PM, David Green wrote:
>
> Huh. Thank you, I did not know that. It makes "sense" (in that I
> understand what's going on now that I see it, and indeed it seems almost
> obvious), but I certainly couldn't call it "expected" because I didn't. And
> I can guarantee I'
Leon (>):
> Reading this discussion, I'm getting the feeling that filename
> literals are increasingly getting magical, something that I don't
> think is a good development. The only sane way to deal with filenames
> is treating them as opaque binary strings, making any more assumptions
> is bound
On Tue, 18 Aug 2009, David Green wrote:
On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
Well, my main thought in this context is that the stuff that can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are di
On 2009-Aug-18, at 3:29 am, Jan Ingvoldstad wrote:
In general, executable documentation is a bad thing. It's been shown
to be a bad thing many times over.
Well, tons of programs have --help options, which could be considered
executable documentation, and it's very useful. Emacs brags about
On Tue, Aug 18, 2009 at 6:59 AM, Carlin Bingham wrote:
> 2009/8/18 Timothy S. Nelson :
>> On Tue, 18 Aug 2009, Mark J. Reed wrote:
>>
>> It's not in the revised spec, but I think that, even though we've
>> revived chdir, we should still have it so that changing $*CWD will do a
>> chdir under
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making any more assumptions
is bound to get you into trou
On 2009-Aug-18, at 5:48 am, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 1:02 PM, David Green
wrote:
It doesn't seem that surprising to me, especially after seeing the
docs the first time. Are there environments where you can set a
variable like $*CWD and it doesn't do something like chdi
Er, that "basename" down there should be a "dirname", for those
playing along at home. Memo to self: do not type long screeds on
Blackberry...
On 8/18/09, Mark J. Reed wrote:
> It would be nice if the bikeshed had aluminum siding. Er, I mean, if
> chdir() changed *CWD and vice-versa, though I'
It would be nice if the bikeshed had aluminum siding. Er, I mean, if
chdir() changed *CWD and vice-versa, though I'm not sure offhand how
best to code that in idiomatic P6 to avoid the infinite recursion.
Anyway, at the very least, a readonly *CWD holding a cached idea of
the current dir is good.
On 2009-Aug-18, at 1:24 am, pugs-comm...@feather.perl6.nl wrote:
+=head3 Default constraints
+
+The default p{} only allows "/" as separator and does not allow
path elements to contain
+characters that won't work on modern Windows and Unix like \ / ? %
* : | " > <,
+etc. The reason for this
On Tue, Aug 18, 2009 at 1:02 PM, David Green wrote:
> On 2009-Aug-18, at 3:12 am, Jan Ingvoldstad wrote:
>>
>> It may seem cool, but I don't like secondary effects like that. They break
>> the principle of least surprise.
>
> It doesn't seem that surprising to me, especially after seeing the docs t
On 2009-Aug-18, at 4:59 am, Carlin Bingham wrote:
2009/8/18 Timothy S. Nelson :
It's not in the revised spec, but I think that, even though
we've revived chdir, we should still have it so that changing $*CWD
will do a chdir under the hood.
While in the spirit of TIMTOWTDI, having a "
On Tue, Aug 18, 2009 at 13:10, Jan Ingvoldstad wrote:
> On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsen
> wrote:
>
>> My idea with portable by default was only portability for modern Unix and
>> modern Windows. So DOS and VMS limitations would not apply. The problem of
>> enforcing truly "p
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #68636]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=68636 >
Since the ins2 branch merge, you can't run the non-installed 'perl6'
fakexecutable from
2009/8/18 David Green :
> On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote:
>>
>> On Tue, 18 Aug 2009, David Green wrote:
>>>
> or however that would work in P6. It may have problems, but by definition
> they're the same problems as chdir() has. What am I missing?
>
>
chdir is a familar funct
On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
Well, my main thought in this context is that the stuff that
can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are differences, but the two are
a lot
the
Author: jani
Date: 2009-08-18 13:18:13 +0200 (Tue, 18 Aug 2009)
New Revision: 28020
Modified:
docs/Perl6/Spec/S16-io.pod
Log:
Rephrasing for clarity, also changed "POSIX" to "portable POSIX" where
appropriate
Modified: docs/Perl6/Spec/S16-io.pod
===
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsen wrote:
> My idea with portable by default was only portability for modern Unix and
> modern Windows. So DOS and VMS limitations would not apply. The problem of
> enforcing truly "portable" filenames is that the files names get too
> restrictiv
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #68594]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=68594 >
rakudo: IO.WHAT.say
rakudo 0d4fe0: ( no output )
I'd expect this to print "IO()" or
On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Maybe setting $*CWD just calls chdir() under the hood? Same
implementation, brand new shiny Perl-style interface!
That was my intent, but we had some discussions on IRC about the
whys and wherefores
2009/8/18 Timothy S. Nelson :
> On Tue, 18 Aug 2009, Mark J. Reed wrote:
>
> It's not in the revised spec, but I think that, even though we've
> revived chdir, we should still have it so that changing $*CWD will do a
> chdir under the hood.
>
While in the spirit of TIMTOWTDI, having a "magic
>> Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy
>> of enforced portable filenames by default, it should (at least) also exclude
>> - as the first character, and forbid more than one . in a filename.
>
> And, as I mentioned in an earlier post during the discussion, t
On Tue, 18 Aug 2009, Mark J. Reed wrote:
On Tue, Aug 18, 2009 at 11:04 AM, David Green wrote:
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
chdir provides functionality that would be quite convoluted to mimic
through manually setting $*CWD, such as changing to a relative
directory.
Mayb
Author: wayland
Date: 2009-08-18 12:16:37 +0200 (Tue, 18 Aug 2009)
New Revision: 28019
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
S32/IO: Mention that Path can be used as an array of path elements
S16: Restrict filenames to POSIX
Modified: docs/Per
On Tue, 18 Aug 2009, Troels Liebe Bentsen wrote:
Glob's are special and should properly have it's own sub format, the problem of
including * and ? in Path's is that on Unix this is a allowed file system name.
Agreed about the subformat, but I think the "glob" function is
sufficient in this c
> On Tue, Aug 18, 2009 at 11:04 AM, David Green wrote:
>> On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
>>>
>>> chdir provides functionality that would be quite convoluted to mimic
>>> through manually setting $*CWD, such as changing to a relative
>>> directory.
>>
>> Maybe setting $*CWD just c
On Mon, Aug 17, 2009 at 23:11, Jon Lang wrote:
>> The default p{} should only allow "/" as separator and should not allow
>> characters that won't work on modern Windows and Unix like \ / ? % * : | " >
>> <,
>> etc. The reason for this is that portable Path's should be the default and if
>> you re
Author: wayland
Date: 2009-08-18 11:47:04 +0200 (Tue, 18 Aug 2009)
New Revision: 28018
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S32/IO] A few changes, including:
* Revived .chdir() due to popular demand
* IO::FileNode merged into Path
Modified
On Tue, Aug 18, 2009 at 3:47 AM, David Green wrote:
> On 2009-Aug-17, at 12:27 pm, Moritz Lenz wrote:
>>
>> However it seems we have to pay a price: each act of rendering a Pod
>> file actually means executing the program that's being documented (at
>> least the BEGIN blocks and other stuff that ha
On Tue, 18 Aug 2009, David Green wrote:
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
chdir provides functionality that would be quite convoluted to mimic
through manually setting $*CWD, such as changing to a relative
directory.
Maybe setting $*CWD just calls chdir() under the hood? Same
On Tue, Aug 18, 2009 at 11:04 AM, David Green wrote:
> On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
>>
>> chdir provides functionality that would be quite convoluted to mimic
>> through manually setting $*CWD, such as changing to a relative
>> directory.
>
> Maybe setting $*CWD just calls chdi
On Tue, Aug 18, 2009 at 10:58 AM, Nicholas Clark wrote:
> Oh gosh yes. I forgot. AUX.TXT
> And all the the other CP/M device file names, with our without extensions...
>
>
> [And of course, IIRC, DOS filenames can't be more than 64 characters. Which
> means that your code thinks that it knows what
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
chdir provides functionality that would be quite convoluted to mimic
through manually setting $*CWD, such as changing to a relative
directory.
Maybe setting $*CWD just calls chdir() under the hood? Same
implementation, brand new shiny Perl-st
On Tue, Aug 18, 2009 at 10:36:45AM +0200, Jan Ingvoldstad wrote:
> On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clark wrote:
> > On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl
> > wrote:
> >
> >> +=head3 Default constraints
> >> +
> >> +The default p{} only allows "/" as sep
On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clark wrote:
> On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl wrote:
>
>> +=head3 Default constraints
>> +
>> +The default p{} only allows "/" as separator and does not allow path
>> elements
>> +to contain
>> +characters that won
2009/8/18 :
> Author: wayland
> Date: 2009-08-18 09:24:07 +0200 (Tue, 18 Aug 2009)
> New Revision: 28017
>
> +=item chdir FILENAME
> +X X
> +
> +=item chdir
> +
> +Gone, just set $*CWD (which throws an exception if it fails).
> +
chdir provides functionality that would be quite convoluted to mimi
On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl wrote:
> +=head3 Default constraints
> +
> +The default p{} only allows "/" as separator and does not allow path
> elements
> +to contain
> +characters that won't work on modern Windows and Unix like \ / ? % * : | " >
> <,
Author: wayland
Date: 2009-08-18 09:24:07 +0200 (Tue, 18 Aug 2009)
New Revision: 28017
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S28-special-names.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S02] Changed :io to :p and :path
[S16] Documen
64 matches
Mail list logo
