Availability of Smallapack in Pharo6.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Availability of Smallapack in Pharo6.0

Nicolas Cellier
Hi,
I announce the availability of Smallapack in Pharo6.

The ConfigurationOfSmallapack is in http://www.squeaksource.com/MetacelloRepository and there is a copy in meta repo for Pharo 3/4/5/6.

Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments.
External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI.
Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing).

I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance).

But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo...

Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me. But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.

Reply | Threaded
Open this post in threaded view
|

Re: Availability of Smallapack in Pharo6.0

Tudor Girba-2
Hi Nicolas,

Very nice! It’s great to have a fast library for linear algebra.

Cheers,
Doru


> On Jan 12, 2019, at 12:33 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Hi,
> I announce the availability of Smallapack in Pharo6.
>
> The ConfigurationOfSmallapack is in http://www.squeaksource.com/MetacelloRepository and there is a copy in meta repo for Pharo 3/4/5/6.
>
> Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments.
> External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI.
> Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing).
>
> I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance).
>
> But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo...
>
> Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me. But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.
>

--
www.feenk.com

“Programming is executable philosophy."


Reply | Threaded
Open this post in threaded view
|

Re: Availability of Smallapack in Pharo6.0

Denis Kudriashov
In reply to this post by Nicolas Cellier
Hi Nicolas

пт, 11 янв. 2019 г. в 23:34, Nicolas Cellier <[hidden email]>:
Hi,
I announce the availability of Smallapack in Pharo6.

The ConfigurationOfSmallapack is in http://www.squeaksource.com/MetacelloRepository and there is a copy in meta repo for Pharo 3/4/5/6.

Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments.
External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI.
Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing).

I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance).

But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo...

Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me.

Protocol with star is still convention to store class extensions in files. No compatibility issues here. Calypso just hides it from user because package and protocol is not the same thing. And I hope in Pharo 8 we will support multiple protocols and separate packaging. But more important is to finely clean RPackage implementation. The current way how method is became bound to package is horrible.  
 
But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.

Reply | Threaded
Open this post in threaded view
|

Re: Availability of Smallapack in Pharo6.0

Nicolas Cellier


Le sam. 12 janv. 2019 à 14:14, Denis Kudriashov <[hidden email]> a écrit :
Hi Nicolas

пт, 11 янв. 2019 г. в 23:34, Nicolas Cellier <[hidden email]>:
Hi,
I announce the availability of Smallapack in Pharo6.

The ConfigurationOfSmallapack is in http://www.squeaksource.com/MetacelloRepository and there is a copy in meta repo for Pharo 3/4/5/6.

Currently, the ported version uses a derivative of OpalCompiler patched to handle method with 16+ arguments.
External function calls have not been converted yet to UnifiedFFI, but the patched compiler rather has hook to compile legacy FFI.
Though I did not install the hook to call FFI with more than 15 arguments, so there is at least 1 unit test failing (but not crashing).

I have auto-re-generated all the source code for using UnifiedFFI formats, so the dependency on legacy FFI is not a necessity (apart for simplifying cross dialect maintenance).

But I want to review the generated code method by method rather than filing it in blindly (the wrapper functions are also generated, and I might loose comments or improvments if I'm careless). Unfortunately, the state of diff tools in Pharo6, be it thru MC or worse than all, thru legacy change lists, does not enable such a large scale review, so I think that I will edit in Squeak and run in Pharo...

Now that Smallapack supports Opal, there should be no major problem for porting to Pharo7, but I did not have time to try yet. A few more MC regressions, and the fact to forbid protocol beginning with a * was too serious a cross compatibility hurdle for me.

Protocol with star is still convention to store class extensions in files. No compatibility issues here. Calypso just hides it from user because package and protocol is not the same thing. And I hope in Pharo 8 we will support multiple protocols and separate packaging. But more important is to finely clean RPackage implementation. The current way how method is became bound to package is horrible.  
 

Hi Denis,
OK, but hiding is troubling...
When I came from VW, I found that Squeak categories matching package names was a quick and dirty hack.
Since then, I find it works remarkably well, it is somehow a declarative meta information (method property), and I much prefer that to hidden package classification accessible from an IDE only.
It still happens to me to loose methods in VW because they are not packaged or wrongly packaged, so I'm not sure that cleaning is winning in that case.
And if you go with multiple classifications, then there's no reason to not keep the hack.

But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.

Reply | Threaded
Open this post in threaded view
|

Re: Availability of Smallapack in Pharo6.0

Pharo Smalltalk Developers mailing list


Hi Denis,
OK, but hiding is troubling...
When I came from VW, I found that Squeak categories matching package names was a quick and dirty hack.
Since then, I find it works remarkably well, it is somehow a declarative meta information (method property), and I much prefer that to hidden package classification accessible from an IDE only.

I agree :) and I told that several times in the past :)
We also lost the inplace edit and the logic sometimes is super confusing. 

It still happens to me to loose methods in VW because they are not packaged or wrongly packaged, so I'm not sure that cleaning is winning in that case.
And if you go with multiple classifications, then there's no reason to not keep the hack.

For now multiple classifications is not in our priority since our list is already too long. 


But I'll come back to it, tools are generally better in ph7 than ph6. Stay tuned.

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Julie Jonas 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France