Re: [Pharo-dev] Integration process in presence of "external" project

[Esteban Lorenzano]

in fact I just checked and Versioner already does that: right button on 
monticello over a configuration gives you a: “create development/release 
version”.
So only thing we need is to use the tools we already created :)


> On 22 Apr 2015, at 08:50, Esteban Lorenzano  wrote:
> 
> and btw… of course I agree repositories need to be added, and configurations 
> kept in image. 
> 
> cheers, 
> Esteban
> 
>> On 22 Apr 2015, at 08:34, Esteban Lorenzano  wrote:
>> 
>> I disagree with your proposal. 
>> It will be a mess, nobody will merge (because there will be no point on 
>> doing it) and we will not move out from a monolithic system. 
>> What I propose is not an invention, is how big projects work… what you have 
>> to take into account is that any project under the Pharo umbrella does not 
>> have an owner, but a maintainer. That means if Alan is on vacation or he 
>> does not has the time to do the new configuration, anyone can doit. 
>> 
>> Yes, it can look slow, but that is because you are too used to the old 
>> workflow, and because right now system is not modular. 
>> The method I propose will enhance modularity (while the older will, at 
>> least, not help), which means with time, changes will be applied just in one 
>> module and not along the full system like now. 
>> 
>> Of course with proper tools this will be faster, but I very much prefer 
>> people telling me “I need this” (that’s why I did the integrator app, and 
>> modified the monkey to take and validate configurations), and we do it, that 
>> we abandon our pursuit of modularity because is uncomfortable at the 
>> beginning. 
>> 
>> We can modify also monticello or versioner (better monticello because 
>> everything will be closer, but  using versioner API) to do a “save new 
>> version” which would be more or less the same as a slice, but for a 
>> configuration, and it will: 
>> 
>> - save the packages associated to the configuration
>> - create a new version
>> - save the new configuration
>> 
>> this will not be to much work (I think I can have it in a couple of days), 
>> it will help the process (because eventually everything should be managed 
>> through configurations (or PPM configurations), and it will allow us to keep 
>> a process that is better and validated.. 
>> 
>> TL;DR: Better enhance the tools than drop the process. 
>> 
>> Esteban
>> 
>>> On 22 Apr 2015, at 07:47, stepharo  wrote:
>>> 
>>> Esteban
>>> I was thinking about the following this night.
>>> 
>>> While I understand that we want configuration only it will slow us down 
>>> like hell.
>>> 
>>> Example
>>> with guille we wanted to fix a problem (I do not remember which one)
>>> we need a change to be done in rubric so we will have to publish the change 
>>> in rubric repo
>>>  - (find it and add it) so the rubric repo should be there before
>>>  - then one guy of rubric should have a look
>>>  - then merge
>>>  - then publish an issue with a configuration
>>>  - then only then we can work
>>>  => result why do we need sync for me and guille to continue to work???
>>>  => what if Alain in on vacation?
>>>  we stop working?
>>>  => Remember: We did Pharo especially because people in squeak did not want 
>>> that we change
>>>  packages.
>>> 
>>> Alternate process
>>>  - we do a fix we publish it in Pharo and yes this touches Rubric and
>>>  - we  integrate it in Pharo head
>>>  - then the guy from rubric merge in their trunk when they want.
>>>  it should be part of the their process to merge always with pharo trunk
>>>  - At that point they can report a problem
>>>  - then they produce at their speed a new configuration
>>>  - then we integrate when ready their change
>>> 
>>> 
>>> Stef
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] Integration process in presence of "external" project

[Thierry Goubier]

Le 22/04/2015 09:02, Esteban Lorenzano a écrit :

in fact I just checked and Versioner already does that: right button
on monticello over a configuration gives you a: “create
development/release version”. So only thing we need is to use the
tools we already created :)


My position would be that, as in large projects with external upstream,
the version of the external project you integrate is not exactly the
same as the external one.

You have a process of pushing fixes upstream, and merging the versions
from the external project into yours. If you have good merge support, 
this is an easy process.


Also remember that we have to deal with long-lived integration processes
with a significant memory; large configurations with lots of versions
may become a concern after a while (and for the current image, it
doesn't mean much to have access to all that history). We saw that with 
package history; it may be nice to plan for that now.


Another idea/possibility is to consider Baselines; given that a possible 
evolution for Pharo is towards versionning systems which handles 
branches and tags properly, baselines make that process significantly 
simpler than configurations by letting one only describe the 
dependencies between packages and sub-projects, and not their specific 
version numbers.


A key evaluation to see if that works is: can a Minimal image can be 
rebuilt easily up to a full image, at any point (i.e. at least is all 
the information related to external projects easily available).


A second one would be: if we had a git based process, how would that be? 
Could considering that (planning for branches, basically) make our 
current process simpler?


Thierry





On 22 Apr 2015, at 08:50, Esteban Lorenzano 
wrote:

and btw… of course I agree repositories need to be added, and
configurations kept in image.

cheers, Esteban


On 22 Apr 2015, at 08:34, Esteban Lorenzano 
wrote:

I disagree with your proposal. It will be a mess, nobody will
merge (because there will be no point on doing it) and we will
not move out from a monolithic system. What I propose is not an
invention, is how big projects work… what you have to take into
account is that any project under the Pharo umbrella does not
have an owner, but a maintainer. That means if Alan is on
vacation or he does not has the time to do the new configuration,
anyone can doit.

Yes, it can look slow, but that is because you are too used to
the old workflow, and because right now system is not modular.
The method I propose will enhance modularity (while the older
will, at least, not help), which means with time, changes will be
applied just in one module and not along the full system like
now.

Of course with proper tools this will be faster, but I very much
prefer people telling me “I need this” (that’s why I did the
integrator app, and modified the monkey to take and validate
configurations), and we do it, that we abandon our pursuit of
modularity because is uncomfortable at the beginning.

We can modify also monticello or versioner (better monticello
because everything will be closer, but  using versioner API) to
do a “save new version” which would be more or less the same as a
slice, but for a configuration, and it will:

- save the packages associated to the configuration - create a
new version - save the new configuration

this will not be to much work (I think I can have it in a couple
of days), it will help the process (because eventually everything
should be managed through configurations (or PPM configurations),
and it will allow us to keep a process that is better and
validated..

TL;DR: Better enhance the tools than drop the process.

Esteban


On 22 Apr 2015, at 07:47, stepharo  wrote:

Esteban I was thinking about the following this night.

While I understand that we want configuration only it will slow
us down like hell.

Example with guille we wanted to fix a problem (I do not
remember which one) we need a change to be done in rubric so we
will have to publish the change in rubric repo - (find it and
add it) so the rubric repo should be there before - then one
guy of rubric should have a look - then merge - then publish an
issue with a configuration - then only then we can work =>
result why do we need sync for me and guille to continue to
work??? => what if Alain in on vacation? we stop working? =>
Remember: We did Pharo especially because people in squeak did
not want that we change packages.

Alternate process - we do a fix we publish it in Pharo and yes
this touches Rubric and - we  integrate it in Pharo head - then
the guy from rubric merge in their trunk when they want. it
should be part of the their process to merge always with pharo
trunk - At that point they can report a problem - then they
produce at their speed a new configuration - then we integrate
when ready their change


Stef

Re: [Pharo-dev] Improving the documentation model

[Hilaire]

Le 21/04/2015 15:11, stephan a écrit :
> TL;DR: Some roadmap ideas. Looks like a lot of work.
> Comments and improvements welcome:
> We should replace the Pillar document format
> by a better one, suitable for WYSIWYG editing and
> creating long documents.

People mentioned Lyx[1] and there is TeXmacs[2] as well.


[1] https://en.wikipedia.org/wiki/LyX
[2] https://en.wikipedia.org/wiki/GNU_TeXmacs

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

Re: [Pharo-dev] Improving the documentation model

[Damien Cassou]

nacho <0800na...@gmail.com> writes:

> The other day I was thinking about this. I thought that it would be a great
> idea to have a pillar rendering engine inside Pharo.
> In that way the documentation written will be available in the image
> WYSIWYG with no need for recompilation. The update of books will be easy,
> just do a Software Update and the documentation is up to date.
> a Pillar rendering, WYSIWYG editor would be great.

in the following thread, I reference a prototype that does just that:

http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-td4819726.html

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] Integration process in presence of "external" project

[Andrei Chis]

On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano 
wrote:

> in fact I just checked and Versioner already does that: right button on
> monticello over a configuration gives you a: “create development/release
> version”.
> So only thing we need is to use the tools we already created :)


But this only works for releasing simple configurations that do not depend
on other configurations.
This would work for rubric, for example, but not for other configurations
we have in gtools.

Cheers,
Andrei


>
> > On 22 Apr 2015, at 08:50, Esteban Lorenzano  wrote:
> >
> > and btw… of course I agree repositories need to be added, and
> configurations kept in image.
> >
> > cheers,
> > Esteban
> >
> >> On 22 Apr 2015, at 08:34, Esteban Lorenzano 
> wrote:
> >>
> >> I disagree with your proposal.
> >> It will be a mess, nobody will merge (because there will be no point on
> doing it) and we will not move out from a monolithic system.
> >> What I propose is not an invention, is how big projects work… what you
> have to take into account is that any project under the Pharo umbrella does
> not have an owner, but a maintainer. That means if Alan is on vacation or
> he does not has the time to do the new configuration, anyone can doit.
> >>
> >> Yes, it can look slow, but that is because you are too used to the old
> workflow, and because right now system is not modular.
> >> The method I propose will enhance modularity (while the older will, at
> least, not help), which means with time, changes will be applied just in
> one module and not along the full system like now.
> >>
> >> Of course with proper tools this will be faster, but I very much prefer
> people telling me “I need this” (that’s why I did the integrator app, and
> modified the monkey to take and validate configurations), and we do it,
> that we abandon our pursuit of modularity because is uncomfortable at the
> beginning.
> >>
> >> We can modify also monticello or versioner (better monticello because
> everything will be closer, but  using versioner API) to do a “save new
> version” which would be more or less the same as a slice, but for a
> configuration, and it will:
> >>
> >> - save the packages associated to the configuration
> >> - create a new version
> >> - save the new configuration
> >>
> >> this will not be to much work (I think I can have it in a couple of
> days), it will help the process (because eventually everything should be
> managed through configurations (or PPM configurations), and it will allow
> us to keep a process that is better and validated..
> >>
> >> TL;DR: Better enhance the tools than drop the process.
> >>
> >> Esteban
> >>
> >>> On 22 Apr 2015, at 07:47, stepharo  wrote:
> >>>
> >>> Esteban
> >>> I was thinking about the following this night.
> >>>
> >>> While I understand that we want configuration only it will slow us
> down like hell.
> >>>
> >>> Example
> >>> with guille we wanted to fix a problem (I do not remember which one)
> >>> we need a change to be done in rubric so we will have to publish the
> change in rubric repo
> >>>  - (find it and add it) so the rubric repo should be there before
> >>>  - then one guy of rubric should have a look
> >>>  - then merge
> >>>  - then publish an issue with a configuration
> >>>  - then only then we can work
> >>>  => result why do we need sync for me and guille to continue to work???
> >>>  => what if Alain in on vacation?
> >>>  we stop working?
> >>>  => Remember: We did Pharo especially because people in squeak did not
> want that we change
> >>>  packages.
> >>>
> >>> Alternate process
> >>>  - we do a fix we publish it in Pharo and yes this touches Rubric and
> >>>  - we  integrate it in Pharo head
> >>>  - then the guy from rubric merge in their trunk when they want.
> >>>  it should be part of the their process to merge always with pharo
> trunk
> >>>  - At that point they can report a problem
> >>>  - then they produce at their speed a new configuration
> >>>  - then we integrate when ready their change
> >>>
> >>>
> >>> Stef
> >>>
> >>>
> >>
> >
>
>
>

Re: [Pharo-dev] Integration process in presence of "external" project

[Andrei Chis]

On Wed, Apr 22, 2015 at 7:47 AM, stepharo  wrote:

> Esteban
> I was thinking about the following this night.
>
> While I understand that we want configuration only it will slow us down
> like hell.
>
> Example
> with guille we wanted to fix a problem (I do not remember which one)
> we need a change to be done in rubric so we will have to publish the
> change in rubric repo
> - (find it and add it) so the rubric repo should be there before
> - then one guy of rubric should have a look
> - then merge
> - then publish an issue with a configuration
> - then only then we can work
> => result why do we need sync for me and guille to continue to work???
> => what if Alain in on vacation?
> we stop working?
> => Remember: We did Pharo especially because people in squeak did not
> want that we change
> packages.
>
> Alternate process
> - we do a fix we publish it in Pharo and yes this touches Rubric and
> - we  integrate it in Pharo head
> - then the guy from rubric merge in their trunk when they want.
> it should be part of the their process to merge always with pharo
> trunk
> - At that point they can report a problem
> - then they produce at their speed a new configuration
> - then we integrate when ready their change
>
>
This kind of process will be a pain for those that have to merge the
changes back to their repos.
I did this for a while when I was synching the debugger repo with Pharo and
even if I only had to merge maybe one slice a day it was kind of annoying.

Cheers,
Andrei


>
> Stef
>
>
>

Re: [Pharo-dev] TDD and BDD

[Miguel Moquillon]

Le 21/04/2015 13:44, Sean P. DeNigris a écrit :

Miguel Moquillon wrote

BDD and TDD stands for different purposes with different actors...

While that's unfortunately often true in practice, there is no difference
philosophically. [T|B]DD "done right" always focuses on the user.
[...]
The "In order to..." that you're describing is the outer, high-level
acceptance test that in Ruby for example might be written with Cucumber. But
once one has a failing acceptance test, the next step in BDD is to drop down
into e.g. RSpec and write something a lot closer to a unit test, often
mocking out collaborators to drive creation of an API.

In summary, the intent of BDD is to be "TDD Done Right".
I don't agreed with your assumption: there is a difference 
philosophically both in theory and in practice.
The word 'Test' in TDD doesn't mean its purpose is to test; it is a 
misconception. In fact TDD is a method for developers to focus on the 
design of their code by avoiding over-designing.
In other side, BDD stands for test, more exactly functional testing. It 
is a safety belt to
avoid both functional regressions and to ensure the written code is 
valid according to

the requirements.

So, when a functional test failed, the next step in BDD is to pass the 
control to the developer to fix the issue whatever

its method (BDD don't cover this level).
They are not related but, as you wrote in your example with Ruby, they 
can be used both in a project, at a different level. BDD doesn't imply 
TDD but yes, in practice, they are often used in conjunction.


Now, some tools were inspired by BDD to provide the developers a better 
way to express unit tests (RSpec for example), to be more focused on the 
design, but they are in fact more related to TDD than BDD. Don't 
confound the approach with the tools.



There is no
inherent conflict, and no specific tools are technically required. Although,
since as McLuhan suggested, we become our tools, so obviously the proper
tools may be decisive, especially when first learning.
There is no conflicts between TDD and BDD because they are not related 
and they are not concurrent.
In fact they can be used both but at different level. The same with the 
tools.
Beside that, I have a principle: don't learn an approach through a tool. 
But use a tool
to facilitate the application of the approach. And as you wrote, indeed, 
the proper tool is important.


Miguel Moquillon

Re: [Pharo-dev] Improving the documentation model

[Damien Cassou]

Dmitri Zagidulin  writes:

> * Extend Pillar. With a few more features, it can be on par with
> Markdown and Asciidoc, and then eventually surpass it (and have nice
> Pharo-specific features like detection and unit-testing of Pharo code
> blocks, etc).


could you please add missing features to
http://www.smalltalkhub.com/#!/~Pier/Pillar


> * Invest in instant-preview tech, in-image.

we have this prototype already:
http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-td4819726.html

But its author waits for TxText and Athens before investing more of his
time.


> This is similar to what PillarHub does, for example, by using the Ace
> online editor. Take a look at the first screenshot in:
> http://pillarhub.pharocloud.com/hub/pillarhub/about Side-by-side
> instant preview makes it possible to have the best of both worlds,
> text-based markup and WYSIWYG, without the typical WYSIWYG drawbacks
> (of making distributed version control difficult, first and foremost).


what I don't like about WYSIWYG word processors is that they hide the
content. I want to control my content. I want to immediately see if a
line is a section title (semantically) or if it's just bold and huge. I
want to immediately see if a section title is automatically numbered or
if the number was written manually.


> 3) The convenience of WYSIWYG can be provided with side-by-side instant
> preview (again, see PillarHub and the numerous WYSIWYG instant-previews in
> Markdown editors).


Luc improved the pillar plugin for TextMate so that it has instant
preview too.


> And actually, the WYSIWYG approach is much closer to HTML 1.0 (in the sense
> that, users have to indicate *semantic* intentions like emphasis by
> selecting different fonts, versus something like HTML 4/5, where the actual
> intention is declared (EMPH tags, QUOTE tags, etc).


I agree that this is a very important point.


> - Asciidoc has the ability to do file imports (compose a larger document
> out of smaller docs)


Cyril implemented that in Pillar last week.


> * Links. Asciidoc has semantic links both within a document, and across
> different Asciidoc documents (references to chapters, sections, etc).
> Pillar has within-document links, and inter-doc links are on the roadmap.


Cyril has to revise that part.


> * The ability to drop down to a more expressive markup (LaTeX or HTML). For
> heavier-duty features like formulas and equations, all of the simple markup
> languages allow the author to drop down to LaTeX and lay out formulas to
> their heart's content.


this is on Pillar roadmap as well: http://www.smalltalkhub.com/#!/~Pier/Pillar

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] Integration process in presence of "external" project

[Thierry Goubier]

Le 22/04/2015 10:26, Andrei Chis a écrit :



On Wed, Apr 22, 2015 at 7:47 AM, stepharo mailto:steph...@free.fr>> wrote:

Esteban
I was thinking about the following this night.

While I understand that we want configuration only it will slow us
down like hell.

Example
with guille we wanted to fix a problem (I do not remember which one)
we need a change to be done in rubric so we will have to publish the
change in rubric repo
 - (find it and add it) so the rubric repo should be there before
 - then one guy of rubric should have a look
 - then merge
 - then publish an issue with a configuration
 - then only then we can work
 => result why do we need sync for me and guille to continue to
work???
 => what if Alain in on vacation?
 we stop working?
 => Remember: We did Pharo especially because people in squeak
did not want that we change
 packages.

Alternate process
 - we do a fix we publish it in Pharo and yes this touches
Rubric and
 - we  integrate it in Pharo head
 - then the guy from rubric merge in their trunk when they want.
 it should be part of the their process to merge always with
pharo trunk
 - At that point they can report a problem
 - then they produce at their speed a new configuration
 - then we integrate when ready their change


This kind of process will be a pain for those that have to merge the
changes back to their repos.
I did this for a while when I was synching the debugger repo with Pharo
and even if I only had to merge maybe one slice a day it was kind of
annoying.


The thing is, if you are not doing it, you're asking someone else to do 
it for you.


So, some of the possibilities are:

- Decouple a bit upstream from Pharo/main, not merging everything from 
there immediately. Wait to see the fixes and changes to stabilize, then 
extract and merge.


- Wait for Pharo/main to pushes fixes to you upstream. So that 
Pharo/main has a duty of collecting the changes, making them all in a 
nice pack, and send them your way.


A good thing is to adjust the process so that pushing things back and 
forth is easing the task of everybody involved (motivation!).


For example, if an hypothetical Stef (not the true one :)) is changing 
and fixing things in Rubric inside Pharo/main, it will make merging 
Rubric newest version harder. So, a good thing would be to make that 
hypothetical Stef in charge of merging the new Rubric version as well. 
If he finds it a pain, then he will ease his tasks by sending his fixes 
nicely packaged to the Rubric maintainer, so that the Rubric manager can 
merge that with the newest version and send it back to Pharo/main for 
integration by our hypothetical Stef :)


