January 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] LibGit error at start up

by Hilaire

I should add the host is Linux 64bits, configured with 32 bits libraries, and DrGeo/32bits was running fine so far (version of June 2018 with P7 32bits image and VM of then). It should not be related to the issue. Le 31/01/2019 Ã 10:29, Hilaire a Ã©critÂ : > I downloaded separately stable P7.0 32 bits image and linux VM. -- Dr. Geo http://drgeo.eu

Jan. 31, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by Sven Van Caekenberghe

All my packages work on Pharo 6, 6.1 and 7 (and 8) without any changes. YMMV. > On 31 Jan 2019, at 11:05, tomo <tomohiro.tomo.oda(a)gmail.com> wrote: > > Hernan, > >> Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. >> The first option was about splitting MyPackage into MyPackage-Common, >> MyPackage-Pharo6 and >> MyPackage-Pharo7 with corresponding methods/classes moved. > > In my project, I migrated MyPackage into Pharo 7, and create > MyPackage-Pharo6 for compatibility. > Then updated BaselineOf to conditionally load MyPackage-Pharo6. > At some point, I will drop MyPackage-Pharo6 to make migration to Pharo 8 > easier :-) > > I haven't used branch or tag to support different platform versions. > I'd prefer branch over tag if I want to keep maintaining codes for older > platforms. > I'd like to hear how people are dealing with this issue, too. > > Best Regards, > --- > tomo > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 31, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by tomo

Hernan, > Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. > The first option was about splitting MyPackage into MyPackage-Common, > MyPackage-Pharo6 and > MyPackage-Pharo7 with corresponding methods/classes moved. In my project, I migrated MyPackage into Pharo 7, and create MyPackage-Pharo6 for compatibility. Then updated BaselineOf to conditionally load MyPackage-Pharo6. At some point, I will drop MyPackage-Pharo6 to make migration to Pharo 8 easier :-) I haven't used branch or tag to support different platform versions. I'd prefer branch over tag if I want to keep maintaining codes for older platforms. I'd like to hear how people are dealing with this issue, too. Best Regards, --- tomo -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 31, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by Guillermo Polito

