Eiffel vs Smalltalk

108 views
Skip to first unread message

Saša Janiška

unread,
Jan 9, 2020, 11:22:40 AM1/9/20
to eiffel...@googlegroups.com
Hello,

in my quest to pick correct language for the open-source GUI project
have eliminated some more languages from my list and while waiting for
installation issue to be resolved, I'd like to get some input on the
following issue: introductory docs very often compare Eiffel with C++
and Smalltalk. I did eliminate C++ from my equation long ago and would
like to get some inputin regard to Eiffel vs Smaltalk...

Here I'm thinking about Pharo and some of its aspects provide clear
advantages over Eiffel like size & activity of the community, clear
roadmap of the project, licensing etc.

On the other hand Eiffel does support usage of convenient tools like
editor (e.g. Vim in my case), VCS tool (Fossil), file-based projects vs
image-based in Pharo.

However, there are many unknown things to me, about which I'd like to
get more info to make it easier to finally decide...

So, can anyone shed some more light about Eiffel vs Pharo (Smalltlak) as
adequate language to be used for hobby project?


Sincerely,
Saša

--
As a strong wind sweeps away a boat on the water,
even one of the roaming senses on which the mind
focuses can carry away a man's intelligence.

Davide Grandi

unread,
Jan 9, 2020, 5:34:48 PM1/9/20
to eiffel...@googlegroups.com
Both.
The choice of what/when/who drive the other language is up to you.
But if you mix the two you'll never regret to learn both.

Good luck & best regards,

Davide

On 09/01/2020 17:22, Saša Janiška wrote:
> Hello,
>
> in my quest to pick correct language for the open-source GUI project
> have eliminated some more languages from my list and while waiting for
> installation issue to be resolved, I'd like to get some input on the
> following issue: introductory docs very often compare Eiffel with C++
> and Smalltalk. I did eliminate C++ from my equation long ago and would
> like to get some inputin regard to Eiffel vs Smaltalk...
>
> Here I'm thinking about Pharo and some of its aspects provide clear
> advantages over Eiffel like size & activity of the community, clear
> roadmap of the project, licensing etc.
>
> On the other hand Eiffel does support usage of convenient tools like
> editor (e.g. Vim in my case), VCS tool (Fossil), file-based projects vs
> image-based in Pharo.
>
> However, there are many unknown things to me, about which I'd like to
> get more info to make it easier to finally decide...
>
> So, can anyone shed some more light about Eiffel vs Pharo (Smalltlak) as
> adequate language to be used for hobby project?
>
> Sincerely,
> Saša
>

--
Ing. Davide Grandi
email : davide...@email.it
mobile : +39 339 7468 778

Larry Rix

unread,
Jan 9, 2020, 7:18:59 PM1/9/20
to Eiffel Users
I have landed on Eiffel for both desktop and web development and never looked back or further.

I cannot speak to SmallTalk as I have never used it—but—I don't need to. Eiffel accomplishes all that I need.


Kindest regards,

Larry

Saša Janiška

unread,
Jan 10, 2020, 2:49:03 AM1/10/20
to eiffel...@googlegroups.com
On Thu, 9 Jan 2020 23:34:42 +0100
Davide Grandi <davide...@email.it> wrote:

> Both.

:-)

> The choice of what/when/who drive the other language is up to you.
> But if you mix the two you'll never regret to learn both.

Well, considering it is going to be a project done in the limited amount of my
free time, I can't afford to learn both and therefore aiming for one only...


Sincerely,
Saša

--

Saša Janiška

unread,
Jan 10, 2020, 2:54:50 AM1/10/20
to eiffel...@googlegroups.com
On Thu, 9 Jan 2020 16:18:59 -0800 (PST)
Larry Rix <lar...@moonshotsoftware.com> wrote:

> I have landed on Eiffel for both desktop and web development and
> never looked back or further.

I'm glad seeing you use Eiffel for desktop apps.

> I cannot speak to SmallTalk as I have never used it—but—I don't need
> to. Eiffel accomplishes all that I need.

Thanks. At the moment, Eiffel makes it easier for creatign stand-alone
executables, while it is still on Pharo's roadmap...but, I'm still open for
mire input while waiting to be able to run EiffelStudio on my Manjaro Linux
machine.