However, it would be allways possible for an external project to make it 
easier to fix in their project directly than in Pharo/main, but for that 
they need to be very reactive (make sure that fixes are propagated back 
very fast in Pharo/main) and make the process as easy as possible for an 
external contributor...


Note that, in such a process, having good tools count. This is one of 
the reasons for using places like bitbucket or github: they do really 
support that kind of process (pull requests, branches, issues, 
server-based merge and CI check, etc...). We could recreate that with 
http repositories, but with a significant amount of work.


Regards,

Thierry



Cheers,
Andrei


Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[Thierry Goubier]

Le 22/04/2015 10:21, Andrei Chis a écrit :



On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano mailto:esteba...@gmail.com>> wrote:

in fact I just checked and Versioner already does that: right button
on monticello over a configuration gives you a: “create
development/release version”.
So only thing we need is to use the tools we already created :)


But this only works for releasing simple configurations that do not
depend on other configurations.
This would work for rubric, for example, but not for other
configurations we have in gtools.


I believe GTTools is certainly a poster case for trying to make that 
process simpler.


I would really be interested to see how a combination of simpler 
configurations, baselines, tags and branches would look. A kind of 
hierarchical modeling where you only have configurations at the moment.


Thierry




Cheers,
Andrei


 > On 22 Apr 2015, at 08:50, Esteban Lorenzano mailto:esteba...@gmail.com>> wrote:
 >
 > and btw… of course I agree repositories need to be added, and
configurations kept in image.
 >
 > cheers,
 > Esteban
 >
 >> On 22 Apr 2015, at 08:34, Esteban Lorenzano mailto:esteba...@gmail.com>> wrote:
 >>
 >> I disagree with your proposal.
 >> It will be a mess, nobody will merge (because there will be no
point on doing it) and we will not move out from a monolithic system.
 >> What I propose is not an invention, is how big projects work…
what you have to take into account is that any project under the
Pharo umbrella does not have an owner, but a maintainer. That means
if Alan is on vacation or he does not has the time to do the new
configuration, anyone can doit.
 >>
 >> Yes, it can look slow, but that is because you are too used to
the old workflow, and because right now system is not modular.
 >> The method I propose will enhance modularity (while the older
will, at least, not help), which means with time, changes will be
applied just in one module and not along the full system like now.
 >>
 >> Of course with proper tools this will be faster, but I very much
prefer people telling me “I need this” (that’s why I did the
integrator app, and modified the monkey to take and validate
configurations), and we do it, that we abandon our pursuit of
modularity because is uncomfortable at the beginning.
 >>
 >> We can modify also monticello or versioner (better monticello
because everything will be closer, but  using versioner API) to do a
“save new version” which would be more or less the same as a slice,
but for a configuration, and it will:
 >>
 >> - save the packages associated to the configuration
 >> - create a new version
 >> - save the new configuration
 >>
 >> this will not be to much work (I think I can have it in a couple
of days), it will help the process (because eventually everything
should be managed through configurations (or PPM configurations),
and it will allow us to keep a process that is better and validated..
 >>
 >> TL;DR: Better enhance the tools than drop the process.
 >>
 >> Esteban
 >>
 >>> On 22 Apr 2015, at 07:47, stepharo mailto:steph...@free.fr>> wrote:
 >>>
 >>> Esteban
 >>> I was thinking about the following this night.
 >>>
 >>> While I understand that we want configuration only it will slow
us down like hell.
 >>>
 >>> Example
 >>> with guille we wanted to fix a problem (I do not remember which
one)
 >>> we need a change to be done in rubric so we will have to
publish the change in rubric repo
 >>>  - (find it and add it) so the rubric repo should be there before
 >>>  - then one guy of rubric should have a look
 >>>  - then merge
 >>>  - then publish an issue with a configuration
 >>>  - then only then we can work
 >>>  => result why do we need sync for me and guille to continue to
work???
 >>>  => what if Alain in on vacation?
 >>>  we stop working?
 >>>  => Remember: We did Pharo especially because people in squeak
did not want that we change
 >>>  packages.
 >>>
 >>> Alternate process
 >>>  - we do a fix we publish it in Pharo and yes this touches
Rubric and
 >>>  - we  integrate it in Pharo head
 >>>  - then the guy from rubric merge in their trunk when they want.
 >>>  it should be part of the their process to merge always
with pharo trunk
 >>>  - At that point they can report a problem
 >>>  - then they produce at their speed a new configuration
 >>>  - then we integrate when ready their change
 >>>
 >>>
 >>> Stef
 >>>
 >>>
 >>
 >

Re: [Pharo-dev] Integration process in presence of "external" project

[Guillermo Polito]

Well, I agree with Esteban and Thierry in the fact that making our lives
easier to manage now by pushing changes into the Pharo/main branch will
make things harder in the long run.

I think we can see this as a case of two dependent configurations

ConfigurationOfPharo (which does not exist but as the ad-hoc list of
packages in Pharo/main)

ConfigurationOfRubric  => depends on ConfigurationOfPharo

Stef, I'd manage it like this:

 - push the change we have into rubric
 - open an issue number X asking for the integration of rubric with that
feature
 - open an issue Y that depends on X with the other slice of changes

And here the main problem that we will have is that if we do not integrate
quickly these fixes, then slices can age and become not valid.

Alternatively, we can do it in several steps, avoiding the dependency:

 - push the change into rubric
 - push the part of the change into pharo that does not break the current
version of rubric (avoid the renames/removals of methods)
 - when both are integrated we do the last step that integrates the last
set of changes


El mié., 22 de abr. de 2015 a la(s) 11:15 a. m., Thierry Goubier <
thierry.goub...@gmail.com> escribió:

> Le 22/04/2015 10:21, Andrei Chis a écrit :
> >
> >
> > On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano  > > wrote:
> >
> > in fact I just checked and Versioner already does that: right button
> > on monticello over a configuration gives you a: “create
> > development/release version”.
> > So only thing we need is to use the tools we already created :)
> >
> >
> > But this only works for releasing simple configurations that do not
> > depend on other configurations.
> > This would work for rubric, for example, but not for other
> > configurations we have in gtools.
>
> I believe GTTools is certainly a poster case for trying to make that
> process simpler.
>
> I would really be interested to see how a combination of simpler
> configurations, baselines, tags and branches would look. A kind of
> hierarchical modeling where you only have configurations at the moment.
>
> Thierry
>
>
> >
> > Cheers,
> > Andrei
> >
> >
> >  > On 22 Apr 2015, at 08:50, Esteban Lorenzano  > > wrote:
> >  >
> >  > and btw… of course I agree repositories need to be added, and
> > configurations kept in image.
> >  >
> >  > cheers,
> >  > Esteban
> >  >
> >  >> On 22 Apr 2015, at 08:34, Esteban Lorenzano  > > wrote:
> >  >>
> >  >> I disagree with your proposal.
> >  >> It will be a mess, nobody will merge (because there will be no
> > point on doing it) and we will not move out from a monolithic system.
> >  >> What I propose is not an invention, is how big projects work…
> > what you have to take into account is that any project under the
> > Pharo umbrella does not have an owner, but a maintainer. That means
> > if Alan is on vacation or he does not has the time to do the new
> > configuration, anyone can doit.
> >  >>
> >  >> Yes, it can look slow, but that is because you are too used to
> > the old workflow, and because right now system is not modular.
> >  >> The method I propose will enhance modularity (while the older
> > will, at least, not help), which means with time, changes will be
> > applied just in one module and not along the full system like now.
> >  >>
> >  >> Of course with proper tools this will be faster, but I very much
> > prefer people telling me “I need this” (that’s why I did the
> > integrator app, and modified the monkey to take and validate
> > configurations), and we do it, that we abandon our pursuit of
> > modularity because is uncomfortable at the beginning.
> >  >>
> >  >> We can modify also monticello or versioner (better monticello
> > because everything will be closer, but  using versioner API) to do a
> > “save new version” which would be more or less the same as a slice,
> > but for a configuration, and it will:
> >  >>
> >  >> - save the packages associated to the configuration
> >  >> - create a new version
> >  >> - save the new configuration
> >  >>
> >  >> this will not be to much work (I think I can have it in a couple
> > of days), it will help the process (because eventually everything
> > should be managed through configurations (or PPM configurations),
> > and it will allow us to keep a process that is better and validated..
> >  >>
> >  >> TL;DR: Better enhance the tools than drop the process.
> >  >>
> >  >> Esteban
> >  >>
> >  >>> On 22 Apr 2015, at 07:47, stepharo  > > wrote:
> >  >>>
> >  >>> Esteban
> >  >>> I was thinking about the following this night.
> >  >>>
> >  >>> While I understand that we want configuration only it will slow
> > us down li

Re: [Pharo-dev] Integration process in presence of "external" project

[Esteban Lorenzano]

> On 22 Apr 2015, at 10:21, Andrei Chis  wrote:
> 
> But this only works for releasing simple configurations that do not depend on 
> other configurations.
> This would work for rubric, for example, but not for other configurations we 
> have in gtools.

then you have two options: 

1) you rewrite your configurations to not need nested configurations. This is 
not recommendable in huge projects like Seaside, but things like GTools are 
easily (I did a quick check and your 3 configurations have in total 7 packages… 
would not be a problem to have them without nesting projects and just using the 
packages).  In fact, this is how Dale recommends using configurations (if I 
understood him right).
2) we enhance the tools to also allow the commit of nested packages. 

I think both approaches needs to be done: you don’t need unnecessary complexity 
in your configurations and we need to add some nesting support to commit new 
version. 

What is not admisible, IMO, is to do something that is wrong just because it 
looks easier in the short term (and I say “in short term” because what looks 
easier now will generate a lot of problems in the future). 

cheers, 
Esteban

Re: [Pharo-dev] Integration process in presence of "external" project

[Pavel Krivanek]

And do not forget that with better Pharo modularization it will start
to be a problem on more lower level. When eg. Morphic will be an
"exteranal" Pharo package.

-- Pavel