Well, I've said it somewhere in the mail, probably got lost in all my blablbla, so I'll summarize. - I use tags to identify releases. - A same release works in Pharo6 and Pharo7 - In the baseline I have defined some conditional package that is loaded in Pharo6 that provides compatibility from Pharo6 to Pharo7. Of course, depending on the change you're doing you may want to have one package per platform besides the core. When I was talking about a single branch I was talking about the so-called master branch, not about creating a new branch (which was case 2) On Thu, Jan 31, 2019 at 10:29 AM HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Guillermo > > El jue., 31 ene. 2019 a las 6:08, Guillermo Polito (< > guillermopolito(a)gmail.com>) escribiÃ³: > >> Hi HernÃ¡n, >> >> On Thu, Jan 31, 2019 at 8:20 AM HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> I would like your advice on this: What's the effortless way to migrate >>> Github repository from Pharo 6 to Pharo 7? >>> >> >> Can you give us some more detail? Do you already have your project in >> github working for Pharo6? Or is it in Smalltalkhub and you are willing to >> move it to github? >> >> > Most of my packages are working on Pharo 6 already, and they are on GitHub. > > > >> I'll assume the first below :) >> >> >>> >>> I thought in the following solutions: >>> >>> 1) In a Pharo 6 image modify my BaselineOf, add & push a new package >>> MyPackage-Pharo6, then load it into a Pharo 7 image, create >>> MyPackage-Pharo7 and port as needed. The same Metacello installation script >>> is preserved for all versions. >>> >>> 2) Tag repository as x.x in a Pharo 6 image, load my package & do port >>> in a Pharo 7 image and push to master. Previous Pharo 6 version could be >>> loaded referring to a tag (or branch maybe?) in the Metacello installation >>> script. >>> >> >> Well, it depends on what you want to provide as "support". >> - Do you want your package to keep working on both versions? >> > > Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. > The first option was about splitting MyPackage into MyPackage-Common, > MyPackage-Pharo6 and MyPackage-Pharo7 with corresponding methods/classes > moved. > > >> - Do you want your new features to be available also in the old version? >> >> > I'm not really interested in backward compatibiilty. > > >> Case 1) Usually I try (if context agrees :) to keep a single branch. And >> I try that my project in that branch is compatible with both Pharo >> versions. Having a single branch if possible removes part of the >> bureaucracy of thinking about backports, patches, and so on... >> Releases are marked as tags, but they are shared between the different >> platforms. >> >> > You're talking about branches but I've used branches for a different > purpose (providing features for example). Wouldn't be more appropriate to > use tags in this case? > > >> We were able to do it with Iceberg for a long time (and it is an example >> that relies on Spec, File stuff, FFI..). >> We have lost that compatibility in the last weeks because we made a fix >> for win64 that was not compatible with Pharo6, but I'm thinking in getting >> that compatibility back at lest for Iceberg 1.5.*. >> >> > I will check those Baselines because I need to see examples of how does it > work. > > >> To keep a single branch compatible with many Pharo versions there is no >> magic: >> 1) we have a forward compatibility package to Pharo 7. The idea is that >> we write code for Pharo7 but in Pharo6 we can load a package with some >> extensions/additions that make it compatible with Pharo7. >> 2) we try to use compatible APIs. For example, we use FileSystem as much >> as possible. Another example is that Iceberg relies a lot in the Path class >> to manipulate the directory tree, and the nicest API of that class changed >> a lot so for simplicity we used the low level API that is a bit uglier and >> verbose, but compatible. >> >> Case 2) At the same time, just to set an example, we were thinking >> version 1.5.* was going to be the last iceberg version supported for >> Pharo6, so pharo7 and 8 were going to use 1.6.*. This means we will have >> two different versions running side by side. >> >> If we want to continue applying patches and critical bugfixes in the >> 1.5.* version, we should have two branches. >> Notice that here I'm assuming that my 1.5.* branch will move much more >> slowly than 1.6.*, since no real active development will be done with it. >> >> > Thank you Guillermo > > > >> Probably other people can share their workflows. >> >> HTH, >> Guille >> >> >>> Any recommendations? Alternative paths? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >>> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 31, 2019

LibGit error at start up

by Hilaire

Hi, I downloaded separately stable P7.0 32 bits image and linux VM. When I fire up, I got this start up error related to Git (which I do not use), see log. It looks like reproducible problem. On the CLI, there is a funny error message "file too short": hilaire@PCHome:~/Travaux/Developpement/DrGeoII/trunk/build/tmp/vm$ ./pharo ./Pharo.image ioLoadModule(./lib/pharo/5.0-201901051900/libgit2.so): Â ./lib/pharo/5.0-201901051900/libgit2.so: fichier trop court ioLoadModule(/home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/vm/./lib/pharo/5.0-201901051900/libgit2.so): Â /home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/vm/./lib/pharo/5.0-201901051900/libgit2.so: fichier trop court tryLoading(/home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/vm/lib/pharo/5.0-201901051900/libgit2.so/.libs/,libgit2.so): stat(/home/hilaire/Travaux/Developpement/DrGeoII/trunk/build/tmp/vm/lib/pharo/5.0-201901051900/libgit2.so/.libs/) N'est pas un dossier External module not found ExternalLibraryFunction(Object)>>error: ExternalLibraryFunction(Object)>>externalCallFailed ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: LGitLibrary>>libgit2_init FFICalloutAPI>>function:module: -- Dr. Geo http://drgeo.eu

Jan. 31, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by HernÃ¡n Morales Durand

