Parallelism and Concurrency II

Hi, After lots of debates off-list (specially with BrowserUk), I got to the following conclusions: - Each OS thread runs a cooperative-event-scheduler where coroutines might be enqueued. - map returns the buffer immediatly and enqueues a coroutine to process the data. - Explicit parall

Re: Re: Parallelism and Concurrency was Re: Ideas for a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading model (nntp: message 20 of 20 -lastone!-) (nntp: message 13 of 20)

Em Ter, 2010-05-18 às 12:58 -0700, Alex Elsayed escreveu: > You are imposing a false dichotomy here. Neither 'green' threads nor kernel > threads preclude each other. In fact, it can be convincingly argued that they > work _best_ when combined. Please look at the GSoC proposal for hybrid > threadi

Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model

Em Ter, 2010-05-18 às 15:15 +0100, nigelsande...@btconnect.com escreveu: > > 1) the interpreter doesn't need to detect the closed over variables, so > > even string eval'ed access to such variables would work (which is, imho, > > a good thing) > You'd have to explain further for me to understand wh

Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model

Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu: > Interoperability with Perl 5 and > is reference counting should not be a high priority in the decision making > process for defining the Perl 6 concurrency model. If we drop that requirement then we can simply go to the

Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message (nntp: message 18 of 20) 14 of 20) "Object-Belongs-to-Thread" threading model

Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu: > 3) The tough-y: Closed-over variables. > These are tough because it exposes lexicals to sharing, but they are so > natural to use, it is hard to suggest banning their use in concurrent > routines. This is the point

Re: Parallelism and Concurrency was Re: Ideas for a (nntp: message 14 of 20) "Object-Belongs-to-Thread" threading model

Em Sex, 2010-05-14 às 18:13 +0100, nigelsande...@btconnect.com escreveu: > The point I(we)'ve been trying to make is that once you have a reentrant > interpreter, and the ability to spawn one in an OS thread, > all the other bits can be built on top. But unless you have that ability, > whilst t

Re: Parallelism and Concurrency was Re: Ideas for a "Object-Belongs-to-Thread" threading model

Em Sex, 2010-05-14 às 15:48 +0400, Richard Hainsworth escreveu: > The less, or rather the more abstract, the specification in perl6, the > less likely perl6 will 'age'. I think the important thing to realize here is that the Perl 6 language keeps its definitions mostly abstract. Junctions, Hyper O

Re: Ideas for a "Object-Belongs-to-Thread" threading model

Em Qua, 2010-05-12 às 10:12 -0700, Dave Whipp escreveu: > Before discussing the implementation, I think it's worth while > stating > what it is that you are attempting to abstract. For example, is the > abstraction intended for a mapping down to a GPU (e.g. OpenCL) with a > hierarchical address

Third and simplified version of Ideas for a "Object-Belongs-to-Thread" threading model

Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu: > he threading model topic still needs lots of thinking, so I decided to > try out some ideas. After I sent the second version, I just realized I could make it simpler by just assuming "one OS thread per Coroutine Group"