2015-04-22 12:03 GMT+02:00 Esteban Lorenzano :
>
> On 22 Apr 2015, at 10:21, Andrei Chis  wrote:
>
> But this only works for releasing simple configurations that do not depend
> on other configurations.
> This would work for rubric, for example, but not for other configurations we
> have in gtools.
>
>
> then you have two options:
>
> 1) you rewrite your configurations to not need nested configurations. This
> is not recommendable in huge projects like Seaside, but things like GTools
> are easily (I did a quick check and your 3 configurations have in total 7
> packages… would not be a problem to have them without nesting projects and
> just using the packages).  In fact, this is how Dale recommends using
> configurations (if I understood him right).
> 2) we enhance the tools to also allow the commit of nested packages.
>
> I think both approaches needs to be done: you don’t need unnecessary
> complexity in your configurations and we need to add some nesting support to
> commit new version.
>
> What is not admisible, IMO, is to do something that is wrong just because it
> looks easier in the short term (and I say “in short term” because what looks
> easier now will generate a lot of problems in the future).
>
> cheers,
> Esteban

Re: [Pharo-dev] Integration process in presence of "external" project

[Esteban Lorenzano]

exactly.
what we need in the long term is a complete better integration process. 
I dream to have a git pharo project with submodules and pull requests. 

Slowly the tools are coming, but this will take time to implement. 
In the mean time, we need to do all the steps we can to allow us to achieve the 
modularisation goal. 
Even if they look not easy because we are still building it, or too used to 
previous ways of doing it. 

Esteban

> On 22 Apr 2015, at 12:15, Pavel Krivanek  wrote:
> 
> And do not forget that with better Pharo modularization it will start
> to be a problem on more lower level. When eg. Morphic will be an
> "exteranal" Pharo package.
> 
> -- Pavel
> 
> 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano :
>> 
>> On 22 Apr 2015, at 10:21, Andrei Chis  wrote:
>> 
>> But this only works for releasing simple configurations that do not depend
>> on other configurations.
>> This would work for rubric, for example, but not for other configurations we
>> have in gtools.
>> 
>> 
>> then you have two options:
>> 
>> 1) you rewrite your configurations to not need nested configurations. This
>> is not recommendable in huge projects like Seaside, but things like GTools
>> are easily (I did a quick check and your 3 configurations have in total 7
>> packages… would not be a problem to have them without nesting projects and
>> just using the packages).  In fact, this is how Dale recommends using
>> configurations (if I understood him right).
>> 2) we enhance the tools to also allow the commit of nested packages.
>> 
>> I think both approaches needs to be done: you don’t need unnecessary
>> complexity in your configurations and we need to add some nesting support to
>> commit new version.
>> 
>> What is not admisible, IMO, is to do something that is wrong just because it
>> looks easier in the short term (and I say “in short term” because what looks
>> easier now will generate a lot of problems in the future).
>> 
>> cheers,
>> Esteban
> 

Re: [Pharo-dev] QualityAssistant v0.4

[Esteban Lorenzano]

this is so good. 
what about integrate it to Pharo?

cheers,
Esteban

> On 22 Apr 2015, at 08:58, Yuriy Tymchuk  wrote:
> 
> Hi everyone!
> 
> Probably most of you know, that I am developing a tool called 
> QualityAssistant, which displays current critics about your code in 
> SystemBrowser, Inspector and Spotter.
> 
> I’m happy to tell you that there is a new release v0.4 which does not require 
> you to do any previous setup! Just load it from configuration browser (pharo 
> 4 & 5) and it will start giving you feedback. More details can be found here: 
> https://github.com/Uko/QualityAssistant#quality-assistant-beta- 
> . If you are 
> upgrading from older version, it is recommended to load QualityAssistant into 
> a fresh image, because multiple announcement and process changes may cause 
> exceptions in old objects.
> 
> Even if you are an experienced programmer you can find QualityAssistant 
> useful for instantly spotting typos or making sure that you didn’t forget 
> some details about your code.
> 
> Please give me a feedback about your experience, as I want to make it even 
> more useful. Either write me an email, or open an entry at: 
> https://github.com/Uko/QualityAssistant/issues 
> 
> 
> Have a nice week!
> Uko
> 
> 

Re: [Pharo-dev] Improving the documentation model

[Sean P. DeNigris]

Damien Cassou-2 wrote
> what I don't like about WYSIWYG word processors is that they hide the
> content. I want to control my content. I want to immediately see if a
> line is a section title (semantically) or if it's just bold and huge. I
> want to immediately see if a section title is automatically numbered or
> if the number was written manually.
> ...
>> And actually, the WYSIWYG approach is much closer to HTML 1.0 (in the
>> sense
>> that, users have to indicate *semantic* intentions like emphasis by
>> selecting different fonts, versus something like HTML 4/5, where the
>> actual
>> intention is declared (EMPH tags, QUOTE tags, etc).
> I agree that this is a very important point.

These are very valid critiques of current non-OOP, pink plane approaches,
but in fact there is no inherent conflict between WYSIWYG and e.g. Pillar.
If we start from our intentions, either from the list I started or your own,
it's easy to see how to have it all. Yes, in a rich text editor, one doesn't
know if it's just "bold and big" or a section title. But we are not talking
about jerry rigging a generic editor such as Word to do something for which
it was never intended. We could, as a start, and an easy bridge between the
two POVs, create a Pillar WYSIWYG editor, where the only options are
semantic. So the menu choice/button/whatever would be all domain related, so
when you saw "big and bold", you would be confident that it was just a
visual cue for a section title, which is important because visual thinking
is an important process - and separate from the intellectual processing of
syntax. Making a richer interface does not have to mean giving anything up.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Improving-the-documentation-model-tp4820814p4821107.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] QualityAssistant v0.4

[Cyril Ferlicot]

Good job ! :D
Really usefull

On 22 April 2015 at 12:23, Esteban Lorenzano  wrote:
> this is so good.
> what about integrate it to Pharo?
>
> cheers,
> Esteban
>
> On 22 Apr 2015, at 08:58, Yuriy Tymchuk  wrote:
>
> Hi everyone!
>
> Probably most of you know, that I am developing a tool called
> QualityAssistant, which displays current critics about your code in
> SystemBrowser, Inspector and Spotter.
>
> I’m happy to tell you that there is a new release v0.4 which does not
> require you to do any previous setup! Just load it from configuration
> browser (pharo 4 & 5) and it will start giving you feedback. More details
> can be found here:
> https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you are
> upgrading from older version, it is recommended to load QualityAssistant
> into a fresh image, because multiple announcement and process changes may
> cause exceptions in old objects.
>
> Even if you are an experienced programmer you can find QualityAssistant
> useful for instantly spotting typos or making sure that you didn’t forget
> some details about your code.
>
> Please give me a feedback about your experience, as I want to make it even
> more useful. Either write me an email, or open an entry at:
> https://github.com/Uko/QualityAssistant/issues
>
> Have a nice week!
> Uko
>
> 
>
>



-- 
Cheers
Cyril Ferlicot

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Yuriy Tymchuk]

I am definitely interested in it. Let me know what I should do for this.

I haven’t got a lot of feedback from users, but I fixed problems reported by my 
group and Alex Bergel. The remaining reported issues are quite minor and 
related to how SmallLint works. Changes to SmallLint will arrive later after I 
figure out what the rules are about and what is the way to improve them.

Cheers,
Uko


> On 22 Apr 2015, at 12:23, Esteban Lorenzano  wrote:
> 
> this is so good. 
> what about integrate it to Pharo?
> 
> cheers,
> Esteban
> 
>> On 22 Apr 2015, at 08:58, Yuriy Tymchuk > > wrote:
>> 
>> Hi everyone!
>> 
>> Probably most of you know, that I am developing a tool called 
>> QualityAssistant, which displays current critics about your code in 
>> SystemBrowser, Inspector and Spotter.
>> 
>> I’m happy to tell you that there is a new release v0.4 which does not 
>> require you to do any previous setup! Just load it from configuration 
>> browser (pharo 4 & 5) and it will start giving you feedback. More details 
>> can be found here: 
>> https://github.com/Uko/QualityAssistant#quality-assistant-beta- 
>> . If you 
>> are upgrading from older version, it is recommended to load QualityAssistant 
>> into a fresh image, because multiple announcement and process changes may 
>> cause exceptions in old objects.
>> 
>> Even if you are an experienced programmer you can find QualityAssistant 
>> useful for instantly spotting typos or making sure that you didn’t forget 
>> some details about your code.
>> 
>> Please give me a feedback about your experience, as I want to make it even 
>> more useful. Either write me an email, or open an entry at: 
>> https://github.com/Uko/QualityAssistant/issues 
>> 
>> 
>> Have a nice week!
>> Uko
>> 
>> 
> 
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Re: [Pharo-dev] TDD and BDD

[Sean P. DeNigris]

Miguel Moquillon wrote
>> In summary, the intent of BDD is to be "TDD Done Right".
> I don't agreed with your assumption: there is a difference 
> philosophically both in theory and in practice.

In actuality, it is a bit overstated, because one key insight of BDD was to
bring /all/ stakeholders into TDD. "In order that... as a... I want..." was
intended as a way to have the customer write a spec that would become an
executable part of the test framework. But, they're also not as totally
independent as you describe. In fact, Dan North, the inventor of BDD has
explained it such - that BDD = TDD if your whole team are programmers, but
BDD includes: TDD if the stakeholders include non-programmers.



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

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[kilon alios]

you definetly got feedback from me with one feature request you did not
reply ;)


On Wed, Apr 22, 2015 at 2:00 PM Yuriy Tymchuk  wrote:

> I am definitely interested in it. Let me know what I should do for this.
>
> I haven’t got a lot of feedback from users, but I fixed problems reported
> by my group and Alex Bergel. The remaining reported issues are quite minor
> and related to how SmallLint works. Changes to SmallLint will arrive later
> after I figure out what the rules are about and what is the way to improve
> them.
>
> Cheers,
> Uko
>
>
> On 22 Apr 2015, at 12:23, Esteban Lorenzano  wrote:
>
> this is so good.
> what about integrate it to Pharo?
>
> cheers,
> Esteban
>
> On 22 Apr 2015, at 08:58, Yuriy Tymchuk  wrote:
>
> Hi everyone!
>
> Probably most of you know, that I am developing a tool called
> QualityAssistant, which displays current critics about your code in
> SystemBrowser, Inspector and Spotter.
>
> I’m happy to tell you that there is a new release v0.4 which does not
> require you to do any previous setup! Just load it from configuration
> browser (pharo 4 & 5) and it will start giving you feedback. More details
> can be found here:
> https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you
> are upgrading from older version, it is recommended to load
> QualityAssistant into a fresh image, because multiple announcement and
> process changes may cause exceptions in old objects.
>
> Even if you are an experienced programmer you can find QualityAssistant
> useful for instantly spotting typos or making sure that you didn’t forget
> some details about your code.
>
> Please give me a feedback about your experience, as I want to make it even
> more useful. Either write me an email, or open an entry at:
> https://github.com/Uko/QualityAssistant/issues
>
> Have a nice week!
> Uko
>
> 
>
>
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Damien Cassou]

kilon alios  writes:

> you definetly got feedback from me with one feature request you did not
> reply ;)

same from me: in my opinion, the notifications should not be part of the
code browser because we can also code in the inspector and the debugger.
I think they should appear at the bottom of the Pharo window.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] Improving the documentation model

[Damien Cassou]

Sean P. DeNigris  writes:

> Damien Cassou-2 wrote
>> what I don't like about WYSIWYG word processors is that they hide the
>> content. I want to control my content. I want to immediately see if a
>> line is a section title (semantically) or if it's just bold and huge. I
>> want to immediately see if a section title is automatically numbered or
>> if the number was written manually.
>> ...
>>> And actually, the WYSIWYG approach is much closer to HTML 1.0 (in the
>>> sense
>>> that, users have to indicate *semantic* intentions like emphasis by
>>> selecting different fonts, versus something like HTML 4/5, where the
>>> actual
>>> intention is declared (EMPH tags, QUOTE tags, etc).
>> I agree that this is a very important point.
>
> These are very valid critiques of current non-OOP, pink plane approaches,
> but in fact there is no inherent conflict between WYSIWYG and e.g. Pillar.
> If we start from our intentions, either from the list I started or your own,
> it's easy to see how to have it all. Yes, in a rich text editor, one doesn't
> know if it's just "bold and big" or a section title. But we are not talking
> about jerry rigging a generic editor such as Word to do something for which
> it was never intended. We could, as a start, and an easy bridge between the
> two POVs, create a Pillar WYSIWYG editor, where the only options are
> semantic. So the menu choice/button/whatever would be all domain related, so
> when you saw "big and bold", you would be confident that it was just a
> visual cue for a section title, which is important because visual thinking
> is an important process - and separate from the intellectual processing of
> syntax. Making a richer interface does not have to mean giving anything up.

ok for me.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] Integration process in presence of "external" project

[Andrei Chis]

In all new tools that we did we tried to have only 2-3 packages and use
tags to organize classes in a packaged (GT-* has 9 packages for 3 projects).
This allows for very simple configurations with clear dependencies.
Glamour has more packages (17) but those should also be reduced, as we do
not need such a low level of granularity.

Given that support for working with multiple nested configuration is not
great we can merge all GT-* projects into one configuration.
I would still like to have different configurations for Glamour and Rubric
as they are separate projects.
So we can have just three configurations (each one for a separate project
that can be released independent of the others):

ConfigurationOfGToolkitCore
> ConfigurationOfGlamourCore
-> ConfigurationOfRubric

This would make releasing a new version easier with the current support
from versioner.
Releasing a version for all three configurations at once would still
require some manual updating of versions, but that's a less frequent
use-case.

Cheers,
Andrei


On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano 
wrote:

> exactly.
> what we need in the long term is a complete better integration process.
> I dream to have a git pharo project with submodules and pull requests.
>
> Slowly the tools are coming, but this will take time to implement.
> In the mean time, we need to do all the steps we can to allow us to
> achieve the modularisation goal.
> Even if they look not easy because we are still building it, or too used
> to previous ways of doing it.
>
> Esteban
>
> > On 22 Apr 2015, at 12:15, Pavel Krivanek 
> wrote:
> >
> > And do not forget that with better Pharo modularization it will start
> > to be a problem on more lower level. When eg. Morphic will be an
> > "exteranal" Pharo package.
> >
> > -- Pavel
> >
> > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano :
> >>
> >> On 22 Apr 2015, at 10:21, Andrei Chis 
> wrote:
> >>
> >> But this only works for releasing simple configurations that do not
> depend
> >> on other configurations.
> >> This would work for rubric, for example, but not for other
> configurations we
> >> have in gtools.
> >>
> >>
> >> then you have two options:
> >>
> >> 1) you rewrite your configurations to not need nested configurations.
> This
> >> is not recommendable in huge projects like Seaside, but things like
> GTools
> >> are easily (I did a quick check and your 3 configurations have in total
> 7
> >> packages… would not be a problem to have them without nesting projects
> and
> >> just using the packages).  In fact, this is how Dale recommends using
> >> configurations (if I understood him right).
> >> 2) we enhance the tools to also allow the commit of nested packages.
> >>
> >> I think both approaches needs to be done: you don’t need unnecessary
> >> complexity in your configurations and we need to add some nesting
> support to
> >> commit new version.
> >>
> >> What is not admisible, IMO, is to do something that is wrong just
> because it
> >> looks easier in the short term (and I say “in short term” because what
> looks
> >> easier now will generate a lot of problems in the future).
> >>
> >> cheers,
> >> Esteban
> >
>
>
>

