[Pharo-users] Metacello load baselines/configurations only

2018-10-02 Thread Peter Uhnak
Hi,

is there a way to instruct Metacello to only install
BaselineOfs/ConfigurationOfs instead of the entire project? For the
purposes of analyzing dependencies.

Thanks,
Peter


Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

2018-10-02 Thread Ben Coman
On Wed, 3 Oct 2018 at 02:27, Sean P. DeNigris  wrote:

> What do you think about Ben's post (paraphrased) that "canonical" doesn't
> mean much in the git/GH world?


I'm happy with that paraphrasing but just to make a fine distinction.
I think the canonical repo is still important, particularly regarding
author rights,
but its not important that its the only copy.
Its a balance between author rights and community rights.
Apart from purely philanthropic reasons, software is open sourced to get
community involvement.
Users that invest time and effort using of open source software can be
argued to have "some" rights
regarding continuity of access and ease of collaboration. I think its this
need that repo copies fill.


On Wed, 3 Oct 2018 at 05:06, Sean P. DeNigris  wrote:

> Ben Coman wrote
> >> In this case, to get the ball rolling would it be possible to create
> >>> under one's own user account
> >> and then transfer to ownership the appropriate entity?
> >>
> > That seems reasonable.  It should be simple to later fork that repo under
> > Pharo-contributions.
>
> Firstly, I have to, as Dale says, "Eat my hat" because this is the first
> time using the migration tool was *not* straightforward! It fell over
> several times due to PDFDocument's comment. First, there was some weird
> non-text, and then a non-ascii character (asciiValue = 8230). Anyway, to
> hopefully prevent any further non-productive conversation, I migrated the
> repo with the hopes that someone in the pharo-contributions organization
> will copy it. I didn't "Transfer" it because after reading the docs, there
> is some internal redirect mechanism instead of a real "move" and e.g. I
> will
> then not be able to have a fork with that name. After it has been pushed to
> the new remote, let me know and I will delete mine.
>
> https://github.com/seandenigris/Artefact


Thanks Sean.

cheers -ben


Re: [Pharo-users] PharoLauncher "version determination error"

2018-10-02 Thread Esteban A. Maringolo
Thanks Sean,

