Re: [Pharo-dev] Launcher and Pharo 6.1

[Sean P. DeNigris]

EstebanLM wrote
> it is safe. 6.1

Great. Thanks, guys. I downloaded a new vm via `curl get.pharo.org/vm61 |
bash` and it seems to be working fine with 6.0 images.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Launcher-and-Pharo-6-1-tp4957770p4958036.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Segmentation fault Pharo 6.1 64bit vm - Ubuntu Linux - loading Metacello dependency

[Tim Mackinnon]

Hi - I just got a seg fault on my Gitlab CI server when trying to load a 
metacello baseline via the st command line hander.


$ ./pharo Pharo.image --no-default-preferences --save --quit st loadLocal.st 
config.st "{'$AWS_ACCESS_KEY_ID'. '$AWS_SECRET_ACCESS_KEY'. 
'$AWS_DEFAULT_REGION'. '$S3_BUCKET'}" |& tee LoadLocal.log

Fetched -> BaselineOfLambda-cypress.1 --- 
filetree:///builds/macta/PharoLambda/src [:] --- 
filetree:///builds/macta/PharoLambda/src
Loaded -> BaselineOfLambda-cypress.1 --- 
filetree:///builds/macta/PharoLambda/src [:] --- 
filetree:///builds/macta/PharoLambda/src
Loading baseline of BaselineOfLambda...
Fetched -> BaselineOfAWS-ShoYoshida.12 --- 
github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository [9149805:v1.10] 
--- github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository
Loaded -> BaselineOfAWS-ShoYoshida.12 --- 
github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository [9149805:v1.10] 
--- github://newapplesho/aws-sdk-smalltalk:v1.10/pharo-repository
Fetched -> ConfigurationOfZTimestamp-SvenVanCaekenberghe.25 --- 
http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo
Loaded -> ConfigurationOfZTimestamp-SvenVanCaekenberghe.25 --- 
http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo
Project: ZTimestamp stable [20]
Fetched -> ZTimestamp-SvenVanCaekenberghe.57 --- http://mc.stfx.eu/Neo --- 
http://mc.stfx.eu/Neo
Project: AWS baseline
Segmentation fault Mon Jul 31 22:18:27 2017


/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942/pharo
Pharo VM version: 5.0-201707201942  Thu Jul 20 20:42:13 UTC 2017 gcc 4.6.3 
[Production Spur 64-bit ITHB VM]
Built from: CoInterpreter VMMaker.oscog-eem.2254 uuid: 
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
Revision: VM: 201707201942 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 
12:42:21 2017 -0700 $ Plugins: 201707201942 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Build host: Linux testing-gce-2c303f4c-2b90-4f17-b8b9-ec690d977073 
3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
plugin path: 
/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942 [default: 
/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942/]


C stack backtrace & registers:
rax 0xa41278c0 rbx 0xa4127750 rcx 0xa4127978 rdx 0xa4127808
rdi 0xa4127528 rsi 0xa4127528 rbp 0xa4127698 rsp 0xa4127a30
r8  0xa4126f68 r9  0xa4127020 r10 0xa41270d8 r11 0xa4127190
r12 0xa4127248 r13 0xa4127300 r14 0xa41273b8 r15 0xa4127470
rip 0xa4127ae8
*[0x7fffa4127ae8]
/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x41cd91]
/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x41d11f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11670)[0x7efe11ad9670]
/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x43645f]
/builds/macta/PharoLambda/build/pharo-vm/lib/pharo/5.0-201707201942/pharo(ceBaseFrameReturn+0xc1)[0x45bec1]
[0x260124e]
[0x0]


Smalltalk stack dump:

Most recent primitives
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
compare:with:collated:
stringHash:initialHash:
stringHash:initialHash:
basicAtLeast:
basicAtLeast:
new:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
stringHash:initialHash:
compare:with:collated:
stringHash:initialHash:

Re: [Pharo-dev] Calypso browser and categories?

[Mariano Martinez Peck]

On Mon, Jul 31, 2017 at 6:15 PM, Denis Kudriashov 
wrote:

> Hi Mariano.
>
> You right. Method for this was implemented but I forgot to use it in
> #selectClass: logic.
> I committed fix to dev branch. I will realze new version soon.
>
>
OK, great. Let me know when you want me to test it. I am glad it was a
"bug". I thought it might have been some "decision".


> But I am not sure that it is only issue you are talking about.
>

Yeah, I figured I can see it elsewhere. But I will find them if there are
other places...


BTW, I also found some other small issues which I comment below. Do you
want me to open issues on github for them?

* "Windows" -> "Delete all windows discarding edits" -> does not close
Calypso windows with none saved edits
* When I have a class opened, with a method opened, then I go to the class
comment tab and I save the class comment, calypso automatically gives me
focus
back to the "method tab" rather than staying in the class comment. This is
annoying as i like to save my class comment frequently and not they flip to
another tab.
* I wish the "new protocol" offers me the existing ones as I type...as I
normally re-use existing protocols (on purpose) and its easy to make small
typos or differences with the original ones.

Thoughts?

Thanks!


>
> 2017-07-31 18:25 GMT+02:00 Mariano Martinez Peck :
>
>> Hi Denis,
>>
>> I wanted to give a serious test to Calypso, that is, start using it all
>> day long. However, there is a critical thing I am missing, which is the
>> grouping of categories (inside packages).
>>
>> I do not want to start discussing again packages vs categories and what
>> are good and bad practices. I do have a few packages and each package may
>> have several categories inside. So... seeing all classes together inside a
>> package is not nice for me.
>>
>> Is there a way in calypso to auto-escope to category level? I mean... say
>> my package is XXX and I have categories XXX-A and XXX-B. I know I can go to
>> left side column and with the tree, I can go to XXX-A and I get what I
>> want. But, for example, when I browse a class of XXX-A, the "focus" of the
>> left side column is XXX and not XXX-A.  So I am wondering if we can make it
>> auto-scope to the category everywhere in Calypso.
>>
>> Thanks in advance,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Calypso browser and categories?

[Denis Kudriashov]

Hi Mariano.

You right. Method for this was implemented but I forgot to use it in
#selectClass: logic.
I committed fix to dev branch. I will realze new version soon.

But I am not sure that it is only issue you are talking about.

2017-07-31 18:25 GMT+02:00 Mariano Martinez Peck :

> Hi Denis,
>
> I wanted to give a serious test to Calypso, that is, start using it all
> day long. However, there is a critical thing I am missing, which is the
> grouping of categories (inside packages).
>
> I do not want to start discussing again packages vs categories and what
> are good and bad practices. I do have a few packages and each package may
> have several categories inside. So... seeing all classes together inside a
> package is not nice for me.
>
> Is there a way in calypso to auto-escope to category level? I mean... say
> my package is XXX and I have categories XXX-A and XXX-B. I know I can go to
> left side column and with the tree, I can go to XXX-A and I get what I
> want. But, for example, when I browse a class of XXX-A, the "focus" of the
> left side column is XXX and not XXX-A.  So I am wondering if we can make it
> auto-scope to the category everywhere in Calypso.
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-dev] Catalog down

[Esteban Lorenzano]

It will be restarted at midnight 

> On 31 Jul 2017, at 19:51, Torsten Bergmann  wrote:
> 
> http://catalog.pharo.org/catalog/json responds with "Service Temporarily 
> Unavailable".
> Sabine already reported it this morning on Discord.
> 
> Any idea?
> 
> 

[Pharo-dev] Catalog down

[Torsten Bergmann]

http://catalog.pharo.org/catalog/json responds with "Service Temporarily 
Unavailable".
Sabine already reported it this morning on Discord.

Any idea?

[Pharo-dev] Calypso browser and categories?

[Mariano Martinez Peck]

Hi Denis,

I wanted to give a serious test to Calypso, that is, start using it all day
long. However, there is a critical thing I am missing, which is the
grouping of categories (inside packages).

I do not want to start discussing again packages vs categories and what are
good and bad practices. I do have a few packages and each package may have
several categories inside. So... seeing all classes together inside a
package is not nice for me.