Hi Guillermo El jue., 31 ene. 2019 a las 6:08, Guillermo Polito (< guillermopolito(a)gmail.com>) escribiÃ³: > Hi HernÃ¡n, > > On Thu, Jan 31, 2019 at 8:20 AM HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> I would like your advice on this: What's the effortless way to migrate >> Github repository from Pharo 6 to Pharo 7? >> > > Can you give us some more detail? Do you already have your project in > github working for Pharo6? Or is it in Smalltalkhub and you are willing to > move it to github? > > Most of my packages are working on Pharo 6 already, and they are on GitHub. > I'll assume the first below :) > > >> >> I thought in the following solutions: >> >> 1) In a Pharo 6 image modify my BaselineOf, add & push a new package >> MyPackage-Pharo6, then load it into a Pharo 7 image, create >> MyPackage-Pharo7 and port as needed. The same Metacello installation script >> is preserved for all versions. >> >> 2) Tag repository as x.x in a Pharo 6 image, load my package & do port in >> a Pharo 7 image and push to master. Previous Pharo 6 version could be >> loaded referring to a tag (or branch maybe?) in the Metacello installation >> script. >> > > Well, it depends on what you want to provide as "support". > - Do you want your package to keep working on both versions? > Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. The first option was about splitting MyPackage into MyPackage-Common, MyPackage-Pharo6 and MyPackage-Pharo7 with corresponding methods/classes moved. > - Do you want your new features to be available also in the old version? > > I'm not really interested in backward compatibiilty. > Case 1) Usually I try (if context agrees :) to keep a single branch. And I > try that my project in that branch is compatible with both Pharo versions. > Having a single branch if possible removes part of the bureaucracy of > thinking about backports, patches, and so on... > Releases are marked as tags, but they are shared between the different > platforms. > > You're talking about branches but I've used branches for a different purpose (providing features for example). Wouldn't be more appropriate to use tags in this case? > We were able to do it with Iceberg for a long time (and it is an example > that relies on Spec, File stuff, FFI..). > We have lost that compatibility in the last weeks because we made a fix > for win64 that was not compatible with Pharo6, but I'm thinking in getting > that compatibility back at lest for Iceberg 1.5.*. > > I will check those Baselines because I need to see examples of how does it work. > To keep a single branch compatible with many Pharo versions there is no > magic: > 1) we have a forward compatibility package to Pharo 7. The idea is that > we write code for Pharo7 but in Pharo6 we can load a package with some > extensions/additions that make it compatible with Pharo7. > 2) we try to use compatible APIs. For example, we use FileSystem as much > as possible. Another example is that Iceberg relies a lot in the Path class > to manipulate the directory tree, and the nicest API of that class changed > a lot so for simplicity we used the low level API that is a bit uglier and > verbose, but compatible. > > Case 2) At the same time, just to set an example, we were thinking version > 1.5.* was going to be the last iceberg version supported for Pharo6, so > pharo7 and 8 were going to use 1.6.*. This means we will have two different > versions running side by side. > > If we want to continue applying patches and critical bugfixes in the 1.5.* > version, we should have two branches. > Notice that here I'm assuming that my 1.5.* branch will move much more > slowly than 1.6.*, since no real active development will be done with it. > > Thank you Guillermo > Probably other people can share their workflows. > > HTH, > Guille > > >> Any recommendations? Alternative paths? >> >> Cheers, >> >> HernÃ¡n >> >> >> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Jan. 31, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by Guillermo Polito