Weird, I think I'm already running 1.4, because the downloaded setup
file was named pharo-launcher-1.4 (I'm downloading again just in case).

The about of my current version shows:
- PharoLauncher-Core-VincentBlondeau.184
- PharoLauncher-Spec-ChristopheDemarey.66
- PharoLauncher-Tests-Core-VincentBlondeau.24

Regards,

On 10/2/2018 9:09 PM, Sean P. DeNigris wrote:
> Esteban A. Maringolo wrote
>> Am I doing something wrong?
> 
> No. It was a bug that has been fixed. From Christophe in another thread:
>> The problem is probably fixed in the latest PharoLauncher version (1.4) 
>> available from http://pharo.org/download.
>> If not, as specified in the dialog text, please run the given command from 
>> the command line to give us more information on what is the problem.
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

-- 
Esteban A. Maringolo



Re: [Pharo-users] [Moose-dev] Plotting genome scale values with Roassal

2018-10-02 Thread Alexandre Bergel via Pharo-users
--- Begin Message ---
Pretty cool!

Alexandre

> On Oct 2, 2018, at 2:21 AM, Hernán Morales Durand  
> wrote:
> 
> 


--- End Message ---


Re: [Pharo-users] PharoLauncher "version determination error"

2018-10-02 Thread Sean P. DeNigris
Esteban A. Maringolo wrote
> Am I doing something wrong?

No. It was a bug that has been fixed. From Christophe in another thread:
> The problem is probably fixed in the latest PharoLauncher version (1.4) 
> available from http://pharo.org/download.
> If not, as specified in the dialog text, please run the given command from 
> the command line to give us more information on what is the problem.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



[Pharo-users] PharoLauncher "version determination error"

2018-10-02 Thread Esteban Maringolo
I downloaded a Pharo 7.0 32 bit using PharoLauncher in Windows, and I'm
getting the mentioned error when attempting to launch the image.

Before displaying the error it opens the image (or an image) twice.



[image: image.png]

Am I doing something wrong?

Regards,

Esteban A. Maringolo


Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

2018-10-02 Thread Sean P. DeNigris
Ben Coman wrote
>> In this case, to get the ball rolling would it be possible to create
>>> under one's own user account
>> and then transfer to ownership the appropriate entity?
>>
> That seems reasonable.  It should be simple to later fork that repo under
> Pharo-contributions.

Firstly, I have to, as Dale says, "Eat my hat" because this is the first
time using the migration tool was *not* straightforward! It fell over
several times due to PDFDocument's comment. First, there was some weird
non-text, and then a non-ascii character (asciiValue = 8230). Anyway, to
hopefully prevent any further non-productive conversation, I migrated the
repo with the hopes that someone in the pharo-contributions organization
will copy it. I didn't "Transfer" it because after reading the docs, there
is some internal redirect mechanism instead of a real "move" and e.g. I will
then not be able to have a fork with that name. After it has been pushed to
the new remote, let me know and I will delete mine.

https://github.com/seandenigris/Artefact



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

2018-10-02 Thread Sean P. DeNigris
Peter Uhnak wrote
> pharo-contribs seems like the best choice

The issue with that is that I didn't see a way for me to add a repo under
that organization, leading me to believe that we would create a bottleneck
like that of integration where all progress depends on a few gatekeepers.
What do you think about Ben's post (paraphrased) that "canonical" doesn't
mean much in the git/GH world?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



Re: [Pharo-users] Iceberg - better control of project name?

2018-10-02 Thread Sean P. DeNigris
Ben Coman wrote
> I'd expect the project name within Iceberg to match the name
> of the working directory on disk.

I wonder if e.g. direct git loading creating a directory with the same name
as the repo (and maybe not what you'd want to see in Pharo) would make that
potentially problematic. Maybe that's an artificial limitation? Not sure,
just musing...



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



Re: [Pharo-users] GTDocument how to

2018-10-02 Thread Juraj Kubelka via Pharo-users
--- Begin Message ---
Hi Hilaire,

You are right, we cannot have real Morph widget inside of Bloc element.

Cheers,
Juraj

> On Oct 2, 2018, at 14:38, Hilaire  wrote:
> 
> Thanks for the tips. It works, the view is not interactive though
> 
> Hilaire
> 
> 
> Le 30/09/2018 à 16:18, Juraj Kubelka via Pharo-users a écrit :
>> You can create extension similar to one you have
>> here: DrGeoCanvas>>#gtInspectorCanvasIn:
>> 
>> DrGeoCanvas>>#gtCanvasIn: aView
>> 
>> ^ self view 
>> ifNil: [ aView empty ] 
>> ifNotNil: [ :aMorph | aMorph gtMorphFor: aView ]
>> 
>> 
>> Then you can obtain Documenter views like this:
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 


--- End Message ---


Re: [Pharo-users] GTDocument how to

2018-10-02 Thread Hilaire
Thanks for the tips. It works, the view is not interactive though

Hilaire


Le 30/09/2018 à 16:18, Juraj Kubelka via Pharo-users a écrit :
> You can create extension similar to one you have
> here: DrGeoCanvas>>#gtInspectorCanvasIn:
>
> DrGeoCanvas>>#gtCanvasIn: aView
> 
> ^ self view 
> ifNil: [ aView empty ] 
> ifNotNil: [ :aMorph | aMorph gtMorphFor: aView ]
>
>
> Then you can obtain Documenter views like this:

-- 
Dr. Geo
http://drgeo.eu





Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

2018-10-02 Thread Ben Coman
On Tue, 2 Oct 2018 at 23:21, Peter Uhnak  wrote:

>
>
> On Tue, Oct 2, 2018 at 4:55 PM Sean P. DeNigris 
> wrote:
>
>> Guillermo Polito wrote
>> > when somebody migrates the repository.
>>
>> Who has access to the Pharo-contributions GH organization? Is that the
>> "go-to" repository for this case? I'm not often clear about under which GH
>> user/org something should be ported if one is not the owner. Do we have a
>> policy?
>
>


> In this case, to get the ball rolling would it be possible to create
>> under one's own user account
>
> and then transfer to ownership the appropriate entity?
>
>
That seems reasonable.  It should be simple to later fork that repo under
Pharo-contributions.


>
> If the project is actively maintained, then please ask the maintainer
> (e.g. I'm waiting for monty to respond to my offer to migrate XMLParser).
>
> Migrating it under your own account is sending signal to the community "I
> am going to take care and MAINTAIN this project.".
> Unless that is your intention, then pharo-contribs seems like the best
> choice. Unlike the old approach it is easy for anyone to contribute with
> pull requests without having to wait for access rights or whatnot.
>

I may be out of line, but in this era of super-simple forking (e.g. on
github), I feel the rules have evolved.
Over time I've encountered several projects having "This is a mirror of
 at  (e.g. some svn repo)"
as the first line of their README.md - perhaps in bold or red.  Pointing to
the location of the canonical repo
always seemed to me to be reasonable attribution and indication of where
care and maintenance is focused.

cheers -ben


Re: [Pharo-users] Iceberg - better control of project name?

2018-10-02 Thread Ben Coman
On Tue, 2 Oct 2018 at 15:52, Guillermo Polito 
wrote:

>  - Maybe, for old projects that don't have a name, we could initialize a
> project's name as it's repository name?
>

In any case, I'd expect the project name within Iceberg to match the name
of the working directory on disk.
Possibly even the project renamed within Iceberg should rename the disk
working directory.
(btw, I don't know if "project name" is the best term, but I can't think of
a better one.)

cheers -ben


>
> On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon  wrote:
>
>> Sounds like the user override is what we are after - I guess we need to
>> make a pr ... sadly my laptop has died so it’s not going to be me for a
>> little while until I can find an Apple store on my travels.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 2 Oct 2018, at 12:30, Ben Coman  wrote:
>>
>>
>>
>> On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris 
>> wrote:
>>
>>> Tim Mackinnon wrote
>>> > either by showing {owner}/{project}
>>>
>>> What about when there are multiple remotes?
>>>
>>
>> +1 to what you imply here, that the owner/remote should not be auto-coded
>> into the project name.
>> Remote are well handled within Iceberg.
>> The user though could add the owner as free text into a custom project
>> name i.e. "owner-project"
>>
>> cheers -ben
>>
>>
>>
>
> --
>
>
>
> 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-users] Image does not start anymore

2018-10-02 Thread Bernhard Pieber
Hi Vincent,

It occurred to me that I had probably misunderstood you. I had tried with the 
Squeak VM and not the latest OpenSmalltalk Pharo VM. With that my image works 
again. Code is saved. Data is there. Learned something for next time. :-)

Thanks everyone for your help.

Cheers,
Bernhard


> Am 02.10.2018 um 09:24 schrieb Bernhard Pieber :
> 
> Hi Vincent,
> 
> Thanks for taking the time to answer. Yes, I have the same error every time.
> 
> I tried with the latest stable Squeak VM. However, I get an error „External 
> module not found“ for libgit2.dll.
> 
> I am afraid I cannot provide the image because the data it contains is 
> sensitive.
> 
> I will look into Epicea next.
> 
> Cheers,
> Bernhard
> 
>> Am 01.10.2018 um 18:09 schrieb  
>> :
>> 
>> Hi,
>> 
>> That is weird. It seems that you should have some debugging process 
>> running... Do you have the same error if you try again? So can also try with 
>> a squeak VM which is more simple.
>> You can always retrieve your changes with Epicea (see Gif) and you 
>> playground code (see in the play cache folder).
>> 
>> Worse case, I can try something to get your data back but without any 
>> guaranty that it will work because it implies to play with the image 
>> bytecode. 
>> 
>> Cheers,
>> Vincent
>> 
>> -Original Message-
>> From: Pharo-users  On Behalf Of 
>> Bernhard Pieber
>> Sent: Saturday, September 29, 2018 9:07
>> To: Any question about pharo is welcome 
>> Subject: [Pharo-users] Image does not start anymore
>> 
>> Hi,
>> 
>> I have a Pharo 7 image which I normally start from Pharo Launcher on 
>> Windows. I think I saved it without problems. However, suddenly it stopped 
>> opening. As it contains data and some unsaved code I would hate to loose, 
>> I'd appreciate any help on how to debug a situation like this. I attached 
>> the debug log.
>> 
>> Cheers,
>> Bernhard
>> <2018-10-01_09-03-51.gif>




Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

2018-10-02 Thread Peter Uhnak
On Tue, Oct 2, 2018 at 4:55 PM Sean P. DeNigris 
wrote:

> Guillermo Polito wrote
> > when somebody migrates the repository.
>
> Who has access to the Pharo-contributions GH organization? Is that the
> "go-to" repository for this case? I'm not often clear about under which GH
> user/org something should be ported if one is not the owner. Do we have a
> policy? In this case, to get the ball rolling would it be possible to
> create
> under one's own user account and then transfer to ownership the appropriate
> entity?


If the project is actively maintained, then please ask the maintainer (e.g.
I'm waiting for monty to respond to my offer to migrate XMLParser).

Migrating it under your own account is sending signal to the community "I
am going to take care and MAINTAIN this project.".
Unless that is your intention, then pharo-contribs seems like the best
choice. Unlike the old approach it is easy for anyone to contribute with
pull requests without having to wait for access rights or whatnot.

Peter


Re: [Pharo-users] Image does not start anymore

2018-10-02 Thread Sean P. DeNigris
Ben Coman wrote
> I'm guessing that would start by copying the ombu folders under
> pharo-local
> to a new image.

Not sure if it's "the way", but I've done that successfully before.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



Re: [Pharo-users] [ANN] Migrated Artefact to GitHub

2018-10-02 Thread Sean P. DeNigris
Guillermo Polito wrote
> when somebody migrates the repository.

Who has access to the Pharo-contributions GH organization? Is that the
"go-to" repository for this case? I'm not often clear about under which GH
user/org something should be ported if one is not the owner. Do we have a
policy? In this case, to get the ball rolling would it be possible to create
under one's own user account and then transfer to ownership the appropriate
entity?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html



Re: [Pharo-users] [Pharo-dev] [ANN] Success story Mobility Map

2018-10-02 Thread Marcus Denker


The Slides from the ESUG presentation are now inline here:

https://www.slideshare.net/zweidenker/docker-and-pharo-zweidenker


>>> 
>>> As presented on ESUG here is the brief description of one of our current 
>>> projects. 
>>> 
>>> Mobility Map
>>> ——
>>> 
>>> Mobility Map is a broker for mobility services. It offers multi-modal 
>>> routing search enabling users to find the best travel options between 
>>> locations. Travel options include car sharing, bikes, trains, busses etc. 
>>> Rented cars can be offered for ride sharing on booking time letting other 
>>> people find it to participate in the ride. Single travel options are 
>>> combined in travel plans that can be booked and managed in a very easy way. 
>>> 
>>> For this project main requirements were scalability to serve a large user 
>>> base and flexibility to add more additional providers to the broker. The 
>>> application has been realized using web technologies for the frontend and 
>>> pharo for the backend. Using a microservice architecture combined with a 
>>> broker it is easy to extend the platform with additional brokers. 
>>> Deployment is done using docker swarm for distributing dozens of pharo 
>>> images among multiple server machines connected by a message queue for the 
>>> communication. Pharo supported that scenario very well enabling us the meet 
>>> the requirements with less effort. 
>>> 
>>> Pharo turned out to be a perfect fit to develop the application in a agile 
>>> way. Small development cycles with continuous integration and continuous 
>>> delivery enables fast turnarounds for the customers to validate progress.
>>> 
>>> This is a screenshot of the search page for multi-modal results:
>>> 
>>> 
>>> 
>> 
>> 
> 
> 




Re: [Pharo-users] Iceberg - better control of project name?

2018-10-02 Thread Guillermo Polito
Issue: https://github.com/pharo-vcs/iceberg/issues/1009



On Tue, Oct 2, 2018 at 10:02 AM Guillermo Polito 
wrote:

> Aaand the mail got sent before :)
>
> Then two other comments that are related or I'd like to discuss:
>   - So far we can allow in iceberg several projects with the same name.
> That is not a problem, so you can clone the same project from two different
> repositories. Of course this would mean that one will be dirty all the time
> (in comparison against the image).
>   - I'd like to "rethink" the directory structure. We have chosen to use
> {owner}/{repository} for some time now, but that is only valid for those
> hostings that store repositories under a username (e.g.,
> github/gitlab/bitbucket) and is not valid for other kind of git
> hostings/server (e.g., a home gitolite).
> This makes that the directory where the repositories are, suddenly
> mixes different structures {owner}/{repository} and {repository}, and we
> pay that lack of coherence afterwards... But making a purely flat structure
> will cause much more name clashes. And there is some story with Metacello
> compatibility around it too!
> I'm just not sure what is the bestish solution here. Maybe what we
> have is good enough, but if somebody would like to prototype around this,
> I'd be glad to learn more about pros and cons ^^.
>
> On Tue, Oct 2, 2018 at 9:51 AM Guillermo Polito 
> wrote:
>
>> Yes, I agree with most of the comments here. I'll try to summarize:
>>
>>  - we should be able to specify the name of a project independently of
>> their location/repository name
>>  - Maybe, for old projects that don't have a name, we could initialize a
>> project's name as it's repository name?
>>
>> On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon  wrote:
>>
>>> Sounds like the user override is what we are after - I guess we need to
>>> make a pr ... sadly my laptop has died so it’s not going to be me for a
>>> little while until I can find an Apple store on my travels.
>>>
>>> Tim
>>>
>>> Sent from my iPhone
>>>
>>> On 2 Oct 2018, at 12:30, Ben Coman  wrote:
>>>
>>>
>>>
>>> On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris 
>>> wrote:
>>>
 Tim Mackinnon wrote
 > either by showing {owner}/{project}

 What about when there are multiple remotes?

>>>
>>> +1 to what you imply here, that the owner/remote should not be
>>> auto-coded into the project name.
>>> Remote are well handled within Iceberg.
>>> The user though could add the owner as free text into a custom project
>>> name i.e. "owner-project"
>>>
>>> cheers -ben
>>>
>>>
>>>
>>
>> --
>>
>>
>>
>> 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
>>
>
>
> --
>
>
>
> 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
>


-- 



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-users] Iceberg - better control of project name?

