August 2018 - Pharo-dev - lists.pharo.org

Esteban's ChangeLog week of 6 August 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 6 August 2018 to 12 August 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/8/2018&to=12/8/2018 ChangeLog ========= 7 August 2018: -------------- * I've been working on a new ODBC driver for Pharo, made on UFFI and Garage. Sadly, I cannot take the existing older ODBC driver as base because it was depending too much on old FFI structure. Also, it didn't have any test or example so it was hard to take as inspiration (too many differences to tacle). Anyway, the new ODBC driver will come soon(tm), in the mean time I needed to fix some issues on UnifiedFFI: * [case: 22287](https://pharo.fogbugz.com/f/cases/22287) * [case: 22300](https://pharo.fogbugz.com/f/cases/22300) This fixes some missing/incorrect parts on UFFI: first one adds a special handling for +size_t+ types (needed because they behave differently in different platforms/architectures). And the second fixes a problem when returning +enum+ values. cheers! Esteban

Aug. 13, 2018

Re: [Pharo-dev] Fwd: [Ann.] Pharo-HDFS API

by Sean P. DeNigris

Matteo Marra-2 wrote > I would like to shareâ¦ a library to access the Hadoop Distributed File > System (HDFS). Cool! Thanks :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 11, 2018

Fwd: [Ann.] Pharo-HDFS API

by Matteo Marra

Hello, I would like to share one of my projects that I am working on in my PhD. Since I am working on Big Data I wrote a library to access the Hadoop Distributed File System (HDFS). We implemented it as a FileSystem in Pharo, using the webHDFS API of HDFS to access the files. With this API you can browse the distributed file system and create/modify/delete directories and files. Here is the git repository: https://gitlab.soft.vub.ac.be/Marra/pharo-hdfs Documentation is in the readme. Ciao, Matteo

Aug. 10, 2018

[Pharo 7.0-dev] Build #1167: 22304-vmtarget-pharo-not-found-during-bootstrap

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1167 was: SUCCESS. The Pull Request #1678 was integrated: "22304-vmtarget-pharo-not-found-during-bootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/1678 Issue Url: https://pharo.fogbugz.com/f/cases/22304 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 10, 2018

Re: [Pharo-dev] debugger "Step Out"

by Tim Mackinnon

When âstep-throughâ was added, that was a lifesaver as we have many block iterations. Step out would also be a few less clicks than run to curser ... so it sounds complimentary. Tim Sent from my iPhone > On 10 Aug 2018, at 04:12, Ben Coman <btc(a)openinworld.com> wrote: > > A very quick note because its hardly important so I know I'll forget it. > > Using MSVC recently and jumping back in the Pharo debugger > I had a moment when I missing their "Step Out" debugger feature. > > Probably less important in Pharo where we tend to have shorter methods, > and you can always select up the stack and "Step Over", > but while I was in-the-flow "Step Out" was what the thing I wanted. > > Anyway, just sharing the thought. > > cheers -ben

Aug. 10, 2018

Re: [Pharo-dev] debugger "Step Out"

by Nicolas Anquetil

+1 although you can mimick it by going down one level in the call stack and do a step-over nicolas On 10/08/2018 04:12, Ben Coman wrote: > A very quick note because its hardly important so I know I'll forget it. > > Using MSVC recently and jumping back in the Pharo debugger > I had a moment when I missing their "Step Out" debugger feature. > > Probably less important in Pharo where we tend to have shorter methods, > and you can always select up the stack and "Step Over", > but while I was in-the-flow "Step Out" was what the thing I wanted. > > Anyway, just sharing the thought. > > cheers -ben -- Nicolas Anquetil RMod team -- Inria Lille

Aug. 10, 2018

debugger "Step Out"

by Ben Coman

A very quick note because its hardly important so I know I'll forget it. Using MSVC recently and jumping back in the Pharo debugger I had a moment when I missing their "Step Out" debugger feature. Probably less important in Pharo where we tend to have shorter methods, and you can always select up the stack and "Step Over", but while I was in-the-flow "Step Out" was what the thing I wanted. Anyway, just sharing the thought. cheers -ben

Aug. 10, 2018

Re: [Pharo-dev] [Pharo-users] New Iceberg Version 1.2.1

by Guillermo Polito