Re: [Pharo-dev] Integration process in presence of "external" project

[Andrei Chis]

On Wed, Apr 22, 2015 at 11:15 AM, Thierry Goubier  wrote:

> Le 22/04/2015 10:21, Andrei Chis a écrit :
>
>>
>>
>> On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano > > wrote:
>>
>> in fact I just checked and Versioner already does that: right button
>> on monticello over a configuration gives you a: “create
>> development/release version”.
>> So only thing we need is to use the tools we already created :)
>>
>>
>> But this only works for releasing simple configurations that do not
>> depend on other configurations.
>> This would work for rubric, for example, but not for other
>> configurations we have in gtools.
>>
>
> I believe GTTools is certainly a poster case for trying to make that
> process simpler.
>
> I would really be interested to see how a combination of simpler
> configurations, baselines, tags and branches would look. A kind of
> hierarchical modeling where you only have configurations at the moment.


One *issue* with GTools is that they still go through a lot of changes.
They are far from their final version :).
For a stable project (for example Zinc) where bugs/features are less
frequent one only needs to integrate once in a while.
This makes working with configurations very easy: there were no complaints
about this process until GTools.

With GTools we need to develop and integrate at a fastest rate.
Still, developing and integrating GTools into pharo just by using slices
and merging commits from Pharo back to the projects' repos would take a lot
of effort.
Right now the problem with configurations is that it takes time from when a
fix is available until it is integrated. Still, until now, with one
exception, we more
or less, sync with pharo quite often.

Reducing the number of configurations, offering a one click solution for
releasing a new version, plus a tool that show a diff for a configuration
would make this  process quite easy.

Cheers,
Andrei


>
> Thierry
>
>
>
>> Cheers,
>> Andrei
>>
>>
>>  > On 22 Apr 2015, at 08:50, Esteban Lorenzano > > wrote:
>>  >
>>  > and btw… of course I agree repositories need to be added, and
>> configurations kept in image.
>>  >
>>  > cheers,
>>  > Esteban
>>  >
>>  >> On 22 Apr 2015, at 08:34, Esteban Lorenzano > > wrote:
>>  >>
>>  >> I disagree with your proposal.
>>  >> It will be a mess, nobody will merge (because there will be no
>> point on doing it) and we will not move out from a monolithic system.
>>  >> What I propose is not an invention, is how big projects work…
>> what you have to take into account is that any project under the
>> Pharo umbrella does not have an owner, but a maintainer. That means
>> if Alan is on vacation or he does not has the time to do the new
>> configuration, anyone can doit.
>>  >>
>>  >> Yes, it can look slow, but that is because you are too used to
>> the old workflow, and because right now system is not modular.
>>  >> The method I propose will enhance modularity (while the older
>> will, at least, not help), which means with time, changes will be
>> applied just in one module and not along the full system like now.
>>  >>
>>  >> Of course with proper tools this will be faster, but I very much
>> prefer people telling me “I need this” (that’s why I did the
>> integrator app, and modified the monkey to take and validate
>> configurations), and we do it, that we abandon our pursuit of
>> modularity because is uncomfortable at the beginning.
>>  >>
>>  >> We can modify also monticello or versioner (better monticello
>> because everything will be closer, but  using versioner API) to do a
>> “save new version” which would be more or less the same as a slice,
>> but for a configuration, and it will:
>>  >>
>>  >> - save the packages associated to the configuration
>>  >> - create a new version
>>  >> - save the new configuration
>>  >>
>>  >> this will not be to much work (I think I can have it in a couple
>> of days), it will help the process (because eventually everything
>> should be managed through configurations (or PPM configurations),
>> and it will allow us to keep a process that is better and validated..
>>  >>
>>  >> TL;DR: Better enhance the tools than drop the process.
>>  >>
>>  >> Esteban
>>  >>
>>  >>> On 22 Apr 2015, at 07:47, stepharo > > wrote:
>>  >>>
>>  >>> Esteban
>>  >>> I was thinking about the following this night.
>>  >>>
>>  >>> While I understand that we want configuration only it will slow
>> us down like hell.
>>  >>>
>>  >>> Example
>>  >>> with guille we wanted to fix a problem (I do not remember which
>> one)
>>  >>> we need a change to be done in rubric so we will have to
>> publish the change in rubric

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Yuriy Tymchuk]

I’m terribly sorry Kilon, because I can not recall it, neither can I find it. 
Can you please tell it again?

Uko


> On 22 Apr 2015, at 13:29, kilon alios  wrote:
> 
> you definetly got feedback from me with one feature request you did not reply 
> ;)
> 
> 
> On Wed, Apr 22, 2015 at 2:00 PM Yuriy Tymchuk  > wrote:
> I am definitely interested in it. Let me know what I should do for this.
> 
> I haven’t got a lot of feedback from users, but I fixed problems reported by 
> my group and Alex Bergel. The remaining reported issues are quite minor and 
> related to how SmallLint works. Changes to SmallLint will arrive later after 
> I figure out what the rules are about and what is the way to improve them.
> 
> Cheers,
> Uko
> 
> 
> 
>> On 22 Apr 2015, at 12:23, Esteban Lorenzano > > wrote:
>> 
> 
>> this is so good. 
>> what about integrate it to Pharo?
>> 
>> cheers,
>> Esteban
>> 
>>> On 22 Apr 2015, at 08:58, Yuriy Tymchuk >> > wrote:
>>> 
>>> Hi everyone!
>>> 
>>> Probably most of you know, that I am developing a tool called 
>>> QualityAssistant, which displays current critics about your code in 
>>> SystemBrowser, Inspector and Spotter.
>>> 
>>> I’m happy to tell you that there is a new release v0.4 which does not 
>>> require you to do any previous setup! Just load it from configuration 
>>> browser (pharo 4 & 5) and it will start giving you feedback. More details 
>>> can be found here: 
>>> https://github.com/Uko/QualityAssistant#quality-assistant-beta- 
>>> . If you 
>>> are upgrading from older version, it is recommended to load 
>>> QualityAssistant into a fresh image, because multiple announcement and 
>>> process changes may cause exceptions in old objects.
>>> 
>>> Even if you are an experienced programmer you can find QualityAssistant 
>>> useful for instantly spotting typos or making sure that you didn’t forget 
>>> some details about your code.
>>> 
>>> Please give me a feedback about your experience, as I want to make it even 
>>> more useful. Either write me an email, or open an entry at: 
>>> https://github.com/Uko/QualityAssistant/issues 
>>> 
>>> 
>>> Have a nice week!
>>> Uko
>>> 
>>> 
>> 
> 
>> ___
>> Moose-dev mailing list
>> moose-...@iam.unibe.ch 
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
>> 
> 

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Tudor Girba]

I think that feedback should be as close as possible to the place it
relates to :)

Doru

On Wed, Apr 22, 2015 at 2:19 PM, Damien Cassou 
wrote:

>
> kilon alios  writes:
>
> > you definetly got feedback from me with one feature request you did not
> > reply ;)
>
> same from me: in my opinion, the notifications should not be part of the
> code browser because we can also code in the inspector and the debugger.
> I think they should appear at the bottom of the Pharo window.
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Fabrizio Perin]

2015-04-22 14:52 GMT+02:00 Tudor Girba :

> I think that feedback should be as close as possible to the place it
> relates to :)
>
>
+1

Re: [Pharo-dev] QualityAssistant v0.4

[Tudor Girba]

Hi,

I only took a brief look, but I think that reaching the no-input-required
situation is a major step forward.

Nice job. Keep it up.

Cheers,
Doru


On Wed, Apr 22, 2015 at 8:58 AM, Yuriy Tymchuk  wrote:

> Hi everyone!
>
> Probably most of you know, that I am developing a tool called
> QualityAssistant, which displays current critics about your code in
> SystemBrowser, Inspector and Spotter.
>
> I’m happy to tell you that there is a new release v0.4 which does not
> require you to do any previous setup! Just load it from configuration
> browser (pharo 4 & 5) and it will start giving you feedback. More details
> can be found here:
> https://github.com/Uko/QualityAssistant#quality-assistant-beta-. If you
> are upgrading from older version, it is recommended to load
> QualityAssistant into a fresh image, because multiple announcement and
> process changes may cause exceptions in old objects.
>
> Even if you are an experienced programmer you can find QualityAssistant
> useful for instantly spotting typos or making sure that you didn’t forget
> some details about your code.
>
> Please give me a feedback about your experience, as I want to make it even
> more useful. Either write me an email, or open an entry at:
> https://github.com/Uko/QualityAssistant/issues
>
> Have a nice week!
> Uko
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Yuriy Tymchuk]

> On 22 Apr 2015, at 14:19, Damien Cassou  wrote:
> 
> 
> kilon alios  writes:
> 
>> you definetly got feedback from me with one feature request you did not
>> reply ;)
> 
> same from me: in my opinion, the notifications should not be part of the
> code browser because we can also code in the inspector and the debugger.
> I think they should appear at the bottom of the Pharo window.

I remember this request, Damien. After it I’ve added also information about 
critics in the inspector and spotter. At the moment I haven’t done anything 
with debugger, but I will definitely look into it.

QualityAssitant was showing global notifications at the beginning, but this 
imposes other kind of problem: how do you deal with many entities that change 
simultaneously? Another example is when you load package with Monticello, as 
code is in fact modified, and you are spammed with notifications.

This is why I decided to step down and now the main goal of QualityAssistant is 
to assure that you can ask each entity about it’s quality and receive the 
critics. Then tools like SystemBrowser, Inspector or Debugger can implement a 
view section that displays this property of an entity.

Current approach does not forbid the creation of global notification system and 
I will work on it, as soon as I’m done with higher priority tasks, or we can 
hack something together during ESUG. Your feedback is very important, and while 
you don’t see the requested feature available yet, it has influenced the design 
decisions taken during the development :)

Cheers.
Uko

> 
> -- 
> Damien Cassou
> http://damiencassou.seasidehosting.st
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
> 

Re: [Pharo-dev] QualityAssistant v0.4

[Yuriy Tymchuk]

Thank you Doru.

> On 22 Apr 2015, at 15:00, Tudor Girba  wrote:
> 
> Hi,
> 
> I only took a brief look, but I think that reaching the no-input-required 
> situation is a major step forward.
> 
> Nice job. Keep it up.
> 
> Cheers,
> Doru
> 
> 
> On Wed, Apr 22, 2015 at 8:58 AM, Yuriy Tymchuk  > wrote:
> Hi everyone!
> 
> Probably most of you know, that I am developing a tool called 
> QualityAssistant, which displays current critics about your code in 
> SystemBrowser, Inspector and Spotter.
> 
> I’m happy to tell you that there is a new release v0.4 which does not require 
> you to do any previous setup! Just load it from configuration browser (pharo 
> 4 & 5) and it will start giving you feedback. More details can be found here: 
> https://github.com/Uko/QualityAssistant#quality-assistant-beta- 
> . If you are 
> upgrading from older version, it is recommended to load QualityAssistant into 
> a fresh image, because multiple announcement and process changes may cause 
> exceptions in old objects.
> 
> Even if you are an experienced programmer you can find QualityAssistant 
> useful for instantly spotting typos or making sure that you didn’t forget 
> some details about your code.
> 
> Please give me a feedback about your experience, as I want to make it even 
> more useful. Either write me an email, or open an entry at: 
> https://github.com/Uko/QualityAssistant/issues 
> 
> 
> Have a nice week!
> Uko
> 
> 
> 
> 
> 
> -- 
> www.tudorgirba.com 
> 
> "Every thing has its own flow"

Re: [Pharo-dev] Integration process in presence of "external" project

[Thierry Goubier]

Le 22/04/2015 14:47, Andrei Chis a écrit :



On Wed, Apr 22, 2015 at 11:15 AM, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:

Le 22/04/2015 10:21, Andrei Chis a écrit :



On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano
mailto:esteba...@gmail.com>
>> wrote:

 in fact I just checked and Versioner already does that:
right button
 on monticello over a configuration gives you a: “create
 development/release version”.
 So only thing we need is to use the tools we already created :)


But this only works for releasing simple configurations that do not
depend on other configurations.
This would work for rubric, for example, but not for other
configurations we have in gtools.


I believe GTTools is certainly a poster case for trying to make that
process simpler.

I would really be interested to see how a combination of simpler
configurations, baselines, tags and branches would look. A kind of
hierarchical modeling where you only have configurations at the moment.


One *issue* with GTools is that they still go through a lot of changes.
They are far from their final version :).


Which is perfectly fine by my book; it just makes it a bit more crucial 
to get the process right :)



For a stable project (for example Zinc) where bugs/features are less
frequent one only needs to integrate once in a while.
This makes working with configurations very easy: there were no
complaints about this process until GTools.


Yes, I agree.


With GTools we need to develop and integrate at a fastest rate.
Still, developing and integrating GTools into pharo just by using slices
and merging commits from Pharo back to the projects' repos would take a
lot of effort.


And this is the key of the discussion: we need a way to streamline the 
process to make it easier (and, if possible, avoid changing anciliary 
information such as the configuration as stored in another repository).



Right now the problem with configurations is that it takes time from
when a fix is available until it is integrated. Still, until now, with
one exception, we more
or less, sync with pharo quite often.


You're the test bench :)


Reducing the number of configurations, offering a one click solution for
releasing a new version, plus a tool that show a diff for a
configuration would make this  process quite easy.


What I know is this:

If you manipulate branches and tags (as in git), what you can do is 
delegate part/all of the configuration update to your SCM.


- Write a configuration which targets a BaselineOf and a tag (say 
v2.0.*) in your development repository. Do not write any package 
information in the configuration, write just the package names and 
dependencies in the BaselineOf. From now on, the Configuration will not 
change.


- In that branch, release regular versions, naming them v2.0., as 
often as you like (nobody will bother if you release v2.0.113 :))


- Add as many feature branches you'd like for your internal development, 
merging into the v2 as you want.


- Update the BaselineOf if necessary (adding a new package, changing 
dependencies).


- Ask Pharo to integrate or merge the latest v2.0. (which consist of 
running the ConfigurationOf: nothing less, nothing more)(*).


- Merge back pharo/main stuff if any, packaged as a set of packages (a 
SLICE, why not: a pull request would be easier, but it is not that 
different).


Until you switch branches and main version, you won't change that 
configuration again and you will never have to write (or generate) a 
version with all packages version numbers again.


