Chris, I've looked into your second suggestion, and what I've discovered is that while I understand what you mean, I haven't the foggiest idea of how to implement it.
Diab On Tue, Oct 11, 2016 at 10:30 AM, Diab Jerius <[email protected]> wrote: > Chris, > > Your second suggestion seems like an interesting approach as it uses > existing machinery. I'll take a look at that. > > On Fri, Oct 7, 2016 at 10:40 PM, Chris Marshall <[email protected]> > wrote: >> A few thoughts: >> >> - Use flexmap with the right options to memory >> map the piddle data so any write would be interrupted >> by the permissions on the file >> >> - Maybe you could use a virtual, affine piddle >> with the data flow back to the parent disabled >> and with a barf or some such (Craig would have >> a better idea on how this could/might work... >> >> - This seems like something good to add to the >> PDL Next Gen required features... >> >> --Chris >> >> >> On 10/7/2016 18:19, Zakariyya Mughal wrote: >>> >>> On 2016-10-07 at 17:35:04 -0400, Diab Jerius wrote: >>>> >>>> [my apologies, forgot to send to list] >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Diab Jerius <[email protected]> >>>> Date: Fri, Oct 7, 2016 at 3:52 PM >>>> Subject: Re: [Pdl-general] Read only piddles? >>>> To: Craig DeForest <[email protected]> >>>> >>>> >>>> On Fri, Oct 7, 2016 at 1:00 PM, Craig DeForest >>>> <[email protected]> wrote: >>>>> >>>>> I don’t think that there is at the moment. >>>>> >>>>> It might be possible to mark a PDL read-only to prevent modification of >>>>> its contents, but modification as you describe involves a Perl-level >>>>> change >>>>> to the variable: putting a new value in the variable is not something >>>>> that >>>>> PDL controls. >>> >>> Perhaps you could look at using the mprotect() syscall on the PDL's data? >>> You will likely have to allocate it yourself in C so that it is >>> page-aligned. There is an example of how to do this at >>> <http://eli.thegreenplace.net/2013/11/05/how-to-jit-an-introduction>. >>> >>>> That's what I feared. I would like to prevent an inadvertent >>>> >>>> $pdl *= 3; >>>> >>>> I started out with a PDL subclass and overriding as many core methods >>>> and operator overloads that I could think of, but that's a chase with >>>> no end. >>> >>> This way would be really tricky to do. It would possibly have to take >>> into consideration the `inplace` flag and the signature of each function >>> under the PDL namespace. >>> >>> I've found that PDL subclassing is very tricky to do in a way that >>> restricts by certain properties. To do it right, we need a more >>> principled approach to defining the functions as pure and impure >>> functions and some sort of (contract? role-based?) mechanism to indicate >>> the kinds of data that a particular operation can be applied on (like >>> statistical levels of measurements). >>> >>> I'm still thinking about how to approach this --- it seems tricky to do >>> while still remaining fast. Especially when simultaneously thinking >>> about refactoring PDL! >>> >>> Scala and Haskell have done very interesting things in this area that we >>> need to steal. ;-) >>> >>> Regards, >>> - Zaki Mughal >>> >>>>> You could make a Perl copy of the PDL and hand *that* off: >>>>> >>>>> $tmp = $my_pdl; >>>>> untrusted($tmp); >>>>> >>>> Unfortunately, the piddles may be large and the calls may be many. >>>> I'm trying to avoid too much memory thrashing. >>>> >>>> >>>>>> On Oct 7, 2016, at 10:27 AM, Diab Jerius <[email protected]> >>>>>> wrote: >>>>>> >>>>>> I've got an application where I need to maintain a functional >>>>>> relationship between several piddles, but need to hand them over to >>>>>> untrusted code which will destroy that relationship if the piddles are >>>>>> modified. >>>>>> >>>>>> Is there any means of marking a piddle as read only? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Diab >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Check out the vibrant tech community on one of the world's most >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>>>> _______________________________________________ >>>>>> pdl-general mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/pdl-general >>>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> pdl-general mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/pdl-general >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> pdl-general mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/pdl-general >> >> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