Sincerely,
Saša

p.s. @Finnian: the issue I have with running ES on my machine seems similar to
the problem I had/have with MyChing.

--
A person is considered still further advanced when he regards honest
well-wishers, affectionate benefactors, the neutral, mediators, the
envious, friends and enemies, the pious and the sinners all with an
equal mind.

Gary Smithrud (GMS134)

unread,
Jan 10, 2020, 5:56:14 AM1/10/20
to eiffel...@googlegroups.com
Smalltalk taught me a very valuable lesson and is the reason why I hate all dynamic typed languages.

Sent from my iPhone

> On Jan 10, 2020, at 2:54 AM, Saša Janiška <sjan...@gmail.com> wrote:
>
> On Thu, 9 Jan 2020 16:18:59 -0800 (PST)
> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20200110085446.5f0b6deb%40atmarama.ddns.net.

Saša Janiška

unread,
Jan 11, 2020, 5:21:58 AM1/11/20
to Eiffel Users
On Friday, January 10, 2020 at 11:56:14 AM UTC+1, GMS wrote:
Smalltalk taught me a very valuable lesson and is the reason why I hate all dynamic typed languages.

Can you elaborate a bit?

Is it just static vs dynamic typing or something else...I'm really interested to hear?


Sincerely,
Saša

Larry Rix

unread,
Jan 11, 2020, 7:30:43 AM1/11/20
to Eiffel Users
Hey GMS!

You and I both! I got roped into Visual FoxPro back in the day. VFP is dynamic typing and a void-safe nightmare! These were the two most common issues I ran into when using VFP. I could never trust the type of a reference nor that it was initialized and remained connected once it was initialized.

Thinking of that—Void-safety alone would shift me off of SmallTalk towards Eiffel. I now code is nothing but Void-safe systems and cannot stand going back to non-Void-safe. It is quite irritating to have to constantly exercise the mental labor of protecting against Void-targets! At this stage in my software career, I am quite settled that Void-safe target calls are the responsibility of the compiler and a programmer ought never to need to consider it other than to work with the compiler.

Gary Smithrud (GMS134)

unread,
Jan 11, 2020, 7:36:29 AM1/11/20
to Saša Janiška, Eiffel Users
It is the issue where type errors are caught at runtime is very bad. My experience with Smalltalk was with a modeling and simulation class assignment (instructors typically allowed me to use other languages for assignments). Basically the simulation ran to completion without issues but with the wrong answer. The problem? I called a method that was defined for my class, but I had an object of the wrong type...which also had a method with the same name. I spent too much time stepping through code, where a compiler for a strongly type language would, obviously caught it immediately.

As a grade student, a research project I wrote in Objective Lisp (limited choices in 1988) had a very important demo and 30 minutes before hand I ran across a Method not Found exception. This is the wrong time to receive such things.

Basically, dynamic type languages have a huge cost with no benefits. Sometimes there are no choices (such as early web browser/JavaScript days). In addition, dynamic typed languages are moving to static typed languages (Python 3) and a couple of JS replacements.

Sent from my iPhone

> On Jan 11, 2020, at 5:22 AM, Saša Janiška <sjan...@gmail.com> wrote:
>

Gary Smithrud (GMS134)

unread,
Jan 11, 2020, 7:54:34 AM1/11/20
to eiffel...@googlegroups.com
Void safety is absolutely the greatest things since sliced bread (ok, there was a few good thing in between).  Not only is a great benefit to individual developers, but is a huge benefit (along with Eiffel’s other features) to large teams of developers.  Too many times I’ve received bug reports because my method complained about a null parameter, where someone else just didn’t bother checking before the call.  Granted, I did have to write the check...and put in the Java doc that the parameter can’t be null...they do it anyway.  Ends up being me that fix it as well.

Sent from my iPhone

On Jan 11, 2020, at 7:30 AM, Larry Rix <lar...@moonshotsoftware.com> wrote:


--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

Finnian Reilly

unread,
Jan 11, 2020, 9:29:34 AM1/11/20
to eiffel...@googlegroups.com
Hi Saša
since you are willing to consider a dynamically typed  language for your project, I would suggest looking at Python for the simple reason that Python has probably the best and most mature binding for wxWidgets. (Judging by the number of books published on wxPython)

