Re: [Pharo-users] [ANN] New Pharo Glorp version and Book chapter

[p...@highoctane.be]

Esteban,

Thanks a lot for this, it really is a great (and much needed) resource!

Phil

On Sun, May 29, 2016 at 8:27 PM, Esteban A. Maringolo 
wrote:

> Hello all,
>
> During the first part of the year, and sponsored by the Pharo
> Consortium, I started a new port of Glorp, the Object-Relational
> mapper, based on the latest version available in VW 8.0.1.
>
> This latest port was done from scratch in Pharo and brings features
> and bugfixes that were accumulated in the VW port during more than 5
> years (previous Pharo port) and weren't available until now; and it
> uses the Garage database drivers (but not limited to them).
>
> During the last couple of months, and also by request of the
> Consortium, I wrote a chapter for one of the Pharo books describing
> Glorp as much as possible, with tutorials and key concepts. The
> chapter ended up being the longest in text and pages of all written;
> the domain is so broad and deep that I'm considering taking it to a
> whole book, who knows...
>
> The book is available at
> <
> https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/Glorp/Glorp.pdf
> >,
> and I will welcome suggestions and corrections as pull requests to
> 
>
> The Glorp repository is the same as the previous one
> (http://www.smalltalkhub.com/#!/~DBXTalk/Glorp), and the current
> Metacello configs will load the previous version for Pharo 4 and the
> new version for Pharo 5. For the foreseeable future I'll continue
> maintaining Glorp, but the code is MIT and I'm open to contributions
> (I'll set up a Github repo in the next days).
>
> Also I've been running production software based on Glorp for a few
> years now, so my experience with it cover most of its features and
> usage patterns, so if you have particular questions not covered by the
> book chapter or any other material feel free to ask me, this mailing
> list or to the Glorp mailing list at .
>
> Best regards!
>
> Esteban A. Maringolo
>
>
>

Re: [Pharo-users] Is lazy evaluation of infinite series possible?

[Evan Donahue]

Hello,

Other people are probably better qualified to weigh in on the best ways to
manage packages in a Pharo image, but this is what I do:

1) Left click on the "desktop" to bring up the "world menu" and select
"Monticello Browser."
2) Click the "+Repository" button and select "smalltalkhub.com" from the
popup menu.
3) Type 'EvanDonahue' and 'Lazy' inside the provided quotes next to owner:
and project:, respectively (user and password can be left ''). Then click
OK.
4) Highlight "Lazy-Core-EvanDonahue.26.mcz" on the right panel (may be 26 or
any other number) and click the "Browse" button to explore the classes and
methods without actually installing in your image. 
5) Click the "Load" button to install the classes in the image. You may also
want to install Lazy-Tests just to have some code examples to look at.
6) To remove everything later, open Monticello again, search for "Lazy,"
right-click Lazy-Core in the left pane, and "unload"

As for your use case, what you have written should work, but if you just
want a ton of 1's, you can use 
LazyList repeat: 1
There are other class methods of increasing generality for generating
infinite lists, but of course you can always use #collect: and friends to
compose appropriately. LazyList is technically still "under development,"
but it should be feature complete for most uses. Let me know if there's any
functionality it's missing, or if you're wondering whether and how it can do
something. If you want to say any more about the operations you are trying
to perform, I can be more specific about how to do them. Roughly, aside from
the infinite methods, the API follows the standard Pharo collections.

And also welcome to Pharo. It's a trip.

Cheers,
Evan



--
View this message in context: 
http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897956p4898034.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] [ANN] New Pharo Glorp version and Book chapter

[Pablo R. Digonzelli]

Excellent Esteban. 
Thanks a lot 



Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Dividato SA 
25 de Mayo 521 
San Miguel de Tucumán 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714

- Mensaje original -
De: "Esteban A. Maringolo" 
Para: "Pharo users" , "GLORP Mailing List" 

Enviados: Domingo, 29 de Mayo 2016 15:27:17
Asunto: [ANN] New Pharo Glorp version and Book chapter

Hello all,

During the first part of the year, and sponsored by the Pharo
Consortium, I started a new port of Glorp, the Object-Relational
mapper, based on the latest version available in VW 8.0.1.

This latest port was done from scratch in Pharo and brings features
and bugfixes that were accumulated in the VW port during more than 5
years (previous Pharo port) and weren't available until now; and it
uses the Garage database drivers (but not limited to them).

