Re: my $key is sensitive;

[Rafael Garcia-Suarez]

Brent 'Dax' Royal-Gordon wrote in perl.perl6.language :
> Basically, I'd like to be able to mark a variable as "sensitive" or
> "secret".  This implies that the language should overwrite the memory
> it uses before deallocating it, and that if possible it should tell
> the virtual memory system to avoid swapping it out.  Moreover, it
> should probably do so recursively, and to any value that has ever been
> stored in the variable.  (In essence, the *variable* marks all
> *values* it ever contains as sensitive.)
>
> This feature could make Perl 6 a better language for security work
> than any other I've seen.  C and C++ could do this, but only with the
> programmer's assistance (by calling a "wipe" function or making sure a
> destructor is correctly called), and optimizers have been known to
> "helpfully" remove such code.

Isn't the "volatile" modifier supposed to avoid this ?

Oh, and remark that "volatile" is quite a high-level construct for a
language like C. So, such a "sensitive" modifier could be added, but its
precise meaning would be highly dependent on the underlying
implementation.

-- 
The universe (which others call the Library) is composed of an indefinite and
perhaps infinite number of hexagonal galleries.
-- Borges

Re: my $key is sensitive;

[Michele Dondi]

On Tue, 4 Oct 2005, Rafael Garcia-Suarez wrote:


language like C. So, such a "sensitive" modifier could be added, but its
precise meaning would be highly dependent on the underlying
implementation.


It would be of interest more to a perl programmer than to a Perl 
programmer. Like keys() as an lvalue in Perl5.



Michele
--

Having taken a look at that: bleech.

Thanks for the constructive feedback Ben. :-)
- Paul Marquess to Ben Morrow in clpmisc

zip: stop when and where?

[Juerd]

What should zip do given 1..3 and 1..6?

(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail

I'd want c, mostly because of code like

for @foo Y 0... -> $foo, $i { ... }

Pugs currently does b.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: zip: stop when and where?

[Joshua Gatcomb]

On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.


Yeah. This is one of those things where it is hard to have a single function
always DWYM. Algorithm::Loops solves this by just providing multiple
functions. I can't see how to solve this using MMD alone. You would need to
add an optional parameter that would specify behavior

-min (zip to the smallest list)
-undef (insert undefs as needed)
-error (blow up if the lists are not equal in size)

etc

Juerd
>

Just my 2 cents from the peanut gallery.

Cheers,
Joshua Gatcomb
a.k.a. L~R

Re: zip: stop when and where?

[Greg Woodhouse]

That (b) certainly seems like the sensible option to me. My second
choice would be d.

A nice thing about c is that it leaves open the possibility of lazy
evaluation (zip as much of the lists as you can, leaving open the
possibility of picking up the process later). But I still prefer b.
Maybe there could be separate "lazy zip" (lzip?).

--- Juerd <[EMAIL PROTECTED]> wrote:

> What should zip do given 1..3 and 1..6?
> 
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
> 
> I'd want c, mostly because of code like
> 
> for @foo Y 0... -> $foo, $i { ... }
> 
> Pugs currently does b.
> 
> 
> Juerd
> -- 
> http://convolution.nl/maak_juerd_blij.html
> http://convolution.nl/make_juerd_happy.html 
> http://convolution.nl/gajigu_juerd_n.html
> 



===
Gregory Woodhouse  <[EMAIL PROTECTED]>



"Without the requirement of mathematical aesthetics a great many discoveries 
would not have been made."

-- Albert Einstein

Re: zip: stop when and where?

[Eric]

Hey,
I'd just like to say that I find B a bit misleading because you couldn't
tell that the first list ended, it could just have undef's at the end. I
like a because it doesn't add any data that wasn't there, of course that
could be a reason to dislike it too. On the other hand c makes a good option
when you want to work with infinite lists. Is this something that could be
modified on per use basis and we just choose one now as the default "they
didn't request a specific one so use this one).

After all that i think I agree on C specificaly because you can provide a
good code use of it and it doesn't add any data that wasn't there before. I
don't think it should ever lean towards (b) but them I bet someone else will
have an equaly good use of that. ;) So in the end I think some way of
chooseing would be good, with one option picked as standard.