On Thu, Aug 9, 2018 at 11:18 AM Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 08.08.2018 um 14:12 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: > > > > Damien Pollet wrote on 8. 8. 2018 13:53: > > First of all, quick stupid question: I'm currently loading my code with > gitlocal://./src as the repository URL (my workflow starts in a terminal > rather than in a Pharo image) > Should I just remove the /src part, now that my repo has the project > metadata? > Also, are more features planned for the .project file? E.g. what about > storing a default selection for Calypso and the Test Runner in there? > On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name < > mailto:norbert@hartl.name <norbert(a)hartl.name>>> wrote: > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this > however. I keep frontend and backend code in some repositories > together so the source is in my case in backend/source. What does it > mean for users not using the âstandardâ name? > Sure there can. Look at any ruby or maven project, they all have strong > conventions for organizing projects and standard config files for deviating > from those conventions. > I would have preferred if Iceberg picked one convention (arbitrarily) in > the absence of a .project file instead of forcing its explicit presence. > IMHO the choice of default directory per se (be it ./, ./src, ./source or > whatever) matters less than the fact that there is a convention in place. > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment > already but the .project file manifests this. So it should not be > supported to have more source dirs in one git repo? It might be not > a good idea that the client has to write the source dir but it opens > the possibility that there can be more than one. > I see your point here, but by using separate source directories you're > sort of creating a hydra projectâ¦ What I mean here is that the source > directories are separate, but their histories are tangled. If you want > separate source dirs it kinda means that you want separate change > histories, doesn't it? What if the same class has diverging definitions in > separate directories (I wonder what maven does in that caseâ¦)? > > > There are monorepos. Some people / companies love them. > > One of these companies we know for good. It is google. Google has one (!) > repositoryf for all their software. > > And that is the point I want to stretch here. One repo with one project > and a standard source directory is too theoretical and too narrow in > thoughts. > I think that you underestimate people when you say this. > Today there is no possibility to reliably make one product out of multiple > repos. Git submodule and git subtree are not even close to something > reliable and usable. > We are well aware of this. And that's why Pharo is not using any of them. But this goes against what you said before, or I'm not getting something. > Descriptions like metacello are language centric. > Yes. But I don't understand why this comes up. You would like language... "agnostic"? For example? > So what is the most secure way of defining a single product? It is the > mono repo. That is the main reason I have my sources in backend/source > because there is a javascript frontend in the same repo because I want to > have one reliable source that defines my product and I can be sure that the > backend and frontend are always the ones that match. > Just to repeat myself (and just to avoid missing it in the previous emails ^^). Can you describe better your needs for "multiple iceberg subdirectories"? > I donât think it is a good idea if we once leave the island to embrace > something like git just to make git islandish a little later. > I did not understand this... > > Just to be very clear. We are talking about two files: .project and > .properties. I have nothing against .properties because we have multiple > formats possible so making it explicit is a good idea. But .project makes > every repo a single source repo. If we enforce .properties files why do we > not scan the repo for directories containing this file? If none is found we > cannot know (or we add looking at some default locations). If multiple > directory are found I can add that to iceberg as a real project out of the > combination for repository-source directory. > This way I could have multiple projects out of one repo. And with the > possibility of having multiple source directories it is obvious that the > path still needs to be added to a url in metacello. > Unless there is one of this directories marked to be the default which > would be loaded if no directory is given. This way the default directory > would be the one selected if only one is there. So you can have multiple > projects in one repo and if this is only one per project the directory can > be automatically resolved. Use case kept. > Yes it could be done, but it's not so easy. I think you're underestimating the problem. For example, - tons of old projects have no .properties file. - so far iceberg only explicitly supported one code directory, and assumed that "no subdirectory" means root directory, not "default" one - If we discover two subdirectories in your repository, and you add a package into your repository, in which subdirectory should it be? - Should in this case be able to add the same package to both subdirectories? Do we commit them at the same time? Or they have different versions? Let's add that all these changes may involve changes in: - UI (and doing it properly takes time to design it, not just "coding" it) - merge Now, again, I can understand that the change make you uncomfortable, but I'd prefer that we talk about what are your needs instead of "how easy it could be done if we weren't stupid". > > Norbert > > On the other hand, separate source directories would be helpful to work > with git-subrepo and similar toolsâ¦ > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > -- 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

Aug. 9, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by Guillermo Polito