During the last couple of months, and also by request of the
Consortium, I wrote a chapter for one of the Pharo books describing
Glorp as much as possible, with tutorials and key concepts. The
chapter ended up being the longest in text and pages of all written;
the domain is so broad and deep that I'm considering taking it to a
whole book, who knows...

The book is available at
,
and I will welcome suggestions and corrections as pull requests to


The Glorp repository is the same as the previous one
(http://www.smalltalkhub.com/#!/~DBXTalk/Glorp), and the current
Metacello configs will load the previous version for Pharo 4 and the
new version for Pharo 5. For the foreseeable future I'll continue
maintaining Glorp, but the code is MIT and I'm open to contributions
(I'll set up a Github repo in the next days).

Also I've been running production software based on Glorp for a few
years now, so my experience with it cover most of its features and
usage patterns, so if you have particular questions not covered by the
book chapter or any other material feel free to ask me, this mailing
list or to the Glorp mailing list at .

Best regards!

Esteban A. Maringolo

-- 
You received this message because you are subscribed to the Google Groups 
"glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to glorp-group+unsubscr...@googlegroups.com.
To post to this group, send email to glorp-gr...@googlegroups.com.
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Re: [Pharo-users] [ANN] New Pharo Glorp version and Book chapter

[Pablo R. Digonzelli]

Ing. Pablo Digonzelli 
Software Solutions 
IP-Solutiones SRL 
Dividato SA 
25 de Mayo 521 
San Miguel de Tucumán 
Email: pdigonze...@softsargentina.com 
pdigonze...@gmail.com 
Cel: 5493815982714

- Mensaje original -
De: "Esteban A. Maringolo" 
Para: "Pharo users" , "GLORP Mailing List" 

Enviados: Domingo, 29 de Mayo 2016 15:27:17
Asunto: [ANN] New Pharo Glorp version and Book chapter
Excellent, thanks a lot




Hello all,

During the first part of the year, and sponsored by the Pharo
Consortium, I started a new port of Glorp, the Object-Relational
mapper, based on the latest version available in VW 8.0.1.

This latest port was done from scratch in Pharo and brings features
and bugfixes that were accumulated in the VW port during more than 5
years (previous Pharo port) and weren't available until now; and it
uses the Garage database drivers (but not limited to them).

During the last couple of months, and also by request of the
Consortium, I wrote a chapter for one of the Pharo books describing
Glorp as much as possible, with tutorials and key concepts. The
chapter ended up being the longest in text and pages of all written;
the domain is so broad and deep that I'm considering taking it to a
whole book, who knows...

The book is available at
,
and I will welcome suggestions and corrections as pull requests to


The Glorp repository is the same as the previous one
(http://www.smalltalkhub.com/#!/~DBXTalk/Glorp), and the current
Metacello configs will load the previous version for Pharo 4 and the
new version for Pharo 5. For the foreseeable future I'll continue
maintaining Glorp, but the code is MIT and I'm open to contributions
(I'll set up a Github repo in the next days).

Also I've been running production software based on Glorp for a few
years now, so my experience with it cover most of its features and
usage patterns, so if you have particular questions not covered by the
book chapter or any other material feel free to ask me, this mailing
list or to the Glorp mailing list at .

Best regards!

Esteban A. Maringolo

-- 
You received this message because you are subscribed to the Google Groups 
"glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to glorp-group+unsubscr...@googlegroups.com.
To post to this group, send email to glorp-gr...@googlegroups.com.
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Re: [Pharo-users] Is lazy evaluation of infinite series possible?

[Erisa]

I took a look at the numerical methods book, but it seems oriented to
actually evaluating an infinite series up to a certain accuracy.  With
formal power series all we want are the coefficients.  For example, consider
the series

S = 1 + x + x^2 + x^3 + ...

The coefficients are an infinite list [1, 1, ...].  What I need is a class
for S that would allow me to perform operations such as addition,
multiplication, etc.  Thus I would like to able to do S * S and get the
infinite list of the coefficients [1, 2, 3, 4, ...] and view say the first
10 or perhaps the nth coefficient.

Your LazyList looks promising.  To create the series this seems like it
would work.

s := LazyList wholes collect: [ :n | 1 ]

But defining the operations is the difficult part.  I would like to look at
your package, but I need some help.  How can I download your package from
smalltalk hub so that I can examine it, play with it, but eventually easily
remove it if I want.  As you can tell, I have just started learning Pharo.





--
View this message in context: 
http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897956p4898028.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Is lazy evaluation of infinite series possible?

[stepharo]

Hello Erisa


I am just learning Pharo (taking the MOOC actually!)


:)


and am wondering whether
it is possible to model formal power series.  I have done this in Haskell
quite easily and efficiently, but struggled to do it in Python without real
success.  It requires one to perform operations on an infinite stream (such
as multiplying two infinite power series).  One then only evaluates the
terms as they are needed, i.e., lazily.  Any thoughts?

I'm eager to hear what other and you will say.
Now since blocks are closures, and I remember that long time ago I 
implemented simply

infinite stream with a closure in CLOS it should be a same in Pharo.
Now it was probably 20 years ago so I forgot the exact implementation.

I hope that you have fun with our neat language.
Stef




--
View this message in context: 
http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897956.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] (no subject)

[stepharo]

Le 29/5/16 à 12:04, frankl1_miky a écrit :

Thanks for all your answers, It's true that pharo community is active.

I'll give you feedback about my progress.

I'm having fun with Pharo Mooc at this period.


I'm happy to see that all the energy I put in the mooc is useful :)



Thanks for your help!



--
View this message in context: 
http://forum.world.st/no-subject-tp4894192p4897990.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[stepharo]

For some reason the package manager is refreshing all packages. I don't know 
why it happens, and it's quite annoying (because it slows down commits), but it 
doesn't cause any actual problems, so don't worry about it too much.

As I understand it, what happens is the following: before you commit to your MC 
repo, you have to find the next version number; a check is then done in all 
relevant repos; the cached content is not used, but an actual refresh is done. 
All this is so that my .5 would not conflict with someone else .5 - the chance 
that this happens is very small, and the check does not really prevent it.

I assumed that but can it be limited to the Repositories that are associated 
with the package? I am afraid that next time I travel I can not commit to my 
local repository (and ofcourse the speed part). :)

We should go one step further: add an option to totally disable this check to 
go outside the target repo,


It would be cool because you imagine when we integrate a change :)


  it makes little sense. But MC is a complex beast ...