Second Version of Ideas for a "Object-Belongs-to-Thread" threading model

Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu: > The threading model topic still needs lots of thinking, so I decided to > try out some ideas. After BrowserUK feedback and some more reading (including http://www.c2.com/cgi/wiki?MessagePassingConcurrency ) and links from there

Re: Ideas for a "Object-Belongs-to-Thread" threading model

BrowserUK wrote: > > -there are the interpreter processes. > > Inventing (overloaded) terminology will just create confusion. Very > > unhelpful in a context that suffers more than its fair share already. Okay, I should probably call them "Actors" to use a more precise terminology - since this

Ideas for a "Object-Belongs-to-Thread" threading model

Hi, The threading model topic still needs lots of thinking, so I decided to try out some ideas. Every concurrency model has its advantages and drawbacks, I've been wondering about this ideas for a while now and I think I finally have a sketch. My primary concerns were: 1 - It can't require lock

Re: Methodicals: A better way to monkey type

Em Qua, 2010-04-21 às 00:16 -0700, Stefan O'Rear escreveu: > Normally, when you write a method call, the definition of the method is > entirely in the domain of the receiver's class: > $object.make-me-a-sandwich; # $object gets to decide what this means Actually, this is delegated to the disp

Re: underscores vs hyphens (was Re: A new era for Temporal)

Em Dom, 2010-04-11 às 07:54 -0700, Damian Conway escreveu: > The relevant suggestion regarding hyphens vs underscores is: > "...to allow both characters, but have them mean the same thing." er... this smells like :: and ' in Perl 5... Which, while I find Acme::Don't amusing, cannot be stated a

Re: underscores vs hyphens (was Re: A new era for Temporal)

Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: > I'm having trouble imaging any convention that involves mixing word > separators being successful. But the convention Damian is proposing is simply "use underscores". Basically camelCase and with_underscores are conventions on "how to c

Re: A common and useful thing that doesn't appear to be easy in Perl 6

Em Ter, 2010-04-06 às 22:19 -0700, Damian Conway escreveu: > > I kinda hope we can get a bit further away from the machine code > > level of reality one of these decades. Perl 6 should not be > > optimized for C semantics. > Agreed. But it should at least support those who need to work at > the ma

Re: You never have privacy from your children in Perl 6

Em Ter, 2010-03-23 às 20:53 +0100, Moritz Lenz escreveu: > unless you count 'trusts' > traits, which are specific to single classes, not groups of subclasses Yes, that was what I meant... daniel

Re: You never have privacy from your children in Perl 6

Em Ter, 2010-03-23 às 19:41 +0100, Carl Mäsak escreveu: > um, so 'protected' is when the deriving classes can see the > attribute? > yup > that's what 'private' means in Perl 6. > what? so there's only really 'public' and 'protected', but no > 'private'? > basically, yes. although 'protected'

Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)

Em Sáb, 2010-03-20 às 22:23 +0300, Richard Hainsworth escreveu: > Here it is the very language that is changing. > For instance, =$fh was used to generate input from a file. Now it is > $fh.lines Note that I did mention versioned dependencies for grammar, CORE and setting. So yes, considering the

Versioned Dependencies (Was: Re: Stability domains in rakudo *)

Em Sáb, 2010-03-20 às 12:16 +0300, Richard Hainsworth escreveu: > Suppose we define a domain of stability as syntax/functionality/features > that will not be changed until a milestone is reached, with the > guarantee that if the language specification changes before then, > backwards compatibili

Re: Functional-style pattern matching

Em Seg, 2010-03-08 às 12:45 -0800, Little Walker escreveu: > I've been looking around to see if there's been any discussion of > introducing functional programming-style pattern matching for method/ > function dispatch. Could someone point me to any such discussions? a Tree matching language is o

Re: Temporal seems a bit wibbly-wobbly

2010/2/22 Mark J. Reed > If the interface between Perl time and human time is going to be done > through UTC, then I don't see the point in specifying that it's TAI > behind the scenes. Especially if you're not specifying the epoch. > The number of seconds between two points in time in UTC is ex

Re: Temporal seems a bit wibbly-wobbly

Em Seg, 2010-02-22 às 13:31 -0500, Mark J. Reed escreveu: > > I'd just like to add that Instant is not "more-or-less" opaque. It is > > "entirely" opaque. > Not according to S02, which says that an Instant will numify to the > number of TAI seconds since "the TAI epoch". That's not opaque. I'd ju

Re: Temporal seems a bit wibbly-wobbly

Em Dom, 2010-02-21 às 21:28 -0800, Larry Wall escreveu: > On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote: > : I just want to know what Perl 6 time zero is. > Well, there's no such thing as time 0 in Perl 6, in the sense that > Instant is more-or-less opaque. I'd just like to add that

Re: Temporal seems a bit wibbly-wobbly

Em Dom, 2010-02-21 às 21:09 -0800, Larry Wall escreveu: > I now see that the most important determinant of DateTimes is > neither the Dates nor the Times themselves, but which TZ you're in. > I propose renaming Temporal to TZ, so we get TZ::Date, TZ::Time, etc, > since they're all dependent primari

Re: 99problems-31-to-40 failure

