Re: Learning by Reversing - thinking about a post

Recently, I did some research into building a Ruby gem with native extensions built with Crystal. I stopped because the project for doing this (Crystallized Ruby) hasn’t been maintained for a while. But, I might have heard that it still works completely or partially anyways.

So, if you explore building a Ruby gem with a Crystal-lang native extension, I’d be very interested in reading such a blog post.

Best,

Andy

LinkedIn: https://www.linkedin.com/in/andymaleh
Blog: https://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: https://www.twitter.com/AndyObtiva

···

On Aug 31, 2022, at 8:07 AM, Mohit Sindhwani <mo_mail@onghu.com> wrote:
 Hi Everyone,

I have been thinking about writing a blog post for creating a native gem but rather than going forward (i.e., creating a gem), I am thinking of starting with an open source gem and looking at what it does and how.

I intend to use a simple single-file C gem [https://github.com/klaxit/fast-polylines\] as the base and I'm thinking of this as the rough outline. Open to get some inputs on whether you'd be interested in anything more on this?

About the Gem itself
# Background to the Gem
# Installing the Gem from Rubygems
# Unpacking the Gem so that we can study it
# Alternatively, grabbing the source from GitHub
# Building the Gem and Installing it Locally
# Running the Tests
# Running the Performance Comparison
# Making Changes

Looking at Everything
# How the interface works from Ruby <-> C
# What the C code looks like
# What the Ruby code looks like
# Looking at the Makefile
# Having a Makefile that also works on Windows
# How the specs are run and what they test
# Adding Performance Comparisons

Finally (possibly)
# How can we improve the gem/ make it more intuitive to use

I expect it to take a few weeks to put together, so don't expect it any time soon :slight_smile:

Best regards,
Mohit.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thanks Andy! Regular C is first. I myself need to get into Crystal, so that may be much later. Here are some links for Crystal gems for Ruby that I had got from a Twitter request.

Best wishes,
Mohit.

···

On 2022-9-1 11:05 am, Andy Maleh wrote:

Recently, I did some research into building a Ruby gem with native extensions built with Crystal. I stopped because the project for doing this (Crystallized Ruby) hasn’t been maintained for a while. But, I might have heard that it still works completely or partially anyways.

So, if you explore building a Ruby gem with a Crystal-lang native extension, I’d be very interested in reading such a blog post.

1 Like

Is crystal developed by ruby or C?

Thanks

···

On Fri, Sep 2, 2022 at 1:29 PM Mohit Sindhwani <mo_mail@onghu.com> wrote:

On 2022-9-1 11:05 am, Andy Maleh wrote:
>  Recently, I did some research into building a Ruby gem with native
> extensions built with Crystal. I stopped because the project for doing
> this (Crystallized Ruby) hasn’t been maintained for a while. But, I
> might have heard that it still works completely or partially anyways.
>
> So, if you explore building a Ruby gem with a Crystal-lang native
> extension, I’d be very interested in reading such a blog post.
>

Thanks Andy! Regular C is first. I myself need to get into Crystal, so
that may be much later. Here are some links for Crystal gems for Ruby
that I had got from a Twitter request.

https://twitter.com/alexanderadam__/status/1558537907899695104?s=20&t=iXG-nEYyQWY0z1hcNhyzCA

Best wishes,
Mohit.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Like a lot of compiled programming languages, Crystal is self-hosted, so a Crystal compiler is written in... Crystal.

···

On 9/2/22 07:35, Henrik P wrote:

Is crystal developed by ruby or C?

Thanks

Quoting hmdne (hmdne@airmail.cc):

Like a lot of compiled programming languages, Crystal is self-hosted, so a
Crystal compiler is written in... Crystal.

Yes, but what is the intermediate when it comes to feeding machine
instructions to the processor? Processors do not understand Crystal.

I know the answer: Crystal requires LLVM. Which requires C++. That's
why Crystal is a no-go for me.

Carlo

···

Subject: [ruby-talk:442959] Re: Learning by Reversing - thinking about a post
  Date: Fri 02 Sep 22 07:42:44AM +0200

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

A very long time ago i tried making a new binding against C++ library
wxWidgets:

the goal while doing that was to write as less code as possible, and not
to duplicate code (because this leats to failures)

but because wxWidgets is a bit tricky in the use of their pointers i
tried my own magic there (so i don't want to just use some wrapper that
wraps everything)

for example wWindow#GetLabel and SetLabel are done with this one line:

calling a bunch of macros there:

which results in 2 C functions ala _get_Label and _set_Label inside a
C++ namespace
inside them there is use of two template functions, called wrap and
unwrap, and another macro to _self

like in case of the _get_Label function, _self turns the C VALUE self
into wxWindow pointer using unwrap.
then calls the C++ function GetLabel, which takes the returned wxString
and uses wrap function to turn it onto a Ruby String

for _set_Label, it is the other way around, it takes the C VALUE get
from the parameter, and tries to read it as a Ruby String,
if that works, it uses unwrap to make a new wxString out of that Ruby
String.
then uses _self to get the wxWindow Pointer and calls the C++ Function
SetLabel

the only thing for the binding left to do is to register them in Ruby,
for documentation purposes i register them as attr inside a #if 0

but the real is defined there

The Wrappers for Pointers for example store them inside some internal
holder,
that causes them to return always the same ruby object for the same pointer,
while on the other side protect them from Ruby's GC for as long as i
want to hold them.

The Unwrappers on the other hand has some logic to not just turn Ruby
Point objects into wxPoint,
but using duck-typing all objects that might have "x" and "y" methods too

···

--

Hanmac

Am 02.09.22 um 07:28 schrieb Mohit Sindhwani:

On 2022-9-1 11:05 am, Andy Maleh wrote:

Recently, I did some research into building a Ruby gem with native
extensions built with Crystal. I stopped because the project for
doing this (Crystallized Ruby) hasn’t been maintained for a while.
But, I might have heard that it still works completely or partially
anyways.

So, if you explore building a Ruby gem with a Crystal-lang native
extension, I’d be very interested in reading such a blog post.

Thanks Andy! Regular C is first. I myself need to get into Crystal, so
that may be much later. Here are some links for Crystal gems for Ruby
that I had got from a Twitter request.

https://twitter.com/alexanderadam__/status/1558537907899695104?s=20&t=iXG-nEYyQWY0z1hcNhyzCA

Best wishes,
Mohit.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thank you for replying Hans Mackowiak.

I would be highly interested in you continuing the development of your
WxWidgets binding project.

I have developed Glimmer as a DSL framework that is used to wrap Ruby C/C++
bindings for various GUI toolkits and make interaction with them more Ruby
friendly while following convention over configuration.

For example, Glimmer DSL for LibUI recently wrapped the Ruby LibUI gem to
provide a DSL for it while also guarding against the garbage collection of
C pointers in it automatically.

I would really be interested in supporting WxWidgets too because it's a
mature and stable native widgets toolkit.

Cheers,

···

On Fri, Sep 2, 2022 at 1:54 AM Hans Mackowiak <hanmac@gmx.de> wrote:

A very long time ago i tried making a new binding against C++ library
wxWidgets:

GitHub - Hanmac/rwx: wxWidgets binding for ruby

the goal while doing that was to write as less code as possible, and not
to duplicate code (because this leats to failures)

but because wxWidgets is a bit tricky in the use of their pointers i
tried my own magic there (so i don't want to just use some wrapper that
wraps everything)

for example wWindow#GetLabel and SetLabel are done with this one line:
rwx/wxWindow.cpp at master · Hanmac/rwx · GitHub

calling a bunch of macros there:
rwx/main.hpp at master · Hanmac/rwx · GitHub

which results in 2 C functions ala _get_Label and _set_Label inside a
C++ namespace
inside them there is use of two template functions, called wrap and
unwrap, and another macro to _self

like in case of the _get_Label function, _self turns the C VALUE self
into wxWindow pointer using unwrap.
then calls the C++ function GetLabel, which takes the returned wxString
and uses wrap function to turn it onto a Ruby String

for _set_Label, it is the other way around, it takes the C VALUE get
from the parameter, and tries to read it as a Ruby String,
if that works, it uses unwrap to make a new wxString out of that Ruby
String.
then uses _self to get the wxWindow Pointer and calls the C++ Function
SetLabel

the only thing for the binding left to do is to register them in Ruby,
for documentation purposes i register them as attr inside a #if 0
rwx/wxWindow.cpp at master · Hanmac/rwx · GitHub
but the real is defined there
rwx/wxWindow.cpp at master · Hanmac/rwx · GitHub

The Wrappers for Pointers for example store them inside some internal
holder,
that causes them to return always the same ruby object for the same
pointer,
while on the other side protect them from Ruby's GC for as long as i
want to hold them.

The Unwrappers on the other hand has some logic to not just turn Ruby
Point objects into wxPoint,
but using duck-typing all objects that might have "x" and "y" methods too

--

Hanmac

Am 02.09.22 um 07:28 schrieb Mohit Sindhwani:
> On 2022-9-1 11:05 am, Andy Maleh wrote:
>>  Recently, I did some research into building a Ruby gem with native
>> extensions built with Crystal. I stopped because the project for
>> doing this (Crystallized Ruby) hasn’t been maintained for a while.
>> But, I might have heard that it still works completely or partially
>> anyways.
>>
>> So, if you explore building a Ruby gem with a Crystal-lang native
>> extension, I’d be very interested in reading such a blog post.
>>
>
> Thanks Andy! Regular C is first. I myself need to get into Crystal, so
> that may be much later. Here are some links for Crystal gems for Ruby
> that I had got from a Twitter request.
>
>
https://twitter.com/alexanderadam__/status/1558537907899695104?s=20&t=iXG-nEYyQWY0z1hcNhyzCA
>
>
> Best wishes,
> Mohit.
>
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Andy Maleh

LinkedIn: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh&gt;
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva&gt;

Thankfully, someone is resurrecting the rwx project with a Pull Request:

I look forward to continued support of this project. I have been seeking
community efforts to support wxWidgets in Ruby again for a while recently.
I'm very happy this happened and I got informed of it through the Ruby-Talk
mailing list.

If I get this working on my machine, I'll look into building a Glimmer DSL
for WX in the near future to wrap the wxWidgets library:
https://www.wxwidgets.org/

Cheers,

···

On Fri, Sep 2, 2022 at 10:33 AM Andy Maleh <andy.am@gmail.com> wrote:

Thank you for replying Hans Mackowiak.

I would be highly interested in you continuing the development of your
WxWidgets binding project.

I have developed Glimmer as a DSL framework that is used to wrap Ruby
C/C++ bindings for various GUI toolkits and make interaction with them more
Ruby friendly while following convention over configuration.

GitHub - AndyObtiva/glimmer: DSL Framework consisting of a DSL Engine and a Data-Binding Library used in Glimmer DSL for SWT (JRuby Desktop Development GUI Framework), Glimmer DSL for Opal (Pure Ruby Web GUI), Glimmer DSL for LibUI (Prerequisite-Free Ruby Desktop Development GUI Library), Glimmer DSL for Tk (Ruby Tk Desktop Development GUI Library), Glimmer DSL for GTK (Ruby-GNOME Desktop Development GUI Library), Glimmer DSL for XML (& HTML), and Glimmer DSL for CSS

For example, Glimmer DSL for LibUI recently wrapped the Ruby LibUI gem to
provide a DSL for it while also guarding against the garbage collection of
C pointers in it automatically.

GitHub - AndyObtiva/glimmer-dsl-libui: Glimmer DSL for LibUI (Prerequisite-Free Ruby Desktop Development GUI Library - No need to pre-install any prerequisites. Just install the gem and have platform-independent GUI that just works)

I would really be interested in supporting WxWidgets too because it's a
mature and stable native widgets toolkit.

Cheers,

On Fri, Sep 2, 2022 at 1:54 AM Hans Mackowiak <hanmac@gmx.de> wrote:

A very long time ago i tried making a new binding against C++ library
wxWidgets:

GitHub - Hanmac/rwx: wxWidgets binding for ruby

the goal while doing that was to write as less code as possible, and not
to duplicate code (because this leats to failures)

but because wxWidgets is a bit tricky in the use of their pointers i
tried my own magic there (so i don't want to just use some wrapper that
wraps everything)

for example wWindow#GetLabel and SetLabel are done with this one line:
rwx/wxWindow.cpp at master · Hanmac/rwx · GitHub

calling a bunch of macros there:
rwx/main.hpp at master · Hanmac/rwx · GitHub

which results in 2 C functions ala _get_Label and _set_Label inside a
C++ namespace
inside them there is use of two template functions, called wrap and
unwrap, and another macro to _self

like in case of the _get_Label function, _self turns the C VALUE self
into wxWindow pointer using unwrap.
then calls the C++ function GetLabel, which takes the returned wxString
and uses wrap function to turn it onto a Ruby String

for _set_Label, it is the other way around, it takes the C VALUE get
from the parameter, and tries to read it as a Ruby String,
if that works, it uses unwrap to make a new wxString out of that Ruby
String.
then uses _self to get the wxWindow Pointer and calls the C++ Function
SetLabel

the only thing for the binding left to do is to register them in Ruby,
for documentation purposes i register them as attr inside a #if 0
rwx/wxWindow.cpp at master · Hanmac/rwx · GitHub
but the real is defined there
rwx/wxWindow.cpp at master · Hanmac/rwx · GitHub

The Wrappers for Pointers for example store them inside some internal
holder,
that causes them to return always the same ruby object for the same
pointer,
while on the other side protect them from Ruby's GC for as long as i
want to hold them.

The Unwrappers on the other hand has some logic to not just turn Ruby
Point objects into wxPoint,
but using duck-typing all objects that might have "x" and "y" methods too

--

Hanmac

Am 02.09.22 um 07:28 schrieb Mohit Sindhwani:
> On 2022-9-1 11:05 am, Andy Maleh wrote:
>>  Recently, I did some research into building a Ruby gem with native
>> extensions built with Crystal. I stopped because the project for
>> doing this (Crystallized Ruby) hasn’t been maintained for a while.
>> But, I might have heard that it still works completely or partially
>> anyways.
>>
>> So, if you explore building a Ruby gem with a Crystal-lang native
>> extension, I’d be very interested in reading such a blog post.
>>
>
> Thanks Andy! Regular C is first. I myself need to get into Crystal, so
> that may be much later. Here are some links for Crystal gems for Ruby
> that I had got from a Twitter request.
>
>
https://twitter.com/alexanderadam__/status/1558537907899695104?s=20&t=iXG-nEYyQWY0z1hcNhyzCA
>
>
> Best wishes,
> Mohit.
>
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

--
Andy Maleh

LinkedIn: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh&gt;
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva&gt;

--
Andy Maleh

LinkedIn: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh&gt;
Blog: http://andymaleh.blogspot.com
GitHub: AndyObtiva (Andy Maleh) · GitHub
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva&gt;