Is there a way in calypso to auto-escope to category level? I mean... say
my package is XXX and I have categories XXX-A and XXX-B. I know I can go to
left side column and with the tree, I can go to XXX-A and I get what I
want. But, for example, when I browse a class of XXX-A, the "focus" of the
left side column is XXX and not XXX-A.  So I am wondering if we can make it
auto-scope to the category everywhere in Calypso.

Thanks in advance,

-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] [ANN] Mustache moved to github

[Ben Coman]

I found this useful to clarify my understanding of git...
https://git-scm.com/book/en/v1/Git-Internals

cheers -ben

On Mon, Jul 31, 2017 at 5:31 PM, Tim Mackinnon  wrote:

> So I’m still puzzled why what I have said is incorrect - tag on master,
> update your repository url to include that tag with “:tagname” and then
> users will get that stable version when they load your baseline (vs.
> Leaving it off and they get whatever you might have in progress on master.
> And sure - you might develop on a branch and get it all perfect first and
> then merge to master - but I still think it is good idea to tag the point
> you are happy with and then update your baselineOf again?)
>
> Peter seems to be implying there is a different (better?) way to do this -
> and I’m wondering if I’m missing something obvious or whether we are all
> saying the same thing (me rather badly it seems)
>
> Tim
>
> On 31 Jul 2017, at 10:18, Alistair Grant  wrote:
>
> Hi Tim,
>
> Perhaps a different way of phrasing it that might help is that tags are
> global, not per branch.
>
> Checking out a commit, whether by id, tag, or Branch name implies the
> entire tree.
>
> Cheers,
> Alistair
>
>
> On 31 Jul. 2017 11:09 am, "Tim Mackinnon"  wrote:
>
> Hi Peter - I am confused now, I’ve always understood that git tags are
> used to mark important points in history. From the Git online manual - "
> Tagging
>
> Like most VCSs, Git has the ability to tag specific points in history as
> being important. Typically people use this functionality to mark release
> points (v1.0, and so on). In this section, you’ll learn how to list the
> available tags, how to create new tags, and what the different types of
> tags are.
> “
>
> So I’ve always understood that by putting a tag on a commit, I was getting
> a snapshot of the whole graph at that point in time? Thus - by specifying
> the “:tag name” on the baseline url, you were getting that version?
>
> Thinking a bit more, I guess if you want to to actually make some changes
> from that tag point - you do need to create a -b branch from it (otherwise
> you have a detached head right?) - is this what you are getting at?
>
> Or is there a more obvious thing I am missing that lets you point to a
> particular version in GIT? I appreciate your insight into this, as I think
> we all need to learn how to do this properly.
>
> Tim
>
> On 31 Jul 2017, at 08:17, Peter Uhnak  wrote:
>
> Nono, I don't think you fully understand git's versioning.
>
> To oversimplify: git's history is composed of commits and parental
> relationships between them. Nothing more, nothing less; it is just a
> directed acyclic graph.
>
> On top of this graph structure you have additional stuff like branches,
> which are just labels atteched to the commits, and also tags, which are
> also just labels.
>
> So when you tag a commit, it doesn't really matter what branch it was on,
> you've simply said that tag 1.0 points to a particular commit XX in the
> history; that commit could belong to master branch, or development branch,
> or any other branch (or no named branch at all, also known as detached
> head).
>
> In another words, your tag points to a commit only, and branches do not
> play any role in this whatsoever.
>
> Am I being clear? (I'm sipping my morning coffee so my brain is not fully
> operational yet ;) )
>
> Peter
>
>
> On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote:
>
> Peter - I meant it as a figurative example - on a master branch you can
> tag whenever you want right? And so you can point users to a specific tag
> on master so they have a stable point to load from (possibly while you
> merge a branch back to master and then update any documentation or config
> before retagging and updating a BaselineOf?
>
> This looks like what the AWS Smalltalk git repo has used as an example.
>
> Tim
>
> (Ps
> Apologies for the "rage" iOS autocorrect - apparently that's what Apple
> thinks tags is corrected to ;)
>
> Sent from my iPhone
>
>
>
> Sent from my iPhone
> On 30 Jul 2017, at 16:35, Peter Uhnak  wrote:
>
>
> If I've understood correctly, this means you can rage master with a
> version number like v1.1 and then put that in the URL
>
> https://github.com/peteruhnak/IconFactory/tree/master:v1.1/
>
>
> I am not sure where you got this url from, but combining branch and tag
> name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or
> whatever would be the latest in master).
>
> (as mentioned in the syntax: branch name OR commit id OR tag id)
>
> Peter
>
>
>
>
>
>
>
>