Em Qui, 2009-10-01 às 12:22 -0400, Kevin Phair escreveu: > This test fails for me with the latest Rakudo. It looks like this is > because when a variable is pushed onto an array, and then > auto-incremented, it is also auto-incremented inside the array. > my @stuff; > my $w = 1; > @stuff.push($w

Re: Lenses?

Em Sáb, 2009-09-26 às 16:14 +1000, Timothy S. Nelson escreveu: > I've been wondering about lenses recently. The page at > http://www.seas.upenn.edu/~harmony/ seems to give an overview, and I know > that > augeas also uses lenses. > It seems to me that a grammar can be thought of as

Re: Should .^methods be curried with the invocant?

Em Sex, 2009-09-25 às 18:28 +0200, Moritz Lenz escreveu: > class A { method m { say 'OH HAI' } }; > my $m = A.new.^methods(:local).[0]; > How should I invoke $m? > In current Rakudo this works: > $m(A.new);# supply the invocant as first argument > But shouldn't be just $m() (invocant magically

Re: r28213 - docs/Perl6/Spec/S32-setting-library

Em Qua, 2009-09-09 às 09:07 -0400, Mark J. Reed escreveu: > I would change the doc to refer to TAI as a "time scale", and also > avoid referring to the numerical value of an Instant as an "epoch". I knew there was something wrong in my use of that terms, please fix it if you like... daniel

Re: s/ DateTime <-> Instant / TAI /

Em Qua, 2009-09-09 às 14:49 +0400, Richard Hainsworth escreveu: > Carl Mäsak wrote: > > I fear that the "Instant" from S02 is a fossil. "Instant" was renamed > > by Dave Rolsky to "DateTime" on 2009-02-19. > There was fairly extensive discussion. My recollection was that > 'Instant' and 'Duration'

Re: Synopsis 02: Range objects

Em Seg, 2009-08-24 às 23:50 +0200, Michael Zedeler escreveu: > The most elegant solution would be if the data types themselves > indicated their capabilities. One thing I think you missed entirely is the fact that the infix:<..> operator is a multi sub, so it falls to regular dispatch semantics,

Re: Custom object constructors

Em Qua, 2009-08-19 às 15:37 -0700, Kevan Benson escreveu: > Should there not be a way to define object constructors with custom > signatures that can be usefully invoked like a normal constructor? What's the problem with method new(Str $timestamp) { self.SUPER::new(ts => strptime('...',$times

Re: xml grammar

Em Seg, 2009-08-03 às 11:04 +1000, Timothy S. Nelson escreveu: > However, my main reason for modifying it was that I needed actions for > what I'm doing. So I'll keep working on that. http://gist.github.com/161467 just to tease :) -- this making the grammar closer to the XML spec... dani

Re: .match and .subst set outer $/?

Em Dom, 2009-07-12 às 22:51 +0200, Moritz Lenz escreveu: > I setting of OUTER::$/ considered syntactic sugar? > I don't care either way, I'd just like some clarification so that I can > write tests and submit tickets (if appropriate). As far as I remember, it's not really OUTER::$/, but each routi

RFC: overriding methods declared by roles (Was: Re: Reusing code: "Everything but the kitchen sink")

Em Sex, 2009-07-10 às 15:39 -0700, Jon Lang escreveu: > The key to understanding roles is to note that roles don't implement > methods; classes implement methods. Er, while I see your point, Roles are not just interfaces... they are OO components that can be plugged into other classes. They often

Re: Re-thinking file test operations

Em Qui, 2009-07-09 às 22:50 -0400, Buddha Buck escreveu: > Both the separate pathname type and the stat($str, :e) proposal > salvage the purity of Str, so either would be acceptable to your > argument. The bigger problem of using a different type is that "/etc/passwd" ~~ :e Would dispatch to S

Private methods in Roles (Was: Re: YAPC::EU and Perl 6 Roles)

Em Qua, 2009-07-08 às 12:49 -0700, Ovid escreveu: > Behavioral: if you are primarily relying on roles to provide behavior > (as we do at the BBC), then silently discarding the role's behavior by > providing a method of the same name in your class can lead to very > confusing bugs. I've lost a lot

Re: Why pass by reference?

Em Dom, 2009-06-14 às 15:53 -0500, John M. Dlugosz escreveu: > In Perl 6, the default parameter passing is to make a read-only alias > for the caller's lvalue. This means that the function may not change > the caller's variable, but must track changes to it made by other means. > What is the poi

Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))

