When I follow the procedure at https://github.com/pharo-nosql/voyage to install Voyage in a 4.0 image, it leads to an unfonctonnal Voyage (timeout on socket when doing a query) My configure baseline is just as simple as the one bellow. All is loaded fine but Voyage. Any suggestion? Hilaire baseline10: spec <version: '1.0-baseline'> "This is Work-In-Progress and should be renamed upon stabilization" spec for: #common do: [ spec blessing: #baseline. [..] "External PROJECTS dependencies" spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'github://pharo-nosql/voyage:master/mc'; versionString: #stable. ]. spec project: 'osprocess' with: [ spec className: 'ConfigurationOfOSProcess'; repository: 'http://www.squeaksource.com/OSProcess'; versionString: #stable]. spec project: 'mustache' with: [ spec className: 'ConfigurationOfMustache'; repository: 'http://www.smalltalkhub.com/mc/NorbertHartl/Mustache/main'; versionString: #stable]. spec project: 'neocsv' with: [ spec className: 'ConfigurationOfNeoCSV'; repository: 'http://mc.stfx.eu/Neo'; versionString: #stable]. spec project: 'seaside' with: [ spec className: 'ConfigurationOfSeaside3'; repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; versionString: #stable]. spec project: 'bootstrap' with: [ spec className: 'ConfigurationOfBootstrap'; repository: 'http://www.smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main'; versionString: #stable]. spec package: 'mold' with: [ spec repository: 'http://www.smalltalkhub.com/mc/philippeback/Mold/main']. "Our PACKAGES dependencies" spec package: 'Cofigest' with: [ spec requires: #('neocsv' 'mustache' 'osprocess' 'voyage')]; package: 'Cofigest-Bank products' with: [ spec requires: 'Cofigest']; package: 'Cofigest-Seaside' with: [ spec requires: #('Cofigest' 'Cofigest-Bank products' 'seaside' 'bootstrap' 'mold')]; package: 'Cofigest-Tests' with: [ spec requires: #('Cofigest' 'Cofigest-Bank products')] ] -- Dr. Geo http://drgeo.eu
I try with the modified configure: spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/estebanlm/Voyage/main'; versionString: #stable. ]. But it does not work either. Error at installation this time. Can'find ALL... Then I tried this one: spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main'; versionString: #stable. ]. In all case the installed Voyage is not fully fonctionnal It is weird because my dev image is 4.0 Pharo based, and Voyage was installed from the MetaRepoForPharo60 Any ideas Hilaire Le 25/03/2017 à 10:47, Hilaire a écrit :
My configure baseline is just as simple as the one bellow. All is loaded fine but Voyage.
-- Dr. Geo http://drgeo.eu
Hi Hilaire, thing is: 1) you use github project, then the baseline spec baseline: âVoyageâ with: [ spec repository: 'github://pharo-nosql/voyage/mc <github://pharo-nosql/voyage/mc>â ]. 2) or you use the metarepo configuration spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/mainâ ]. why this one is not fully functional? then aside that⦠one thing I do not understand is why you are develop a new project with an old (and not maintained anymore) Pharo version? Currently supported version is Pharo5, and even if Voyage is an external project, usually development follows Pharo stable version⦠cheers! Esteban
On 25 Mar 2017, at 11:16, Hilaire <hilaire@drgeo.eu> wrote:
I try with the modified configure:
spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/estebanlm/Voyage/main'; versionString: #stable. ].
But it does not work either. Error at installation this time. Can'find ALL...
Then I tried this one:
spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main'; versionString: #stable. ].
In all case the installed Voyage is not fully fonctionnal
It is weird because my dev image is 4.0 Pharo based, and Voyage was installed from the MetaRepoForPharo60
Any ideas
Hilaire
Le 25/03/2017 à 10:47, Hilaire a écrit :
My configure baseline is just as simple as the one bellow. All is loaded fine but Voyage.
-- Dr. Geo http://drgeo.eu
It is not a new project. It started with Pharo3. Then I see no reason why I can't load the Voyage code of the time of Pharo4, with the matching code version. It should be still there, is not the purpose of Configuration? Or may be I misunderstand how version is working and its purpose. Hilaire Le 25/03/2017 à 18:08, Esteban Lorenzano a écrit :
then aside that⦠one thing I do not understand is why you are develop a new project with an old (and not maintained anymore) Pharo version? Currently supported version is Pharo5, and even if Voyage is an external project, usually development follows Pharo stable versionâ¦
-- Dr. Geo http://drgeo.eu
On 25 Mar 2017, at 19:46, Hilaire <hilaire@drgeo.eu> wrote:
It is not a new project. It started with Pharo3. Then I see no reason why I can't load the Voyage code of the time of Pharo4, with the matching code version. It should be still there, is not the purpose of Configuration? Or may be I misunderstand how version is working and its purpose.
Voyage works on Pharo 4, I was just wondering why you are still using 4 :)
Hilaire
Le 25/03/2017 à 18:08, Esteban Lorenzano a écrit :
then aside that⦠one thing I do not understand is why you are develop a new project with an old (and not maintained anymore) Pharo version? Currently supported version is Pharo5, and even if Voyage is an external project, usually development follows Pharo stable versionâ¦
-- Dr. Geo http://drgeo.eu
Hilaire Yes you can load and old version and it should behave with the old behavior and potentially old bugs. You have the right. This is what a configuration gives you. Now esteban has the right to only add features and fix bugs in the maintained versions. And he could also consider that he does not want to help people using old versions because he is spending a lot of time improving the new ones. Apple, M$ and plenty of others do it this way and they have a lot more money than us. Stef On Sat, Mar 25, 2017 at 7:46 PM, Hilaire <hilaire@drgeo.eu> wrote:
It is not a new project. It started with Pharo3. Then I see no reason why I can't load the Voyage code of the time of Pharo4, with the matching code version. It should be still there, is not the purpose of Configuration? Or may be I misunderstand how version is working and its purpose.
Hilaire
Le 25/03/2017 à 18:08, Esteban Lorenzano a écrit :
then aside that⦠one thing I do not understand is why you are develop a new project with an old (and not maintained anymore) Pharo version? Currently supported version is Pharo5, and even if Voyage is an external project, usually development follows Pharo stable versionâ¦
-- Dr. Geo http://drgeo.eu
Ok I try this configuration, looks like he wants to install UnQLite. See debug log. Hilaire Le 25/03/2017 à 18:08, Esteban Lorenzano a écrit :
spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/mainâ <http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main%E2%80%99> ].
why this one is not fully functional?
-- Dr. Geo http://drgeo.eu
I just did this: Gofer new smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo60'; configurationOf: 'VoyageMongo'; loadStable. (which is the same to the one you did) in a fresh Pharo4 and it loaded fine. No UnQLite (which is correct). Now, I guess Metacello looks for all packages in baseline even if after it will not download them⦠maybe you are seeing this lookup, but it shouldnât affect you. So, I guess there is a problem somewhere, but not in the config or the installation. Maybe a package cache problem? Esteban
On 25 Mar 2017, at 19:51, Hilaire <hilaire@drgeo.eu> wrote:
Ok I try this configuration, looks like he wants to install UnQLite. See debug log.
Hilaire
Le 25/03/2017 à 18:08, Esteban Lorenzano a écrit :
spec project: 'voyage' with: [ spec className: 'ConfigurationOfVoyageMongo'; repository: 'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/mainâ <http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main%E2%80%99> ].
why this one is not fully functional?
-- Dr. Geo http://drgeo.eu <PharoDebug.log>
Indeed, as I wrote in a previous email, this is how I got Voyage installed too in my Pharo4 devel environment, and it went fine too. Therefore the configuration should be ok. So this is weird. It should not be package cache related because I build image with a completely emptied build directory environment. So I am lost. As A matter of fact, I ran the installation script with a Pharo5 image, and now I get another error during the installation process. See bug log. The repo config is the git one, as described in the first email of this thread. Hilaire Le 25/03/2017 à 20:32, Esteban Lorenzano a écrit :
I just did this:
Gofer new smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo60'; configurationOf: 'VoyageMongo'; loadStable.
(which is the same to the one you did)
in a fresh Pharo4 and it loaded fine. No UnQLite (which is correct). Now, I guess Metacello looks for all packages in baseline even if after it will not download them⦠maybe you are seeing this lookup, but it shouldnât affect you.
So, I guess there is a problem somewhere, but not in the config or the installation. Maybe a package cache problem?
Esteban
-- Dr. Geo http://drgeo.eu
I think there is a bug in Voyage when an image clean up is requested. There is a confusion with the #cleanUp: message. Hilaire Le 25/03/2017 à 21:26, Hilaire a écrit :
As A matter of fact, I ran the installation script with a Pharo5 image, and now I get another error during the installation process. See bug log. The repo config is the git one, as described in the first email of this thread.
-- Dr. Geo http://drgeo.eu
More precisely with: SmalltalkImage current cleanUp: true except: #() confirming: false. It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my image, I don't remember. Hilaire Le 25/03/2017 à 21:33, Hilaire a écrit :
I think there is a bug in Voyage when an image clean up is requested. There is a confusion with the #cleanUp: message.
Hilaire
-- Dr. Geo http://drgeo.eu
ah yeah, I wrote an internal durty hack to get it rolling cleanUp: aRepository (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase] Le 25/03/2017 à 21:46, Hilaire a écrit :
It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my image, I don't remember.
-- Dr. Geo http://drgeo.eu
I get that same problem, too, every time I do "Software update". But never understood the rationale of dropping a database at this point. I think we should remove this line Norbert
Am 25.03.2017 um 22:04 schrieb Hilaire <hilaire@drgeo.eu>:
ah yeah, I wrote an internal durty hack to get it rolling
cleanUp: aRepository (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase]
Le 25/03/2017 à 21:46, Hilaire a écrit : It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my image, I don't remember.
-- Dr. Geo http://drgeo.eu
Add an issue in the Voyage github repo and do a pull request to push esteban releasing a new version. On Sun, Mar 26, 2017 at 1:15 PM, Norbert Hartl <norbert@hartl.name> wrote:
I get that same problem, too, every time I do "Software update". But never understood the rationale of dropping a database at this point. I think we should remove this line
Norbert
Am 25.03.2017 um 22:04 schrieb Hilaire <hilaire@drgeo.eu>:
ah yeah, I wrote an internal durty hack to get it rolling
cleanUp: aRepository (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase]
Le 25/03/2017 à 21:46, Hilaire a écrit : It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my image, I don't remember.
-- Dr. Geo http://drgeo.eu
Thanks for the tip but I know that. I have full access to the voyage code. Without knowing the reason and context an issue is useless. Norbert
Am 26.03.2017 um 19:35 schrieb Stephane Ducasse <stepharo.self@gmail.com>:
Add an issue in the Voyage github repo and do a pull request to push esteban releasing a new version.
On Sun, Mar 26, 2017 at 1:15 PM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: I get that same problem, too, every time I do "Software update". But never understood the rationale of dropping a database at this point. I think we should remove this line
Norbert
Am 25.03.2017 um 22:04 schrieb Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>>:
ah yeah, I wrote an internal durty hack to get it rolling
cleanUp: aRepository (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase]
Le 25/03/2017 à 21:46, Hilaire a écrit : It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my image, I don't remember.
-- Dr. Geo http://drgeo.eu <http://drgeo.eu/>
participants (4)
-
Esteban Lorenzano -
Hilaire -
Norbert Hartl -
Stephane Ducasse