[Pharo-dev] Referencing Git tags/branchs/commits [Hijacked: Re: [ANN] Mustache moved to github]

[Peter Uhnak]

> I’ve always understood that git tags are used to mark important points in 
> history

Correct (mark=label)

> putting a tag on a commit, I was getting a snapshot of the whole graph

No, there's no need to perform a snapshot of the whole graph.

Commit id (the 40-bit SHA of a commit) is computed from various properties 
including the content of the commit and the parents, therefore if a single bit 
would have changed in the content, then the ID would be different.

Thus you don't need to perform a whole snapshot (that would be git clone 
--depth=1), because knowing just the ID is enough to identify the version, 
content, and ancestry.

Without anything else, you would work only with the SHA numbers... checking out 
XX, merging  to , etc.
As this is very annoying, you have several concepts to help you

* lightweight tag --- this is literally just a text file in 
.git/refs/tags/tag-name that has the ID of the pointed-to commit
* annotated tag --- stored again in `.git/refs/tags/tag-name`, but instead it 
points to an intermediate file that contains info about the person creating the 
tag, the tag message, etc, but not the tag content; instead the intermediate 
file again points to a commit ID (you can look at the content of the 
intermediate file in .git/objects (git cat-file to read it)
* branch is a kind of a "moving tag"; in e.g. `.git/refs/heads/master` you 
would see the ID of the latest commit (just like a lightweight tag)

So branch is in reality just the tip of the branch (the head of it), and the 
previous commits do not really belong to any branch. (You can see this when you 
merge a branch and then delete the merged branch... the commits are still 
there, only the label was removed.). So it would be as if you deleted a tag and 
created it again after each commit.

> So I’ve always understood that by putting a tag on a commit, I was getting a 
> snapshot of the whole graph at that point in time? Thus - by specifying the 
> “:tag name” on the baseline url, you were getting that version?

tags and branches are just labels; you could directly use : in the 
baseline with the same effect
 
> Thinking a bit more, I guess if you want to to actually make some changes 
> from that tag point - you do need to create a -b branch from it (otherwise 
> you have a detached head right?) - is this what you are getting at?

you don't need a branch, you can just carry on from the "detached" head

> Or is there a more obvious thing I am missing that lets you point to a 
> particular version in GIT?

Yes, you can just say, I want code as it was in version .


To summarize:
* the commit graph representation has no notion of branches or tags
* you can use commit sha instead of tags/branchs
* tags are just references to particular commits
* branches are just like tags, only the reference changes after each commit
* the data representation is very simple and straight-forward, and you can 
easily view it by hand (from terminal with git cat-file) in the .git folder

Peter

(am I making it more clear or more obscure? :-D)

Re: [Pharo-dev] [ANN] Mustache moved to github

[Tim Mackinnon]

So I’m still puzzled why what I have said is incorrect - tag on master, update 
your repository url to include that tag with “:tagname” and then users will get 
that stable version when they load your baseline (vs. Leaving it off and they 
get whatever you might have in progress on master. And sure - you might develop 
on a branch and get it all perfect first and then merge to master - but I still 
think it is good idea to tag the point you are happy with and then update your 
baselineOf again?)

Peter seems to be implying there is a different (better?) way to do this - and 
I’m wondering if I’m missing something obvious or whether we are all saying the 
same thing (me rather badly it seems)

Tim

> On 31 Jul 2017, at 10:18, Alistair Grant  wrote:
> 
> Hi Tim,
> 
> Perhaps a different way of phrasing it that might help is that tags are 
> global, not per branch.
> 
> Checking out a commit, whether by id, tag, or Branch name implies the entire 
> tree.
> 
> Cheers,
> Alistair
> 
> 
> On 31 Jul. 2017 11:09 am, "Tim Mackinnon"  wrote:
> Hi Peter - I am confused now, I’ve always understood that git tags are used 
> to mark important points in history. From the Git online manual - "
> Tagging
> Like most VCSs, Git has the ability to tag specific points in history as 
> being important. Typically people use this functionality to mark release 
> points (v1.0, and so on). In this section, you’ll learn how to list the 
> available tags, how to create new tags, and what the different types of tags 
> are.
> 
> “
> 
> So I’ve always understood that by putting a tag on a commit, I was getting a 
> snapshot of the whole graph at that point in time? Thus - by specifying the 
> “:tag name” on the baseline url, you were getting that version?
> 
> Thinking a bit more, I guess if you want to to actually make some changes 
> from that tag point - you do need to create a -b branch from it (otherwise 
> you have a detached head right?) - is this what you are getting at?
> 
> Or is there a more obvious thing I am missing that lets you point to a 
> particular version in GIT? I appreciate your insight into this, as I think we 
> all need to learn how to do this properly.
> 
> Tim
> 
>> On 31 Jul 2017, at 08:17, Peter Uhnak > > wrote:
>> 
>> Nono, I don't think you fully understand git's versioning.
>> 
>> To oversimplify: git's history is composed of commits and parental 
>> relationships between them. Nothing more, nothing less; it is just a 
>> directed acyclic graph.
>> 
>> On top of this graph structure you have additional stuff like branches, 
>> which are just labels atteched to the commits, and also tags, which are also 
>> just labels.
>> 
>> So when you tag a commit, it doesn't really matter what branch it was on, 
>> you've simply said that tag 1.0 points to a particular commit XX in the 
>> history; that commit could belong to master branch, or development branch, 
>> or any other branch (or no named branch at all, also known as detached head).
>> 
>> In another words, your tag points to a commit only, and branches do not play 
>> any role in this whatsoever.
>> 
>> Am I being clear? (I'm sipping my morning coffee so my brain is not fully 
>> operational yet ;) )
>> 
>> Peter
>> 
>> 
>> On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote:
>>> Peter - I meant it as a figurative example - on a master branch you can tag 
>>> whenever you want right? And so you can point users to a specific tag on 
>>> master so they have a stable point to load from (possibly while you merge a 
>>> branch back to master and then update any documentation or config before 
>>> retagging and updating a BaselineOf?
>>> 
>>> This looks like what the AWS Smalltalk git repo has used as an example.
>>> 
>>> Tim
>>> 
>>> (Ps
>>> Apologies for the "rage" iOS autocorrect - apparently that's what Apple 
>>> thinks tags is corrected to ;)
>>> 
>>> Sent from my iPhone
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On 30 Jul 2017, at 16:35, Peter Uhnak >> > wrote:
>>> 
> 
> If I've understood correctly, this means you can rage master with a 
> version number like v1.1 and then put that in the URL
> 
>> https://github.com/peteruhnak/IconFactory/tree/master:v1.1/ 
>> 
 
 I am not sure where you got this url from, but combining branch and tag 
 name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or 
 whatever would be the latest in master).
 
 (as mentioned in the syntax: branch name OR commit id OR tag id)
 
 Peter
 
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-dev] [ANN] Mustache moved to github

