[Cuis-dev] Porting from Pharo

[Gerald Klix]

Perhaps revealing my intentions is best:

I want have some tool to distribute updates
and maybe applications. I ran across this Smalltalk BitTorrent 
implementation:

https://github.com/dgraciac/BitTalk

I had the intention of porting it to Cuis.
I think a forking port/porting fork (sorry
couldn't resist that pun) is ok,
it wasn't updated for nearly to years.

Now I am under the impression, it isn't
trackerless, therefore I am not sure anymore.
So I will give it a spin on Pharo and
see how it works.


Since it's before 8am here, permit me a rant
about portability:

<rant>
When I was younger I was a big fan of
portability and (open) standards.

Microsoft's mantra about portability then was:

'Portability is for folding kayaks"

I learned the hard way that this motto has
something to it.

Most standards even the most rigid ones are
ambiguous to some extent and implementations
tend to vary in this places.
Me, doing mostly arcane things with
implementations, was hit hard, often.

More than 22 years ago, when looking for a tool
with Smalltalk's feeling, I ran across Python,
version 1.5.1 it was. There was no standard what
so ever, but the implementation adhered to its
documentation nearly literally. Even
undocumented corner cases showed a
unsurprising behavior.
That made think.

So in nutshell:
If porting (and forking) a library
takes me 1 day or so, I will do it over and over again, in the hope to 
bring down the time to
an hour or so, with some automation.
</rant>


Best Regards,

Gerald



On 2021-05-02 00:55, Juan Vuletich via Cuis-dev wrote:
> On 5/1/2021 3:47 PM, Gerald Klix via Cuis-dev wrote:
>> Hi all,
>>
>> is there an easy way to port source code from
>> Pharo to Cuis?
>>
>> I am aware of the tedious way:
>>
>> - File the package into a Pharo image
>> - File out the Categories involved
>> - Implement whatever it takes to
>>   achieve compatibility.
>>
>>
>> Thanks and Best Regards,
>>
>> Gerald
> 
> Beware of any automatic compatibility tool. Pharo and Cuis are 
> incompatible at many places, and a good old human review of the code is 
> advised. Besides, bringing code from Pharo most likely means a fork of 
> that code (because of those incompatibilities), and a separate future 
> evolution. So, it is good to understand that code and appropriate it.
> 
> Unless the code uses only compatible APIs from the system, something 
> that could be useful to investigate, especially if guarantees can be 
> given. Then, the package would be cross dialect, and forking won't be 
> needed.
> 
> Just thinking aloud.
> 
> Cheers,
>