--
Eric Hodges

Re: zip: stop when and where?

[Jonathan Scott Duff]

On Tue, Oct 04, 2005 at 09:00:15PM +0200, Juerd wrote:
> What should zip do given 1..3 and 1..6?
> 
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
> 
> I'd want c, mostly because of code like
> 
> for @foo Y 0... -> $foo, $i { ... }
> 
> Pugs currently does b.

(a) and (d) are certainly wrong IMHO.

Surely zip could get a modifier to vary the behavior as desired?

for @foo ¥ 0...  :greedy-> $foo, $i { ... } # (b)
for @foo ¥ 0...  :conservative  -> $foo, $i { ... } # (c)

Didn't we go over this a while back? 

Anyway, I agree that (c) is probably the sanest default behavior.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: zip: stop when and where?

[Greg Woodhouse]

I see your point. Option b does suggest that you can read ahead in a
"blocked" list and get undef's. If I had to choose just one, I think
I'd opt for d, but having two zip's one acting like c and one like d
might be useful. Then, of course, my first thought was wrong. This one
may well be, too.

--- Eric <[EMAIL PROTECTED]> wrote:

> Hey,
> I'd just like to say that I find B a bit misleading because you
> couldn't
> tell that the first list ended, it could just have undef's at the
> end. I
> like a because it doesn't add any data that wasn't there, of course
> that
> could be a reason to dislike it too. On the other hand c makes a good
> option
> when you want to work with infinite lists. Is this something that
> could be
> modified on per use basis and we just choose one now as the default
> "they
> didn't request a specific one so use this one).
> 
> After all that i think I agree on C specificaly because you can
> provide a
> good code use of it and it doesn't add any data that wasn't there
> before. I
> don't think it should ever lean towards (b) but them I bet someone
> else will
> have an equaly good use of that. ;) So in the end I think some way of
> chooseing would be good, with one option picked as standard.
> 
> --
> Eric Hodges
> 



===
Gregory Woodhouse  <[EMAIL PROTECTED]>



"Without the requirement of mathematical aesthetics a great many discoveries 
would not have been made."

-- Albert Einstein

Re: my $key is sensitive;

[Brent 'Dax' Royal-Gordon]

Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
> So, such a "sensitive" modifier could be added, but its
> precise meaning would be highly dependent on the underlying
> implementation.

Okay, but there needs to be some minimum standard for it, like "the
memory in question no longer contains its original contents after
garbage collection".  The security of the key keeping my information
from the Secret Police shouldn't be compromised because the particular
Perl backend I'm using doesn't implement "is sensitive" in a
meaningful way.

I would like "is sensitive" to be defined to mean that any data stored
in that variable, at any level of recursion, will be zeroed out as
soon as it is garbage collected.  Particular implementations can add
extra features on top of that--such as stopping the VM from swapping
it or even actively encrypting that area of memory--but without a
minimum standard there's no point in supporting the feature at all.

--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

Perl 6 Summary for 2005-09-26 through 2005-10-02

[Matt Fowles]

Perl 6 Summary for 2005-09-26 through 2005-10-02
All~

Welcome to another summary, this time a day late because I was in Philly
for Serenity. If you haven't seen Serenity yet you should stop reading
this summary and go see it. The summary will be here when you get back.
I promise.

  Perl 6 Compiler
No postings this week. I blame Piers for scaring them off last week.

  Parrot
   Summary Links
Last weeks load lib thread morphed into a conversation about the life
span of the shortened links that appear in summaries. Piers pointed out
that, although the short links expire, the long links are archived at
perl.org.



   RT Cleanup
