Re: [Pharo-dev] Anyone else teaching programming in Pharo?

[Nicolas Passerini]

We also teach using Pharo here in Argentina.

We also have created a simplified enviroment for beginner programmers
called Ozono (formerly Loop).

I think it would be nice to share our teaching experiences!

I've been teaching introductory programming in Pharo for the last three
semesters and starting my fourth. I was wondering whether anyone else is
doing that. I've put quite a bit of effort into it and would be willing to
share my materials if anyone was interested. For instance, I've created a
few little MicroWorlds for beginners to use (jumping directly into the
browser is too difficult for complete programming novices). One is for
doing turtle graphics. I've gone ahead and shared that for Pharo 2.0. You
can get it in the Configuration Browser under the name EduTech. If you have
some interest, let me know and I'll see what I can do.


I'm :)
I have boys at home and I would love to have some material to pair program
with them.



Cheers,

Jeff

-- 
Jochen "Jeff" Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

Re: [Pharo-dev] Does "browse" make sense?

[Nicolas Passerini]

Agree.
On Nov 7, 2013 5:51 PM, "Luc Fabresse"  wrote:

> Hi Mariano,
>
>  I would prefer to keep browse for everything.
>  If it is a selector, it opens a browser on the only one implementation or
> the implementors windows.
>  If it is a class name, it browses it.
>  etc.
>  my idea would be to have one keybinding and context disambiguation.
>
> Cheers,
>
> Luc
>
>
> #Luc
>
>
> 2013/11/8 Mariano Martinez Peck 
>
>> Hi guys,
>>
>> Currently (it was not like that before), if we search implementors and
>> there is only one implementation, it will open a normal browser with that
>> method. If there are more, it will open the classic implementors windows.
>> "Browse" (for example in the FinderUI), does exactly the same as
>> implementors: if 1 result, browse, if more than 1 result, implementors
>> windows.
>> Sodo we need to keep having "browse" if it has the same behavior as
>> "implementors"?
>> I am missing something?
>>
>> Thanks,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>

[Pharo-dev] A question about AST

[Nicolas Passerini]

I am looking at the AST of a method like this:

someMethod
^ SomeClass new


It was a surprise to me that the note for 'SomeClass' is an RBVariableNode
instead of a RBClassReference. Which is the best way to tell if an
RBVariableNode represents a global reference or an instance variable?

On the other hand, there are no references to RBClassReference, so this
might be a bug?

Thanks,
Nico

Re: [Pharo-dev] A question about AST

[Nicolas Passerini]

Thank you Markus and Thierry, I will try that.




On Thu, Jan 9, 2014 at 5:10 AM, Goubier Thierry wrote:

>
>
> Le 09/01/2014 01:57, Nicolas Passerini a écrit :
>
>  I am looking at the AST of a method like this:
>>
>> someMethod
>> ^ SomeClass new
>>
>>
>> It was a surprise to me that the note for 'SomeClass' is an
>> RBVariableNode instead of a RBClassReference. Which is the best way to
>> tell if an RBVariableNode represents a global reference or an instance
>> variable?
>>
>
> You test the binding associated with the RBVariableNode
>
> self binding isInstance -> instance variable name
>
> self binding isLiteral or: [ self isGlobal]
> Class reference or a global reference (singleton) or a literal
>
> self binding isTemp -> temporary
>
> Thierry
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
>
>

Re: [Pharo-dev] GT-Spotter dive in shortcut

[Nicolas Passerini]

On Sat, Jun 18, 2016 at 4:39 PM, Ben Coman  wrote:

> Yet
> there are probably a small number of shortcuts with cross platform
> conflicts where hardcoded values are still required, and for those it
> even be useful to hardcode
>

I agree to that. For example I miss that normally in my computer (with
Linux) I every program I can do Ctrl+Backspace to delete the word before
the cursor, which in Pharo does not work, and I think it is related to mac
keyboards not having two different keys for backspace/delete as it is
common in other keyboards.

Re: [Pharo-dev] Code-Icons in the "message" browser

[Nicolas Passerini]

That is great!

On Mon, Jun 20, 2016 at 8:16 AM, Marcus Denker 
wrote:

> Hi,
>
> The “message” (should be “method”) browser (which shows methods on
> “senders of” or “implementors of”
> now shows editor-icons:
>
>
> BreakPoints are not yet fully working, but that should be easy to fix.
> (this is in 60 098)
>
> Marcus
>

[Pharo-dev] Multiple strong selections?

[Nicolas Passerini]

Hi, how is the best way to add a "double click" action to a glamour (fast)
table?

I tried usin onChangeOfPort: #strongSelection, but the event is gathered
multiple times... which in my case opens four times the same window. Is
this a bug that I could try to solve or is it that I am using it wrong?

A little portion of code to depict my problem:

browser transmit to: #repositories; andShow: [ :a | a fastTable
...
onChangeOfPort: #strongSelection act: [ :table | IceGlamourSynchronizer
synchronize: table selection ]
].

Thanks,
Nico

Re: [Pharo-dev] Reordering working directory mess

[Nicolas Passerini]

I agree with Javier, it would be much nicer to have only one shared package
cache and, while I understand that there might be people not wanting that,
I don't see why it couldn't be the default behavior. I think that it would
be a reasonable default, don't you?

On Fri, Jun 24, 2016 at 3:54 PM, Javier Pimás 
wrote:

> I don't know for the new directories, but I always thought that it would
> be nice to have package-cache in ~/.pharo or a place shared by all images,
> to avoid redownloading all .MCZs from other projects each time you launch
> pharo from a different directory.
>
> Cheers!
> Pocho
>
> On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano 
> wrote:
>
>> Hi,
>>
>> Since some time I’ve seen growing the amount of files/directories
>> generated when running Pharo. Up to Pharo 2.0, we had just this:
>>
>> Pharo.image
>> Pharo.changes
>> PharoDebug.log
>> pharo-cache
>>
>> now we have:
>>
>> Pharo.image
>> Pharo.changes
>> PharoDebug.log
>> pharo-cache
>> epicea-sessions
>> play-cache
>> play-stash
>>
>> it does not looks like much, but I think this does not looks professional
>> (we take too much from user space). So I proposed (and implemented) a
>> “concentrator” directory:
>>
>> Pharo.image
>> Pharo.changes
>> ./pharo
>> … and everything for “pharo working internally” here
>>
>> then users have again control about what they have along with the image
>> (this allows to some nice strategies too, when we want a version that does
>> not pollutes the file dir).
>>
>> of course, this idea follows other developing spaces, where things are
>> stored in same fashion way… for example in eclipse for java they store all
>> eclipse data under .workspace directory.
>>
>> so, please note that this is NOT user space… regular pharo users will
>> store his files along with the image, for instance filetree repositories…
>> something like:
>>
>> Pharo.image
>> Pharo.changes
>> .pharo/
>> voyage/
>> punqlite/
>> etc.
>>
>> well… I will commit a SLICE with the changes soon (is not a hard change
>> at all).
>>
>> But then:
>>
>> is ./pharo a good name?
>> will this work?
>>
>> Esteban
>>
>
>
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>

Re: [Pharo-dev] Having comments for pragma?

[Nicolas Passerini]

On Mon, Jun 27, 2016 at 10:36 AM, Denis Kudriashov 
wrote:

> Hi.
>
> In Java annotations are first class objects. You can put behaviour and
> state on them. In Smalltalk you can't do this.
>
> That is not quite true, annotations are (kind of) objects but you can not
put behavior in them, just define attributes and optionally default values
for those attributes.

Re: [Pharo-dev] Having comments for pragma?

[Nicolas Passerini]

On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov 
wrote:

>
> 2016-06-27 13:28 GMT+02:00 Nicolas Passerini :
>
>> That is not quite true, annotations are (kind of) objects but you can not
>> put behavior in them, just define attributes and optionally default values
>> for those attributes.
>
>
> Ah, you are right. I remember many restrictions was applied to them which
> always forced me to hate Java :)
>

Yep.

Re: [Pharo-dev] confused about the "image opening session"

[Nicolas Passerini]

Me too :)

On Tue, Jul 5, 2016 at 9:50 PM, stepharo  wrote:

> Hi
>
> I saw that we have a new cool feature that presents changes that would
> have been loaded but not save in the image.
>
> Now I got confused because several times I prompted with this list and I
> do not see how I ended up having it
>
> since I save my image and did not get crash (or idea that I lost changes).
>
> Is it me that do not understand correctly this feature?
>
> At the minimum it would be nice to have a little bit more explanation
> about what is happening.
>
> Because I imagine new guys coming and seeing this list without any further
> explanation could be confused.
>
> Stef
>
>
>

Re: [Pharo-dev] Epicea?

[Nicolas Passerini]

There has been already a discussion about the same topic a few days ago and
I think that there is a consensus on considering it a bug that has to be
solved (look for «confused about the "image opening session"»). Yet I think
there is not even a bug in the issue tracker.

On Fri, Jul 15, 2016 at 1:33 PM, Alexandre Bergel 
wrote:

> Hi!
>
> When I close and open an image, there is an Epicea window, with apparently
> some of my previous change.
> I am not sure what to do with it beside closing it. What is it supposed to
> show me? A small help would great.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] how to update monticello cypress repository downloaded from github?

[Nicolas Passerini]

AFAIK that is the only way

>
> 1. delete github-cache folder in the image folder
> 2. unload all the loaded packages
> 3. execute this script again
>

At least if you have a metadata less github repository, is that the case?
But that was the conclusion to which we arrived with Dale a few weeks ago
and he's changing stuff, so maybe in the latest version it is already
solved.

Re: [Pharo-dev] how to update monticello cypress repository downloaded from github?

[Nicolas Passerini]

It happens the same to me.

On Sun, Jul 17, 2016 at 4:37 PM, Peter Uhnák  wrote:

>   Metacello new
>> baseline: 'FileDialog';
>> repository: 'github://peteruhnak/file-dialog/repository';
>> get;
>> load.
>
>
> Using #get indeed downloads a fresh copy, however the code in Pharo is
> _not_ reloaded.
> Is this a bug? Or do I need to do yet something more to reload that too?
>
> Peter
>

Re: [Pharo-dev] [Pharo-users] [ANN] file dialog replacement experiment

[Nicolas Passerini]

On Sun, Jul 17, 2016 at 4:25 PM, Peter Uhnák  wrote:

> I wonder… does Pharo support such workflow that it would pull the code
> from github? I.e. the development would continue on GitHub and Pharo would
> just pull the updates.
>
>
It is not ready for production, but I am working on that.

Re: [Pharo-dev] git feature request

[Nicolas Passerini]

In Iceberg you currently can:

1) Download a project using metacello github:// protocol
2) Use Iceberg to make it "writable" (i.e. transform it to an Iceberg
repository, pointing to the same remote repository), this is just one step.
3) Commit and push using the new repo, etc.