> > [SNIP] > I think I can see what is the rationale behind it but Iâm not sure this > can be the way to go: > > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this however. I > keep frontend and backend code in some repositories together so the source > is in my case in backend/source. What does it mean for users not using the > âstandardâ name? > Well, I think the opposite. The tool should enforce some standard way, and then, if you want to diverge from it you should specify it explicitly. > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment already > but the .project file manifests this. So it should not be supported to have > more source dirs in one git repo? It might be not a good idea that the > client has to write the source dir but it opens the possibility that there > can be more than one. > Our solution doesn't close the door either. Actually, we were thinking on having composite projects (a project with subprojects), which would support your use case. We are aware we wanted this for Pharo so for example we can split pharo itself in several smaller subprojects instead of having the mess of ~500 packages we have today. However, we were not aware of any project out there using such setup, and previous iceberg versions was maybe supporting this just "by chance" and not by design. (Just imagine that having in the same image two repositories with the same git repository behind but different source directories could be a way, but it's more of a workaround). This said, could you explain better how you were using this so far? - you have different source directories for frontend/backend? - you interact with them as different repositories in the same image? or from different images pointing to the same repo? - every time you commit in one of the iceberg repositories you get detached in the other(s)? This said, I'd like to support this scenarios, but I want to do it by design :) > - My mode of working is to have an eye on dirty repositories because that > shows what the impact of your work is. If I have a lot of dirty > repositories in my repository list it does not feel good and I donât want > that. Especially for projects I donât have write access to. How can I > change this? Iâm not sure that assuming everyone will add these files is a > likely one. > Maybe we need to be less invasive with colors? My point of view is that Monticello shows tons of packages and repositories, automatic rewrite and auto-deprecation rules rewrite code dynamically and mark monticello packages as dirty. But nobody ever complained about monticello or tried to change it. What are the packages you depend on and you have no write access to? If we make a pull request per day, I think we can solve this situation really fast... > > Norbert > > > -- 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

Aug. 9, 2018

Re: [Pharo-dev] [Pharo-users] New Iceberg Version 1.2.1

by Tim Mackinnon

On a slightly related note - and Iâm hearing what Norbert is saying as I need to work on multi language projects - it would be handy if I could specify the name of the project somehow. My /exercism/pharo repo (which was created for me) - appear in Iceberg as Pharo - which is confusing, as I really want to call it Execercism, but have no way to do this currently (and I support its something the .projects file would enable right?) Tim > On 9 Aug 2018, at 11:17, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 08.08.2018 um 14:12 schrieb Herbert VojÄÃk <herby(a)mailbox.sk <mailto:herby@mailbox.sk>>: >> >> >> >> Damien Pollet wrote on 8. 8. 2018 13:53: >>> First of all, quick stupid question: I'm currently loading my code with gitlocal://./src <gitlocal://./src> as the repository URL (my workflow starts in a terminal rather than in a Pharo image) >>> Should I just remove the /src part, now that my repo has the project metadata? >>> Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? >>> On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> <mailto:norbert@hartl.name <mailto:norbert@hartl.name>>> wrote: >>> - I donât think there can be a âstandard wayâ of defining source >>> directory. And I donât think that a tool should enforce this >>> however. I keep frontend and backend code in some repositories >>> together so the source is in my case in backend/source. What does it >>> mean for users not using the âstandardâ name? >>> Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. >>> I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. >>> - I donât see why there needs to be a 1:1 relationship between a >>> repository and working copy in pharo. It is like this at the moment >>> already but the .project file manifests this. So it should not be >>> supported to have more source dirs in one git repo? It might be not >>> a good idea that the client has to write the source dir but it opens >>> the possibility that there can be more than one. >>> I see your point here, but by using separate source directories you're sort of creating a hydra projectâ¦ What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that caseâ¦)? >> >> There are monorepos. Some people / companies love them. >> > One of these companies we know for good. It is google. Google has one (!) repositoryf for all their software. > > And that is the point I want to stretch here. One repo with one project and a standard source directory is too theoretical and too narrow in thoughts. Today there is no possibility to reliably make one product out of multiple repos. Git submodule and git subtree are not even close to something reliable and usable. Descriptions like metacello are language centric. So what is the most secure way of defining a single product? It is the mono repo. That is the main reason I have my sources in backend/source because there is a javascript frontend in the same repo because I want to have one reliable source that defines my product and I can be sure that the backend and frontend are always the ones that match. > > I donât think it is a good idea if we once leave the island to embrace something like git just to make git islandish a little later. > > Just to be very clear. We are talking about two files: .project and .properties. I have nothing against .properties because we have multiple formats possible so making it explicit is a good idea. But .project makes every repo a single source repo. If we enforce .properties files why do we not scan the repo for directories containing this file? If none is found we cannot know (or we add looking at some default locations). If multiple directory are found I can add that to iceberg as a real project out of the combination for repository-source directory. This way I could have multiple projects out of one repo. And with the possibility of having multiple source directories it is obvious that the path still needs to be added to a url in metacello. Unless there is one of this directories marked to be the default which would be loaded if no directory is given. This way the default directory would be the one selected if only one is there. So you can have multiple projects in one repo and if this is only one per project the directory can be automatically resolved. Use case kept. > > Norbert > >>> On the other hand, separate source directories would be helpful to work with git-subrepo and similar toolsâ¦ >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet <http://people.untyped.org/damien.pollet>