Joshua Hoblitt has been continuing his massive clean up of RT. It makes
me glad of two things: that someone is doing it and that I am not doing
it. I won't post all of the links for these messages, but much work is
getting done.

   debug segments
Jonathan Worthington posted an RFC of his design for debug and source
segments in Parrot's packfiles. People seem to like it generally.
Hopefully the design will be implemented soon.



   Leo's Context Branch Hits the Mainline
After a few more reviews from Chip, Leo's context branch has been dubbed
ready and has been moved to the mainline. This marks the culmination of
quite a bit of hard work from many people (especially Leo). Nice work
all.

 -- bit of review

 -- merge

   Amber PMCs
Roger Browne wondered how he should include Amber PMCs. Leo and Will
suggested he put the pmcs into the languages directory similar to the
way Tcl does it.



   Data::Escape Needs Tests
Jerry Gay added a TODO for tests for Data::Escape. This would be a great
thing for an eager lurker to cut his or her teeth on.



   Magic Numbers Bad, Magic Strings Good
Last weeks magic thread ended down with the conclusion that Parrot would
use a magic string instead of a magic number.



   Tests fail on win32
Jerry Gay opened a new RT ticket for some failing tests on Windows.



   Here Doc in PIR
Will Coleda revived a thread from February about PIR here doc syntax.
Looks like the syntax is ok.



   Win32 PCRE
François Perrad enabled PCRE on Win32. Jerry Gay applied the patch.



   PLATFORMS and MinGW
François Perrad updated the PLATFORMS file for MinGW.



   parrot_config dependency
Nick Glencross provided a patch (for comment only) that eases the
dependency on parrot_config. I am not sure that he got many comments.



   Data::Escape::String Dislikes Unicode
Will noticed that Data::Escape::String doesn't work on Unicode strings.



   Make Cleanup
Joshua Hoblitt started RT tickets for several things that are part of a
general make system clean up.







   Parrot Leaves Crumbs
Nick Glencross rediscovered the core files that parrot leaves around.
This is a known problem.



   Parrot Threads
Dave Frost wondered what the plan for Parrot Threading was going to be.
The answer (provided by Leo with more details from Jonathan Worthington)
was OS threads.



   Once deprecation's lost its fun...
Leo went on a bit of fall cleaning adding things to the deprecated list.
He even threatened to resolve some of them soon.









   Lexical and Variable Sized Register Frames
With the calling conventions having been redone, Leo has plans to move
to system of dynamically sized registers frames with static lexicals
stored directly in them. Chip should produce details soon.



   Exception Handling Bug
Roger Browne found a bug with exception handlers in the new scheme. Leo
fixed it. I wonder if anyone made a test out of it...



   Config missing output
Will Coleda noticed that Configure.pl was not outputting a response to a
step on his platform.



   Parrot 0.3.0 TODO
Robert J Eaglestone wondered what would be a good way of chipping in.
Will Coleda, predictably, tried to turn him towards working for the good
of Tcl.



   Tru64 Issues
Jarkko Hietaniemi appears to have recently come into some time with a
Tru64 machine. He found lots of problems, which he added to RT, so I
won't link them here.

   src/extends.c
chromatic made good on a promise to auto generate src/extends.c
automatically. Leo quibbled over pod, but thought it was 

Re: zip: stop when and where?

[Damian Conway]

Juerd wrote:


What should zip do given 1..3 and 1..6?