What it is not done yet is the integration with github (or whatever)
fork/pr capabilities, it is in the roadmap but not just now because those
are not standard git operations, so it will involve communicating directly
to the github rest api (and others, we will not be attached to git nor
github).

So you should add two extra steps which are forking and pull requesting
from outside Pharo (or requesting access to the respository to commit right
there).

This should be a normal flow for contributing to a tool you are using,
right now is partially supported to be done from a git(hub) repository, I
intend to extend it to be done also from tools installed from smalltalkhub,
etc. Should be the same thing.


About the discussion between commits and PRs... I've seen both models
working right, I think that both have their advantages and I would like to
build tools to support both schemas. Personally, I prefer to give people
the possibility to commit, but even so I am used to work with PRs, because
it really helps the code review. Yes you can have your own branch, and I
can see the changes introduced by any commit, but usually is a PR that
moves people towards looking to the code, and I think that it is a nice
model that works well in practice.
In other projects, you have to fork, commit there, then PR, if two people
want to work together in an issue is not obvious how to do it... it adds
more bureaucracy, it might be necessary for a large project like Pharo, but
normally I prefer to avoid it.

On Fri, Jul 22, 2016 at 4:42 PM, Esteban Lorenzano 
wrote:

> Hi,
>
> This flow is taken into account in the new iceberg... I cannot go into
> details because I'm still on holidays (and no internet) until Monday... And
> Nico is also taking some days.
> Anyway, yes... We had this flow in mind (and others, of course) when we
> worked in the use cases we want to support.
>
> Cheers,
> Esteban
>
> > On 22 Jul 2016, at 15:14, Ben Coman  wrote:
> >
> >> On Fri, Jul 22, 2016 at 3:11 PM, Peter Uhnak  wrote:
> >>> On Fri, Jul 22, 2016 at 11:55:46AM +0800, Ben Coman wrote:
> >>> I'm not sure what the roadmap is for git integration, but just a use
> case
> >>> that occurs to me while I work "a bit with git" for the first time from
> >>> Pharo.
> >>>
> >>> I install a project via a Baseline from git and makes a small
> improvement.
> >>> What is the easiest way to contribute back?  I can't push back to the
> >>> personal repo I downloaded from, so the easiest thing would be a single
> >>> menu item to:
> >>> 1. Fork original repository
> >>> 2. Push current in-Image code to a new branch in that fork.
> >>>
> >>> Maybe even...
> >>> 3. Issue a pull request to the original repository.
> >>
> >> This is indeed the idiomatic way to contribute on GitHub.
> >>
> >> 1. fork
> >> 2. install _your fork_ with gitfiletree/remote git repo
> >> 3. make an improvement (you can use master branch, since it's your
> repo, but that's a detail)
> >> 4. issue a pull request
> >
> > That is how you do it if you *already* know you want to be contribute
> > to an application or package. But what if I was just planning to *use*
> > an application or package, only later I ended up tracing down a bug to
> > that application and fixed it.  What is the *easiest* for me to push
> > to my personal github account from where I make the Pull Request.
> > Something like this [1] from within Pharo (disclaimer, I've not
> > performed these action before, I had to hunt a bit to find it as an
> > example)...
> >
> > [1] https://gist.github.com/jagregory/710671
> >
> >> Maybe IceBerg (https://github.com/npasserini/iceberg) could have some
> nice interface for this eventually.
> >
> > Thanks for the link.  This will be interesting to watch.
> >
> > cheers -ben
> >
>
>

Re: [Pharo-dev] A taste of bootstrap

[Nicolas Passerini]

Hey! This is great news!
I am anxious to work with you for integrating git and bootstrap.

On Fri, Jul 22, 2016 at 8:57 PM, Pavel Krivanek 
wrote:

>
>
> 2016-07-22 16:42 GMT+02:00 Mariano Martinez Peck :
>
>>
>>
>> On Fri, Jul 22, 2016 at 11:38 AM, Pavel Krivanek <
>> pavel.kriva...@gmail.com> wrote:
>>
>>>
>>>
>>> 2016-07-22 16:24 GMT+02:00 Guillermo Polito :
>>>


 On Fri, Jul 22, 2016 at 4:12 PM, Mariano Martinez Peck <
 marianop...@gmail.com> wrote:

> Hi Pavel,
>
> Congrats for your hard work!  You know me well, so don't take my next
> question as negative.
> You have been working in minimal images since years. Guille has also
> done quite some work, and many other people as well.
> My question is have we decreased the effort to keep it working as
> Pharo evolves? Previously, there were always problems with the
> dependencies: a single commit to Pharo would add or break a dependency and
> so we cannot bootstrap anymore. In other words...there was still a lot of
> human action needed to check and fix dependencies. Is this still the case?
>

 Complex questions requires complex answers :). It's not a yes, neither
 a no.

 - We have automatized the dependency analyses
 - We added Lint rules that ensure that no new dependencies are added to
 the kernel because of an integration
 - We will be adding soon enough more tools to automatically validate
 and ensure the health of the bootstrap, and to detect possible problems.

 Buuut,

 - Lint rules can (and sometimes are) ignored
 - Not everybody is aware of how to maintain dependencies or even they
 do not know they should care about it

 So the human factor is still of big importance (and risk), and
 educating people is harder than machines ^^

>>>
>>> I must say that current need of human work required for proper reloading
>>> of all Pharo packages is too high. It can be better only as soon as the
>>> bootstrapping will be part of our development/release process.
>>>
>>
>> Exactly!!! Totally agree. And..what are the plans of getting the
>> bootstrapping as part of the development and release process? I am sure it
>> is on the roadmap.
>>
>
> Simply as soon as possible :-) I will work on preparation of it in the
> next weeks.
>
> -- Pavel
>
>
>>
>>
>>>
>>> On the other hand, dependency problems are now quite rare and are very
>>> rare in the kernel packages.
>>>
>>>
>> That's very good to hear!
>>
>>
>>> -- Pavel
>>>
>>>


> Cheers,
>
>
>
> On Fri, Jul 22, 2016 at 10:37 AM, Pavel Krivanek <
> pavel.kriva...@gmail.com> wrote:
>
>>
>>
>> 2016-07-22 15:22 GMT+02:00 Ben Coman :
>>
>>> On Fri, Jul 22, 2016 at 9:12 PM, Pavel Krivanek
>>>  wrote:
>>> > Hi,
>>> >
>>> > as you maybe know, we are working on Pharo image bootstrap - the
>>> process
>>> > that can generate an image from source codes and initialize it
>>> correctly.
>>> > Because of practical reasons we do not bootstrap the standard
>>> image at once
>>> > but we are trying to bootstrap a small headless kernel image and
>>> then load
>>> > the rest of the system into it.
>>> >
>>> > The good news is that we are successful in our effor. We are
>>> already able to
>>> > produce well usable images as you can test here:
>>>
>>> Great to hear of your continuing progress.
>>>
>>> >
>>> > https://goo.gl/fn1VbP
>>> >
>>> > From the Pharo/Squeak point of view this image is very special
>>> because it
>>> > doesn't contain any object inherited from 70's. Pharo lost its
>>> umbilical
>>> > cord.
>>>
>>> Does this mean you are starting with a zero byte file and adding nil,
>>> true, false, etc...?
>>> Or what is the size of the image you start with?
>>>
>>
>> No, we are not generating image file directly. We use special VM
>> simulator and then save its object memory.
>> Our bootstrapped image has about 5MB now (in Spur format).
>>
>>
>>>
>>> cheers -ben
>>>
>>> >
>>> > Notice that the initial display width is too narrow and and we
>>> still need a
>>> > lot of work on the building process, but In the next weeks and
>>> months it
>>> > will change a lot the Pharo development - especially as soon as it
>>> will be
>>> > combined with Git support.
>>> >
>>> > Cheers,
>>> > -- Pavel
>>> >
>>> >
>>>
>>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>


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

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

[Nicolas Passerini]

Hi,

I think that whatever default behavior and shortcuts you decide, it would
be nice to be able to configure it. So, if someone does not feel
comfortable with the default, he has a simple way to change it and
configure in a way that gets better along with his way of using Pharo.
Don't you think?

On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Nicolai,
>
> It is good to encourage this, but it is a reality that it is a lot of work
> to do a good job of complaining and criticizing and personally I have a
> talk at ESUG that needs work, so I won't have the luxury of detailed
> criticisms much longer :) and I'm sure that this is an issue for others as
> well ...
>
> But if all of us make a point to "complain" when we hit an annoying issue
> AND have the time to complain, then eventually you guys will get the kind
> of feedback that you need to make better decisions, compromises and
> preferences...
>
> Dale
> On 8/7/16 7:33 AM, Nicolai Hess wrote:
>
>
>
> 2016-08-07 16:10 GMT+02:00 Tudor Girba :
>
>> Hi Dale,
>>
>> Thanks for your thoughts. And thanks for giving these new quirks time to
>> settle :).
>>
>> Actually, I am looking for what is annoying and I specifically interested
>> in the reasons why it is annoying. Please feel free to report the bits that
>> annoy you.
>>
>
> +1
> Pharo is not an environment where we should live with annoyance.
> I would encourage people to report anything that disturbs the daily work
> and discuss what behavior or gui layout is expected  and what could be done
> better. I am sure we can not find a way to satisfy all, we have different
> workflows and different expectations, but it is better to talk about,
> instead of just live with it.
>
>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> > On Aug 7, 2016, at 3:57 PM, Dale Henrichs <
>> dale.henri...@gemtalksystems.com> wrote:
>> >
>> >
>> >
>> > On 8/7/16 6:16 AM, Tudor Girba wrote:
>> >> Hi Stef,
>> >>
>> >>
>> >> That is why we made the default printing not affect the text editor,
>> and this feature is around since almost 2 years and, except of you, there
>> was no other complain.
>> >>
>> > I believe that this is a logical fallacy ... many developers are too
>> busy actually trying to do work with these tools and don't have time or
>> inclination to get involved in an argument :)
>> >
>> > There are a number of odd, awkward, hidden, "old way does not work
>> anymore" things that I am running into as I have just been using Pharo5.0
>> for a couple of months ... I understand that when the GUI changes one must
>> give it a little bit of time to "settle in" and see if my annoyance is due
>> to the fact that things have changed or if the "old way was better" ...
>> >
>> > I don't like the funky popup prints either --- they often obscure the
>> underlying text and when I do something to see the underlying text I lose
>> the printout --- occasionally it is useful as a preview but that's not the
>> only use case .. often the result is what I want ...
>> >
>> > But I am trying to do real work and I really don't have the time to get
>> into an embroiled argument over things so far I feel less productive (the
>> debugger buttons are a real annoyance) but perhaps with practice and
>> patience I will eventually see the light of putting heavily used menu items
>> off in a corner ...
>> >
>> > BTW, I've basically given up on using browser shortcuts altogether ...
>> I am assuming that the shortcuts will be changing yet again in 6.0 so I'm
>> not going to try to memorize shortcuts that will be changing every 6 months
>> :)
>> >
>> > While I am complaining --- is there a way to be able to change the
>> width of the inspector panes in a debugger? I'm almost never able to see
>> what I want to see in the inspector panes because they aren't wide enough
>> and unlike every other pane in the universe, I can't grab the pane and
>> change its width ... I'm sure you have a good argument for why it can't be
>> moved --- but that doesn't stop me from being annoyed ...
>> >
>> > Optimized code is often uglier than the cleanly crafted beautiful code
>> that runs too damn slow ...
>> >
>> > I could go on and on, but I'm sure you've good reasons for all of the
>> the things that you have changed and this isn't the only GUI in the world
>> that is annoying to use :)
>> >
>> > Remember that I am still in the phase of "give it a little bit of time
>> to "settle in" and see if my annoyance is due to the fact that things have
>> changed or if the "old way was better" ... "
>> >
>> > Dale
>> >
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>>
>>
>>
>
>

