search for: top_sizer

...l.rb:15:in `initialize'' from TestTextCtrl.rb:24:in `on_init'' from TestTextCtrl.rb:30 Using the following (probably overly verbose) program: require ''wx'' include Wx class MyFrame < Frame def initialize(title) super(nil, -1, title) @top_sizer = BoxSizer.new( Wx::VERTICAL ) @panel = Panel.new(self) @panel.set_auto_layout(true) @panel.set_sizer(@top_sizer) @test_text_ctrl = TextCtrl.new(@panel, -1, "") style = @test_text_ctrl.get_default_style() style.set_background_colour(WHITE) @test_text_ctrl.set_...

...;span class="cx"> </span><span class="cx"> def setup_panel </span><ins>+ panel = Wx::Panel.new(self, -1) + </ins><span class="cx"> sizer = Wx::BoxSizer.new(Wx::VERTICAL) </span><span class="cx"> top_sizer = Wx::BoxSizer.new(Wx::HORIZONTAL) </span><span class="cx"> </span><del>- @go_butt = Wx::StaticText.new(self, -1, ''Location:'') </del><ins>+ @go_butt = Wx::StaticText.new(panel, -1, ''Location:'') </ins&g...

...rl.rb:24:in `on_init'' > from TestTextCtrl.rb:30 > > > Using the following (probably overly verbose) program: > > require ''wx'' > include Wx > > class MyFrame < Frame > def initialize(title) > super(nil, -1, title) > @top_sizer = BoxSizer.new( Wx::VERTICAL ) > @panel = Panel.new(self) > @panel.set_auto_layout(true) > @panel.set_sizer(@top_sizer) > @test_text_ctrl = TextCtrl.new(@panel, -1, "") > > style = @test_text_ctrl.get_default_style() > style.set_background_colo...

The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio-mmio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code transforms calls coming from the IOMMU API into corresponding virtio requests. Mappings are kept in an interval tree instead of page tables.

The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio-mmio transport without emulating page tables. This implementation handle ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code is to create requests and send them through virtio. Implementing the IOMMU API is fairly straightforward since the virtio-iommu MAP/UNMAP interface is

On 14/02/18 14:53, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without emulating > page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into > corresponding virtio

Hi Jean-Philippe, please find some comments below. On 17/11/17 19:52, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without emulating > page tables. This implementation handle ATTACH, DETACH, MAP and UNMAP handles > requests. > > The bulk of the code is to create

Implement the virtio-iommu driver following version 0.6 of the specification [1]. Previous version, RFCv2, was sent in November [2]. This version addresses Eric's comments and changes the device number. (Since last week I also tested and fixed the probe/release functions, they now use devm properly.) I did not include ACPI support because the next IORT specifications isn't ready yet (even

Implement the virtio-iommu driver following version 0.6 of the specification [1]. Previous version, RFCv2, was sent in November [2]. This version addresses Eric's comments and changes the device number. (Since last week I also tested and fixed the probe/release functions, they now use devm properly.) I did not include ACPI support because the next IORT specifications isn't ready yet (even

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

Hi Attached is a patch to add HtmlWindow and some of its friends, including HtmlEasyPrinting. Also a sample. I haven''t tried exposing the parsing and rendering API yet to allow custom tags etc - I just wanted to get basic HTML and the 0.6.0 compatibility classes first. There may well be some quite easy classes left. There''s one ugly kludge to get OnOpeningURL to compile -

...t (nil) + # -1 means this frame will be supplied a default id + super(nil, -1, title, pos, size, style) + setup_menus + setup_panel + create_status_bar(2) + set_status_text("Welcome to wxRuby!") + end + + def setup_panel + sizer = Wx::BoxSizer.new(Wx::VERTICAL) + top_sizer = Wx::BoxSizer.new(Wx::HORIZONTAL) + + @go_butt = Wx::StaticText.new(self, -1, ''Location:'') + top_sizer.add(@go_butt, 0, Wx::ALL, 4) + @addr_bar = Wx::TextCtrl.new(self, -1, ''HOME'', Wx::DEFAULT_POSITION, + Wx::DEFAULT_...

Hi Eric, On 03/10/17 14:04, Auger Eric wrote: > When rebasing the v0.4 driver on master I observe a regression: commands > are not received properly by QEMU (typically an attach command is > received with a type of 0). After a bisection of the guest kernel the > first commit the problem appears is: > > commit e3067861ba6650a566a6273738c23c956ad55c02 > arm64: add basic

Running an mmap-intensive workload on ZFS on a X4500, Solaris 10 11/06 (update 3). All file IO is mmap(file), read memory segment, unmap, close. Tweaked the arc size down via mdb to 1GB. I used that value because c_min was also 1GB, and I was not sure if c_max could be larger than c_min....Anyway, I set c_max to 1GB. After a workload run....: > arc::print -tad { . . . ffffffffc02e29e8

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different