(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail

I'd want c, mostly because of code like

for @foo Y 0... -> $foo, $i { ... }

Pugs currently does b.


I agree that C should have named options (perhaps :min and :max) that 
allow precise behaviour to be specified.


I suspect that the dwimmiest default would be for C to stop zipping at 
the length of the shortest finite argument. And to fail unless all finite 
arguments are of the same length. Hence:


 @i3 =   1..3   ;
 @a3 = 'a'..'c' ;
 @i6 =   1..6   ;

 zip(@a3, @i3)# 'a', 1, 'b', 2, 'c', 3
 zip(@i3, @i6)# fail
 zip(100..., @a3, @i3)# 100, 'a', 1, 101, 'b', 2, 102, 'c', 3
 zip(100..., @a3, @i6)# fail

Damian

Re: zip: stop when and where?

[Luke Palmer]

On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.

I think (c) is correct, precisely for this reason.  The idiom:

for 0... Y @array -> $index, $elem {...}

Is one we're trying to create.  If it involves a pain like:

for 0... Y @array -> $index, $elem {
$elem // last;
}

Then it's not going to be a popular idiom.

If you want behavior (b), SWIM:

for 0... Y @array, undef xx Inf -> $index, $elem {
...
}

If that ends up being common, we could create a syntax for it, like
postfix:<...>:

@array...  # same as (@array, undef xx Inf)

Luke

Re: zip: stop when and where?

[Luke Palmer]

On 10/4/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> If that ends up being common, we could create a syntax for it, like
> postfix:<...>:
>
> @array...  # same as (@array, undef xx Inf)

No, no, that's a bad idea, because:

@array...# same as @array.elems..Inf

So I think I'm pretty much with Damian on this one.  I don't like the
idea of it discriminating between finite and infinite lists, though. 
What about things like =<>, for which it is never possible to know if
it is infinite?

I don't think people make assumptions about the zip operator.  "Does
it quit on the shortest one or the longest one?" seems like a pretty
common question for a learning Perler to ask.  That means they'll
either write a little test or look it up in the docs, and we don't
need to be so strict about its failure.  I'd like to go with the
minimum.

I was thinking a good name for the adverbs would be :long and :short.

Luke

Fwd: zip: stop when and where?

[David Storrs]

Both Luke and I missed the fact that my mail and his response went  
only to each other so, with his permission, here it is as a forward.


--Dks


Begin forwarded message:


From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>


On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:


How about:

@foo = ('a', 'b', 'c');

for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5  
undef 6

for @foo ¥ 1..6 :fillin('')   # a 1 b 2 c 3 '' 4 '' 5 '' 6
for @foo ¥ 1..6 :fillin(0)# a 1 b 2 c 3 0 4 0 5 0 6
for @foo ¥ 1..6 :fillin(return)   # same as:  return ('a', 1, 'b', 2
'c', 3);

A couple of things bother me about this, though:

- Bad endweight on the adverb.  It looks like you are modifying the
second list, not the ¥ op



That's because you are.  I can't seem to find the document that
describes this, but as far as I recall (and my memory may be fuzzy
here), infix operators with adverbs look roughly like this:

   rule infixop {? }

Where  is, of course, greedy.  So since .. is tighter than Y:

for @foo Y 1..6 :fillin(undef) {...}

Is equivalent to:

for @foo Y (1..6 :fillin(undef)) {...}

And to get it modifying Y you need to do:

for (@foo) Y (1..6) :fillin(undef) {...}

(Parens added around @foo for symmetry).



for @foo ¥ 1..6 :fillin(last) # a 1 b 2 c 3



Uh, I don't think that works.  First off, it would have to be:

for (@foo) Y (1..6) :fillin{ last } {...}

But I don't think that works either, since you want that last to be
associated with the for loop, which it is not lexically inside.
Honestly, I just don't think it's an option, and that :short/:long (or
:min/:max) is a better option.  However, I wonder how you would get
behavior like this:

for (@foo) Y (@bar, undef xx Inf) Y (1...) :short -> $foo, $bar,
$index {...}

Hmm, probably just like that :-)



Could something like this syntax be made to work?

for (@foo ¥:fillin(undef) 1..6) but true  # a but true, 1 but
true...undef but true, 6 but true



I think you've stumbled upon the reason why we made adverbs come after
operators.  The important thing is the zip, not the fact that you're
filling in with undef.

Luke