Re: [Pharo-dev] Do we kill the catalog?

[Guillermo Polito]

Just for the record

https://pharo.fogbugz.com/f/cases/21825/Improve-Catalog-loading
https://github.com/pharo-project/pharo/pull/1292

Feel free to review or to propose other PRs,
Guille

Re: [Pharo-dev] self-backporting from P7 to P6.1

[Guillermo Polito]

Esteban did some work on making a forward compatibility package for spec.

github://pharo-contributions/Spec70Compatibility:v1.0.0/src

The idea is that people should do the opposite: code for Pharo7, while
being in Pharo 6.

But that covers only Spec. We have to think if there is some automatic
solution for all the stream/file changes also.

Peter, I want your file dialog into pharo!

On Mon, Apr 30, 2018 at 11:37 AM, Peter Uhnák  wrote:

> Hi,
>
> are there some recommended practices / tooling for custom backporting from
> P7 to P6.1?
>
> Thanks,
> Peter
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] self-backporting from P7 to P6.1

[Guillermo Polito]

On Mon, Apr 30, 2018 at 12:19 PM, Peter Uhnák  wrote:

> > The idea is that people should do the opposite: code for Pharo7, while
>> being in Pharo 6.
>>
>
> Exactly. Several times I was put off contributing to P7, because I needed
> a solution now, and not in year when P7 comes out... so I hacked a
> workaround instead of a proper fix... which is not good.
>
> > Peter, I want your file dialog into pharo!
>
>
>> Me too !!
>>
>
> Me too. :-D
>
> But I'm finishing my degree in ~45 days so it won't be before that...
>

Finish your degree, that's important too :)


>
> Peter
>



-- 



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

[Pharo-dev] Github API on github

[Guillermo Polito]

Hi guys,

I extracted and extended some of the github API from iceberg, so it can be
used as a standalone project. Maybe this is useful for somebody.

https://github.com/guillep/github-api

It should be easy to extend and add new functionalities, so don't hesitate
if you need some missing request :)

Guille

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] CI Build order and strange "latest" Pharo 7 effect

[Guillermo Polito]

Follow up.

We tested with Pablo how these options work on a separate repository/job.

I just integrated these changes, and they effectively disable concurrent
builds on the development branch. PRs are still being validated
concurrently.

On Fri, Oct 13, 2017 at 11:37 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Well, apparently there is an option to disable concurrent builds, and we
> should be able to make it work only for the development branch.
>
> https://jenkins.io/doc/book/pipeline/syntax/#options
> https://stackoverflow.com/questions/41492688/how-to-
> limit-jenkins-concurrent-multibranch-pipeline-builds
> https://issues.jenkins-ci.org/browse/JENKINS-46593
>
> I've opened the following issue:
>
> https://pharo.fogbugz.com/f/cases/20541/Diable-concurrent-
> builds-for-the-development-branch
>
> and the following PR:
>
> https://github.com/pharo-project/pharo/pull/363
>
> Could you review/check? I'm in the middle of a meeting right now :)
>
>
> On Fri, Oct 13, 2017 at 9:40 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 12, 2017 at 9:23 PM, Torsten Bergmann <asta...@gmx.de> wrote:
>>
>>> Hi Guille,
>>>
>>> I understand that we want run the pull requests for contributions in
>>> parallel. But do we want to run also  the main build for
>>> the daily official relase in parallel to have such side effects? I doubt
>>> that.
>>>
>>> As I wrote it is not only an issue of the file server. The zero conf
>>> does not give you the latest
>>> although available (which is bad if you want to do the next
>>> contribution) and we inform about
>>> later build earlier than previous builds, etc.
>>>
>>
>> Yes, I agree that this is a real issue. The reason is the following:
>> every build, all artifacts are uploaded to the file server + a copy named
>> latest.zip, which is used by zeroconf scripts. latest.zip is overwritten on
>> every build. This means that the last build to finish is the last that
>> writes to latest.zip.
>>
>>
>>>
>>> Sure it would be "nice" if our future Pharo 12 would already be
>>> available before we release Pharo 7 - but it
>>> still is not correct and confuses people ;)
>>>
>>> So is there anything that can be done to improve/solve this?
>>>
>>
>> I'll check the options and come back to everybody here.
>>
>>
>>>
>>> Thanks
>>> T.
>>>
>>>
>>> Am 12.10.2017 um 16:12 schrieb Guillermo Polito:
>>>
>>>>
>>>>
>>>> On Thu, Oct 12, 2017 at 4:01 PM, Norbert Hartl <norb...@hartl.name
>>>> <mailto:norb...@hartl.name>> wrote:
>>>>
>>>>
>>>> > Am 12.10.2017 um 14:23 schrieb Torsten Bergmann <asta...@gmx.de
>>>> <mailto:asta...@gmx.de>>:
>>>>
>>>> >
>>>> > Hi,
>>>> >
>>>> > today there was an interesting effect visible for the Pharo
>>>> build on CI for Pharo 7:
>>>> >
>>>> > Esteban merged three contributions for Pharo 7 into #development
>>>> (see [1]). All three merges on git triggered the CI.
>>>> > For each a separate build for Pharo 7 started on CI independently.
>>>> >
>>>> > While usually one would expect the builds in regular build order
>>>> 183, 184, 185 the CI job for building 185 job was faster
>>>> > (as you can see on the attached screenshot).
>>>> >
>>>> > So the 185 series of images was copied first to the file server
>>>> [3] because the job was already finished.
>>>> > Afterwards 183 build completed on CI and these images were
>>>> copied to the file server with a newer timestamp.
>>>> >
>>>> > So you have the order 185, 183 with 183 having the files with
>>>> the newest timestamp (but not being the most recent state of Pharo).
>>>> >
>>>> > This leads to several unfortunate effects:
>>>> >  1. When you sort on file server [3] descending by date the
>>>> build 183 images are newer than the build 185 images
>>>> >  2. When you use PharoLauncher to download "latest-32" you get
>>>> an 183 image instead of the "real latest" 185 image
>>>> >  3. When you

[Pharo-dev] Updating CI plugins

[Guillermo Polito]

Hi all,

I'm updating CI plugins. *This will require a CI restart. *The
corresponding issue is here:

https://pharo.fogbugz.com/f/cases/20884/Update-CI-Plugins

The installed versions are the following:

Workspace Cleanup Plugin 0.34 0.33
SCM API Plugin 2.2.6 2.2.1
Pipeline Utility Steps 1.5.1 1.4.1
Pipeline: API 2.24 2.20
Pipeline: Build Step 2.6 2.5.1
Pipeline: Declarative 1.2.5 1.1.9
Pipeline: Declarative Extension Points API 1.2.5 1.1.9
Pipeline: Groovy 2.41 2.40
Pipeline: Model API 1.2.5 1.1.9
Pipeline: Nodes and Processes 2.16 2.15
Pipeline: Shared Groovy Libraries 2.9 2.8
Pipeline: Stage Step 2.3 2.2
Pipeline: Stage Tags Metadata 1.2.5 1.1.9
Pipeline: Step API 2.14 2.12
Rebuilder 1.27 1.25
JUnit Plugin 1.23 1.21
Git client plugin 2.7.0 2.5.0
Git plugin 3.6.4 3.5.1
GitHub API Plugin 1.90 1.86
GitHub Branch Source Plugin 2.3.2 2.2.3
GitHub plugin 1.28.1 1.28.0
Copy Artifact Plugin 1.39 1.38.1
Credentials Plugin 2.1.16 2.1.15
Build Timeout 1.19 1.18
Conditional BuildStep 1.3.6 1.3.5

I'll keep you updated as soon as the update is finished.
Guille


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Updating CI plugins

[Guillermo Polito]

Christophe is also taking benefit of this to update jenkins from 2.32.3 LTS
to 2.89.2 LTS

On Fri, Dec 22, 2017 at 10:06 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Hi all,
>
> I'm updating CI plugins. *This will require a CI restart. *The
> corresponding issue is here:
>
> https://pharo.fogbugz.com/f/cases/20884/Update-CI-Plugins
>
> The installed versions are the following:
>
> Workspace Cleanup Plugin 0.34 0.33
> SCM API Plugin 2.2.6 2.2.1
> Pipeline Utility Steps 1.5.1 1.4.1
> Pipeline: API 2.24 2.20
> Pipeline: Build Step 2.6 2.5.1
> Pipeline: Declarative 1.2.5 1.1.9
> Pipeline: Declarative Extension Points API 1.2.5 1.1.9
> Pipeline: Groovy 2.41 2.40
> Pipeline: Model API 1.2.5 1.1.9
> Pipeline: Nodes and Processes 2.16 2.15
> Pipeline: Shared Groovy Libraries 2.9 2.8
> Pipeline: Stage Step 2.3 2.2
> Pipeline: Stage Tags Metadata 1.2.5 1.1.9
> Pipeline: Step API 2.14 2.12
> Rebuilder 1.27 1.25
> JUnit Plugin 1.23 1.21
> Git client plugin 2.7.0 2.5.0
> Git plugin 3.6.4 3.5.1
> GitHub API Plugin 1.90 1.86
> GitHub Branch Source Plugin 2.3.2 2.2.3
> GitHub plugin 1.28.1 1.28.0
> Copy Artifact Plugin 1.39 1.38.1
> Credentials Plugin 2.1.16 2.1.15
> Build Timeout 1.19 1.18
> Conditional BuildStep 1.3.6 1.3.5
>
> I'll keep you updated as soon as the update is finished.
> Guille
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

[Guillermo Polito]

On Tue, Jan 2, 2018 at 1:13 PM, Henrik Sperre Johansen <
henrik.s.johan...@veloxit.no> wrote:

> Stephane Ducasse-3 wrote
> > Hi Bernhard
> >
> > Have a look at how guille started to implement File package.
> > (Guille is actively converting all the image users of the old
> > hierarchy but last time he losts a couple of hours
> > because changing epicea and other users of positionable streams and
> > sourceArray... at the same time
> > was leading to complex situations :).  But Guille told me that he
> > learned and will come back to this.)
> >
> > He is using ZnCharacterWriteStream and wrapper like
> > ZnCrPortableWriteStream.
> >
> > writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag
> >
> > | extension fileName  outputStream |
> > extension := stOrCsFlag ifTrue: ['.st']  ifFalse: ['.cs'].
> > fileName := baseName, extension.
> > fileName := FileSystem disk checkName: fileName fixErrors: true.
> > outputStream := (File named: fileName) writeStream.
> > (ZnCrPortableWriteStream on: (ZnCharacterWriteStream
> > on: outputStream
> > encoding: 'utf8')) nextPutAll: aStream contents.
> >
> > outputStream close.
> >
> > writeSourceCodeFrom: aStream toFileReference: aFileReference
> >
> > aFileReference writeStreamDo: [ :outputStream |
> >  (ZnCrPortableWriteStream on: (ZnCharacterWriteStream
> >  on: outputStream
> >  encoding: 'utf8')) nextPutAll: aStream contents.
> >  ].
> >
> > self inform: 'Filed out to: ', String cr, aFileReference basename
> >
> >
> > self inform: 'Filed out to: ', String cr, fileName.
> >
> > I hope it helps.
> >
> > Stef
> >
> > On Sat, Dec 30, 2017 at 1:27 PM, Bernhard Pieber 
>
> > bernhard@
>
> >  wrote:
> >> I just saw that the FileStream hierarchy including MultiByteFileStream
> is
> >> deprecated. However, I can't find what file stream class should be used
> >> to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also
> >> uses MultiByteFileStream.
> >>
> >> Can someone please point me to the right code?
> >>
> >> Bernhard
>
> Maybe it's just me, but I'd a big fan of convenience methods over explicit
> stacking when it comes to multi-layer streams.
> - It documents the intended/valid ways to stack (such as which streams it
> makes sense to wrap in a ZnCrPortableWriteStream, or which streams one
> normally would want to #buffered:do:)
> - It makes the transition (in terms of conciseness) from "traditional"
> filestreams less jarring (provided convenience methods provide sensible
> defaults).
>
> Say, for instance, a #withEncoding:do:* on read/writeStream, so instead of
> the above, one can do:
>
> fileName := FileSystem disk checkName: fileName fixErrors: true.
> (outputStream :=(File named: fileName) writeStream)
>withEncoding: 'utf8'
>   do: [:encodedWriteStream |
>   encodedWriteStream nextPutAll: aStream contents].
> outputStream close.
>
> and
> aFileReference writeStreamDo: [ :outputStream |
>outputStream withEncoding: 'utf8' do: [:encodedStream |
>   encodedStream nextPutAll: aStream contents. ]].
> or
> input := aFileReference readStreamDo: [ :inputStream |
>inputStream withEncoding: 'utf8' do: [:decodingStream |
>   decodingStream contents]]
>
> It's more involved than the current multibytestreams, but takes away the
> burden of determining the correct stack of ZnStreams for the common case.
> For instance, you'd normally want file write streams to also be wrapped by
> a
> buffered stream, and have a single flush at end of withEncoding:do:, while
> the same isn't necessary for withEncoding:do: on the base WriteStream
> class.
>


It's not just you :).

I was during last sprint (while seeing such idioms appear) adding
convenience methods like

writeStreamEncoded: anEncoding
writeStreamDo: aBlock encoded: anEncoding

readStreamEncoded: anEncoding
readStreamDo: aBlock encoded: anEncoding

But my image fantastically crashed, the save image failed and I lost
everything...



> Cheers,
> Henry
>
> *Bad name, I know, but you get the point.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] How to restore image upgrade? was New Year Wishlist (2018) ?

[Guillermo Polito]

On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

>
>
> 2017-12-25 23:54 GMT+01:00 Ben Coman :
>
>> As a half-way house, consider that "upgrade" scripts could be a good
>> mechanism
>> post-Release when changes should be less-deep/less-arduous on the system.
>> This might avoid Esteban's time being needed to re-Release for each
>> upgrade,
>> with post-Release moving to a more community supported mechanism.
>> This could scale better as we gain more users interested in long term
>> support
>> of their applications on a stable-release than the moving target of the
>> development-edge.
>>
>> cheers -ben
>>
>
> Hi Ben,
> upgrade scripts is what is used by Squeak trunk (as available via
> Monticello).
> it's difficult to write correctly, and difficult to test (clearly a job
> for a bot).
> Every intermediate script has to be replayed (or not, but who knows?) and
> this is done via MonticelloConfigurationMap.
> Can you imagine that transposed to git?
>
> It's not reversible (we don't provide the reverse scripts).
> It might fail due to specific changes in the image (let's say dirty
> workspace), and not only code changes.
>
> So it's very very far from git smoothness.
> Fortunately, those scripts are rarely needed (as a percentage of commits).
> Unfortunately, they are regularly needed (several times a year).
> Remind that Pharo is supposed to change Kernel classes a bit faster than
> Squeak ;)
>
>
>> On 25 December 2017 at 23:11, Stephane Ducasse 
>> wrote:
>>
>>> Nicolas
>>>
>>> We want to keep the live part of Pharo and incremental loading and it
>>> is key for us. Now we should not be naive.
>>>
>>
> Hi Steph,
> Not every provocation deserves an answer ;)
> I hope everyone here wants a lively thing, otherwise why use Pharo?
>
>
>> Most of the time we do not have the garantee that a change will work
>>> when loaded.
>>>
>>> We have bots passing tests for rejecting broken code.
> But the problem is that correct code can also be rejected
>
> We proposed Pablo to work since two years on a really working dynamic
>>> code loader and
>>> Pablo has really nice results. But it takes time to evaluate if/how we
>>> integrate its changes.
>>> Pablo has an atomic coder loader and an incremental and modular class
>>> builder.
>>> He also designed a modular shutdown/startup list manager (in production).
>>>
>>> Glad to ear that. I hope to read publications on this subject one day
> then.
> Two years for nice intermediate results just confirms that the problem is
> very tough as we all know...
>
> We want to be able to have a **real** and robust incremental load.
>>> Right now as you know it and as in ANY smalltalk I can break the
>>> system super easily.
>>> There is no magic. I do not see how we can make sure that any piece of
>>> code will be loaded
>>> and do not break the system.
>>> So our objective is to have a new infrastructure that we can updates
>>> (like method hashes for example without having to
>>> twists our mind and do five updates).
>>>
>>> Now about git, we want and we will have our lovely image as a working
>>> directory but this requires engineering
>>> because the image is another artefact that other languages do not have
>>> to worry.
>>> We will get there.
>>>
>>>
> Agree with all you said,
>
> My point is that git is not going to help you solving the problems others
> don't have.
> If we have seemless integration for bootstrap free code, that will already
> be something...
> For the rest, it's a bit too much wishful thinking to my taste.
> As said above, because bootstrap problems happen rarely, but regularly,
> I can predict that pharo development won't be as smooth as dreamed of for
> some time.
> We have to accept that and work hard to find acceptable trade offs.
> I'm interested in seeing which solution will emerge.
>

In any case, the problem of updating pharo itself is a problem we have had
for some time.
And it is not specific to git and it is even shared with monticello.

We lack of an atomic update with (a) object migration rules and (b) correct
suspension of processes to avoid stack corruption.
That is really difficult to make explicit manually in a script.


>
>
> Stef
>>>
>>>
>>> On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier
>>>  wrote:
>>> >
>>> >
>>> > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel :
>>> >>
>>> >> My four wishes, in no particular order:
>>> >> - Better code completion
>>> >> - Git in Pharo as easy as using Git for other languages
>>> >
>>> > The recipe is easy: turn pharo into a file based edit-compile-run
>>> language
>>> > and expunge those live object burden ;)
>>> > Let me explain why it's not just trolling.
>>> > Currently we have to download an image made by a bot.
>>> > Pharo has gradually lost the power to upgrade the image (it's not new).
>>> >
>>> > If we recognize that an image acts like a 

Re: [Pharo-dev] git and author/timestamps, 10000's of files, etc.

[Guillermo Polito]

On Sun, Jan 14, 2018 at 7:11 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> I've been skimming the ironically named "blame" thread and just want to
> clear up some apparent misconceptions.
>
> git/github is not the reason that the author/timestamps information was
> "lost" ... when tonel was introduced the author/timestamp info was not
> included in the format as a separately serialized file. filetree's
> implementation of author/timestamp support (around for almost 6 years now)
> was an annoying source of commit conflicts and often prevented automatic
> merges.
>
> git/github has perfectly functional blame support[1], so the decision to
> rely on git for supplying the author/timestamp for tonel was a sound
> decision. Thierry Goubier's GitFileTree[2] implementation does a very good
> job of converting git author/timestamp information into Monticello meta
> data, and is proof that author/timestamp information can be extracted from
> a git repository.
>
> AFAICT, the single issue here is that the code to link between git's
> author/timestamp information and the in-image author/timestamp information
> has not been written YET ...
>

Actually, I remember Esteban doing a prototype some months ago. The idea
was to query author/timestamp information from git just after
bootstrapping, and to embed this information in the resulting image.
The problem is that this approach was SUPER slow, because it had to blame
on each method. And increasing the build times is not very nice because it
kind of slows down the frequency of integrations, specially during sprints.

Now, each commit usually changes only a couple of methods, so
author/timestamp of methods will remain the same for 99.9% of the methods
most of the time. It would be possible to cache it and re-calculate the new
ones following the commit diff. At least this would restore the timestamp
of the methods found in the image.

A second point, and orthogonal to the previous one, would be to also manage
the "browse versions". Today the version browser queryies only the changes
file. I think it would make sense to do it by epicea files (for local
modifications) and then fallback to a git repository (if any) to give a
full history. Technically, it should not be difficult to do, except for the
detail that the repository was transformed at some point from filetree to
tonel, so blame will not quite work out of the box :).


> git/github is not the reason that there are "1000's of files on disk".
> Tonel uses a file per class format which significanly reduces the file
> count for Smalltalk repositories on disk. FileTree format uses a file per
> method format and for large projects leads to a large number of files,
> which in and of itself is not a problem (at least for git), but does lead
> to excessive disk space consumption.
>
> SmalltalkCI[2], which provides support for Smalltalk on travis-ci[3] and
> appveyory[4] was created by Fabio Niephaus an active member of the Squeak
> community. Travis-ci makes it possible to run cross-dialect tests to
> validate github pull requests and checkins[5] for cross-dialect projects.
>
> It seems that there are at least some (less vocal) members of the Squeak
> community who are interested in using git.
>
> Dale
>
> [1] https://www.git-scm.com/docs/git-blame
> [2] https://github.com/hpi-swa/smalltalkCI
> [3] https://travis-ci.org/
> [4] https://www.appveyor.com/
> [5] https://travis-ci.org/Metacello/metacello
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] git workflow (iceberg) and monticello packages

[Guillermo Polito]

On Sun, Feb 4, 2018 at 11:07 PM, Nicolai Hess  wrote:

> Hi ,
>
> I am still not sure I understand the git based development workflow.
>
> I set up my image and repository as described by the guide.
>
> now, if new commits are in the pharo-project, iceberg shows the list of
> incoming
> changes (commits). Ok, but:
>
> If I modify code in my image (for example, change a method in class Morph),
> the morphic-core package is marked as dirty in monticello and my
> pharo repository in iceberg is marked with an asterisk.
> If I choose "synchronize repository ..." I would expect my change to be an
> uncommited change, but instead, it isn't shown and the Morphic-core package
> isn't dirty anymore.
>
> Is it because I need to create a branch first ? But why is the
> Morphic-core package
> not dirty anymore, the change is not commited or published, how do I know
> where are my changes ?
>

No, that's a bug between the iceberg-monticello interaction. Iceberg does
not manage himself the detection of modified/dirty packages, he relies for
that on monticello.
And it happens from time to time that
 - a package is marked as dirty and it is not
 - a package is marked as cleand and it is not

both cases are confusing. I don't know if this comes from a bad usage of
the monticello API or something else...


>
>
> nicolai
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Cleaning up... baseClass, instanceSide, theNonMetaclass

[Guillermo Polito]

In my code I use to use instanceSide and classSide. don't know why. Maybe
they are clearer to me?

On Sun, Feb 11, 2018 at 8:59 PM, Denis Kudriashov 
wrote:

> 2018-02-11 18:14 GMT+01:00 Stephane Ducasse :
>
>> Hi
>>
>> We already got this discussion and I plan to address it.
>> Now I discovered that in addition to instanceSide and theNonMetaclass we
>> have
>>
>> - classClass and baseClass
>> - theMetaclass and theNonMetaclass
>> - instanceSide and classSide
>>
>> https://pharo.fogbugz.com/f/cases/20941/deprecate-theMetacla
>> ss-and-the-theNonMeta
>>
>> Even if instanceSide and classSide come from UI concerns I think that
>> there are much
>> better than the others.
>>
>
> + 100
>
>
>>
>> So have you any concerns and prefer one of the other couples? Because
>> we should stop
>> accumulate cruft in the system. We do not need three ways to do the same.
>>
>> Stef
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

[Guillermo Polito]

On Thu, Feb 8, 2018 at 6:28 AM, Ben Coman  wrote:

> Could the Iceberg gurus try and comment on the following workflow.
>
> Please familiarise with the first four commits here...
> https://github.com/Traadh/cloudflareun/network
>
> from these actions...
>
> "first commit" -- on github I created it as an unitialized repo to try
> to push a "new repo" to it per my other post, but when that failed
> from the command line I did `git init; git add README; git remote ...;
> git push ...`)
>
> "First Pharo code" -- cloned the repo with Iceberg, added a package,
> synchronised, added commit comment and clicked  master>
>
> "Update class comment" -- edited the class comment, then from Iceberg
> synchronised, added commit comment and clicked  master>
>
> "Updated README" -- on github, used the built-in editor to easily
> preview markdown.  Clicked its 
>
>
> PROBLEM...
>
> Now I'm at a point having trouble synchronising Iceberg to pick up
> that last change.
> 1. Right-clicked on "cloudflareun" and chose "Synchronise repository..."
> 2. In [Update] tab, clicked 
> and listed under [commits to be imported] is "Updated README". Good.
> 3. Then clicked on  which I expected would load that commit into
> the Image,
> and a new commit "Merge with ref/remotes/origin/master" showed up in
> [commit to be imported]
>
> So now I'm lost.
> It seems the  only operates on the disk?
> But why does it create a merge commit?
> It should have fast-forwarded.


> Checking from the command line, only shows the first three commits are
> common with the github network graph. The fourth commit is the new
> merge commit.
> $ git log
> commit f49c64a7751f95712acc30dab692fc7e85e0c810
> Merge: c818e9a 52ab6ac
> Author: Ben Coman 
> Date:   Thu Feb 8 11:55:34 2018 +0800
> Merge with refs/remotes/origin/master
>
> commit c818e9adebeb6be001b202aa48da009be97920eb
> Author: Ben Coman 
> Date:   Thu Feb 8 11:42:57 2018 +0800
> Update class comment.
>
> commit 6f2df89b219c56530412252ace96bc95eb78373a
> Author: Ben Coman 
> Date:   Thu Feb 8 11:37:01 2018 +0800
> First Pharo code
>
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> Checking the remote...
> $ git log origin/master
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> Whoops... not what I expected but I don't think that affected anything
> now.  Probably it was left over from early attempts to create a "new"
> "cloudflareun" repo.
>
> Try again...
> $ git remote --v
> origin g...@github.com:Traadh/cloudflareun.git (fetch)
> origin g...@github.com:Traadh/cloudflareun.git (push)
> traadh g...@github.com:Traadh/cloudflareun.git (fetch)
> traadh g...@github.com:Traadh/cloudflareun.git (push)
>
> $ git log traadh/master
> commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
> Author: Ben Coman 
> Date:   Thu Feb 8 11:54:20 2018 +0800
> Updated README
>
> commit c818e9adebeb6be001b202aa48da009be97920eb
> Author: Ben Coman 
> Date:   Thu Feb 8 11:42:57 2018 +0800
> Update class comment.
>
> commit 6f2df89b219c56530412252ace96bc95eb78373a
> Author: Ben Coman 
> Date:   Thu Feb 8 11:37:01 2018 +0800
> First Pharo code
>
> commit 52ab6ac696760a60fe56af57e45f2e2ceaaae35e
> Author: Ben Coman 
> Date:   Thu Feb 8 11:31:28 2018 +0800
> first commit
>
> So there are the four commits matching github.  So it seems that
> Iceberg's FETCH did the right thing updating the remote. But the disk
> working directory should have just fast-forwarded rather than merging.
>
> Now seeing both these commits...
> * Merge with ref/remotes/origin/master
> * Updated README
> in the one [New commits to be imported] seems to be mixing results
> from the working repo and the remote repo in a way that makes it hard
> to guess the consequence of any next action here.
>
> I do see a  option when I right-click on one of those
> commits.
> Perhaps the "load" means to load from the disk working directory into
> the Image(?) but its a bit hidden compared to the  and 
> that are buttons.
> It seems dangerous to take that action right now, since I guess the
> Image would diverge from the disk working directory.
>
>
> FIXING...
>
> What I ended up doing was remove the "merge commit" from the disk
> working directory
> $ git reset --hard HEAD^
>
> then opened a new Iceberg which for [Updates] only showed only the
> single commit  "Updated README" fetched into the remote repo.  Good.
> I right-clicked on that and did  which correctly
> fast-forwarded the disk working directory...
> $ git log
> commit 587bed95c4b8fb3986c9962c9206405c81c99e3d
> Author: Ben Coman 
> Date:   Thu Feb 8 11:54:20 2018 

Re: [Pharo-dev] VirtualMachine vs. Platform and Bootstrap

[Guillermo Polito]

On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann  wrote:

> Hi,
>
> 1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit
> (internally depending on wordSize):
>
>  Smalltalk vm is32Bit
>
>Anything OK on that side.
>
> 2. We can also query for the OPERATING SYSTEM we are running on using:
>
>  Smalltalk os
>
>and there are subclasses for OSPlatform like Win32Platform,
> Win64Platform as well as Unix32Platform,
>unix64Platform, ...
>
>But when I evaluate "Smalltalk os" in Pharo 7 Build #70552
>
>   2a) I receive a Win32Platform instance which means 32 bit although
> I'm running on a Win 64 system
>   2b) I receive a Unix32Platform instance which means 32 bit although
> I'm running on a Ubuntu 64 system
>
>I see this as a clear bug and very confusing
>

