Re: [Pharo-users] Class shown in _UnpackagedPackage but belongs to package

[Ben Coman]

Thought-0.0.2...
What does Monticello > Browse show?

Thought-0.0.3...
Have a look at RPackageOrganizer class >> initialize

cheers -ben

On Wed, Sep 14, 2016 at 1:05 PM, Ben Coman  wrote:
> Very first thought...
> 1. Close all Nautilus windows.
> 2. Smalltalk recompileAll.
>
> ??
> cheers -ben
>
> On Wed, Sep 14, 2016 at 11:58 AM, Esteban A. Maringolo
>  wrote:
>> Hi,
>>
>> After renaming, promoting as tag, moving to package and other
>> non-secuential operations in Nautilus which screwed up the packaging,
>> now all classes are shown in _UnpackagedPackage but when browsed via
>> Spotter they show the right package in the class template.
>>
>> SequenceableCollection subclass: #OrderedCollection
>>   instanceVariableNames: 'array firstIndex lastIndex'
>>   classVariableNames: ''
>>   package: 'Collections-Sequenceable'
>>
>> Any pointers on how to fix/rebuild whatever is needed?
>> It took me two classes and less than 5 minutes to screw it, I guess
>> it's a new record. :)
>>
>> Regards!
>>
>> ps: this happens with the latest 5.0 image and vm version.
>>
>> Esteban A. Maringolo
>>

Re: [Pharo-users] Class shown in _UnpackagedPackage but belongs to package

[Ben Coman]

Very first thought...
1. Close all Nautilus windows.
2. Smalltalk recompileAll.

??
cheers -ben

On Wed, Sep 14, 2016 at 11:58 AM, Esteban A. Maringolo
 wrote:
> Hi,
>
> After renaming, promoting as tag, moving to package and other
> non-secuential operations in Nautilus which screwed up the packaging,
> now all classes are shown in _UnpackagedPackage but when browsed via
> Spotter they show the right package in the class template.
>
> SequenceableCollection subclass: #OrderedCollection
>   instanceVariableNames: 'array firstIndex lastIndex'
>   classVariableNames: ''
>   package: 'Collections-Sequenceable'
>
> Any pointers on how to fix/rebuild whatever is needed?
> It took me two classes and less than 5 minutes to screw it, I guess
> it's a new record. :)
>
> Regards!
>
> ps: this happens with the latest 5.0 image and vm version.
>
> Esteban A. Maringolo
>

[Pharo-users] Class shown in _UnpackagedPackage but belongs to package

[Esteban A. Maringolo]

Hi,

After renaming, promoting as tag, moving to package and other
non-secuential operations in Nautilus which screwed up the packaging,
now all classes are shown in _UnpackagedPackage but when browsed via
Spotter they show the right package in the class template.

SequenceableCollection subclass: #OrderedCollection
  instanceVariableNames: 'array firstIndex lastIndex'
  classVariableNames: ''
  package: 'Collections-Sequenceable'

Any pointers on how to fix/rebuild whatever is needed?
It took me two classes and less than 5 minutes to screw it, I guess
it's a new record. :)

Regards!

ps: this happens with the latest 5.0 image and vm version.

Esteban A. Maringolo

Re: [Pharo-users] [Pharo-dev] [ANN] RProjectConnector V2.1

[Ben Coman]

On Wed, Sep 14, 2016 at 12:25 AM, Blondeau Vincent
 wrote:
>
>
>
>> -Message d'origine-
>> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
>> Serge Stinckwich
>> Envoyé : vendredi 2 septembre 2016 16:44
>> À : Pharo Development List
>> Cc : scismallt...@googlegroups.com; Any question about pharo is welcome
>> Objet : Re: [Pharo-dev] [ANN] RProjectConnector V2.1
>>
>> Great job Vincent !
>>
> It will be great when it will work on OS X ;)
>
>> There is some problems on Mac OS X:
>> - when I try to load in a fresh Pharo 5.0 image, I got a DNU on:
>> RObjectArray class>>initElementType:
>> I was able to load the package after a while by loading directly the package
>> with the Monticello Browser
>
> Strange, I deleted these methods... Please ensure you are using a Pharo 6.0 
> image (it should work under Pharo 5.0 too) and that version 14 of 
> ConfigurationOfRProjectConnector and version 71 of the RConnector packages 
> are loaded.
>
>> - Apparently there is still some methods using NB like: RSession
>> class>>checkSession or RSession class>>initEmbeddedR:
>
> Should not, it is modified ...
>
>>
>> I try to move the R dll close to my Pharo VM and also inside the Plugins
>> directory but without success ...
>
> It should be at the same location that libcairo.2.dylib
>
>> Is there a way to say where are the R dll instead of copying them ?

