On 1/6/20 8:54 AM, Josef Reidinger wrote: > V Sun, 5 Jan 2020 11:51:29 +0100 > Ancor Gonzalez Sosa <an...@suse.de> napsáno: > >> On 1/3/20 12:24 PM, Ancor Gonzalez Sosa wrote: >>> On 1/3/20 11:31 AM, Josef Reidinger wrote: >>>> V Fri, 3 Jan 2020 11:14:15 +0100 >>>> >>>> Hi, this is quite interesting. Especially similarities in testing looks >>>> nice. I have few questions: >>> >>> I have to say that my feeling is that similarities in testing are not as >>> deep as they may look in the surface. Tests in Crystal use almost >>> exactly the same syntax that RSpec, but AFAIK there is nothing like >>> "let" and nothing like rspec-mocks. >> >> Good news, I added Spectator[1] to the project and now both test files >> disk_size_test.rb and disk_size_spec.cr are basically identical. >> >> The Spectator home page claims that "developers coming from Ruby and >> RSpec will feel right at home" and I must say it's absolutely true. >> >> Cheers. >> >> [1] https://gitlab.com/arctic-fox/spectator > > Good to heard that. > Then maybe we can try for some serious usage took the most compute intensive > part of yast2-storage-ng ( I think computing proposal is the winner now, not? > ) and try to write it in crystal.
That's the obvious candidate. The problem is that the proposal code relies heavily in libstorage-ng, so we would need libstorage-ng bindings in Crystal. > When I think about it, it probably need two input - current state + > configuration ( defaults + product specific changes + maybe user changes from > guided setup integrated together? ) and return the proposed action to apply > on graph ( or target graph, but I worry it cannot be easily import to > libstorage-ng ). That's how the current proposal works, you can simulate any starting point, any restrictions, any setting, etc. The problem is, again, that a big portion of such information is currently represented with data structures coming from libstorage-ng. > And when we have it compare speed. I think the task is good also because it > can be well paralleled and we already reach its limit in some bug reports. Fortunately, those problems only happen in SLE-15. In SP1 we already introduced changes so we don't need to use brute-force with so big combinations of possibilities. But yes, definitely those scenarios are still a perfect benchmark to measure the gain in speed and memory consumption. So feel free to help with the libstorage-ng bindings. :-) Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscr...@opensuse.org To contact the owner, e-mail: yast-devel+ow...@opensuse.org
