Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
>Adam Turoff wrote:
>
>> *: Sarathy tells me that Perforce sucks at maintaining thousands of
>> anonymous checkouts, while CVS doesn't mind at all.
This is a feature of perforce that is useful - it can warn you that
you are about to change a file th
Nick Ing-Simmons wrote:
>
>
> I see no reason why the perforce changes cannot be 'checked in' to CVS
> one-by-one so that CVS builds its own representation of the change history.
I've got this working now in a program called 'vcp', I need to test
p4->cvs updates using the perl5 repository next
Grant M. <[EMAIL PROTECTED]> writes:
>I am reading various discussions regarding threads, shared objects,
>transaction rollbacks, etc., and was wondering if anyone here had any
>thoughts on instituting an event model for Perl6? I can see an event model
>allowing for some interesting solutions to s
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>NI> Indeed that is exactly how tied arrays work - they (automatically) add
>NI> 'p' magic (internal tie) to their elements.
>
>Hmm, I always understood a tied array to be the _array_ not each individual
>element.
The perl level tie is on the array. Th
Ken Fox <[EMAIL PROTECTED]> writes:
>Short
>circuiting should not be customizable by each type for example.
We are already having that argument^Wdiscussion elsewhere ;-)
But I agree variable vtables are not the place for that.
--
Nick Ing-Simmons
Dear All
I wrote a large C++ program which used embedded Perl. Later, this was changed to
embedded Python. The reasons for this included:
1) Python allows you to pass a pointer to an object from C/C++ to the embedded Python
interpreter, wheras Perl makes you push and pop off the stack (as far
* Nick Ing-Simmons ([EMAIL PROTECTED]) [10 Sep 2000 06:38]:
[...]
> This is a feature of perforce that is useful - it can warn you that
> you are about to change a file that someone else is already working
> on.
As can CVS.
cheers,
--
\def\Koschei{Iain Truskett}% http://eh
On 8 Sep 2000 04:57:46 -, Perl6 RFC Librarian wrote:
>Instead of
>
> %subhash = map { f($_) ? ($_, $hash{$_}) : () } keys %hash; # lengthy
>
>one may now write
>
> %subhash = %hash{f($_)};# code block f($_) will be evaluated for Truth
>over all the keys
I almost like
Jeremy Howard wrote:
>
> Not only do you lose consistency here (as Christian already pointed out),
> but also speed. Array functions and operations would be tightly optimised
> loops, and furthermore multiple operations would avoid redundant loops and
> copies. Good luck finding a way of getting
Jeremy Howard writes:
> No, there's no arbitrary decision. *Every* operator is component wise on
> lists. It is internally consistent, and consistent with most other languages
> that provide array/list operators. It's easy to get stuck on the '*'
> example, because different mathematicians have di
[EMAIL PROTECTED] wrote:
>
> I disagree. You end up with a situation where some
>
>@a * @b;
>
> are in scalar context, some not.
No, everything would be in a scalar context. If you used tie() to
specially tie a variable, then you might be able to overload +, *, -,
etc, but this is no diffe
Nathan Torkington wrote:
>
> Actually, the only refinement I'd like to see is that boolean operators
> (==, &&, ||) be excepted from the distributive rule.
>
> This is to permit:
>
> if (@a == @b) # shallow comparison
>
> and
>
> @a = @b || @c;# @a=@b or @a=@c; # ish
Nathan Wiger wrote:
> The only thing that *really* makes me nervous about the RFC is this
> part:
>
> > > @d = @b * @c; # Returns (2,8,18)
> > >
> > > If the lists are not of equal length, an error is raised.
>
> I really don't like the "error is raised" part, at least not by default.
> Maybe
Nathan Wiger wrote:
> My main fear is that while this RFC seems really good for math ops, but
> seems too array- and PDL-specific. Here are some examples of mixed
> contexts; how would these be handled under the RFC?
>
> @user_data = @empty || $user;
> %files = scalar(get_files()) || @DEFA
Nathan Torkington wrote:
> Jeremy Howard writes:
> > No, there's no arbitrary decision. *Every* operator is component wise on
> > lists. It is internally consistent, and consistent with most other
languages
> > that provide array/list operators. It's easy to get stuck on the '*'
> > example, becau
Jeremy Howard writes:
> > @a = @b || @c; # @a=@b or @a=@c; # ish
> Doesn't work in P5 (try it!)
I know it doesn't, and I'm saying (yet again) that I'd like it to work
in perl6.
Nat
Jeremy Howard wrote:
> - Mathematica (combines functional, declarative, and procedural styles;
> implements memoization, lazy lists, and array notation)
> - Matlab (fast and simple array language)
> - C++ expression templates such as POOMA and Blitz++ (implicit looping and
> generalised slicin
RFC 178 proposes a shared data model for Perl6 threads. In a shared
data model
- globals are shared unless localized
- file-scoped lexicals are shared unless the thread recompiles the
file
- block scoped lexicals may be shared by
- passing a reference to them
- closures
- declaring one s
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Right, but databases are all dealing with mainly disk access. A 1ms lock
DS> operation's no big deal when it takes 100ms to fetch the data being locked.
DS> A 1ms lock operation *is* a big deal when it takes 100ns to fetch the data
DS>
> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes:
SWM> If you actually compile a Perl program, like
SWM>$a = $b
SWM> and then look at the op tree, you won't find the symbol "$b", or "b"
SWM> anywhere in it. The fetch() op does not have the name of the variable
SWM> $b; r
> SWM> If you actually compile a Perl program, like
>
> SWM> $a = $b
>
> SWM> and then look at the op tree, you won't find the symbol "$b", or "b"
> SWM> anywhere in it. The fetch() op does not have the name of the variable
> SWM> $b; rather, it holds a pointer to the value for $b.
>
> W
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Chaim Frenkel wrote:
>> No scanning. I was considering that all variables on a store would
>> safe store the previous value in a thread specific holding area[*]. Then
>> upon a deadlock/rollback, the changed values would be restored.
>>
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Once we have an API, we write test cases to exercise the API.
NT> Then we code.
Would it be worthwhile to 'waste' some time on writing caller and callee
stubs? This would flesh out the final api and give the module writers
something
Chaim Frenkel writes:
> Would it be worthwhile to 'waste' some time on writing caller and callee
> stubs? This would flesh out the final api and give the module writers
> something of an environment to work with?
Yes, I'm appalled I forgot this. It's part of what I've been thinking
about.
By ha
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> Would it be worthwhile to 'waste' some time on writing caller and callee
>> stubs? This would flesh out the final api and give the module writers
>> something of an environment to work with?
NT> Yes, I'm app
Doug Hunt wrote:
> Jeremy Howard wrote:
>
> > - Mathematica (combines functional, declarative, and procedural styles;
> > implements memoization, lazy lists, and array notation)
> > - Matlab (fast and simple array language)
> > - C++ expression templates such as POOMA and Blitz++ (implicit loop
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Actually, the only refinement I'd like to see is that boolean operators
NT> (==, &&, ||) be excepted from the distributive rule.
NT> This is to permit:
NT> if (@a == @b) # shallow comparison
NT> and
NT> @a = @b ||
Doug Hunt wrote:
> You might also look at APL, a language which has been doing really funky
> N-dimensional
> array manipulation for longer than anyone...
I'd say PDL has probably been influenced quite strongly by APL/J in its
PDL threading notion. And with more and more "funny characters" makin
Nathan Wiger wrote:
> what people would want to use the ops for, and it's also more usable to
> us non-PDLers.
I'd like to suggest that it is not a very good idea to start dividing
the world into PDLers and non-PDLers. There are a multitude of reasons
but I am not keen to go into details.
Chr
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>> for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
>>
>> Probably we'll have to say that the user must explicitly zip if that
>> is what is desired.
PS> Yes, please. I view the flattening of lists as a feature, not a bug, and
PS> it has made Pe
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> my_while { pred() } { # don't gimme no Tcl flac.
>> ...
>> } # no semicolon needed here!
DC> Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
--
Chaim Frenkel
Would returning the array of status be sufficient?
@foo = chmod 755, "bar", "baz", "quux";
# @foo == (0, 2, 0);
How to convert them to error messages would be a challenge.
Unless passing them through $! would do the trick.
Hmm, perl -wle '$!=3; print $!'
No such process
Yup, w
At 01:26 AM 9/10/00 -0400, Chaim Frenkel wrote:
>Would returning the array of status be sufficient?
>
> @foo = chmod 755, "bar", "baz", "quux";
> # @foo == (0, 2, 0);
>
>How to convert them to error messages would be a challenge.
>Unless passing them through $! would do the trick.
Randal L. Schwartz wrote:
>
> uninit looks like a typo for "unit".
>
> Maybe we need "denit" for "de-nitialize" :)...
Yuck. I dislike "de-" anything. "un-" is far more
often the correct prefix. Anyway, the counterpart
of "init" should be, I think, "exit". But seriously,
the opposite of "ini
34 matches
Mail list logo