Aug. 9, 2018

[Pharo 7.0-dev] Build #1166: 22306-RubSurfaceSelectionShape-ivar-tag-unused

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1166 was: SUCCESS. The Pull Request #1679 was integrated: "22306-RubSurfaceSelectionShape-ivar-tag-unused" Pull request url: https://github.com/pharo-project/pharo/pull/1679 Issue Url: https://pharo.fogbugz.com/f/cases/22306 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 9, 2018

[Pharo 7.0-dev] Build #1165: 22302-isDefinition-on-RBVariableNode-should-check-sequence-defines

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1165 was: FAILURE. The Pull Request #1676 was integrated: "22302-isDefinition-on-RBVariableNode-should-check-sequence-defines" Pull request url: https://github.com/pharo-project/pharo/pull/1676 Issue Url: https://pharo.fogbugz.com/f/cases/22302 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 9, 2018

Re: [Pharo-dev] [Pharo-users] New Iceberg Version 1.2.1

by Norbert Hartl

> Am 08.08.2018 um 14:12 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: > > > > Damien Pollet wrote on 8. 8. 2018 13:53: >> First of all, quick stupid question: I'm currently loading my code with gitlocal://./src <gitlocal://./src> as the repository URL (my workflow starts in a terminal rather than in a Pharo image) >> Should I just remove the /src part, now that my repo has the project metadata? >> Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? >> On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> <mailto:norbert@hartl.name <mailto:norbert@hartl.name>>> wrote: >> - I donât think there can be a âstandard wayâ of defining source >> directory. And I donât think that a tool should enforce this >> however. I keep frontend and backend code in some repositories >> together so the source is in my case in backend/source. What does it >> mean for users not using the âstandardâ name? >> Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. >> I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. >> - I donât see why there needs to be a 1:1 relationship between a >> repository and working copy in pharo. It is like this at the moment >> already but the .project file manifests this. So it should not be >> supported to have more source dirs in one git repo? It might be not >> a good idea that the client has to write the source dir but it opens >> the possibility that there can be more than one. >> I see your point here, but by using separate source directories you're sort of creating a hydra projectâ¦ What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that caseâ¦)? > > There are monorepos. Some people / companies love them. > One of these companies we know for good. It is google. Google has one (!) repositoryf for all their software. And that is the point I want to stretch here. One repo with one project and a standard source directory is too theoretical and too narrow in thoughts. Today there is no possibility to reliably make one product out of multiple repos. Git submodule and git subtree are not even close to something reliable and usable. Descriptions like metacello are language centric. So what is the most secure way of defining a single product? It is the mono repo. That is the main reason I have my sources in backend/source because there is a javascript frontend in the same repo because I want to have one reliable source that defines my product and I can be sure that the backend and frontend are always the ones that match. I donât think it is a good idea if we once leave the island to embrace something like git just to make git islandish a little later. Just to be very clear. We are talking about two files: .project and .properties. I have nothing against .properties because we have multiple formats possible so making it explicit is a good idea. But .project makes every repo a single source repo. If we enforce .properties files why do we not scan the repo for directories containing this file? If none is found we cannot know (or we add looking at some default locations). If multiple directory are found I can add that to iceberg as a real project out of the combination for repository-source directory. This way I could have multiple projects out of one repo. And with the possibility of having multiple source directories it is obvious that the path still needs to be added to a url in metacello. Unless there is one of this directories marked to be the default which would be loaded if no directory is given. This way the default directory would be the one selected if only one is there. So you can have multiple projects in one repo and if this is only one per project the directory can be automatically resolved. Use case kept. Norbert >> On the other hand, separate source directories would be helpful to work with git-subrepo and similar toolsâ¦ >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet <http://people.untyped.org/damien.pollet>