(*) Does anybody knows if we can use Metacello to merge instead of loading?

Thierry


Cheers,
Andrei


Thierry



Cheers,
Andrei


  > On 22 Apr 2015, at 08:50, Esteban Lorenzano
mailto:esteba...@gmail.com>
 >>
wrote:
  >
  > and btw… of course I agree repositories need to be
added, and
 configurations kept in image.
  >
  > cheers,
  > Esteban
  >
  >> On 22 Apr 2015, at 08:34, Esteban Lorenzano
mailto:esteba...@gmail.com>
 >>
wrote:
  >>
  >> I disagree with your proposal.
  >> It will be a mess, nobody will merge (because there
will be no
 point on doing it) and we will not move out from a
monolithic system.
  >> What I propose is not an invention, is how big projects
work…
 what you have to take into account is that any project
under the
 Pharo umbrella does not have an owner, but a maintainer.
That mea

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Damien Cassou]

Yuriy Tymchuk  writes:

> Current approach does not forbid the creation of global notification system 
> and I will work on it, as soon as I’m done with higher priority tasks, or we 
> can hack something together during ESUG. Your feedback is very important, and 
> while you don’t see the requested feature available yet, it has influenced 
> the design decisions taken during the development :)

:-)

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding accents

[Leo]

Sven
 I saw the tests and they works fine.
The problem is on the field.
I have a form with javascript that gets addresses from Google Maps, then the 
form is submitted to my Pharo-Zinc-App.
When the form is submitted by Safari(OS X), Smalltalks receives the character 
with accent without encoding (no %).
Continuing with the Neuquen example,   the 'accented e’ that should be  %C3%A9 
is received as the raw character.
With Firefox all works fine, the character is received with the correct 
encoding.

So the problem is related to ‘decode:’
In the research I  also saw that some accented characters could be received as 
one character encoded, for example the 'accented e’ could be also %E9.

thanks
Leo


   


> El 21/4/2015, a las 18:26, pharo-dev-requ...@lists.pharo.org escribió:
> 
> Date: Tue, 21 Apr 2015 22:59:52 +0200
> From: Sven Van Caekenberghe mailto:s...@stfx.eu>>
> To: Pharo Development List  >
> Subject: Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding
>   accents
> Message-ID:  >
> Content-Type: text/plain; charset=utf-8
> 
> Leo,
> 
> Are you sure you understand what percent encoding is ?
> 
> Check the class comment of ZnPercentEncoding, it has links to a Wikipedia 
> article.
> 
> Did you see ZnPercentEncoderTests ?
> 
> Anyway, I would think this is what you want to do:
> 
> ZnPercentEncoder new encode: 'Neuqu?n, Neuqu?n Province, Argentina'.
> 
>   => 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'
> 
> ZnPercentEncoder new decode: 
> 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'. 
> 
>   => 'Neuqu?n, Neuqu?n Province, Argentina'
> 
> Seems to work fine, no ?
> 
> What problem do you have with ZnUrl ?
> 
> Sven

Re: [Pharo-dev] QualityAssistant v0.4

[Sean P. DeNigris]

Uko2 wrote
> I am developing a tool called QualityAssistant, which displays current
> critics about your code in SystemBrowser, Inspector and Spotter.

Holy crap - this tool is /Amazing/! It highlights the offending code and
even has a button to fix automatically if possible!!! +1 to integration



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821143.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Johan Fabry]

Hola,

It looks like a really cool tool! I just added it to my LRP development image 
and I plan on using it full time. I am always interested in writing cleaner 
code.

So expect comments from me :-) Actually I already have one:

For one class I got the critic ‘References an abstract class’ and 'Subclass 
responsibility not defined’. Excellent that you found it, but now I have to go 
through all the methods of the class to see where the first critic comes from, 
and through all methods of all leaf classes for the second one. :-( :-( :-( 
That’s a lot of work for me to rescue some information which apparently the 
tool already knows. Please add more information on where the issue is on these 
kinds of errors, so I can fix them more easily ...

Thanks and keep up the good work!

> On Apr 22, 2015, at 03:58, Yuriy Tymchuk  wrote:
> 
> Hi everyone!
> 
> Probably most of you know, that I am developing a tool called 
> QualityAssistant, which displays current critics about your code in 
> SystemBrowser, Inspector and Spotter.
> 
> I’m happy to tell you that there is a new release v0.4 which does not require 
> you to do any previous setup! Just load it from configuration browser (pharo 
> 4 & 5) and it will start giving you feedback. More details can be found here: 
> https://github.com/Uko/QualityAssistant#quality-assistant-beta- 
> . If you are 
> upgrading from older version, it is recommended to load QualityAssistant into 
> a fresh image, because multiple announcement and process changes may cause 
> exceptions in old objects.
> 
> Even if you are an experienced programmer you can find QualityAssistant 
> useful for instantly spotting typos or making sure that you didn’t forget 
> some details about your code.
> 
> Please give me a feedback about your experience, as I want to make it even 
> more useful. Either write me an email, or open an entry at: 
> https://github.com/Uko/QualityAssistant/issues 
> 
> 
> Have a nice week!
> Uko
> 
> 
> ___
> Moose-dev mailing list
> moose-...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[Yuriy Tymchuk]

> On 22 Apr 2015, at 15:59, Johan Fabry  wrote:
> 
> Hola,
> 
> It looks like a really cool tool! I just added it to my LRP development image 
> and I plan on using it full time. I am always interested in writing cleaner 
> code.

Thanks :)

> 
> So expect comments from me :-) Actually I already have one:
> 
> For one class I got the critic ‘References an abstract class’ and 'Subclass 
> responsibility not defined’. Excellent that you found it, but now I have to 
> go through all the methods of the class to see where the first critic comes 
> from, and through all methods of all leaf classes for the second one. :-( :-( 
> :-( That’s a lot of work for me to rescue some information which apparently 
> the tool already knows. Please add more information on where the issue is on 
> these kinds of errors, so I can fix them more easily …

Yes, this is the major issue with SmallLint. If you are interested in details 
here it goes:
for example "References an abstract class” is defined to work on a class, and 
it’s definitely easier to check whether the class is abstract and has any 
references than taking a method getting all class references and checking is 
any class is abstract. But as the result you get a critic about the class and 
not about the methods that access it.

Right now I’m analyzing Small Lint rules to see what issues they have and 
understanding how to approach the problem. Maybe some temporary hack will be 
possible for certain rules, otherwise it will be fixed when I get to improving 
the Small Lint.

Nevertheless your feedback is very important, as I get to know what the real 
issues are.

Cheers,
Uko



> 
> Thanks and keep up the good work!
> 
>> On Apr 22, 2015, at 03:58, Yuriy Tymchuk > > wrote:
>> 
>> Hi everyone!
>> 
>> Probably most of you know, that I am developing a tool called 
>> QualityAssistant, which displays current critics about your code in 
>> SystemBrowser, Inspector and Spotter.
>> 
>> I’m happy to tell you that there is a new release v0.4 which does not 
>> require you to do any previous setup! Just load it from configuration 
>> browser (pharo 4 & 5) and it will start giving you feedback. More details 
>> can be found here: 
>> https://github.com/Uko/QualityAssistant#quality-assistant-beta- 
>> . If you 
>> are upgrading from older version, it is recommended to load QualityAssistant 
>> into a fresh image, because multiple announcement and process changes may 
>> cause exceptions in old objects.
>> 
>> Even if you are an experienced programmer you can find QualityAssistant 
>> useful for instantly spotting typos or making sure that you didn’t forget 
>> some details about your code.
>> 
>> Please give me a feedback about your experience, as I want to make it even 
>> more useful. Either write me an email, or open an entry at: 
>> https://github.com/Uko/QualityAssistant/issues 
>> 
>> 
>> Have a nice week!
>> Uko
>> 
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@iam.unibe.ch 
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> 
> 
> 
> ---> Save our in-boxes! http://emailcharter.org  
> <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry 
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> 

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

[Johan Fabry]

Some weird behavior in quality assistant. Have a look at this method:

duplicateVar: aVarName 

self show: 'Var: ', aVarName, ' redefinition ignored'.

This raises the issue: ‘Use cascaded nextPutAll:’s instead of #, in 
nextPutAll:’ It also pops up the automatic rewrite icon, so I clicked on it to 
see how it would transform the code. Result:

duplicateVar: aVarName
self
show: 'Var: ' , aVarName;
show: ' redefinition ignored'

Needless to say, that’s not a behavior preserving transformation.


> On Apr 22, 2015, at 03:58, Yuriy Tymchuk  wrote:
> 
> Please give me a feedback about your experience, as I want to make it even 
> more useful. Either write me an email, or open an entry at: 
> https://github.com/Uko/QualityAssistant/issues 
> 


---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

[Yuriy Tymchuk]

Good point, this brings up two problems.

1) The rule can improve detection by checking the type is the message is sent 
to self
2) Automatic fixing should display the changes and letting you decide whether 
you want to apply them.

1st will take some time. 2nd will be soon in QA :)

Uko

> On 22 Apr 2015, at 16:33, Johan Fabry  wrote:
> 
> Some weird behavior in quality assistant. Have a look at this method:
> 
> duplicateVar: aVarName 
> 
>   self show: 'Var: ', aVarName, ' redefinition ignored'.
> 
> This raises the issue: ‘Use cascaded nextPutAll:’s instead of #, in 
> nextPutAll:’ It also pops up the automatic rewrite icon, so I clicked on it 
> to see how it would transform the code. Result:
> 
> duplicateVar: aVarName
>   self
>   show: 'Var: ' , aVarName;
>   show: ' redefinition ignored'
> 
> Needless to say, that’s not a behavior preserving transformation.
> 
> 
>> On Apr 22, 2015, at 03:58, Yuriy Tymchuk > > wrote:
>> 
>> Please give me a feedback about your experience, as I want to make it even 
>> more useful. Either write me an email, or open an entry at: 
>> https://github.com/Uko/QualityAssistant/issues 
>> 
> 
> 
> ---> Save our in-boxes! http://emailcharter.org  
> <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry 
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> 

Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding accents

[Sven Van Caekenberghe]

Leo,

I am sorry but you will have to be more specific and concrete. You are mixing 
lots of different things (encoding/decoding, form submit, JS - and there are 
details missing) - there are many places where you could have done something 
wrong.

Please try to isolate your problem with a concrete short piece of code that I 
can run. Something along the lines of ZnDefaultServerDelegate>>formTest[1|2|3]: 
maybe.

Sven

> On 22 Apr 2015, at 15:46, Leo  wrote:
> 
> Sven
>  I saw the tests and they works fine.
> The problem is on the field.
> I have a form with javascript that gets addresses from Google Maps, then the 
> form is submitted to my Pharo-Zinc-App.
> When the form is submitted by Safari(OS X), Smalltalks receives the character 
> with accent without encoding (no %).
> Continuing with the Neuquen example,   the 'accented e’ that should be  
> %C3%A9 is received as the raw character.
> With Firefox all works fine, the character is received with the correct 
> encoding.
> 
> So the problem is related to ‘decode:’
> In the research I  also saw that some accented characters could be received 
> as one character encoded, for example the 'accented e’ could be also %E9.
> 
> thanks
> Leo
> 
> 
>
> 
> 
>> El 21/4/2015, a las 18:26, pharo-dev-requ...@lists.pharo.org escribió:
>> 
>> Date: Tue, 21 Apr 2015 22:59:52 +0200
>> From: Sven Van Caekenberghe 
>> To: Pharo Development List 
>> Subject: Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding
>>  accents
>> Message-ID: 
>> Content-Type: text/plain; charset=utf-8
>> 
>> Leo,
>> 
>> Are you sure you understand what percent encoding is ?
>> 
>> Check the class comment of ZnPercentEncoding, it has links to a Wikipedia 
>> article.
>> 
>> Did you see ZnPercentEncoderTests ?
>> 
>> Anyway, I would think this is what you want to do:
>> 
>> ZnPercentEncoder new encode: 'Neuqu?n, Neuqu?n Province, Argentina'.
>> 
>>  => 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'
>> 
>> ZnPercentEncoder new decode: 
>> 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'. 
>> 
>>  => 'Neuqu?n, Neuqu?n Province, Argentina'
>> 
>> Seems to work fine, no ?
>> 
>> What problem do you have with ZnUrl ?
>> 
>> Sven
> 

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

[Cyril Ferlicot]

Hi !
Your quality assistant say to me "repeated method in the superclass"
(If a class is overriding a method, it should use a different code. Is
meaningless to have a method in a class and in its superclass) but
i've 3 methods into my class and all overrides a method with "^
shouldBeImplemented" in the superclass.
I think something is wrong with this warning :)


On 22 April 2015 at 16:45, Yuriy Tymchuk  wrote:
> Good point, this brings up two problems.
>
> 1) The rule can improve detection by checking the type is the message is
> sent to self
> 2) Automatic fixing should display the changes and letting you decide
> whether you want to apply them.
>
> 1st will take some time. 2nd will be soon in QA :)
>
> Uko
>
>
> On 22 Apr 2015, at 16:33, Johan Fabry  wrote:
>
> Some weird behavior in quality assistant. Have a look at this method:
>
> duplicateVar: aVarName
>
> self show: 'Var: ', aVarName, ' redefinition ignored'.
>
> This raises the issue: ‘Use cascaded nextPutAll:’s instead of #, in
> nextPutAll:’ It also pops up the automatic rewrite icon, so I clicked on it
> to see how it would transform the code. Result:
>
> duplicateVar: aVarName
> self
> show: 'Var: ' , aVarName;
> show: ' redefinition ignored'
>
> Needless to say, that’s not a behavior preserving transformation.
>
>
> On Apr 22, 2015, at 03:58, Yuriy Tymchuk  wrote:
>
> Please give me a feedback about your experience, as I want to make it even
> more useful. Either write me an email, or open an entry at:
> https://github.com/Uko/QualityAssistant/issues
>
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>



-- 
Cheers
Cyril Ferlicot

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/50004
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] bd8aef: 50004

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: bd8aef00a052613d0e0d41065e9d85ee42cf05c8
  
https://github.com/pharo-project/pharo-core/commit/bd8aef00a052613d0e0d41065e9d85ee42cf05c8
  Author: Jenkins Build Server 
  Date:   2015-04-22 (Wed, 22 Apr 2015)

  Changed paths:
M MonticelloGUI.package/MCConfigurationBrowser.class/class/opening/open.st
M MonticelloGUI.package/MCWorkingCopyBrowser.class/class/instance 
creation/open.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script612.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script613.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50003.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50004.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
StartupPreferences.package/StartupPreferencesLoader.class/class/example/example.st
M 
StartupPreferences.package/StartupPreferencesLoader.class/instance/private/buildStreamFor_.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/defaults/defaultAvailableRepositories.st
M 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/example/example.st
A 
Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/initialization/reset.st

  Log Message:
  ---
  50004
15377 StartupLoader leftovers in StartupPreferencesLoader
https://pharo.fogbugz.com/f/cases/15377