Re: [Pharo-dev] Iceberg in general

[Nicolas Passerini]

Hi Norbert,

Up to date, Iceberg has only been developed/used/tested on Pharo 6.0,
please look at the prerrequisites in https://github.com/npasserini/iceberg.
I can not tell if it would work on Pharo 5.0.

Either way, if you could submit a bug report I will happily pay a look at
it.

On Tue, Aug 9, 2016 at 1:55 PM, Peter Uhnák  wrote:

>
>
> On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl  wrote:
>
>> I'm using pharo5 and I wonder we is this version marked as stable
>
>
> The readme states:
>
> "This is still a prototype and is not yet ready for production, but you
> are invited to try it and provide feedback. "
>
> Note however that I've successfully started using it for smaller
> project(s) that are hosted on GitHub. Of course there's a lot of issues
> https://github.com/npasserini/iceberg/issues , but it can be forced to
> work if you are willing to live on the edge. :)
>
> Regarding your error, it would be best to submit a bug report.
>
> Peter
>

Re: [Pharo-dev] Iceberg in general

[Nicolas Passerini]

Issue #111 <https://github.com/npasserini/iceberg/issues/111> is fixed and
included in github://npasserini/iceberg:0.2.1
(or github://npasserini/iceberg:stable).

Thanks for reporting it.

On Tue, Aug 9, 2016 at 2:34 PM, Peter Uhnák  wrote:

> > I can not tell if it would work on Pharo 5.0.
>
> I using IceBerg on Pharo 5.
>
> On Tue, Aug 9, 2016 at 2:10 PM, Norbert Hartl  wrote:
>
>> I've checked again on pharo6 and get the same error.
>>
>> - downloaded pharo6
>>
>> - Metacello new
>>  baseline: 'Iceberg';
>>  repository: 'github://npasserini/iceberg:stable';
>>  load.
>>
>> - openend UI via tools/Iceberg
>>
>> - click "Clone new repository"
>>
>> Same error as in pharo5. Cannot parse URL
>>
>> I've created an issue
>>
>> Norbert
>>
>> Am 09.08.2016 um 14:00 schrieb Nicolas Passerini :
>>
>> Hi Norbert,
>>
>> Up to date, Iceberg has only been developed/used/tested on Pharo 6.0,
>> please look at the prerrequisites in https://github.com/npasserini/
>> iceberg. I can not tell if it would work on Pharo 5.0.
>>
>> Either way, if you could submit a bug report I will happily pay a look at
>> it.
>>
>> On Tue, Aug 9, 2016 at 1:55 PM, Peter Uhnák  wrote:
>>
>>>
>>>
>>> On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl 
>>> wrote:
>>>
>>>> I'm using pharo5 and I wonder we is this version marked as stable
>>>
>>>
>>> The readme states:
>>>
>>> "This is still a prototype and is not yet ready for production, but you
>>> are invited to try it and provide feedback. "
>>>
>>> Note however that I've successfully started using it for smaller
>>> project(s) that are hosted on GitHub. Of course there's a lot of issues
>>> https://github.com/npasserini/iceberg/issues , but it can be forced to
>>> work if you are willing to live on the edge. :)
>>>
>>> Regarding your error, it would be best to submit a bug report.
>>>
>>> Peter
>>>
>>
>>
>>
>

[Pharo-dev] Character encoding and line ending in OSSubprocess

[Nicolas Passerini]

Hi, I am using OSSubprocess for throwing git commands (using Iceberg with
the GitFileTree backend), and I find that  characters (for example spanish
áéíóúñ) and line endings are not correctly encoded/decoded.

Does someone have the same problem?
Are we doing something wrong?

I am working on linux, and latest Pharo 6.

With Guille Polito we tried some time ago a little fix that seemed to work
but maybe it needs more testing, and before investing more time on it I
thought that it would be a good idea to have more opinions on the topic.

Re: [Pharo-dev] Character encoding and line ending in OSSubprocess

[Nicolas Passerini]

On Mon, Aug 22, 2016 at 3:31 PM, Thierry Goubier 
wrote:

> does this happens when you are using one of the GitFileTree generated
> command or when you use directly the command line api (runGitCommand and
> friends)?
>

I think that it happens in both cases, the most obvious is that it fails to
bring my github name, which happens to have an "á".
But I will check your idea, to be sure.


> Does this happens with OSProcess as well?
>
> I am not sure about this, can I use gitfiletree with OSProcess, how can I
test it?

Re: [Pharo-dev] Character encoding and line ending in OSSubprocess

[Nicolas Passerini]

On Mon, Aug 22, 2016 at 4:29 PM, Thierry Goubier 
wrote:

>
>
> 2016-08-22 16:08 GMT+02:00 Nicolas Passerini :
>
>>
>> On Mon, Aug 22, 2016 at 3:31 PM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> does this happens when you are using one of the GitFileTree generated
>>> command or when you use directly the command line api (runGitCommand and
>>> friends)?
>>>
>>
>> I think that it happens in both cases, the most obvious is that it fails
>> to bring my github name, which happens to have an "á".
>>
>
> Hum, I may be missing a string convert on some arguments of the git clone
> command...
>
>
Ok, if that's the way to go I can try to fix it and send you a pull
request.
I was thinking if it can not be resolved by OSSubprocess itself.


> But I will check your idea, to be sure.
>>
>>
>>> Does this happens with OSProcess as well?
>>>
>>> I am not sure about this, can I use gitfiletree with OSProcess, how can
>> I test it?
>>
>>
> Just load OSProcess before loading GitFileTree, it should notice it and
> avoid loading OSSubprocess.
>
>
> Ok, I will try that, thankyou.

Re: [Pharo-dev] About PythonDocTest for Pharo

[Nicolas Passerini]

On Thu, Aug 18, 2016 at 11:28 PM, Denis Kudriashov 
wrote:

>
> 2016-08-18 13:32 GMT+02:00 stepharo :
>
>> withExtension: aString
>>
>> "Returns a new file reference with a different file extension"
>
>
> Does this comment is really needed?
> I only see extra word "different". And rest is same as method name. IMHO
> we should rename method to "withDifferentExtension:" and remove comment.
>

I think that it is interesting that the comment also says that it will
return a FileReference... of course there are other ways to know that, but
it is nice that the comment avoids the research/guessing.
More over, which is not obvious is that it will *change* the extension,
because the "with" prefix could mislead you to think that it will *add* the
extension. Maybe we can come up with a better name (withDifferentExtension:
works better, I agree) or we need the comment to be explicit about it.

Re: [Pharo-dev] Iceberg: success and fail

[Nicolas Passerini]

Sorry, I didn't understand how to reproduce the problem. I understand you
tried to save a package to the Iceberg repository, is that right?
How did you create your local repository? Did you already have a git
repository in the same directory?

(Yes, an error in the issue tracker will be appreciated, thanks!)

On Fri, Aug 26, 2016 at 7:25 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> Hi all,
>
> I was able to do my first commit with Iceberg on github !
> So this is great.
>
> I'm trying now to move an existing project on SmalltalkHub on github.
> I made a local repository and when I try a package in this repo, I
> have the following error.
> I can put the error report on Iceberg issue tracker if needed.
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>

Re: [Pharo-dev] iceberg: create repository?

[Nicolas Passerini]

Right, the names are inconsistent. Thank you for noticing it.

On Fri, Aug 26, 2016 at 9:48 PM, Alexandre Bergel 
wrote:

> Hi!
>
> I think the following window can be improved:
>
>
>
> Do I want to import or create a repository? I think the button title has
> to be changed…
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

Re: [Pharo-dev] How to load with Iceberg?

[Nicolas Passerini]

Hi Alex, the history is just work in progress, you should be able to load
any version from there, yes.

Yet I consider that a somehow advanced function, it will allow to load any
commit into your image.
So, wouldn't you prefer to load a branch or tag?

(For branches it is already supported, for tags I have to do it, but I
could try to have it soon if that is what you need.)

On Fri, Aug 26, 2016 at 9:39 PM, Alexandre Bergel 
wrote:

> Hi!
>
> How can I load a version using Iceberg?
>
> I managed to open the history of a repo, but I cannot load a version.
> By the way, I see a commit with the comment ‘gitfiletree repository
> properties’. What is that? I have never made this commit.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] Iceberg: success and fail

[Nicolas Passerini]

Thank you Serge, I will pay a look at it.

On Fri, Aug 26, 2016 at 11:43 PM,  wrote:

>
>
> Envoyé de mon iPhone
>
> Le 26 août 2016 à 23:34, Nicolas Passerini  a
> écrit :
>
> Sorry, I didn't understand how to reproduce the problem. I understand you
> tried to save a package to the Iceberg repository, is that right?
> How did you create your local repository? Did you already have a git
> repository in the same directory?
>
>
> This was an existing git repo on github but without any Pharo packages. I
> load my project from Smalltalk and try to add the packages with the Iceberg
> tool.
>
>
> (Yes, an error in the issue tracker will be appreciated, thanks!)
>
>
> I will do it later.
>
>
> On Fri, Aug 26, 2016 at 7:25 PM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> Hi all,
>>
>> I was able to do my first commit with Iceberg on github !
>> So this is great.
>>
>> I'm trying now to move an existing project on SmalltalkHub on github.
>> I made a local repository and when I try a package in this repo, I
>> have the following error.
>> I can put the error report on Iceberg issue tracker if needed.
>>
>> --
>> Serge Stinckwich
>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>>
>
>

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Nicolas Passerini]

Well, I am not sure if this has to do with Iceberg itself, because Iceberg
does nothing with dependencies.

But I am not sure that a ConfigurationOfXXX really has information of only
one package. Normally you will have only one configuration for each
project, am I wrong?
Then the configuration specifies (among other stuff) dependencies between
the parts (packages) of your project... I think this is right.
If you depend in another project, then you should not depend in specific
packages but in another configuration.

