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