Em Sex, 2009-06-12 às 11:52 -0700, Jon Lang escreveu: > On Fri, Jun 12, 2009 at 11:51 AM, Daniel Ruoso wrote: > > Ok, There's one thing that is not clear in the thread, which is when an > > array is multidimensional or not... > > For instance: > > @a = (1, 2

Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))

Ok, There's one thing that is not clear in the thread, which is when an array is multidimensional or not... For instance: @a = (1, 2, 3; 4, 5, 6; 7, 8, 9); Will produce a flatten array, because list assignment causes flattening, so the dimensionality was lost. It is important to remember that

Implicit threading vs Imperative barriers

Hi, Following my last reasoning on implicit threading and implicit event-based programming[1], I came to two interesting realizations... 1 - Every object is potentially lazy, not only lists. 2 - Lazy doesn't mean "wait until I need the data", but "don't stall me because of that data". That bas

Re: The game of life

Em Qui, 2009-05-28 às 00:26 -0500, John M. Dlugosz escreveu: > Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote: > > Perhaps Perl 6 should not aspire to the expressiveness of APL. :) As > > nice as it is that you can write Conway's Life in a one-liner(*), I > > think that a little verbosity now

Re: CPAN -- moving forward

Em Sáb, 2009-05-30 às 22:54 +0200, Daniel Carrera escreveu: > In the hopes of helping the CPAN discussion move forward, in the > direction of tangible work, I have made a wiki page with a proposal: > Please read the "Basics" section, which is quite short. The main point > of this section is to di

Is the Perl community just about Code? (Was: Re: New CPAN)

Em Sex, 2009-05-29 às 23:37 +0200, Daniel Carrera escreveu: > Your idea of using CPAN to share holiday pictures is one of the things > that really turned me off from your CPAN6 proposal. If you replace "holiday pictures" by 'YAPC pictures', 'Talk slides', 'Code Snippets', 'Perl related scientific

Re: [RFC] CPAN6 requirements analysis

Em Sex, 2009-05-29 às 01:54 +0200, Daniel Carrera escreveu: > Larry Wall wrote: > > I support the notion of distributing binaries because nobody's gonna > > want to chew up their phone's battery doing unnecessary compiles. The > > ecology of computing devices is different from ten years ago. > By

Re: Illustration of stuff we've been discussing

Em Qui, 2009-05-28 às 09:27 -0500, John M. Dlugosz escreveu: > Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: > > Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: > >> Please see <http://www.dlugosz.com/Perl6/web/info-model-1.html> > >> and talk to

RFC: How does using CPAN with Perl 6 would look like (Was: Re: New CPAN)

Em Qui, 2009-05-28 às 16:18 +0200, Daniel Carrera escreveu: > Hello all, > There was some talk on IRC about a new version of CPAN to match the new > version of Perl. I just wanted to point out some previous conclusion on this issue. What currently we generically name "CPAN" is actually composed

Re: Amazing Perl 6

Em Qui, 2009-05-28 às 21:36 +1000, Damian Conway escreveu: > Mark J. Reed asked: > > ? And if &[+] means &infix:<+>, how do I refer to the Code of the > > list operator [+]? > &prefix:<[+]> Is that really? I mean... [ ] is a meta-operator, so [+] 1, 1, 2, 3 isn't a prefix, but a [ ] meta with

Re: Illustration of stuff we've been discussing

Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu: > Please see > and talk to me about it. The illustratino is cool, but it doesn't take into account the possibility of: @a[0] := $x; which means that an array is, theoretically, an a

Re: How to write this "properly" in Perl 6?

Em Qua, 2009-05-27 às 23:46 +0200, Carl Mäsak escreveu: > Not sure if I grokked the whole set of rules, but here's a one-liner > that does it: > $ perl6 -e 'say (, "bon" xx ++$*n, "digi" xx > $*n).join(", ") while *' It does, but it would be prettier if it was lazy... for 2..* -> $n { (, "bon" xx