wxWidgets is a popular and very well supported project allowing you to create cross platform GUI applications that work on all 3 major desktop platforms. I really wish Eiffel had a wxWidgets binding this good.

Also vim has support for Python.

I know Smalltalk also has a binding for WxWidgets but the project website domain is dormant. This is a bad sign indicating that the project is likely no longer maintained.



regards
Finnian
Hello,

in my quest to pick correct language for the open-source GUI project
have eliminated some more languages from my list and while waiting for
installation issue to be resolved, I'd like to get some input on the
following issue: introductory docs very often compare Eiffel with C++
and Smalltalk. I did eliminate C++ from my equation long ago and would
like to get some inputin regard to Eiffel vs Smaltalk...

Here I'm thinking about Pharo and some of its aspects provide clear
advantages over Eiffel like size & activity of the community, clear
roadmap of the project, licensing etc.

On the other hand Eiffel does support usage of convenient tools like
editor (e.g. Vim in my case), VCS tool (Fossil), file-based projects vs
image-based in Pharo.

However, there are many unknown things to me, about which I'd like to
get more info to make it easier to finally decide...

So, can anyone shed some more light about Eiffel vs Pharo (Smalltlak) as
adequate language to be used for hobby project?


Sincerely,
Saša


-- 
SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read

Saša Janiška

unread,
Jan 12, 2020, 2:56:47 AM1/12/20
to eiffel...@googlegroups.com
On Sat, 11 Jan 2020 04:30:43 -0800 (PST)
Larry Rix <lar...@moonshotsoftware.com> wrote:

> Thinking of that—Void-safety alone would shift me off of SmallTalk
> towards Eiffel. I now code is nothing but Void-safe systems and
> cannot stand going back to non-Void-safe.

[...]

> At this stage in my software career, I am quite settled that Void-safe target
> calls are the responsibility of the compiler and a programmer ought never to
> need to consider it other than to work with the compiler.

Well-spoken. ;)


Sincerely,
Saša

--
He who is satisfied with gain which comes of its own accord, who
is free from duality and does not envy, who is steady in both
success and failure, is never entangled, although performing actions.

Saša Janiška

unread,
Jan 12, 2020, 2:59:18 AM1/12/20
to Eiffel Users
On Sat, 11 Jan 2020 07:36:27 -0500
"Gary Smithrud (GMS134)" <gary.s...@gmail.com> wrote:

> Basically, dynamic type languages have a huge cost with no benefits.

I was told by some about Smalltalk's productivity and that was the main reason
to consider Pharo since, otherwise, I did not plan e.g. to use dynamic
languages like Python...

Sincerely,
Saša

--

Saša Janiška

unread,
Jan 12, 2020, 3:12:09 AM1/12/20
to eiffel...@googlegroups.com
On Sat, 11 Jan 2020 14:29:28 +0000
Finnian Reilly <fin...@eiffel-loop.com> wrote:

Hello Finnian,

> since you are willing to consider a dynamically typed  language for
> your project, I would suggest looking at Python for the simple reason
> that Python has probably the best and most mature binding for
> wxWidgets. (Judging by the number of books published on wxPython)

Well, as I mentioned in another email (in in prior corresponce with you), I am
not really into dynamic typed languages considering that they could saver some
dev-time upfront, but probably being cause of lot of debug time later...

> wxWidgets is a popular and very well supported project allowing you
> to create cross platform GUI applications that work on all 3 major
> desktop platforms. I really wish Eiffel had a wxWidgets binding this
> good.

However, your mentioning of wxWIdgets is interesting since now I recall that
long ago when I was plaing with Haskell I Was thinking about using wxHaskell
and can remember that wxEiffel bindings were used as the basis for Haskell
bindings, so just wonder what had happened with wxEiffel?