2018-10-02 Thread Guillermo Polito
Aaand the mail got sent before :)

Then two other comments that are related or I'd like to discuss:
  - So far we can allow in iceberg several projects with the same name.
That is not a problem, so you can clone the same project from two different
repositories. Of course this would mean that one will be dirty all the time
(in comparison against the image).
  - I'd like to "rethink" the directory structure. We have chosen to use
{owner}/{repository} for some time now, but that is only valid for those
hostings that store repositories under a username (e.g.,
github/gitlab/bitbucket) and is not valid for other kind of git
hostings/server (e.g., a home gitolite).
This makes that the directory where the repositories are, suddenly
mixes different structures {owner}/{repository} and {repository}, and we
pay that lack of coherence afterwards... But making a purely flat structure
will cause much more name clashes. And there is some story with Metacello
compatibility around it too!
I'm just not sure what is the bestish solution here. Maybe what we have
is good enough, but if somebody would like to prototype around this, I'd be
glad to learn more about pros and cons ^^.

On Tue, Oct 2, 2018 at 9:51 AM Guillermo Polito 
wrote:

> Yes, I agree with most of the comments here. I'll try to summarize:
>
>  - we should be able to specify the name of a project independently of
> their location/repository name
>  - Maybe, for old projects that don't have a name, we could initialize a
> project's name as it's repository name?
>
> On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon  wrote:
>
>> Sounds like the user override is what we are after - I guess we need to
>> make a pr ... sadly my laptop has died so it’s not going to be me for a
>> little while until I can find an Apple store on my travels.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 2 Oct 2018, at 12:30, Ben Coman  wrote:
>>
>>
>>
>> On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris 
>> wrote:
>>
>>> Tim Mackinnon wrote
>>> > either by showing {owner}/{project}
>>>
>>> What about when there are multiple remotes?
>>>
>>
>> +1 to what you imply here, that the owner/remote should not be auto-coded
>> into the project name.
>> Remote are well handled within Iceberg.
>> The user though could add the owner as free text into a custom project
>> name i.e. "owner-project"
>>
>> cheers -ben
>>
>>
>>
>
> --
>
>
>
> 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
>