Are you using the system to do the library path resolution? Or finding
the library file in Pharo and then passing an absolute path to FFI?

cheers -ben

>>
> Didn't think so .. Maybe the VM developers knows ?
>
>
> Thanks!
>
> Vincent
>
>
>> Thank you.
>>
>>
>>
>>
>> On Thu, Sep 1, 2016 at 5:42 PM, Blondeau Vincent
>>  wrote:
>> > Hello everyone,
>> >
>> >
>> >
>> > I am glad to announce the release of version 2.1 of the RProjectConnector.
>> >
>> > The binding between Pharo and R (https://www.r-project.org/) is now
>> > translated to UFFI and so to Pharo 6.0.
>> >
>> >
>> >
>> > You can call directly your R methods from Pharo. For example, with the
>> > famous iris clustering example:
>> >
>> >
>> >
>> >   iris := 'eval' asREval: {RObject findVar: 'iris'}.
>> >
>> >   'plot'
>> >
>> > asREval:
>> >
>> > {(iris at: 'Petal.Length').
>> >
>> > (iris at: 'Petal.Width').
>> >
>> > (#pch -> 21).
>> >
>> > (#xlab -> 'length').
>> >
>> > (#ylab -> 'Width').
>> >
>> > (#bg  ->((iris at: 'Species') collect:
>> > [ :value | {'red'. 'green3'. 'blue'} at: value ])).
>> >
>> > (#main -> 'Edgar Anderson''s Iris Data')}.
>> >
>> >   iris inspect.
>> >
>> >
>> >
>> > To use it, you should install R and copy the R libraries near the
>> > Pharo VM (see the documentation on SmalltalkHub
>> > (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for
>> > how to proceed).
>> >
>> >
>> >
>> > Don’t forget to relaunch Pharo after the installation to be able to
>> > use the connector.
>> >
>> >
>> >
>> > Only basic features are implemented yet, but you can participate to
>> > its extension!
>> >
>> >
>> >
>> > Cheers,
>> >
>> > Vincent Blondeau
>> >

Re: [Pharo-users] double dispatch example

[Denis Kudriashov]

2016-09-13 20:56 GMT+02:00 stepharo :

>
> I was thinking about the code in Pharo.
>
> Plenty of examples:
>
>> - Converting money
>>
>
> can you tell me more about this one?


Probably most known and beautiful case is arithmetic operations. Look at
#adaptToInteger:andSend: and friends.

Re: [Pharo-users] Problem cleaning up image

[Marcus Denker]

> On 13 Sep 2016, at 18:54, Vitor Medina Cruz  wrote:
> 
> I understand. I thought it did more stuff, like remove necessary development 
> tools or executing processes,

It does call #cleanUpForRelease, but this we call at *every* update on the CI, 
too. This calls  the #cleanUp method of all classes
and does some more (rehashing all dictionaries, restarting all? methods holding 
on to blocks…).

> I don't know, but considering its implementation it should affect only the 
> image size, right?
> 
Yes. Of course right now Cog is not compacting the somewhat empty allocated  
memory regions, so e.g. the
47 MB image should be around 15 MB empty space and the cleanup will not shrink 
it.

But when this is fixed, you should see a change. A saved image is too a large 
extend methods and literals they
point to (especially for things like Tutorials). In the past the normal image 
was ca. 25MB, while the shrieked one
after cleanup for deployment maybe 15? I do not remember.

But that was already a bit of “moored law” time ago ;-)

Marcus

Re: [Pharo-users] Problem cleaning up image

[Vitor Medina Cruz]

I understand. I thought it did more stuff, like remove necessary
development tools or executing processes, I don't know, but considering its
implementation it should affect only the image size, right?

Thanks,
Vitor

On Tue, Sep 13, 2016 at 8:30 AM, Marcus Denker 
wrote:

>
> > On 13 Sep 2016, at 13:15, Vitor Medina Cruz 
> wrote:
> >
> > Humm, why not? When I load the configuration it loads several other
> packages, wouldn't that need a cleanup too? When I first see that I could
> cleanup an image my first thought was to put it in a production state with
> my code, then I would cleanup to leave it as lean as possible. Isn't that
> correct?
> >
> > If I should not clean after load my packages why provide the
> functionality? Why not provide clean images to be used in production so
> that people could download and load it's ready to production code?
> >
>
> No, the #cleanUpForProduction just unloads tests, examples and things like
> that… it only touches loaded code in the sense that it
> unloads all packages named -Tests and -Examples.
>
> But if the external package happens to be structured in a way that this is
> bad, it would brake.
>
> I never expected this to be run *after* more packages are loaded, just
> *before*.
>
> What it does right now it this (you can see that it could be simpler if
> our packages are better structured):
>
> cleanUpForProduction
> "self new cleanUpForProduction"
> "delete logo"
> PolymorphSystemSettings showDesktopLogo: false.
>
> self packagesForCleanUpInProduction do: [ :each | (MCPackage
> named: each) unload ].
> self helpPackages do: [ :each | (MCPackage named: each) unload ].
> self testPackages do: [ :each | (MCPackage named: each) unload ].
> self examplePackages do: [ :each | (MCPackage named: each) unload
> ].
> (MCPackage named: 'ScriptLoader40') unload.
>
>
> (MCPackage named: 'MonticelloMocks') unload.
> (MCPackage named: 'ToolsTest') unload.
> (MCPackage named: 'Announcements-Tests-Core') unload.
> (MCPackage named: 'AST-Tests-Core') unload.
> (MCPackage named: 'AST-Interpreter-Test') unload.
> (MCPackage named: 'Ring-Tests-Containers') unload.
> (MCPackage named: 'Ring-Tests-Kernel') unload.
> (MCPackage named: 'Ring-Tests-Monticello') unload.
> (MCPackage named: 'Regex-Tests-Core') unload.
> (MCPackage named: 'Refactoring-Tests-Changes') unload.
> (MCPackage named: 'Refactoring-Tests-Core') unload.
> (MCPackage named: 'Refactoring-Tests-Critics') unload.
> (MCPackage named: 'Refactoring-Tests-Environment') unload.
> (MCPackage named: 'FileSystem-Tests-Core') unload.
> (MCPackage named: 'FileSystem-Tests-Disk') unload.
> (MCPackage named: 'FileSystem-Tests-Memory') unload.
>
> (MCPackage named: 'GT-Tests-Inspector') unload.
> (MCPackage named: 'Glamour-Tests-Core') unload.
> (MCPackage named: 'Glamour-Tests-Morphic') unload.
> (MCPackage named: 'Glamour-Tests-Resources') unload.
> (MCPackage named: 'Glamour-Tests-Rubric') unload.
>
> (MCPackage named: 'Versionner-Core-Model') unload.
> (MCPackage named: 'Versionner-Core-DependenciesModel') unload.
> (MCPackage named: 'Versionner-Core-Announcements') unload.
> (MCPackage named: 'Versionner-Core-Commands') unload.
> (MCPackage named: 'Versionner-Spec-Browser') unload.
> (MCPackage named: 'Versionner-Tests-Core-Commands') unload.
> (MCPackage named: 'Versionner-Tests-Core-DependenciesModel')
> unload.
> (MCPackage named: 'Versionner-Tests-Core-Model') unload.
> (MCPackage named: 'Versionner-Tests-Resources') unload.
>
> self cleanUpForRelease.
>
>
> Marcus
>
>
>

Re: [Pharo-users] [Pharo-dev] [ANN] RProjectConnector V2.1

[Blondeau Vincent]

> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Serge Stinckwich
> Envoyé : vendredi 2 septembre 2016 16:44
> À : Pharo Development List
> Cc : scismallt...@googlegroups.com; Any question about pharo is welcome
> Objet : Re: [Pharo-dev] [ANN] RProjectConnector V2.1
>
> Great job Vincent !
>
It will be great when it will work on OS X ;)

> There is some problems on Mac OS X:
> - when I try to load in a fresh Pharo 5.0 image, I got a DNU on:
> RObjectArray class>>initElementType:
> I was able to load the package after a while by loading directly the package
> with the Monticello Browser

Strange, I deleted these methods... Please ensure you are using a Pharo 6.0 
image (it should work under Pharo 5.0 too) and that version 14 of 
ConfigurationOfRProjectConnector and version 71 of the RConnector packages are 
loaded.

> - Apparently there is still some methods using NB like: RSession
> class>>checkSession or RSession class>>initEmbeddedR:

Should not, it is modified ...

>
> I try to move the R dll close to my Pharo VM and also inside the Plugins
> directory but without success ...

It should be at the same location that libcairo.2.dylib

> Is there a way to say where are the R dll instead of copying them ?
>
Didn't think so .. Maybe the VM developers knows ?


Thanks!

Vincent


> Thank you.
>
>
>
>
> On Thu, Sep 1, 2016 at 5:42 PM, Blondeau Vincent
>  wrote:
> > Hello everyone,
> >
> >
> >
> > I am glad to announce the release of version 2.1 of the RProjectConnector.
> >
> > The binding between Pharo and R (https://www.r-project.org/) is now
> > translated to UFFI and so to Pharo 6.0.
> >
> >
> >
> > You can call directly your R methods from Pharo. For example, with the
> > famous iris clustering example:
> >
> >
> >
> >   iris := 'eval' asREval: {RObject findVar: 'iris'}.
> >
> >   'plot'
> >
> > asREval:
> >
> > {(iris at: 'Petal.Length').
> >
> > (iris at: 'Petal.Width').
> >
> > (#pch -> 21).
> >
> > (#xlab -> 'length').
> >
> > (#ylab -> 'Width').
> >
> > (#bg  ->((iris at: 'Species') collect:
> > [ :value | {'red'. 'green3'. 'blue'} at: value ])).
> >
> > (#main -> 'Edgar Anderson''s Iris Data')}.
> >
> >   iris inspect.
> >
> >
> >
> > To use it, you should install R and copy the R libraries near the
> > Pharo VM (see the documentation on SmalltalkHub
> > (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for
> > how to proceed).
> >
> >
> >
> > Don’t forget to relaunch Pharo after the installation to be able to
> > use the connector.
> >
> >
> >
> > Only basic features are implemented yet, but you can participate to
> > its extension!
> >
> >
> >
> > Cheers,
> >
> > Vincent Blondeau
> >
> >
> >
> !!!
> ***
> > ** "Ce message et les pièces jointes sont
> > confidentiels et réservés à l'usage exclusif de ses destinataires. Il
> > peut également être protégé par le secret professionnel. Si vous
> > recevez ce message par erreur, merci d'en avertir immédiatement
> > l'expéditeur et de le détruire. L'intégrité du message ne pouvant être
> > assurée sur Internet, la responsabilité de Worldline ne pourra être
> > recherchée quant au contenu de ce message. Bien que les meilleurs
> > efforts soient faits pour maintenir cette transmission exempte de tout
> > virus, l'expéditeur ne donne aucune garantie à cet égard et sa
> > responsabilité ne saurait être recherchée pour tout dommage résultant
> > d'un virus transmis.
> >
> > This e-mail and the documents attached are confidential and intended
> > solely for the addressee; it may also be privileged. If you receive
> > this e-mail in error, please notify the sender immediately and destroy
> > it. As its integrity cannot be secured on the Internet, the Worldline
> > liability cannot be triggered for the message content. Although the
> > sender endeavours to maintain a computer virus-free network, the
> > sender does not warrant that this transmission is virus-free and will
> > not be liable for any damages resulting from any virus transmitted.!!!"
>
>
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/


!!!*
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant a

Re: [Pharo-users] double dispatch example

[Alexandre Bergel]

Hi Stef!

Plenty of examples:

- Converting money
- Paper, Stone, Scissor
- A canvas containing triangle, circle, box has to be printed, on an html 
canvas or PDF. (Very close to the Visitor design pattern, but simpler)

Here are the lectures I use:
https://dl.dropboxusercontent.com/u/31543901/TMP/DoubleDispatch.zip

(One of them is highly inspired from a lecture from Oscar)

Hope it helps!

Cheers,
Alexandre

> On Sep 13, 2016, at 7:33 AM, stepharo  wrote:
> 
> Hi
> 
> If you happen to know a double dispatch situation in Pharo, I'm interested 
> since I'm revisiting my lecture.
> 
> 
> Stef
> 
> 

Re: [Pharo-users] Problem cleaning up image

[Marcus Denker]

> On 13 Sep 2016, at 13:15, Vitor Medina Cruz  wrote:
> 
> Humm, why not? When I load the configuration it loads several other packages, 
> wouldn't that need a cleanup too? When I first see that I could cleanup an 
> image my first thought was to put it in a production state with my code, then 
> I would cleanup to leave it as lean as possible. Isn't that correct? 
> 
> If I should not clean after load my packages why provide the functionality? 
> Why not provide clean images to be used in production so that people could 
> download and load it's ready to production code?
> 

No, the #cleanUpForProduction just unloads tests, examples and things like 
that… it only touches loaded code in the sense that it
unloads all packages named -Tests and -Examples.

But if the external package happens to be structured in a way that this is bad, 
it would brake.

I never expected this to be run *after* more packages are loaded, just 
*before*. 

What it does right now it this (you can see that it could be simpler if our 
packages are better structured):

cleanUpForProduction
"self new cleanUpForProduction"
"delete logo"   
PolymorphSystemSettings showDesktopLogo: false.

self packagesForCleanUpInProduction do: [ :each | (MCPackage named: 
each) unload ]. 
self helpPackages do: [ :each | (MCPackage named: each) unload ].   
self testPackages do: [ :each | (MCPackage named: each) unload ].
self examplePackages do: [ :each | (MCPackage named: each) unload ].
(MCPackage named: 'ScriptLoader40') unload. 


(MCPackage named: 'MonticelloMocks') unload.
(MCPackage named: 'ToolsTest') unload.  
(MCPackage named: 'Announcements-Tests-Core') unload.   
(MCPackage named: 'AST-Tests-Core') unload. 
(MCPackage named: 'AST-Interpreter-Test') unload.   
(MCPackage named: 'Ring-Tests-Containers') unload.  
(MCPackage named: 'Ring-Tests-Kernel') unload.  
(MCPackage named: 'Ring-Tests-Monticello') unload.  
(MCPackage named: 'Regex-Tests-Core') unload.   
(MCPackage named: 'Refactoring-Tests-Changes') unload.  
(MCPackage named: 'Refactoring-Tests-Core') unload. 
(MCPackage named: 'Refactoring-Tests-Critics') unload.  
(MCPackage named: 'Refactoring-Tests-Environment') unload.  
(MCPackage named: 'FileSystem-Tests-Core') unload.  
(MCPackage named: 'FileSystem-Tests-Disk') unload.  
(MCPackage named: 'FileSystem-Tests-Memory') unload.

(MCPackage named: 'GT-Tests-Inspector') unload. 
(MCPackage named: 'Glamour-Tests-Core') unload. 
(MCPackage named: 'Glamour-Tests-Morphic') unload.  
(MCPackage named: 'Glamour-Tests-Resources') unload.
(MCPackage named: 'Glamour-Tests-Rubric') unload.   

(MCPackage named: 'Versionner-Core-Model') unload.
(MCPackage named: 'Versionner-Core-DependenciesModel') unload.  
(MCPackage named: 'Versionner-Core-Announcements') unload.  
(MCPackage named: 'Versionner-Core-Commands') unload.   
(MCPackage named: 'Versionner-Spec-Browser') unload.

(MCPackage named: 'Versionner-Tests-Core-Commands') unload. 
(MCPackage named: 'Versionner-Tests-Core-DependenciesModel') unload.
(MCPackage named: 'Versionner-Tests-Core-Model') unload.

(MCPackage named: 'Versionner-Tests-Resources') unload. 


self cleanUpForRelease.


Marcus

Re: [Pharo-users] Problem cleaning up image

[Vitor Medina Cruz]

Humm, why not? When I load the configuration it loads several other
packages, wouldn't that need a cleanup too? When I first see that I could
cleanup an image my first thought was to put it in a production state with
my code, then I would cleanup to leave it as lean as possible. Isn't that
correct?

If I should not clean after load my packages why provide the functionality?
Why not provide clean images to be used in production so that people could
download and load it's ready to production code?

Regards,
Vitor

On Tue, Sep 13, 2016 at 4:00 AM, Marcus Denker 
wrote:

> Hi,
>
> I think it is not really realistic to expect this to work *after* loading
> code of others.
>
> Why not
>
> -> do image clean
> -> *then* load the packages you need?
>
> Marcus
>
> On 13 Sep 2016, at 03:19, Vitor Medina Cruz  wrote:
>
> Ok, I did some extra tests and I think I figured what is happening: the
> code I load on the image subject to clean has a startUp method that starts
> a Teapot server on port 8080. I tried various scenarios:
>
> 1- Load a fresh image from get.pharo.org and execute clean --> Ok
> 2- Load a fresh image from get.pharo.org only with the dependencies from
> my project (ConfigurationOfTwitterChallenge), one at a time, and execute
> clean --> Ok
> 3- Load a fresh image from get.pharo.org, apply
> ConfigurationOfTwitterChallenge and execute clean --> Fail
> 4- Load a fresh image from get.pharo.org, apply
> ConfigurationOfTwitterChallenge and execute eval "TwitterChallengeMain
> stopDefaultExecution. ImageCleaner cleanUpForProduction. Smalltalk
> snapshot: true andQuit: true." --> *Ok *(Assuming  ImageCleaner
> cleanUpForProduction. Smalltalk snapshot: true andQuit: true. does the same
> as clean --production)
>
> It appears I cannot clean an Image with the server started. Question: is
> that an error or I really should not try to clean an image with a server
> on? If the former I open an issue on FogBuz and I will try on a
> not-headless vm to see if some error happen.
>
> Regards,
> Vitor
>
>
>
> On Mon, Sep 12, 2016 at 6:59 AM, stepharo  wrote:
>
>> Ok may be this is just an endless loop :)
>>
>>
>>
>> Le 12/9/16 à 10:22, Marcus Denker a écrit :
>>
>> Hello,
>>
>> Yes, this is a bug that we really need to fix.
>> (sadly no information to add other thant that).
>>
>> On 09 Sep 2016, at 15:16, Vitor Medina Cruz  wrote:
>>
>> Hello,
>>
>> Isn't cleanup the headless image working right now? I know it has some
>> problems, but I tried to:
>>
>> curl get.pharo.org | bash
>> ./pharo Pharo.image clean --production
>>
>> It runs for hours and don't complete. Last time I leave it for about 5
>> hours before I cancelled.
>>
>> Regards,
>> Vitor
>>
>>
>>
>>
>
>

[Pharo-users] double dispatch example

[stepharo]

Hi

If you happen to know a double dispatch situation in Pharo, I'm 
interested since I'm revisiting my lecture.



Stef

Re: [Pharo-users] Iceberg and git workflow

[Nicolas Passerini]

Hi Holger, I think that both patterns are currently supported (in beta
version), but maybe we do not use exactly the same tools.

First, Iceberg does not use the concept of "stash". The git stash changes
the file in your git working copy (on your file system), while your
(modified) code is not there, is in the Pharo image.

Going deeper into it, we understand git is very powerful but we do not
believe that git is the ultimate perfect code versioning tool. We think
that there are some git usage patterns that tend to be difficult to
understand so we are trying to create a better abstraction on top of that.
Also we would like to come up with an abstraction that works not only for
git but for other repositories.

So, we try to support the kind of requirements you are worried about, but
maybe not in the same way that the command line tools you are used to. I
also have been working with git in languages like Scala, Javascript, Xtend,
etc and I was used to the command line tools... so now the task for me is
to try to understand: which of all those things I was used to do were
really necessary and which of them are just boilerplate I need to do
because of my tools are too low level?

Maybe your experience can help us answer that question.


> a.) If current HEAD is same as origin/master
>
> $ git stash (stash away my not finished changes)
> $ vi code.c fix..
> $ git commit -a -c "subject
>
> long explanation of fix
> reference to bug"
> $ git stash apply (and go back to working on my feature)
>
>
So, why is this better than having a new image with a clean version of HEAD?


> b.) E.g. if I finished n-commits but I am not fully done
>

For this I would propose a slightly different pattern:

>
> # store my work
> $ git commit -a -m "Work In Progress hack.."
>

You can commit, ok... but also you could just save the image with your work
in progress, no need to create a hacky commit.


> $ git checkout -b new-feature-branch
>
> # go back to master
> $ git checkout master
> $ git reset --hard origin/master (to restore)
>

To avoid reset, I would propose to leave master like that and put the new
work in a clean branch, starting on origin/master.

In git-command-line language it would be:
git checkout -b fix origin/master

So you create a new branch for your fix out of origin/master, leaving the
original branch untouched.


>
> # work on the fix
> $ vi code.c fix..
> $ git commit -a -c "fix..."
>
> No problems here... just we do not use vi for editing code :)


> # go back and continue on my fix
> $ git checkout new-feature-branch
>
$ git rebase origin/master
> $ git reset HEAD^1
> .. continue to work
>
>  Several things here. First, I think that everything is simpler if you
just leave your original branch untouched, so you could re-checkout that
branch without the need for reset and removing hacky commits. But even more
interesting if you agree to have two images one for each task, you just go
back to your first image and everything is just like you left it, including
open windows and whatever task you were doing. I think that is a beautiful
value of Pharo I would not like to loose.

The only thing left would be to incorporate the fix into this image, right
now we do not support rebase, you would need to merge... but I understand
why one would prefer rebase in this scenario, at some point we will support
both options.


So, to sum up. I am not trying to replicate in Pharo the way I used to work
in Javascript... I think that would be silly. Instead, we are trying to
take the good stuff of git into Pharo, but without loosing all the good
stuff of Pharo.

Re: [Pharo-users] Problem cleaning up image

[Marcus Denker]

Hi,

I think it is not really realistic to expect this to work *after* loading code 
of others.

Why not 

-> do image clean
-> *then* load the packages you need?

Marcus

> On 13 Sep 2016, at 03:19, Vitor Medina Cruz  wrote:
> 
> Ok, I did some extra tests and I think I figured what is happening: the code 
> I load on the image subject to clean has a startUp method that starts a 
> Teapot server on port 8080. I tried various scenarios:
> 
> 1- Load a fresh image from get.pharo.org  and execute 
> clean --> Ok
> 2- Load a fresh image from get.pharo.org  only with 
> the dependencies from my project (ConfigurationOfTwitterChallenge), one at a 
> time, and execute clean --> Ok
> 3- Load a fresh image from get.pharo.org , apply 
> ConfigurationOfTwitterChallenge and execute clean --> Fail
> 4- Load a fresh image from get.pharo.org , apply 
> ConfigurationOfTwitterChallenge and execute eval "TwitterChallengeMain 
> stopDefaultExecution. ImageCleaner cleanUpForProduction. Smalltalk snapshot: 
> true andQuit: true." --> Ok (Assuming  ImageCleaner cleanUpForProduction. 
> Smalltalk snapshot: true andQuit: true. does the same as clean --production)
> 
> It appears I cannot clean an Image with the server started. Question: is that 
> an error or I really should not try to clean an image with a server on? If 
> the former I open an issue on FogBuz and I will try on a not-headless vm to 
> see if some error happen.
> 
> Regards,
> Vitor
> 
> 
> 
> On Mon, Sep 12, 2016 at 6:59 AM, stepharo  > wrote:
> Ok may be this is just an endless loop :)
> 
> 
> 
> Le 12/9/16 à 10:22, Marcus Denker a écrit :
>> Hello,
>> 
>> Yes, this is a bug that we really need to fix.
>> (sadly no information to add other thant that).
>> 
>>> On 09 Sep 2016, at 15:16, Vitor Medina Cruz >> > wrote:
>>> 
>>> Hello,
>>> 
>>> Isn't cleanup the headless image working right now? I know it has some 
>>> problems, but I tried to:
>>> 
>>> curl get.pharo.org  | bash 
>>> ./pharo Pharo.image clean --production
>>> 
>>> It runs for hours and don't complete. Last time I leave it for about 5 
>>> hours before I cancelled.
>>> 
>>> Regards,
>>> Vitor
>> 
> 
> 

Re: [Pharo-users] Seaside not installing

[stepharo]

thanks for the alarm and tx esteban for the fix.


Le 13/9/16 à 08:58, Hersh Krishna via Pharo-users a écrit :