[Tim Mackinnon]

Hi Peter - I am confused now, I’ve always understood that git tags are used to 
mark important points in history. From the Git online manual - "
Tagging
Like most VCSs, Git has the ability to tag specific points in history as being 
important. Typically people use this functionality to mark release points 
(v1.0, and so on). In this section, you’ll learn how to list the available 
tags, how to create new tags, and what the different types of tags are.

“

So I’ve always understood that by putting a tag on a commit, I was getting a 
snapshot of the whole graph at that point in time? Thus - by specifying the 
“:tag name” on the baseline url, you were getting that version?

Thinking a bit more, I guess if you want to to actually make some changes from 
that tag point - you do need to create a -b branch from it (otherwise you have 
a detached head right?) - is this what you are getting at?

Or is there a more obvious thing I am missing that lets you point to a 
particular version in GIT? I appreciate your insight into this, as I think we 
all need to learn how to do this properly.

Tim

> On 31 Jul 2017, at 08:17, Peter Uhnak  wrote:
> 
> Nono, I don't think you fully understand git's versioning.
> 
> To oversimplify: git's history is composed of commits and parental 
> relationships between them. Nothing more, nothing less; it is just a directed 
> acyclic graph.
> 
> On top of this graph structure you have additional stuff like branches, which 
> are just labels atteched to the commits, and also tags, which are also just 
> labels.
> 
> So when you tag a commit, it doesn't really matter what branch it was on, 
> you've simply said that tag 1.0 points to a particular commit XX in the 
> history; that commit could belong to master branch, or development branch, or 
> any other branch (or no named branch at all, also known as detached head).
> 
> In another words, your tag points to a commit only, and branches do not play 
> any role in this whatsoever.
> 
> Am I being clear? (I'm sipping my morning coffee so my brain is not fully 
> operational yet ;) )
> 
> Peter
> 
> 
> On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote:
>> Peter - I meant it as a figurative example - on a master branch you can tag 
>> whenever you want right? And so you can point users to a specific tag on 
>> master so they have a stable point to load from (possibly while you merge a 
>> branch back to master and then update any documentation or config before 
>> retagging and updating a BaselineOf?
>> 
>> This looks like what the AWS Smalltalk git repo has used as an example.
>> 
>> Tim
>> 
>> (Ps
>> Apologies for the "rage" iOS autocorrect - apparently that's what Apple 
>> thinks tags is corrected to ;)
>> 
>> Sent from my iPhone
>> 
>> 
>> 
>> Sent from my iPhone
>> On 30 Jul 2017, at 16:35, Peter Uhnak  wrote:
>> 
 
 If I've understood correctly, this means you can rage master with a 
 version number like v1.1 and then put that in the URL
 
> https://github.com/peteruhnak/IconFactory/tree/master:v1.1/
>>> 
>>> I am not sure where you got this url from, but combining branch and tag 
>>> name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or 
>>> whatever would be the latest in master).
>>> 
>>> (as mentioned in the syntax: branch name OR commit id OR tag id)
>>> 
>>> Peter
>>> 
>> 
>> 
> 

