On 1/3/20 11:31 AM, Josef Reidinger wrote:

V Fri, 3 Jan 2020 11:14:15 +0100 Ancor Gonzalez Sosa <ancor@suse.de> napsáno:

...

Ok, and now that I got your attention, let's rephrase the subject into something more realistic: "I'm starting to port to Crystal a very small and limited subset of yast-storage-ng".

See more details at https://github.com/ancorgs/y3storage

Is something I wanted to do in the past Hack Week... and in the previous one... and so on. So finally I used the downtimes of my recent trip to Nuremberg and some vacation time to get it started.

Since next Hack Week will take place soon, I hope to continue with that and maybe experiment with automatic translation or bindings. Let's see.

So far, you can get surprised about how similar both languages are by displaying y2storage/disk_size.rb side by side with y3storage/disk_size.cr, or also y2storage/disk_size_test.rb and disk_size_spec.cr.

Cheers.

PS.- No, there is no evil plan to migrate YaST to Crystal. This is just done in the Hack Week spirit of "what if".

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. In fact, DiskSize is an example of RSpec used as traditional unit tests "masked" into RSpec syntax. That makes the conversion very easy. We will need to experiment by migrating other tests with an advanced usage of "let" and with mocking of other components.

1. do you compare speed? Is really crystal significantly faster then ruby? And what about size?

I have only ported a very small part so far, so I can't run any significant test. Maybe after porting the whole "ruby" directory we can do some benchmarks. In theory, the difference in both memory consumption and speed should be huge (that's what people say).

2. how is crystal supported in SLE? Can we easily use it for speed critical parts of yast?

Crystal is not present in SLE at all. I got it from the official page, which provides RPMs for many, many distros: https://crystal-lang.org/install/ The compiler is based on LLVM, so it should be possible to get it working in all architectures supported by SLE. But in practice, I would be very surprised if anyone has ever compiled Crystal for anything beyond x86 and ARM. IMHO, using Crystal for something really serious would imply some kind of investment in the project. It's not like Ruby or Python, a language you can take just for granted everywhere. On the other hand, it's already supported in Travis and that kind of services, since many companies are migrating some parts of their Ruby infrastructure to Crystal (for performance and concurrency reasons).

3. how works bindings to C++? I expect FFI should work fine, but C++ is not much FFI friendly.

As most LLVM languages out there, binding to C libraries is trivial. But, as always, C++ is another story. It always needs extra tools (like SWIG) to generate proper bindings. SWIG does not support Crystal. AFAIK, the only almost-working bindings generator is Bindgen. But again, only tested in x86. https://github.com/Papierkorb/bindgen Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

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 -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 1/6/20 8:54 AM, Josef Reidinger wrote:

V Sun, 5 Jan 2020 11:51:29 +0100 Ancor Gonzalez Sosa <ancor@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+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 1/6/20 2:55 PM, Martin Vidner wrote:

On Fri, Jan 03, 2020 at 11:31:48AM +0100, Josef Reidinger wrote:

...

V Fri, 3 Jan 2020 11:14:15 +0100 Ancor Gonzalez Sosa <ancor@suse.de> napsáno:

...

See more details at https://github.com/ancorgs/y3storage

Hi, this is quite interesting. Especially similarities in testing looks nice. I have few questions:

1. do you compare speed? Is really crystal significantly faster then ruby? And what about size? 2. how is crystal supported in SLE? Can we easily use it for speed critical parts of yast? 3. how works bindings to C++? I expect FFI should work fine, but C++ is not much FFI friendly.

Oh, interesting! Thanks for sharing, Ancor.

Among the motivations why one would be interested in Crystal, I also care about better type safety. https://crystal-lang.org/ says:

...

Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language clean, Crystal has built-in type inference, so most type annotations are unneeded.

All types are non-nilable in Crystal, and nilable variables are represented as a union between the type and nil. As a consequence, the compiler will automatically check for null references in compile time, helping prevent the dreadful billion-dollar mistake.

Are you interested in this?

Definitively, that is one of the most interesting features of Crystal. You can use nil wherever it makes sense, but you should never get a nil in places where you didn't expect it.

Have you found any problems/benefits during the porting so far?

I have needed to modify some small things here and there to make obvious for the compiler that some variables can never be nil. But nothing too big so far. Also related to types but not to nil, one of the main changes is that we need to be very explicit about the exact size of the integer variables we use. In particular the ones we used to represent the size of devices (which we always represent internally in bytes). Ruby can represent integers of any size and it will adapt automagically the variable from int32 to int64 or even beyond as the number stored in that variable grows. With Crystal you have to declare the variables as Int64 or UInt64 since the very beginning if you expect those numbers to grow. Again, not a big deal. After my short experience, the type system of Crystal feels like an almost perfect balance between dynamic and static typing. On one hand, the usage of union types gives you a lot of the Ruby's flexibility without going as far as pure duck-typing. On the other hand, the built-in type inference system removes the hassle usually associated to static languages. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org