Yup.


>
> The reason for this behavior is simple: because I run with the 32 bit
> VM/image on these two 64 bit operating
> systems and in Pharo:
>
>   for 2a) the#isActivePlatform method ask the VM (???)for the platform
> name (which is Win32 then)
>
>   for 2b) the#isActivePlatform method also considers the word size from
> the VM (???)
>
> But to me the "os" should give me infos about the underlying operating
> system and is currently
> returning a wrong instance (because it falls back to querying about the
> running VM, not the real platform)
>
> This would be easy to fix with some UFFI calls (for instance piping from
> "uname -i" on Unix or "ver" on Windows).
> With UFFI I would also be able to give more and better infos in the
> platform hierarchy about the underlying OS.
>
> But doing this would introduce a dependency from the "Systems-Platforms"
> package to "UFFI" (and currently my
> understanding is that UFFI comes later)
>
> From what I understood from the comment in getPwdViaFFI:with we also would
> like to focus on a minimal dependency
> for bootstrap ... and only depend on FFI and not UFFI.
>

Well, but that's because the working directory is needed at bootstrap time.
Take into account that the packages that belong to the bootstrap are those
listed in

BaselineOfPharoBootstrap

System-Platforms is listed there, but maybe it is not so necessary? We
should check what are the usages of it.
In any case, what I'd say is that "stuff" that is not really needed at
bootstrap time should be loaded afterwards, maybe as a separate package
with extension methods?
And in that case you're free to go and use uFFI, that should be no problem.

Just take into account that uFFI is loaded by BaselineOfMorphicCore
nowadays.


>
> Any comments how we could deal with that best?
>
> Thx
> T.
>
>
>
>
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Guillermo Polito]

++999^1000 :)

On Fri, Feb 23, 2018 at 7:32 AM, Stephane Ducasse 
wrote:

> Thanks Sven
> I thought that suddenly I was an idiot.
>
>
> On Thu, Feb 22, 2018 at 11:47 AM, Sven Van Caekenberghe 
> wrote:
> >
> >
> >> On 22 Feb 2018, at 10:41, Clément Bera  wrote:
> >>
> >>
> >>
> >> On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <
> stepharo.s...@gmail.com> wrote:
> >> Clement
> >>
> >> can you open a bug entry so that we clean this situation?
> >>
> >>
> >> What is the bug?
> >
> > Having two selectors doing the same thing is bad and confuses everybody.
> So that is a 'bug'.
> >
> >> You want to merge the two selectors and break compatibility with
> frameworks using the removed one?
> >
> > Either we keep on adding cruft (or leaving cruft in place) in the sake
> of backwards compatibility or be do something about it. It is not hard to
> fix a couple of senders. It could be done more softly with a deprecation.
> >
> > Cleanups at the level of Object are particularly valuable.
> >
> >> Stef
> >>
> >> On Mon, Feb 19, 2018 at 12:43 PM, Clément Bera 
> wrote:
> >> > Hi,
> >> >
> >> > It seems the two methods have exactly the same behavior indeed.
> >> > valueWithPossibleArgs: anArray
> >> > valueWithEnoughArguments: anArray
> >> >
> >> > One was edited recently but I think it's only to change the comment,
> they're
> >> > both very old. My guess is that there are two for compatibility
> purpose (One
> >> > is the selector that is considered as the most relevant that should
> be used,
> >> > the other one is the one also present in other Smalltalks so we have
> it for
> >> > cross-Smalltalk librairies or something like that), but only one is
> really
> >> > needed. If you need only the concept for SOM-NS you can just
> implement one,
> >> > if you want to be compatible with different Smalltalk lib implement
> both.
> >> >
> >> > All use-cases of these methods I have found do not inject nils, they
> expect
> >> > the block to have a number of arguments of the block less or equal to
> the
> >> > number of parameters in the argument array. I would say they're used
> as
> >> > #cullWithArguments: but for some reason other selector names were
> preferred.
> >> >
> >> > Now, as you mentioned, these two methods are more than just
> >> > cullWithArguments: since they inject nils if there are not enough
> >> > parameters. To me it looks incorrect to do so because then while
> debugging
> >> > your code you will get issues due to those injected nils and it will
> be
> >> > tedious for the application programmer to track the problem down to
> these
> >> > two methods.
> >> >
> >> > There a few use-cases for nil injection though. Typically when
> changing
> >> > existing frameworks in multiple repositories, it may be that during
> the
> >> > update process the change to the caller is installed before the
> change of
> >> > the callee, and if the code is actually used (code in UI for
> instance),
> >> > injecting nils might avoid system break-down. Another use-case is for
> >> > compatibility with frameworks using the nil injection, but I can't
> find a
> >> > framework doing that right now.
> >> >
> >> > Honestly, I would not implement the nil injection, but maybe some one
> else
> >> > has a different point of view.
> >> >
> >> > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <
> smallt...@stefan-marr.de>
> >> > wrote:
> >> >>
> >> >> Hi:
> >> >>
> >> >> I am trying to understand the different between and perhaps origin of
> >> >> BlockClosure>>#valueWithPossibleArgs: and
> >> >> BlockClosure>>#valueWithEnoughArguments:
> >> >>
> >> >> I am trying to decide which of the two I need for SOMns.
> >> >>
> >> >> The first one has seen more recent changes, when looking at the
> Pharo 6.1
> >> >> download:
> >> >>
> >> >> valueWithPossibleArgs: anArray—>  2/12/2017 StephaneDucasse
> >> >> valueWithEnoughArguments: anArray —>  3/11/2001 nk
> >> >>
> >> >> While they have rather different implementations, they seem to behave
> >> >> identically, as far as I could tell using the following example:
> >> >>
> >> >> blocks := {
> >> >>   [ { } ].
> >> >>   [:a | { a } ].
> >> >>   [:a :b | { a. b } ].
> >> >>   [:a :b :c | { a. b. c } ]
> >> >> }.
> >> >>
> >> >> blocks collect: [:b | b valueWithPossibleArgs: {1}].
> >> >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}].
> >> >> blocks collect: [:b | b valueWithEnoughArguments: {1}].
> >> >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}].
> >> >>
> >> >> I was also wondering how they relate to #cull:*
> >> >>
> >> >> One of the major differences seems to be that valueWithP* and
> valueWithE*
> >> >> are both injecting nil for absent arguments, while normal #value*
> and #cull*
> >> >> methods signal an error.
> >> >> Is there a specific use case why one wouldn’t want to be strict here
> as
> >> >> well, but instead inject nils?
> >> >>
> >> >> Any comments or pointer 

Re: [Pharo-dev] Monticello file out bug during bootstrap

[Guillermo Polito]

Hi Alistair,

Can you provide some more context on what are you trying to do and how?

Generally you should not change anything in the bootstrap, just modify the
classes you want to modify and commit them into the repository. The
bootstrap will take care of it.

The only cases when you need to change bootstrap code are:
 - your code modifies the API of the class builder, the binary
representation of compiled methods, requires changing some class
initialization or if it adds/removes some VM special object (as the ones in
the special objects array)
 - you want to add a new package to pharo. In this case you need to add
your package to the repository and update the corresponding baseline so it
is loaded in the image (otherwise it will be in disk but ignored...)

Guille

On Sun, Feb 25, 2018 at 9:47 PM, Stephane Ducasse 
wrote:

> Now I do not understand what is this classSide here.
> If we have a trait apparently we do not file out a class method as
> class but as classSide Super strange.
>
> Stef
>
> On Sun, Feb 25, 2018 at 9:46 PM, Stephane Ducasse
>  wrote:
> > Apparently this method was like that in Pharo 60 so this is not my edit.
> >
> > fullClassName
> >"Using #class selector for classes for backwards compatibility"
> >
> >^ self classIsMeta
> >   ifFalse: [self className]
> >   ifTrue: [
> >   (self actualClass isNil or: [ self actualClass isTrait ])
> >   ifFalse: [self className, ' class']
> >   ifTrue: [self className, ' classSide']]
> >
> > Now it does not mean that this is not a bug I introduced.
> >
> >
> >
> >
> > On Sun, Feb 25, 2018 at 9:42 PM, Stephane Ducasse
> >  wrote:
> >> the problem is here of course but I need my mind back (In the train to
> >> home). ...
> >>
> >>
> >> MCMethodDefinition>>fullClassName
> >> "Using #class selector for classes for backwards compatibility"
> >>
> >> ^ self classIsMeta
> >> ifFalse: [self className]
> >> ifTrue: [
> >> (self actualClass isNil or: [ self actualClass isTrait ])
> >> ifFalse: [self className, ' class']
> >> ifTrue: [self className, ' classSide']]
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Feb 25, 2018 at 9:41 PM, Stephane Ducasse
> >>  wrote:
> >>> Hi Alistair
> >>>
> >>> This is my mistake! I introduced this bug when I transformed
> >>> theMetaClass to classSide
> >>> Now I was paying super attention and I did not touch theMetaClass even
> >>> when class would have been far enough.
> >>> So do you have a scenario? So that I can try to have a look.
> >>> Unfortunately I was away from home and lab since a week and I may have
> >>> problem to allocate concentrated time.
> >>> But I will try.
> >>> Tx for reporting this!
> >>>
> >>> Stef
> >>>
> >>>
> >>> On Sun, Feb 25, 2018 at 3:48 PM, Alistair Grant 
> wrote:
>  Hi Everyone,
> 
>  I'm working on integrating the file attribute primitives in to the
> main
>  code during bootstrap.
> 
>  Class methods for FileAttributesPluginPrims are written out as:
> 
> 
> 
>  !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp:
> 'nil'!
>  reset
>  "Reload the masks"
> 
>  Default := nil.! !
> 
> 
>  As you can see, the class name is written with "classSide" instead of
>  "class", resulting in the method quietly being ignored during file in.
> 
>  This comes about in:
> 
> 
>  MCStWriter>>writeMethodPreamble: definition
>  self chunkContents: [:str |
>  stream bang.
>  str nextPutAll: definition fullClassName;
>  nextPutAll: ' methodsFor: ';
>  nextPutAll: definition category asString printString;
>  nextPutAll: ' stamp: ';
>  nextPutAll: definition timeStamp asString printString
>  ]
> 
> 
>  which calls:
> 
> 
>  MCMethodDefinition>>fullClassName
>  "Using #class selector for classes for backwards compatibility"
> 
>  ^ self classIsMeta
>  ifFalse: [self className]
>  ifTrue: [
>  (self actualClass isNil or: [ self actualClass isTrait ])
>  ifFalse: [self className, ' class']
>  ifTrue: [self className, ' classSide']]
> 
> 
> 
>  Because FileAttributesPluginPrims doesn't exist in the image (the code
>  is read in from the git repository and being written out to a .st
> file),
>  #actualClass returns nil, resulting in "classSide" being used instead
> of
>  "class".
> 
>  I've never seen "classSide" used in chunk format.  Is there any time
>  "classSide" is valid, and any suggestions on how this should be fixed?
>  (My first thought is to just change MCStWriter>>writeMethodPreamble:
> 

Re: [Pharo-dev] Pull Request 20898-MultiByteFileStream-upToAll-does-not-work-correctly-with-UTF-8

[Guillermo Polito]

Well, It looks like when you read tonel files with your changes there are
some "invisible"  characters left over in the stream.

I think that first you should be able to reproduce the issue locally
without bootstrapping by trying to import a tonel file in an image with
your changes.
Just take any of the files inside Pharo's src/ directory and try:

reader := TonelReader on: stream fileName: '...'.
reader loadDefinitions.

Once with the monticello definitions you can try to compile them or check
if the source code in the methods have something strange...

If that fails, come back and we can do a skype trying to show you how to
bootstrap :)
Guille

On Sun, Feb 25, 2018 at 9:37 PM, Stephane Ducasse 
wrote:

> Hi bernhard
>
> sorry. Yes we should have a look.
>
> Stef
>
> On Sun, Feb 25, 2018 at 4:12 PM, Bernhard Pieber 
> wrote:
> > Hi all,
> >
> > Can somebody please help me get my bugfix from December integrated? For
> some reason CI fails and I have no idea how to debug that. :-(
> > https://github.com/pharo-project/pharo/pull/632
> >
> > Bernhard
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] "curl https://get.pharo.org/64 | bash" does not work (on Mac)

[Guillermo Polito]

These pages are wrong (at least):

http://pharo.org/download
https://pharo.org/gnu-linux-installation-64
https://pharo.org/gnu-linux-installation


On Sun, Feb 25, 2018 at 9:36 PM, Stephane Ducasse 
wrote:

> which page?
>
> https://pharo.fogbugz.com/f/cases/21407/should-update-
> curl-L-https-get-pharo-org-64-bash-to-have-the-L
>
> On Sun, Feb 25, 2018 at 5:49 PM, K K Subbu  wrote:
> > On Sunday 25 February 2018 09:54 PM, Bernhard Pieber wrote:
> >>
> >> Hi all,
> >>
> >> Here is the output:
> >>% Total% Received % Xferd  Average Speed   TimeTime Time
> >> Current
> >>   Dload  Upload   Total   SpentLeft
> >> Speed
> >> 100   237  100   2370 0899  0 --:--:-- --:--:-- --:--:--
> >> 901
> >> bash: line 1: syntax error near unexpected token `newline'
> >> bash: line 1: `'
> >>
> >> "curl https://get.pharo.org/64/ | bash" does work, though. It is just
> that
> >> in the documentation (https://get.pharo.org/64/) the link has no
> trailing
> >> slash.
> >
> >
> > The URL https://get.pharo.org/64 will return a 301 (Moved permanently)
> > redirect reply. Unlike wget, curl will follow the redirect only if -L
> option
> > is given, so
> >
> > curl -L https://get.pharo.org/64 | bash
> >
> > will also work fine. The document needs to be updated to use -L option
> for
> > curl.
> >
> > HTH .. Subbu
> >
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Vm-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

[Guillermo Polito]

I'll try making a PR now to fix that.

On Mon, Feb 26, 2018 at 10:19 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Hmm, wait, I think these are two different issues :)
>
> I managed to successfully use OSSubprocess in 64bits with some tweaks. The
> problem is that OSSubprocess does some manual type coertions like assumming
> 32 bits:
>
> collectArgumentPointersInto: aPointer
> [...]
> aPointer nbUInt32AtOffset: (self argVArguments size - 1) * self
> systemAccessor sizeOfPointer put: 0
>
> That should probably be replaced by:
>
> aPointer platformUnsignedLongAt: (self argVArguments size - 1) * self
> systemAccessor sizeOfPointer put: 0.
>
>
> Now, those methods depend on UFFI, having UFFI is a must for OSSubprocess.
>
> On Thu, Feb 22, 2018 at 7:07 PM, Alistair Grant <akgrant0...@gmail.com>
> wrote:
>
>>
>> Hi Eliot,
>>
>> On 21 February 2018 at 18:56, Eliot Miranda <eliot.mira...@gmail.com>
>> wrote:
>> >
>> > Hi Alistair,
>> >
>> > On Wed, Feb 21, 2018 at 9:31 AM, Alistair Grant <akgrant0...@gmail.com>
>> wrote:
>> >>
>> >> Yep, OSSubprocess doesn't work on 64 bit VMs at the moment.
>> >>
>> >> Eliot, Mariano has indicated he's waiting on
>> >> https://github.com/pharo-project/pharo-vm/pull/142
>> >> Do you know of a reason why it shouldn't be merged?
>> >
>> >
>> > Well, the changes to FilePlugin.class belong in VMMaker.oscog.
>>
>> Good point.  I'm embarrassed to say I didn't look at the code, just
>> the comments.
>>
>>
>> >  And cfileRecordSize doesn't make sense , since all pointers are of the
>> same size in C:
>> >
>> > cfileRecordSize
>> > + "Return the size of a stdio FILE* handle"
>> > + 
>> > + 
>> > + ^self sizeof: #'FILE*'
>> >
>> > I would simple use (self sizeof: #'void *') or (self sizeof: #'FILE *').
>>
>> Yep - although this could use .
>>
>>
>> > Other than that I can't see any problems.
>>
>> I've sent Mariano a message asking him to clarify what he needs from
>> this PR.  I'll follow up again after he replies (I'm keen to see
>> OSSubprocess on the 64 bit VM).
>>
>> Thanks!
>> Alistair
>>
>>
>> >>
>> >> Thanks,
>> >> Alistair
>> >>
>> >>
>> >>
>> >> On 21 February 2018 at 18:22, phideaux <jcas...@cdix.org> wrote:
>> >> > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit
>> you get a
>> >> > talkback because
>> >> > ExternalAddress integerAt:put:size:signed: fails using
>> >> > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims'
>> >> >
>> >> > Something to do with OSSubprocess not accommodating 64 bit pointers
>> perhaps?
>> >> >
>> >> > Same code works fine on 32bit version.
>> >> >
>> >> > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS
>> downloaded
>> >> > from pharo.org/downloaded page
>> >> >
>> >> > Regards,
>> >> > Jay+
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Sent from: http://forum.world.st/Pharo-Sm
>> alltalk-Developers-f1294837.html
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > _,,,^..^,,,_
>> > best, Eliot
>> >
>>
>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Vm-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

[Guillermo Polito]

Hmm, wait, I think these are two different issues :)

I managed to successfully use OSSubprocess in 64bits with some tweaks. The
problem is that OSSubprocess does some manual type coertions like assumming
32 bits:

collectArgumentPointersInto: aPointer
[...]
aPointer nbUInt32AtOffset: (self argVArguments size - 1) * self
systemAccessor sizeOfPointer put: 0

That should probably be replaced by:

aPointer platformUnsignedLongAt: (self argVArguments size - 1) * self
systemAccessor sizeOfPointer put: 0.


Now, those methods depend on UFFI, having UFFI is a must for OSSubprocess.

On Thu, Feb 22, 2018 at 7:07 PM, Alistair Grant 
wrote:

>
> Hi Eliot,
>
> On 21 February 2018 at 18:56, Eliot Miranda 
> wrote:
> >
> > Hi Alistair,
> >
> > On Wed, Feb 21, 2018 at 9:31 AM, Alistair Grant 
> wrote:
> >>
> >> Yep, OSSubprocess doesn't work on 64 bit VMs at the moment.
> >>
> >> Eliot, Mariano has indicated he's waiting on
> >> https://github.com/pharo-project/pharo-vm/pull/142
> >> Do you know of a reason why it shouldn't be merged?
> >
> >
> > Well, the changes to FilePlugin.class belong in VMMaker.oscog.
>
> Good point.  I'm embarrassed to say I didn't look at the code, just
> the comments.
>
>
> >  And cfileRecordSize doesn't make sense , since all pointers are of the
> same size in C:
> >
> > cfileRecordSize
> > + "Return the size of a stdio FILE* handle"
> > + 
> > + 
> > + ^self sizeof: #'FILE*'
> >
> > I would simple use (self sizeof: #'void *') or (self sizeof: #'FILE *').
>
> Yep - although this could use .
>
>
> > Other than that I can't see any problems.
>
> I've sent Mariano a message asking him to clarify what he needs from
> this PR.  I'll follow up again after he replies (I'm keen to see
> OSSubprocess on the 64 bit VM).
>
> Thanks!
> Alistair
>
>
> >>
> >> Thanks,
> >> Alistair
> >>
> >>
> >>
> >> On 21 February 2018 at 18:22, phideaux  wrote:
> >> > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit you
> get a
> >> > talkback because
> >> > ExternalAddress integerAt:put:size:signed: fails using
> >> > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims'
> >> >
> >> > Something to do with OSSubprocess not accommodating 64 bit pointers
> perhaps?
> >> >
> >> > Same code works fine on 32bit version.
> >> >
> >> > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS
> downloaded
> >> > from pharo.org/downloaded page
> >> >
> >> > Regards,
> >> > Jay+
> >> >
> >> >
> >> >
> >> > --
> >> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >> >
> >>
> >
> >
> >
> > --
> > _,,,^..^,,,_
> > best, Eliot
> >
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Updating CI plugins

[Guillermo Polito]

Jenkins and slaves are up un running. Let's cross fingers hoping everything
is ok :)

Keep you updated

On Fri, Dec 22, 2017 at 10:14 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Christophe is also taking benefit of this to update jenkins from 2.32.3
> LTS to 2.89.2 LTS
>
> On Fri, Dec 22, 2017 at 10:06 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> Hi all,
>>
>> I'm updating CI plugins. *This will require a CI restart. *The
>> corresponding issue is here:
>>
>> https://pharo.fogbugz.com/f/cases/20884/Update-CI-Plugins
>>
>> The installed versions are the following:
>>
>> Workspace Cleanup Plugin 0.34 0.33
>> SCM API Plugin 2.2.6 2.2.1
>> Pipeline Utility Steps 1.5.1 1.4.1
>> Pipeline: API 2.24 2.20
>> Pipeline: Build Step 2.6 2.5.1
>> Pipeline: Declarative 1.2.5 1.1.9
>> Pipeline: Declarative Extension Points API 1.2.5 1.1.9
>> Pipeline: Groovy 2.41 2.40
>> Pipeline: Model API 1.2.5 1.1.9
>> Pipeline: Nodes and Processes 2.16 2.15
>> Pipeline: Shared Groovy Libraries 2.9 2.8
>> Pipeline: Stage Step 2.3 2.2
>> Pipeline: Stage Tags Metadata 1.2.5 1.1.9
>> Pipeline: Step API 2.14 2.12
>> Rebuilder 1.27 1.25
>> JUnit Plugin 1.23 1.21
>> Git client plugin 2.7.0 2.5.0
>> Git plugin 3.6.4 3.5.1
>> GitHub API Plugin 1.90 1.86
>> GitHub Branch Source Plugin 2.3.2 2.2.3
>> GitHub plugin 1.28.1 1.28.0
>> Copy Artifact Plugin 1.39 1.38.1
>> Credentials Plugin 2.1.16 2.1.15
>> Build Timeout 1.19 1.18
>> Conditional BuildStep 1.3.6 1.3.5
>>
>> I'll keep you updated as soon as the update is finished.
>> Guille
>>
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>> Research Engineer
>>
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>
>> CRIStAL - UMR 9189
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Guillermo Polito]

Hi,

About why 1.1.1 and not 1.2.0. It's not about cheap or not, but about
semantics :)
We can agree that there is no hard rule on versionning, do we? But I try to
follow the following guidelines (delta my own interpretation that adds some
subjectivity :P)
- Major Version will change when we break backwards compatibility
- Minor Version will change when new features are added
- Otherwise, patch version will change.

So I don't assign a new version number regarding the number of changes but
about what they mean...
Now, I considered myself this release as a patch because mostly little bugs
here and there were fixed.
Moreover, one of the changes done in the credentials manager was to
*recover* some backwards compatibility for people setting up credentials in
settings files.
Of course, to this we add to this that my own interpretation saying that
the changes do not break compatibility nor add features :)

Now, this is the kind of subjective topic that starts a flamewar, but I'd
prefer to use my time on somewhat else ^^.
In any case, I think it is more important to discuss about the numbering as
soon as we have a clear documentation on Iceberg's API...

Regarding the bad links, I copy-pasted the text from the PR instead from
the release page in Iceberg, which messes up links.

Patch version containing the following cleanups and enhancements

#864 <https://github.com/pharo-vcs/iceberg/issues/864> Repairing Missing
repositories lead to wrong source directory
#861 <https://github.com/pharo-vcs/iceberg/pull/861> update tonel to v1.0.9
#836 <https://github.com/pharo-vcs/iceberg/issues/836> DefaultBackendType
class variable is unused
#862 <https://github.com/pharo-vcs/iceberg/issues/862> Iceberg tests are
not running in Pharo 7
#852 <https://github.com/pharo-vcs/iceberg/issues/852> Make error dialogs
copy-pastable
#858 <https://github.com/pharo-vcs/iceberg/issues/858> IceTipReadOnlyTextMorph
does not allow select and copy anymore
#850 <https://github.com/pharo-vcs/iceberg/issues/850> Change Detached head
status from error to warning if we are on a tag
#853 <https://github.com/pharo-vcs/iceberg/issues/853> Clone dialog
"username" is confusing
#860 <https://github.com/pharo-vcs/iceberg/pull/860> CredentialStore API
#854 <https://github.com/pharo-vcs/iceberg/issues/854> Error in History
window

Guille

On Mon, Jun 18, 2018 at 9:12 PM Torsten Bergmann  wrote:

> Great - thank you! Might be a small patch release - but nonetheless
> important.
>
> BTW: the links in your mail are pointing to PR's of Pharo and not Iceberg.
> If you used
>  a template you might want to consider changing it.
>
>
> *Gesendet:* Montag, 18. Juni 2018 um 17:47 Uhr
> *Von:* "Guillermo Polito" 
> *An:* "Any question about pharo is welcome" ,
> "Discusses Development of Pharo" 
> *Betreff:* [Pharo-dev] [Ann] Iceberg v1.1.1
> Hi everybody,
>
> This week we have a small patch release of Iceberg, version v1.1.1.
> This version will be available in the next Pharo build.
>
> In summary, this release fixes two issues with the new credentials
> manager, and introduces a couple of other enhancements/bugfixes.
>
> Below you will find the detailed changes log.
> Enjoy,
> Guille
>
>
> Integrate Iceberg 1.1.1
> https://pharo.fogbugz.com/f/cases/22168/Integrate-Iceberg-1-1-1
>
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.1.1
>
> #864 <https://github.com/pharo-project/pharo/pull/864> Repairing Missing
> repositories lead to wrong source directory
> #861 <https://github.com/pharo-project/pharo/pull/861> update tonel to
> v1.0.9
> #836 <https://github.com/pharo-project/pharo/pull/836> DefaultBackendType
> class variable is unused
> #862 <https://github.com/pharo-project/pharo/pull/862> Iceberg tests are
> not running in Pharo 7
> #852 <https://github.com/pharo-project/pharo/pull/852> Make error dialogs
> copy-pastable
> #858 <https://github.com/pharo-project/pharo/pull/858> IceTipReadOnlyTextMorph
> does not allow select and copy anymore
> #850 <https://github.com/pharo-project/pharo/pull/850> Change Detached
> head status from error to warning if we are on a tag
> #853 <https://github.com/pharo-project/pharo/pull/853> Clone dialog
> "username" is confusing
> #860 <https://github.com/pharo-project/pharo/pull/860> CredentialStore API
> #854 <https://github.com/pharo-project/pharo/pull/854> Error in History
> window
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
>
&

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

[Guillermo Polito]

Hi,

I don't know the windows situation at all, but I'm wondering.

([ File stdioDescriptorIsATTY not ]
on: PrimitiveFailed
do: [ :ex | "HACK kept for retrocompatibility" Smalltalk os isWin32 ])
ifTrue: [ ^ self createStdioFileFor: moniker ].

the first thing I would do, just trying to keep the same behaviour, is to
invert the test... Something like

Smalltalk os isWin32 ifTrue: [
[ File stdioDescriptorIsATTY not ]
on: PrimitiveFailed
do: [ :ex | false ])
ifTrue: [ ^ self createStdioFileFor: moniker ]. ]

Like that, this would only penalise windows in the worst case. Then a first
question arises in my head: why isWin32 and not isWindows? Is there a
reason behind that? Wouldn't that prevent correct behaviour in windows 64
bits?

My next impression is that testing for "a TTY or a file or a pipe" seems
buggy... We should put a more intention revealing selector like
#isInvalidStdioHandle?
A more high level test will allow us to do any check we want in the
background, and it allows better to understand why we check for TTY or File
or Pipe or la mar en coche :)

On Thu, Aug 2, 2018 at 8:54 PM Alistair Grant  wrote:

> File class>>stdioHandles calls primitiveFileStdioHandles() which
> eventually opens the stdio streams (if possible) using the Windows
> native GetStdHandle() function.
>

What does #stdioHandles return to the image in the case of a non-console
windows VM? I mean, when "it is not possible"?

>From the docs, https://docs.microsoft.com/en-us/windows/console/getstdhandle
says we may have an INVALID_HANDLE_VALUE or NULL in case it fails.
Is the file plugin is masking the error? If so, thats why we need such
strange workarounds...

 - If it is an invalid handle, why not just testing for "isInvalidHandle"