holger

[Pharo-users] [ANN] New Pharo Glorp version and Book chapter

[Esteban A. Maringolo]

Hello all,

During the first part of the year, and sponsored by the Pharo
Consortium, I started a new port of Glorp, the Object-Relational
mapper, based on the latest version available in VW 8.0.1.

This latest port was done from scratch in Pharo and brings features
and bugfixes that were accumulated in the VW port during more than 5
years (previous Pharo port) and weren't available until now; and it
uses the Garage database drivers (but not limited to them).

During the last couple of months, and also by request of the
Consortium, I wrote a chapter for one of the Pharo books describing
Glorp as much as possible, with tutorials and key concepts. The
chapter ended up being the longest in text and pages of all written;
the domain is so broad and deep that I'm considering taking it to a
whole book, who knows...

The book is available at
,
and I will welcome suggestions and corrections as pull requests to


The Glorp repository is the same as the previous one
(http://www.smalltalkhub.com/#!/~DBXTalk/Glorp), and the current
Metacello configs will load the previous version for Pharo 4 and the
new version for Pharo 5. For the foreseeable future I'll continue
maintaining Glorp, but the code is MIT and I'm open to contributions
(I'll set up a Github repo in the next days).

Also I've been running production software based on Glorp for a few
years now, so my experience with it cover most of its features and
usage patterns, so if you have particular questions not covered by the
book chapter or any other material feel free to ask me, this mailing
list or to the Glorp mailing list at .

Best regards!

Esteban A. Maringolo

Re: [Pharo-users] Is lazy evaluation of infinite series possible?

[Evan Donahue]

Hello,

I know infinite series are mentioned in the numerical methods book, although
I haven't worked with those classes specifically.

http://files.pharo.org/books/numerical-methods/2016-04-NumericalMethods.pdf

You could also use a LazyList, depending on what you were doing, from
http://smalltalkhub.com/#!/~EvanDonahue/Lazy/

x := 3.
Float e raisedTo: x. " = 20.085536923187664"

eX := LazyList wholes collect: [ :n | (x raisedTo: n) / n factorial ].
(eX take: 20) sum asFloat. " = 20.085536921517672"

2 * (Float e raisedTo: x). " = 40.17107384637533"

twoEX := eX with: eX collect: [ :a :b | a + b ].
(twoEX take: 20) sum asFloat. " = 40.171073843035344"

Will either of those work?

Evan



--
View this message in context: 
http://forum.world.st/Is-lazy-evaluation-of-infinite-series-possible-tp4897956p4898015.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Thierry Goubier]

Le 29/05/2016 14:04, Peter Uhnak a écrit :

On Sun, May 29, 2016 at 11:21:21AM +0200, Thierry Goubier wrote:

Le 29/05/2016 11:15, Peter Uhnák a écrit :

  > All this is so that my .5 would not conflict with someone else .5

How is this a problem? Because it will be "Me.5" and "You.5", so there
can't be any conflict.


Me.5 and Me.5 are possible...

Think of numbering your own stuff on two different branches.

More, Metacello depends on Me.5 5 to be greater than You.5 5 for some of the
baselines / configurations to work properly :)


Can't it use the ancestry to decide?


I suggested that to Dale... Disregard version numbers, only consider as 
newer if the other is in the ancestry chain.


Would also be a lot more precise, because we would then use the package 
version UID instead of the name.version number approximation which can 
leads to failures or loading the wrong package in some cases.



Because my impression is from this that merges are naive, compared to
git which actually checks the ancestry of both up the common endpoint
and diffs based on that.


This does not describe the Monticello merges. Monticello merges do walk 
the ancestry chain to find a common ancestor and does a three way merge, 
as git does.


The problem is that the Monticello ancestry chain is often damaged for 
three reasons: removing part of it to reduce memory usage (Done for the 
Pharo3 release), removing all or part of it because your package 
ancestry chain is too long (I remember seeing some packages doing that 
on purpose?), the common ancestor doesn't exist anymore in the 
repositories visible to Monticello (long-lived packages that have moved 
between repositories, typically).


When Monticello sees a version in the history, it expects the full 
package to be available in the repositories; if this package is the 
common ancestor of the merge and can't be retrieved, then the merge will 
fail.


What GitFileTree/git does there is to ensure that if a version is in the 
ancestry, it can be retrieved. Git merge also use that property. Any 
GitFileTree-like layer would provide the same property (FossilFileTree, 
for example).


Note: in the git documentation, it is stated that git may create virtual 
ancestors in some cases, to simplify/reduce the merge work. In such 
cases, if set up, the gitfiletree merge driver will be called for all 
those merges (i.e. a single merge in git may trigger multiple merges).


Obvious, isn't it ;)

Thierry


Peter



Thierry



Peter

On Sun, May 29, 2016 at 10:37 AM, Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:


 > On 29 May 2016, at 10:28, Holger Freyther mailto:hol...@freyther.de>> wrote:
 >
 >
 >> On 29 May 2016, at 09:58, Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:
 >>
 >>
 >>>
 >>> For some reason the package manager is refreshing all packages. I 
don't know why it happens, and it's quite annoying (because it slows down commits), but 
it doesn't cause any actual problems, so don't worry about it too much.
 >>
 >> As I understand it, what happens is the following: before you commit to 
your MC repo, you have to find the next version number; a check is then done in all 
relevant repos; the cached content is not used, but an actual refresh is done. All 
this is so that my .5 would not conflict with someone else .5 - the chance that this 
happens is very small, and the check does not really prevent it.
 >
 > I assumed that but can it be limited to the Repositories that are 
associated with the package? I am afraid that next time I travel I can not commit 
to my local repository (and ofcourse the speed part). :)

 We should go one step further: add an option to totally disable this
 check to go outside the target repo, it makes little sense. But MC
 is a complex beast ...

  > holger

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Peter Uhnak]