Aug. 9, 2018

Re: [Pharo-dev] CI Down

by Guillermo Polito

This afternoon we were notified that everything is UP again. Not necessarily stable but UP. On Wed, Aug 8, 2018 at 6:38 PM Martin Dias <tinchodias(a)gmail.com> wrote: > > > El miÃ©., 8 de ago. de 2018 05:44, Norbert Hartl <norbert(a)hartl.name> > escribiÃ³: > >> Might be but doing make in the pharo repo gives you this >> > > hm... we should check that dependency. Epicea, Ombu and Hiedra packages > should be versioned in pharo repo. > > >> â¦ >> Project: Hermes baseline >> Project: Ficus 0.3.8 >> ...RETRY->Hiedra >> ...RETRY->Hiedra >> gofer repository error: 'GoferRepositoryError: Could not access >> http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut: >> Cannot connect to 128.93.162.53:80'...ignoring >> ...FAILED->Hiedra'Errors in script loaded from >> /Users/norbert/play/iot/pharo/bootstrap/scripts/prepare_image.st' >> Could not resolve: Hiedra [Hiedra] in >> /Users/norbert/play/iot/pharo/pharo-local/package-cache >> http://smalltalkhub.com/mc/MartinDias/Ficus/main/ ERROR: >> âGoferRepositoryError: Could not access >> http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut: >> Cannot connect to 128.93.162.53:80' >> â¦ >> >> >> Am 08.08.2018 um 11:21 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> I was convinced that Epicea was now managed inside Pharo. >> >> On 8 Aug 2018, at 11:15, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> The one thing is not be able to run the CI. The bigger problem is that >> pharo is not buildable at all. Can we please move mission critical repos >> like epicea to github? >> >> Norbert >> >> Am 08.08.2018 um 09:55 schrieb Guillermo Polito < >> guillermopolito(a)gmail.com>: >> >> Hi all, >> >> Since yesterday evening, CI is down because of Inria network problems at >> the level of Paris. >> Inria tells us that they do not have yet an estimation of how much time >> it will take to fix it. >> >> Until then, there will be no CI testing PRs nor new builds. >> Previous Pharo builds are still available in http://files.pharo.org/, >> which is hosted in OVH. >> >> I'll keep you updated, >> Guille >> >> >> >> >> -- 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

Aug. 8, 2018

Re: [Pharo-dev] CI Down

by Martin Dias

El miÃ©., 8 de ago. de 2018 05:44, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: > Might be but doing make in the pharo repo gives you this > hm... we should check that dependency. Epicea, Ombu and Hiedra packages should be versioned in pharo repo. > â¦ > Project: Hermes baseline > Project: Ficus 0.3.8 > ...RETRY->Hiedra > ...RETRY->Hiedra > gofer repository error: 'GoferRepositoryError: Could not access > http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut: > Cannot connect to 128.93.162.53:80'...ignoring > ...FAILED->Hiedra'Errors in script loaded from > /Users/norbert/play/iot/pharo/bootstrap/scripts/prepare_image.st' > Could not resolve: Hiedra [Hiedra] in > /Users/norbert/play/iot/pharo/pharo-local/package-cache > http://smalltalkhub.com/mc/MartinDias/Ficus/main/ ERROR: > âGoferRepositoryError: Could not access > http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut: > Cannot connect to 128.93.162.53:80' > â¦ > > > Am 08.08.2018 um 11:21 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > I was convinced that Epicea was now managed inside Pharo. > > On 8 Aug 2018, at 11:15, Norbert Hartl <norbert(a)hartl.name> wrote: > > The one thing is not be able to run the CI. The bigger problem is that > pharo is not buildable at all. Can we please move mission critical repos > like epicea to github? > > Norbert > > Am 08.08.2018 um 09:55 schrieb Guillermo Polito <guillermopolito(a)gmail.com > >: > > Hi all, > > Since yesterday evening, CI is down because of Inria network problems at > the level of Paris. > Inria tells us that they do not have yet an estimation of how much time it > will take to fix it. > > Until then, there will be no CI testing PRs nor new builds. > Previous Pharo builds are still available in http://files.pharo.org/, > which is hosted in OVH. > > I'll keep you updated, > Guille > > > > >

Aug. 8, 2018