-- 



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-users] Iceberg - better control of project name?

2018-10-02 Thread Guillermo Polito
Yes, I agree with most of the comments here. I'll try to summarize:

 - we should be able to specify the name of a project independently of
their location/repository name
 - Maybe, for old projects that don't have a name, we could initialize a
project's name as it's repository name?

On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon  wrote:

> Sounds like the user override is what we are after - I guess we need to
> make a pr ... sadly my laptop has died so it’s not going to be me for a
> little while until I can find an Apple store on my travels.
>
> Tim
>
> Sent from my iPhone
>
> On 2 Oct 2018, at 12:30, Ben Coman  wrote:
>
>
>
> On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris 
> wrote:
>
>> Tim Mackinnon wrote
>> > either by showing {owner}/{project}
>>
>> What about when there are multiple remotes?
>>
>
> +1 to what you imply here, that the owner/remote should not be auto-coded
> into the project name.
> Remote are well handled within Iceberg.
> The user though could add the owner as free text into a custom project
> name i.e. "owner-project"
>
> cheers -ben
>
>
>

-- 



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-users] Image does not start anymore

2018-10-02 Thread Bernhard Pieber
Hi Vincent,

Thanks for taking the time to answer. Yes, I have the same error every time.

I tried with the latest stable Squeak VM. However, I get an error „External 
module not found“ for libgit2.dll.