Hi HernÃ¡n, On Thu, Jan 31, 2019 at 8:20 AM HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > I would like your advice on this: What's the effortless way to migrate > Github repository from Pharo 6 to Pharo 7? > Can you give us some more detail? Do you already have your project in github working for Pharo6? Or is it in Smalltalkhub and you are willing to move it to github? I'll assume the first below :) > > I thought in the following solutions: > > 1) In a Pharo 6 image modify my BaselineOf, add & push a new package > MyPackage-Pharo6, then load it into a Pharo 7 image, create > MyPackage-Pharo7 and port as needed. The same Metacello installation script > is preserved for all versions. > > 2) Tag repository as x.x in a Pharo 6 image, load my package & do port in > a Pharo 7 image and push to master. Previous Pharo 6 version could be > loaded referring to a tag (or branch maybe?) in the Metacello installation > script. > Well, it depends on what you want to provide as "support". - Do you want your package to keep working on both versions? - Do you want your new features to be available also in the old version? Case 1) Usually I try (if context agrees :) to keep a single branch. And I try that my project in that branch is compatible with both Pharo versions. Having a single branch if possible removes part of the bureaucracy of thinking about backports, patches, and so on... Releases are marked as tags, but they are shared between the different platforms. We were able to do it with Iceberg for a long time (and it is an example that relies on Spec, File stuff, FFI..). We have lost that compatibility in the last weeks because we made a fix for win64 that was not compatible with Pharo6, but I'm thinking in getting that compatibility back at lest for Iceberg 1.5.*. To keep a single branch compatible with many Pharo versions there is no magic: 1) we have a forward compatibility package to Pharo 7. The idea is that we write code for Pharo7 but in Pharo6 we can load a package with some extensions/additions that make it compatible with Pharo7. 2) we try to use compatible APIs. For example, we use FileSystem as much as possible. Another example is that Iceberg relies a lot in the Path class to manipulate the directory tree, and the nicest API of that class changed a lot so for simplicity we used the low level API that is a bit uglier and verbose, but compatible. Case 2) At the same time, just to set an example, we were thinking version 1.5.* was going to be the last iceberg version supported for Pharo6, so pharo7 and 8 were going to use 1.6.*. This means we will have two different versions running side by side. If we want to continue applying patches and critical bugfixes in the 1.5.* version, we should have two branches. Notice that here I'm assuming that my 1.5.* branch will move much more slowly than 1.6.*, since no real active development will be done with it. Probably other people can share their workflows. HTH, Guille > Any recommendations? Alternative paths? > > Cheers, > > HernÃ¡n > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Jan. 31, 2019

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo open documentation

by Norbert Hartl

Very good initiative! Did you talk about the catalog, too? This list somehow mirrors the catalog. And as it is done in markdown it does not easily work as a parsable document, does it? Norbert > Am 30.01.2019 um 15:00 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > > Hi everyone! > > With some other members of the community we are proud to announce a > new effort on Pharo documentation. > > We launched an organization pharo-open-documentation which is a > user-maintained documentation related to Pharo environment, language, > and libraries. > > Currently it has three main projects: > - pharo-wiki : Wiki related to the Pharo programming language and environment. > - awesome-pharo : A collection of awesome Pharo libraries, tools, > frameworks and software. We want to make this project a reference in > https://github.com/sindresorhus/awesome > - awesome-pharo-ml : List of projects, books, booklets, papers, and > applications related to machine learning, AI, data science in Pharo. > > Contributions are welcomed! > > If you own a cool project in Pharo others could use in their own > projects, send us a PR to awesome-pharo! > If you have knowledge on Pharo or projects of Pharo, we would be glad > if you could contribute to the pharo-wiki! Don't forget to read the > contribution guidelines. ;) > > We opened a Twitter to announce new entries on the pharo-wiki. > > https://twitter.com/PharoOpen > > Have a nice day! > > -- > Cyril Ferlicot > https://ferlicot.fr >

Jan. 31, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Hilaire

Le 31/01/2019 Ã 01:58, Ben Coman a Ã©critÂ : > Maybe not critical. Just trying to get coverage.Â Agree > If two people download the same binary and get different results, then > its something different in the environment The situation is a bit different. According to the user description, Dr. Geo was working on his Windows 10 host until he proceeded on a system update this January. > and a matter of carving up that space looking for patterns. > I've seen graphics issues arising only on specific video cards before. I did not receive yett the supplementary info from the user. Best Hilarie -- Dr. Geo http://drgeo.eu

Jan. 31, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Hilaire

Hi Benoit, You seems to describe another problem I am not sure to understand. Is it related to the encoding of your name in the path of your system? Does it look to your related to these bugs: https://bugs.launchpad.net/drgeo/+bug/1468205 https://bugs.launchpad.net/drgeo/+bug/1412834 ? Thanks to give a try Hilaire Le 31/01/2019 Ã 04:46, Benoit St-Jean via Pharo-users a Ã©critÂ : > Unfortunately, Dr. Geo suffers from the same problem I have with any > Pharo 6.x and 7.x image regarding the encoding of my name in Windows.Â > It crashes when the app starts at the exact same place and I can't do > much.Â Sorry. -- Dr. Geo http://drgeo.eu

Jan. 31, 2019