[Pharo 7.0-dev] Build #1164: 21955-remove-methods-from-TClass-and-friends

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1164 was: FAILURE. The Pull Request #1657 was integrated: "21955-remove-methods-from-TClass-and-friends" Pull request url: https://github.com/pharo-project/pharo/pull/1657 Issue Url: https://pharo.fogbugz.com/f/cases/21955 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 8, 2018

[Pharo 7.0-dev] Build #1163: 22268-MCFileTreeFileSystemUtils-classwriteSteamForindo-should-delete-the-file-if-it-exists

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1163 was: SUCCESS. The Pull Request #1639 was integrated: "22268-MCFileTreeFileSystemUtils-classwriteSteamForindo-should-delete-the-file-if-it-exists" Pull request url: https://github.com/pharo-project/pharo/pull/1639 Issue Url: https://pharo.fogbugz.com/f/cases/22268 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 8, 2018

[Pharo 7.0-dev] Build #1162: 22245-Package-ReleaseTests-should-be-Release-Tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1162 was: SUCCESS. The Pull Request #1674 was integrated: "22245-Package-ReleaseTests-should-be-Release-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1674 Issue Url: https://pharo.fogbugz.com/f/cases/22245 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 8, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On 7 August 2018 at 19:47, Ben Coman <btc(a)openinworld.com> wrote: > > it gets stuck the following loop... https://github.com/bencoman/ opensmalltalk-vm/blob/8231b96f9b/platforms/win32/vm/ sqWin32SpurAlloc.c#L139-L183 whoops, that was meant to be the minheadless file.... https://github.com/bencoman/opensmalltalk-vm/blob/8231b96f9b/platforms/minh… In the meantime, I'll forge ahead to play with osvm_run(); > I've hardly used Visual Studio before, and never combined with CMake, so I'll record a few things I discover in case others might find it interesting or advise a better way. To try with the Stack Interpreter first, in CMakeLists.txt changed... option(COG_JIT "Cog JIT" ON) to... option(COG_JIT "Cog JIT" OFF) then cleared the cache... Right-clicked on "CMakeLists.txt > Cache(x64-Debug only) > Delete cache folder..." otherwise it didn't seem to pick up that change. To give the VM an image to run and something to do... Right-clicked on "CMakeLists.txt > Debug and Launch Settings > pharo.exe" then edited the presented "launch.vs.json" as follows... { "version": "0.2.1", "defaults": {}, "configurations": [ { "type": "default", "project": "CMakeLists.txt", "projectTarget": "pharo.exe (dist\\pharo.exe)", "name": "pharo.exe minImage+eval (dist\\pharo.exe)", "args": [ "C:\\#Dev\\latest-minimal-64\\Pharo7.0-metacello-64bit-65cff7b.image eval 19 + 23", ] }, ] } Then... "CMake > Build All" followed by starting... "x64-Debug" with "pharo.exe minImage+eval" which opened a console window that doesn't do much besides output like this... GIV(remapBufferCount) == 0 47923 Now I notice the file "dist\stderr" says... "Your VM is too old for this image. Please download the latest VM." so probably I need to run "scripts\updateSCCSVersions" but thats a shell script. How to run it under Windows? Luckily my installed Git Windows has Git Bash which opens a cygwin environment. where I do... cd /c/#Repos/OpenSmalltalk/opensmalltalk-vm/ ./scripts/ updateSCCSVersions Now to give a bit more visibility to program execution, in "spurstack64src/interp.c" I inserted the following into main interpreter loop... "+" unsigned long long debugCountBytecode = 0; while (1) { "+" debugCountBytecode += 1; "+" if ((debugCountBytecode % 100000 == 0)) "+" { "+" printf("%llu\n", debugCountBytecode); "+" } Then... "CMake > Build All" followed by starting... "x64-Debug" with "pharo.exe minImage+eval" which opened a console window with the following output... GIV(remapBufferCount) == 0 47923 GIV(remapBufferCount) == 0 42469 100000 200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 1400000 1500000 and updated contents of these files... yay! dist\stderr ==> #'EvaluateCommandLineHandler successfully finished' dist\stdout ==> 42 However the VM/Image keeps running. Adding "--quit" to the command line didn't help. I'm not really familiar with the command line handlers. Doing... "Debug > Break All" bring me up some warnings like... "winmm.pdb not loaded" "winmm.pdb contains the debug information required to find the source for the module winmm.dll" Never heard of a PDB, but loaded them by following these instructions... "Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger" https://msdn.microsoft.com/en-us/library/ms241613.aspx and learnt a lot more about them... "PDB Files: What Every Developer Must Know" https://www.wintellect.com/pdb-files-what-every-developer-must-know/ Now the next few times I started... "x64-Debug" with "pharo.exe minImage+eval" it got hung up downloading the symbols. I had to terminate & restart debugging it a few times as it progressed a bit each time. When finally got running again and after 1500000 printed I did... "Debug > Break All" and... "Debug > Windows > Threads" and now it shows the proper names rather than just addresses... A little surprised by the number of threads. No clue what ntdll.dll!NtWaitForWorkViaWorkerFactory or winmm.dll!timeThread are, but leave that for later. Now with all thread stopped, trying... "Debug > Windows > Parallel Stacks"... shows the two application threads are "in external code" invoked from ioRelinquishProcessorForMicroseconds() and beatThreadStateMachine(). Clicking on each of those displays their source code indicating the "external code" for each is MsgWaitForMultipleObjects() and WaitForSingleObject() respectively . Its very easy to flip back and forth between the two application threads, stepping-out of the "external code" with Shift-F11, to observe a tiny window of VM operation. Well thats enough for one post! Success running a MSVC compiled Spur Stack "minheadless" VM. Next I'll try... option(COG_JIT "Cog JIT" ON) cheers -ben P.S. Definitions for the curious... sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds) { /* wake us up if something happens */ ResetEvent(vmWakeUpEvent); MsgWaitForMultipleObjects(1, &vmWakeUpEvent, FALSE, microSeconds / 1000, QS_ALLINPUT); ioProcessEvents(); /* keep up with mouse moves etc. */ return microSeconds; } static DWORD WINAPI beatThreadStateMachine(void *careLess) { beatThreadState = active; while (beatThreadState != condemned) { DWORD res = WaitForSingleObject(beatSemaphore, beatThreadState == active ? beatMilliseconds : INFINITE); if (res == WAIT_TIMEOUT) heartbeat(); else if (res == WAIT_FAILED) abortMessage(TEXT("Fatal: WaitForSingleObject(beatSemaphore) %ld"), GetLastError()); else printLastError(TEXT("beatThreadStateMachine WaitForSingleObject")); } beatThreadState = dead; return 0; }