or so? We can have that on the image side and then dispatch to the correct
thing in the file plugin maybe?

 - Maybe the #stdioHandles primitive should just fail in the case we don't
have correct handles? that would allow us to do a much more elegant
approach on the image side...

> I suspect File needs a nameless variant (I'm not certain how pipes
> > work in unix but I doubt echo foo | cat ever touches the filesystem)
>
> That's my understanding (it doesn't touch the file system).
>
>
Well... I see this is just a aesthetic issue and I don't see how this is
related to the above more serious issue...

Re: [Pharo-dev] CI Issue on PR

[Guillermo Polito]

Just FYI, Pablo has answered in the PR.
In short, adding new packages means adding them also in the baselines,
otherwise metacello does not load them.

On Wed, Aug 1, 2018 at 6:48 AM Eric Gade  wrote:

> Hello all,
>
> I'm having a strange issue with CI on my recent pull request. See
> https://github.com/pharo-project/pharo/pull/1666#issuecomment-409431721
>
> The short if it is that tests are failing because it seems some of the new
> classes I created are not being loaded into whatever CI is doing. Those
> classes are clearly in the commits however. Not sure how to handle this.
> It's entirely possible I messed up a part of this process.
>
> Any suggestions?
>
> --
> Eric
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Problem with Iceberg and Working Branches

[Guillermo Polito]

Hi!

On Wed, Aug 1, 2018 at 1:30 PM Eric Gade  wrote:

> I have already mentioned some of this on Discord so forgive me for being
> redundant if you've seen it.
>
> I'm having problems loading into the latest P7 images from Launcher a
> working branch of Pharo that I have forked. I perform the following steps:
>

I'll try to reproduce it, but meanwhile.


> 1. "Repair" the missing local repository for Pharo and load from my forked
> version on Github
> 2. Now in the "detached working copy" state, I repair again
> 3. This time I select "Discard local changes and checkout existing
> branch". I select my working branch from the remotes
>

I have a remark on this step, that should be known and understood by people
contributing Pharo.
- When you download an image, that image knows from which commit it was
built. This is done on purpose so then you can continue working from
exactly that commit (less merge problems, do not need to update your live
image...).
- Every week some tenths of pull requests are integrated in Pharo, so
loading the Pharo7 image of today will give you an image compleeetely
different from the one you worked with one week ago.

What this means, is that if you checkout an old branch, Iceberg will try to
"downgrade" all your packages to your branch's version, and that may not
always work, because while updating pharo packages you may break running
code and running instances (take into account you have several processes
running). This is the same problem of the old "Software update" option in
Pharo that was deprecated and removed some time ago already. And this is
why in general we do not recommend nowadays to update a pharo image through
iceberg, because you cause a kind of self brain-surgery scenario.

This is why also we DO recommend, when you start with a new image to
"create a new branch from the image commit". Because this option makes you
work on a branch that is 100% in sync with your Pharo image and it will
just simplify your life :).

For your particular use case (have a new image and want to keep working on
an old pharo branch), I'd suggest that instead of doing "Discard local
changes and checkout existing branch" you do
 - load your fork
 - create *new* branch from image
 - merge your old branch into this new one

That will be by far less disruptive.


> 4. It will attempt to load, but eventually a popup appears (not a normal
> error) that simply says "origin: Error" and "Assertion failed".
>

You have the popup with the "Ignore" and "Debug" options? Could you click
on "Debug" and share your stack trace?


>
> I'm not sure what's going on, since this procedure seemed to work a week
> or so ago if I remember correctly. As of a couple of days ago I can no
> longer load (ie work on) my working branch.
>

Well, this is for sure related to what I described above, using a new image
with an old branch


>
> I figure I'm doing something wrong, but need to know what.
>

Maybe not, and it's just a matter of a complex scenario + an unexpected
case in iceberg (thus the assertion).

Keep us updated to see if we can help you,
Guille

Re: [Pharo-dev] Problem with Iceberg and Working Branches

[Guillermo Polito]

Ah, just in case I add to what I say: this particular tricky scenario is
specific for Pharo and contributing to Pharo.

Any third party project/library will not have the constraints described in
my previous email.

On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito 
wrote:

> Hi!
>
> On Wed, Aug 1, 2018 at 1:30 PM Eric Gade  wrote:
>
>> I have already mentioned some of this on Discord so forgive me for being
>> redundant if you've seen it.
>>
>> I'm having problems loading into the latest P7 images from Launcher a
>> working branch of Pharo that I have forked. I perform the following steps:
>>
>
> I'll try to reproduce it, but meanwhile.
>
>
>> 1. "Repair" the missing local repository for Pharo and load from my
>> forked version on Github
>> 2. Now in the "detached working copy" state, I repair again
>> 3. This time I select "Discard local changes and checkout existing
>> branch". I select my working branch from the remotes
>>
>
> I have a remark on this step, that should be known and understood by
> people contributing Pharo.
> - When you download an image, that image knows from which commit it was
> built. This is done on purpose so then you can continue working from
> exactly that commit (less merge problems, do not need to update your live
> image...).
> - Every week some tenths of pull requests are integrated in Pharo, so
> loading the Pharo7 image of today will give you an image compleeetely
> different from the one you worked with one week ago.
>
> What this means, is that if you checkout an old branch, Iceberg will try
> to "downgrade" all your packages to your branch's version, and that may not
> always work, because while updating pharo packages you may break running
> code and running instances (take into account you have several processes
> running). This is the same problem of the old "Software update" option in
> Pharo that was deprecated and removed some time ago already. And this is
> why in general we do not recommend nowadays to update a pharo image through
> iceberg, because you cause a kind of self brain-surgery scenario.
>
> This is why also we DO recommend, when you start with a new image to
> "create a new branch from the image commit". Because this option makes you
> work on a branch that is 100% in sync with your Pharo image and it will
> just simplify your life :).
>
> For your particular use case (have a new image and want to keep working on
> an old pharo branch), I'd suggest that instead of doing "Discard local
> changes and checkout existing branch" you do
>  - load your fork
>  - create *new* branch from image
>  - merge your old branch into this new one
>
> That will be by far less disruptive.
>
>
>> 4. It will attempt to load, but eventually a popup appears (not a normal
>> error) that simply says "origin: Error" and "Assertion failed".
>>
>
> You have the popup with the "Ignore" and "Debug" options? Could you click
> on "Debug" and share your stack trace?
>
>
>>
>> I'm not sure what's going on, since this procedure seemed to work a week
>> or so ago if I remember correctly. As of a couple of days ago I can no
>> longer load (ie work on) my working branch.
>>
>
> Well, this is for sure related to what I described above, using a new
> image with an old branch
>
>
>>
>> I figure I'm doing something wrong, but need to know what.
>>
>
> Maybe not, and it's just a matter of a complex scenario + an unexpected
> case in iceberg (thus the assertion).
>
> Keep us updated to see if we can help you,
> Guille
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Problem with Iceberg and Working Branches

[Guillermo Polito]

On Wed, Aug 1, 2018 at 2:02 PM Eric Gade  wrote:

> Every week some tenths of pull requests are integrated in Pharo, so
>> loading the Pharo7 image of today will give you an image compleeetely
>> different from the one you worked with one week ago.
>>
>
> This is something I'm used to from the non-Pharo Git world. Normally I
> would do what it called "rebasing," which essentially replays any commits
> on my branch atop the HEAD of the current master branch. In cases where you
> know that the things you're working on are unlikely to have changed in the
> meantime, this tends to work most of the time.
>

Well we do not support rebase in iceberg yet. In part because we would like
to keep the UI as simple as possible (because lots of people do not really
know git) and in part because I personally believe rebase as an evil
feature that people tend to overuse. (That does not mean that rebase is bad
in itself, I actually use it myself from time to time, but I'm strongly
against rewriting public commits/history).


>
>
>> For your particular use case (have a new image and want to keep working
>> on an old pharo branch), I'd suggest that instead of doing "Discard
>> local changes and checkout existing branch" you do
>>
>
> I'll give this a shot in a little bit and let you know if it works.
>

Cool!

>
>
>> You have the popup with the "Ignore" and "Debug" options? Could you click
>> on "Debug" and share your stack trace?
>>
>
> No. This is not the normal error popup. It's more like a little dialog
> that only has text and an OK button. However, I was able to go into the
> repository via Iceberg and attempt to checkout the branch from origin
> directly. That did give me a normal error and I do have a fuel dump of the
> stack. Unfortunately it is too big to attach to emails to this list.
>

If you want, send me a dropbox link or something like that personally...


>
> I will send a follow up message with the attachment, but it will need mod
> approval.
>
> On Wed, Aug 1, 2018 at 7:52 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> Ah, just in case I add to what I say: this particular tricky scenario is
>> specific for Pharo and contributing to Pharo.
>>
>> Any third party project/library will not have the constraints described
>> in my previous email.
>>
>> On Wed, Aug 1, 2018 at 1:48 PM Guillermo Polito <
>> guillermopol...@gmail.com> wrote:
>>
>>> Hi!
>>>
>>> On Wed, Aug 1, 2018 at 1:30 PM Eric Gade  wrote:
>>>
>>>> I have already mentioned some of this on Discord so forgive me for
>>>> being redundant if you've seen it.
>>>>
>>>> I'm having problems loading into the latest P7 images from Launcher a
>>>> working branch of Pharo that I have forked. I perform the following steps:
>>>>
>>>
>>> I'll try to reproduce it, but meanwhile.
>>>
>>>
>>>> 1. "Repair" the missing local repository for Pharo and load from my
>>>> forked version on Github
>>>> 2. Now in the "detached working copy" state, I repair again
>>>> 3. This time I select "Discard local changes and checkout existing
>>>> branch". I select my working branch from the remotes
>>>>
>>>
>>> I have a remark on this step, that should be known and understood by
>>> people contributing Pharo.
>>> - When you download an image, that image knows from which commit it was
>>> built. This is done on purpose so then you can continue working from
>>> exactly that commit (less merge problems, do not need to update your live
>>> image...).
>>> - Every week some tenths of pull requests are integrated in Pharo, so
>>> loading the Pharo7 image of today will give you an image compleeetely
>>> different from the one you worked with one week ago.
>>>
>>> What this means, is that if you checkout an old branch, Iceberg will try
>>> to "downgrade" all your packages to your branch's version, and that may not
>>> always work, because while updating pharo packages you may break running
>>> code and running instances (take into account you have several processes
>>> running). This is the same problem of the old "Software update" option in
>>> Pharo that was deprecated and removed some time ago already. And this is
>>> why in general we do not recommend nowadays to update a pharo image through
>>> iceberg, because you cause a kind of self brain-surgery scenario.
>>>
>&g

Re: [Pharo-dev] Iceberg: Cannot Clone Pharo Repository

[Guillermo Polito]

As a workaround, maybe you can try updating your fork before cloning it
from Iceberg?

$ git clone yourFork
$ git pull from-pharo
$ git push

On Mon, Aug 6, 2018 at 10:26 AM Guillermo Polito 
wrote:

> Hi Eric,
>
> Thanks for the report. I'm looking into it.
>
> On Sun, Aug 5, 2018 at 6:20 PM Eric Gade  wrote:
>
>> I am having (new) issues cloning my forked pharo repository in a fresh P7
>> image for development. Git objects are pulled from the repository
>> successfully, but during the checkout phase the error posted below occurs
>> (I can also provide a fuel dump by request).
>>
>> Here is my current system:
>> OSX 10.13.1 (High Sierra)
>> Pharo 7.0
>> Build information:
>> Pharo-7.0+alpha.build.1159.sha.65cff7b3c78af7ecf3728abdd2f44bf0cbc8a548 (32
>> Bit)
>>
>> My fork:
>> https://github.com/darth-cheney/pharo
>>
>> Error Stack:
>>
>> ```
>> IceUnknownCommit(Object)>>doesNotUnderstand: #adopt
>> IcePharoPlugin>>repositoryWillBeCreated:
>> [ :each | each repositoryWillBeCreated: aRepository ] in
>> IcePluginManager>>repositoryWillBeCreated: in Block: [ :each | each
>> repositoryWillBeCreated: aRepositor...etc...
>> Array(SequenceableCollection)>>do:
>> IcePluginManager>>repositoryWillBeCreated:
>> IceRepositoryCreator>>cloneRepository
>> [ self validate.
>> self isCloning
>> ifTrue: [ self cloneRepository ]
>> ifFalse: [ self addLocalRepository ] ] in
>> IceRepositoryCreator>>createRepository in Block: [ self validate
>> BlockClosure>>on:do:
>> IceRepositoryCreator>>createRepository
>> [ ^ IceRepositoryCreator new
>> repository: repository;
>> remote: (IceGitRemote url: self remoteUrl);
>> location: self projectLocation location;
>> createRepository ] in
>> IceTipGitHubRepositoryPanel(IceTipGitRepositoryPanel)>>newRepository in
>> Block: [ ^ IceRepositoryCreator new...
>> [ :bar |
>> bar label: aString.
>> aBlock value ] in MorphicUIManager(UIManager)>>informUser:during: in
>> Block: [ :bar | ...
>> [ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in
>> Block: [ :bar | aBlock value: bar ]
>> BlockClosure>>cull:
>> [ ^ block cull: self ] in [ self prepareForRunning.
>> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in
>> Block: [ ^ block cull: self ]
>> [ activeProcess psValueAt: index put: anObject.
>> aBlock value ] in CurrentJob(DynamicVariable)>>value:during: in Block: [
>> activeProcess psValueAt: index put: anObject
>> BlockClosure>>ensure:
>> CurrentJob(DynamicVariable)>>value:during:
>> CurrentJob class(DynamicVariable class)>>value:during:
>> [ self prepareForRunning.
>> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in
>> Block: [ self prepareForRunning
>> BlockClosure>>ensure:
>> Job>>run
>> MorphicUIManager(UIManager)>>displayProgress:from:to:during:
>> MorphicUIManager>>informUserDuring:
>> MorphicUIManager(UIManager)>>informUser:during:
>> IceTipGitHubRepositoryPanel(IceTipGitRepositoryPanel)>>newRepository
>> IceTipGitHubRepositoryPanel>>newRepository
>> IceTipRegisterRepositoryDialog>>doAccept
>> [ self doAccept.
>> true ] in IceTipRegisterRepositoryDialog(IceTipOptionDialog)>>accept in
>> Block: [ self doAccept
>> BlockClosure>>on:do:
>> IceTipRegisterRepositoryDialog(IceTipOptionDialog)>>accept
>> ```
>>
>> --
>> Eric
>>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [rmod] About the infinite debugger

[Guillermo Polito]

Hi Tim,

Are you on Pharo 6 or 7? If in 7, what build are you using?

Pablo and Santi have made a fix 2 fridays ago (that I presume got
integrated last week). The fix consists on changing a bit the exception
handling during exception handling.

https://github.com/pharo-project/pharo/pull/1621/files

The fix seems simple, but it has a lot of information contained on it (like
the fact that the system introduces exception handlers in the middle of the
stack transparently to manage errors while stepping, or the fact that
UnhandledError does another traversal of the stack but needs to start at
the good place...). The Exception tests we had are still green, and we can
now do stepping on code that raises exceptions. When stepping inside the
DNU multiple times the debugging experience is not as smooth as the one in
Pharo 3 (before it got broken) but this is FAR BETTER than Pharo7 since we
have not experienced new infinite debuggers anymore :)...

I'll let Pablo and Santi answer more properly with the technical details.

On my side, I think we need to better document and do some more unit tests
on that dark part of the system :).

On Mon, Aug 6, 2018 at 8:50 AM Stéphane Ducasse 
wrote:

> Hi tim
>
> We know and we made huge progress because before we could not even
> reproduce it.
> We spent some times on it. I thought the solution found by pablo and
> santiago got integrated.
>
> Stef
>
> Guys - this really needs attention - I’ve spend hours now trying to debug
> some code and most of it is in closing infinite debuggers. It makes a
> mockery of our tagline - “awesome debugging”. And the extra irony is that
> I’m debugging some file path stuff for exercism, to make it easier for
> hopefully more people to learn Pharo.
>
> How can we get this fixed?
>
> Tim
>
> On 2 Aug 2018, at 21:44, Norbert Hartl  wrote:
>
> bump
>
> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>
> On 07/03/2018 05:02 PM, Martin McClure wrote:
>
> On 06/29/2018 07:48 AM, Guillermo Polito wrote:
> I know that the exception handling/debugging has been modified several
> times in the latest years (some refactorings, hiding contexts...), we
> unfortunately don't have tests for it, so I'd like some more pair of
> eyes on it. Ben, Martin could you take a look?
>
> Hi Guille,
> I'm just back from vacation last week, and about to go on vacation for
> another week, but I'll see what I can see.
> About the primitive pragmas for context-marking, I think some of those
> were changed for the exception handling fix that Andres and I did a few
> years back, so *could* be involved in this. I'd hate to see regression
> in the exception handling in an attempt to fix this bug.
>
>
> After a look at at the pull request, I'm quite sure that removing the
> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
> it! The start of execution of exception handlers must be marked in order
> for #findNextHandlerContext to work correctly. If these contexts are not
> marked, exceptions signaled from inside an exception handler can find
> the wrong handler. See the code and comment in #findNextHandlerContext.
>
> I'm afraid that I cannot immediately help with the debugger problem,
> since I don't know the debugger nearly as well as I do the exception
> handling code, and I'm going on vacation for a week in 20 minutes. :-)
> Perhaps when I get back I can take a look at it if it is still a problem
> by then.
>
> Regards,
> -Martin
>
>
>
>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>

-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] About the infinite debugger

[Guillermo Polito]

Hi Steven,

The thing about your fix was mainly that it only worked for the case of
running tests. We could however reproduce this bug from a playground too.

At first, replacing #pass to #debug looked like a hack to me :) Just
looking at the code of  runCaseForDebug:, I felt the correct thing to do
there was to use #pass (and let any potential caller handle the exception
if he wants).
Otherwise, we should be able to understand:
 - can #pass be used? is it buggy?
 - does it work on any case or it should be avoided in some cases?
 - and how can we fix it (or at least document it?)?

But still, I think you were in the right direction too, because your fix
shows a good intuition too: both #pass and #debug will do different things
with the exception.
-  #pass will **resignal** it from the current context,
-  #debug will just open a debugger on it.

So that means that probably there was a problem when the exception was
handled in a calling context.



On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou 
wrote:

> Hi,
>
> i had no answer to my comments on fogbuz (one of the first) so i assumed
> it was not a good idea.
>
> In the usecases i used to reproduce the bug, replacing "ex pass" by "ex
> debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz.
>
> Did not have any side effect, but i do not know enough about the system
> and maybe it does. I think i already asked about that somewhere (here or on
> discord) but no answers.
>
> But maybe it is wrong to do that? I'd be happy to have feedback on that.
>
> Steven.
>
> Le 2018-08-05 22:27, Tim Mackinnon a écrit :
>
> Guys - this really needs attention - I've spend hours now trying to debug
> some code and most of it is in closing infinite debuggers. It makes a
> mockery of our tagline - "awesome debugging". And the extra irony is that
> I'm debugging some file path stuff for exercism, to make it easier for
> hopefully more people to learn Pharo.
>
> How can we get this fixed?
>
> Tim
>
> On 2 Aug 2018, at 21:44, Norbert Hartl  wrote:
>
> bump
>
> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>
> On 07/03/2018 05:02 PM, Martin McClure wrote:
>
> On 06/29/2018 07:48 AM, Guillermo Polito wrote:
> I know that the exception handling/debugging has been modified several
> times in the latest years (some refactorings, hiding contexts...), we
> unfortunately don't have tests for it, so I'd like some more pair of
> eyes on it. Ben, Martin could you take a look?
>
> Hi Guille,
> I'm just back from vacation last week, and about to go on vacation for
> another week, but I'll see what I can see.
> About the primitive pragmas for context-marking, I think some of those
> were changed for the exception handling fix that Andres and I did a few
> years back, so *could* be involved in this. I'd hate to see regression
> in the exception handling in an attempt to fix this bug.
>
>
> After a look at at the pull request, I'm quite sure that removing the
> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring
> it! The start of execution of exception handlers must be marked in order
> for #findNextHandlerContext to work correctly. If these contexts are not
> marked, exceptions signaled from inside an exception handler can find
> the wrong handler. See the code and comment in #findNextHandlerContext.
>
> I'm afraid that I cannot immediately help with the debugger problem,
> since I don't know the debugger nearly as well as I do the exception
> handling code, and I'm going on vacation for a week in 20 minutes. :-)
> Perhaps when I get back I can take a look at it if it is still a problem
> by then.
>
> Regards,
> -Martin
>
>
>
>


-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Iceberg: Cannot Clone Pharo Repository

[Guillermo Polito]

Hi Eric,

Thanks for the report. I'm looking into it.

On Sun, Aug 5, 2018 at 6:20 PM Eric Gade  wrote:

> I am having (new) issues cloning my forked pharo repository in a fresh P7
> image for development. Git objects are pulled from the repository
> successfully, but during the checkout phase the error posted below occurs
> (I can also provide a fuel dump by request).
>
> Here is my current system:
> OSX 10.13.1 (High Sierra)
> Pharo 7.0
> Build information:
> Pharo-7.0+alpha.build.1159.sha.65cff7b3c78af7ecf3728abdd2f44bf0cbc8a548 (32
> Bit)
>
> My fork:
> https://github.com/darth-cheney/pharo
>
> Error Stack:
>
> ```
> IceUnknownCommit(Object)>>doesNotUnderstand: #adopt
> IcePharoPlugin>>repositoryWillBeCreated:
> [ :each | each repositoryWillBeCreated: aRepository ] in
> IcePluginManager>>repositoryWillBeCreated: in Block: [ :each | each
> repositoryWillBeCreated: aRepositor...etc...
> Array(SequenceableCollection)>>do:
> IcePluginManager>>repositoryWillBeCreated:
> IceRepositoryCreator>>cloneRepository
> [ self validate.
> self isCloning
> ifTrue: [ self cloneRepository ]
> ifFalse: [ self addLocalRepository ] ] in
> IceRepositoryCreator>>createRepository in Block: [ self validate
> BlockClosure>>on:do:
> IceRepositoryCreator>>createRepository
> [ ^ IceRepositoryCreator new
> repository: repository;
> remote: (IceGitRemote url: self remoteUrl);
> location: self projectLocation location;
> createRepository ] in
> IceTipGitHubRepositoryPanel(IceTipGitRepositoryPanel)>>newRepository in
> Block: [ ^ IceRepositoryCreator new...
> [ :bar |
> bar label: aString.
> aBlock value ] in MorphicUIManager(UIManager)>>informUser:during: in
> Block: [ :bar | ...
> [ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in
> Block: [ :bar | aBlock value: bar ]
> BlockClosure>>cull:
> [ ^ block cull: self ] in [ self prepareForRunning.
> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in
> Block: [ ^ block cull: self ]
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in CurrentJob(DynamicVariable)>>value:during: in Block: [
> activeProcess psValueAt: index put: anObject
> BlockClosure>>ensure:
> CurrentJob(DynamicVariable)>>value:during:
> CurrentJob class(DynamicVariable class)>>value:during:
> [ self prepareForRunning.
> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in
> Block: [ self prepareForRunning
> BlockClosure>>ensure:
> Job>>run
> MorphicUIManager(UIManager)>>displayProgress:from:to:during:
> MorphicUIManager>>informUserDuring:
> MorphicUIManager(UIManager)>>informUser:during:
> IceTipGitHubRepositoryPanel(IceTipGitRepositoryPanel)>>newRepository
> IceTipGitHubRepositoryPanel>>newRepository
> IceTipRegisterRepositoryDialog>>doAccept
> [ self doAccept.
> true ] in IceTipRegisterRepositoryDialog(IceTipOptionDialog)>>accept in
> Block: [ self doAccept
> BlockClosure>>on:do:
> IceTipRegisterRepositoryDialog(IceTipOptionDialog)>>accept
> ```
>
> --
> Eric
>


-- 



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

[Pharo-dev] CI Down

[Guillermo Polito]

Hi all,

Since yesterday evening, CI is down because of Inria network problems at
the level of Paris.
Inria tells us that they do not have yet an estimation of how much time it
will take to fix it.

Until then, there will be no CI testing PRs nor new builds.
Previous Pharo builds are still available in http://files.pharo.org/, which
is hosted in OVH.

I'll keep you updated,
Guille

Re: [Pharo-dev] CI Down

[Guillermo Polito]

This afternoon we were notified that everything is UP again. Not
necessarily stable but UP.

On Wed, Aug 8, 2018 at 6:38 PM Martin Dias  wrote:

>
>
> El mié., 8 de ago. de 2018 05:44, Norbert Hartl 
> escribió:
>
>> Might be but doing make in the pharo repo gives you this
>>
>
> hm... we should check that dependency. Epicea, Ombu and Hiedra packages
> should be versioned in pharo repo.
>
>
>> …
>> Project: Hermes baseline
>> Project: Ficus 0.3.8
>> ...RETRY->Hiedra
>> ...RETRY->Hiedra
>> gofer repository error: 'GoferRepositoryError: Could not access
>> http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut:
>> Cannot connect to 128.93.162.53:80'...ignoring
>> ...FAILED->Hiedra'Errors in script loaded from
>> /Users/norbert/play/iot/pharo/bootstrap/scripts/prepare_image.st'
>> Could not resolve: Hiedra [Hiedra] in
>> /Users/norbert/play/iot/pharo/pharo-local/package-cache
>> http://smalltalkhub.com/mc/MartinDias/Ficus/main/ ERROR:
>> ‚GoferRepositoryError: Could not access
>> http://smalltalkhub.com/mc/MartinDias/Epicea/main/: ConnectionTimedOut:
>> Cannot connect to 128.93.162.53:80'
>> …
>>
>>
>> Am 08.08.2018 um 11:21 schrieb Esteban Lorenzano :
>>
>> I was convinced that Epicea was now managed inside Pharo.
>>
>> On 8 Aug 2018, at 11:15, Norbert Hartl  wrote:
>>
>> The one thing is not be able to run the CI. The bigger problem is that
>> pharo is not buildable at all. Can we please move mission critical repos
>> like epicea to github?
>>
>> Norbert
>>
>> Am 08.08.2018 um 09:55 schrieb Guillermo Polito <
>> guillermopol...@gmail.com>:
>>
>> Hi all,
>>
>> Since yesterday evening, CI is down because of Inria network problems at
>> the level of Paris.
>> Inria tells us that they do not have yet an estimation of how much time
>> it will take to fix it.
>>
>> Until then, there will be no CI testing PRs nor new builds.
>> Previous Pharo builds are still available in http://files.pharo.org/,
>> which is hosted in OVH.
>>
>> I'll keep you updated,
>> Guille
>>
>>
>>
>>
>>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Association hash vs equality

[Guillermo Polito]

Actually, #= and #hash should be defined so:

if (a=b) then a hash = b hash
if a != b, it's not important

This is required because some collections (like sets, dictionaries) will
index their elements by their hash. Then, typically the collection
implementation will first ask the hash, access the index with it, and
retrieve the object if it is = only. Notice that several objects can have
the same hash but be equals nonetheless.

On Thu, Aug 16, 2018 at 11:36 AM Jan Blizničenko 
wrote:

> Hello, I've been looking at implementation of Associtation and LookupKey
> (its
> superclass).
> In LookupKey, there is LookupKey>>#= and LookupKey>>#hash both implemented
> to use key (compare keys and use hash of key), but in Association,
> Association>>#= compares both key and value, but hash is not changed there,
> so only hash of key is used, therefore it does not correspond to
> implementation of method = ... shouldn't it?
>
> To demonstrate:
> (1 -> #a) = (1 -> #b).
>   is false but
> (1 -> #a) hash = (1 -> #b) hash.
>   is true
>
> I also noticed similar discussion for Doplhin smalltalk
> http://forum.world.st/Association-gt-gt-hash-td3368868.html where guys
> state
> it is all right, but I still do not see why.
>
> Jan
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Is Jenkins OK?

[Guillermo Polito]

Nope, the osx slave is down since yesterday.
https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/

I've been trying to restart it but no luck so far...
I'll keep you updated.

On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant 
wrote:

> I have a PR that has been running for over 13 hours...
>
>
> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pending%20pull%20request%20and%20branch%20Pipeline/detail/PR-1684/1/pipeline
>
> (if there's something I can do about this myself instead of annoying
> the list, please let me know)
>
> Thanks,
> Alistair
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Is Jenkins OK?

[Guillermo Polito]

Thanks Torsten.

Builds should be working now, though unstable.

We are experiencing several other issues with the CI regarding permissions
and so.
We have open a ticket in the ci-support app and we are waiting for their
answer.

On Tue, Aug 14, 2018 at 11:20 AM Torsten Bergmann  wrote:

> For future reference: https://github.com/pharo-project/pharo/pull/1687
>
> *Gesendet:* Dienstag, 14. August 2018 um 10:45 Uhr
> *Von:* "teso...@gmail.com" 
> *An:* Pharo-dev 
> *Betreff:* Re: [Pharo-dev] Is Jenkins OK?
> I am disabling the testing on OS X until the slave come back from the
> grave!!
>
> So we can continue working!
>
> Cheers.
>
> On Tue, Aug 14, 2018 at 10:03 AM Alistair Grant 
> wrote:
>
>> On Tue, 14 Aug 2018 at 09:59, Guillermo Polito
>>  wrote:
>> >
>> > Nope, the osx slave is down since yesterday.
>> > https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/
>> >
>> > I've been trying to restart it but no luck so far...
>> > I'll keep you updated.
>>
>>
>> Thanks, Guille!
>>
>> Cheers,
>> Alistair
>>
>>
>> >
>> >
>> > On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant 
>> wrote:
>> >>
>> >> I have a PR that has been running for over 13 hours...
>> >>
>> >>
>> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pending%20pull%20request%20and%20branch%20Pipeline/detail/PR-1684/1/pipeline
>> >>
>> >> (if there's something I can do about this myself instead of annoying
>> >> the list, please let me know)
>> >>
>> >> Thanks,
>> >> Alistair
>> >>
>> >
>> >
>> > --
>> >
>> >
>> >
>> > 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
>>
>
>
>
> --
> Pablo Tesone.
> teso...@gmail.com
>


-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] A new rule to implement in Pharo ?

[Guillermo Polito]

We had another idea yesterday with Julien.

Add a rule to check that in a test `self skip` is only present in the first
statement of a test case.

On Fri, Aug 17, 2018 at 9:38 AM Marcus Denker 
wrote:

>
>
> > On 13 Aug 2018, at 14:59, Lionel Akue  wrote:
> >
> > Hello,
> >
> > Do you have a rule you would like to get implement in Pharo?
> >
> > I am reading about Renraku and I would like to exercise.
> >
> > Thanks,
> >
> > Lionel
>
> Some ideas:
>
> - Test Class not in Package with name -Tests
> - add rule: non-exisitng selector send in a method that has itself no
> senders means that the whole method most likely is dead code
>
> Improvements:
>
> - SharedPool subclasses should not trigger “excessive number of vars” QA
> rule (as their duty is to define variables)
>
>
> Marcus
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Guillermo Polito]

Hi,

I'll write down some of the reasons of the project's design, like that I
can afterwards copy paste it in the wiki :).

First, this design did not came up from an egg. We worked on it for about
two months. And it is thought to be backwards compatible and manage lots of
metacello particularities. It may have things that are perfectible, sure,
so let's discuss it.

One of the main problems we saw in metacello, and that Iceberg inherited,
was the "source subdirectory" thing. This source directory had to be
specified in the CLIENT, meaning that every time we clone a repository we
should know by heart the directory chose by its developer. Moreover, we
lack a standard way to do it, so everybody does as he feels (root
directory, src, source, repository, mc).

This has some bad consequences:
 - once a repository is referenced by some other project, it is more
complicated to change its source directory. Imagine that tomorrow we set as
standard that all git repos should have the code in src. Then voyage should
change. And all its clients too.
 - Making a typo in the code subdirectory means sometimes super ugly errors
from metacello that are difficult to debug and understand (e.g., "Cannot
resolve BaselineOfMetacello WTF")

Moreover, there was another problem that people started stumbling on: the
fact that iceberg got confused sometimes thinking that an empty project was
in filetree (to keep backwards compatibility with projects without a
.properties).

So we decided that for this release we wanted to revert a bit that
situation. Think object: let's put the meta-data used to interpret a
project's structure inside the project itself.
The idea is that:

 - each project should contain both a .project and a .properties file. The
first can contain arbitrary project meta-data (such as the source
directory). The second contains the cypress properties, which are needed to
correctly interpret the code inside the source directory.
 - a project without a .project file is an old project and cannot be
interpreted, because we don't know the source directory
 - a project without a .properties file is an old project and is by default
transformed in a project with a #filetree properties file
 - an old project cloned from iceberg detects the missing .project file and
gives the user the opportunity to declare it (and then commit it explicitly)
 - an old project cloned and loaded from a Metacello expression defining a
source directory will honnor the source directory defined in the Metacello
expression (for backwards compatibility, and we have ~500 tests about this).

# About defaults values / forcing the user to define a project

First, notice that even when the repositories you load are just marked as
"dirty".
This is because in memory we add a project to your repository.
But you're not forced to commit it.
Actually, you can still load packages and baselines from that repository
without committing.

This is in line with Iceberg's "explicitness". We try to not do any
destructive operation without asking the user first (that's why we have
several preview windows for pushing, pulling, checkout, merge..., and why
contrastingly with monticello we show the committed changes on the commit
window...). So, instead of transparently "adding the file" we have decided
to modify the project in memory and let the user the responsibility to
commit that file.

If there's a drawback, is that the repository is marked as dirty. Which is
a bit noisy, yes, but still I think it's not so bad compared with the
previous drawbacks.
To solve this, we could have some default values, yes, and only mark it as
dirty if the project does not follow the default value.
This could work, but right now all projects use different names for their
source directories.
So the question is, what would be a good default? I'd like to use 'src'
since this is short, well known and less alien (all these in the sense that
we do not lose anything and we have a lot to gain by using it).
However, not much repositories use 'src' so it will still produce a lot of
"noise"...

But still! Committing that file is a one-time operation. Once people fix
their repositories adding the project meta-data, you will not see them
dirty anymore. So we can see this as a transition noise too...

Of course, new ideas are welcome. I'll let Pablo and Esteban add their
points of view on this too.
Guille

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Guillermo Polito]

>
> [SNIP]
> I think I can see what is the rationale behind it but I’m not sure this
> can be the way to go:
>
> - I don’t think there can be a „standard way“ of defining source
> directory. And I don’t think that a tool should enforce this however. I
> keep frontend and backend code in some repositories together so the source
> is in my case in backend/source. What does it mean for users not using the
> „standard“ name?
>

Well, I think the opposite. The tool should enforce some standard way, and
then, if you want to diverge from it you should specify it explicitly.


> - I don’t see why there needs to be a 1:1 relationship between a
> repository and working copy in pharo. It is like this at the moment already
> but the .project file manifests this. So it should not be supported to have
> more source dirs in one git repo? It might be not a good idea that the
> client has to write the source dir but it opens the possibility that there
> can be more than one.
>

Our solution doesn't close the door either. Actually, we were thinking on
having composite projects (a project with subprojects), which would support
your use case. We are aware we wanted this for Pharo so for example we can
split pharo itself in several smaller subprojects instead of having the
mess of ~500 packages we have today. However, we were not aware of any
project out there using such setup, and previous iceberg versions was maybe
supporting this just "by chance" and not by design. (Just imagine that
having in the same image two repositories with the same git repository
behind but different source directories could be a way, but it's more of a
workaround).

This said, could you explain better how you were using this so far?
 - you have different source directories for frontend/backend?
 - you interact with them as different repositories in the same image? or
from different images pointing to the same repo?
 - every time you commit in one of the iceberg repositories you get
detached in the other(s)?

This said, I'd like to support this scenarios, but I want to do it by
design :)


> - My mode of working is to have an eye on dirty repositories because that
> shows what the impact of your work is. If I have a lot of dirty
> repositories in my repository list it does not feel good and I don’t want
> that. Especially for projects I don’t have write access to. How can I
> change this? I’m not sure that assuming everyone will add these files is a
> likely one.
>

Maybe we need to be less invasive with colors? My point of view is that
Monticello shows tons of packages and repositories, automatic rewrite and
auto-deprecation rules rewrite code dynamically and mark monticello
packages as dirty. But nobody ever complained about monticello or tried to
change it.

What are the packages you depend on and you have no write access to? If we
make a pull request per day, I think we can solve this situation really
fast...


>
> Norbert
>
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Pharo-users] New Iceberg Version 1.2.1

[Guillermo Polito]

On Thu, Aug 9, 2018 at 11:18 AM Norbert Hartl  wrote:

>
>
> Am 08.08.2018 um 14:12 schrieb Herbert Vojčík :
>
>
>
> Damien Pollet wrote on 8. 8. 2018 13:53:
>
> First of all, quick stupid question: I'm currently loading my code with
> gitlocal://./src as the repository URL (my workflow starts in a terminal
> rather than in a Pharo image)
> Should I just remove the /src part, now that my repo has the project
> metadata?
> Also, are more features planned for the .project file? E.g. what about
> storing a default selection for Calypso and the Test Runner in there?
> On Wed, 8 Aug 2018 at 10:28, Norbert Hartl  mailto:norb...@hartl.name >> wrote:
>- I don’t think there can be a „standard way“ of defining source
>directory. And I don’t think that a tool should enforce this
>however. I keep frontend and backend code in some repositories
>together so the source is in my case in backend/source. What does it
>mean for users not using the „standard“ name?
> Sure there can. Look at any ruby or maven project, they all have strong
> conventions for organizing projects and standard config files for deviating
> from those conventions.
> I would have preferred if Iceberg picked one convention (arbitrarily) in
> the absence of a .project file instead of forcing its explicit presence.
> IMHO the choice of default directory per se (be it ./, ./src, ./source or
> whatever) matters less than the fact that there is a convention in place.
>- I don’t see why there needs to be a 1:1 relationship between a
>repository and working copy in pharo. It is like this at the moment
>already but the .project file manifests this. So it should not be
>supported to have more source dirs in one git repo? It might be not
>a good idea that the client has to write the source dir but it opens
>the possibility that there can be more than one.
> I see your point here, but by using separate source directories you're
> sort of creating a hydra project… What I mean here is that the source
> directories are separate, but their histories are tangled. If you want
> separate source dirs it kinda means that you want separate change
> histories, doesn't it? What if the same class has diverging definitions in
> separate directories (I wonder what maven does in that case…)?
>
>
> There are monorepos. Some people / companies love them.
>
> One of these companies we know for good. It is google. Google has one (!)
> repositoryf for all their software.
>
> And that is the point I want to stretch here. One repo with one project
> and a standard source directory is too theoretical and too narrow in
> thoughts.
>

I think that you underestimate people when you say this.


> Today there is no possibility to reliably make one product out of multiple
> repos. Git submodule and git subtree are not even close to something
> reliable and usable.
>

We are well aware of this. And that's why Pharo is not using any of them.
But this goes against what you said before, or I'm not getting something.


> Descriptions like metacello are language centric.
>

Yes. But I don't understand why this comes up. You would like language...
"agnostic"? For example?


> So what is the most secure way of defining a single product? It is the
> mono repo. That is the main reason I have my sources in backend/source
> because there is a javascript frontend in the same repo because I want to
> have one reliable source that defines my product and I can be sure that the
> backend and frontend are always the ones that match.
>

Just to repeat myself (and just to avoid missing it in the previous emails
^^). Can you describe better your needs for "multiple iceberg
subdirectories"?


> I don’t think it is a good idea if we once leave the island to embrace
> something like git just to make git islandish a little later.
>

I did not understand this...


>
> Just to be very clear. We are talking about two files: .project and
> .properties. I have nothing against .properties because we have multiple
> formats possible so making it explicit is a good idea. But .project makes
> every repo a single source repo. If we enforce .properties files why do we
> not scan the repo for directories containing this file? If none is found we
> cannot know (or we add looking at some default locations). If multiple
> directory are found I can add that to iceberg as a real project out of the
> combination for repository-source directory.
>
This way I could have multiple projects out of one repo. And with the
> possibility of having multiple source directories it is obvious that the
> path still needs to be added to a url in metacello.
>
Unless there is one of this directories marked to be the default which
> would be loaded if no directory is given. This way the default directory
> would be the one selected if only one is there. So you can have multiple
> projects in one repo and if this is only one per project the directory can
> be automatically resolved. Use case kept.
>

Yes it 

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

[Guillermo Polito]

Damien,

Could you check that at least the proposed image-side changes fix your
problem for *nixes?

On Sat, Aug 4, 2018 at 7:13 PM Sean P. DeNigris 
wrote:

> Alistair Grant wrote
> >> Tracking issue:
> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274
> > The issue above is for the VM changes.
> >
> > The issue for image changes is:
> > https://pharo.fogbugz.com/f/cases/22296/Stdio-file-creation-fixes
>
> Thanks for looking into this, Alistair! Few are brave enough to dive into
> these dark corners of the system ;-)
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Iceberg > review pull request & repo name clash

[Guillermo Polito]

Hi Ben,

The github integration has sure problems, since we were not actively
working on it.
So I really think it needs some love.

Please go ahead an open as many issues (or PRs) as you want ^^.

On Fri, Sep 7, 2018 at 4:54 AM Ben Coman  wrote:

> Two concerns from one flow of events...
>
> I was trying out "review a pull request" feature for the first time.  This
> looks very promising, but I got stuck.
>
> In Pharo 6.1...
> Downloaded http://files.pharo.org/platform/Pharo6.1-win.zip
> Updated Icerberg per https://github.com/pharo-vcs/iceberg#update-iceberg
> Iceberg
>   > Settings > Use custom keys = Enabled
>   > Add > Clone remote repository
>   Remote URL = g...@github.com:exercism/pharo.git
>   ==> "pharo" repo appears, status "Not loaded"
>   > "pharo" repo > Packages ==> BaselineOfExercism, Exercism, etc
>
>
>   > "pharo" repo > Github > View pull request > origin > enter github
> account password
>   ==> shows PR#98 "Move setup to class initialization..."
> > right-click 98 > Review pull request
>   ==> an empty window titled "Browsing pull request: #98" appeared
> (see attached)
> Trying the same in Pharo 7 gave a different problem...
> From Launcher started
> Pharo-7.0.0-alpha.build.1231.sha.cf8aa48.arch.32bit...
> Iceberg
>   > Settings > Use custom keys = Enabled
>   > "pharo" repo > Forget Repository > Ticked "Also remove repository from
> file system"
>   > Add > Clone remote repository
>   Remote URL = g...@github.com:exercism/pharo.git
>   ==> "pharo" appears, status = "Fetch required. Unknown cf8aa48"
>   > "pharo" repo > Fetch
>   ==> no change in status,
>   but I do see the the expected files in repo on disk
>
>   > "pharo" repo > Packages
>   ==> only shows LICENSE and README.md.
>   Why did this "just work" in 6.1 ?
>   It seems the source directory is wrong.
>   From this point is it possible to update the source directory to
> "dev/src/" ?
>
> Maybe its due to the name clash "pharo-project/pharo" versus
> "exercism/pharo"
> and something was retained after the "Forget Repository".
> Such a name clash is unfortunate, but is a corner case that should be
> handled.
> This could be a useful test case.
>
> Before I log an issue, could someone check I'm not doing something wrong.
>
> cheers -ben
>
>
> P.S. A work around might have been giving a custom local name for the
> exercism/pharo repo,
> much like you can specify the folder created by command line 'git clone'.
> Is such a feature planned for Iceberg?
>
>
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Iceberg goodness plus ideas

[Guillermo Polito]

Hi Ben,

I'm really interested on improving on this. Please read below :)

On Sun, Sep 9, 2018 at 5:07 PM Ben Coman  wrote:

> First, kudos to Iceberg team for detecting the mistake I made messing
> around at the command line under the feet of an Iceberg managed repo.
> I'm interested in some general discussion of a few ideas before logging
> any issues.
>
> I had an Iceberg managed repo branch "ready-multiple-commands"
> as shown at [A] in the attached pic.
> (note that this is "exercism/pharo" not "pharo-project/pharo")
>
> I wanted to compare "git log --graph" between a few branches
> so I jumped into a command prompt and did so.  Along the way I changed
> branch to "master" from the command line [B].
> Then friends arrived and it was six hours until I got back to it
> and was presented with "Detached Working Copy" [C],
> and I'd forgotten what I'd done.
>
> Repair repository [D] didn't make this immediately obvious
> although given the two commits after a while I managed to work it out
> and simply `git checkout ready-multiple-commands` at the command line
> fixed things, returning the display to [A].
>
> So the discussion points I'm interested in are:
>
> a. An extra column "Image Branch" with the existing column
> renamed "Disk Branch" would have made my mistake immediately obvious.
>

Yes, this could be easily done. We can have a new version with that soon to
try it out and see if this improves the situation.
This change would have no significant side effect, and rolling back is
cheap.
So I'd like to experiment with this kind of simple UI issues, that may
improve the overall understanding.


>
> b. Such under the covers command line operation may be a corner case(??),
> so if not an extra column, a red Status message "Image Branch
> ready-multiple-commands" or similar would have helped.
>
> Well, it is not necessarily a corner case, because this will happen for
people maintaining external files... At least with current implementation.
We are thinking on adding support for external files, but that will not
arrive soon.

Also, the "Detached working copy" is also a bit more complicated than
checking out a different branch :).
I'll do some writeup here so people can better understand the motivations
behind the current implementation.
I'll try to be clear, but this is much easier to talk about this issues
around a blackboard... I can try to do some drawings next time ^^.

So far we decided that Iceberg will not let you work unless you image's
working copy is aligned with the repository's working copy/HEAD.
This provokes this kind of situations when touching the repository from
outside the image, but we think it is simpler to understand.

An alternative solution could be to let the image and the disk diverge
(like implementing in the image some kind of virtual branch). But this
could be confusing also. Because this could lead to scenarios where you
touch your disk working copy and the image does not "care" them?

Also, take into account that every point of divergence in history will lead
to new merge points, and this will increase the possibilities of conflicts.
So, we could have:

Image [commit X]  -  Disk working copy [commit Y] - Remote repository
[commit Z]

Imagine that we have a more complex (but flexible?) implementation that
allows you to work in this scenario.
Then you choose to pull from the image.
 - Merging Z with Y could lead to conflicts
 - Merging Y with X too.
 - And merging Z with X too.

So that would lead to a super mess that would be hyper complicated for
average users :)
We have thought about this complex scenarios and we decided we wanted to
avoid them, because already bare-git is complicated in itself...

Actually, we have been really picky in our merge design and Iceberg only
lets you merge 2 commits at a time (even if there are three commits in play
when you pull: image, git HEAD and the pulled commit ;)).


> c. In the first paragraph of [D] it was not apparent what "working copy"
> and "repository commit" referred to (although after a while I worked it out
> from the given commit hashes -- the former was in-Image and the latter
> on-disk.  But the files on disk are a "working copy" in all other git
> documentation and it invites confusion not to refer to it like that.  It
> seems to me we deal with two working copies: an "image working copy" and a
> "disk working copy". That terminology would have eased discovery of my
> mistake.
>

There are effectively two working copies, yes :) I'll try to propose a new
text for the repair action explanations soon enough. I'll ping you so you
can do a double check on it ^^.


>
> d. Instead of the commit hashes [D], is it feasible to match those to
> branches/tags and display those.  That would have made my mistake more
> obvious.
>

Not quite. Iceberg's working copy remembers the commit from where the code
was loaded, not the branch.
And the branch can move, so it's not necessarily a good source of that
information.

What I mean by this is 

Re: [Pharo-dev] Release test for unused temps and other

[Guillermo Polito]

Hi, I don't think that 20 seconds will affect the overall process :). It
will only become a problem if we increment the number of these kind of
tests by *a lot*...

Another solution is to make some tests run in parallel. But for this to run
properly we have to increase the number of slaves in Jenkins, and the bad
news is that we reached the current maximum limit (of 5 slaves).
We have to talk to the inria people to see what solution they could provide
to us for this, because otherwise the infrastructure does not scale for
lots of PRs with big jobs.

Guille

On Fri, Sep 7, 2018 at 8:23 AM Alistair Grant  wrote:

> On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. 
> wrote:
> >
> >
> > Maybe we could have a package with release tests that are not executed
> > by the CI but that are executed at the moment of the feature freeze and
> > some time before the Pharo release to ensure the quality of the code
> > base for tests that are too long?
>
> The drawback of this approach is that it relies on the original author
> going back and submitting a fix in a timely manner (quite possibly
> after they've moved on to other things).
>
> If the tests could be run on a specified set of classes / methods,
> perhaps we could run them as part of Iceberg, i.e. when going to
> commit code, these tests are run on the classes in the commit and a
> warning opened prompting the user to fix them before actually
> committing.
>
> Cheers,
> Alistair
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Pharo BOF at ESUG

[Guillermo Polito]

Ok by me, so tuesday or wednesday?

On Mon, Sep 10, 2018 at 2:46 PM Stéphane Ducasse 
wrote:

> Hello
>
> We would like to have a BOF around Pharo.
> Since there are many topics to talk about.
> Tuesday after the show us your project?
> We can have one at the beach before the social event aroun 17h?
>
> Stef
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>

-- 



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

[Pharo-dev] Tonel class comments

[Guillermo Polito]

Hi all,

Since people have been asking how to use Tonel, I've took a look at it and
have written down two class comments for both the reader and the writer.
I'll push them to Tonel and schedule soon a patch release with it. Here are
the class comments so people can see them/discusses them.
Please, report any enhancements as pull requests in

g...@github.com:pharo-vcs/tonel.git



! TonelReader

I'm a monticello reader for tonel format repositories. I read
 - a package per directory
 - a class per file
 - a set of extensions to a single class per file (for example, all
extensions of a package to String will be in a single file)

I'm created on a file reference to a directory where the package will be
read and the name of the package to read.

[[[
TonelReader on: 'someDirectoryWithTonelPackages' asFileReference filename:
'MyPackageName'
]]]

My main method is
- ==#definitions== reads and parses the tonel file, returns a list of
monticello definitions.
- ==#snapshot== returns a monticello snapshot with the read definitions.
- ==#version== returns a monticello version with the read snapshot.

!! Implementation details

The monticello versions I return do have artificial information. Since I'm
just meant to read versions from a directory, this directory has no
information such as commit message, commit time, author, or ancestors.
Check the method ==#loadVersionInfo== for more information.

! TonelWriter

I'm a monticello writer for tonel format, writing
 - a package per directory
 - a class per file
 - a set of extensions to a single class per file (for example, all
extensions of a package to String will be in a single file)

I'm created on a file reference to a directory where the package will be
written.

[[[
TonelWriter on: ('someDirectory' asFileReference ensureCreateDirectory)
]]]

My main methods are
- ==#writeVersion:== that receives as argument a monticello version to
write, from where I'll extract the corresponding monticello snapshot.
- ==#writeSnapshot:== that receives as argument a monticello snapshot to
write, from where I'll write all the contained definitions.

!! Implementation details

Notice that while writing, if the written package/snapshot already exists
in the directory I'll overwrite it (i.e., remove it and recreate it).


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Loading configuration of spur

[Guillermo Polito]

Hi,

I'll Esteban answer better but I don't know if that VMMaker mirror is up to
date.

Taking a look at the images/newImage.sh script, it is using Pharo5.0. But I
see no reason for it not working on latest versions. Probably some patches
are required...

What is your error?


On Sun, Mar 11, 2018 at 7:14 PM, Javier Pimás 
wrote:

> Ok, now I moved forward but cannot load vmmaker sources into a pharo 61
> image, is that supported? I have this snippet that doesn't work:
>
> Metacello new
> filetreeDirectory: '../VMMaker/mc';
> baseline: 'Spur';
> load
>
> where ../VMMaker/mc is a clone of the official pharo repo at github.
>
> Cheers,
> pocho
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Loading configuration of spur

[Guillermo Polito]

Hmm no idea. The best I can think about is that that VMMaker version is old
(Pharo5 is at least 2 years old) and there is probably a dependency between
VMMaker and the compiler (thus that BytecodeEncoder ref). IF VMMaker is
overriding some methods in BytecodeEncoder, then what is happenning is that
you're breaking the compiler (?).

In any case, again, that is not the official VMMaker repository but a
mirror.

On Mon, Mar 12, 2018 at 11:53 AM, Javier Pimás <elpochodelage...@gmail.com>
wrote:

> Oh I forgot to write down the actual error. There is a MNU for
> BytecodeEncoder class>>#isExtension: which seems to have been removed from
> the image. It is a bit different to typical doesNotUnderstand errors
> because it opens an emergency evaluator and leaves the image unusable.
>
> On Mon, Mar 12, 2018 at 6:10 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> Hi,
>>
>> I'll Esteban answer better but I don't know if that VMMaker mirror is up
>> to date.
>>
>> Taking a look at the images/newImage.sh script, it is using Pharo5.0. But
>> I see no reason for it not working on latest versions. Probably some
>> patches are required...
>>
>> What is your error?
>>
>>
>> On Sun, Mar 11, 2018 at 7:14 PM, Javier Pimás <elpochodelage...@gmail.com
>> > wrote:
>>
>>> Ok, now I moved forward but cannot load vmmaker sources into a pharo 61
>>> image, is that supported? I have this snippet that doesn't work:
>>>
>>> Metacello new
>>> filetreeDirectory: '../VMMaker/mc';
>>> baseline: 'Spur';
>>> load
>>>
>>> where ../VMMaker/mc is a clone of the official pharo repo at github.
>>>
>>> Cheers,
>>> pocho
>>>
>>> --
>>> Javier Pimás
>>> Ciudad de Buenos Aires
>>>
>>
>>
>>
>> --
>>
>>
>>
>> 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
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>
>> *Phone: *+33 06 52 70 66 13 <06%2052%2070%2066%2013>
>>
>
>
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Error opening Zinc MC repository in latest Pharo 7

[Guillermo Polito]

Ah, that's Iceberg's magic proxies I think :/

On Tue, Mar 13, 2018 at 3:05 PM, Sven Van Caekenberghe  wrote:

> For some reason I can no longer open Zinc's old school MC repository in
> Pharo-7.0+alpha.build.690.sha.ffd58dcc88a0698be21b52b565a86316799cb25d
> (32 Bit)
>
> MCHttpRepository
>  location: 'http://mc.stfx.eu/ZincHTTPComponents'
>  user: ''
>  password: ''.
>
> > Open repository (browser UI)
>
> gives me a DNU see [1]
>
> I just don't see what is wrong, maybe it has to do with the latest commit
> in the repo, (it took a git version number from the image as ancestor), but
> this code is hard to look at.
>
> Now I am stuck trying to fix a problem with Zinc.
>
> Any help would be appreciated,
>
> Sven
>
> [1]
>
> UndefinedObject(Object)>>doesNotUnderstand: #<
> [ :ancestor |
> (ancestor versionNumber < aVersionArray third
> or: [ ancestor versionNumber = aVersionArray third
> and: [ ancestor author ~= aVersionArray second ] ])
> ifTrue: [ newer add: ancestor name ] ] in [ :aVersionArray |
> workingCopy ancestors
> do: [ :ancestor |
> (ancestor versionNumber < aVersionArray third
> or: [ ancestor versionNumber = aVersionArray third
> and: [ ancestor author ~=
> aVersionArray second ] ])
> ifTrue: [ newer add: ancestor name ] ] ] in [
> :workingCopy |
> | versionsForPackage |
> workingCopy ancestors do: [ :ancestor | loaded add: ancestor name ].
> versionsForPackage := versions
> select: [ :v | v first = workingCopy package name ].
> versionsForPackage
> do: [ :aVersionArray |
> workingCopy ancestors
> do: [ :ancestor |
> (ancestor versionNumber < aVersionArray
> third
> or: [ ancestor versionNumber =
> aVersionArray third
> and: [ ancestor
> author ~= aVersionArray second ] ])
> ifTrue: [ newer add: ancestor name
> ] ] ] ] in MCFileRepositoryInspector>>refresh in Block: [ :ancestor | ...
> Array(SequenceableCollection)>>do:
> [ :aVersionArray |
> workingCopy ancestors
> do: [ :ancestor |
> (ancestor versionNumber < aVersionArray third
> or: [ ancestor versionNumber = aVersionArray third
> and: [ ancestor author ~=
> aVersionArray second ] ])
> ifTrue: [ newer add: ancestor name ] ] ] in [
> :workingCopy |
> | versionsForPackage |
> workingCopy ancestors do: [ :ancestor | loaded add: ancestor name ].
> versionsForPackage := versions
> select: [ :v | v first = workingCopy package name ].
> versionsForPackage
> do: [ :aVersionArray |
> workingCopy ancestors
> do: [ :ancestor |
> (ancestor versionNumber < aVersionArray
> third
> or: [ ancestor versionNumber =
> aVersionArray third
> and: [ ancestor
> author ~= aVersionArray second ] ])
> ifTrue: [ newer add: ancestor name
> ] ] ] ] in MCFileRepositoryInspector>>refresh in Block: [ :aVersionArray
> | ...
> Array(SequenceableCollection)>>do:
> [ :workingCopy |
> | versionsForPackage |
> workingCopy ancestors do: [ :ancestor | loaded add: ancestor name ].
> versionsForPackage := versions
> select: [ :v | v first = workingCopy package name ].
> versionsForPackage
> do: [ :aVersionArray |
> workingCopy ancestors
> do: [ :ancestor |
> (ancestor versionNumber < aVersionArray
> third
> or: [ ancestor versionNumber =
> aVersionArray third
> and: [ ancestor
> author ~= aVersionArray second ] ])
> ifTrue: [ newer add: ancestor name
> ] ] ] ] in MCFileRepositoryInspector>>refresh in Block: [ :workingCopy |
> ...
> Array(SequenceableCollection)>>do:
> MCFileRepositoryInspector>>refresh
> [ self refresh.
> MCWorkingCopy addDependent: self ] in 
> MCFileRepositoryInspector>>setRepository:workingCopy:
> in Block: [ self refresh
> [ self value.
> Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self
> value
>
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Error opening Zinc MC repository in latest Pharo 7

[Guillermo Polito]

Well, I'll try to explain it.

Once Iceberg is loaded, all Pharo packages are initialized with a special
MCVersionInfo: IceProxyMCVersionInfo.

This MCVersion info is there because the image does not come by default
with a pharo repository. So, at runtime, when it is used, it tries to
determine if the pharo repository was defined and if so, it does become
itself by a normal version.
For this, it uses both #doesNotUnderstand: and #become:.

I'm not happy with that implementation. It could be simplified by just
adding a Pharo repository in iceberg by default...

In any case, one way to fix that, is to create a pharo repository. That
should "bind" the proxy version infos...

On Tue, Mar 13, 2018 at 3:40 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:

> Well it is so magic that I do not understand what is happening ...
>
> > On 13 Mar 2018, at 15:32, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
> >
> > Ah, that's Iceberg's magic proxies I think :/
> >
> > On Tue, Mar 13, 2018 at 3:05 PM, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
> > For some reason I can no longer open Zinc's old school MC repository in
> Pharo-7.0+alpha.build.690.sha.ffd58dcc88a0698be21b52b565a86316799cb25d
> (32 Bit)
> >
> > MCHttpRepository
> >  location: 'http://mc.stfx.eu/ZincHTTPComponents'
> >  user: ''
> >  password: ''.
> >
> > > Open repository (browser UI)
> >
> > gives me a DNU see [1]
> >
> > I just don't see what is wrong, maybe it has to do with the latest
> commit in the repo, (it took a git version number from the image as
> ancestor), but this code is hard to look at.
> >
> > Now I am stuck trying to fix a problem with Zinc.
> >
> > Any help would be appreciated,
> >
> > Sven
> >
> > [1]
> >
> > UndefinedObject(Object)>>doesNotUnderstand: #<
> > [ :ancestor |
> > (ancestor versionNumber < aVersionArray third
> > or: [ ancestor versionNumber = aVersionArray third
> > and: [ ancestor author ~= aVersionArray second ]
> ])
> > ifTrue: [ newer add: ancestor name ] ] in [ :aVersionArray |
> > workingCopy ancestors
> > do: [ :ancestor |
> > (ancestor versionNumber < aVersionArray third
> > or: [ ancestor versionNumber = aVersionArray
> third
> > and: [ ancestor author ~=
> aVersionArray second ] ])
> > ifTrue: [ newer add: ancestor name ] ] ] in [
> :workingCopy |
> > | versionsForPackage |
> > workingCopy ancestors do: [ :ancestor | loaded add: ancestor name ].
> > versionsForPackage := versions
> > select: [ :v | v first = workingCopy package name ].
> > versionsForPackage
> > do: [ :aVersionArray |
> > workingCopy ancestors
> > do: [ :ancestor |
> > (ancestor versionNumber < aVersionArray
> third
> > or: [ ancestor versionNumber =
> aVersionArray third
> > and: [ ancestor
> author ~= aVersionArray second ] ])
> > ifTrue: [ newer add: ancestor
> name ] ] ] ] in MCFileRepositoryInspector>>refresh in Block: [ :ancestor
> | ...
> > Array(SequenceableCollection)>>do:
> > [ :aVersionArray |
> > workingCopy ancestors
> > do: [ :ancestor |
> > (ancestor versionNumber < aVersionArray third
> > or: [ ancestor versionNumber = aVersionArray
> third
> > and: [ ancestor author ~=
> aVersionArray second ] ])
> > ifTrue: [ newer add: ancestor name ] ] ] in [
> :workingCopy |
> > | versionsForPackage |
> > workingCopy ancestors do: [ :ancestor | loaded add: ancestor name ].
> > versionsForPackage := versions
> > select: [ :v | v first = workingCopy package name ].
> > versionsForPackage
> > do: [ :aVersionArray |
> > workingCopy ancestors
> > do: [ :ancestor |
> > (ancestor versionNumber < aVersionArray
> third
> > or: [ ancestor versionNumber =
> aVersionArray third
> > and: [ ancestor
> author ~= aVersionArray second ] ])
> > ifTrue: [ newer add: ancestor
> name ] ] ] ] in 

Re: [Pharo-dev] cannot write to the changes file

[Guillermo Polito]

Yes, the changes files were being opened twice, and the second time it
failed :).

On Tue, Mar 13, 2018 at 11:11 PM, Cyril Ferlicot D. <
cyril.ferli...@gmail.com> wrote:

> Le 13/01/2018 à 18:03, Ben Coman a écrit :
> >
> > Great! That was quick work (thanks Pavel.)
> > Do you have an issue for me to follow, or should I create it?
> >
> > cheers -ben
> >
>
> It seems that the problem was corrected today (probably the change in
> File usage).
>
> Can someone else confirm?
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Epicea changes broken in latest 7

[Guillermo Polito]

I cannot reproduce it from here... does your file have non-ascii characters?

On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe 
wrote:

> World Menu > Tools > Code Changes
>
> click on any change, boom.
>
> [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] in [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
> BlockClosure>>cull:
> Context>>evaluateSignal:
> Context>>handleSignal:
> Context>>handleSignal:
> MessageNotUnderstood(Exception)>>signal
> UndefinedObject(Object)>>doesNotUnderstand: #<
> ZnUTF8Encoder>>nextCodePointFromStream:
> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> ZnCharacterReadStream>>nextElement
> [ :out |
> | partialMatch pattern matched |
> partialMatch := (self collectionSpecies new: aCollection size)
> writeStream.
> pattern := aCollection readStream.
> matched := false.
> [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
> whileFalse: [ | ch |
> (ch := self nextElement) = pattern next
> ifTrue: [ pattern atEnd
> ifTrue: [ matched := true ]
> ifFalse: [ partialMatch nextPut:
> ch ] ]
> ifFalse: [ pattern reset.
> out nextPutAll: partialMatch contents.
> partialMatch reset.
> out nextPut: ch ] ].
> matched
> ifFalse: [ out nextPutAll: partialMatch contents ] ] in
> ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
> String class(SequenceableCollection class)>>new:streamContents:
> String class(SequenceableCollection class)>>streamContents:
> ZnCharacterReadStream>>upToAll:
> [ stream upToAll: token ] in 
> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> in Block: [ stream upToAll: token ]
> BlockClosure>>on:do:
> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> OmSTONEntryReader>>entryPositionsDo:
> OmSTONEntryReader>>entryPositionsUpTo:
> [ :readStream |
> readStream position: startPosition.
> ^ self newEntryReader
> stream: readStream;
> entryPositionsUpTo: endPosition ] in 
> OmBlockFileStore>>entryPositionsStartingAt:upTo:
> in Block: [ :readStream | ...
> [ ^ aBlockClosure value: readStream ] in [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^
> aBlockClosure value: readStream ]
> BlockClosure>>on:do:
> [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream |
> ...
> [ aBlock value: stream ] in 
> FileReference(AbstractFileReference)>>readStreamDo:
> in Block: [ aBlock value: stream ]
> BlockClosure>>ensure:
> FileReference(AbstractFileReference)>>readStreamDo:
> OmBlockFileStore(OmFileStore)>>readEntriesWith:
> OmBlockFileStore>>entryPositionsStartingAt:upTo:
> OmBlock>>refresh
> OmBlock>>checkIfMustRefreshBlock
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Guillermo Polito]

Hi Dale!

On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 03/05/2018 09:07 AM, Guillermo Polito wrote:
>
>> On the other side, there is the fact that Metacello baselines are so far
>> nice to describe release project dependencies, but they are not so nice to
>> describe subprojects/development dependencies that may get edited along
>> with the parent project. Kind of what we used to do with #bleedingEdge. I
>> feel this is a complex problem, that not even SBT or maven that are there
>> since years are capable of solving nicely... Tode and Iceberg metacello
>> integration try to solve this problem by "ignoring the dependency and using
>> the loaded repository" but this may not be successful either...
>>
>
> I have not been following this thread in detail, but this comment leads me
> to believe that the issue that you guys are running into has to do with
> trying to ongoing distributed development across multiple projects and
> multiple platform versions ...


I don't know exactly the case of Calypso, but I don't think it is being
maintained for other than latest Pharo 7.

The Calypso case as I understand it is that it has a couple of dependencies

 Calypso
   | - commander
   | - class annotations

The three projects are hosted in different repositories, but Denis wants to
work on "bleeding edge" of the three of them at the same time.
Then when he loads calypso in a new image, if he just uses a baseline he
will load specific versions of the dependencies and not the latest ones...

I think this is the particular use case for locking, isn't it?


>
> If so then I think that the moral equivalent of #bleedingEdge should be a
> branch structure along the lines of:
>
>   master branch --- the project release that is known to work on all
> supported platform versions.
>   dev_pharo6  --- the current #bleedingEdge for Pharo6.0
>   dev_pharo7  --- the current #bleedingEdge for Pharo7.0
>
> In an image where you want to use the dev_pharo7 for a project, you do a
> Metacello lock on github:///xxx:dev_pharo7/src BEFORE loading the
> project ... if there are multiple projects that need to all coordinate
> development then you follow the same convention and use a Metacello lock
> for each of the projects ... Executing expressions to lock projects is
> tedious to use and manage.
>

It is not that complicated I think ^^.


>
> In tODE I started using project entries[1] that are downloaded to disk and
> shared by multiple images that allow a developer to specify what
> branch/tag/commit they are interested in using ... each image that is
> started up in a "cluster" uses the project entry to do a Metacello lock on
> the project "automagically"... if there is a series of projects where the
> developer needs to use dev_pharo6 they can arrange to edit the project
> entry to reflect the proper branches for the set of projects that need
> special _development_ treatment ... these .ston files can be shared amongst
> groups of developers ... of course once the local clones of these projects
> are on the local disk, then it is up to the developer (or a set of scripts)
> to periodically update to the latest development version of each of the
> projects ...


YES. This gets closer to what I want. What I don't like from locking is
that I have to:
  - know in advance all the projects (+ dependencies) I want to develop
(specially if I'm not the main project developer)
  - know where they are stored in the disk
  - do an explicit locking on each of them

There is a missing abstraction that probably you get in Rowan or tODE with
that project entry specification?
Because the reality is that personally I'm starting a new image every a
couple of days, and having a specification for it would be much easier than
locking here and there...
I want just to specify "My project X at development time requires Y, Z, H
and Z and H are subprojects".
Then, he should realize he should lock Z and H for me.

Now, If subprojects Z and H are in the same repository as X, that should
not be complicated :).
In Denis' case it could be more complicated...


> To share a specific configuration of development git repos, you need to
> know that SHA anyway, so the image can produce a collection of project
> entries with the SHA of the commit and those project entries can be
> included in a bug report ...
>
> For Rowan[2], I am using a "load specification"[3], which is a second
> generation project entry  the Rowan work is still evolving ...
>
> Anyway, I think that putting the control of what is being used for
> development completely in the developers hands and avoiding the need to
> edit baselines is a good thing ... and I think that th

[Pharo-dev] generated webdoc?

[Guillermo Polito]

Hi all,

I know that we had before the generated webdoc from pharo releases in the
file server (files.pharo.org).

But I cannot see it anymore.

Do we still have it hosted somewhere? We were planning to use it as online
material for a course. I know that it is mostly not needed, but newby
students need somehow to bootstrap themselves :).

Thanks,
Guille

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] MCMczWriter>>#flush breaks

[Guillermo Polito]

On Tue, Mar 13, 2018 at 8:08 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> I was trying to merge in Zinc changes from the latest Pharo 7 back to the
> MC Zinc repos. It seems like MCMczWriter>>#flush breaks [1]. I can save to
> the package cache but not to an Http repo, nor copy to it.


> Guile, has this been tested, or do you no longer use the old MC ?
>

I do not use old MC since some time already...

I'll take a look at this tomorrow morning. But if this is broken it means
it was not covered by tests :/


>
> Sven
>
> [1]
> ByteString(Object)>>error:
> ByteString(Object)>>errorImproperStore
> ByteString>>at:put:
> ZipWriteStream(WriteStream)>>nextPut:
> [ :ch | self nextPut: ch ] in 
> ZipWriteStream(DeflateStream)>>next:putAll:startingAt:
> in Block: [ :ch | self nextPut: ch ]
> ByteArray(SequenceableCollection)>>do:
> ZipWriteStream(DeflateStream)>>next:putAll:startingAt:
> ZipWriteStream(DeflateStream)>>nextPutAll:
> ZipStringMember(ZipArchiveMember)>>compressDataTo:
> ZipStringMember(ZipArchiveMember)>>writeDataTo:
> ZipStringMember(ZipArchiveMember)>>writeTo:
> [ :member |
> member writeTo: stream.
> member endRead ] in ZipArchive>>writeTo: in Block: [ :member | ...
> OrderedCollection>>do:
> ZipArchive>>writeTo:
> MCMczWriter>>flush
> MCMczWriter class>>fileOut:on:
> MCVersion>>fileOutOn:
> [ :s | aVersion fileOutOn: s ] in MCHttpRepository(
> MCFileBasedRepository)>>basicStoreVersion: in Block: [ :s | aVersion
> fileOutOn: s ]
> MCHttpRepository>>entityStreamContents:
> MCHttpRepository>>writeStreamForFileNamed:replace:do:
> MCHttpRepository(MCFileBasedRepository)>>writeStreamForFileNamed:do:
> MCHttpRepository(MCFileBasedRepository)>>basicStoreVersion:
> MCHttpRepository(MCRepository)>>storeVersion:
> MCHttpRepository(MCFileBasedRepository)>>storeVersion:
> [ super storeVersion: aVersion ] in MCHttpRepository>>storeVersion: in
> Block: [ super storeVersion: aVersion ]
> BlockClosure>>on:do:
> MCHttpRepository>>retryOnCredentialRequest:
> MCHttpRepository>>storeVersion:
> MCWorkingCopyBrowser>>storeVersion:in:
> [ self
> storeVersion: newVersion in: aRepository;
> storeDependencies: newVersion in: aRepository ] in [ [ self
> storeVersion: newVersion in: aRepository;
> storeDependencies: newVersion in: aRepository ]
> ensure: [ (MCVersionInspector new version: newVersion) show ] ] in
> MCWorkingCopyBrowser>>basicSaveVersionIn: in Block: [ self...
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Loading code with iceberg

[Guillermo Polito]

Hi Javier, you should register your repository, otherwise it will be just
garbage collected:

[[[
myRepository register.
]]]

On Sun, Apr 1, 2018 at 4:57 PM, Javier Pimás 
wrote:

> We are loading some code using Iceberg API in pharo6.1. That works fine,
> the problem we have is that when I open Iceberg browser no repo is shown
> up. Maybe you can help me find what we are doing wrong. We first update
> iceberg, then load our repo, code is below.
>
> Cheers,
> Pocho.
>
> 
>
> Author useAuthor: 'LoadSqueakNOS' during: [
> "First update Iceberg"
>
> MetacelloPharoPlatform select.
> #(
> 'BaselineOfTonel'
> 'BaselineOfLibGit'
> 'BaselineOfIceberg'
> 'Iceberg-UI'
> 'Iceberg-Plugin-GitHub'
> 'Iceberg-Plugin'
> 'Iceberg-Metacello-Integration'
> 'Iceberg-Libgit-Tonel'
> 'Iceberg-Libgit-Filetree'
> 'Iceberg-Libgit'
> 'Iceberg'
> 'Iceberg-Pharo6'
> 'LibGit-Core'
> 'MonticelloTonel-Tests'
> 'MonticelloTonel-Core'
> 'MonticelloTonel-FileSystem' )
> do: [ :each | (each asPackageIfAbsent: [ nil ]) ifNotNil:
> #removeFromSystem ].
>
> Metacello new
>   baseline: 'Iceberg';
>   repository: 'github://pharo-vcs/iceberg:v0.6.8';
>   load.
> ]
>
> "Based on the same file from the pharo-vm project"
>
> myRepository := IceRepositoryCreator new
> url: 'g...@github.com:nopsys/CogNOS.git';
> subdirectory: 'Image-src';
> createRepository.
> (myRepository addPackageNamed: 'SqueakNOS') loadLatest.
>
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

Yes, that is the thing. Is libgit reading that properties file or not? I'll
do some digging..

On Tue, Apr 10, 2018 at 11:31 PM, Peter Uhnák  wrote:

> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
>
> There are config options `core.eol` and `core.autocrlf`, but my impression
> was that Iceberg was somehow bypassing them?
>
> Peter
>
>
> On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <
> emaring...@gmail.com> wrote:
>
>> Not stricly related, or maybe yes, but years ago in InfOil we started
>> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
>> that setting to store code in the repo, we didn't have any issues
>>
>> The .gitattributes contained this:
>> *.img binary
>> *.chg binary
>> *.sml binary
>> OurImage.img merge=ours
>> OurImage.chg merge=ours
>> *.pax eol=lf
>> *.cls eol=lf
>>
>> .pax was the "package definition" and "method extensions" (methods not
>> belonging to the package) file.
>> .cls was the 1 file per class+class-side used by this scheme
>>
>> Even we did everything in Windows for some reason I don't remember (+5
>> yrs ago) LF was better for Gitlab. What I also don't remember is if
>> during the checkout in the Gitlab CI some conversion was used or not. I
>> don't remember a lot of things, but I can ask them if you want.
>>
>> But I can confirm that this "trick" does work.
>>
>> Git for Windows even asks you if you want to automatically convert CRLF
>> to LF during checkin and back to CRLF on checkout.
>>
>> Regards,
>>
>>
>> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> > Hi,
>> >
>> > I’ve been wondering how to better fix the problem of having windows and
>> > linux/macOS people contributing and the fact that files are written in
>> > their native system format (crlf windows, lf for the rest of the
>> world).
>> >
>> > I digged a bit and I found a couple a link that helped me (after trying
>> > to understand the
>> > doc): https://stackoverflow.com/questions/170961/whats-the-
>> best-crlf-carriage-return-line-feed-handling-strategy-with-git
>> >
>> > and it seems adding a .gitattributes file with this content:
>> >
>> > # Auto detect text files and perform LF normalization
>> > *text=auto
>> > *.sttext merge=union eol=lf
>> >
>> > could fix the problem?
>> > can someone confirm this?
>> >
>> > (I confess this issue confuses me a lot :P)
>> >
>> > cheers!
>> > Esteban
>>
>> --
>> Esteban A. Maringolo
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

It could be a checkbox in the "create repository dialog".

"Use lf as default line ending"

(and set it to true by default (?))

On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák  wrote:

> An argument can be made that Pharo would _always_ produce LF.
> I don't think I've ever needed _code_ to be CRLF in a ~decade of using git
> on Windows. It was always just an annoyance.
>
> Peter
>
> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano 
> wrote:
>
>> hi,
>>
>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>> wrote:
>> >
>> > Not stricly related, or maybe yes, but years ago in InfOil we started
>> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
>> > that setting to store code in the repo, we didn't have any issues
>> >
>> > The .gitattributes contained this:
>> > *.img binary
>> > *.chg binary
>> > *.sml binary
>> > OurImage.img merge=ours
>> > OurImage.chg merge=ours
>> > *.pax eol=lf
>> > *.cls eol=lf
>> >
>> > .pax was the "package definition" and "method extensions" (methods not
>> > belonging to the package) file.
>> > .cls was the 1 file per class+class-side used by this scheme
>> >
>> > Even we did everything in Windows for some reason I don't remember (+5
>> > yrs ago) LF was better for Gitlab. What I also don't remember is if
>> > during the checkout in the Gitlab CI some conversion was used or not. I
>> > don't remember a lot of things, but I can ask them if you want.
>> >
>> > But I can confirm that this "trick" does work.
>> >
>> > Git for Windows even asks you if you want to automatically convert CRLF
>> > to LF during checkin and back to CRLF on checkout.
>>
>> exactly what I want, because pharo/iceberg/tonel uses the system line
>> ending to write the files :)
>> thanks!
>>
>> Esteban
>>
>> ps: otherwise I will need to add some support in-image and I don’t think
>> is the best approach.
>> pps: now it remains to see if libgit2 honours the .gitattributes config
>>
>> >
>> > Regards,
>> >
>> >
>> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> >> Hi,
>> >>
>> >> I’ve been wondering how to better fix the problem of having windows and
>> >> linux/macOS people contributing and the fact that files are written in
>> >> their native system format (crlf windows, lf for the rest of the
>> world).
>> >>
>> >> I digged a bit and I found a couple a link that helped me (after trying
>> >> to understand the
>> >> doc): https://stackoverflow.com/questions/170961/whats-the-best-
>> crlf-carriage-return-line-feed-handling-strategy-with-git
>> >>
>> >> and it seems adding a .gitattributes file with this content:
>> >>
>> >> # Auto detect text files and perform LF normalization
>> >> *text=auto
>> >> *.sttext merge=union eol=lf
>> >>
>> >> could fix the problem?
>> >> can someone confirm this?
>> >>
>> >> (I confess this issue confuses me a lot :P)
>> >>
>> >> cheers!
>> >> Esteban
>> >
>> > --
>> > Esteban A. Maringolo
>> >
>>
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

Both, the checkbox will be used to set the property in disk at some point
:).

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano <esteba...@gmail.com>
wrote:

> or a .iceberg file?
>
> Esteban
>
> ps: yep, we need it… we will have it, why not start now?
>
> On 10 Apr 2018, at 23:52, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
>
> It could be a checkbox in the "create repository dialog".
>
> "Use lf as default line ending"
>
> (and set it to true by default (?))
>
> On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
>
>> An argument can be made that Pharo would _always_ produce LF.
>> I don't think I've ever needed _code_ to be CRLF in a ~decade of using
>> git on Windows. It was always just an annoyance.
>>
>> Peter
>>
>> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <esteba...@gmail.com>
>> wrote:
>>
>>> hi,
>>>
>>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo <emaring...@gmail.com>
>>> wrote:
>>> >
>>> > Not stricly related, or maybe yes, but years ago in InfOil we started
>>> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we
>>> used
>>> > that setting to store code in the repo, we didn't have any issues
>>> >
>>> > The .gitattributes contained this:
>>> > *.img binary
>>> > *.chg binary
>>> > *.sml binary
>>> > OurImage.img merge=ours
>>> > OurImage.chg merge=ours
>>> > *.pax eol=lf
>>> > *.cls eol=lf
>>> >
>>> > .pax was the "package definition" and "method extensions" (methods not
>>> > belonging to the package) file.
>>> > .cls was the 1 file per class+class-side used by this scheme
>>> >
>>> > Even we did everything in Windows for some reason I don't remember (+5
>>> > yrs ago) LF was better for Gitlab. What I also don't remember is if
>>> > during the checkout in the Gitlab CI some conversion was used or not. I
>>> > don't remember a lot of things, but I can ask them if you want.
>>> >
>>> > But I can confirm that this "trick" does work.
>>> >
>>> > Git for Windows even asks you if you want to automatically convert CRLF
>>> > to LF during checkin and back to CRLF on checkout.
>>>
>>> exactly what I want, because pharo/iceberg/tonel uses the system line
>>> ending to write the files :)
>>> thanks!
>>>
>>> Esteban
>>>
>>> ps: otherwise I will need to add some support in-image and I don’t think
>>> is the best approach.
>>> pps: now it remains to see if libgit2 honours the .gitattributes config
>>>
>>> >
>>> > Regards,
>>> >
>>> >
>>> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
>>> >> Hi,
>>> >>
>>> >> I’ve been wondering how to better fix the problem of having windows
>>> and
>>> >> linux/macOS people contributing and the fact that files are written in
>>> >> their native system format (crlf windows, lf for the rest of the
>>> world).
>>> >>
>>> >> I digged a bit and I found a couple a link that helped me (after
>>> trying
>>> >> to understand the
>>> >> doc): https://stackoverflow.com/questions/170961/whats-the-best-cr
>>> lf-carriage-return-line-feed-handling-strategy-with-git
>>> >>
>>> >> and it seems adding a .gitattributes file with this content:
>>> >>
>>> >> # Auto detect text files and perform LF normalization
>>> >> *text=auto
>>> >> *.sttext merge=union eol=lf
>>> >>
>>> >> could fix the problem?
>>> >> can someone confirm this?
>>> >>
>>> >> (I confess this issue confuses me a lot :P)
>>> >>
>>> >> cheers!
>>> >> Esteban
>>> >
>>> > --
>>> > Esteban A. Maringolo
>>> >
>>>
>>>
>>>
>>
>
>
> --
>
> 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
> <http://www.cnrs.fr/>*
>
> *Web:* *http://guillep.github.io* <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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

I'd say yes?

https://github.com/libgit2/libgit2/commit/b83fd07880307106deb0ac7cb0d415d85c27f465

?

On Tue, Apr 10, 2018 at 11:42 PM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Yes, that is the thing. Is libgit reading that properties file or not?
> I'll do some digging..
>
> On Tue, Apr 10, 2018 at 11:31 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
>
>> > Git for Windows even asks you if you want to automatically convert CRLF
>> > to LF during checkin and back to CRLF on checkout.
>>
>> There are config options `core.eol` and `core.autocrlf`, but my
>> impression was that Iceberg was somehow bypassing them?
>>
>> Peter
>>
>>
>> On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <
>> emaring...@gmail.com> wrote:
>>
>>> Not stricly related, or maybe yes, but years ago in InfOil we started
>>> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
>>> that setting to store code in the repo, we didn't have any issues
>>>
>>> The .gitattributes contained this:
>>> *.img binary
>>> *.chg binary
>>> *.sml binary
>>> OurImage.img merge=ours
>>> OurImage.chg merge=ours
>>> *.pax eol=lf
>>> *.cls eol=lf
>>>
>>> .pax was the "package definition" and "method extensions" (methods not
>>> belonging to the package) file.
>>> .cls was the 1 file per class+class-side used by this scheme
>>>
>>> Even we did everything in Windows for some reason I don't remember (+5
>>> yrs ago) LF was better for Gitlab. What I also don't remember is if
>>> during the checkout in the Gitlab CI some conversion was used or not. I
>>> don't remember a lot of things, but I can ask them if you want.
>>>
>>> But I can confirm that this "trick" does work.
>>>
>>> Git for Windows even asks you if you want to automatically convert CRLF
>>> to LF during checkin and back to CRLF on checkout.
>>>
>>> Regards,
>>>
>>>
>>> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>>> > Hi,
>>> >
>>> > I’ve been wondering how to better fix the problem of having windows and
>>> > linux/macOS people contributing and the fact that files are written in
>>> > their native system format (crlf windows, lf for the rest of the
>>> world).
>>> >
>>> > I digged a bit and I found a couple a link that helped me (after trying
>>> > to understand the
>>> > doc): https://stackoverflow.com/questions/170961/whats-the-b
>>> est-crlf-carriage-return-line-feed-handling-strategy-with-git
>>> >
>>> > and it seems adding a .gitattributes file with this content:
>>> >
>>> > # Auto detect text files and perform LF normalization
>>> > *text=auto
>>> > *.sttext merge=union eol=lf
>>> >
>>> > could fix the problem?
>>> > can someone confirm this?
>>> >
>>> > (I confess this issue confuses me a lot :P)
>>> >
>>> > cheers!
>>> > Esteban
>>>
>>> --
>>> Esteban A. Maringolo
>>>
>>>
>>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <b...@openinworld.com> wrote:

>
>
> On 14 April 2018 at 01:10, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <b...@openinworld.com> wrote:
>>
>>>
>>>
>>> On 13 April 2018 at 23:15, Alistair Grant <akgrant0...@gmail.com> wrote:
>>>
>>>> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferli...@gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
>>>> guillermopol...@gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >> The thing is that the best way to do it is to clone your own fork...
>>>> And each one has her/his one.
>>>>
>>>
>>> I know, but momentarily forgot while trying to work on my first Issue
>>> with the new UI.
>>> However I discovered something cool...
>>>
>>> I had directly cloned "g...@github.com:pharo-project/pharo.git"
>>> successfully brought that "Up to date"
>>> then in the "Working copy of pharo" window, clicked  and
>>> filled in details,
>>> made my code change,
>>> then clicked 
>>> then clicked  bringing me to a window titled "Push
>>> pharo/21686-.../21686..."
>>> where the only option to "Push to remote: " was  "origin (g...@github.com:
>>> pharo-project/pharo.git)"
>>> and clicking  of course produced an error "LGit_GIT_EEOF: ERROR:
>>> Permission to pharo-project/pharo.git denied to bencoman."
>>> Fair enough!
>>>
>>
>> Have to gracefully manage that error. Could you open an issue?
>>
>>
>>>
>>> But then...!!!
>>> Back in the "Repositories" window,
>>> "pharo" > right-click > Repository > Add Remote
>>>Remote name = bencoman
>>>Remote URL = g...@github.com:pharo-project/pharo.git
>>> And back in the "Working copy of pharo" window
>>> clicked   bringing again me to a window titled "Push
>>> pharo/21686-.../21686..."
>>> but now I had an extra option "bencoman <g...@github.com:bencoman/pharo
>>> .git>"
>>> and selecting that and clicking   worked
>>>
>>> https://github.com/bencoman/pharo/tree/21686-Setting-backgro
>>> und-images-doesnt-work-on-Pharo-70
>>>
>>
>> Esteban is working on adding the add remote to the pull/push windows
>>
>> https://github.com/pharo-vcs/iceberg/issues/624
>>
>> so you will have less clicks to do there ;)
>>
>>
>>>
>>>
>>> Now the key thing here is that I **didn't** have to first
>>> synchronise  github.com:bencoman/pharo.git  with  github.com:
>>> pharo-project/pharo.git
>>> and remember to clone  github.com: bencoman/pharo.git .
>>> I just pushed to my repo **after-the-fact**.
>>>
>>> I haven't submitted many fixes lately to get familiar with Iceberg,
>>> and maybe I missed something in the old workflow,
>>> but previously it seemed that my pharo github repo needed to be up to
>>> date,
>>> and I must clone from there.
>>>
>>
>> Well, it depends.
>>
>> Scenario 1) If you're not planning to reuse your clone, you don't need to
>> care about synchronize.
>>  - just reclone pharo from pharo
>>  - add your fork as remote
>>  - you're set
>>
>> Scenario 2) If you want to reuse your clone you may not synchronize them.
>>  - pull from pharo from time to time
>>  - start a new branch from the current commit
>>  - you're set
>>
>> But then, there is people that may want/need to have some other workflow.
>> For example:
>>  - I start from scenario 1
>>  - make a branch
>>  - commit some work
>>  - tomorrow I come back and I download a new image
>> * a couple of integrations may have happened in between!!
>> * but I want to continue working in my branch
>>
>> Then the scenario could be solved as:
>>  - fetch from pharo
>>  - if you're in detached mode, just use the merge image into branch
>> action and select your branch
>>  - or if you want to do it manually:
>>- checkout your branch in your image without loading packages
>>- merge pharo/development into your branch
>>  - continue working
>>
>> Now, wha

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Guillermo Polito]