15354 Add 

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

[stepharo]

Yuriy this is excellent because it will force us to have
- better rules
- rules with as many as automatic transformations as possible :)

Excellent job.

Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

Ok perfect then I will not work on changes that touch other projects.
I suggest also guille not to try and we should focus on something else 
than in the image.



I disagree with your proposal.
It will be a mess, nobody will merge (because there will be no point on doing 
it) and we will not move out from a monolithic system.
What I propose is not an invention, is how big projects work… what you have to 
take into account is that any project under the Pharo umbrella does not have an 
owner, but a maintainer. That means if Alan is on vacation or he does not has 
the time to do the new configuration, anyone can doit.

Yes, it can look slow, but that is because you are too used to the old 
workflow, and because right now system is not modular.
The method I propose will enhance modularity (while the older will, at least, 
not help), which means with time, changes will be applied just in one module 
and not along the full system like now.

Ok I will let you enhance the modularity because my time is more expensive.
Then when pharo will be modular I will come back.



Of course with proper tools this will be faster, but I very much prefer people 
telling me “I need this” (that’s why I did the integrator app, and modified the 
monkey to take and validate configurations), and we do it, that we abandon our 
pursuit of modularity because is uncomfortable at the beginning.

You mixed everything. Did I talk about abandon our pursuit of modularity.
Now what you are suggesting is that a change that can take 10 min will 
take several days to be done.
From my concentration and energy point of view I will not work under 
such conditions.


May I ask you when is the last time you work on remodularizing Pharo?
Because I can say that I got my share with Guille but if Pharo does not 
respect my time

then no problem I will do something else.




We can modify also monticello or versioner (better monticello because 
everything will be closer, but  using versioner API) to do a “save new version” 
which would be more or less the same as a slice, but for a configuration, and 
it will:

- save the packages associated to the configuration
- create a new version
- save the new configuration

And? I will have to
- enter the repo of the external project
- fight with a configuration of a project that I do not know, - no 
thanks - or all the external project

should work for real with versioner.
- But people will have to look anyway at my changes but in addition 
they will have
a potentially incompatible version (that may be they cannot load in 
there image).





this will not be to much work (I think I can have it in a couple of days), it 
will help the process (because eventually everything should be managed through 
configurations (or PPM configurations), and it will allow us to keep a process 
that is better and validated..

TL;DR: Better enhance the tools than drop the process.
Which process? Right now what you are proposing is just slowly the 
remodularisation
from my point of view. Because if we have to wait (and we already faced 
it) that a change goes in
rubric and in the rubric configuration so that we can ***continue*** to 
work. Then we are dead.
Because other projects not under our control depend on rubric and I will 
not fix any of them.



I'm sorry I will not work on tools. So I will work on my home projects.


Stef




Esteban


On 22 Apr 2015, at 07:47, stepharo  wrote:

Esteban
I was thinking about the following this night.

While I understand that we want configuration only it will slow us down like 
hell.

Example
with guille we wanted to fix a problem (I do not remember which one)
we need a change to be done in rubric so we will have to publish the change in 
rubric repo
- (find it and add it) so the rubric repo should be there before
- then one guy of rubric should have a look
- then merge
- then publish an issue with a configuration
- then only then we can work
=> result why do we need sync for me and guille to continue to work???
=> what if Alain in on vacation?
we stop working?
=> Remember: We did Pharo especially because people in squeak did not want 
that we change
packages.

Alternate process
- we do a fix we publish it in Pharo and yes this touches Rubric and
- we  integrate it in Pharo head
- then the guy from rubric merge in their trunk when they want.
it should be part of the their process to merge always with pharo trunk
- At that point they can report a problem
- then they produce at their speed a new configuration
- then we integrate when ready their change


Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

and btw… of course I agree repositories need to be added, and configurations 
kept in image.
So what will happen when I publish a configuration with new package in 
the repo of XXX

where XXX is under dev or under a more recent version.
They will have to merge. Because I will only publish to be able to load 
the code I changed into
just the next version of Pharo so that I can continue to work on the 
other parts of the changes.


Stef


cheers,
Esteban


On 22 Apr 2015, at 08:34, Esteban Lorenzano  wrote:

I disagree with your proposal.
It will be a mess, nobody will merge (because there will be no point on doing 
it) and we will not move out from a monolithic system.
What I propose is not an invention, is how big projects work… what you have to 
take into account is that any project under the Pharo umbrella does not have an 
owner, but a maintainer. That means if Alan is on vacation or he does not has 
the time to do the new configuration, anyone can doit.

Yes, it can look slow, but that is because you are too used to the old 
workflow, and because right now system is not modular.
The method I propose will enhance modularity (while the older will, at least, 
not help), which means with time, changes will be applied just in one module 
and not along the full system like now.

Of course with proper tools this will be faster, but I very much prefer people 
telling me “I need this” (that’s why I did the integrator app, and modified the 
monkey to take and validate configurations), and we do it, that we abandon our 
pursuit of modularity because is uncomfortable at the beginning.

We can modify also monticello or versioner (better monticello because 
everything will be closer, but  using versioner API) to do a “save new version” 
which would be more or less the same as a slice, but for a configuration, and 
it will:

- save the packages associated to the configuration
- create a new version
- save the new configuration

this will not be to much work (I think I can have it in a couple of days), it 
will help the process (because eventually everything should be managed through 
configurations (or PPM configurations), and it will allow us to keep a process 
that is better and validated..

TL;DR: Better enhance the tools than drop the process.

Esteban


On 22 Apr 2015, at 07:47, stepharo  wrote:

Esteban
I was thinking about the following this night.

While I understand that we want configuration only it will slow us down like 
hell.

Example
with guille we wanted to fix a problem (I do not remember which one)
we need a change to be done in rubric so we will have to publish the change in 
rubric repo
   - (find it and add it) so the rubric repo should be there before
   - then one guy of rubric should have a look
   - then merge
   - then publish an issue with a configuration
   - then only then we can work
   => result why do we need sync for me and guille to continue to work???
   => what if Alain in on vacation?
   we stop working?
   => Remember: We did Pharo especially because people in squeak did not want 
that we change
   packages.

Alternate process
   - we do a fix we publish it in Pharo and yes this touches Rubric and
   - we  integrate it in Pharo head
   - then the guy from rubric merge in their trunk when they want.
   it should be part of the their process to merge always with pharo trunk
   - At that point they can report a problem
   - then they produce at their speed a new configuration
   - then we integrate when ready their change


Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

in fact I just checked and Versioner already does that: right button on 
monticello over a configuration gives you a: “create development/release 
version”.
So only thing we need is to use the tools we already created :)


Well did you try the configurations that other people created with 
versionner?

I will not fix them.


Stef




On 22 Apr 2015, at 08:50, Esteban Lorenzano  wrote:

and btw… of course I agree repositories need to be added, and configurations 
kept in image.

cheers,
Esteban


On 22 Apr 2015, at 08:34, Esteban Lorenzano  wrote:

I disagree with your proposal.
It will be a mess, nobody will merge (because there will be no point on doing 
it) and we will not move out from a monolithic system.
What I propose is not an invention, is how big projects work… what you have to 
take into account is that any project under the Pharo umbrella does not have an 
owner, but a maintainer. That means if Alan is on vacation or he does not has 
the time to do the new configuration, anyone can doit.

Yes, it can look slow, but that is because you are too used to the old 
workflow, and because right now system is not modular.
The method I propose will enhance modularity (while the older will, at least, 
not help), which means with time, changes will be applied just in one module 
and not along the full system like now.

Of course with proper tools this will be faster, but I very much prefer people 
telling me “I need this” (that’s why I did the integrator app, and modified the 
monkey to take and validate configurations), and we do it, that we abandon our 
pursuit of modularity because is uncomfortable at the beginning.

We can modify also monticello or versioner (better monticello because 
everything will be closer, but  using versioner API) to do a “save new version” 
which would be more or less the same as a slice, but for a configuration, and 
it will:

- save the packages associated to the configuration
- create a new version
- save the new configuration

this will not be to much work (I think I can have it in a couple of days), it 
will help the process (because eventually everything should be managed through 
configurations (or PPM configurations), and it will allow us to keep a process 
that is better and validated..

TL;DR: Better enhance the tools than drop the process.

Esteban


On 22 Apr 2015, at 07:47, stepharo  wrote:

Esteban
I was thinking about the following this night.

While I understand that we want configuration only it will slow us down like 
hell.

Example
with guille we wanted to fix a problem (I do not remember which one)
we need a change to be done in rubric so we will have to publish the change in 
rubric repo
  - (find it and add it) so the rubric repo should be there before
  - then one guy of rubric should have a look
  - then merge
  - then publish an issue with a configuration
  - then only then we can work
  => result why do we need sync for me and guille to continue to work???
  => what if Alain in on vacation?
  we stop working?
  => Remember: We did Pharo especially because people in squeak did not want 
that we change
  packages.

Alternate process
  - we do a fix we publish it in Pharo and yes this touches Rubric and
  - we  integrate it in Pharo head
  - then the guy from rubric merge in their trunk when they want.
  it should be part of the their process to merge always with pharo trunk
  - At that point they can report a problem
  - then they produce at their speed a new configuration
  - then we integrate when ready their change


Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

Le 22/4/15 13:01, Guillermo Polito a écrit :
Well, I agree with Esteban and Thierry in the fact that making our 
lives easier to manage now by pushing changes into the Pharo/main 
branch will make things harder in the long run.


Yes but you see when you clean the architecture and the dependencies 
then after you can change

not before.
At least I'm not Toyota (if you know the story). My time is too limited.


I think we can see this as a case of two dependent configurations

ConfigurationOfPharo (which does not exist but as the ad-hoc list of 
packages in Pharo/main)


ConfigurationOfRubric  => depends on ConfigurationOfPharo

Stef, I'd manage it like this:

 - push the change we have into rubric
 - open an issue number X asking for the integration of rubric with 
that feature

 - open an issue Y that depends on X with the other slice of changes

And here the main problem that we will have is that if we do not 
integrate quickly these fixes, then slices can age and become not valid.
This is ok for me so I will not work on anything during the summer. 
Because when people are on vacation

what do we do? Busy polling? Play magic?




Alternatively, we can do it in several steps, avoiding the dependency:

 - push the change into rubric
 - push the part of the change into pharo that does not break the 
current version of rubric (avoid the renames/removals of methods)
 - when both are integrated we do the last step that integrates the 
last set of changes

And die in deadlock?



El mié., 22 de abr. de 2015 a la(s) 11:15 a. m., Thierry Goubier 
mailto:thierry.goub...@gmail.com>> escribió:


Le 22/04/2015 10:21, Andrei Chis a écrit :
>
>
> On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano
mailto:esteba...@gmail.com>
> >> wrote:
>
> in fact I just checked and Versioner already does that:
right button
> on monticello over a configuration gives you a: “create
> development/release version”.
> So only thing we need is to use the tools we already created :)
>
>
> But this only works for releasing simple configurations that do not
> depend on other configurations.
> This would work for rubric, for example, but not for other
> configurations we have in gtools.

I believe GTTools is certainly a poster case for trying to make that
process simpler.

I would really be interested to see how a combination of simpler
configurations, baselines, tags and branches would look. A kind of
hierarchical modeling where you only have configurations at the
moment.

Thierry


>
> Cheers,
> Andrei
>
>
>  > On 22 Apr 2015, at 08:50, Esteban Lorenzano
mailto:esteba...@gmail.com>
> >>
wrote:
>  >
>  > and btw… of course I agree repositories need to be added, and
> configurations kept in image.
>  >
>  > cheers,
>  > Esteban
>  >
>  >> On 22 Apr 2015, at 08:34, Esteban Lorenzano
mailto:esteba...@gmail.com>
> >>
wrote:
>  >>
>  >> I disagree with your proposal.
>  >> It will be a mess, nobody will merge (because there will
be no
> point on doing it) and we will not move out from a
monolithic system.
>  >> What I propose is not an invention, is how big projects
work…
> what you have to take into account is that any project under the
> Pharo umbrella does not have an owner, but a maintainer.
That means
> if Alan is on vacation or he does not has the time to do the new
> configuration, anyone can doit.
>  >>
>  >> Yes, it can look slow, but that is because you are too
used to
> the old workflow, and because right now system is not modular.
>  >> The method I propose will enhance modularity (while the
older
> will, at least, not help), which means with time, changes
will be
> applied just in one module and not along the full system
like now.
>  >>
>  >> Of course with proper tools this will be faster, but I
very much
> prefer people telling me “I need this” (that’s why I did the
> integrator app, and modified the monkey to take and validate
> configurations), and we do it, that we abandon our pursuit of
> modularity because is uncomfortable at the beginning.
>  >>
>  >> We can modify also monticello or versioner (better
monticello
> because everything will be closer, but  using versioner API)
to do a
> “save new version” which would be more or less the same as a
slice,
> but for a configuration, and it will:
>  >>
>  >> - save the packages associated to the configuration
>

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

Le 22/4/15 13:21, Esteban Lorenzano a écrit :

exactly.
what we need in the long term is a complete better integration process.
I dream to have a git pharo project with submodules and pull requests.

Slowly the tools are coming, but this will take time to implement.
In the mean time, we need to do all the steps we can to allow us to achieve the 
modularisation goal.
Even if they look not easy because we are still building it, or too used to 
previous ways of doing it.


This is ok for me but I will not work on this condition.

I will just frustrate too much. Just waiting that somebody somewhere is 
integrating a stupid change
so that I can work. Because there are moments where I can work and other 
not.


I will accomodate about this and work on other projects than Pharo.

Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

andrei

You talk about releasing.
I talk about changes that should be done on a system while people are 
not active.


Stef


Le 22/4/15 15:29, Andrei Chis a écrit :
In all new tools that we did we tried to have only 2-3 packages and 
use tags to organize classes in a packaged (GT-* has 9 packages for 3 
projects).

This allows for very simple configurations with clear dependencies.
Glamour has more packages (17) but those should also be reduced, as we 
do not need such a low level of granularity.


Given that support for working with multiple nested configuration is 
not great we can merge all GT-* projects into one configuration.
I would still like to have different configurations for Glamour and 
Rubric as they are separate projects.
So we can have just three configurations (each one for a separate 
project that can be released independent of the others):


ConfigurationOfGToolkitCore
> ConfigurationOfGlamourCore
-> ConfigurationOfRubric

This would make releasing a new version easier with the current 
support from versioner.
Releasing a version for all three configurations at once would still 
require some manual updating of versions, but that's a less frequent 
use-case.


Cheers,
Andrei


On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano 
mailto:esteba...@gmail.com>> wrote:


exactly.
what we need in the long term is a complete better integration
process.
I dream to have a git pharo project with submodules and pull requests.

Slowly the tools are coming, but this will take time to implement.
In the mean time, we need to do all the steps we can to allow us
to achieve the modularisation goal.
Even if they look not easy because we are still building it, or
too used to previous ways of doing it.

Esteban

> On 22 Apr 2015, at 12:15, Pavel Krivanek
mailto:pavel.kriva...@gmail.com>> wrote:
>
> And do not forget that with better Pharo modularization it will
start
> to be a problem on more lower level. When eg. Morphic will be an
> "exteranal" Pharo package.
>
> -- Pavel
>
> 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano
mailto:esteba...@gmail.com>>:
>>
>> On 22 Apr 2015, at 10:21, Andrei Chis
mailto:chisvasileand...@gmail.com>>
wrote:
>>
>> But this only works for releasing simple configurations that do
not depend
>> on other configurations.
>> This would work for rubric, for example, but not for other
configurations we
>> have in gtools.
>>
>>
>> then you have two options:
>>
>> 1) you rewrite your configurations to not need nested
configurations. This
>> is not recommendable in huge projects like Seaside, but things
like GTools
>> are easily (I did a quick check and your 3 configurations have
in total 7
>> packages… would not be a problem to have them without nesting
projects and
>> just using the packages).  In fact, this is how Dale recommends
using
>> configurations (if I understood him right).
>> 2) we enhance the tools to also allow the commit of nested
packages.
>>
>> I think both approaches needs to be done: you don’t need
unnecessary
>> complexity in your configurations and we need to add some
nesting support to
>> commit new version.
>>
>> What is not admisible, IMO, is to do something that is wrong
just because it
>> looks easier in the short term (and I say “in short term”
because what looks
>> easier now will generate a lot of problems in the future).
>>
>> cheers,
>> Esteban
>

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