Aug. 8, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by Damien Pollet

First of all, quick stupid question: I'm currently loading my code with gitlocal://./src as the repository URL (my workflow starts in a terminal rather than in a Pharo image) Should I just remove the /src part, now that my repo has the project metadata? Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name> wrote: > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this however. I > keep frontend and backend code in some repositories together so the source > is in my case in backend/source. What does it mean for users not using the > âstandardâ name? > Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment already > but the .project file manifests this. So it should not be supported to have > more source dirs in one git repo? It might be not a good idea that the > client has to write the source dir but it opens the possibility that there > can be more than one. > I see your point here, but by using separate source directories you're sort of creating a hydra projectâ¦ What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that caseâ¦)? On the other hand, separate source directories would be helpful to work with git-subrepo and similar toolsâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 8, 2018

Re: [Pharo-dev] CI Down

by Norbert Hartl

Might be but doing make in the pharo repo gives you this â¦ Project: Hermes baseline Project: Ficus 0.3.8 ...RETRY->Hiedra ...RETRY->Hiedra gofer repository error: 'GoferRepositoryError: Could not access http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut: Cannot connect to 128.93.162.53:80'...ignoring ...FAILED->Hiedra'Errors in script loaded from /Users/norbert/play/iot/pharo/bootstrap/scripts/prepare_image.st' Could not resolve: Hiedra [Hiedra] in /Users/norbert/play/iot/pharo/pharo-local/package-cache http://smalltalkhub.com/mc/MartinDias/Ficus/main/ ERROR: âGoferRepositoryError: Could not access http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut: Cannot connect to 128.93.162.53:80' â¦ > Am 08.08.2018 um 11:21 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > I was convinced that Epicea was now managed inside Pharo. > >> On 8 Aug 2018, at 11:15, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> The one thing is not be able to run the CI. The bigger problem is that pharo is not buildable at all. Can we please move mission critical repos like epicea to github? >> >> Norbert >> >>> Am 08.08.2018 um 09:55 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >>> >>> Hi all, >>> >>> Since yesterday evening, CI is down because of Inria network problems at the level of Paris. >>> Inria tells us that they do not have yet an estimation of how much time it will take to fix it. >>> >>> Until then, there will be no CI testing PRs nor new builds. >>> Previous Pharo builds are still available in http://files.pharo.org/ <http://files.pharo.org/>, which is hosted in OVH. >>> >>> I'll keep you updated, >>> Guille >> >

