search for: deserialiser

...n Live Ins: %x4 ^~~~~~~~~~~~~~~~~ ``` Should I expect this to work, or is some part of my workflow wrong? I put the full log and just the extracted MIR file online: https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and would appreciate any guidance whether I should file this as a deserialiser bug. Best, Valentin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180319/0d3d733f/attachment.html>

...> ``` > > Should I expect this to work, or is some part of my workflow wrong? > > I put the full log and just the extracted MIR file online: > https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and > would appreciate any guidance whether I should file this as a deserialiser > bug. > > Best, > Valentin > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -------------- next part -------------- An HTML attach...

...ect this to work, or is some part of my workflow wrong? >>> >>> I put the full log and just the extracted MIR file online: >>> https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and >>> would appreciate any guidance whether I should file this as a deserialiser >>> bug. >>> >>> Best, >>> Valentin >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/ma...

The filesystem_walk command is the appliance's counterpart of the daemon's internal_filesystem_walk command. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted tsk_dirent structs. It returns to the caller the list of tsk_dirent structs generated by the internal_filesystem_walk command. Signed-off-by: Matteo Cafasso <noxdafox

...gt; Should I expect this to work, or is some part of my workflow wrong? >> >> I put the full log and just the extracted MIR file online: >> https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and >> would appreciate any guidance whether I should file this as a deserialiser >> bug. >> >> Best, >> Valentin >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> &g...

"appliance: Added filesystem_walk command" -> "New API: filesystem_walk" On Tuesday 05 April 2016 18:47:31 Matteo Cafasso wrote: > The filesystem_walk command is the appliance's > counterpart of the daemon's internal_filesystem_walk command. It is not the counterpart in the appliance, but in the library. The appliance is the small VM used to do all the

Hi, some of the comments for patch #3 apply also for this one, namely: - wrapping of commit message - indentation of forward declarations - usage of XDR deserialization from guestfs_protocol.h - On Sunday 03 April 2016 16:30:49 Matteo Cafasso wrote: > The filesystem_walk command is the appliance's > counterpart of the daemon's > internal_filesystem_walk command. > > It

...t of my workflow wrong? >>>>> >>>>> I put the full log and just the extracted MIR file online: >>>>> https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and >>>>> would appreciate any guidance whether I should file this as a deserialiser >>>>> bug. >>>>> >>>>> Best, >>>>> Valentin >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>&...

The yara_scan API parses the file generated by the daemon counterpart function and returns the list of yara_detection structs to the user. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted yara_detection structs. It returns to the caller the list of yara_detection structs generated by the internal_yara_scan command. Signed-off-by:

..., or is some part of my workflow wrong? >>>> >>>> I put the full log and just the extracted MIR file online: >>>> https://drive.google.com/open?id=1Br0s9Qvr4tzPv8nqbnV_nWezpEH5Ci7B and >>>> would appreciate any guidance whether I should file this as a deserialiser >>>> bug. >>>> >>>> Best, >>>> Valentin >>>> >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >&...

The yara_scan API parses the file generated by the daemon counterpart function and returns the list of yara_detection structs to the user. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted yara_detection structs. It returns to the caller the list of yara_detection structs generated by the internal_yara_scan command. Signed-off-by:

The yara_scan API parses the file generated by the daemon counterpart function and returns the list of yara_detection structs to the user. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted yara_detection structs. It returns to the caller the list of yara_detection structs generated by the internal_yara_scan command. Signed-off-by:

The yara_scan API parses the file generated by the daemon counterpart function and returns the list of yara_detection structs to the user. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted yara_detection structs. It returns to the caller the list of yara_detection structs generated by the internal_yara_scan command. Signed-off-by:

The filesystem_walk command is the appliance's counterpart of the daemon's internal_filesystem_walk command. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted tsk_dirent structs. It returns to the caller the list of tsk_dirent structs generated by the internal_filesystem_walk command. Signed-off-by: Matteo Cafasso

2016-04-04 13:09 GMT+03:00 Pino Toscano <ptoscano@redhat.com>: > Hi, > > some of the comments for patch #3 apply also for this one, namely: > - wrapping of commit message > - indentation of forward declarations > - usage of XDR deserialization from guestfs_protocol.h > - > > On Sunday 03 April 2016 16:30:49 Matteo Cafasso wrote: > > The filesystem_walk

Library's counterpart of the daemon's internal_filesystem_walk command. It writes the daemon's command output on a temporary file and parses it, deserialising the XDR formatted tsk_dirent structs. It returns to the caller the list of tsk_dirent structs generated by the internal_filesystem_walk command. Signed-off-by: Matteo Cafasso <noxdafox@gmail.com> ---

v2: - Increased the amount of collected information from the FS content. - Moved filesystem_walk0 as internal command. - Code improvement based on comments. - Adhere to project's coding style. - Better command documentation. - More robust tests. Patch ready for review, code available at: https://github.com/noxdafox/libguestfs/tree/filesystem_walk Matteo Cafasso (5): generator:

I''m trying to use ruby''s yaml library to serialise and deserialise some legacy classes. Simply adding a to_yaml_properties() method isn''t sufficient as special methods need to be called to get and set the properties (they''re not stored simply in instance variables that I can access), and I don''t want to change the class any more than I have to.

v3: - File size will be reported as - 1 if it cannot be retrieved. - Code improvements based on comments. Matteo Cafasso (5): generator: Added tsk_dirent struct configure: Added libtsk compile-time check daemon: Added internal_filesystem_walk command appliance: Added filesystem_walk command appliance: Added filesystem_walk command tests daemon/Makefile.am | 4 +-

v8: - rebase on master - bump version to 1.33.37 - squash commits 1, 2, 3 Kept original commits messages when squashing them. Matteo Cafasso (3): New API: internal_filesystem_walk New API: filesystem_walk lib: Added filesystem_walk command tests daemon/Makefile.am | 4 +- daemon/tsk.c | 249 ++++++++++++++++++++++++++++++++++++++