On Sun, May 29, 2016 at 11:21:21AM +0200, Thierry Goubier wrote:
> Le 29/05/2016 11:15, Peter Uhnák a écrit :
> >  > All this is so that my .5 would not conflict with someone else .5
> > 
> > How is this a problem? Because it will be "Me.5" and "You.5", so there
> > can't be any conflict.
> 
> Me.5 and Me.5 are possible...
> 
> Think of numbering your own stuff on two different branches.
> 
> More, Metacello depends on Me.5 5 to be greater than You.5 5 for some of the
> baselines / configurations to work properly :)

Can't it use the ancestry to decide?

Because my impression is from this that merges are naive, compared to
git which actually checks the ancestry of both up the common endpoint
and diffs based on that.

Peter

> 
> Thierry
> 
> > 
> > Peter
> > 
> > On Sun, May 29, 2016 at 10:37 AM, Sven Van Caekenberghe  > > wrote:
> > 
> > 
> > > On 29 May 2016, at 10:28, Holger Freyther  > > wrote:
> > >
> > >
> > >> On 29 May 2016, at 09:58, Sven Van Caekenberghe  > > wrote:
> > >>
> > >>
> > >>>
> > >>> For some reason the package manager is refreshing all packages. I 
> > don't know why it happens, and it's quite annoying (because it slows down 
> > commits), but it doesn't cause any actual problems, so don't worry about it 
> > too much.
> > >>
> > >> As I understand it, what happens is the following: before you commit 
> > to your MC repo, you have to find the next version number; a check is then 
> > done in all relevant repos; the cached content is not used, but an actual 
> > refresh is done. All this is so that my .5 would not conflict with someone 
> > else .5 - the chance that this happens is very small, and the check does 
> > not really prevent it.
> > >
> > > I assumed that but can it be limited to the Repositories that are 
> > associated with the package? I am afraid that next time I travel I can not 
> > commit to my local repository (and ofcourse the speed part). :)
> > 
> > We should go one step further: add an option to totally disable this
> > check to go outside the target repo, it makes little sense. But MC
> > is a complex beast ...
> > 
> >  > holger
> > 
> > 
> > 
> 
> 