The problem here is that we are (at least Iceberg is) assuming a
correlation between project and repository, because in fact Iceberg handles
repositories. If a project would be spawn in several repositories, at least
now Iceberg can't do anything about it, it will treat them as independent
"projects". I am not sure about changing this logic in the near future, and
also we should think if that is not a Cargo/Metacello feature.

On Sat, Aug 27, 2016 at 10:35 AM, Peter Uhnak  wrote:

> Hi,
>
> one thing that I wanted to ask about IceBerg --- during the IceBerg talk
> Nico mentioned that we need to think in terms of projects.
>
> Now I understand that perspective, because that's how git behaves and
> that's how _I_ think,
>
> however at the same time, there is a strong push for focusing on
> packages... having each package describing it's dependencies, etc.
>
> So my question is, how do those two views interact with each other?
> Because I feel like they are going against each other.
>
> Peter
>
>

Re: [Pharo-dev] wish for Iceberg

[Nicolas Passerini]

On Mon, Aug 29, 2016 at 10:11 PM, Alexandre Bergel 
wrote:

> Hi!
>
> It would be great to be able to save the repositories on the disk,
> somewhere. And to not have to type them all the time.
>

You're right, this is already in my backlog.
This is good feedback because now I can prioritize it better.


>
> Also, if I install a git repository, I would like to be able to commit /
> push after modifying it.
>
> This is a bit more difficult, because (if I understand what you mean) you
have a git repo that you probably downloaded with Gofer or Metacello. So
Iceberg can not use it for committing/pushing (because it is not a real git
repo). I have been talking with Dale and Cristophe, so that Metacello and
Cargo will use Iceberg for downloading git repos... so you will not have
that problem any more. Still, it might be a while until those changes are
integrated in Metacello (I think).
So in the meantime I can build a tool to convert a git metacello-downloaded
MCRepository to an Iceberg repository in a simple way. Do you think it
would be useful?

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Nicolas Passerini]

>
> >>> With the Iceberg tool, you can load or unload packages.
> >>> How it will works if the dependencies are not loaded before ?
> >>
> >> AFAIK, this is not iceberg concern… this is a work for metacello (or
> cargo).
> >
> > Yes you are right, but when you load a package from Iceberg, the
> > dependencies should be loaded at the same time I guess.
>
> No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello
> for dependency management. A proper package manager (Cargo?) should
> coordinate artifacts of both.
>
>
> I think I agree with both Estebans, I hope that Metacello/Cargo will use
Iceberg to load packages, but it should be their responsibility to decide
which packages and versions to load.

Re: [Pharo-dev] about clas deprecation

[Nicolas Passerini]

Sounds good!

On Fri, Sep 2, 2016 at 8:11 AM, stepharo  wrote:

> Hi
>
> Using the idea we got with Peter Uhnak, we know implemented using
> transformation library of gustavo two new transformation:
>
> - deprecate class
>
> just compile a new method raising a warning:
>
> + a class method deprecated returning true (this could then
> improve to rename the method new if it already exist).
>
> - rename and deprecate:
>
> the idea here is that we want to make sure that we can rename a
> class and that external users get a chance to load and execute their code.
> For that if we have a class A we rename it into ANewName and create an
> empty subclass A that we deprecate.
>
> Let us know what you think.
>
> Stef and Gustavo
>
>
>

Re: [Pharo-dev] about package naming

[Nicolas Passerini]

Yes Icebergs uses RPackages, I have RPackages and Tags and I do not
remember having problems.

On Mon, Sep 5, 2016 at 9:50 AM, Guille Polito 
wrote:

> As far as I understand, Iceberg uses RPackages. And RPackages do not
> necessarily follow MC conventions.
>
>
>  Original Message 
>
> 
> Wow, I do not know where that email came from O_o.
> It looks a spammish email. Maybe it came from my phone?
>
> If it happens again, please tell me so I can take action.
> 
>
> Now in-topic: I agree with having conventions and with the tests one
> particularly. But as you say, we should also think what are the benefits in
> terms of tooling so people do not feel forced to use it: they feel
> attracted to use it :).
>
>
>  Original Message 
>
> No guillermo. This is really annoying.
>
> With long package list like Collections* then you do not see well the
> tests.
>
> So we should check the bug like that we are free.
>
> Je suis pas de place  que no necesita activar gustamucho la 🎶 que ya el
> otro lado
>
> Le 4 sept. 2016 10:18, "stepharo"  a écrit :
>
>> Hi guys
>>
>> Sorry to be that dull and stupid but I do not get why (beside following
>> the seaside convention - and I do not understand it either) why the test
>> package for FileSystem-Core is named FileSystem-Tests-Core
>>
>> and not just
>>
>> FileSystem-Core-Tests
>>
>> like that we could have
>>
>> FileSystem-Core-Help
>>
>> FileSystem-Core-Examples
>>
>> And when we are looking for FileSystem-Core we can see automatically
>> FileSystem-Core-Tests
>>
>> Now we cannot.
>>
>> Stef
>>
>>
>>
>
>
>

Re: [Pharo-dev] Iceberg Question

[Nicolas Passerini]

Yes, it can be cryptic. It would be nice that we discuss which is the best
vocabulary to use so that it is clear both for people with or without a
strong git background.

Iceberg does not have a "pull" operation, as it is intended from the git
command line. Instead you have fetch and merge separately (remember: git
pull = git fetch + git merge).
In this way, you first download all new versions from the remote
repository, you can browse them, and then you can decide to:
a. Merge the remote changes into your local branch
b. Load any version, without merging (which in git is called "detached
head").

I thought this way (more similar to current Pharo tools than to the git
command line) is better for our needs, but I could be wrong. Or we could
have both.

Also, one tricky thing here is that "incomming changes" could be two
different things:
- changes in the remote repository but not merged into your current branch.
- changes in your current branch but not loaded into the image

I am not sure how should be the best way to show that information.

On Sun, Sep 4, 2016 at 8:56 PM, Alexandre Bergel 
wrote:

> Hi!
>
> I have a question regarding the window:
>
>
> Why if I want to retrieve the new versions, I need to press the button
> “Fetch new versions”. I think I should do a pull ? But instead, i can do a
> load or a merge. A bit cryptic…
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

Re: [Pharo-dev] Message browser strange new behavior

[Nicolas Passerini]

I agree, it is sometimes difficult to find a class in the message browser
because of the inheritance organization.
I think that most often I do not want that, but also it might be useful in
other circunstances, so maybe the best would be to have both possibilities
and make is easy to change from one to the other.

On Sun, Sep 4, 2016 at 10:10 AM, stepharo  wrote:

> Hi denis
>
> I looked at senders of iconNamed:
>
> and when I see a Smalltalk ui icons iconNamed: I change it into self
> iconNamed: when I can.
>
> May be I was also changing the superclass to be Model and this would be
> the problem.
>
> It would be nice to have the possibility to get the list displayed not
> following inheritance but
>
> just based on alphabetic name of classes.
>
>
> Stef
>
> Le 4/9/16 à 10:05, Denis Kudriashov a écrit :
>
> I can't reproduce (or I not see it)
> Could you explain more?
>
> 2016-09-03 22:11 GMT+02:00 stepharo :
>
>> Hi
>>
>>
>> Often I look at senders and I modify them directly in the message browser
>> and I do not one by one.
>>
>> Now when I recompile a method I get a new one and I lose the next one.
>>
>> Am I the only one to have this behavior. It is highly disrputing.
>>
>> Stef
>>
>>
>>
>
>

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

[Nicolas Passerini]

I think it would be nice to be able to run tests in background.

What would be the problem? A test case that fails because you were doing
something at the same time? I think it is not so serious, it is up to you
to know which tests did you run and do nothing that would conflict with the
test run. Now you can't do anything.

On Fri, Sep 16, 2016 at 11:30 AM, Denis Kudriashov 
wrote:

>
> 2016-09-15 18:46 GMT+02:00 Marcus Denker :
>
>> > would itself seem to a big impediment.   It would be good if "Author"
>> > was dependent on the context of the call chain.This would seem a
>> > requirement for one day having two people working in the one Image (is
>> > this a possible use case where someone is using a remote debugger
>> > while another person is using the standard UI?)
>> >
>> Could it be part of Denis new ExecutionEnvironment concept?
>
>
> It could be used here but I think such problem is more complex. Most parts
> of system is not implemented with concurrency in mind.
>

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

[Nicolas Passerini]

On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker 
wrote:

>
> > On 16 Sep 2016, at 12:43, Nicolas Passerini 
> wrote:
> >
> > I think it would be nice to be able to run tests in background.
> >
>
> The easiest is to start multiple images… this way they can destroy
> whatever without impacting you.
> I think Guille has something in preparation…
>
> The nice aspect of this is that it runs really in parallel.
>

 That is a nice feature, but if I am working on something and I make
changes I would like to run the tests right where I am working.

Re: [Pharo-dev] Author / TestRunner interaction in fresh image

[Nicolas Passerini]

Yes, that would be great.

I just wander if the increased complexity pays off... normally if I am
running my tests I do not have lots of tasks in mind, I will decide what to
do next after seeing that my tests are green. Maybe I just want to browse
some code, I do not need super fancy features.



On Fri, Sep 16, 2016 at 4:13 PM, Guille Polito 
wrote:

>
>
>  Original Message 
>
>
>
> On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker 
> wrote:
>
>>
>> > On 16 Sep 2016, at 12:43, Nicolas Passerini 
>> wrote:
>> >
>> > I think it would be nice to be able to run tests in background.
>> >
>>
>> The easiest is to start multiple images… this way they can destroy
>> whatever without impacting you.
>> I think Guille has something in preparation…
>>
>> The nice aspect of this is that it runs really in parallel.
>>
>
>  That is a nice feature, but if I am working on something and I make
> changes I would like to run the tests right where I am working.
>
> That is a cosmethic thing.
>
> Imagine you could run the tests on a copy of the image you were
> developing. If there is an error, your development image gets notified, and
> so you can then debug the error on your local environment.
>
>

Re: [Pharo-dev] Iceberg and other repos

[Nicolas Passerini]

Hi Norbert, are you using the stable version or the develpment one?


On Thu, Sep 22, 2016 at 10:49 AM, Esteban Lorenzano 
wrote:

> https://github.com/npasserini/iceberg/issues
>
> but I think this one is already reported (at least, I know I have talk
> with Nico about it :P)
>
> Esteban
>
> > On 22 Sep 2016, at 10:37, Norbert Hartl  wrote:
> >
> > I loaded my project with gitfiletree and tried to use it with iceberg.
> But I get
> >
> > 
> >
> > It seems that Iceberg assumes that packages are loaded with Iceberg
> itself. Meaning if the repository is not an iceberg repository
> #loadedVersion returns nil.
> >
> > So where to report bugs for iceberg?
> >
> > Norbert
> >
>
>
>

[Pharo-dev] Better diffs

[Nicolas Passerini]

I am not happy with Iceberg diffs so I wonder if there is a better diff
morphs around.

Currently I am using a GLMDiffPresentation, which gives an easy way to show
a diff, but is not much flexible. Some requirements I have are:
a. Configure coloring (currently changes are always shown in red for the
left version and in green for the right version).
b. Provide a title for each side of the diff
c. (more difficult) Show three way diffs.

Also highlighting is just not right in current version, several times it
does not highlight correctly the changed code.

So, do you know if there is a better way to show diffs?

Thank you.
Nico

Re: [Pharo-dev] Iceberg and other repos

[Nicolas Passerini]

On Thu, Sep 22, 2016 at 11:43 AM, Norbert Hartl  wrote:

> I'm using stable, sorry for not saying.
>

No worries.

I think it is fixed in the newer development version, but let me check it
and I will come back to you.

Re: [Pharo-dev] Iceberg and other repos

[Nicolas Passerini]

Yes, I do not know exactly why, but Metacello will not update your packages
if you do that.

On Thu, Sep 22, 2016 at 12:27 PM, Norbert Hartl  wrote:

>
> Am 22.09.2016 um 11:56 schrieb Nicolas Passerini :
>
>
> On Thu, Sep 22, 2016 at 11:43 AM, Norbert Hartl 
> wrote:
>
>> I'm using stable, sorry for not saying.
>>
>
> No worries.
>
> I think it is fixed in the newer development version, but let me check it
> and I will come back to you.
>
> I loaded
>
> Metacello new
>   baseline: 'Iceberg';
>   repository: 'github://npasserini/iceberg:master';
>   load.
>
> but the problem still exists. I must confess that I struggle to use this
> properly. By executing the expression above I cannot see what I really
> updated. Monticello browser is not of any help. I can see Iceberg.package
> which is bold. Loading the package does not seem to do anything and the
> package stays bold.
>
> Norbert
>
>

Re: [Pharo-dev] Iceberg and other repos

[Nicolas Passerini]

Hi Norbert,

I am failing to reproduce this issue, I would need more info.
What I did is:
- create a git repository with git file tree and load some package into a
clean Pharo 6 Image with the stable version of Iceberg
- add a local iceberg repository pointing to the same directory where the
gitfiletree repository resides
- open an Iceberg repository synchronizer for that project.

... and it seems to work, so I must be missing something.

On Thu, Sep 22, 2016 at 12:38 PM, Nicolas Passerini 
wrote:

> Yes, I do not know exactly why, but Metacello will not update your
> packages if you do that.
>
> On Thu, Sep 22, 2016 at 12:27 PM, Norbert Hartl 
> wrote:
>
>>
>> Am 22.09.2016 um 11:56 schrieb Nicolas Passerini :
>>
>>
>> On Thu, Sep 22, 2016 at 11:43 AM, Norbert Hartl 
>> wrote:
>>
>>> I'm using stable, sorry for not saying.
>>>
>>
>> No worries.
>>
>> I think it is fixed in the newer development version, but let me check it
>> and I will come back to you.
>>
>> I loaded
>>
>> Metacello new
>>   baseline: 'Iceberg';
>>   repository: 'github://npasserini/iceberg:master';
>>   load.
>>
>> but the problem still exists. I must confess that I struggle to use this
>> properly. By executing the expression above I cannot see what I really
>> updated. Monticello browser is not of any help. I can see Iceberg.package
>> which is bold. Loading the package does not seem to do anything and the
>> package stays bold.
>>
>> Norbert
>>
>>
>

Re: [Pharo-dev] Many problems with Iceberg :-(

[Nicolas Passerini]

Hi Alex, I'm sorry I missed your last message on Slack.

Yes, current "stable" version (v0.2.1) has a bug, that I decided not to fix
because I am about to release v0.3. The new version is quite stable and a
lot faster, so maybe you will like to give it a test before the release
(that should be in a few days anyway.

It seems that you have loaded code from Monticello but at the same time you
have the same packages in an Iceberg repository. Am I right?

If that is the case, I have to say we do not support exactly that usage
pattern. Sorry, for that, I will work on supporting it.

In the meanwhile, you have a few workarounds:
1) If your code is already in a git repository (I guess it is the case
given your error), then loading it in a clean image should not pose any
problems.
2) Or if you loaded from github using metacello it should also work (I
would say it should work also for code loaded from gitfiletree but Norbert
reported a problem with it, which I am not being able to reproduce.)
3) Otherwise, if your code is only in monticello, then saving it to a clean
Iceberg repository should work also.


