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
