On Fri, Nov 12, 2010 at 8:21 PM, Stefan O'Rear wrote:
> This goes without saying. One caveat - it should be possible to pass
> integer file descriptors.
Integer file descriptions should exist in the POSIX module, just like
Win32 handles should exist in the Win32 module, but they don't have a
pla
On Wed, Oct 13, 2010 at 1:20 AM, Tim Bunce wrote:
> I've not used them, but Ruby 1.9 Fibers (continuations) and the
> EventMachine Reactor pattern seem interesting.
Continuations and fibers are incredibly useful and should be easy to
implement on parrot/rakudo but they aren't really concurrency.
On Wed, Oct 13, 2010 at 1:13 PM, Tim Bunce wrote:
> If you wanted to start a hundred threads in a language that has good
> support for async constructs you're almost certainly using the wrong
> approach. In the world of perl6 I expect threads to be used rarely and
> for specific unavoidably-bockin
On Wed, Oct 13, 2010 at 12:46 AM, Tim Bunce wrote:
> So I'd like to use this sub-thread to try to identify when lessons we
> can learn from ithreads. My initial thoughts are:
>
> - Don't clone a live interpreter.
> Start a new thread with a fresh interpreter.
>
> - Don't try to share mutable da
On Tue, Oct 12, 2010 at 10:28 PM, B. Estrade wrote:
>> I agree. I would prefer implicit over explicit concurrency wherever possible.
>
> I know you're speaking about the Perl interface to concurrency, but
> you seem to contradict yourself because message passing is explicit
> whereas shared memory
On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway wrote:
> The problem is: while most people can agree on what have proved to be
> unsatisfactory threading models, not many people can seem to agree on
> what would constititute a satisfactory threading model (or, possibly, models).
>
> What we really
On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg wrote:
> If thread-unsafe subroutines are called, then something like ithreads
> might be used.
For the love of $DEITY, let's please not repeat ithreads!
On Sun, Aug 1, 2010 at 11:39 PM, Martin D Kealey
wrote:
> In any case I'd much rather prefer that the behaviour be lexically scoped,
> with either adverbs or pragmata, not with the action-at-a-distance that's
> caused by tagging something as fundamental as a String.
In many cases the collation is
On Thu, Jul 29, 2010 at 9:51 PM, Aaron Sherman wrote:
> My only strongly held belief, here, is that you should not try to answer any
> of these questions for the default range operator on
> unadorned, context-less strings. For that case, you must do something that
> makes sense for all Unicode cod
On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan wrote:
> Some possible examples of customization:
>
> $foo ~~ $a..$b :QuuxNationality # just affects this one test
I like that
> $bar = 'hello' :QuuxNationality # applies anywhere the Str value is used
>
What if you compare a QuuxNationality St
On Wed, Jul 28, 2010 at 11:29 PM, Aaron Sherman wrote:
> The more I look at this, the more I think ".." and "..." are reversed. ".."
> has a very specific and narrow usage (comparing ranges) and "..." is
> probably going to be the most broadly used operator in the language outside
> of quotes, com
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
wrote:
> Would it make sense to define $*FS as the implied local file system, and
> thus that a bare 'open' is sugar for
> my $fh = $*FS.open('/path/to/directory/filename', :r);
>
> This then means that there is an implicit
> $*FS.connect();
> t
On Thu, Jun 10, 2010 at 2:07 PM, Mark J. Reed wrote:
> But open is already overloaded in p5, with pipes etc. We don't want
> to repeat the mistakes of the past, and the fact that open(FH, $foo)
> could run an arbitrary shell command was arguably a mistake, but
> transparent access to storage wher
On Thu, Jun 10, 2010 at 9:15 AM, Richard Hainsworth
wrote:
> Ideally [at least, what I would like], managing a file on a remote resource
> should be the same as managing one locally, eg.
>
> my Amazon $fn = open("$path-to-input-file-location/$file-name", :r) or die
> $!;
> for $fn.readlines { };
>
On Fri, Apr 2, 2010 at 5:59 PM, Aristotle Pagaltzis wrote:
> He is saying he can’t see how these differ from each other:
>
> .doit(1,2,3): { $^a <=> $^b } # okay
> + .doit(1,2,3): { $^a <=> $^b } # okay
>
> Or how these two differ from each other:
>
> + .doit(1,2,3):{ $^a <=
Maybe it's just me, but I don't see the value of having some
*arbitrary* predefined order for complex numbers. If people really
want to order their complex numbers, let them do it themselves in
whatever way they want.
Leon
On Mon, Mar 29, 2010 at 6:10 AM, Darren Duncan wrote:
> I was actually th
A space between the colon and the opening brace ;-)
Leon
On Sat, Mar 27, 2010 at 2:01 AM, Geoffrey Broadwell wrote:
> On Fri, 2010-03-26 at 08:38 +0100, pugs-comm...@feather.perl6.nl wrote:
>> .doit: { $^a <=> $^b } # okay
>> .doit(): { $^a <=> $^b } # okay
>>
lementing logic that belongs to the
filesystem sounds like really Bad Idea™ to me. Two paths can't be
reliably compared without choosing to make some explicit assumptions,
and I don't think Perl should make such choices for the programmer.
Leon Timmermans
On Fri, Aug 14, 2009 at 7:41 PM, David Green wrote:
> Well, we can encode a URI any way we like -- I was thinking of anything up
> to the next whitespace or semicolon, and internal semicolons, etc. being
> %-encoded.
Semicolons are reserved characters in URIs: inappropriately percentage
encoding
On Fri, Aug 14, 2009 at 12:34 PM, David Green wrote:
> Of course, this being P6, we can have some kind of "io" macro that parses
> the single item after it:
>
> my $file1 = io file://some/dir/some%20file; # the
> quick way
I don't think that's a good idea. In general, parsin
If you want to write a fast parser for XML, preventing backtracking is
going to be quite essential. I suspect the problem is your grammar,
not the grammar engine itself. You could post it to perl6-users and
ask for advice on it.
Leon
On Thu, Jun 4, 2009 at 7:25 AM, Richard Hainsworth wrote:
> Is
On Thu, May 21, 2009 at 4:18 PM, John M. Dlugosz
<2nb81l...@sneakemail.com> wrote:
> Can someone post a link?
http://svn.pugscode.org/pugs/docs/u4x/README
Google is your friend ;-)
2009/5/4 Damian Conway :
>
> Each approach has advantages and disadvantages.
> Feedback via this forum would be most welcome.
>
Most people seem to lean towards the pod comments, though I disagree
with it on a simple ground: aesthetics. Python docstrings aren't just
useful, they are reasonably pre
On Tue, Mar 10, 2009 at 12:09 AM, Larry Wall wrote:
>
> Yes, the only difference between C and C is that you can
> only use C at the start of a statement. But we're more liberal
> about where statements are expected in Perl 6, so you can say things
> like:
>
> my @results = do for @list -> $x
On Wed, Feb 25, 2009 at 5:56 AM, Timothy S. Nelson
wrote:
> Am I right in guessing that the AnyEvent stuff should go in S17 ?
>
I would suggest to rename that to Event (since unlike Perl 5 that name
is still available in Perl 6).
Leon
On Tue, Feb 24, 2009 at 1:13 AM, Timothy S. Nelson
wrote:
> On Mon, 23 Feb 2009, Leon Timmermans wrote:
>
>> I think most forms of IPC should be addons, if only because they have
>> inherent unportability. Stuff like sockets and pipes should be in
>> obviously, signals
I think most forms of IPC should be addons, if only because they have
inherent unportability. Stuff like sockets and pipes should be in
obviously, signals maybe (they have lots of portability issues, but
they may be too often used to just drop), but things like SysV IPC
really shouldn't. Anything m
On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky wrote:
> After some discussion I made a number of drastic revisions to
> S32-setting-library/Temporal.pod
>
> What I want to see in Perl 6 is a set of very minimal roles that can be used
> to provide a simply object from gmtime() and localtime(). These
On Wed, Feb 18, 2009 at 12:16 PM, Timothy S. Nelson
wrote:
> On Wed, 18 Feb 2009, Leon Timmermans wrote:
>
>The only difference I could see was that shutdown allows changing the
> readability and writeability. While I agree that this functionality should
> be exposed, (see
I'd like to note that FileDescriptors are not reserved unices. I know
Windows also has them (though they aren't commonly used), and quite
possibly others too.
Also, IO::Socket.close() is not an alternative for a shutdown()
method. They do subtly different things. IO::Socket should support
both IMH
> +role Date {
> + has Calendar $.calendar;
> + has NumberName $.year;
> + has NumberName $.month;
> + has NumberName $.dayofmonth;
> + has NumberName $.dayofweek;
> + has NumberName $.dayofyear;
> + has NumberName $.dayofquarter;
> + has NumberName
On Sat, Feb 14, 2009 at 10:31 PM, Brandon S. Allbery KF8NH
wrote:
>
> I think the point here is that on POSIX systems that gets you ioctl() and
> fcntl(), and on non-POSIX systems either they don't exist or they throw
> runtime errors. Aside from my earlier suggestion that non-POSIX systems
> gen
* hate that interface, and I don't see how it covers an
accepting socket.
IMO there should be two calls
method IO connect($RemoteHost, $RemotePort, *%options)
where *%options can contain things like the local address,
non-blockingness, etc...
method IO::Accepting listen($LocalHost, $LocalPort, *%options)
role IO::Accepting does IO::Socket {
IO accept();
}
> -=head1 Input and Output
> +=head2 IO::Pipe
>
> -=over 4
> +class IO::Pipe does IO::POSIX does IO::Closeable does IO::Openable {
> +...
> +}
Why should this do POSIX? What about non-POSIX operating systems?
Regards,
Leon Timmermans
On Wed, Feb 4, 2009 at 4:37 PM, wrote:
> +=head2 IO
> +
> +The base role only tags that this is an IO object for more generic
> +purposes. It doesn't specify any methods or attributes.
> +
Shouldn't IO::readable and IO::Writable do IO?
> +
> +=head2 IO::Closeable
> +
I still think this should
urage doing just that). I don't understand what's the
question, really.
Though if you mean with open() that is should do what PHP's fopen does
(open anything, from files to http connections and more): absolutely
not. That's the kind of behavior that must be explicit, else we open
up to a whole range of security problems.
Regards,
Leon Timmermans
:async> flag lets the call
> +return an undefined value if no character is immediately available.
>
IMHO it would be better to call that non-blocking IO instead of
asynchronous IO, but I'm POSIX-biased.
Regards,
Leon Timmermans
When going OO, I'd say an augment()/inner() approach would be
cleanest. See
http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook/Basics/Recipe6.pod
for an example. I don't know how to express that in Perl 6 though.
Regards,
Leon
On Fri, Jan 2, 2009 at 2:08 AM, Steve Lukas wrote:
> Hello,
>
I can't help wondering "why does pid_file_handler need to be split up
in the first place?" Why wouldn't it be possible to simply call
pid_file_handler after become_daemon?
Regards,
Leon Timmermans
On Thu, Jan 1, 2009 at 10:34 PM, Geoffrey Broadwell wrote:
> In t
:
$fstab does WhitespaceTrim does TranslateKlingon;
I'm not sure if this is the best way to approach the problem though.
This is a power drill, a screwdriver will also do in many cases.
> If so, how do you specify direction?
That would be a problem with this approach. You'd probably need
separate roles for readers and writers.
Regards,
Leon Timmermans
On Mon, Dec 15, 2008 at 8:47 PM, Stephen Weeks wrote:
> do {
>die 'some text';
>say 'after the exception';
>CATCH {
>say 'caught the exception';
>...; # what goes here?
>}
> }
>
> My proposal is to call .resume() on the exception object.
>
> Thoughts?
>
The spec sa
;
> my File $fstab = new(:name, :filter)
>
You can already easily mix it in using 'does':
$fstab = open('/etc/fstab', :r);
$fstab does WhitespaceTrim;
I don't think it's really necessary to include that into open(),
though it might be useful syntactic sugar.
Regards,
Leon Timmermans
by
> printing it or showing it in a GUI to be clicked on, is separated from the
> OS/locale-dependent underlying_name (which may not be easily displayed on a
> standard GUI – suppose it is in ancient Buriyat), then identifying nodes and
> traversing a network of nodes could be made abstract enough to handle all
> sorts of environments.
>
> Perhaps, too a module for a specific environment, eg., Windows, would
> provide the syntatic sugar that makes specifying a location look like
> specifying a directory natively, eg.
> use IO::Windows;
> my Location $x .= new(:OSpath);
> whilst for linux it would be
> use IO::Linux;
> my Location $x .=new(:OSpath);
>
> This started as short wish list and got far too long. Sorry
>
I think a File::Spec-like approach would be better.
Regards,
Leon Timmermans
On Fri, Dec 12, 2008 at 3:04 AM, Jon Lang wrote:
> One of the things about roles is that once you have composed a bunch
> of them into another role, they're considered to be composed into
> whatever that role is composed into. So "does File" would be
> equivalent to "does Mappable does Pollable d
$remote_host, $port, :type);
would return a Socket & Buffered & Pollable & Writable
Regards,
Leon Timmermans
On Mon, Dec 8, 2008 at 8:16 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> It looks like Python 3000 just tried that.
>
> People are not happy about it:
> http://utcc.utoronto.ca/~cks/space/blog/python/OsListdirProblem
>
Yeeh, I also noted exactly that problem when reading the "What's New
In
MHO the spec on === is quite clear: "two values are never equivalent
unless they are of exactly the same type." IMHO, you shouldn't be
using === but == anyway when doing that kind of numerical work. That
one should DWIM.
Regards,
Leon Timmermans
collation, not (just) character set. TIMTOWTDI.
There is no right way to do it as it depends on the circumstances, but
a simple binary sort is not a bad default.
Leon Timmermans
ance)
A \x2F always means a '/'. UTF-8 was designed to be backwards
compatible like that.
Regards,
Leon Timmermans
On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote:
> Do I understand your question right, that you want the return
> of == to be false because there is a one(1,0,1) junction? As
> Duncan points out junctions are immutable values and as such
> the % autothreads but the resulting values
> According to Synopsis 2, under "Immutable types", a Junction is a "Set with
> additional behaviors". This implies to me a Junction consists just of
> distinct unordered values. A Junction is not a Bag and it doesn't matter
> that we lose the fact that a value occurred more than once in the argu
50 matches
Mail list logo