I also consider that having wxEiffel would be excellent choise, since nowadays
wxQt port is also in much better shape than in the past (see
https://wiki.wxwidgets.org/WxQt/Status) and would maybe/probably provide more
stable option than the one provided by modern GTK+ (gtk3, gtk4...).

I decided not to use Racket since it looks that the language does cover a lot
and would probably require learning mayn things I'm probably not interest
within the scope of my project. Moreover, there is talk of another version in
the future which would possibly have non-Scheme syntax.

Otoh, Eiffel looks as more conservative option in the long run keeping one's
time/coding-investment more future-safe. Let's hope the community will increase
a bit as well...having wxEiffel would be superb, but at the moment although I
am ready to start exploring Eiffel, do some bindings of the library I'd have to
use, I can't run ES on my Manjaro/Arch machine. :-(


Sincerely,
Saša

--
When your intelligence has passed out of the dense forest
of delusion, you shall become indifferent to all that has
been heard and all that is to be heard.

Larry Rix

unread,
Jan 12, 2020, 5:40:53 AM1/12/20
to Eiffel Users
Good morning,  Saša  

While I was a VFP programmer, I never considered the language to have a "huge cost". Why? Because I did not know better. Moreover, I was taught to "sing-the-praises" of the language, so how could I possibly honestly look at it when I was taught and indoctrinated into thinking VFP was the greatest thing ever? Since then, I have learned that programmers treat programming languages like religion and no one tears down their own faith, eh?

I also learned to tolerate the pain of using VFP. I never questioned dynamic typing as a bad thing (see point above). I never once thought seriously or for very long about how nice it would be to have the compiler catch my type-errors. I did think about the labor-intense process of having to manually assure type-safety, but I swallowed that and accepted it because it was a required pain if one was to use VFP—and—I was making money with VFP and money and feeding my family was worth any pain I suffered. Hey—and if an employer was willing to write me a check each month, who was I to complain?

So—the point is simply this—each language TOOL comes with faults and pressure or pain points. With what TOOL are those reduced and by how far? Moreover, how much does MONEY drive the "love" of a TOOL? Also—how does "group-think" and "peer-pressure" or "group-dynamic" elevate the TOOL to where people are singing praises and feel a pressure (or worse never consider) objectively assessing it?

Folks in the Eiffel community are sometimes accused of being "zealots" and holding the TOOL higher than it ought. We get the equivalent of the "you-re-just-a-HATER" speech when talking about Eiffel as a TOOL compared to other TOOLS. The other version we get all the time is the "holier-than-thou" speech as though programming languages are faiths and religions and not just engineering TOOLS!

I have spent a long time doing this now and I may have actually crossed the line. There are many here including Dr. Meyer, who can tell you that I have done my share of bashing of Eiffel for what I see as its faults. The TOOL (it is after all just a TOOL) on the whole does have a few faults. Laying those aside, I have never yet found a TOOL that is as finely crafted to the purpose of creating software with the least amount of cost and pain (if one remains smart and level headed).

I am quite sure the SmallTalk folks will provide a glowing report of SmallTalk as a TOOL. Just be aware of the blinders that people have to their TOOLS and the faults (pain and pressure points) of them.

Kindest regards,

Larry Rix

Larry Rix

unread,
Jan 12, 2020, 7:01:00 AM1/12/20
to Eiffel Users
Finnian makes an excellent point! One of my major complaints about Eiffel, on the whole, has to do with a severe lack of what I might call "libraries-in-depth"—that is—we have libraries (sure we do), but they are not wide-and-deep. Wide in the sense of broad coverage of relevant technologies (e.g. a cell phone option in Eiffel)—Deep in the sense of high-level abstraction versus low-level.

Now—that said—I am delighted to be working with Javier and Jocelyn on the WrapC effort because having a robust and easy-to-use C/C++ library wrapping tool opens Eiffel up very quickly to a wealth of wide-and-deep libraries without having to recode them in Eiffel directly.

The Eiffel folks have done an excellent job at building the fledgling basis for web-development in EWF. The way I see it now—if the WrapC/UI effort can quickly blossom into a wealth of C/C++ library inclusion, then we're well on our way to finally being a serious contender in a world driven by "popularity" and money-making.

I have let it slip to the side, but this same idea of bolting-on existing "popular" work is what was driving me to create an HTML and BootStrap library for EWF/Eiffel—an effort to leverage the wide-and-deep coverage of these two core technologies and make them simple and easy to leverage in Eiffel.

Saša Janiška

unread,
Jan 12, 2020, 9:04:07 AM1/12/20
to eiffel...@googlegroups.com
On Sun, 12 Jan 2020 05:40:41 -0500
Larry Rix <lar...@moonshotsoftware.com> wrote:

Hiya Larry,

> While I was a VFP programmer, I never considered the language to have
> a "huge cost". Why? Because I did not know better.

:-)