Re: Amazing Perl 6

Em Qua, 2009-05-27 às 18:46 +0200, Daniel Carrera escreveu: > Hi Daniel, Hi Daniel, :P > Sounds very interesting. Can you post slides? It'd be cool if the talk > was taped, like the Google tech talks. Will it be in English? I don't > speak Portuguese (I do speak Spanish and some German). It wil

Amazing Perl 6

Hi, As I recently mentioned in IRC, I'm going to give a talk about Perl 6 in the International Free Software Forum in Porto Alegre, Brazil. For those who don't know FISL, it's one of the biggest events in the world with ~ 5k people attending (http://www.fisl.org.br). This talk is not targetted on

RFC: Implicit threading and Implicit event-loop (Was: Re: Continuations)

Em Ter, 2009-05-26 às 19:33 -0700, Jon Lang escreveu: > "The exact semantics of autothreading with respect to control > structures are subject to change over time; it is therefore erroneous > to pass junctions to any control construct that is not implemented via > as a normal single or multi dispat

Re: Question for Larry

Em Seg, 2009-05-25 às 11:36 -0500, John M. Dlugosz escreveu: > Can you tell me if I'm missing something fundamental here? While I'm not larry, I think I can help you out here ;) > Regarding "item containers" ... > my @A = (1, 2, 3); > my $x; # default to "is Scalar" > $x = @A; '$x'

Re: Meditations on a Loop

Em Sex, 2009-05-22 às 18:27 -0500, John M. Dlugosz escreveu: > Daniel Ruoso wrote: > > That's because dot is an operator as well and might be subject to be > > overriden... but don't tell anyone that... > You mean by installing a different dispatcher for the object? By

Re: Meditations on a Loop

Em Qui, 2009-05-21 às 20:21 -0500, John M. Dlugosz escreveu: > but it was crudly inserted, so just before it the text still reads, "The > "dot" form and the indirect object form DEFAULT to method calls. All > other prefix calls DEFAULT to subroutine calls." (emphasis mine), That's because dot i

Re: Meditations on a Loop

Em Sex, 2009-05-22 às 01:25 -0500, John M. Dlugosz escreveu: > @primes = do $_ if prime($_) for 1..100; > becomes > @primes = $_ when prime($_) for 1..100; you gained one stroke, it's certainly better... I think it's time to play golf with Perl 6 already ;) jokes aside, "$_ when prime($_

Re: Meditations on a Loop

Em Qui, 2009-05-21 às 21:33 -0300, Daniel Ruoso escreveu: > my @x = map { $_ * 2 for 1,2,3 }, 1,2,3; > say @x[0]; # 1; > say @x[0;0]; # ERROR > say @x[1]; # 1; > say @x[1;0]; # ERROR er... there should be a 2 as output of the fourth line there... daniel

Re: Meditations on a Loop

Em Qua, 2009-05-20 às 19:55 -0500, John M. Dlugosz escreveu: > If you would be so kind, please take a look at > . I spent a couple days > on this, and besides needing it checked for correctness, found a few > issues as well as more food for though

Re: Meditations on a Loop

Em Qua, 2009-05-20 às 20:58 -0500, Patrick R. Michaud escreveu: > On Wed, May 20, 2009 at 07:55:55PM -0500, John M. Dlugosz wrote: > > If you would be so kind, please take a look at > > . > "The reason this [.prime] works is because the method

Re: Call for review: traits, lift