I am afraid I cannot provide the image because the data it contains is 
sensitive.

I will look into Epicea next.

Cheers,
Bernhard

> Am 01.10.2018 um 18:09 schrieb  
> :
> 
> Hi,
> 
> That is weird. It seems that you should have some debugging process 
> running... Do you have the same error if you try again? So can also try with 
> a squeak VM which is more simple.
> You can always retrieve your changes with Epicea (see Gif) and you playground 
> code (see in the play cache folder).
> 
> Worse case, I can try something to get your data back but without any 
> guaranty that it will work because it implies to play with the image 
> bytecode. 
> 
> Cheers,
> Vincent
> 
> -Original Message-
> From: Pharo-users  On Behalf Of Bernhard 
> Pieber
> Sent: Saturday, September 29, 2018 9:07
> To: Any question about pharo is welcome 
> Subject: [Pharo-users] Image does not start anymore
> 
> Hi,
> 
> I have a Pharo 7 image which I normally start from Pharo Launcher on Windows. 
> I think I saved it without problems. However, suddenly it stopped opening. As 
> it contains data and some unsaved code I would hate to loose, I'd appreciate 
> any help on how to debug a situation like this. I attached the debug log.
> 
> Cheers,
> Bernhard
> <2018-10-01_09-03-51.gif>