> I also learned to tolerate the pain of using VFP. I never questioned
> dynamic typing as a bad thing (see point above). I never once thought
> seriously or for very long about how nice it would be to have the
> compiler catch my type-errors. I did think about the labor-intense
> process of having to manually assure type-safety, but I swallowed
> that and accepted it because it was a required pain if one was to use
> VFP—and—I was making money with VFP and money and feeding my family
> was worth any pain I suffered. Hey—and if an employer was willing to
> write me a check each month, who was I to complain?

Fair enough. :-)

> Laying those aside, I have never yet found a TOOL that is as finely crafted
> to the purpose of creating software with the least amount of cost and pain
> (if one remains smart and level headed).

That hit the nail, indeed. Thanks a lot!

> I am quite sure the SmallTalk folks will provide a glowing report of
> SmallTalk as a TOOL.

Sure. I even got an explanation why static typing is not so important in
Smalltalk. I won't go into it since Eiffel suits my mind better with file-based
approch, ability to use one's own editor, keeping things under version control,
standalone executables and, of course, static typing. ;)

Now, if I just would be able to use ES...


Sincerely,
Saša

--
A self-realized man has no purpose to fulfill in the discharge
of his prescribed duties, nor has he any reason not to perform
such work. Nor has he any need to depend on any other living being.

Saša Janiška

unread,
Jan 12, 2020, 9:12:19 AM1/12/20
to eiffel...@googlegroups.com
On Sun, 12 Jan 2020 04:00:59 -0800 (PST)
Larry Rix <lar...@moonshotsoftware.com> wrote:

> Wide in the sense of broad coverage of
> relevant technologies (e.g. a cell phone option in Eiffel)—Deep in
> the sense of high-level abstraction versus low-level.

Fortunately, being somewhat an old guy, I still prefer desktop and use my
"smart" phone for what it it is primarily designed. :-)

> Now—that said—I am delighted to be working with Javier and Jocelyn on the
> WrapC effort

I definetely have an use-case to WrapC effort to bind 3rd party C library
required for my project...

> because having a robust and easy-to-use C/C++ library wrapping tool opens
> Eiffel up very quickly to a wealth of wide-and-deep libraries without having
> to recode them in Eiffel directly.

Do I read correctly "C/C++ library wrapping tool" since in that case I strongly
believe that it would be worthwhile to join forces and revive wxEiffel project!
(It was good enough in the past to provide basis for wxHaskell!!)

> The Eiffel folks have done an excellent job at building the fledgling
> basis for web-development in EWF.

Another area I understand is important for many folks, but for myself I try to
fullfill all my web-related needs with TIki (https://tiki.org/) - it's PHP, but
it does the job. :-D

> The way I see it now—if the WrapC/UI effort can quickly blossom into a wealth
> of C/C++ library inclusion, then we're well on our way to finally being a
> serious contender in a world driven by "popularity" and money-making.

That would be very nice, indeed.

> I have let it slip to the side, but this same idea of bolting-on existing
> "popular" work is what was driving me to create an HTML and BootStrap library
> for EWF/Eiffel—an effort to leverage the wide-and-deep coverage of these two
> core technologies and make them simple and easy to leverage in Eiffel.

"Utility is the principle" - I have no objection in regard. ;)


Sincerely,
Saša

--
There is no possibility of one's becoming a yogī, O Arjuna,
if one eats too much or eats too little, sleeps too much
or does not sleep enough.

Larry Rix

unread,
Jan 12, 2020, 9:52:59 AM1/12/20
to Eiffel Users
Looks like wxWidgets is a very current and lively project. @  https://github.com/wxWidgets/wxWidgets  

Javier or Jocelyn, please help me to clarify if WrapC can do C++ or is it just C?

David Jenkins