Em Dom, 2009-05-03 às 21:15 -0700, Larry Wall escreveu: > On Sun, May 03, 2009 at 08:20:17PM +0200, Moritz Lenz wrote: > : If I understood the specs correctly, variables can be lifted, so you can > : write > : > : sub f() {lift $a + $b}; > : { > : my $a is context = 3; > : my $b is context

Re: FYI - modern Muldis D code examples

Em Qua, 2009-04-08 às 01:04 -0700, Darren Duncan escreveu: > To recap, Muldis D is my new programming language part of whose purpose is to > eventually succeed SQL as the query+DDL language of choice for relational > DBMSs, > in the same manner that Perl 6 is intended to eventually supplant Perl 5

Re: S08 Draft questions (Captures and Signatures)

Em Qua, 2009-04-01 às 05:41 -0700, Jon Lang escreveu: > On Wed, Apr 1, 2009 at 5:07 AM, Daniel Ruoso wrote: > > The concept of "invocant" only exists in terms of syntax now. In runtime > > the invocant is simply the first positional argument. This simplifies > >

Re: S08 Draft questions (Captures and Signatures)

Em Ter, 2009-03-31 às 22:54 -0700, Jon Lang escreveu: > Yes, I know that there is no S08. I'm working on writing one, and I'd > like some feedback to help me do so. ++ > My draft is going to be about Signatures and Captures. Thus, my questions: > Invocants: The concept of "invocant" only exist

Re: On Junctions

Em Dom, 2009-03-29 às 22:57 -0700, Mark Lentczner escreveu: > What I see here is that there is a tendency to want to think about, > and operate on, the eigenstates as a Set, but this seems to destroy > the "single value" impersonation of the Junction. > Further, if one ever calls .!eigenstates(

Re: On Sets (Was: Re: On Junctions)

Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu: > Daniel Ruoso wrote: > > The thing is that junctions are so cool that people like to use it for > > more things than it's really usefull (overseeing that junctions are too > > much powerfull for that use

Re: On Junctions

Em Sáb, 2009-03-28 às 16:17 +1100, Damian Conway escreveu: > Nested heterogeneous junctions are extremely useful. For example, the > common factors of two numbers ($x and $y) are the eigenstates of: > all( any( factors($x) ), any( factors($y) ) ) I think that's the exact case where we should b

Re: On Sets (Was: Re: On Junctions)

Em Sex, 2009-03-27 às 09:17 -0400, Mark J. Reed escreveu: > From a high-level perspective, the blackjack example seems perfect for > junctions. An Ace isn't a set of values - its one or the other at a > time. It seems to me if you can't make it work with junctions - f you > have to use sets inste

Re: On Sets (Was: Re: On Junctions)

Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu: > So I get that we do need some cool support for sets as well, I mean... > no collapsing, no autothreading... but maybe some specific behaviors... As an aditional idea... multi infix:<⋃>(Set $a, Set $b) {...} multi infix:<

On Sets (Was: Re: On Junctions)

Em Sex, 2009-03-27 às 13:36 +0300, Richard Hainsworth escreveu: > On #perl6, rouso, masak and moritz_ explained that I am incorrectly > thinking about junctions as sets and that for this task I should be > using another perl idiom, namely lists. Sorry for not taking each individual point on your

Re: use v5 Support

Em Qua, 2009-03-25 às 23:11 -0500, jason switzer escreveu: > S01 says that perl5 code will be supported via "use v5". Can someone confirm > that embedded perl5 code is still required of any valid implementation? I wouldn't think it would be a really bad idea if inline "use v5" inside Perl 6 code t

Re: Logo considerations

Em Ter, 2009-03-24 às 09:17 -0400, Mark J. Reed escreveu: > Are we seeking a logo for Perl 6 in general or Rakudo in particular? > It seems like the latter should be derived from the former, perhaps > with the Parrot logo mixed in. are you suggesting that the cat should be eating a parrot in the r

Re: Logo considerations

Em Ter, 2009-03-24 às 09:01 -0300, Daniel Ruoso escreveu: > A zombie cat? While I wasn't really serious about it... <>

Re: Logo considerations

Em Seg, 2009-03-23 às 21:47 -0700, Darren Duncan escreveu: > If you're going for sciencey or mathey illustrations, then I think its > important > to include something that speaks quantum physics in there, since quantum > superpositions aka Junctions are one of the big central user features that

Re: r25891 - in docs/Perl6/Spec: . S32-setting-library

Em Sex, 2009-03-20 às 14:08 +0100, Jonathan Worthington escreveu: > It's probably a minor issue, but part of me wants Junction to be OK too > for explaining stuff. Telling people the default parameter type is Any, > to accept anything they can write Object and to accept just junctions > you writ

Re: r25891 - in docs/Perl6/Spec: . S32-setting-library

Em Qua, 2009-03-18 às 18:50 -0700, Larry Wall escreveu: > On Wed, Mar 18, 2009 at 06:32:18PM -0700, Jon Lang wrote: > : > +method !eigenstates (Junction $j: --> List) > : > : Shouldn't that be lowercase-j junction? > Maybe, though there might be a Junction role involved for subtype > matches l

Re: Recursive Runtime Role Reapplication Really Rebounds

Em Qui, 2009-03-12 às 11:49 -0700, Larry Wall escreveu: > In addition to what Jonathan said, it is possible that the ability > to coerce multiple arguments depends on the type itself, since we > probably want to allow Foo(1,2,3) and such for listy types that > don't necessarily want to use the [1,2

Re: Recursive Runtime Role Reapplication Really Rebounds

Em Qui, 2009-03-12 às 19:07 +0100, Jonathan Worthington escreveu: > IIRC, that's a special syntactic form that only counts when it is on the > RHS of but or does. (And yes, in this case it fails if the role has more > than one attr...) I think in all other cases, it's a coercion. hmm... for som

Re: Recursive Runtime Role Reapplication Really Rebounds

Em Qui, 2009-03-12 às 10:28 -0700, Larry Wall escreveu: > On Thu, Mar 12, 2009 at 08:51:45AM -0700, Ovid wrote: > : > From: David Green > : > I suppose, but is there a reason why you want to apply roles instead of > coercing > : > the results? > : Because I am coming from Moose instead of Perl 6

Re: .map/.reduce with larger arity

Em Seg, 2009-03-09 às 12:24 -0700, Larry Wall escreveu: > On Mon, Mar 09, 2009 at 02:40:43PM -0300, Daniel Ruoso wrote: > : ... $capture ~~ $signature ...; > : my $args_matched = @($/).elems; > : &code.(|$/); > That API still would not tell the match whether signature must

Re: .map/.reduce with larger arity

Em Dom, 2009-03-08 às 21:31 -0700, Larry Wall escreveu: > I think the basic rule has to be simply can the signature bind to > the remaining arguments. If not, we get a warning on unused arguments. Just to put here an idea I sent on irc... What if Signature.ACCEPTS set $/ with the matched argumen

Re: [pugs-commits] r25698 - docs/Perl6/Spec/S32-setting-library

Em Sex, 2009-03-06 às 18:51 +0100, TSa escreveu: > I know that the use of 'is also' is called monkey patching but I can't > understand why this is regarded as a bad thing. Having a class assembled > from multiple modules is a rather normal affair. You're describing Roles here, which is something y

Re: new Capture behavior (Was: Re: r25685 - docs/Perl6/Spec)

Em Qui, 2009-03-05 às 18:43 -0800, Jon Lang escreveu: > OK; let me get a quick clarification here. How does: > say "Hello, World!"; This is the equivalent to &say.postcircumfix:<( )>( \("Hello, World") ); > differ from: > "Hello, World!".say; This is just "Hello, World!".say; Mean

Re: new Capture behavior (Was: Re: r25685 - docs/Perl6/Spec)

Em Qui, 2009-03-05 às 12:58 -0300, Daniel Ruoso escreveu: > What really got me confused is that I don't see what problem this change > solves, since it doesn't seem that a signature that expects an invocant > (i.e.: cares about invocant) will accept a call without an invocant,

new Capture behavior (Was: Re: r25685 - docs/Perl6/Spec)

Em Qua, 2009-03-04 às 20:21 +0100, pugs-comm...@feather.perl6.nl escreveu: > Simplify meaning of Capture and Match in item context to preserve sanity > (an object in item context is always just itself, never a subpart) sub foo { return 1 } my $a = foo(); That is currently expressed as tak

Re: $?OS change

Em Seg, 2009-03-02 às 10:39 -0300, Daniel Ruoso escreveu: > Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu: > > Are we talking about $?VM vs. $?XVM here? > Well, yes... that adresses $?HOST_PERL and $?TARGET_PERL... but still > leaves $?HOST_ARCH and $?TARGET_ARC

Re: $?OS change

Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu: > On Mon, 2 Mar 2009, Daniel Ruoso wrote: > > So, I think the proper name to the variables would be > > $?ARCH and $*ARCH > > Where they would stringify to the arch triplet, while providing > > convenience

Re: $?OS change

Em Seg, 2009-03-02 às 17:04 +1100, Timothy S. Nelson escreveu: > Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $* > counterparts). I'd like to recommend that we eliminate $?OS, and replace it > with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts? The usual way

Re: Comparing inexact values (was "Re: Temporal changes")

Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu: > $y.error = 0.001; > $x ~~ $y; Looking at this I just started wondering... why wouldn't that be made with: my $y = 10 but Imprecise(5%); $x ~~ $y; daniel

Re: Exceptions question

Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu: > for @! {} > might provide the needed semantics... After sending this mail I've just realized I don't know exactly which are the needed semantics... what happens if you have several unthrown exceptions in the block, doe

Re: Exceptions question

Em Qui, 2009-02-26 às 22:26 +1100, Timothy S. Nelson escreveu: > given(any(@!)) { > } using junctions on exception handling doesn't seem like a good idea to me, because it is too much of a basic feature... but... for @! { } might provide the needed semantics... OTOH, I think it would be sane t

Re: Comparing inexact values (was "Re: Temporal changes")

Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu: > Daniel Ruoso wrote: > > if $y ~~ [..] $x ± $epsilon {...} > Junctions should not return individual values in list context, It is not the junction that is returning the individual values, but the infix:<±> operator... daniel

Re: Comparing inexact values (was "Re: Temporal changes")

Em Ter, 2009-02-24 às 08:59 -0800, Larry Wall escreveu: > I'm using ± more in the engineering sense than the mathematical > sense. What about... if $x ~~ [..] $x ± $epsilon {...} That would mean that $x ± $epsilon in list context returned each value, where in scalar context returned a junctio

Re: Signals question for S16: IPC / IO / Signals

Em Seg, 2009-02-23 às 19:49 -0800, Larry Wall escreveu: > On Tue, Feb 24, 2009 at 04:01:40PM +1300, Martin D Kealey wrote: > : Conceptually I think they should all go in add-on(s), however I suspect that > : when an exception is thrown inside a signal handler, cleanly unwinding the > : call chain w

Re: r25445 - docs/Perl6/Spec/S32-setting-library

Em Sex, 2009-02-20 às 10:53 -0800, Larry Wall escreveu: > Perhaps we could just go with Instant and Duration as top-level roles > since they're rather fundamental to lots of computing. As builtins > they would presumably come with appropriate operators predefined. And > as roles they could be twe

Re: r25445 - docs/Perl6/Spec/S32-setting-library

Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu: > By the by, I'm also inclined to agree with those who prefer "Instant" > to "DateTime" on aesthetic grounds. I should note that I'm insisting on DateTime just as the reference p5 module in CPAN, I don't oppose it being called Instant in Perl

Re: r25445 - docs/Perl6/Spec/S32-setting-library

Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu: > On Fri, 20 Feb 2009, Daniel Ruoso wrote: > > If we're going to use an epoch, it should be the Operating System's > > epoch. Anything else will lead to confusion and disorder ;P > And which OS epoch would that be

Re: r25445 - docs/Perl6/Spec/S32-setting-library

Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu: > That being said, I'm thinking that all actual times represented by > floats in Perl are TAI time, not the Unix pseudo time with hidden > leap seconds. I sure wish they'd done away with civic leap seconds > in 2000 and said we'll put in a le

Re: More trees and roles

Em Sex, 2009-02-20 às 11:19 +1100, Timothy S. Nelson escreveu: > if(! defined($footree.root)) { warn "Unrooted tree"; } There are some other very interesting possibilities: unless ($footree.can(root)) { warn "Unrooted tree"; } or even better unless ($footree ~~ RootedTree) { warn "Unr

Re: Spec reorganisation

Em Qui, 2009-02-19 às 22:57 +1100, Timothy S. Nelson escreveu: > Interesting. I'm happy to assume that $root is allowed to be > Undefined, I think. But let me ask a question; were you to represent an > unrooted tree in a computer, how would you do it so that, if you had to look > around

  1   2   >