Re: [Pharo-dev] CI Down

[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  wrote:

>
>
> El mié., 8 de ago. de 2018 05:44, Norbert Hartl 
> 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 :
>>
>> I was convinced that Epicea was now managed inside Pharo.
>>
>> On 8 Aug 2018, at 11:15, Norbert Hartl  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 <
>> guillermopol...@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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] CI Down

[Martin Dias]

El mié., 8 de ago. de 2018 05:44, Norbert Hartl 
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 :
>
> I was convinced that Epicea was now managed inside Pharo.
>
> On 8 Aug 2018, at 11:15, Norbert Hartl  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  >:
>
> 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
>
>
>
>
>

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/1164/

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/1163/

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/development/1162/

Re: [Pharo-dev] New Iceberg Version 1.2.1

[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  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

Re: [Pharo-dev] CI Down

[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 :
> 
> I was convinced that Epicea was now managed inside Pharo.
> 
>> On 8 Aug 2018, at 11:15, Norbert Hartl > > 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 >> >:
>>> 
>>> 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
>> 
> 

Re: [Pharo-dev] CI Down

[Esteban Lorenzano]

I was convinced that Epicea was now managed inside Pharo.

> On 8 Aug 2018, at 11:15, Norbert Hartl  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 > >:
>> 
>> 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
> 

Re: [Pharo-dev] CI Down

[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  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/ 
> , which is hosted in OVH.
> 
> I'll keep you updated,
> Guille

Re: [Pharo-dev] CI Down

[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 :
> 
> 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

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Norbert Hartl]

> Am 07.08.2018 um 16:00 schrieb Guillermo Polito :
> 
> 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 

Re: [Pharo-dev] About the infinite debugger

[teso...@gmail.com]

Yes, we have to check all the scenarios.

The problems with the UI process is not resolved at all.

On Tue, Aug 7, 2018 at 11:11 PM Denis Kudriashov 
wrote:

> I have more special cases where debugger hangs:
> 19662
> 
> , 19928
> 
> , 20274
> 
> .
> They are still relevant
>
> 2018-08-07 22:01 GMT+01:00 Denis Kudriashov :
>
>> Hi.
>>
>> Good job guys. I just checked my case 19848
>> .
>> And it is now fixed.
>>
>> Thanks
>>
>>
>>
>> 2018-06-29 15:48 GMT+01:00 Guillermo Polito :
>>
>>> Hi all,
>>>
>>> during today's sprint we have been working with lots of people on the
>>> infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/).
>>> We have checked the emails sent in the latest month. Then, together with
>>> Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis
>>> all day. We have been also comparing the debuggers code between pharo 3/4
>>> (where the bug was is present) and pharo 7, but this was not necessarily
>>> straight forward as the code is not the same and there is no easy diff...
>>>
>>> ND, we have found that the problem may come from a wrong pragma
>>> marker. Just removing that pragma gives us back the same behaviour as in
>>> Pharo 3/4. :D
>>>
>>> https://github.com/pharo-project/pharo/pull/1621
>>>
>>> I know that the exception handling/debugging has been modified several
>>> times in the latest years (some refactorings, hiding contexts...), we
>>> unfortunately don't have tests for it, so I'd like some more pair of eyes
>>> on it. Ben, Martin could you take a look?
>>>
>>> Thanks all for the fish,
>>> Guille
>>>
>>
>>
>

-- 
Pablo Tesone.
teso...@gmail.com

[Pharo-dev] CI Down

[Guillermo Polito]

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

Re: [Pharo-dev] Minheadless trial

[Esteban Lorenzano]

Hi,

> On 8 Aug 2018, at 09:33, Ben Coman  wrote:
> 
> 
> 
> On 7 August 2018 at 13:47, Esteban Lorenzano  > wrote:
> Hi Ben,
> 
> Sorry for coming here so late, I didn’t see this thread before. 
> I already have a working minheadless branch that was adapted to Eliot’s 
> process. 
> It was working for Pharo in Linux and Mac (Windows was ongoing but not 
> finished, that’s why is not pushed).
> 
> You can find this branch here: 
> 
> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm 
> 
> 
> I'll have a look at it.
>  
> Interesting part is that I didn’t tackled any of the issues you are working 
> on, so the work is easily mergeable :) 
> 
> Cheers, 
> Esteban
> 
> Ps: with some changes in image, I’m using exclusively this VM since a couple 
> of months and it works fine.
> 
> That is good to know.  So just to be clear... 
> even though its name indicates "headless", you are running a full graphical 
> Image?

Yes, using SDL2 and OSWindow (with some modifications). Advantages of Pharo 
investment on this, even in things that seemed useless at the beginning ;)
Also, the minheadless VM has a “traditional display” flag that will start a 
word too.

> I got more curious about the original announcement saying... 
> "minheadless is a VM variant that unifies a lot of the code for Windows, 
> Linux and OS X.”

Yes, I like what Ronie did there, even if there is still work to do, but is 
cool.

> 
> So here 
> https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_AxnZKl7x048/edit?usp=sharing
>  
> 
> I compare...
>find "platforms/Win32/vm" -exec wc {} \;
>find "platforms/Unix/vm" -exec wc {} \; 
>find "platforms/Mac OS/vm" -exec wc {} \;
> to...
>find "platforms/minheadless" -exec wc {} \; 
> 
> and if nothing important has been missed it seems about 30% of the original 
> size. 
> I'd expect Ronie's effort to produce this should have a massive impact on 
> future maintainability.  

It depends, but this is one of the reasons why we want to move into it. 
Our strategy is let the less possible in the VM (ideally, just the “core” VM 
and a great FFI support), and move all the rest into the image.

Esteban

> 
> cheers -ben
> 
> P.S. I excluded the following presuming its common before/after.
>find "platforms/Cross/vm" -exec wc {} \;
> btw, its about half the size of platforms/minheadless.