Alternate process
- we do a fix we publish it in Pharo and yes this touches
Rubric and
- we  integrate it in Pharo head
- then the guy from rubric merge in their trunk when they want.
it should be part of the their process to merge always
with pharo trunk
- At that point they can report a problem
- then they produce at their speed a new configuration
- then we integrate when ready their change


This kind of process will be a pain for those that have to merge the 
changes back to their repos.
I did this for a while when I was synching the debugger repo with 
Pharo and even if I only had to merge maybe one slice a day it was 
kind of annoying.


Andrei

If we do a change that touch your project you will have to produce a 
configuration

and merge the change anyway.
Do not expect me to know what is the head of your project and what I 
should know.
You know your project so you merge the changes we propose. Then you 
control the speed

at which you want to release.
Else I will create stupid configuration (in the sense that may be I will 
break something
without even knowing it) and you will have to merge anyway the 
configurations and the package.

Do not dream there is no such alternative.

We should go fast to change some structural aspects and avoid to have 
changes that touch

external packages but there is no magic

Stef

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

The thing is, if you are not doing it, you're asking someone else to 
do it for you.


So, some of the possibilities are:

- Decouple a bit upstream from Pharo/main, not merging everything from 
there immediately. Wait to see the fixes and changes to stabilize, 
then extract and merge.


- Wait for Pharo/main to pushes fixes to you upstream. So that 
Pharo/main has a duty of collecting the changes, making them all in a 
nice pack, and send them your way.


A good thing is to adjust the process so that pushing things back and 
forth is easing the task of everybody involved (motivation!).


For example, if an hypothetical Stef (not the true one :)) is changing 
and fixing things in Rubric inside Pharo/main, it will make merging 
Rubric newest version harder. 

Why?
As a maintainer of Rubric, you know the system, its current development 
status.

So you can decide when you reconcile with the Pharo version.
I would say that Pharo core hackers should not integrate changes in 
external packages (only in urgence)


So, a good thing would be to make that hypothetical Stef in charge of 
merging the new Rubric version as well. If he finds it a pain, then he 
will ease his tasks by sending his fixes nicely packaged to the Rubric 
maintainer, so that the Rubric manager can merge that with the newest 
version and send it back to Pharo/main for integration by our 
hypothetical Stef :)


However, it would be allways possible for an external project to make 
it easier to fix in their project directly than in Pharo/main, but for 
that they need to be very reactive (make sure that fixes are 
propagated back very fast in Pharo/main) and make the process as easy 
as possible for an external contributor...
I do not think that putting the stress on external projects to merge 
fast is good.

Because you can be in the middle of something.
Of course with a correct branch it can be simpler but we do not have 
such tool right now.


Note that, in such a process, having good tools count. This is one of 
the reasons for using places like bitbucket or github: they do really 
support that kind of process (pull requests, branches, issues, 
server-based merge and CI check, etc...). We could recreate that with 
http repositories, but with a significant amount of work.


Regards,

Thierry



Cheers,
Andrei


Stef

Re: [Pharo-dev] QualityAssistant v0.4

[stepharo]

NO NO NO integration in the image.
NO external tools to talk to. NO NO NO Change your mindset.
ConfigurationBrowser is your friend. One click and load.
Or a startup preference.
The configurationBrowser could have button: "add to my startupPreference."

Stef

Le 22/4/15 16:43, Sean P. DeNigris a écrit :

Uko2 wrote

I am developing a tool called QualityAssistant, which displays current
critics about your code in SystemBrowser, Inspector and Spotter.

Holy crap - this tool is /Amazing/! It highlights the offending code and
even has a button to fix automatically if possible!!! +1 to integration



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821143.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

[stepharo]

Le 20/4/15 21:52, Dmitri Zagidulin a écrit :

I've been:

- Rewriting/updating the Pharo driver for the Riak NoSQL database, at 
https://github.com/SmalltalkZen/phriak. (It needs a tiny bit more 
documentation before making a full-on mailing list announcement, though).


Cool!



- Helping out with updating the UPBE book to catch it up with the 
Pharo 4.0 release.



On Mon, Apr 20, 2015 at 7:32 AM, Serge Stinckwich 
mailto:serge.stinckw...@gmail.com>> wrote:


On Mon, Apr 20, 2015 at 9:09 AM, stepharo mailto:steph...@free.fr>> wrote:
> Hi phil
>
> just that you know what we are doing
>
> - Mathieu Lacatou an intern from Thales should be visiting
the team for
> 10 days to pair program with esteban
> about the OSWindow multi-windowing support
>
> - JB and Merwan are extending the OSWindow touch support, like
> generating scroll events
>
> - JB is working on Woden and adding some shadders for 3D demoes.

I will have a new guy from Senegal starting to work tomorrow in my lab
on using GPU and Wooden for doing SPH&epidemiological modeling.
How to coordinate all these activities ?

--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

[stepharo]

From what I know:
the configruation of OSWindow in the repo is not loaded when there is a 
configuration in the image.

Kind of

Le 22/4/15 08:31, Tudor Girba a écrit :
Could JB describe the problem with Metacello? Perhaps there is a 
workaround.


Doru

On Tue, Apr 21, 2015 at 3:27 PM, stepharo > wrote:



Hi phil

just that you know what we are doing

 - Mathieu Lacatou an intern from Thales should be
visiting the team for
10 days to pair program with esteban
 about the OSWindow multi-windowing support

 - JB and Merwan are extending the OSWindow touch
support, like
generating scroll events

 - JB is working on Woden and adding some shadders for
3D demoes.

I will have a new guy from Senegal starting to work tomorrow
in my lab
on using GPU and Wooden for doing SPH&epidemiological modeling.
How to coordinate all these activities ?


Cool :)
I do not know
For now he should have a look at Woden, JB  planned to make a CI.
But he was blocked because of a bug in the old version of
Metacello that we use.
So as soon as Metacello is updated, JB can continue his build.

Stef







--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] TDD and BDD

[stepharo]

Christophe

I do not have the answer just the constraints.
This is hyper important that the solution does not change much SUnit.
This way we do not end up with a mess with Sunit version.

It is better to have a separate package.

Stef

Le 20/4/15 13:02, Christophe Demarey a écrit :

Hi,

With BDD a current test practice is to start method names with 'should'.
It is not yet possible in Pharo but easily do-able (update of TestCase and some 
Nautilus methods).
I would like that Pharo detects tes methods all methods of a class subclassing 
(directly or not) TestCase AND starting with either 'test' or 'should'.
I also would like to add 'deny' to not use 'shouldNot' but here I'm not sure.

WDYT?

Christophe.

Re: [Pharo-dev] QualityAssistant v0.4

[Marcus Denker]

> On 22 Apr 2015, at 20:08, stepharo  wrote:
> 
> NO NO NO integration in the image.
> NO external tools to talk to. NO NO NO Change your mindset.

But that will get quite hard: If we improve and people create more tools, then
the “Pharo that could be” (with the tools loaded) will be very different from 
the
“Pharo that is”. And nobody who downloads pharo will load additional tools.
Nobody.

Our goal of a modular and minimal image should not mean that Pharo itself
does not come with those tools that we want people to use by default.

Marcus

Re: [Pharo-dev] Integration process in presence of "external" project

[Thierry Goubier]

Le 22/04/2015 20:05, stepharo a écrit :



The thing is, if you are not doing it, you're asking someone else to
do it for you.

So, some of the possibilities are:

- Decouple a bit upstream from Pharo/main, not merging everything from
there immediately. Wait to see the fixes and changes to stabilize,
then extract and merge.

- Wait for Pharo/main to pushes fixes to you upstream. So that
Pharo/main has a duty of collecting the changes, making them all in a
nice pack, and send them your way.

A good thing is to adjust the process so that pushing things back and
forth is easing the task of everybody involved (motivation!).

For example, if an hypothetical Stef (not the true one :)) is changing
and fixing things in Rubric inside Pharo/main, it will make merging
Rubric newest version harder.




Why?
As a maintainer of Rubric, you know the system, its current development
status.
So you can decide when you reconcile with the Pharo version.
I would say that Pharo core hackers should not integrate changes in
external packages (only in urgence)


I agree.

What I said is that if Pharo core hackers do not take a bit of time to 
package and push upstream (i.e. to the external project) their fixes, 
then it will be hard for the external project maintainer to reconcile 
Pharo and his stream.


Note that as the Rubric maintainer, if I go on holiday for three weeks, 
I may have to cope with a jump of around 30 to 50 versions of Pharo main 
to adjust too... If this happens to be the period you go on a fixing bug 
chase over Rubric, then the merge may be a tad challenging ;)



So, a good thing would be to make that hypothetical Stef in charge of
merging the new Rubric version as well. If he finds it a pain, then he
will ease his tasks by sending his fixes nicely packaged to the Rubric
maintainer, so that the Rubric manager can merge that with the newest
version and send it back to Pharo/main for integration by our
hypothetical Stef :)

However, it would be allways possible for an external project to make
it easier to fix in their project directly than in Pharo/main, but for
that they need to be very reactive (make sure that fixes are
propagated back very fast in Pharo/main) and make the process as easy
as possible for an external contributor...



I do not think that putting the stress on external projects to merge
fast is good.


I consider that some external projects sufficiently staffed may want to 
react this way. Up to them...



Because you can be in the middle of something.
Of course with a correct branch it can be simpler but we do not have
such tool right now.


In fact, we do. Apart of the github/bitbucket kind of stuff, it is also 
possible to use smalltalkhub in that way.


It's just a matter of organizing your projects and branches (with one 
smalltalkhub repository per branch). If you organize yourself that way, 
you'll end up being very close to a git / branch type of approach.


Thierry

Re: [Pharo-dev] ARM Cogit

[Thierry Goubier]

Yes!

Thanks to all for that effort.

Thierry

Le 22/04/2015 20:42, Eliot Miranda a écrit :

Hi All,

 thanks to hard work by Tim Rowledge and Lars Wasserman we now have
a functional JIT for the ARM in the simulator.  We're still probably
some weeks away from a functional ARM JIT VM; issues like instruction
cache flushing on real hardware can be tricky to solve.  But we're at
least ready to start trying to compile the JIT VM for ARM.  Doug, see
that I added a build directory for build.linux32ARM/squeak.cog.spur.
Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away.
--
best,
Eliot

[Pharo-dev] Pb when exporting setting?

[Alexandre Bergel]

Hi!

I have an error: 
KeyNotFound: key #’Weight Below Threshold’ not found in SystemDictionary

Any idea what’s going on? How can I reset the export? Where is this file by the 
way? I could not find it.

cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Integration process in presence of "external" project

[Andrei Chis]

On Wed, Apr 22, 2015 at 7:55 PM, stepharo  wrote:

>  andrei
>
> You talk about releasing.
> I talk about changes that should be done on a system while people are not
> active.
>

If we are all on vacation, or you really really need a bug fixed, or you
make a change that touches a lot of
packages then I see no problem if you make a slice and notify us so we can
back port it.

What I would like to avoid is this becoming the default behaviour any time
you want to make change that is
just related to a project that is maintain by configurations.

Right now for rubric you can just commit you package to the rubric repo
under the pharo team, create a new version
using versioner, copy it to PharoInbox50, make an issue to integrate it and
integrate it. A few more steps then
working with slices but you do not have to wait for us to integrate :). You
might get some merge conflicts
when we are actively working on rubric but then we are around to help with
the merge.

Cheers,
Andrei



>
> Stef
>
>
> Le 22/4/15 15:29, Andrei Chis a écrit :
>
> In all new tools that we did we tried to have only 2-3 packages and use
> tags to organize classes in a packaged (GT-* has 9 packages for 3
> projects).
> This allows for very simple configurations with clear dependencies.
> Glamour has more packages (17) but those should also be reduced, as we do
> not need such a low level of granularity.
>
>  Given that support for working with multiple nested configuration is not
> great we can merge all GT-* projects into one configuration.
> I would still like to have different configurations for Glamour and Rubric
> as they are separate projects.
> So we can have just three configurations (each one for a separate project
> that can be released independent of the others):
>
>  ConfigurationOfGToolkitCore
> > ConfigurationOfGlamourCore
> -> ConfigurationOfRubric
>
>  This would make releasing a new version easier with the current support
> from versioner.
> Releasing a version for all three configurations at once would still
> require some manual updating of versions, but that's a less frequent
> use-case.
>
>  Cheers,
> Andrei
>
>
> On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano 
> wrote:
>
>> exactly.
>> what we need in the long term is a complete better integration process.
>> I dream to have a git pharo project with submodules and pull requests.
>>
>> Slowly the tools are coming, but this will take time to implement.
>> In the mean time, we need to do all the steps we can to allow us to
>> achieve the modularisation goal.
>> Even if they look not easy because we are still building it, or too used
>> to previous ways of doing it.
>>
>> Esteban
>>
>> > On 22 Apr 2015, at 12:15, Pavel Krivanek 
>> wrote:
>> >
>> > And do not forget that with better Pharo modularization it will start
>> > to be a problem on more lower level. When eg. Morphic will be an
>> > "exteranal" Pharo package.
>> >
>> > -- Pavel
>> >
>> > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano :
>> >>
>> >> On 22 Apr 2015, at 10:21, Andrei Chis 
>> wrote:
>> >>
>> >> But this only works for releasing simple configurations that do not
>> depend
>> >> on other configurations.
>> >> This would work for rubric, for example, but not for other
>> configurations we
>> >> have in gtools.
>> >>
>> >>
>> >> then you have two options:
>> >>
>> >> 1) you rewrite your configurations to not need nested configurations.
>> This
>> >> is not recommendable in huge projects like Seaside, but things like
>> GTools
>> >> are easily (I did a quick check and your 3 configurations have in
>> total 7
>> >> packages… would not be a problem to have them without nesting projects
>> and
>> >> just using the packages).  In fact, this is how Dale recommends using
>> >> configurations (if I understood him right).
>> >> 2) we enhance the tools to also allow the commit of nested packages.
>> >>
>> >> I think both approaches needs to be done: you don’t need unnecessary
>> >> complexity in your configurations and we need to add some nesting
>> support to
>> >> commit new version.
>> >>
>> >> What is not admisible, IMO, is to do something that is wrong just
>> because it
>> >> looks easier in the short term (and I say “in short term” because what
>> looks
>> >> easier now will generate a lot of problems in the future).
>> >>
>> >> cheers,
>> >> Esteban
>> >
>>
>>
>>
>
>