In any case, do not hesitate comming to me with any question or problem, I
will try to help you. (But take into account the different time zones.)

Cheers,
Nico


On Fri, Sep 23, 2016 at 5:36 AM, Tudor Girba  wrote:

> Hi,
>
> Please use the development version of Iceberg. It should be fixed there.
>
> Metacello new
> baseline: 'Iceberg';
> repository: 'github://npasserini/iceberg';
> load.
>
> Cheers,
> Doru
>
>
> > On Sep 23, 2016, at 12:07 AM, Alexandre Bergel 
> wrote:
> >
> > Hi!
> >
> > I am facing several bugs using Iceberg.
> > Am I the only one?
> >
> > 
> > 
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing has its own flow."
>
>
>
>
>
>
>

Re: [Pharo-dev] Many problems with Iceberg :-(

[Nicolas Passerini]

Thanks, Norbert.

On Fri, Sep 23, 2016 at 10:46 AM, Norbert Hartl  wrote:

> No,
>
> I unloaded the code and reloaded the development version. My error is
> slightly different. I use a repository that is having a filetree repository
> (or gitfiletree) and that I try to open with iceberg
>
> Norbert
>
>
>
> Am 23.09.2016 um 00:07 schrieb Alexandre Bergel :
>
> Hi!
>
> I am facing several bugs using Iceberg.
> Am I the only one?
>
> 
> 
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] How does Pharo store instance variables?

[Nicolas Passerini]

If you defined the variable as an instance variable in the class side, you
can access it as

Greeter instVarNamed: 'greeting'
or
Greeter instVarAt: 1