[Pharo-users] QCMagritte & Voyage?

[Udo Schneider]

All,

I'm currently trying to wrap my head around QCMagritte. So far it seems 
to include most of what I need.


I'm not sure though how/where to integrate a persistency layer (i.e. 
Voyage in this case). I'm either missing some place to activly take 
control and do saving/upgrading or any callback when objects/collections 
have been changed.


Any pointers or sample code?

Thanks,

Udo

Re: [Pharo-users] (no subject)

[frankl1_miky]

Thanks for all your answers, It's true that pharo community is active.

I'll give you feedback about my progress.

I'm having fun with Pharo Mooc at this period.

Thanks for your help!



--
View this message in context: 
http://forum.world.st/no-subject-tp4894192p4897990.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Thierry Goubier]

Le 29/05/2016 11:15, Peter Uhnák a écrit :

 > All this is so that my .5 would not conflict with someone else .5

How is this a problem? Because it will be "Me.5" and "You.5", so there
can't be any conflict.


Me.5 and Me.5 are possible...

Think of numbering your own stuff on two different branches.

More, Metacello depends on Me.5 5 to be greater than You.5 5 for some of 
the baselines / configurations to work properly :)


Thierry



Peter

On Sun, May 29, 2016 at 10:37 AM, Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:


> On 29 May 2016, at 10:28, Holger Freyther mailto:hol...@freyther.de>> wrote:
>
>
>> On 29 May 2016, at 09:58, Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:
>>
>>
>>>
>>> For some reason the package manager is refreshing all packages. I don't 
know why it happens, and it's quite annoying (because it slows down commits), but it 
doesn't cause any actual problems, so don't worry about it too much.
>>
>> As I understand it, what happens is the following: before you commit to 
your MC repo, you have to find the next version number; a check is then done in all 
relevant repos; the cached content is not used, but an actual refresh is done. All 
this is so that my .5 would not conflict with someone else .5 - the chance that this 
happens is very small, and the check does not really prevent it.
>
> I assumed that but can it be limited to the Repositories that are 
associated with the package? I am afraid that next time I travel I can not commit 
to my local repository (and ofcourse the speed part). :)

We should go one step further: add an option to totally disable this
check to go outside the target repo, it makes little sense. But MC
is a complex beast ...

 > holger

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Peter Uhnák]

> All this is so that my .5 would not conflict with someone else .5

How is this a problem? Because it will be "Me.5" and "You.5", so there
can't be any conflict.

Peter

On Sun, May 29, 2016 at 10:37 AM, Sven Van Caekenberghe 
wrote:

>
> > On 29 May 2016, at 10:28, Holger Freyther  wrote:
> >
> >
> >> On 29 May 2016, at 09:58, Sven Van Caekenberghe  wrote:
> >>
> >>
> >>>
> >>> For some reason the package manager is refreshing all packages. I
> don't know why it happens, and it's quite annoying (because it slows down
> commits), but it doesn't cause any actual problems, so don't worry about it
> too much.
> >>
> >> As I understand it, what happens is the following: before you commit to
> your MC repo, you have to find the next version number; a check is then
> done in all relevant repos; the cached content is not used, but an actual
> refresh is done. All this is so that my .5 would not conflict with someone
> else .5 - the chance that this happens is very small, and the check does
> not really prevent it.
> >
> > I assumed that but can it be limited to the Repositories that are
> associated with the package? I am afraid that next time I travel I can not
> commit to my local repository (and ofcourse the speed part). :)
>
> We should go one step further: add an option to totally disable this check
> to go outside the target repo, it makes little sense. But MC is a complex
> beast ...
>
> > holger
>
>
>

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Sven Van Caekenberghe]

> On 29 May 2016, at 10:28, Holger Freyther  wrote:
> 
> 
>> On 29 May 2016, at 09:58, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> 
>>> For some reason the package manager is refreshing all packages. I don't 
>>> know why it happens, and it's quite annoying (because it slows down 
>>> commits), but it doesn't cause any actual problems, so don't worry about it 
>>> too much.
>> 
>> As I understand it, what happens is the following: before you commit to your 
>> MC repo, you have to find the next version number; a check is then done in 
>> all relevant repos; the cached content is not used, but an actual refresh is 
>> done. All this is so that my .5 would not conflict with someone else .5 - 
>> the chance that this happens is very small, and the check does not really 
>> prevent it.
> 
> I assumed that but can it be limited to the Repositories that are associated 
> with the package? I am afraid that next time I travel I can not commit to my 
> local repository (and ofcourse the speed part). :)

We should go one step further: add an option to totally disable this check to 
go outside the target repo, it makes little sense. But MC is a complex beast ...

> holger

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Holger Freyther]

> On 29 May 2016, at 09:58, Sven Van Caekenberghe  wrote:
> 
> 
>> 
>> For some reason the package manager is refreshing all packages. I don't know 
>> why it happens, and it's quite annoying (because it slows down commits), but 
>> it doesn't cause any actual problems, so don't worry about it too much.
> 
> As I understand it, what happens is the following: before you commit to your 
> MC repo, you have to find the next version number; a check is then done in 
> all relevant repos; the cached content is not used, but an actual refresh is 
> done. All this is so that my .5 would not conflict with someone else .5 - the 
> chance that this happens is very small, and the check does not really prevent 
> it.

I assumed that but can it be limited to the Repositories that are associated 
with the package? I am afraid that next time I travel I can not commit to my 
local repository (and ofcourse the speed part). :)

holger

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Sven Van Caekenberghe]

> On 29 May 2016, at 09:51, Peter Uhnak  wrote:
> 
> On Sat, May 28, 2016 at 10:48:47PM +0200, Holger Freyther wrote:
>> Hi,
>> 
>> every time I save a local package using gitfiletree:// it tries to download 
>> from the pharo5 inbox. Is this to be expected? I do not have the inbox 
>> associated with that package though? Can the version number resolving be 
>> changed?
> 
> For some reason the package manager is refreshing all packages. I don't know 
> why it happens, and it's quite annoying (because it slows down commits), but 
> it doesn't cause any actual problems, so don't worry about it too much.

As I understand it, what happens is the following: before you commit to your MC 
repo, you have to find the next version number; a check is then done in all 
relevant repos; the cached content is not used, but an actual refresh is done. 
All this is so that my .5 would not conflict with someone else .5 - the chance 
that this happens is very small, and the check does not really prevent it.

> Peter
> 
>> 
>> kind regards
>>  holger
> 

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

[Peter Uhnak]

On Sat, May 28, 2016 at 10:48:47PM +0200, Holger Freyther wrote:
> Hi,
> 
> every time I save a local package using gitfiletree:// it tries to download 
> from the pharo5 inbox. Is this to be expected? I do not have the inbox 
> associated with that package though? Can the version number resolving be 
> changed?

For some reason the package manager is refreshing all packages. I don't know 
why it happens, and it's quite annoying (because it slows down commits), but it 
doesn't cause any actual problems, so don't worry about it too much.

Peter

> 
> kind regards
>   holger