Is that Pharo 7?

On Fri, Apr 13, 2018 at 9:43 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> Yes I was able to commit also.
> Very slick interface :-)
>
>
> But now, every time I want to commit, my image crash and I have:
>
> Assertion failed: (git_atomic_get(__n_inits) > 0), function
> git__global_state, file /Users/travis/build/OpenSmalltalk/opensmalltalk-
> vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c,
> line 322.
>
>
> On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse  > wrote:
>
>> I could commit my first commit with iceberg 2.0
>> Well done
>>
>> It feels nicer :).
>>
>> Stef
>>
>>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Guillermo Polito]

I want your bug reports!

Le ven. 13 avr. 2018 à 21:09, Stephane Ducasse  a
écrit :

> I could commit my first commit with iceberg 2.0
> Well done
>
> It feels nicer :).
>
> Stef
>
> --



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <b...@openinworld.com> wrote:

>
>
> On 13 April 2018 at 23:15, Alistair Grant <akgrant0...@gmail.com> wrote:
>
>> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferli...@gmail.com>
>> wrote:
>> >
>> >
>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
>> guillermopol...@gmail.com> wrote:
>> >>
>> >>
>> >> The thing is that the best way to do it is to clone your own fork...
>> And each one has her/his one.
>>
>
> I know, but momentarily forgot while trying to work on my first Issue with
> the new UI.
> However I discovered something cool...
>
> I had directly cloned "g...@github.com:pharo-project/pharo.git"
> successfully brought that "Up to date"
> then in the "Working copy of pharo" window, clicked  and filled
> in details,
> made my code change,
> then clicked 
> then clicked  bringing me to a window titled "Push
> pharo/21686-.../21686..."
> where the only option to "Push to remote: " was  "origin (g...@github.com:
> pharo-project/pharo.git)"
> and clicking  of course produced an error "LGit_GIT_EEOF: ERROR:
> Permission to pharo-project/pharo.git denied to bencoman."
> Fair enough!
>

Have to gracefully manage that error. Could you open an issue?


>
> But then...!!!
> Back in the "Repositories" window,
> "pharo" > right-click > Repository > Add Remote
>Remote name = bencoman
>Remote URL = g...@github.com:pharo-project/pharo.git
> And back in the "Working copy of pharo" window
> clicked   bringing again me to a window titled "Push
> pharo/21686-.../21686..."
> but now I had an extra option "bencoman <g...@github.com:bencoman/
> pharo.git>"
> and selecting that and clicking   worked
>
> https://github.com/bencoman/pharo/tree/21686-Setting-
> background-images-doesnt-work-on-Pharo-70
>

Esteban is working on adding the add remote to the pull/push windows

https://github.com/pharo-vcs/iceberg/issues/624

so you will have less clicks to do there ;)


>
>
> Now the key thing here is that I **didn't** have to first
> synchronise  github.com:bencoman/pharo.git  with  github.com:
> pharo-project/pharo.git
> and remember to clone  github.com: bencoman/pharo.git .
> I just pushed to my repo **after-the-fact**.
>
> I haven't submitted many fixes lately to get familiar with Iceberg,
> and maybe I missed something in the old workflow,
> but previously it seemed that my pharo github repo needed to be up to
> date,
> and I must clone from there.
>

Well, it depends.

Scenario 1) If you're not planning to reuse your clone, you don't need to
care about synchronize.
 - just reclone pharo from pharo
 - add your fork as remote
 - you're set

Scenario 2) If you want to reuse your clone you may not synchronize them.
 - pull from pharo from time to time
 - start a new branch from the current commit
 - you're set

But then, there is people that may want/need to have some other workflow.
For example:
 - I start from scenario 1
 - make a branch
 - commit some work
 - tomorrow I come back and I download a new image
* a couple of integrations may have happened in between!!
* but I want to continue working in my branch

Then the scenario could be solved as:
 - fetch from pharo
 - if you're in detached mode, just use the merge image into branch action
and select your branch
 - or if you want to do it manually:
   - checkout your branch in your image without loading packages
   - merge pharo/development into your branch
 - continue working

Now, what I would like is that we detect such "common rough scenarios" and
discuss how we could have a better UI support for them.
Maybe we need as a part of the Pharo plugin a wizard that takes you through
the "synchronize my image again please"?
Or could it be solved with some strategy that is general enough to be
reused in any repository?


>
> The new UI is intuitive and made it east to clone from pharo-project, make
> fix the push to bencoman.
> I worked this out from just a small bit of trial & error.
>
>
> One request...
> In attached snapshot where the remotes show "origin",
> please consider showing that as "pharo-project"
> The term "origin" is useful for generic documentation and for examples,
> but there is *nothing* special about that label from a git perspective.
> A remote is a remote is a remote.
>

Well that's mostly a libgit thing. It does it by default I think when you
clone, and I'm pretty sure that a lot of people would be against breaking
such default because that's how git works also.
Wha

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant <akgrant0...@gmail.com>
wrote:

> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferli...@gmail.com>
> wrote:
> >
> >
> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
> >>
> >>
> >> The thing is that the best way to do it is to clone your own fork...
> And each one has her/his one.
> >>
> >
> >
> > What your can do is display the list of forks and ask to select the
> right one. Then it will create the Pharo repo with the two remotes.
>
>
This would be strange. Pharo has 75 forks...


>
> I was going to suggest prompting for the git username.  You can
> substitute it in to:
>
> g...@github.com:{username}/pharo.git
>
> and add upstream (pharo-project).


Yes, and if it does not exist we have to use github's API to create the
fork...

It's doable... But doing it well will take time:
 - I would like a UI where I explain users what I will do with their git
credentials
 - I would like to prevent them that I'm doing a fork before doing it
 - I want to show a good progress bar
 - I want to wait until github's finished with the fork (it's an async
operation) before continuing with the process
 - And then, I want that if possible iceberg is well (automatically) tested
because there are so many corner cases that it starts to be really
complicated to do it manually.

But also our plate is full with other things, and we have to prioritize...

If someone wants to give it a try, I can give a hand, review, test,
advice...


>
>
> Cheers,
> Alistair
>
>


-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 4:26 PM, Ben Coman  wrote:

>
>
> On 13 April 2018 at 21:14, Marcus Denker  wrote:
>
>>
>>
>> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
>>
>> Can you make the video available online?
>>
>>
>> https://youtu.be/A9H8jsSnBKM
>>
>
> I like the new "New Repo", particularly additional of GitHub alternative
> (not that I use them, but options is good)
> Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo"
> entry or similar
> which presets *everything* required to clone the Pharo repo.
>

The thing is that the best way to do it is to clone your own fork... And
each one has her/his one.


>
> Later, here you might even go as far as letting uses entry an Issue and
> pre-create the branch
> that a fix will be submitted on.  But for now... one step at a time.
>

That's already there


>
> 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-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 5:38 PM, Alistair Grant <akgrant0...@gmail.com>
wrote:

> Hi Guille,
>
> On 13 April 2018 at 17:29, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
> >
> >
> > On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant <akgrant0...@gmail.com>
> > wrote:
> >>
> >> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferli...@gmail.com>
> >> wrote:
> >> >
> >> >
> >> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito
> >> > <guillermopol...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> The thing is that the best way to do it is to clone your own fork...
> >> >> And each one has her/his one.
> >> >>
> >> >
> >> >
> >> > What your can do is display the list of forks and ask to select the
> >> > right one. Then it will create the Pharo repo with the two remotes.
> >>
> >
> > This would be strange. Pharo has 75 forks...
> >
> >>
> >>
> >> I was going to suggest prompting for the git username.  You can
> >> substitute it in to:
> >>
> >> g...@github.com:{username}/pharo.git
> >>
> >> and add upstream (pharo-project).
> >
> >
> > Yes, and if it does not exist we have to use github's API to create the
> > fork...
>
> I hadn't even thought of this, I was assuming that the fork had
> already been created.
>
> I still think this would be useful, especially for regular
> contributors who like to start with a clean image when development a
> PR.
>
>
> > It's doable... But doing it well will take time:
> >  - I would like a UI where I explain users what I will do with their git
> > credentials
> >  - I would like to prevent them that I'm doing a fork before doing it
> >  - I want to show a good progress bar
> >  - I want to wait until github's finished with the fork (it's an async
> > operation) before continuing with the process
> >  - And then, I want that if possible iceberg is well (automatically)
> tested
> > because there are so many corner cases that it starts to be really
> > complicated to do it manually.
> >
> > But also our plate is full with other things, and we have to
> prioritize...
> >
> > If someone wants to give it a try, I can give a hand, review, test,
> > advice...
>
> Fair enough.
>
> Would you be willing to accept a patch that requires an existing fork?
>

Of course good is better than perfect :)

https://github.com/pharo-vcs/iceberg

I've worked yesterday and this morning to have iceberg's ci green and
working for PRs also. I've enhanced included a couple of new tests.


>
> Cheers,
> Alistair
>
>


-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Images, VMs and 32 vs 64bit

[Guillermo Polito]

VMs share most of the code. At least the basic interpreter, primitives and
garbage collector.
But there are some platform specificities such as how some plugins are
managed.
Also there are different JIT backends, one per platform.
I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Pharo Development List , "Peter Uhnák" <
> i.uh...@gmail.com>
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 22:39:16 + (UTC)
> Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
> Thanks!
>
> I don't really care about the image format, my question was more oriented
> towards the code itself.  As I don't have a Mac, I was curious as to
> whether there would be code differences between platforms, VMs and 32 vs
> 64bit distributions, code-wise!
>
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
> On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <
> i.uh...@gmail.com> wrote:
>
>
> > images for different platforms (Mac, Linux, Windows)
>
> yes
> It is the responsibility of the VM to contain the differences. Note that
> there's some "platform-specific" code, but the image contains the code for
> all platforms at once.
> Generally speaking you can code on one platform, copy the image files to
> another and continue your work (although doing this can cause trouble, as
> e.g. some file paths may now point to non-existing locations).
> You can download the images independently of the platform too (e.g. Pharo
> 6 images: http://files.pharo.org/image/60/ )
>
> > VMs (32bit, 64bit)
>
> yes?
> the files are different, but I don't know if there's code difference, or
> if the images are just built with different memory layouts
>
> Peter
>
> On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <
> pharo-dev@lists.pharo.org> wrote:
>
>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Pharo Development List 
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 22:13:18 + (UTC)
> Subject: Images, VMs and 32 vs 64bit
> I was wondering if images for different platforms (Mac, Linux, Windows)
> and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do
> they all have the exact same code base or some classes/methods are in some
> and not in others or different?
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Environment variables encoding ?

[Guillermo Polito]

Hi,

I think this problem is not environment variable exclusive. It also affects
file paths and others. So far Pharo does not detect the locale to perform
the encoding and it should be nice to do it.

On Tue, Apr 17, 2018 at 10:56 AM, Henrik Sperre Johansen <
henrik.s.johan...@veloxit.no> wrote:

> Damien Pollet wrote
> > It seems macOS normalizes UTF-8 differently from everyone else in file
> > names (I think base character + composing instead of precomposed
> > codepoint). That might affect PWD.
> > For environment variables, even if most sensible platforms should have
> > adopted UTF-8 by now, I wouldn't be surprised if there's no official
> > encoding whatsoever (i.e. they're just bytes with a 0 at the end…)
> >
> > On 17 April 2018 at 09:36, Sven Van Caekenberghe 
>
> > sven@
>
> >  wrote:
> >
> >> Hi,
> >>
> >> The dictionary
> >>
> >>  OSPlatform current environment
> >>
> >> contains a copy of the OS's environment variables (more correctly of the
> >> VM process), as key/value pairs.
> >>
> >> These are obtained via the following system calls:
> >>
> >> on macOS & *nix
> >>
> >>   LIBC environ
> >>
> >> on Windows
> >>
> >>   KERNEL32 GetEnvironmentStrings
> >>
> >> It is however a bit unclear how these are encoded. On macOS & *nix that
> >> seems to be UTF8, on Windows there are some reports that it appears to
> be
> >> Latin1 - but both might be locale specific, I don't know either way.
> >>
> >> Does anyone know for sure ?
> >>
> >> I furthermore think that OSEnvironment and its subclasses, who do this
> >> call, should be responsible for decoding the C strings into proper Pharo
> >> strings, and not leave that responsibility to its users.
> >>
> >> Fundamentally, in the following, the decoding is still not done
> correctly
> >> and that is wrong/confusing IMHO.
> >>
> >> $ FOO=benoît ./pharo Pharo.image eval 'OSEnvironment current
> >> associations'
> >> {'TERM_PROGRAM'->'Apple_Terminal'. 'TERM'->'xterm-256color'.
> >> 'SHELL'->'/bin/bash'. 'TMPDIR'->'/var/folders/sy/
> >> sndrtj9j1tq06j0lfnshmrl8gn/T/'. 'FOO'->'benoît'.
> >> 'Apple_PubSub_Socket_Render'->'/private/tmp/com.apple.
> launchd.uWk7pivcLT/Render'.
> >> 'TERM_PROGRAM_VERSION'->'404'.
> >> 'TERM_SESSION_ID'->'845BECCD-0AB0-4686-B7F9-3A0FF84BDCB7'.
> >> 'USER'->'sven'.
> >> 'SSH_AUTH_SOCK'->'/private/tmp/com.apple.launchd.y5oCwdUyaG/Listeners'.
> >> 'PATH'->'/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/
> texbin:/opt/X11/bin'.
> >> 'PWD'->'/tmp/benoît'. 'XPC_FLAGS'->'0x0'. 'XPC_SERVICE_NAME'->'0'.
> >> 'HOME'->'/Users/sven'. 'SHLVL'->'2'. 'LOGNAME'->'sven'.
> >> 'LC_CTYPE'->'UTF-8'. 'DISPLAY'->'/private/tmp/com.
> >> apple.launchd.lsgASYFiWW/org.macosforge.xquartz:0'.
> >> 'SECURITYSESSIONID'->'186a9'. 'OLDPWD'->'/tmp/benoît'.
> >> '_'->'/tmp/benoît/pharo-vm/Pharo.app/Contents/MacOS/Pharo'.
> >> '__CF_USER_TEXT_ENCODING'->'0x1F5:0x0:0x0'}
> >>
> >> Of course, if we change this, we will need to fix callers.
> >>
> >> Opinions ?
> >>
> >> Sven
> >>
> >> PS: Furthermore, I note that there is a subtle difference in how $FOO
> and
> >> $PWD in the above are UTF-8 encoded. In the former, normalisation was
> >> done,
> >> in the latter not. Maybe that could lead to problems (when
> >> comparing/composing them). This is a difficult/complex subject (
> >> https://medium.com/concerning-pharo/an-implementation-of-unicode-
> >> normalization-7c6719068f43).
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Damien Pollet
> > type less, do more [ | ] http://people.untyped.org/damien.pollet
>
> If by different, you mean that it actually normalizes the file names, then
> yes.
> All Mac filenames are in a well defined form; NFD.
> On linux, they're just arrays of bytes, and anything goes.
> That the bytes mostly happen to be valid utf8 strings in NFC, is just a
> by-product of the fact that's the format most programs use when calling the
> file primitives.
>
> Cheers,
> Henry
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] DelayScheduler cleanup & Bootstrap

[Guillermo Polito]

On Sun, Apr 15, 2018 at 3:19 PM, Ben Coman  wrote:

> I am doing a pass to cleanup the DelayScheduler hierarchy.
> I'll be refactoring of the hierarchy to aid code understanding
> and eliminate redundant instance variables from the original code.
> The target structure is
> DelayNullScheduler -- minimum interface to avoid errors in rest of system
> (6 empty methods)
> |__DelayBasicScheduler -- fully working sans race protection (equivalent
> to Courageous scheduler)
>   |__DelaySpinScheduler -- plus race protection
>
> Can someone advise how/where the Bootstrap loads Delay and the
> DelaySchedulers?
>

Delay and Delay schedulers are atomically loaded during bootstrap (because
they are part of the Kernel package so far).
So there should be nothing special to do there.


> where the invocation of Delay_class>>#initialize selects the delay
> scheduler.
>

Once the image is created, the first method invoked is

PharoBootstrapInitialization >> initializeCommandLineHandlerAndErrorHandling

which is in the image. You can change it as you please :).


> I need to determine whether during transition the Bootstrap might need to
> temporarily hop to a different scheduler,
> and how to provide the new structure in the Image for operational testing
> before switching.
>

In the bootstrap there is no "switching". A new image is created from
scratch with the code that you provide...
Initially the image has no delay scheduler process, so calling `Delay class
initialize` will create it for you.

So as soon as you define

Delay class >> initialize
"Delay initialize"
Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ].
Scheduler := *MyNewScheduler new*.
Scheduler startTimerEventLoop.
SessionManager default
registerSystemClassNamed: self name
atPriority: 20.

The bootstrap will take it into account.
And tests will be run with that configuration.

Maybe there is something else to it?
You want to do test the switching also? Because for this I would do it with
normal smalltalk code... no bootstrap involved...


>
> 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-dev] Do we kill the catalog?

[Guillermo Polito]

Hi all,

IMHO, the problem is not metacello or gofer but the fact that the catalog
uses the old Metacello API: i.e.,

Gofer new
  repository: 'zzz';
  configurationOf: 'XXX';
  load.
(ConfigurationOfXXX project version: #YYY) load

instead of the *new* Metacello API

Metacello new
  repository: 'zzz'
  configurationOf: 'XXX'
  loadVersion: #'YYY'



On Fri, Apr 20, 2018 at 3:34 PM, Esteban Lorenzano 
wrote:

>
>
> > On 20 Apr 2018, at 12:42, Cyril Ferlicot D. 
> wrote:
> >
> > Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
> >>
> >>
> >>> On 20 Apr 2018, at 11:01, Thierry Goubier  >>> > wrote:
> >>>
> >>> Le 20/04/2018 à 09:09, Stephane Ducasse a écrit :
>  The underlying questions (sorry for people that need subtitles) are:
>  - how do we have a central place to declare projects
>  - right now in Smalltalkhub/list is a nice way to find projects
>  with the move to github
>  we should get a central place
> >>>
> >>> One of the issues I have with the Catalog is that it made a mess of
> >>> the various MetaRrepo for Pharo... Showing in the end that the single
> >>> place one should put a ConfigurationOf for Pharo is the squeak meta
> repo.
> >>
> >> not really.
> >> if you put your project in the squeak meta repo it will not even be
> >> listed (is old stuff and we are not listing those).
> >>
> >> the idea was to add a project in its corresponding development repo. But
> >> is an uncomfortable way, yes (and it was a patch, not meant to last)
> >>
> >>> That in addition the Catalog doesn't even use the best package
> >>> management we have at a given point is just salt rubbed in the wound.
> >>
> >> that’s a one method change. Instead:
> >>
> >> loadConfiguration
> >> Gofer it
> >> url: self repositoryUrl;
> >> configurationOf: self name;
> >> load
> >>
> >> loadConfiguration
> >> Metacello new
> >> repository: self repositoryUrl;
> >> configuration: self name;
> >> load.
> >>
> >> when I made catalog, Metacello usage was not so expanded.
> >> Yet… gofer will use metacello to load so, yes, it will use the best
> >> package management we have at the moment.
> >>
> >
> > Hi,
> >
> > Except if it changed recently, Gofer does not use Metacello behind.
> >
> > At Synectique when I tried to clean all our configurations because it
> > was really hard to update them, I found some problems in the
> > configurations but the projects were loading. The reasons was that we
> > used Gofer and the bugs of gofer compensated the problems in the
> > configurations. After switching to Metacello the projects did not load
> > anymore and I needed to fix the configurations to make them clean.
> >
> > So, if it worked with Gofer but not Metacello, I doubt Gofer use
> Metacello.
>
> there is no way of loading a configuration/baseline without metacello.
>
> Esteban
>
> >
> >>
> >> very unlikely.
> >> a spec made in STON you just have to modify it each time you do a
> >> release (which is exactly what you have to do now with configurations).
> >>
> >> A crawler will not handle the need to publish a released version.
> >>
> >> one STON file as I imagine would be something like:
> >>
> >> project {
> >> “name” : "blah",
> >> “url” : "http://github.com/someone/blah;,
> >> “lastVersion” : “v1.0.0",
> >> “description” : “Some project description"
> >> }
> >>
> >> and maybe a couple more. How’s that cryptic?
> >> maybe you are confusing things?
> >>
> >>
> >
> >
> > --
> > Cyril Ferlicot
> > https://ferlicot.fr
> >
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Do we kill the catalog?

[Guillermo Polito]

Hi all,

I think that we are all aligned. Stef may be "too strong" in his way of
talking, but he raised an issue: we should probably do an iteration on the
catalog. And I think we all agree on that?

So, what would be a list of tasks for it? (I copy past what Stef put before)

- Use Metacello API.
Metacello new
  repository: 'zzz'
  configurationOf: 'XXX'
  loadVersion: #'YYY'


This point should is easy. I can open an issue and work on it today.


- Support for Baseline (no idea what it means)

This point requires that we agree on how to publish baselines.
Should we continue providing configurations that point to the
baselines? I've read some rants against it.
I know it may be "uncomfortable", but publishing some meta-data in a
repository in XXX technology is kind of the same...
We can argue about visibility and smalltalkhub's stability (I've seen
new users struggling to create an account and making a satisfactory
login), but this can be a separate issue.


- What else?


Now, I also think about what to do with the meta-repo's. Should Pharo7 see
MetaRepo for pharo 5 and pharo 6 and pharo 4? or should only see the one
for pharo 7?

What about Pharo 6? What are the meta-repo's it is looking for?

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

[Guillermo Polito]

Can't we make Extensions first class objects in ring?

On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek 
wrote:

> 2018-03-26 10:52 GMT+02:00 Stephane Ducasse :
> > Pavel
> >
> > Why we do not know if this is a class or trait?
>
> Imagine that you are loading a package that has an extension method to
> a class in a foreign package. It is identified only by the behavior
> name, e.g. "TBehavior". But later, e.g. during merging of the package
> model with some other, you will realize that the method is in fact a
> part of a trait so you need to change kind of the class stub you
> already have.
>
> > Maybe we could have decided that Ring2 only works for new traits if
> > this simplifies your life.
>
> Because the traits are now a library and anyone can come with its own
> metaclass that modifies the behavior metamodel, it is reasonable to
> support it. And anyway, this work is already done ;-)
>
> -- Pavel
>
> > Stef
> >
> > On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek
> >  wrote:
> >> Hi,
> >>
> >> I did some serious Ring 2 refactorings that I wanted to have finished
> >> before the integration into Pharo.
> >> Because Pharo now starts to support the stateful traits, it needs to
> >> be supported by the metamodel too. However, we need to be able to
> >> model the images with the old traits as well and from the internal
> >> point of view, they are quite different.
> >> Moreover, if you load a code into the Ring model, you sometimes do not
> >> know if the behavior, where you load a method, is a class or you later
> >> will realize that it is a trait. The Ring 2 used for this a complex
> >> machinery that was able to switch the behavior kind using the
> >> #becomeForward: message.
> >> Some time ago I decided to solve both problems by introducing of the
> >> behavior strategies. That means that every behavior is a composition
> >> of an instance of the RGBehavior class and a behavior strategy (e.g.
> >> RGClassStrategy). Then changing of the behavior kind is then only a
> >> matter of swapping of the strategy (which has a state so it not so
> >> straightforward but still easy). The classes like RGClass or RGTrait
> >> are still present but now they are only the factories that produce the
> >> behaviors and they have no real instances.
> >>
> >> The next big thing I decided to do in Ring is renaming of the
> >> entities. From the beginning, I used the prefix "RG2" to avoid the
> >> collisions with the old Ring implementation but I supposed that before
> >> the final release it will be renamed because, from the user
> >> perspective, the Ring 2 should be a replacement for the old Ring and
> >> not completely separate project. The attempts to replace the old Ring
> >> with the new one showed me, that it is possible, but the old Ring is
> >> so deeply used in the system that it leads to a huge amount of
> >> instabilities.
> >> So I decided to rename the Ring 2 classes and some methods to do not
> >> make collisions with the old implementation. While the old Ring class
> >> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
> >> now it is renamed simply to RGClass. RG2Definition was renamed to
> >> RGObject. The only ugly exception is RG2Package which is now named
> >> RGPackageDefinition because the old Ring does not follow the naming
> >> convention and uses the name "RGPackage". The old Ring packages will
> >> get suffix "Deprecated" into their names. The old Ring and the Ring2
> >> can coexist in one image and it is still possible to load the new Ring
> >> into the Pharo 6.
> >>
> >> Then I started to work on the changes metamodel for Ring with the goal
> >> to be able to record, reproduce and revert (almost) all changes that
> >> the user does in the model. The main goal of it is to be able to get
> >> comparisons of two models and compute loading order of the changes so
> >> it will be more easy to replace the Monticello metamodel and the
> >> metamodel for code differences with a single solid solution based on
> >> Ring.
> >>
> >> Cheers,
> >> -- Pavel
> >>
> >
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Guillermo Polito]