But also you can define class variables from the instance side, which is
slightly different (and I think most common, isn't it?)

Object subclass: #Greeter
instanceVariableNames: ''
classVariableNames: 'greeting'
package: 'Greetings'

if that is the case, there is in fact a dictionary which is accessed by
doing

Greeting classPool


On Mon, Oct 3, 2016 at 10:23 PM, CodeDmitry  wrote:

> I am trying to study Pharo's internals and I am now curious how it stores
> class variables.
>
> I notice that in order to have a class `Greeter` with a "static" variable
> `greeting`, I need to make `greeting` an instance variable under "show show
> the class side" and create a "Getter" and "Setter" for this "instance
> variable".
>
> First thing that confuses me is, why is this called an instance variable if
> this particular "static" method is not bound to any particular instance? Is
> it just because it is defined in an "instance" of a "ProtoClass"?
>
> Second thing that confuses me is, where are these pairs of ("instance
> variable name" => "instance variable value") stored? I know that I can call
>
> Transcript show:
> ((Greeter class) instanceVariables at: 1).
>
> which prints "greeting".
>
> and
>
> Transcript show:
>   Greeter instanceVariables class.
>
> which prints "Array"(curious, i expected a Dictionary mapping Strings to
> Object).
>
> Transcript show:
> ((Greeter class) instanceVariables at: 1) class.
>
> prints "ByteSymbol".
>
> Now I am confused, where are the actual values of the "static variables"
> stored? I can find the names, but  can't understand where  the values are
> hidden.
>
> Can somebody help me understand  this?
>
>
>
>
> --
> View this message in context: http://forum.world.st/How-
> does-Pharo-store-instance-variables-tp4917924.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

[Pharo-dev] [ANN] New release of iceberg

[Nicolas Passerini]

Hi, we are releasing a new version of Iceberg, with several new features
and bugfixes. I would't yet say that is 100% production ready, but it is
close, so I want to invite you to test it and provide feedback.

You can install it by doing:

Metacello new
  baseline: 'Iceberg';
  repository: 'github://npasserini/iceberg';
  load.

More installation instructions and documentation can be found at
https://github.com/npasserini/iceberg.

Some of the new features in this version are:
- Allow to commit several packages together in the same commit.
- Show diffs for incoming and outgoing commits (i.e. before push/pull you
can browse the difference between the remote and the local versions).
- New History view allows to see any commit in any branch and compare it to
the current loaded version.
- Better support for interacting code loaded outside Iceberg (smaltalkhub,
filetree, gitfiletree, etc).
- From the diff view, revert changes or browse them (i.e. open a Nautilus
on the changed class/method).
- Automatically update presentations on code / repository changes.
- Integration with Metacello, i.e. after installing Iceberg you do
something like

Metacello new
  baseline: 'TaskIt';
  repository: 'github://sbragagnolo/taskit';
  load.


(By default) it will be loaded using iceberg (there is a setting to avoid
it if you prefer traditional behavior.

- Improved handling of git errors.
- Improved performance for several operations.
- Improved documentation.
- ... and several bug fixes and other minor improvements (please look at
https://github.com/npasserini/iceberg/milestone/7?closed=1 for more
details).


Please do not hesitate to contact me if you have any doubts.

Re: [Pharo-dev] [ANN] New release of iceberg

[Nicolas Passerini]

Hi Hernán, thank you for your report. It would be even nicer if you could
report it at https://github.com/npasserini/iceberg/issues

I think we might not be far from having Iceberg working on Pharo 5.0. Even
we have our tests running on Pharo 6.0 and 5.0 in travis (
https://travis-ci.org/npasserini/iceberg), both for linux and mac.

Sadly the tests do not cover the UI and that is why I missed the issue
reported by Hernán. I do not know how hard could it be to have tests for
that.

But the real problem right now is to have everything running on Windows.
That might take a while, maybe next month we will arrive there.



On Fri, Oct 14, 2016 at 12:48 AM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

>
> Ok. IMHO Nicolas if you really want more feedback I think it's worth it to
> release it for 5.0, unless 6.0 has dramatically changed :)
> Cheers,
>
> Hernán
>
>
> 2016-10-13 14:02 GMT-03:00 Esteban Lorenzano :
>
>> in principle, Iceberg is meant to work on Pharo6+
>> No idea about backward compatibility (it shouldn’t be so hard either…)
>>
>> Esteban
>>
>> On 13 Oct 2016, at 19:00, Hernán Morales Durand 
>> wrote:
>>
>> Hi Nicolas,
>>
>> After installing it in Pharo 5.0 (#50761, Win 7) and clicking World Menu
>> -> Tools -> Iceberg
>> I got the Exception in the screenshot attached.
>>
>>
>> 2016-10-13 9:25 GMT-03:00 Nicolas Passerini :
>>
>>> Hi, we are releasing a new version of Iceberg, with several new features
>>> and bugfixes. I would't yet say that is 100% production ready, but it is
>>> close, so I want to invite you to test it and provide feedback.
>>>
>>> You can install it by doing:
>>>
>>> Metacello new
>>>   baseline: 'Iceberg';
>>>   repository: 'github://npasserini/iceberg';
>>>   load.
>>>
>>> More installation instructions and documentation can be found at
>>> https://github.com/npasserini/iceberg.
>>>
>>> Some of the new features in this version are:
>>> - Allow to commit several packages together in the same commit.
>>> - Show diffs for incoming and outgoing commits (i.e. before push/pull
>>> you can browse the difference between the remote and the local versions).
>>> - New History view allows to see any commit in any branch and compare it
>>> to the current loaded version.
>>> - Better support for interacting code loaded outside Iceberg
>>> (smaltalkhub, filetree, gitfiletree, etc).
>>> - From the diff view, revert changes or browse them (i.e. open a
>>> Nautilus on the changed class/method).
>>> - Automatically update presentations on code / repository changes.
>>> - Integration with Metacello, i.e. after installing Iceberg you do
>>> something like
>>>
>>> Metacello new
>>>   baseline: 'TaskIt';
>>>   repository: 'github://sbragagnolo/taskit';
>>>   load.
>>>
>>>
>>> (By default) it will be loaded using iceberg (there is a setting to
>>> avoid it if you prefer traditional behavior.
>>>
>>> - Improved handling of git errors.
>>> - Improved performance for several operations.
>>> - Improved documentation.
>>> - ... and several bug fixes and other minor improvements (please look at
>>> https://github.com/npasserini/iceberg/milestone/7?closed=1 for more
>>> details).
>>>
>>>
>>> Please do not hesitate to contact me if you have any doubts.
>>>
>>
>> 
>>
>>
>>
>

Re: [Pharo-dev] Git versions on CI slaves

[Nicolas Passerini]

So what is the path to go?
Shall we update the slaves to use the newer version or should we see how to
remove that option?

BTW, the -C option is in which git command?

2016-10-21 11:20 GMT+02:00 Pavel Krivanek :

> Hi,
>
> we have a problem with current MonticelloFileTree (and Iceberg) on our CI
> slaves because it requires option -C that was introduced in version 1.8.5
> or something like so but our slaves have older Git versions (1.7).
>
> -- Pavel
>

Re: [Pharo-dev] [Ann] Stack Android VM

[Nicolas Passerini]

This is great!

2016-10-23 23:08 GMT+02:00 Denis Kudriashov :

> Great.
> Do you have prebuilt apk file?
>
> 2016-10-23 22:03 GMT+02:00 Santiago Bragagnolo <
> santiagobragagn...@gmail.com>:
>
>>Still far from production. But since i would happy to have some
>> feedback, I'm happy to show you some progress on the android VM. Not yet
>> release. But we have already a way of compiling and deploying an image into
>> an android device.
>>
>>   You can check it in this repo github.
>>   https://github.com/sbragagnolo/pharo-vm/
>>
>>   The building steps are detailed on the README-Android.md file.
>> Building the Stack AndroidVM
>>
>>1.
>>
>>Download the sources from github
>>
>>
>>git clone --depth=1 https://github.com/sbragagnolo/pharo-vmcd pharo-vm
>>
>>2.
>>
>>Set-up your environment: This script will download the SDK installer
>>and NDK R10
>>
>>cd android/scripts
>>./setupAndroidEnvironment.st
>>
>>This script downloads the content from
>>- 'http://dl.google.com/android/repository/android-ndk-r10e-li
>>   nux-x86_64.zip'.
>>   - 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'.
>>
>>After this process you should have available the environment
>>variables ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by checking
>>your .bashrc file at the user's home directory.
>>3.
>>
>>Create a new image: this image will be created by pointing to this
>>local git repository
>>
>>cd android/scripts
>>./newImage.st
>>
>>4.
>>
>>Link sources to the build folder: The Android vm relies on a Java
>>wrapper. This sources must be accessible from the build folder.
>>
>>cd android/scripts
>>./linkSources.st
>>
>>5.
>>
>>Generate the sources of the stack vm: This script executes the
>>generator of the image created on int the 3rd step.
>>
>>cd android/scripts
>>./generateStackAndroidMake.st
>>
>>6.
>>
>>Generate the resource image for deployment: This script download and
>>suites up an image for deployment on the folder
>>build/assets/SmalltalkRessources
>>
>>cd android/scripts
>>./newResourceImage.st
>>
>>This image created in this point is downloaded with it related VM for
>>editing and loading the code you want to deploy, or configure the things
>>you want.
>>7.
>>
>>The VM compilation: This script generates the libraries with the VM
>>code.
>>
>>cd build
>>./build.sh
>>
>>8.
>>
>>The Java wrapper compilation and Android Application packaging
>>
>>cd build
>>./package.sh
>>
>>9.
>>
>>Installing into your device. If you want to generate an APK file with
>>your custom name, you will need to deal with the AndroidManifest.xml 
>> before
>>runing the package.sh script :)
>>
>>cd build/bin
>>adb install -r StackActivity-debug.apk
>>
>>
>>
>> - Im currently working on the JIT version of the VM, that still avoiding
>> me :).
>>  But you have as well the instruction on the same README-Android.me file.
>>
>>
>>  Santiago
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Nicolas Passerini]

2016-11-07 10:37 GMT+01:00 Denis Kudriashov :

> NativeStructure
>subclass : #SDL_Point
>layout : StructureLayout
>slots: { #x &=> #int. #y &=> #int}
> ...
> (I got example of Ronie definition from his paper https://hal.inria.fr/
> hal-01353884/document).
> So all offsets logic will go to one place StructureLayout and slots. And
> also we will not forced to use accessors anymore.
>

I like this idea.
But one question, would it be backwards compatible? (I mean, if I have
current FFI invocations that use a structure in the traditional way, will I
have to change all these functions if I try to migrate to this new idea?)

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Nicolas Passerini]

Well, maybe we can do it for Pharo 7.

2016-11-07 14:46 GMT+01:00 Esteban Lorenzano :

>
> On 7 Nov 2016, at 14:39, Nicolas Passerini  wrote:
>
>
> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov :
>
>> NativeStructure
>>subclass : #SDL_Point
>>layout : StructureLayout
>>slots: { #x &=> #int. #y &=> #int}
>> ...
>> (I got example of Ronie definition from his paper
>> https://hal.inria.fr/hal-01353884/document).
>> So all offsets logic will go to one place StructureLayout and slots. And
>> also we will not forced to use accessors anymore.
>>
>
> I like this idea.
> But one question, would it be backwards compatible? (I mean, if I have
> current FFI invocations that use a structure in the traditional way, will I
> have to change all these functions if I try to migrate to this new idea?)
>
>
> no, and that’s why I didn’t considered it for now.
> this is an api change, non backwards compatible and then it breaks my own
> criteria about Pharo6 development: no more API changes.
>
> but yes, in general, I like the idea… just we cannot break things just
> like that (I know, I break things… but this is not willingly :P)
>
> Esteban
>
>

[Pharo-dev] Saving and retrieving global settings

[Nicolas Passerini]

Hi, I added some settings into Iceberg and stored them. I expected that
they would be automatically loaded into a new image, but it does not work.
What I understand is that settings are loaded when the image is opened for
the first time, and Iceberg isn't there yet. Then I load Iceberg but it
will not load the global settings.

So, my question is: what would be the best way to load Iceberg settings
just after loading Iceberg into the image?

Re: [Pharo-dev] Bloc: Problems Running

[Nicolas Passerini]

2016-11-29 13:08 GMT+01:00 Denis Kudriashov :

> And my problem was related to feature/issue of Iceberg to require github
> keys.


This is interesting for my, which operation did demand for your github keys?
I mean, were keys need for that operation or did Iceberg ask you for keys
before they are needed?

Re: [Pharo-dev] Bloc: Problems Running

[Nicolas Passerini]

Thank you Denis, do you happen to know which version or branch of Iceberg
is loaded?

2016-11-30 12:56 GMT+01:00 Denis Kudriashov :

> Hi Nicolas.
>
> 2016-11-29 22:55 GMT+01:00 Nicolas Passerini :
>
>> 2016-11-29 13:08 GMT+01:00 Denis Kudriashov :
>>
>>> And my problem was related to feature/issue of Iceberg to require github
>>> keys.
>>
>>
>> This is interesting for my, which operation did demand for your github
>> keys?
>> I mean, were keys need for that operation or did Iceberg ask you for keys
>> before they are needed?
>>
>
> I got error when I install dev Brick:
>
> Git error: Cloning into ''Brick''...
> Permission denied (publickey).
> fatal: Could not read from remote repository.
> And I found comment that it could be not required in future.
>

Re: [Pharo-dev] Generate accessors refactoring

[Nicolas Passerini]

Let me recapitulate a little.
A) What to do in case that a method with same selector already exists in
the same class?
So far I think we've come up with four ideas:
1. Create with an alternative name such as instVar1 / instVar1:
2. Create with an alternative name but ask the user what the name should be.
3. Replace existing method with simple accessor.
4. Do nothing.

I think that the last one is the best alternative and should be the default
action. Let me analyze the others:
1. Is the current behavior, but I always end up deleting the method, I
can't think of a situation in which I want to keep a method named #name1 .
I know that there was a lot of thinking on top of this ideas, but even so I
think that we can (should) rethink things once in a while.

2. A little better, because lets me select a name better than #name1. Still
I do not like it, because this means that I have a Class with
- an instance variable 'name'
- a method #name which is not the accessor for 'name' inst var.
-  and an accessor which is named in another way

I think this can happen in two situations:
- The original #name method is in fact a (smarter) accessor (i.e., for
example it provides a lazy initialization). In this case the best action is
4 => do nothing, accessor already exists, do not provide a new one.
- The original #name does something else, that maybe has nothing to do with
the variable name... in this case, I think the best is aborting the
refactor. I am not proposing that refactoring browser should abort the
refactor automatically, probably not, but that is what I would do as user:
my class has a weird name clash, so I should rename either the inst var or
the method, it has no automatic solution.

I am not sure about how the "generate accessors" could help me coping with
name clashes, but I do not like generating accessor with another name
different from the inst var name is a good idea. We could have this as an
option to the user, but should not be the default.

3. This is really dangerous, we shouldn't do it. I am not sure if someone
would like to have this as a (non default) option.


B) What if the colliding method is in a superclass?
Well, pretty much the same but:
- in option 3 instead of replacing a method you could override it.
- the method in the superclass could not be a "smarter accessor" unless you
are trying to create accessors in subclass for an inst var in the
superclass... I do not like it. So I'd consider it allways as a name clash.

Then I think that the best option is still do nothing (option 4). You could
offer to create method with another name as alternative (option 2)... but I
still think that this kind of name "coincidences" may introduce bugs in the
future and should be avoided.

C) Colliding methods in subclasses.
Here we have a more subtle situation because the existing method could be a
smarter accessor, that even could have its motivation to be there (for
example because initialization code only is useful for one subclass).

I still think that doing nothing could be a safe solution, better than
creating it with an alternative name (but we could allow it also).