unread,
Jan 13, 2020, 2:01:19 AM1/13/20
to eiffel...@googlegroups.com
I worked on a Smalltalk application for 16 years for a major airline. We used it to schedule maintenance on aircraft, so it was very important. I was not involved with the development of the application, but came in after it had been deployed. The user interface was quite innovative; the users liked it. I was told that Smalltalk made developing the application much easier and faster than other options available at the time (C, C++, Visual Basic. Sadly I don't believe they considered Eiffel.) - in fact I'm not sure if the other options could have built that UI in the time allowed. 

Maintenance, which I was responsible for, was another thing. I can remember many times wishing I could tell from a method's (feature's) signature what the type of an object was supposed to be. Lack of static typing made both debugging and enhancements more difficult. The development environment made up for some of the shortcomings - it was easy to create test data, step through execution and examine the contents of objects - but not all of them. I'd say Smalltalk had a lot of advantages for building applications, not so many for maintaining them. My impression is that Python is similar.



Saša

--

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20200112085915.6b29a1fe%40atmarama.ddns.net.

Saša Janiška

unread,
Jan 13, 2020, 3:49:55 AM1/13/20
to eiffel...@googlegroups.com
On Sun, 12 Jan 2020 16:17:34 +0000 (UTC)
"'David Jenkins' via Eiffel Users" <eiffel...@googlegroups.com>
wrote:

> I'd say Smalltalk had a lot of advantages for building applications, not so
> many for maintaining them. My impression is that Python is similar.

Nice summary!

Considering the nature of my project it looks as Eiffel is better (best)
option. ;)


Sincerely,
Saša

--
A person is said to be established in self-realization and is called a
yogī [or mystic] when he is fully satisfied by virtue of acquired
knowledge and realization. Such a person is situated in transcendence
and is self-controlled. He sees everything — whether it be pebbles,
stones or gold — as the same.

javier hector

unread,
Jan 13, 2020, 7:19:56 AM1/13/20
to Eiffel Users


On Sunday, January 12, 2020 at 11:52:59 AM UTC-3, Larry Rix wrote:
Looks like wxWidgets is a very current and lively project. @  https://github.com/wxWidgets/wxWidgets  

Javier or Jocelyn, please help me to clarify if WrapC can do C++ or is it just C?

WrapC only wraps C code.
--Javier

Larry Rix

unread,
Jan 13, 2020, 7:41:00 AM1/13/20
to Eiffel Users
I stand corrected! Only C and not C++. That's too bad! But—on the bright side, it is far better than nothing at all!

Saša Janiška

unread,
Jan 13, 2020, 9:35:23 AM1/13/20
to eiffel...@googlegroups.com
On Mon, 13 Jan 2020 07:40:49 -0500
Larry Rix <lar...@moonshotsoftware.com> wrote:

> I stand corrected! Only C and not C++. That's too bad!

For my project binding C is enough and welcome to have some tool to autoamte
process a bit.

> But—on the bright side, it is far better than nothing at all!

Yes. Moreover wxEiffel seems to be made without any tool, but any tool to help
with the C++ bindings would be nice to have...


Sincerely,
Saša

--
He is a perfect yogī who, by comparison to his own self,
sees the true equality of all beings, in both their
happiness and their distress, O Arjuna!

javier hector

unread,
Jan 13, 2020, 10:31:15 AM1/13/20
to Eiffel Users


On Monday, January 13, 2020 at 11:35:23 AM UTC-3, Saša Janiška wrote:
On Mon, 13 Jan 2020 07:40:49 -0500
Larry Rix <lar...@moonshotsoftware.com> wrote:

> I stand corrected! Only C and not C++. That's too bad!

For my project binding C is enough and welcome to have some tool to autoamte
process a bit.
If you can share the list of C libraries that you want to wrap, I can help you get started with them,

> But—on the bright side, it is far better than nothing at all!

Yes. Moreover wxEiffel seems to be made without any tool, but any tool to help
with the C++ bindings would be nice to have...

--Javier

Saša Janiška

unread,
Jan 14, 2020, 6:53:54 AM1/14/20
to eiffel...@googlegroups.com
On Mon, 13 Jan 2020 07:31:14 -0800 (PST) javier hector
<javier...@gmail.com> wrote:

Hello Javier,

