help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: string serialization of builtin datatypes


From: Juan Pablo Carbajal
Subject: Re: string serialization of builtin datatypes
Date: Wed, 6 May 2015 23:07:09 +0200

On Wed, May 6, 2015 at 8:12 PM, Mike Miller <address@hidden> wrote:
> On Wed, May 6, 2015 at 19:47:04 +0200, Andreas Weber wrote:
>> Dear users,
>>
>> I once wrote a serialize function
>> (https://github.com/octave-de/serialize) to get a human readable string
>> representation of built in datatypes. To restore the var just call eval.
>> The intended purpose is to serialize objects for transmission over
>> byte-stream channels (serial, tcp...) or for storage in databases while
>> perserve the readability by humans(in contrast to the usage of
>> typecast(x, "uint8" for example).
>>
>> Does anyone see an octave-forge package this might fit in?
>>
>> btw: Do we have a function which checks a string for malicious code
>> before evaluating? For example wget, system, unlink and so on.
>>
>> Any feedback and suggestions highly appreciated.
>
> So basically an Octave equivalent of Python's repr()? I think I missed
> this when you announced it before, but this is awesome!
>
> I actually think such a function would be incredibly useful to be a
> standard feature of Octave itself.
>
> If it was a function in core Octave that worked with all builtin
> types, it could also be overridden for classes and user-defined types
> and become ever more useful to everyone without having to depend on an
> external package or library.
>
> I think that once there was a question or discussion about having a
> display mode option to enable this for display of objects in the
> interpreter also, e.g.
>
>   >> x = [1 2; 3 4]
>   x =
>      1   2
>      3   4
>   >> format literal_representation
>   >> x
>   x = [1 2; 3 4]
>
Indeed, this topic came about in Octconf 2012, maybe it had already
been discussed before. Such a feature would be very welcomed.

Conceptually, io would be the right package, however if the chances
are that this is going to move to core rather quickly I will go for a
less involved package...maybe general? (let the stones fall ...)

> or something like that. There seems to be some convergence there with
> what you have created.
>
> --
> mike
>
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-octave



reply via email to

[Prev in Thread] Current Thread [Next in Thread]