Aug. 8, 2018

Re: [Pharo-dev] CI Down

by Esteban Lorenzano

I was convinced that Epicea was now managed inside Pharo. > On 8 Aug 2018, at 11:15, Norbert Hartl <norbert(a)hartl.name> wrote: > > The one thing is not be able to run the CI. The bigger problem is that pharo is not buildable at all. Can we please move mission critical repos like epicea to github? > > Norbert > >> Am 08.08.2018 um 09:55 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: >> >> Hi all, >> >> Since yesterday evening, CI is down because of Inria network problems at the level of Paris. >> Inria tells us that they do not have yet an estimation of how much time it will take to fix it. >> >> Until then, there will be no CI testing PRs nor new builds. >> Previous Pharo builds are still available in http://files.pharo.org/ <http://files.pharo.org/>, which is hosted in OVH. >> >> I'll keep you updated, >> Guille >

Aug. 8, 2018

Re: [Pharo-dev] CI Down

by Esteban Lorenzano

Also, this problems includes smalltalkhub :( Esteban (Good moment to remember all that we have good git support now :P) > On 8 Aug 2018, at 09:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > Since yesterday evening, CI is down because of Inria network problems at the level of Paris. > Inria tells us that they do not have yet an estimation of how much time it will take to fix it. > > Until then, there will be no CI testing PRs nor new builds. > Previous Pharo builds are still available in http://files.pharo.org/ <http://files.pharo.org/>, which is hosted in OVH. > > I'll keep you updated, > Guille

Aug. 8, 2018

Re: [Pharo-dev] CI Down

by Norbert Hartl

The one thing is not be able to run the CI. The bigger problem is that pharo is not buildable at all. Can we please move mission critical repos like epicea to github? Norbert > Am 08.08.2018 um 09:55 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi all, > > Since yesterday evening, CI is down because of Inria network problems at the level of Paris. > Inria tells us that they do not have yet an estimation of how much time it will take to fix it. > > Until then, there will be no CI testing PRs nor new builds. > Previous Pharo builds are still available in http://files.pharo.org/ <http://files.pharo.org/>, which is hosted in OVH. > > I'll keep you updated, > Guille

Aug. 8, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

> Am 07.08.2018 um 16:00 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi, > > I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :). > > First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it. > > One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....). > > This has some bad consequences: > - once a repository is referenced by some other project, it is more complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too. > - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF") > > Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties). > > So we decided that for this release we wanted to revert a bit that situation. Think object: let's put the meta-data used to interpret a project's structure inside the project itself. > The idea is that: > > - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory. > - a project without a .project file is an old project and cannot be interpreted, because we don't know the source directory > - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file > - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly) > - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this). > > # About defaults values / forcing the user to define a project > > First, notice that even when the repositories you load are just marked as "dirty". > This is because in memory we add a project to your repository. > But you're not forced to commit it. > Actually, you can still load packages and baselines from that repository without committing. > > This is in line with Iceberg's "explicitness". We try to not do any destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file. > > If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks. > To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value. > This could work, but right now all projects use different names for their source directories. > So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). > However, not much repositories use 'src' so it will still produce a lot of "noise"... > > But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too... > > Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too. > I think I can see what is the rationale behind it but Iâm not sure this can be the way to go: - I donât think there can be a âstandard wayâ of defining source directory. And I donât think that a tool should enforce this however. I keep frontend and backend code in some repositories together so the source is in my case in backend/source. What does it mean for users not using the âstandardâ name? - I donât see why there needs to be a 1:1 relationship between a repository and working copy in pharo. It is like this at the moment already but the .project file manifests this. So it should not be supported to have more source dirs in one git repo? It might be not a good idea that the client has to write the source dir but it opens the possibility that there can be more than one. - My mode of working is to have an eye on dirty repositories because that shows what the impact of your work is. If I have a lot of dirty repositories in my repository list it does not feel good and I donât want that. Especially for projects I donât have write access to. How can I change this? Iâm not sure that assuming everyone will add these files is a likely one. Norbert

Aug. 8, 2018