> If you can share the list of C libraries that you want to wrap, I can
> help you get started with them,

Here is the lib I want to use:

https://www.astro.com/swisseph/swephprg.htm

The whole C API is summarized in these four steps:

(https://www.astro.com/swisseph/swephprg.htm#_Toc19111155)

1. Set the directory path of the ephemeris files, e.g.:

swe_set_ephe_path(”C:\\SWEPH\\EPHE”);

2. From the birth date, compute the Julian day number:

jul_day_UT = swe_julday(year, month, day, hour, gregflag);

3. Compute a planet or other bodies:

ret_flag = swe_calc_ut(jul_day_UT, planet_no, flag, lon_lat_rad, err_msg);

4. At the end of your computations close all files and free memory calling
swe_close();


The signatures are as follows:

1. void swe_set_ephe_path(char *path);

2. double swe_julday(int year, int month, int day, double hour, int gregflag);

3. long swe_calc_ut(

double tjd_ut, /* Julian day number, Universal Time */

int ipl, /* planet number */

long iflag, /* flag bits */

double *xx, /* target address for 6 position values: longitude, latitude, distance, long. speed, lat. speed, dist. speed */

char *serr); /* 256 bytes for error string */

4. void swe_close(void);

Of course, in real application, I'd like to provide thick bindings,
e.g. to provide appropriate class to store double *xx record etc. but
probably one has to start with thin C API wrapper first, right?

javier hector

unread,
Jan 14, 2020, 7:32:21 AM1/14/20
to Eiffel Users


On Tuesday, January 14, 2020 at 8:53:54 AM UTC-3, Saša Janiška wrote:
On Mon, 13 Jan 2020 07:31:14 -0800 (PST) javier hector
<javier...@gmail.com> wrote:

Hello Javier,

> If you can share the list of C libraries that you want to wrap, I can
> help you get started with them,

Here is the lib I want to use:

https://www.astro.com/swisseph/swephprg.htm
Ok I will take a look.

Saša Janiška

unread,
Oct 26, 2020, 9:25:51 AM10/26/20
to eiffel...@googlegroups.com
On Tue, 14 Jan 2020 04:32:21 -0800 (PST)
javier hector <javier...@gmail.com> wrote:

> > > If you can share the list of C libraries that you want to wrap, I
> > > can help you get started with them,
> >
> > Here is the lib I want to use:
> >
> > https://www.astro.com/swisseph/swephprg.htm
>
> Ok I will take a look.

In order to get real feeling (still have to digest Larry's elaborate answer)
for the language & (Eiffel) method, I'd like to check how easy/difficult is to
wrap 3rd party C library which I'd need for my project.

Moreover, I'm interested whether WrapC tool can help providing thicker bindings
which are more in Eiffel's spirit instead of plain thin wrapper over C API?

Lastly, I'm curious what does happen with Eiffel's "void safety" when dealing
with C libs and what about GC?


Sincerely,
Gour

--
Thus the wise living entity's pure consciousness becomes covered by
his eternal enemy in the form of lust, which is never satisfied and
which burns like fire.

javier...@gmail.com

unread,
Oct 27, 2020, 9:11:43 AM10/27/20
to Eiffel Users
On Monday, October 26, 2020 at 10:25:51 AM UTC-3 sjan...@gmail.com wrote:
On Tue, 14 Jan 2020 04:32:21 -0800 (PST)
javier hector <javier...@gmail.com> wrote:

> > > If you can share the list of C libraries that you want to wrap, I
> > > can help you get started with them,
> >
> > Here is the lib I want to use:
> >
> > https://www.astro.com/swisseph/swephprg.htm
>
> Ok I will take a look.

In order to get real feeling (still have to digest Larry's elaborate answer)
for the language & (Eiffel) method, I'd like to check how easy/difficult is to
wrap 3rd party C library which I'd need for my project.

Moreover, I'm interested whether WrapC tool can help providing thicker bindings
which are more in Eiffel's spirit instead of plain thin wrapper over C API?
WrapC is a low level wrapper. 

Lastly, I'm curious what does happen with Eiffel's "void safety" when dealing
with C libs and what about GC?
Reply all
Reply to author
Forward
0 new messages