On Fri, Mar 23, 2018 at 7:53 PM, Ben Coman  wrote:

>
>
> On 23 March 2018 at 11:31, Ben Coman  wrote:
>
>>
>>
>> On 23 March 2018 at 05:14, Cédrick Béler  wrote:
>>
>>> Hi,
>>>
>>> I just saw students and they still have some problem on windows with the
>>> launcher.
>>>
>>> First, the launcher has to be run in admin mode.
>>>
>>> Then, the image download starts but there is an error when
>>> uncompressing. Here is the stack.
>>>
>>> Any idea on how to fix that ?
>>>
>>
>> Now I notice...
>> the Linux PharoLauncher download is a ZIP file
>> and the Mac PharoLauncher download is a ZIP file
>> so... can we make the Windows PharoLauncher download a ZIP file?
>>
>> Doing that, at least as an interim measure, would *immediately* make
>> PharoLauncher
>> usable to students on locked-down Windows machines in University student
>> labs.
>> I'd expect this will improve the success with this experiment
>> to use PharoLauncher as the main user entry point.
>>
>> The problem with using an "Installer" for the Windows PharoLauncher is
>> the large amount
>> of testing required to work *reliably* with *all* the "different ways
>> people work"
>> under several different versions of Windows introduced different layers
>> of user security intricacies.
>> Lets move forward in small steps.  A ZIP download/extract is simple, and
>> consistent with other platforms.
>>
>> In the meantime while waiting for that to happen, you can...
>>
>> 1. Download/extract  http://files.pharo.org/platform/Pharo6.1-win.zip
>>
>> 2. Rename  Pharo6.1folder to  PharoLauncher
>> Rename  Pharo6.1.*  files toPharoLauncher1.1.*
>>
>> 3. Metacello new
>>smalltalkhubUser: 'Pharo'
>>project: 'PharoLauncher';
>>configuration: 'PharoLauncher';
>>load.
>> PhLDeploymentScript doAll.
>> PharoLauncher open.
>> Smalltalk snapshot: true  andQuit: true.
>>
>
>> 4. Zip up the parent folder, test on another machine and provide a link
>> to your students.
>>
>> cheers -ben
>>
>>
>> P.S.  I was going to suggest also renaming  Pharo.exe  to
>> PharoLauncher.exe
>> but with an empty Documents\Pharo\vms
>> I get... "Error: Cannot detect Pharo executable in
>> C:\Temp\MyPharoLauncher\PharoLauncher"
>> in PhLVirtualMachine>>initializeOn: "File @
>> C:\Temp\MyPharoLauncher\PharoLauncher"
>> since "executables := aFolder allChildrenMatching: self class
>> executableName."
>> is empty since "self class executableName" ==> "Pharo.exe"
>>
>> It would be nice for that to not be hard coded.  I tried digging further
>> but ran out of time.
>> I am curious it mattered since using "Pharo.exe" the Launcher went on to
>> download a VM anyway.
>>
>>
>> P.S.2.
>> I believe the best path forward for system-wide PharoLauncher installed
>> under "C:\Program Files"
>> would be to install there only...
>> * the VM
>> * PharoLauncher.ZIP
>> * a tiny non-Pharo wrapper program as the shortcut linked from AllUsers >
>> Start Menu > PharoLauncher
>> that extracts PharoLauncher.ZIP to the user's data area and then starts
>> that user specific PharoLauncher.
>>
>> Then regardless whether:
>> * they individually download/extract  PharoLauncher.ZIP
>> * the system-wide-wrapper extracts  PharoLauncher.ZIP
>> its a similar experience for users which should aid reliability by
>> reducing the number of "different " use cases.
>>
>
> Coincidentally I have returned to Windows for a short while so thought I
> should
> put my money where my mouth is and have a stab at this.  After a few hours
> trying with NSIS,
> I went searching for an alternative and Advanced Installer looked like a
> good chance.
> https://www.advancedinstaller.com/feats-list.html
> The important part of  (free) Basic Features  is "Windows 10/8/7/Vista and
> UAC installs"
> Also further down are some CI options.
>
> After just the "Simple Installation" tutorial and experimenting a few
> hours I ironed out
> a potential solution uploaded for testing to
> http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi
> with the full build tree at  http://www.mediafire.com/file/
> 5ijiww848lbkk7m/PharoLauncher%20Advanced%20Installer.zip
> Links should be live for 30 days.
> I've directly attached the much smaller installer-configuration file
> "PharoLauncher.aip".
>
>
> PharoLauncher was built with some minor changes from above...
> 1. Download/extracted  http://files.pharo.org/platform/Pharo6.1-win.zip
>
> 2. Renamed  Pharo6.1folder to  BCPharoLauncher
> Renamed  Pharo6.1.*  files toPharoLauncher1.1.*
>
> 3. Metacello new
>smalltalkhubUser: 'Pharo'
>project: 'PharoLauncher';
>configuration: 'PharoLauncher';
> load.
>  PharoLauncher hardResetPersistanceState: true.
>  PhLDeploymentScript doAll.
>  PhLDeploymentScript  closeWindowsAndOpenLauncher.
>  Smalltalk snapshot: true  andQuit: true.
>
> 4. Moved the  image & changes  files into a subfolder 

Re: [Pharo-dev] Build 739 breaks project load initialization order?

[Guillermo Polito]

I'm checking it.

It may be a side effect of: https://github.com/pharo-project/pharo/pull/1130

Short story long:
 - building Pharo we need to ensure that class initializations are executed
in a particular order, so some metacello configurations are disabling
monticello initializers during baselines
 - I introduced/refactored a couple of new baselines because I'm playing
with creating smaller images.
- I discovered (and tried to patch probably not entirely right) a bug
that makes baseline postloads being executed more than once
 - but all tests were green :D

So I'll introduce a new test to verify that monticello initializers are
enabled by default and check what the problem is.
Keep you updated.


On Thu, Mar 29, 2018 at 9:18 AM, Max Leske  wrote:

> I can confirm that class side #initialization is broken. Don't know since
> when though.
>
> Cheers,
> Max
>
>
>
> On 29 March 2018 at 08:28:00, Martin McClure (mar...@hand2mouse.com)
> wrote:
>
> Good to know. In my case, however, I'm always loading code into a fresh
> image where these classes don't previously exist, so I would think that
> #initialize would always be sent.
>
>
> On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote:
> > class side #initialize is only send by MC if the incoming source code is
> different, has changed. I always add a date in a comment to be sure.
> >
> >> On 29 Mar 2018, at 04:47, Martin McClure 
> wrote:
> >>
> >> On 03/28/2018 04:35 PM, Martin McClure wrote:
> >>> I have a project that loads via Metacello in builds up through build
> >>> 738. In 739 the load fails with DNU.
> >>>
> >>> The failure is in a method I have specified via a #postLoadDoIt:. It
> >>> fails because it sends a message to a pool variable, which is nil.
> >>> However, it should not be nil because it should have been initialized
> by
> >>> a class-side #initialize method in a prerequisite package.
> >>>
> >>> Again, this worked up through build 738. Any idea what changed in 739
> >>> that would cause this, and is this change intentional?
> >> Odd, I don't see any code changes that would be likely to have caused
> this.
> >>
> >> Is the expected behavior of Metacello to send #initialize to classes in
> >> prerequisite packages before running a #postLoadDoIt in a package? I'd
> >> think so, but am starting to wonder if this is perhaps unordered and
> >> I've just been lucky...
> >>
> >> -Martin
> >
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Build 739 breaks project load initialization order?

[Guillermo Polito]

PR: https://github.com/pharo-project/pharo/pull/1161

I added a test to avoid this problem in the future.

Guille

On Thu, Mar 29, 2018 at 9:36 AM, Guillermo Polito <guillermopol...@gmail.com
> wrote:

> Issue: https://pharo.manuscript.com/f/cases/21658/
> Monticello-initializers-are-not-enabled-by-default
>
> On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> I'm checking it.
>>
>> It may be a side effect of: https://github.com/pharo-proje
>> ct/pharo/pull/1130
>>
>> Short story long:
>>  - building Pharo we need to ensure that class initializations are
>> executed in a particular order, so some metacello configurations are
>> disabling monticello initializers during baselines
>>  - I introduced/refactored a couple of new baselines because I'm playing
>> with creating smaller images.
>> - I discovered (and tried to patch probably not entirely right) a bug
>> that makes baseline postloads being executed more than once
>>  - but all tests were green :D
>>
>> So I'll introduce a new test to verify that monticello initializers are
>> enabled by default and check what the problem is.
>> Keep you updated.
>>
>>
>> On Thu, Mar 29, 2018 at 9:18 AM, Max Leske <maxle...@gmail.com> wrote:
>>
>>> I can confirm that class side #initialization is broken. Don't know
>>> since when though.
>>>
>>> Cheers,
>>> Max
>>>
>>>
>>>
>>> On 29 March 2018 at 08:28:00, Martin McClure (mar...@hand2mouse.com)
>>> wrote:
>>>
>>> Good to know. In my case, however, I'm always loading code into a fresh
>>> image where these classes don't previously exist, so I would think that
>>> #initialize would always be sent.
>>>
>>>
>>> On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote:
>>> > class side #initialize is only send by MC if the incoming source code
>>> is different, has changed. I always add a date in a comment to be sure.
>>> >
>>> >> On 29 Mar 2018, at 04:47, Martin McClure <mar...@hand2mouse.com>
>>> wrote:
>>> >>
>>> >> On 03/28/2018 04:35 PM, Martin McClure wrote:
>>> >>> I have a project that loads via Metacello in builds up through build
>>> >>> 738. In 739 the load fails with DNU.
>>> >>>
>>> >>> The failure is in a method I have specified via a #postLoadDoIt:. It
>>> >>> fails because it sends a message to a pool variable, which is nil.
>>> >>> However, it should not be nil because it should have been
>>> initialized by
>>> >>> a class-side #initialize method in a prerequisite package.
>>> >>>
>>> >>> Again, this worked up through build 738. Any idea what changed in
>>> 739
>>> >>> that would cause this, and is this change intentional?
>>> >> Odd, I don't see any code changes that would be likely to have caused
>>> this.
>>> >>
>>> >> Is the expected behavior of Metacello to send #initialize to classes
>>> in
>>> >> prerequisite packages before running a #postLoadDoIt in a package?
>>> I'd
>>> >> think so, but am starting to wonder if this is perhaps unordered and
>>> >> I've just been lucky...
>>> >>
>>> >> -Martin
>>> >
>>>
>>>
>>>
>>
>>
>> --
>>
>>
>>
>> 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
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Build 739 breaks project load initialization order?

[Guillermo Polito]

Issue:
https://pharo.manuscript.com/f/cases/21658/Monticello-initializers-are-not-enabled-by-default

On Thu, Mar 29, 2018 at 9:33 AM, Guillermo Polito <guillermopol...@gmail.com
> wrote:

> I'm checking it.
>
> It may be a side effect of: https://github.com/pharo-
> project/pharo/pull/1130
>
> Short story long:
>  - building Pharo we need to ensure that class initializations are
> executed in a particular order, so some metacello configurations are
> disabling monticello initializers during baselines
>  - I introduced/refactored a couple of new baselines because I'm playing
> with creating smaller images.
> - I discovered (and tried to patch probably not entirely right) a bug
> that makes baseline postloads being executed more than once
>  - but all tests were green :D
>
> So I'll introduce a new test to verify that monticello initializers are
> enabled by default and check what the problem is.
> Keep you updated.
>
>
> On Thu, Mar 29, 2018 at 9:18 AM, Max Leske <maxle...@gmail.com> wrote:
>
>> I can confirm that class side #initialization is broken. Don't know since
>> when though.
>>
>> Cheers,
>> Max
>>
>>
>>
>> On 29 March 2018 at 08:28:00, Martin McClure (mar...@hand2mouse.com)
>> wrote:
>>
>> Good to know. In my case, however, I'm always loading code into a fresh
>> image where these classes don't previously exist, so I would think that
>> #initialize would always be sent.
>>
>>
>> On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote:
>> > class side #initialize is only send by MC if the incoming source code
>> is different, has changed. I always add a date in a comment to be sure.
>> >
>> >> On 29 Mar 2018, at 04:47, Martin McClure <mar...@hand2mouse.com>
>> wrote:
>> >>
>> >> On 03/28/2018 04:35 PM, Martin McClure wrote:
>> >>> I have a project that loads via Metacello in builds up through build
>> >>> 738. In 739 the load fails with DNU.
>> >>>
>> >>> The failure is in a method I have specified via a #postLoadDoIt:. It
>> >>> fails because it sends a message to a pool variable, which is nil.
>> >>> However, it should not be nil because it should have been initialized
>> by
>> >>> a class-side #initialize method in a prerequisite package.
>> >>>
>> >>> Again, this worked up through build 738. Any idea what changed in 739
>> >>> that would cause this, and is this change intentional?
>> >> Odd, I don't see any code changes that would be likely to have caused
>> this.
>> >>
>> >> Is the expected behavior of Metacello to send #initialize to classes
>> in
>> >> prerequisite packages before running a #postLoadDoIt in a package? I'd
>> >> think so, but am starting to wonder if this is perhaps unordered and
>> >> I've just been lucky...
>> >>
>> >> -Martin
>> >
>>
>>
>>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [pharo-project/pharo] 21646 AbstractFileReference should use "utilities" protocol name (#1149)

[Guillermo Polito]

Hi Torsten,

I like all this cleanups and recategorizations.

But I have two requests, tell me what you think:

 - first and more important. I'd like that we define a convention document
in a wiki page or pillar document for protocols. What are the correct
protocols to use and why? This is important for newcomers and for making
tools. I see that you're doing a lot of recategorizations but I'd like if
we set them up and discuss them in the mailing list.

 - second and more technological. Why are all categorizations splitted in
mini pull requests, scoped to one class? Can we group them at least by
package? otherwise this is killing our integration infrastructure (which is
modest but for free :)). Also separating all this changes means that we
cannot easily find them in the history later on, I'd prefer that we group
related changes in related commits if possible.  Marcus was telling me this
may be because people have trouble reviewing them if they are too big? I
can review if you put me ask me as reviewer.

Tx,
Guilel

On Sun, Mar 25, 2018 at 8:54 PM, Astares  wrote:

> https://pharo.fogbugz.com/f/cases/21646/AbstractFileReference-should-
> use-utilities-protocol-name
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/pharo-project/pharo/pull/1149
> Commit Summary
>
>- 21646 AbstractFileReference should use "utilities" protocol name
>
> File Changes
>
>- *M* src/FileSystem-Core/AbstractFileReference.class.st
> (2)
>
> Patch Links:
>
>- https://github.com/pharo-project/pharo/pull/1149.patch
>- https://github.com/pharo-project/pharo/pull/1149.diff
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> , or mute the thread
> 
> .
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Pharo 7 new file stream encoders

[Guillermo Polito]

That should be fixed now. I proposed also the rename. I can revert it if
needed.

On Fri, Mar 16, 2018 at 1:04 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:

>
>
> > On 16 Mar 2018, at 11:29, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > Yes, I'll provide a PR with that functionality soon. Probably in that
> case *ZnCrPortableWriteStream* is not the right name for that class. Sven,
> do you think renaming it now (before it has lots of users) would be
> acceptable towards backwards compatibility? Otherwise I would name it
> ZnNewLineConverterStream...
>
> Renaming is OK/better, if it works (critical class in IO)
>
> Note #forPlatformLineEnding should do: OSPlatform current lineEnding
>
> > Keep you updated,
> > Guille
> >
> > On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
> > I think the idea is to use ZnCrPortableWriteStream for that.
> >
> > > On 15 Mar 2018, at 14:58, Thierry Goubier <thierry.goub...@gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > how does one create a file stream in Pharo 7 that forces a specific
> > > line end convention ? For example, for forcing all end of lines to be
> > > Character lf.
> > >
> > > The old way,
> > >
> > > fileStream lineEndConvention: #'lf'.
> > >
> > > does not work anymore.
> > >
> > > Thanks,
> > >
> > > Thierry
> > >
> >
> >
> >
> >
> >
> > --
> >
> > 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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] FileHandle creates a buffered stream on a buffered stream

[Guillermo Polito]

Nice catch. The write stream is well defined in comparison.

https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-stream-on-a-buffered-stream

https://github.com/pharo-project/pharo/pull/1118

Can somebody review please?

Tx,
Guille

On Thu, Mar 15, 2018 at 4:00 PM, Sven Van Caekenberghe  wrote:

> Hi (Guille),
>
> FileHandle creates a buffered stream on a buffered stream when sent
> #readStream.
>
> Note how #binaryReadStream adds a bufferer stream as well as
> #readStreamEncoded:
>
> Probably the latter should not do this
>
> Sven
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Pharo 7 new file stream encoders

[Guillermo Polito]

Thierry, Sven,

Can you review https://github.com/pharo-project/pharo/pull/1116 ?

Tx,
Guille

On Fri, Mar 16, 2018 at 11:29 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Hi,
>
> Yes, I'll provide a PR with that functionality soon. Probably in that case
> *ZnCrPortableWriteStream* is not the right name for that class. Sven, do
> you think renaming it now (before it has lots of users) would be acceptable
> towards backwards compatibility? Otherwise I would name it
> ZnNewLineConverterStream...
>
> Keep you updated,
> Guille
>
> On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
>
>> I think the idea is to use ZnCrPortableWriteStream for that.
>>
>> > On 15 Mar 2018, at 14:58, Thierry Goubier <thierry.goub...@gmail.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > how does one create a file stream in Pharo 7 that forces a specific
>> > line end convention ? For example, for forcing all end of lines to be
>> > Character lf.
>> >
>> > The old way,
>> >
>> > fileStream lineEndConvention: #'lf'.
>> >
>> > does not work anymore.
>> >
>> > Thanks,
>> >
>> > Thierry
>> >
>>
>>
>>
>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Performances of source code search on latest Pharo

[Guillermo Polito]

Yes, looking at the stack in the profiler, there is a buffered stream
missing in there. The thing is that source/changes file reading/writing
required special attention in the migration (or the image became unusable
:)).

I'll fix it tomorrow first thing in the morning, if you can wait a couple
of hours ;)

Guille

On Sun, Mar 18, 2018 at 10:54 AM, Sven Van Caekenberghe 
wrote:

>
>
> > On 18 Mar 2018, at 00:03, Cyril Ferlicot 
> wrote:
> >
> > Time to execute: SystemNavigation new browseMethodsWithSourceString:
> > 'Method source with it' matchCase: false
> >
> > Pharo 6.1: 2480ms
> >
> > Pharo 7: 132041ms
>
> You didn't type a digit too much, did you ? That is 2 orders of magnitude,
> maybe on Windows ;-)
>
> https://pharo.manuscript.com/f/cases/21612/Performances-
> regression-on-source-code-search
>
> I can confirm that the slowdown pre/post recent file/stream changes in
> Pharo 7 is about 1 order of magnitude (x10).
>
> There is however no fundamental problem, since the following are equally
> fast (~ 1s) in both cases (using old/new streams).
>
> SmalltalkImage current sourcesFile asFileReference readStreamDo: [ :in | [
> in atEnd ] whileFalse: [ in next ] ]
>
> I think there is a ZnBufferedReadStream missing (between the
> ZnCharacterReadStream and the primitive File stream) in
> SourceFile>>#tryOpenReadOnly:
>
> Sven
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[Guillermo Polito]

Hi!

On Mon, Mar 19, 2018 at 9:17 AM, Alistair Grant 
wrote:

[SNIP]

>
> https://pharo.fogbugz.com/f/cases/21615/Separate-bootstrap-process-in-to-
> distinct-stages
>
> https://github.com/pharo-project/pharo/pull/1127
>
> This does the first step of breaking the bootstrap process in to
> distinct phases and moving all the downloads to the start (e.g.
> allowing a test VM to be substituted for the build stage).


Nice! thanks!


>
> Once this is integrated I can submit a PR that modifies Jenkinsfile to
> use the new shell scripts, removing code duplication.
>

Question: Why not in this same PR?


>
>
> On 16 March 2018 at 14:38, teso...@gmail.com  wrote:
> > Hi,
> >  sorry my mistake when updating the scripts. As the bootstrap.sh is
> not
> > executed during the Jenkins process it has not been validated (locally
> I'm
> > not using that script, because is trying to download each time the VM and
> > the bootstraping process image)
>
> There are also scripts to snapshot and restore the bootstrap state,
> avoiding the need to do the multiple downloads.
>
> Just to be clear again: This is intended to complement and help with
> the goal of moving the bootstrap process to pure Pharo code.  Each of
> the shell scripts can eventually be replaced by a call to the
> equivalent Pharo code.
>
>
:)


>
> Thanks!
> Alistair
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] pharo bootstrap is in inconsistent state

[Guillermo Polito]

On Mon, Mar 19, 2018 at 2:13 PM, Alistair Grant <akgrant0...@gmail.com>
wrote:

> Hi Guille,
>
> On 19 March 2018 at 13:59, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
> > Hi!
> >
> > On Mon, Mar 19, 2018 at 9:17 AM, Alistair Grant <akgrant0...@gmail.com>
> > wrote:
> >
> > [SNIP]
> >>
> >>
> >>
> >> https://pharo.fogbugz.com/f/cases/21615/Separate-
> bootstrap-process-in-to-distinct-stages
> >>
> >> https://github.com/pharo-project/pharo/pull/1127
> >>
> >> This does the first step of breaking the bootstrap process in to
> >> distinct phases and moving all the downloads to the start (e.g.
> >> allowing a test VM to be substituted for the build stage).
> >
> >
> > Nice! thanks!
> >
> >>
> >>
> >> Once this is integrated I can submit a PR that modifies Jenkinsfile to
> >> use the new shell scripts, removing code duplication.
> >
> >
> > Question: Why not in this same PR?
>
> Because I'm not at all familiar with Jenkins, so am a bit nervous
> about changing it.  Smaller changes will be easier to work on if
> something goes wrong. :-)
>
>
Ah, but if you do something wrong the build will fail.

In any case, as soon as you want to dive into changing the JenkinsFile,
send me a private mail. I probably have to give you permissions in Jenkins
(otherwise jenkins ignores changes in the JenkinsFile for security reasons).


> Cheers,
> Alistair
>
>
>
> >> On 16 March 2018 at 14:38, teso...@gmail.com <teso...@gmail.com> wrote:
> >> > Hi,
> >> >  sorry my mistake when updating the scripts. As the bootstrap.sh
> is
> >> > not
> >> > executed during the Jenkins process it has not been validated (locally
> >> > I'm
> >> > not using that script, because is trying to download each time the VM
> >> > and
> >> > the bootstraping process image)
> >>
> >> There are also scripts to snapshot and restore the bootstrap state,
> >> avoiding the need to do the multiple downloads.
> >>
> >> Just to be clear again: This is intended to complement and help with
> >> the goal of moving the bootstrap process to pure Pharo code.  Each of
> >> the shell scripts can eventually be replaced by a call to the
> >> equivalent Pharo code.
> >>
> >
> > :)
> >
> >>
> >>
> >> Thanks!
> >> Alistair
> >>
> >
> >
> >
> > --
> >
> >
> >
> > 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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Guillermo Polito]

If the launcher had a command line interface, I'd use it all the time :)

On Tue, Mar 20, 2018 at 10:15 AM, Marcus Denker 
wrote:

> Hi,
>
>
> I'm really glad PharoLauncher has been promoted to the download page,
> but it seems some people want to push PharoLauncher to *be* Pharo.
> To me this seems a poor strategy.
>
> The README file in the PharoLauncher zip downloads says...
>"Pharo 1.1-2018.01.16 This distribution was built January 16, 2018."
>
> This seems strange to me and highly likely to confuse newcomers.
> Pharo 1.1 more than a few years old.   How can something built in 2018 be
> named "Pharo 1.1" ?
>
> And if PharoLauncher is instead published as Pharo 7, then it seems
> strange to use it to run Pharo 5 images and later Pharo 8 images.
> Why not have the Downloads page just say "The recommended way to manage
> Pharo downloads is with PharoLauncher"
> and allow PharoLauncher to exist as a separate entity.  This would be
> similar similar to those applications where you download
> an initial 500kB installer, which then grabs the other 100MB from the net
> to complete the install.
>
> Also, when maybe one day we can use Pharo as a command line shell, how
> will that relate to PharoLauncher being presented "as" Pharo.
>
>
>
> What is clear is that people use many images anyway. And the more machines
> get bigger, this will happen even more.
>
> So any download can only be “the VM + a Template image”.
> => when you just start “Pharo” it starts the template (read only)
> => drag an image (or double click) -> opens that image.
>
> To make that work for real we would need to have one release per version
> (Pharo6, Pharo7, Pharo8) that you install…
>
> The launcher is a similar scheme that I think could be even better, it
> adds:
>
> - easy find images online
> - manage your images (you do not need to use it, you can just use the UI
> of your OS instead, too).
> - manage VMs in addition.
> - which means that it is just one download that people need to install to
> be able to run all old images, too.
>
> So I think if can be quite nice… it needs some iterations
>
> - simplify the UI so people know what todo when they see it the first time
> - make sure it works everywhere
> - Sign it so installation is easier
> - We need something that the images that end up on disk do not have the
> bit set that make drag-n-drop fail.
> - integrate command line: There should be a menu to write scripts to
> /usr/local/bin to run pharo images easily
> - Longterm: we need 1-file images… a container that has the image itself +
> auxiliary stuff on “disk” but that is one file.
>
> So for me this is a bit like docker: to use docker, you install docker on
> the mac. There is one way, it works.
>
> Marcus
>
>
>
>
>
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] New Files in Pharo - Migration Guide, How To's and examples

[Guillermo Polito]

Yes, it would be good to have those kind of methods. But there are some
other constraints to have into account :)
  - introducing these without introducing duplications is right now
complicated because streams do not share a hierarchy
  - having a common hierarchy is maybe complicated: ZnStreams should for
the moment be backwards compatible with Pharo>4?
  - using traits to avoid duplications would be good, but for now traits
are forbidden from kernel packages
(otherwise we need to add traits in the kernel, + trait support in
the class builder, runtime,... and the image will grow MBs and the build
time will grow too)

About the naming, I'm for

 - #buffered / #bufferedWithBufferSize: size
 - #encoded / #utf8Encoded / #encodedAs: encoding
 - #usingCr / #usingLf / #usingCrLf /
#usingPlatformLineEndingConvention / #usingLineConvention:
aConvention

On Mon, Mar 19, 2018 at 9:53 PM, Esteban A. Maringolo 
wrote:

> 2018-03-19 17:42 GMT-03:00 Nicolas Cellier  gmail.com>:
> > 2018-03-19 21:21 GMT+01:00 Denis Kudriashov :
> >>
> >> 2018-03-19 20:39 GMT+01:00 Esteban A. Maringolo :
> >>>
> >>> 2018-03-19 16:32 GMT-03:00 Denis Kudriashov :
>
> >>> > aStream buffered.
> >>> I'd only change this one, to #beBuffered.
>
> >> But #be sounds like it modifies receiver.
> >> But idea is same as #reversed or #sorted for collections.
> > -1 for beBuffered, it's not about adding states to the stream.
> > As Denis said, it's a transform producing a new stream.
>
>
> I didn't understand it was returning a transformed instance, I
> actually thought it was the opposite, so if that is the case then
> Denis' suggested selectors are fine.
>
> Thanks for the clarification.
>
> Esteban A. Maringolo
>
>


-- 



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

[Pharo-dev] New Files in Pharo - Migration Guide, How To's and examples

[Guillermo Polito]

Hi all,

I've put some minutes summarizing the new APIs provided by the combination
of the new File implementation and the Zn encoders. They all basically
follow the decorator pattern to stack different responsibilities such as
buffering, encoding, line ending convertions.

Please, do not hesitate to give your feedback.

Guille


1. Basic Files

By default files are binary. Not buffered.

(File named: 'name') readStream.
(File named: 'name') readStreamDo: [ :stream | ... ].
(File named: 'name') writeStream.
(File named: 'name') writeStreamDo: [ :stream | ... ].


2. Encoding

To add encoding, wrap a stream with a corresponding
ZnCharacterRead/WriteStream.

"Reading"
utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf8'.
utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: 'utf16'.

"Writing"
utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf8'.
utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: 'utf16'.

3. Buffering

To add buffering, wrap a stream with a corresponding
ZnBufferedRead/WriteStream.

bufferedReadStream := ZnBufferedReadStream on: aStream.
bufferedWriteStream := ZnBufferedWriteStream on: aStream.

It is in general better to buffer the reading on the binary file and apply
the encoding on the buffer in memory than the other way around. See

[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding:
'utf8') upToEnd
]] timeToRun. "0:00:00:09.288"

[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding:
'utf8')) upToEnd
]] timeToRun. "0:00:00:14.189"

4. File System

By default, file system files are buffered and utf8 encoded to keep
backwards compatibility.

'name' asFileReference readStreamDo: [ :bufferedUtf8Stream | ... ].
'name' asFileReference writeStreamDo: [ :bufferedUtf8Stream | ... ].

FileStream also provides access to plain binary files using the
#binaryRead/WriteStream messages. Binary streams are buffered by default
also.

'name' asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | ... ].
'name' asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | ... ].

If you want a file with another encoding (to come in the PR
https://github.com/pharo-project/pharo/pull/1134), you can specify it while
obtaining the stream:

'name' asFileReference
readStreamEncoded: 'utf16'
do: [ :bufferedUtf16Stream | ... ].

'name' asFileReference
writeStreamEncoded: 'utf8'
do: [ :bufferedUtf16Stream | ... ].

5. Line Ending Conventions

If you want to write files following a specific line ending convention, use
the ZnNewLineWriterStream.
This stream decorator will transform any line ending (cr, lf, crlf) into a
defined line ending.
By default it chooses the platform line ending convention.

lineWriter := ZnNewLineWriterStream on: aStream.

If you want to choose another line ending convention you can do:

lineWriter forCr.
lineWriter forLf.
lineWriter forCrLf.
lineWriter forPlatformLineEnding.

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Pharo 7 new file stream encoders

[Guillermo Polito]

Hi,

Yes, I'll provide a PR with that functionality soon. Probably in that
case *ZnCrPortableWriteStream*
is not the right name for that class. Sven, do you think renaming it now
(before it has lots of users) would be acceptable towards backwards
compatibility? Otherwise I would name it ZnNewLineConverterStream...

Keep you updated,
Guille

On Thu, Mar 15, 2018 at 3:11 PM, Sven Van Caekenberghe  wrote:

> I think the idea is to use ZnCrPortableWriteStream for that.
>
> > On 15 Mar 2018, at 14:58, Thierry Goubier 
> wrote:
> >
> > Hi all,
> >
> > how does one create a file stream in Pharo 7 that forces a specific
> > line end convention ? For example, for forcing all end of lines to be
> > Character lf.
> >
> > The old way,
> >
> > fileStream lineEndConvention: #'lf'.
> >
> > does not work anymore.
> >
> > Thanks,
> >
> > Thierry
> >
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Guillermo Polito]

On Mon, Mar 5, 2018 at 4:45 PM, Cyril Ferlicot <cyril.ferli...@gmail.com>
wrote:

>
> On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> But, "one single class" does not mean anything. Because it depends from
>> which branch/commitish you are loading it from...
>>
>> Can you explain better what is the problem because I am not getting it...
>>
>> In any case, independently of where is the burden, I want to veto any new
>> integration that may make future builds non-reproducible. Otherwise this is
>> a source of chaos and dead kittens.
>>
>> The problem is that actually if you have a git project with a stable and
> dev branch you will need:
> - One baseline on the stable branch with determined dependencies versions
> - One baseline on the dev branch with less restricted versions (for
> example 3.x.x)
> Then, when you release a new stable version by merging the development
> branch you need to edit the merge by hand to merge everything except the
> baseline.
> I think this is what Denis wants to avoid.
>
But in general, such merges need to be done only for major and minor
> releases. Not for a patch because you can do a hotfix. You create a new
> branch from master, then merge in in master and development when it's done.
>

I still do not understand... Also I do not understand your usage of the
term "the merge". Can somebody give a **concrete** scenario?

When you release a version, please do not move that version. You should
then create new versions, with new numbers and new code. But never touch
old versions with old numbers and old code. Like that I can download the
same old code using the same old number to get the old version whenever I
want :).

You can try to do it with branches, tags, different repositories, or even
with zipfiles in mails. I don't care. Just don't modify releases and I'm
happy with it.




>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>



-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Guillermo Polito]

Yes and no. I think I kind of get it now from all comments... There are two
problems together, one is how to reproduce the loading of a project (or
getting a working version), and the other is how to use metacello also to
manage the development of the project when the dependencies feel more like
subprojects that may be edited altogether...

On one side there is the reproducibility problem. I understand Stephan's
and Nicolas' points. Using exact versions may block development. However, I
see also that people in general have problems using semantic versioning and
getting working versions done. This morning the image was broken because of
wrong but "not fixed" dependencies... This afternoon Pablo was blocked
executing the bootstrap because iceberg's and the image version did not
match and Metacello was not the best friend when resolving a conflict on a
package that did not exist on one of the two conflicting versions...

So yes, it may block upgrades, but until we have tools that allow us to
cope with the complexity, I prefer to have reproducible versions where I
can reproduce bugs in a reproducible way than an unpredictable version
where I cannot grasp the cause of a problem :/.

On the other side, there is the fact that Metacello baselines are so far
nice to describe release project dependencies, but they are not so nice to
describe subprojects/development dependencies that may get edited along
with the parent project. Kind of what we used to do with #bleedingEdge. I
feel this is a complex problem, that not even SBT or maven that are there
since years are capable of solving nicely... Tode and Iceberg metacello
integration try to solve this problem by "ignoring the dependency and using
the loaded repository" but this may not be successful either...

Now, pushing the complexity to how we manage the Pharo repository is not
the solution either :)

On Mon, Mar 5, 2018 at 5:51 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> The well known problem with fixed configurations is dependencies:
>
> My project A version 1.2.3 depends on project C version 4.3 (semantic
> versioning). I have tested it with 4.3.35, it works well...
> If semantic versioning is correctly used, it should work with any 4.x.y
> where x>=3.
> There is another project B version 2.1.4 which depends on project C
> version 4.4 (still semantic).
>
> Loading latest patch 4.4.20 should work for both A & B.
> And even 4.6.11 which is the latest compatible version in 4.x serie
>
> IMO, the package ConfigurationOfPackageA and ConfigurationOfPackageB
> should NOT specify the exact version of package C, but only the minimal
> compatible version.
> Then, if you want a reproducible image, that is up to the specific
> assembly of package A and package B (let's call it
> ConfigurationOfPackageAandBandC) that you should force the specific C
> version.
>
> Isn't it the problem?
>
> 2018-03-05 17:17 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>:
>
>> 2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <cyril.ferli...@gmail.com>:
>>
>>>
>>> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <
>>> guillermopol...@gmail.com> wrote:
>>>>
>>>>
>>>> I still do not understand... Also I do not understand your usage of the
>>>> term "the merge". Can somebody give a **concrete** scenario?
>>>>
>>>> I'll try
>>> For example the project MaterialDesignLite have two branches that are
>>> always here:
>>> - master
>>> - development
>>>
>> Each commit on master is a stable release and end up with a tag as
>>> "v1.2.2".
>>>
>>
>> I do not agree with this sentence:
>>
>>
>>> Since it's stable, BaselineOfMaterialDesignLite should depend only on
>>> fixed version of the dependencies. For example it should depend on
>>> MaterialDesignColor "v1.0.0".
>>>
>>
>> Maybe I am wrong of course. But this is what I expect from semantic
>> versioning:
>>
>> If I made project which uses some libraries I want to get latest fixes
>> even in my stable version. This is what semantics versioning is about.
>> Minor releases are supposed to be safe for dependent projects.
>> It is of course question of trust to third parties. But if I do not trust
>> them I should fork dependency and use it instead of original one.
>>
>> On the branch dev, we want to get the patches and possibly the minor
>>> versions of the dependencies automatically. In the baseline we then want to
>>> depend on MaterialDesignColor "v1.x.x". Thus, we follow the changes of
>>> MaterialDesignColor while it's not a major release.
&g

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Guillermo Polito]

But, "one single class" does not mean anything. Because it depends from
which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new
integration that may make future builds non-reproducible. Otherwise this is
a source of chaos and dead kittens.

On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov 
wrote:

> 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot :
>
>> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov 
>> wrote:
>> > Hi Pablo.
>> >
>> > Dev branch approach not really works. Because any merge into master will
>> > break master baseline. (notice that baseline is in same repo).
>> > And managing merges by hand all the time is not a solution.
>> >
>> >
>> Hi!
>> If you don't want to manage the merges by hand you can maybe have two
>> bsaelines?
>> BaselineOfCalypso and BaselineOfCalypsoDev?
>>
>
> It should work. But is it right way that everybody should follow?
>
> With configurations it was easy to do in single class.
>
>
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Guillermo Polito]

But can you explain me the scenario? I still don't understand it :(

On Mon, Mar 5, 2018 at 4:51 PM, Denis Kudriashov <dionisi...@gmail.com>
wrote:

> Maybe we should just load Calypso dependencies explicitly.
> In any case they will be used by other projects. Like new Iceberg will use
> Commander. And ClassAnnotation will be in Kernel.
> So we will need to load them in another time than Calypso.
>
> Now we can just put them directly into #loadCalypso method. (there are
> three dependencies)
> It will fix my problem and make Pharo build reproducible.
>
> 2018-03-05 16:38 GMT+01:00 Guillermo Polito <guillermopol...@gmail.com>:
>
>> But, "one single class" does not mean anything. Because it depends from
>> which branch/commitish you are loading it from...
>>
>> Can you explain better what is the problem because I am not getting it...
>>
>> In any case, independently of where is the burden, I want to veto any new
>> integration that may make future builds non-reproducible. Otherwise this is
>> a source of chaos and dead kittens.
>>
>> On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <dionisi...@gmail.com>
>> wrote:
>>
>>> 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferli...@gmail.com>:
>>>
>>>> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisi...@gmail.com>
>>>> wrote:
>>>> > Hi Pablo.
>>>> >
>>>> > Dev branch approach not really works. Because any merge into master
>>>> will
>>>> > break master baseline. (notice that baseline is in same repo).
>>>> > And managing merges by hand all the time is not a solution.
>>>> >
>>>> >
>>>> Hi!
>>>> If you don't want to manage the merges by hand you can maybe have two
>>>> bsaelines?
>>>> BaselineOfCalypso and BaselineOfCalypsoDev?
>>>>
>>>
>>> It should work. But is it right way that everybody should follow?
>>>
>>> With configurations it was easy to do in single class.
>>>
>>>
>>>>
>>>> --
>>>> Cyril Ferlicot
>>>> https://ferlicot.fr
>>>>
>>>>
>>>
>>
>>
>> --
>>
>>
>>
>> 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
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


-- 



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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Is Beacon still planned to be added to P7?

[Guillermo Polito]

On Mon, Apr 23, 2018 at 1:13 PM, Tudor Girba  wrote:

> I hope so. Beacon is ready to be integrated, but I do not know if there is
> enough bandwidth right now due to the Iceberg work.
>

Well, if people issue a pull request I'll gladly review it.

Guille


>
> Doru
>
> > On Apr 23, 2018, at 1:08 PM, Peter Uhnák  wrote:
> >
> > Hi,
> >
> > in several older discussions there was a mention of Beacon logger being
> added to Pharo 7 (by default)... is that still the plan?
> >
> > Thanks,
> > Peter
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>
>


-- 



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

[Pharo-dev] About the infinite debugger

[Guillermo Polito]

Hi all,

during today's sprint we have been working with lots of people on the
infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We
have checked the emails sent in the latest month. Then, together with
Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis
all day. We have been also comparing the debuggers code between pharo 3/4
(where the bug was is present) and pharo 7, but this was not necessarily
straight forward as the code is not the same and there is no easy diff...

ND, we have found that the problem may come from a wrong pragma marker.
Just removing that pragma gives us back the same behaviour as in  Pharo
3/4. :D

https://github.com/pharo-project/pharo/pull/1621

I know that the exception handling/debugging has been modified several
times in the latest years (some refactorings, hiding contexts...), we
unfortunately don't have tests for it, so I'd like some more pair of eyes
on it. Ben, Martin could you take a look?

Thanks all for the fish,
Guille

[Pharo-dev] [Call for testers] Pharo Launcher 1.4.5

[Guillermo Polito]

Hi all,

We have been working these last ~two weeks with Christophe on the stability
of the launcher. We have prepared version 1.4.5, and we would like to have
some feedback.

http://files.pharo.org/pharo-launcher/1.4.5

So, we would really LOVE, if somebody can play with this version and send
us feedback. Specially, if your username in your machine has characters
that encoded take more than 1 byte, we really would like your feedback. We
have tested with japanese characters, and others like î,ü, etc, but the
more the better.

The main focus was on:
 - correct management of encodings (in all platforms)
   - of environment variables
   - of files and paths
   - of commands called through OSProcess
 - better error management in case of edge cases (like when we cannot
determine the version of an image)

Just FYI: the major limitation of the launcher right now (and it was like
that since ever) is that we cannot call external processes with non-ascii
characters in windows. This happens because ProcessWrapper uses the ascii
version of the windows API to create a process.

With what we have learnt this week, we would like to push some of these
fixes to Pharo7 too soon:
 - Correct encoding/decoding of environment variables in linux/osx
 - Ability to access the encoded version of environment variables in
linux/osx to give users control over the encoding they want (or even access
binary data)
 - Correct encoding/decoding of environment variables in windows by using
the correct windows API (current primitiveGetenv in windows uses Ascii
version too...)

In the long term, we also need a solution to enhance or replace
ProcessWrapper using the W (wide) version of the windows API. But that is
far more work...

GC, Guille & Christophe

Re: [Pharo-dev] STON updates/improvements

[Guillermo Polito]

Thanks Sven :)

On Fri, Oct 12, 2018 at 11:38 AM Sven Van Caekenberghe  wrote:

> Now, AFTER the changes, the STON serialisation looks as follows:
>
> {
> #datatype : MimeType [ 'application/json' ],
> #background : Color [ #red ],
> #home : URL [ 'https://pharo.org/experimental' ],
> #workdir : FILE [ '/tmp/pharo/work' ]
> }
>
> which is a huge improvement, IMO.
>

Yes, I've suffered the things you explain before :)


>
> What do you think ? Comments, feedback, remarks ?
> Any other suggestions for other object that could use this treatment ?
>

Question: is it a new mechanism or it is based on the existing mapping
mechanisms? Can we override it/extend it?

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

[Guillermo Polito]

Ok, so can we agree on deprecating the non compatible methods and redirect
the user to the new ones?

To me, the problem with returning a stream is that from a user perspective
you don't know:
 - is the file encoded or binary
 - if it is encoded, in which encoding?
 - if i receive an open file stream, and I want to delete that file I have
to close it, retrieve the file, delete it?
 - IMHO, what is the worst: whose responsibility is it to close the file?

On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak  wrote:

> >  It should return a FileReference, not an open stream. I believe there
> are methods that do that.
>
> There are different APIs for that.
>
> fileOpen*, as the name implies, _opens the file_ and returns the stream.
> (I think this should be the case for fileSave*)
>
> If you want file reference, then you can use e.g.
>
> UIManager default chooseFileMatching: #() label: nil
>
> or `chooseFileMatching:label:`, `chooseFileName:extensions:path:preview:`,
> `chooseFullFileName:extensions:path:preview:`,
> `chooseFullFileNameMatching:label:`.
> Also some methods for selecting directories
> (`chooseDirectory:path:`, chooseDirectory:from:`, ...)
>
> iirc some of them actually return String (file path) instead of
> FileReference. (
> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui-manager-md
> )
>
> So it can be confusing, but the API is already available.
>
> Also iirc UIManager should be preferred over UITheme builder.
>
> Peter
>
> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe  wrote:
>
>>
>>
>> > On 6 Sep 2018, at 21:37, Torsten Bergmann  wrote:
>> >
>> > Hi,
>> >
>> > A question to those who worked on the new streams for Pharo 7:
>> >
>> >
>> > In PHARO 6 I used the following expression to open a file dialog and
>> let the user choose
>> > a binary file:
>> >
>> >s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
>> >
>> > This returned
>> > - either nil (when file dialog was canceled)
>> > - a "MultiByteFileStream" instance when a file was selected
>> >
>> > The MultiByteFileStream instance already had the name of the file (=
>> full path) and I was
>> > able to query it for further use:
>> >
>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
>> > s name inspect
>> >
>> > (for instance to display which file is processed in a window by showing
>> the full path)
>> >
>> >
>> >
>> > Now in PHARO 7 same expression returns an instance of
>> ZnCharacterReadStream (as MultiByteFileStream
>> > is deprecated):
>> >
>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
>> >
>> > and  ZnCharacterReadStream  does not understand #name - and in fact the
>> info about the name is
>> > totally lost/not available. To me this looks missing/broken.
>> >
>> > So what is the recommended way in Pharo 7 to open a file dialog, let
>> the use choose a file
>> > and get a file stream but also the name? IMHO this is either broken or
>> missing...
>> >
>> > Thanks
>> > T.
>>
>> It should return a FileReference, not an open stream. I believe there are
>> methods that do that.
>>
>> But that is an incompatible API change (same selector, different return
>> type). So hard to decide.
>>
>>
>>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

[Guillermo Polito]

Hi all,

I've proposed a PR with some cleanups in this respect

https://github.com/pharo-project/pharo/pull/1941

This is the proposed replacement API that returns file references instead
of streams or file names.

"Get existing file reference"
UIManager default
chooseExistingFileReference: 'title'
extensions: nil
path: FileSystem workingDirectory.

"Get existing file reference filtering by extensions"
UIManager default
chooseExistingFileReference: 'title'
extensions: #('log')
path: FileSystem workingDirectory.

"Get existing file reference to file"
UIManager default
chooseExistingFileReference: 'title'
extensions: nil
path: FileSystem workingDirectory / 'PharoDebug.log'.

"Get file reference for save (not necessarily existing)"
UIManager default
chooseForSaveFileReference: 'title'
extensions: #('log')
path: 'PharoDebuasdg.log'.

On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito 
wrote:

> Ok, so can we agree on deprecating the non compatible methods and redirect
> the user to the new ones?
>
> To me, the problem with returning a stream is that from a user perspective
> you don't know:
>  - is the file encoded or binary
>  - if it is encoded, in which encoding?
>  - if i receive an open file stream, and I want to delete that file I have
> to close it, retrieve the file, delete it?
>  - IMHO, what is the worst: whose responsibility is it to close the file?
>
> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak  wrote:
>
>> >  It should return a FileReference, not an open stream. I believe there
>> are methods that do that.
>>
>> There are different APIs for that.
>>
>> fileOpen*, as the name implies, _opens the file_ and returns the stream.
>> (I think this should be the case for fileSave*)
>>
>> If you want file reference, then you can use e.g.
>>
>> UIManager default chooseFileMatching: #() label: nil
>>
>> or `chooseFileMatching:label:`,
>> `chooseFileName:extensions:path:preview:`,
>> `chooseFullFileName:extensions:path:preview:`,
>> `chooseFullFileNameMatching:label:`.
>> Also some methods for selecting directories
>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...)
>>
>> iirc some of them actually return String (file path) instead of
>> FileReference. (
>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui-manager-md
>> )
>>
>> So it can be confusing, but the API is already available.
>>
>> Also iirc UIManager should be preferred over UITheme builder.
>>
>> Peter
>>
>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe 
>> wrote:
>>
>>>
>>>
>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann  wrote:
>>> >
>>> > Hi,
>>> >
>>> > A question to those who worked on the new streams for Pharo 7:
>>> >
>>> >
>>> > In PHARO 6 I used the following expression to open a file dialog and
>>> let the user choose
>>> > a binary file:
>>> >
>>> >s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
>>> >
>>> > This returned
>>> > - either nil (when file dialog was canceled)
>>> > - a "MultiByteFileStream" instance when a file was selected
>>> >
>>> > The MultiByteFileStream instance already had the name of the file (=
>>> full path) and I was
>>> > able to query it for further use:
>>> >
>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
>>> > s name inspect
>>> >
>>> > (for instance to display which file is processed in a window by
>>> showing the full path)
>>> >
>>> >
>>> >
>>> > Now in PHARO 7 same expression returns an instance of
>>> ZnCharacterReadStream (as MultiByteFileStream
>>> > is deprecated):
>>> >
>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
>>> >
>>> > and  ZnCharacterReadStream  does not understand #name - and in fact
>>> the info about the name is
>>> > totally lost/not available. To me this looks missing/broken.
>>> >
>>> > So what is the recommended way in Pharo 7 to open a file dialog, let
>>> the use choose a file
>>> > and get a file stream but also the name? IMHO this is either broken or
>>> missing...
>>> >
>>> > Thanks
>>> > T.
>>>
>>> It should return a FileReference, not an open stream. I believe there
>>> are methods that do that.
>>>
>>> But that is an incompatible API change (same selector, different return
>>> type). So hard to decide.
>>>
>>>
>>>
>
> --
>
>
>
> 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
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <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
<http://www.cnrs.fr>*


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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

[Guillermo Polito]

Well, there are still variants
 - chooseFile*
 - fileOpen*
 - fileSave*
 - chooseFileName*
 - chooseFullFileName*

I prefered rather to be explicit and to avoid confusion with the old API
(which I deprecated, not removed!)

On Sat, Oct 27, 2018 at 2:42 PM Denis Kudriashov 
wrote:

> What about different names?
>
> UIManager default
> chooseFileIn: aFileReference
> withExtensions: #()
> title: 'title'
>
>  UIManager default
>   chooseFileForSaveIn: aFileReference
>   withExtensions: #()
>   title: 'title'
>
> We can just expect file references because it is what is exposed to users
> in pharo file system. Not neccessery to put it in method name.
>
> пт, 26 окт. 2018 г., 16:32 Guillermo Polito :
>
>> Hi all,
>>
>> I've proposed a PR with some cleanups in this respect
>>
>> https://github.com/pharo-project/pharo/pull/1941
>>
>> This is the proposed replacement API that returns file references instead
>> of streams or file names.
>>
>> "Get existing file reference"
>> UIManager default
>> chooseExistingFileReference: 'title'
>> extensions: nil
>> path: FileSystem workingDirectory.
>>
>> "Get existing file reference filtering by extensions"
>> UIManager default
>> chooseExistingFileReference: 'title'
>> extensions: #('log')
>> path: FileSystem workingDirectory.
>>
>> "Get existing file reference to file"
>> UIManager default
>> chooseExistingFileReference: 'title'
>> extensions: nil
>> path: FileSystem workingDirectory / 'PharoDebug.log'.
>>
>> "Get file reference for save (not necessarily existing)"
>> UIManager default
>> chooseForSaveFileReference: 'title'
>> extensions: #('log')
>> path: 'PharoDebuasdg.log'.
>>
>> On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito <
>> guillermopol...@gmail.com> wrote:
>>
>>> Ok, so can we agree on deprecating the non compatible methods and
>>> redirect the user to the new ones?
>>>
>>> To me, the problem with returning a stream is that from a user
>>> perspective you don't know:
>>>  - is the file encoded or binary
>>>  - if it is encoded, in which encoding?
>>>  - if i receive an open file stream, and I want to delete that file I
>>> have to close it, retrieve the file, delete it?
>>>  - IMHO, what is the worst: whose responsibility is it to close the file?
>>>
>>> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak  wrote:
>>>
>>>> >  It should return a FileReference, not an open stream. I believe
>>>> there are methods that do that.
>>>>
>>>> There are different APIs for that.
>>>>
>>>> fileOpen*, as the name implies, _opens the file_ and returns the
>>>> stream. (I think this should be the case for fileSave*)
>>>>
>>>> If you want file reference, then you can use e.g.
>>>>
>>>> UIManager default chooseFileMatching: #() label: nil
>>>>
>>>> or `chooseFileMatching:label:`,
>>>> `chooseFileName:extensions:path:preview:`,
>>>> `chooseFullFileName:extensions:path:preview:`,
>>>> `chooseFullFileNameMatching:label:`.
>>>> Also some methods for selecting directories
>>>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...)
>>>>
>>>> iirc some of them actually return String (file path) instead of
>>>> FileReference. (
>>>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui-manager-md
>>>> )
>>>>
>>>> So it can be confusing, but the API is already available.
>>>>
>>>> Also iirc UIManager should be preferred over UITheme builder.
>>>>
>>>> Peter
>>>>
>>>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann  wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > A question to those who worked on the new streams for Pharo 7:
>>>>> >
>>>>> >
>>>>> > In PHARO 6 I used the following expression to open a file dialog and
>>>>> let the user choose
>>>>> > a binary file:
>>>>> >
>>>>> >s := UITheme builder fileOpen: 'Choose a file' extensions:
>>>>> #('exe').
>>>>> >
>>>>> &g

[Pharo-dev] Better management of encoding of environment variables

[Guillermo Polito]

Hi all,

following the meeting we had here @Inria headquarters, I'll be backporting
some of the improvements we did in the launcher this last month regarding
the encoding of environment variables.

I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/

We have already studied possible alternatives with Pablo and Christophe and
we have some conclusions and we propose some changes:

API Proposal for OSEnvironment
=


   -
*at: aVariableName *

Gets the String value of an environment variable called `aVariableName`
It is the system reponsibility to manage the encoding.
Rationale: A common denominator for all platforms providing an already
decoded string, because windows does not (compared to *nix systems) provide
a encoded byte representation of the value. Windows has instead its own
wide string representation.

   - *[optionally] rawAt: anEncodedVariableName*

Gets the Byte value of an environment variable called
`anEncodedVariableName`.
It is the user responsibility to encode and decode argument and return
values in the encoding of this preference.
Rationale: Some systems may want to have the liberty to use different
encodings, or even to put binary data in the variables.

   - *[optionally] at: aVariableName encoding: anEncoding*

Gets the value of an environment variable called `aVariableName` using
`anEncoding` to encode/decode arguments and return values.
Rationale: *xes could potentially use different encodings for their
environment variables or even use different encodings in different parts of
their file system.

Other Implementation details
=

   - VM primitives returning paths Strings should be carefuly managed to
   decode them, since they are actually C strings (so byte arrays) disguised
   as ByteStrings.
   - Windows requires calling the right *Wide version of the functions from
   C, plus the correct encoding routine. This could be implemented as an FFI
   call or by modifying the VM to do it properly instead of calling the Ascii
   version