Re: [Pharo-dev] [ANN] Mustache moved to github

[Peter Uhnak]

* you can have metadata-less filetree and metadata-full(?) filetree
* metadata are version information like the author name, versions of 
packages, parent versions, etc.
* metadata-less do not store such information as it is assumed that the 
information is stored elsewhere (e.g. in git history)
* gitfiletree is just a filetree format, which in addition performs git commits 
of the exported files via shell execution of Git executable
* gitfiletree can operate both in metadata, and metadata-less mode (the latter 
is preferable, otherwise you'll have an endless barrage of merge conflicts)
* iceberg is metadata-less filetree only, and performs git commits using libgit

So yes, the format is the same and you can even use gitfiletree and iceberg at 
the same time from e.g. different images.

Peter


On Sun, Jul 30, 2017 at 12:11:48PM -0300, Esteban A. Maringolo wrote:
> Hi all
> 
> Sorry to Norbert for hijacking this post, but I'd also like to move
> some of my projects to Github, I used Peter's scripts in the past, but
> one thing I don't understand is how to automatically convert a
> ConfigurationOf to a BaselineOf, and if this is really necessary.
> 
> Is the FileTree format, as used by filetree and gitfiletree MC repos,
> 100% compatible with the repository format of Iceberg? It seems so to
> me, but it's better to ask than be sorry.
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 
> 2017-07-30 11:35 GMT-03:00 Peter Uhnak :
> >>
> >> If I've understood correctly, this means you can rage master with a 
> >> version number like v1.1 and then put that in the URL
> >>
> >> > https://github.com/peteruhnak/IconFactory/tree/master:v1.1/
> >>
> >
> > I am not sure where you got this url from, but combining branch and tag 
> > name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or 
> > whatever would be the latest in master).
> >
> > (as mentioned in the syntax: branch name OR commit id OR tag id)
> >
> > Peter
> >
> 