Re: [Pharo-dev] Integration process in presence of "external" project

[Esteban Lorenzano]

> On 22 Apr 2015, at 21:17, Andrei Chis  wrote:
> 
> 
> 
> On Wed, Apr 22, 2015 at 7:55 PM, stepharo  > wrote:
> andrei
> 
> You talk about releasing. 
> I talk about changes that should be done on a system while people are not 
> active.
> 
> If we are all on vacation, or you really really need a bug fixed, or you make 
> a change that touches a lot of 
> packages then I see no problem if you make a slice and notify us so we can 
> back port it.
> 
> What I would like to avoid is this becoming the default behaviour any time 
> you want to make change that is
> just related to a project that is maintain by configurations.
> 
> Right now for rubric you can just commit you package to the rubric repo under 
> the pharo team, create a new version 
> using versioner, copy it to PharoInbox50, make an issue to integrate it and 
> integrate it. A few more steps then 
> working with slices but you do not have to wait for us to integrate :). You 
> might get some merge conflicts
> when we are actively working on rubric but then we are around to help with 
> the merge.

I will add a “commit new version” option that will reduce the steps too. 
It will: 
- commit dirty packages from version to corresponding configuration, 
- generate and commit new version. 
- It will do it recursively with nested configurations 

so, this will solve all complains you might have :)

Esteban

> 
> Cheers,
> Andrei
> 
>  
> 
> Stef
> 
> 
> Le 22/4/15 15:29, Andrei Chis a écrit :
>> In all new tools that we did we tried to have only 2-3 packages and use tags 
>> to organize classes in a packaged (GT-* has 9 packages for 3 projects).
>> This allows for very simple configurations with clear dependencies.
>> Glamour has more packages (17) but those should also be reduced, as we do 
>> not need such a low level of granularity.  
>> 
>> Given that support for working with multiple nested configuration is not 
>> great we can merge all GT-* projects into one configuration.
>> I would still like to have different configurations for Glamour and Rubric 
>> as they are separate projects.
>> So we can have just three configurations (each one for a separate project 
>> that can be released independent of the others):
>> 
>> ConfigurationOfGToolkitCore
>> > ConfigurationOfGlamourCore
>> -> ConfigurationOfRubric
>> 
>> This would make releasing a new version easier with the current support from 
>> versioner.
>> Releasing a version for all three configurations at once would still require 
>> some manual updating of versions, but that's a less frequent use-case.
>> 
>> Cheers,
>> Andrei
>> 
>> 
>> On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano > > wrote:
>> exactly.
>> what we need in the long term is a complete better integration process.
>> I dream to have a git pharo project with submodules and pull requests.
>> 
>> Slowly the tools are coming, but this will take time to implement.
>> In the mean time, we need to do all the steps we can to allow us to achieve 
>> the modularisation goal.
>> Even if they look not easy because we are still building it, or too used to 
>> previous ways of doing it.
>> 
>> Esteban
>> 
>> > On 22 Apr 2015, at 12:15, Pavel Krivanek > > > wrote:
>> >
>> > And do not forget that with better Pharo modularization it will start
>> > to be a problem on more lower level. When eg. Morphic will be an
>> > "exteranal" Pharo package.
>> >
>> > -- Pavel
>> >
>> > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano > > >:
>> >>
>> >> On 22 Apr 2015, at 10:21, Andrei Chis > >> > wrote:
>> >>
>> >> But this only works for releasing simple configurations that do not depend
>> >> on other configurations.
>> >> This would work for rubric, for example, but not for other configurations 
>> >> we
>> >> have in gtools.
>> >>
>> >>
>> >> then you have two options:
>> >>
>> >> 1) you rewrite your configurations to not need nested configurations. This
>> >> is not recommendable in huge projects like Seaside, but things like GTools
>> >> are easily (I did a quick check and your 3 configurations have in total 7
>> >> packages… would not be a problem to have them without nesting projects and
>> >> just using the packages).  In fact, this is how Dale recommends using
>> >> configurations (if I understood him right).
>> >> 2) we enhance the tools to also allow the commit of nested packages.
>> >>
>> >> I think both approaches needs to be done: you don’t need unnecessary
>> >> complexity in your configurations and we need to add some nesting support 
>> >> to
>> >> commit new version.
>> >>
>> >> What is not admisible, IMO, is to do something that is wrong just because 
>> >> it
>> >> looks easier in the short term (and I say “in short term” because what 
>> >> looks
>> >> easier now will generate a lot of problems in the future).
>> >>
>> >> cheers,
>> >> Esteban
>> >
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

[Tudor Girba]

Aha. We have the same issue with GT, so when building the development
image, we first explicitly load all latest versions of ConfigurationOfG*
from the project configuration. This should solve that problem.

Doru


On Wed, Apr 22, 2015 at 8:13 PM, stepharo  wrote:

>  From what I know:
> the configruation of OSWindow in the repo is not loaded when there is a
> configuration in the image.
> Kind of
>
> Le 22/4/15 08:31, Tudor Girba a écrit :
>
> Could JB describe the problem with Metacello? Perhaps there is a
> workaround.
>
>  Doru
>
> On Tue, Apr 21, 2015 at 3:27 PM, stepharo  wrote:
>
>>
>>  Hi phil

 just that you know what we are doing

  - Mathieu Lacatou an intern from Thales should be visiting the
 team for
 10 days to pair program with esteban
  about the OSWindow multi-windowing support

  - JB and Merwan are extending the OSWindow touch support, like
 generating scroll events

  - JB is working on Woden and adding some shadders for 3D demoes.

>>> I will have a new guy from Senegal starting to work tomorrow in my lab
>>> on using GPU and Wooden for doing SPH&epidemiological modeling.
>>> How to coordinate all these activities ?
>>>
>>
>>  Cool :)
>> I do not know
>> For now he should have a look at Woden, JB  planned to make a CI.
>> But he was blocked because of a bug in the old version of Metacello that
>> we use.
>> So as soon as Metacello is updated, JB can continue his build.
>>
>> Stef
>>
>>>
>>>
>>
>>
>
>
>  --
>  www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] QualityAssistant v0.4

[Sean P. DeNigris]

stepharo wrote
> NO NO NO integration in the image.
> NO external tools to talk to. NO NO NO Change your mindset.

I was actually thinking specifically of new users. I already know how to
load it and make extensive use of startup preferences so it doesn't really
matter to me. But it's taken me 5 years to find all the cool extensions I
use routinely. How will a new user appreciate our Ferrari when we give it to
them without paint, headlights, or seats? Maybe we can have something like
Edgar's FunSqueak, with all the cool IDE features, be the default download,
but then, if we're not all using that image, we may commit a sin similar
Marcus' repeated warning that "the artefact on the build server needs to be
the artefact of release" of using a different image than we release...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821265.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] QualityAssistant v0.4

[kilon alios]

There is a solution that I was thinking when I was imagining implementing
my own Configuration Browser than I named "Tartara". One of the ideas I had
was the introduction of packages, which is basically something that would
trigger the installation of multiple projects at the same time. So I was
imaging "Core" package that will contain all the core IDEs, "GT" package
all the GT tools , "Games" where there will be multiple games etc.

This way the user would not need to install those tools one by one. Ideally
I was also imagining a detailed description per package with even the
ability to rate the quality of the package or even review it .

>From the looks of it this is already possible with Configuration Browser
but it does not provide this separation yet.

On Wed, Apr 22, 2015 at 11:18 PM Sean P. DeNigris 
wrote:

> stepharo wrote
> > NO NO NO integration in the image.
> > NO external tools to talk to. NO NO NO Change your mindset.
>
> I was actually thinking specifically of new users. I already know how to
> load it and make extensive use of startup preferences so it doesn't really
> matter to me. But it's taken me 5 years to find all the cool extensions I
> use routinely. How will a new user appreciate our Ferrari when we give it
> to
> them without paint, headlights, or seats? Maybe we can have something like
> Edgar's FunSqueak, with all the cool IDE features, be the default download,
> but then, if we're not all using that image, we may commit a sin similar
> Marcus' repeated warning that "the artefact on the build server needs to be
> the artefact of release" of using a different image than we release...
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/QualityAssistant-v0-4-tp4821070p4821265.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] ARM Cogit

[kilon alios]

Yes , yes , yes , would love to have Pharo available on Android and use
it on my smartphone on a daily basis , thank you very much guys.

On Wed, Apr 22, 2015 at 9:42 PM Eliot Miranda 
wrote:

> Hi All,
>
> thanks to hard work by Tim Rowledge and Lars Wasserman we now have a
> functional JIT for the ARM in the simulator.  We're still probably some
> weeks away from a functional ARM JIT VM; issues like instruction cache
> flushing on real hardware can be tricky to solve.  But we're at least ready
> to start trying to compile the JIT VM for ARM.  Doug, see that I added a
> build directory for build.linux32ARM/squeak.cog.spur.  Hopefully a fast VM
> for Raspberry Pi and Android is only a few weeks away.
>
> --
> best,
> Eliot
>

Re: [Pharo-dev] Improving the documentation model

[Kasper Osterbye]

To me this whole notion of which format to use, if it should be WYSIWYG, and
what kind of markup to use is somewhat dependent on that usage scenarios one
consider.

I too would like to see something which moves beyond plain strings. As the
computer scientist I am, would also like it to be something uniform across
usage. However - there is difference in how we I view a comment and how I
view a book. 
In a method comment I would like to be able to add a little bold, and
perhaps a few links to elsewhere.
In a class method I would like to be to also do lists, perhaps a heading or
two (which I could do with bold perhaps).
A package comment I start to want to include diagrams and images.

In a full book or paper, well, I want it all there (aka level of Latex or
Word).

Pillar is no worse than 99% of the other markup's out there, so fine with
me. 
What I tried in my little Pillar/Nautilus combo was to show how one can make
a morph which shows pillar markup as a rendered text (as opposed to string),
but editing that text is done by editing the pillar markup. I believe
someone with more experience than I can make one that works more smoothly.
Also, I believe the same trick can be used of inlined method comments.

So, my point is, that Pillar and other markup languages were intended to be
for wiki, and web pages, not for books. That is something at the level of
class comments or package comments.




--
View this message in context: 
http://forum.world.st/Improving-the-documentation-model-tp4820814p4821286.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] ARM Cogit

[stepharo]

This is really excellent!
Keep pushing this.
I'm eager to play with a raspberry.
We should continue to revisit the UI elements to consume less in any case.
Because I'm convinced that we are doing too many things at the wrong place.

Stef

Le 22/4/15 21:42, Eliot Miranda a écrit :

Hi All,

thanks to hard work by Tim Rowledge and Lars Wasserman we now have 
a functional JIT for the ARM in the simulator. We're still probably 
some weeks away from a functional ARM JIT VM; issues like instruction 
cache flushing on real hardware can be tricky to solve.  But we're at 
least ready to start trying to compile the JIT VM for ARM.  Doug, see 
that I added a build directory for build.linux32ARM/squeak.cog.spur. 
Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away.

--
best,
Eliot

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

Ok so this is the way to go for me. At least to try.

Le 22/4/15 21:47, Thierry Goubier a écrit :
In fact, we do. Apart of the github/bitbucket kind of stuff, it is 
also possible to use smalltalkhub in that way.


It's just a matter of organizing your projects and branches (with one 
smalltalkhub repository per branch). If you organize yourself that 
way, you'll end up being very close to a git / branch type of approach.


Thierry 

Re: [Pharo-dev] Integration process in presence of "external" project

[stepharo]

I will add a “commit new version” option that will reduce the steps too.
It will:
- commit dirty packages from version to corresponding configuration,
- generate and commit new version.
- It will do it recursively with nested configurations

so, this will solve all complains you might have :)

Ok show us and we will do it.
Now for now I will not work on changes that imply waiting for an 
integration of a subproject.


Stef

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

[Yuriy Tymchuk]

Hi,

thank you for reporting. Can you tell me on which project are you running it, 
or file out the hierarchy so I can reproduce it?

Uko

> On 22 Apr 2015, at 18:06, Cyril Ferlicot  wrote:
> 
> Hi !
> Your quality assistant say to me "repeated method in the superclass"
> (If a class is overriding a method, it should use a different code. Is
> meaningless to have a method in a class and in its superclass) but
> i've 3 methods into my class and all overrides a method with "^
> shouldBeImplemented" in the superclass.
> I think something is wrong with this warning :)
> 
> 
> On 22 April 2015 at 16:45, Yuriy Tymchuk  wrote:
>> Good point, this brings up two problems.
>> 
>> 1) The rule can improve detection by checking the type is the message is
>> sent to self
>> 2) Automatic fixing should display the changes and letting you decide
>> whether you want to apply them.
>> 
>> 1st will take some time. 2nd will be soon in QA :)
>> 
>> Uko
>> 
>> 
>> On 22 Apr 2015, at 16:33, Johan Fabry  wrote:
>> 
>> Some weird behavior in quality assistant. Have a look at this method:
>> 
>> duplicateVar: aVarName
>> 
>> self show: 'Var: ', aVarName, ' redefinition ignored'.
>> 
>> This raises the issue: ‘Use cascaded nextPutAll:’s instead of #, in
>> nextPutAll:’ It also pops up the automatic rewrite icon, so I clicked on it
>> to see how it would transform the code. Result:
>> 
>> duplicateVar: aVarName
>> self
>> show: 'Var: ' , aVarName;
>> show: ' redefinition ignored'
>> 
>> Needless to say, that’s not a behavior preserving transformation.
>> 
>> 
>> On Apr 22, 2015, at 03:58, Yuriy Tymchuk  wrote:
>> 
>> Please give me a feedback about your experience, as I want to make it even
>> more useful. Either write me an email, or open an entry at:
>> https://github.com/Uko/QualityAssistant/issues
>> 
>> 
>> 
>> 
>> ---> Save our in-boxes! http://emailcharter.org <---
>> 
>> Johan Fabry   -   http://pleiad.cl/~jfabry
>> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>> 
>> 
> 
> 
> 
> -- 
> Cheers
> Cyril Ferlicot
>