Here we could think also about writing the accessor, because it will not
override preexistent behavior. But we have to think about a few situations:
- Easy, if any of the colliding methods (they could be serveral one for
each subclass) is not a smarter accessor... we have name clashes and we
cannot do anything.
- If all colliding methods are smart accessors, we could create one in the
superclass, provided that there exists at least one subclass which does not
provide its own implementation.


Of course there is not precise way of determining if a preexistent method
can be considered as a smarter accessor or not... so we only can let the
user decide.

To resume:
- Doing nothing will be the best default as it is suitable for all cases,
and can not do any harm.
- Creating methods with alternative names could be optional, but shouldn't
be default. In this case I prefer to ask the user for a name instead of
creating one automatically.
- Creating the method even in case of collision can be dangerous... I am
not sure if we should even allow it as an option.

2016-12-07 0:03 GMT+01:00 Ben Coman :

> How about mostly keeping the existing behaviour, but default to
> collisions being deselected?
> Then at least you don't need to search for it.
> It minimises the chance of missing it by mistake.
> The deselected item easily stands out to be reselected if required.
>
> P.S. An additional side idea: If collision is from a superclass then
> append (Superclass>>name) to the list item, and clicking on it shows a
> code dialog to the right similar to Spotter code review pane, to make
> a review easier.
>
> cheers -ben
>
> On Tue, Dec 6, 2016 at 10:09 PM, Yuriy Tymchuk 
> wrote:
> > It shouldn’t be too intelligent. Keep the default behavior, and for each
> > method add a 3-state checkbox: create (default), skip, force (override).
> > Also having a usage 

Re: [Pharo-dev] Generate accessors refactoring

[Nicolas Passerini]

Yes, I meant what Denis says.

If you abort the refactoring/transformation in case of name clash, then you
will have more cases in which the transformation is not applicable.

2016-12-08 14:19 GMT+01:00 Denis Kudriashov :

>
> 2016-12-08 14:18 GMT+01:00 Denis Kudriashov :
>
>> To be clear, you don't mean Do Nothing; you mean Issue an Error and Abort
>>> the Refactoring right?
>>
>>
>> No. "Do Nothing" means that if we already have method with instVar name
>> we will skip this accessor. So we will not generate setter if there is
>> already method #instVar:. No matter if this method do something wrong
>> inside.
>
>
> But getter will be generated in that case. No abort.
>

Re: [Pharo-dev] protocol pane "no messages" Re: [Pharo-users] setter method

[Nicolas Passerini]

I will add that I doubt that any filetree repository (or at least its
metadata-less versions) repository is capable of remembering an empty
protocol.

2016-12-10 20:27 GMT+01:00 p...@highoctane.be :

> Hi Ben,
>
> Yes and no.
> Because you can add a protocol right away without any method and end up in
> my layout.
>
> Pedantically yours,
> Phil
>
> On Sat, Dec 10, 2016 at 2:17 PM, Ben Coman  wrote:
>
>> Nope. I'll see your pedantic, and raise you...
>>
>> Clicking on "no messages" and adding a method you get...
>> --all--
>> as yet unclassified.
>>
>> So "no protocols" goes away, but there are still no protocols.
>>
>> (pedantic poker, fun for all the family)
>> cheers -ben
>>
>>
>> On Sat, Dec 10, 2016 at 2:56 AM, p...@highoctane.be 
>> wrote:
>> > To be pedantic it should be "no protocols" because as soon as you add
>> one,
>> > you get
>> >
>> > --all--
>> > someaddedprotocol
>> >
>> > even if there is no method.
>> >
>> > Phil
>> >
>> > On Fri, Dec 9, 2016 at 7:21 PM, Ben Coman  wrote:
>> >>
>> >> [Forwarded to pharo-dev for side discussion...]
>> >>
>> >> On Sat, Dec 10, 2016 at 2:15 AM, Ben Coman 
>> wrote:
>> >> > On Sat, Dec 10, 2016 at 1:39 AM, Kateryna Aloshkina
>> >> >  wrote:
>> >> >> Hi everybody!
>> >> >>
>> >> >> I've just joined the community:) and have a question
>> >> >> How to write the method count: such that, when invoked on an
>> instance
>> >> >> of
>> >> >> Counter, instance variable is set to the argument given to the
>> message?
>> >> >> so that
>> >> >> Counter new count: 7
>> >> >> would set the value of a new Counter instance to 7
>> >> >> (It is a little exercise from
>> >> >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exo-Cou
>> nter.pdf)
>> >> >>
>> >> >>
>> >> >> Best wishes,
>> >> >> Kateryna
>> >> >
>> >> > Welcome Kateryna,
>> >> > I hope you are having fun and Pharo changes the way you think about
>> >> > programming.
>> >> >
>> >> > Referring to Figure 1.2, assuming you've already created the class,
>> >> > first make sure you are on the instance-side rather than the
>> class-side
>> >> > of the class such that the class definition in the bottom (code) pane
>> >> > looks just like Figure 1.2.  Click the  button to toggle which
>> >> > side you look at.
>> >> >
>> >> > Now in the third (protocols) pane on "no messages"
>> >> > and you will get a method template in the code pane
>> >> >
>> >> > Change... messageSelectorAndArgumentNames
>> >> > to... count:
>> >> >
>> >> > then change statements
>> >> > to an assignment to the instance variable.
>> >> > and  the the code to save & compile the method.
>> >>
>> >> To be pedantic, shouldn't "no messages" actually be "no methods"
>> >> But maybe even better would be... "click for method template" ?
>> >>
>> >> cheers -ben
>> >>
>> >
>>
>>
>

Re: [Pharo-dev] The Iceberg TechTalk recording

[Nicolas Passerini]

Maybe we could try to edit the video? Is it possible?

2016-12-13 21:20 GMT+01:00 Esteban Lorenzano :

> Ah, but you need to skip until minute 10 :P
>
> Esteban
>
> > On 13 Dec 2016, at 21:19, Esteban Lorenzano  wrote:
> >
> > Hi,
> >
> > for those who couldn’t join us, this is the recording:
> >
> > https://www.youtube.com/watch?v=AuZAFfWS34w
> >
> > I think it was a great talk :)
> >
> > cheers,
> > Esteban
>
>

Re: [Pharo-dev] Do you think VersionBrowser is counterintuitive?

[Nicolas Passerini]

I agree, current version is not intuitive.

Moreover, is it possible to consider a design that could allow Iceberg or
other tools to contribute older versions from repository?

2016-12-23 16:16 GMT+01:00 Denis Kudriashov :

>
> 2016-12-23 16:04 GMT+01:00 Thierry Goubier :
>
>>
>> In short, what you describe replaces a non-obvious, arbitrary pane
>> allocation by another one... maybe just more familiar to you.
>
>
> No. I suggest current image version on left pane with visible label
> "current version". And selected version on the right pane.
> Also when you will switch from one version to another left pane will be
> never changed which will be visible and intuitive indication that new
> selected method is on the right pane because only right pane will change.
>

Re: [Pharo-dev] Call of projects of open-dev lectures

[Nicolas Passerini]

What do you think about Iceberg?

2017-01-04 15:48 GMT+01:00 Stephane Ducasse :

> Hi
>
> We are organising a lecture where students should
> - learn pharo
> - learn how to communicate with open source community
> - learn how to reverse engineer, fix bugs
> They should work by 3/4.
>
> We are looking for projects that would like to accept
> - propose some bugs to be fixed
> - to communicate with newbies and from time to time
>
> I was thinking about
> - MDL
> - Roassal
> - Moose ?
> - Pillar ? but nobody beside me and I do not have the time
> - DRGeoII
> - Telescope
> - Artefact
> - Scale
> - Ecstatic
>
> So if you have a project and you want to participate.
> We would like to have
> - web page?
> - mailing-list
> - bug trackers/todo?
>
> Stef
>

Re: [Pharo-dev] [Pharo-users] Pharo Sprint in Buenos Aires

[Nicolas Passerini]

I think UTN is not a good idea for a Pharo sprint, because we will need a
good Internet connection and that can not be guaranteed here.
(Or correct me and tell me that Internet connection is not a must, so we
can meet here at UTN without problems).

How much people is coming to the Sprint?


On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye  wrote:

> The Pabellon 1 is closed on saturdays afternoon, but have you asked for
> Pabellon 2? I think it's open on saturdays (i don't know if it is possible
> to book a room)
>
>
> 2013/9/4 Guillermo Polito 
>
>> Probably UTN?
>>
>>
>> On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni wrote:
>>
>>> So it looks like we are going to do the Pharo sprint in Buenos Aires
>>> Saturday, the 14th of September.
>>> The question is now where do we meet?
>>> The original idea was to reserver a room at the UBA, but that is not
>>> possible the weekend.
>>> Any suggestions?
>>>
>>> On 2013-09-03, at 09:05, Mariano Martinez Peck 
>>> wrote:
>>>
>>> > Cool. I'll be there, of course!
>>> > Keep us informed.
>>> > Cheers,
>>> >
>>> >
>>> > On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni >> >wrote:
>>> >
>>> >> everything is open so far, guido had the idea of reserving a room at
>>> the
>>> >> UBA,
>>> >> we will have more details tomorrow :)
>>> >>
>>> >> On 2013-09-02, at 21:24, Gisela Decuzzi 
>>> wrote:
>>> >>> Great! The idea is to spend the full day? Or do you have any planed
>>> time?
>>> >>>
>>> >>>
>>> >>> 2013/9/2 Camillo Bruni 
>>> >>>
>>>  I spend a month in Buenos Aires working together with Guido Chari @
>>> the
>>>  UBA,
>>>  we take this opportunity to organize a Pharo sprint outside France
>>> ;)
>>> 
>>>  We are in early preparation phase and the date nor location isn't
>>> fixed
>>>  yet,
>>>  so if you are motivated to join, can mark possible dates on this
>>> doodle:
>>> 
>>>  http://doodle.com/qey7iieqm5yr4wwy
>>> 
>>>  cheers,
>>>  camillo
>>> 
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Mariano
>>> > http://marianopeck.wordpress.com
>>>
>>>
>>
>

Re: [Pharo-dev] [tlp] Re: [Pharo-users] Pharo Sprint in Buenos Aires

[Nicolas Passerini]

If you say so...

The Systems Department won't be open on Saturday afternoon, but we could
reserve a lab.


On Wed, Sep 4, 2013 at 10:39 AM, Clara Allende wrote:

> On the 4th floor there's some stable connection. Also if we are not too
> much people we could use the teacher's room at Systems Department... Or one
> of the laboratories in the 3rd floor (the yellow one would be nice).
>
>
> On 4 September 2013 10:32, Nicolas Passerini  wrote:
>
>> I think UTN is not a good idea for a Pharo sprint, because we will need a
>> good Internet connection and that can not be guaranteed here.
>> (Or correct me and tell me that Internet connection is not a must, so we
>> can meet here at UTN without problems).
>>
>> How much people is coming to the Sprint?
>>
>>
>> On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye wrote:
>>
>>> The Pabellon 1 is closed on saturdays afternoon, but have you asked for
>>> Pabellon 2? I think it's open on saturdays (i don't know if it is possible
>>> to book a room)
>>>
>>>
>>> 2013/9/4 Guillermo Polito 
>>>
>>>> Probably UTN?
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni 
>>>> wrote:
>>>>
>>>>> So it looks like we are going to do the Pharo sprint in Buenos Aires
>>>>> Saturday, the 14th of September.
>>>>> The question is now where do we meet?
>>>>> The original idea was to reserver a room at the UBA, but that is not
>>>>> possible the weekend.
>>>>> Any suggestions?
>>>>>
>>>>> On 2013-09-03, at 09:05, Mariano Martinez Peck 
>>>>> wrote:
>>>>>
>>>>> > Cool. I'll be there, of course!
>>>>> > Keep us informed.
>>>>> > Cheers,
>>>>> >
>>>>> >
>>>>> > On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni <
>>>>> camillobr...@gmail.com>wrote:
>>>>> >
>>>>> >> everything is open so far, guido had the idea of reserving a room
>>>>> at the
>>>>> >> UBA,
>>>>> >> we will have more details tomorrow :)
>>>>> >>
>>>>> >> On 2013-09-02, at 21:24, Gisela Decuzzi 
>>>>> wrote:
>>>>> >>> Great! The idea is to spend the full day? Or do you have any
>>>>> planed time?
>>>>> >>>
>>>>> >>>
>>>>> >>> 2013/9/2 Camillo Bruni 
>>>>> >>>
>>>>> >>>> I spend a month in Buenos Aires working together with Guido Chari
>>>>> @ the
>>>>> >>>> UBA,
>>>>> >>>> we take this opportunity to organize a Pharo sprint outside
>>>>> France ;)
>>>>> >>>>
>>>>> >>>> We are in early preparation phase and the date nor location isn't
>>>>> fixed
>>>>> >>>> yet,
>>>>> >>>> so if you are motivated to join, can mark possible dates on this
>>>>> doodle:
>>>>> >>>>
>>>>> >>>> http://doodle.com/qey7iieqm5yr4wwy
>>>>> >>>>
>>>>> >>>> cheers,
>>>>> >>>> camillo
>>>>> >>>>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Mariano
>>>>> > http://marianopeck.wordpress.com
>>>>>
>>>>>
>>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Taller de Lenguajes de Programación" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to tlp-utn-2012+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Taller de Lenguajes de Programación" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tlp-utn-2012+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

Re: [Pharo-dev] [tlp] Re: [Pharo-users] Pharo Sprint in Buenos Aires

[Nicolas Passerini]

I think it would be great to use 10Pines office if it is available.


On Fri, Sep 6, 2013 at 12:15 PM, Gisela Decuzzi wrote:

> Hello! If we are having hosting problems during the weekend with the
> sprint we can use 10Pines (http://www.10pines.com/) office.In fact in ten
> pines we will be very happy to offer our place for this kind of events.
> During the week is more complex to find room, but we are not used to work
> during weekends ;)
>
> So, the office is near Retiro (Av. Leandro N. Alem y Viamonte) we have
> internet access and if it's sunny we can use the roof.
> We should set a date to confirm the availability (again if it's weekend,
> is available otherwise we should check).
>
>
>
>
>
>  2013/9/4 Camillo Bruni 
>
>> From the doodle we're around 7, so I'd count with something like 10
>> people?
>> And yes, I think internet connection is a requirement, at least for
>> updating the issue tracker.
>>
>> On 2013-09-04, at 10:32, Nicolas Passerini  wrote:
>>
>> > I think UTN is not a good idea for a Pharo sprint, because we will need
>> a
>> > good Internet connection and that can not be guaranteed here.
>> > (Or correct me and tell me that Internet connection is not a must, so we
>> > can meet here at UTN without problems).
>> >
>> > How much people is coming to the Sprint?
>> >
>> >
>> > On Wed, Sep 4, 2013 at 10:12 AM, Sebastian Tleye 
>> wrote:
>> >
>> >> The Pabellon 1 is closed on saturdays afternoon, but have you asked for
>> >> Pabellon 2? I think it's open on saturdays (i don't know if it is
>> possible
>> >> to book a room)
>> >>
>> >>
>> >> 2013/9/4 Guillermo Polito 
>> >>
>> >>> Probably UTN?
>> >>>
>> >>>
>> >>> On Wed, Sep 4, 2013 at 2:45 PM, Camillo Bruni > >wrote:
>> >>>
>> >>>> So it looks like we are going to do the Pharo sprint in Buenos Aires
>> >>>> Saturday, the 14th of September.
>> >>>> The question is now where do we meet?
>> >>>> The original idea was to reserver a room at the UBA, but that is not
>> >>>> possible the weekend.
>> >>>> Any suggestions?
>> >>>>
>> >>>> On 2013-09-03, at 09:05, Mariano Martinez Peck <
>> marianop...@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> Cool. I'll be there, of course!
>> >>>>> Keep us informed.
>> >>>>> Cheers,
>> >>>>>
>> >>>>>
>> >>>>> On Mon, Sep 2, 2013 at 10:42 PM, Camillo Bruni <
>> camillobr...@gmail.com
>> >>>>> wrote:
>> >>>>>
>> >>>>>> everything is open so far, guido had the idea of reserving a room
>> at
>> >>>> the
>> >>>>>> UBA,
>> >>>>>> we will have more details tomorrow :)
>> >>>>>>
>> >>>>>> On 2013-09-02, at 21:24, Gisela Decuzzi 
>> >>>> wrote:
>> >>>>>>> Great! The idea is to spend the full day? Or do you have any
>> planed
>> >>>> time?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2013/9/2 Camillo Bruni 
>> >>>>>>>
>> >>>>>>>> I spend a month in Buenos Aires working together with Guido
>> Chari @
>> >>>> the
>> >>>>>>>> UBA,
>> >>>>>>>> we take this opportunity to organize a Pharo sprint outside
>> France
>> >>>> ;)
>> >>>>>>>>
>> >>>>>>>> We are in early preparation phase and the date nor location isn't
>> >>>> fixed
>> >>>>>>>> yet,
>> >>>>>>>> so if you are motivated to join, can mark possible dates on this
>> >>>> doodle:
>> >>>>>>>>
>> >>>>>>>> http://doodle.com/qey7iieqm5yr4wwy
>> >>>>>>>>
>> >>>>>>>> cheers,
>> >>>>>>>> camillo
>> >>>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Mariano
>> >>>>> http://marianopeck.wordpress.com
>> >>>>
>> >>>>
>> >>>
>> >>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Taller de Lenguajes de Programación" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tlp-utn-2012+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

[Pharo-dev] Issues trying to use NewList on Nautilus

[Nicolas Passerini]

Last Saturday in the Pharo Sprint in Buenos Aires, together with Mariano
Peck and Guido Chari we have been trying to address issue
11605,
i.e. using NewList in Nautilus. I am still trying to finish with this task,
and I have a few questions, may be somebody here can enlighten me.

We have encountered some problems with multiple selections. First, the list
has 4 ValueModels for its selected elements: selectedIndex,
selectedIndexes, selectedItem, selectedItems. I would like to understand
more clearly how should we use them. In particular I find difficult to
bring the plural versions and the singular versions together.
If I select more than one element in the list, it seems that the value in
the selectedItem/selectedIndex points to the last one I clicked. But then
the model in Nautilus is receiving two updates, one from selectedItem/Index
and the other from selectedItems/indexes, should we just ignore the
singular one or what?

Second, in my linux the list doesn't seem to receive ctrl+click events. Any
clue about this?


Finally, another question not related to multiple selections.
The old list (it was a PluggableIconListMorph) has a "searchedElement"
attribute. Looking at the categories list in Nautilus, the usage is so: if
you have not selected any category (i.e. you are seeing the method of all
categories in a class) and you click on a method in the method list, the
searched element of the category list points to the category of the
selected method. This is different from selecting the category, because
selecting the category would filter the method list. It also highlights the
category in a different color.

So, my question is, should we keep this behaviour while migrating Nautilus
to new lists o not?
If the answer is yes, I would ask how to do it, because the NewList does
not seem to have this feature. Should I add the searchedElement to the
NewList or is there another way to achieve the same behavior?

Re: [Pharo-dev] Issues trying to use NewList on Nautilus

[Nicolas Passerini]

> If your UI is based on multi selection (and Nautilus definitely is) you
> should not register to whenSelectedIndexChanged:/whenSelectedItemChanged:,
> but only the plural version.
>

Ok, I get that.
Still, when you create a NewList you have to provide a setIndexSelector,
for example in the CategoryWidget I am doing:

categoriesList := NewList
on: self
 getItemsSelector: #getCategories
setIndexSelector: #selectedCategoryIndex:
 getDisplaySelector: #categoryWrapper:.

So, every time you click on the categories list (both selecting multiple
categories or not) the CategoryWidget receives the #selectedCategoryIndex:
message.
The current selectedCategoryIndex: message reads like this:

selectedCategoryIndex: anInteger

| anObject |
anObject := self getCategories at: anInteger ifAbsent: [ nil ].
 self model selectedCategory: anObject.
 self changed: #selectedCategoryIndex.
 self model categorySelectionChanged.
self model changed: #currentHistoryIndex.


Also the NewList is in the list of dependents of the CategoryWidget, so it
also gets the #update: message
Is this right?

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

[Nicolas Passerini]

Hi Demian, I've been using your ppa for a while, but I could have the last
update working.
This is the information I've got:

npasserini@pablitar-xps:~/Downloads$ sudo apt-get install
pharo-launcher:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  pharo-launcher:i386
0 upgraded, 1 newly installed, 0 to remove and 193 not upgraded.
Need to get 0 B/15.3 MB of archives.
After this operation, 48.0 MB of additional disk space will be used.
(Reading database ... 552696 files and directories currently installed.)
Unpacking pharo-launcher:i386 (from
.../pharo-launcher_2013.09.27-1~ppa1~precise1_i386.deb) ...
dpkg: error processing
/var/cache/apt/archives/pharo-launcher_2013.09.27-1~ppa1~precise1_i386.deb
(--unpack):
 trying to overwrite '/usr/share/man/man1/pharo.1.gz', which is also in
package pharo-vm-core:i386 2013.06.12-1~ppa1~precise1
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/pharo-launcher_2013.09.27-1~ppa1~precise1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any clue?
Is there any information else, that I could give you to help find out the
problem?


On Thu, Sep 26, 2013 at 10:58 AM, Damien Cassou wrote:

> On Thu, Sep 26, 2013 at 2:04 PM, kilon  wrote:
> > Is this why image launching fails, or is it unrelated ?
>
>
> open a new thread about that please.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
>
>