Re: [Pharo-dev] [ANN] Mustache moved to github

[Peter Uhnak]

Nono, I don't think you fully understand git's versioning.

To oversimplify: git's history is composed of commits and parental 
relationships between them. Nothing more, nothing less; it is just a directed 
acyclic graph.

On top of this graph structure you have additional stuff like branches, which 
are just labels atteched to the commits, and also tags, which are also just 
labels.

So when you tag a commit, it doesn't really matter what branch it was on, 
you've simply said that tag 1.0 points to a particular commit XX in the 
history; that commit could belong to master branch, or development branch, or 
any other branch (or no named branch at all, also known as detached head).

In another words, your tag points to a commit only, and branches do not play 
any role in this whatsoever.

Am I being clear? (I'm sipping my morning coffee so my brain is not fully 
operational yet ;) )

Peter


On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote:
> Peter - I meant it as a figurative example - on a master branch you can tag 
> whenever you want right? And so you can point users to a specific tag on 
> master so they have a stable point to load from (possibly while you merge a 
> branch back to master and then update any documentation or config before 
> retagging and updating a BaselineOf?
> 
> This looks like what the AWS Smalltalk git repo has used as an example.
> 
> Tim
> 
> (Ps
> Apologies for the "rage" iOS autocorrect - apparently that's what Apple 
> thinks tags is corrected to ;)
> 
> Sent from my iPhone
> 
> 
> 
> Sent from my iPhone
> On 30 Jul 2017, at 16:35, Peter Uhnak  wrote:
> 
> >> 
> >> If I've understood correctly, this means you can rage master with a 
> >> version number like v1.1 and then put that in the URL
> >> 
> >>> https://github.com/peteruhnak/IconFactory/tree/master:v1.1/
> > 
> > I am not sure where you got this url from, but combining branch and tag 
> > name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or 
> > whatever would be the latest in master).
> > 
> > (as mentioned in the syntax: branch name OR commit id OR tag id)
> > 
> > Peter
> > 
> 
> 

Re: [Pharo-dev] [ci-announces] IMPORTANT: Virtual Machines loss

[Christophe Demarey]

> Le 30 juil. 2017 à 10:39, Guillermo Polito  a 
> écrit :
> 
> I don't want to be pesimistic, but this means we don't have CI until we 
> restore all slaves. From the Pharo point of view, we lost almost all but 1 or 
> 2 slaves in different ci servers. Check:
> 
> - https://ci.inria.fr/pharo/ 
> - https://ci.inria.fr/pharo-contribution/ 
> 
> - https://ci.inria.fr/pharo-ci-jenkins2/ 
> 
> 
> I'd like to make for real a call for help in here. We have, for each project 
> (pharo, pharo-contribution, ci-jenkins2), to set-up slaves for windows linux 
> and mac. This means we have to create slaves, check they can connect to 
> jenkins (and otherwise configure them, install dependencies (windows through 
> remote desktop...)).

I will create most of slaves today for all projects.

[Pharo-dev] Esteban's ChangeLog week of 24 July 2017

[estebanlm]

Hello!

This is my weekly ChangeLog, from 24 July 2017 to 30 July 2017.
You can see it in a better format by going here: 
http://log.smallworks.eu/web/search?from=24/7/2017=30/7/2017

ChangeLog
=

25 July 2017:
-

*I made a [pull request](https://github.com/hpi-swa/smalltalkCI/pull/311) 
to enable Pharo 6.1 on SmalltalkCI :)


24 July 2017:
-

*I just released [Pharo 6.1](http://pharo.org/news/pharo6.1-released) to 
update VM and Iceberg (which now 
is version 0.5.5).


cheers! 
Esteban