Re: [Pharo-dev] Lowering the pain of newbies

[Tim Mackinnon]

Is this a goal we can all share for 7.0?

Sort out the expert tools (like git etc), but equally enable that simplicity 
you expect for a child/newbie/expert...

I'm in!

Tim

Sent from my iPhone

> On 17 Aug 2017, at 20:52, Stephane Ducasse  wrote:
> 
> Hi guys
> 
> my son coded in Pharo 60
> 
> testGuessUrlPart
> 
>  |dg8|
>  dg8 := GameItem new;
>  name: 'Dragon Quest VIII : Journey Of The Cursed King';
>  console: 'PS2'.
>   self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
> 
> and guess what he broke the system.
> 
> We should not accept such kind of behavior.
> name: should not change the name of the class.
> 
> I do not know the solution but I fear when I will teach 160 students this 
> fall.
> We should make sure that Pharo is not a system only for experts!
> 
> any idea is welcome
> 
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
> 
> Stef
> 

Re: [Pharo-dev] Lowering the pain of newbies

[Peter Uhnak]

On Thu, Aug 17, 2017 at 05:23:28PM -0300, Esteban A. Maringolo wrote:
> What are the odds?

100%, this _always_ happens to some student. (You just need to omit a single 
semicolon and you've just broke it.)

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

[TomW]

Thank you for the very enlightening post.

A quick followup question regarding your transaction data using an RDB and
complex queries using Neo4j.
 
Do you have a mechanism for maintaining/synchronizing data updated via
transactions (into the RDB) in the the Neo4j database?

Tom 



--
View this message in context: 
http://forum.world.st/Pharo-behind-ALLSTOCKER-marketplace-tp4919088p4961941.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Lowering the pain of newbies

[Esteban A. Maringolo]

What are the odds?

The ability to break a system in a few steps seems to be an inherited trait.

My daughter (2 years old) was randomly punching my keyboard and caused
a segfault that I couldn't reproduce afterwards.

Regards!


Esteban A. Maringolo


2017-08-17 16:52 GMT-03:00 Stephane Ducasse :
> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
>   |dg8|
>   dg8 := GameItem new;
>   name: 'Dragon Quest VIII : Journey Of The Cursed King';
>   console: 'PS2'.
>self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
>
> and guess what he broke the system.
>
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
> I do not know the solution but I fear when I will teach 160 students this 
> fall.
> We should make sure that Pharo is not a system only for experts!
>
> any idea is welcome
>
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>
> Stef
>

Re: [Pharo-dev] Lowering the pain of newbies

[Cyril Ferlicot]

On jeu. 17 août 2017 at 21:53, Stephane Ducasse 
wrote:

> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
>   |dg8|
>   dg8 := GameItem new;
>   name: 'Dragon Quest VIII : Journey Of The Cursed King';
>   console: 'PS2'.
>self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
>
> and guess what he broke the system.
>
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
> I do not know the solution but I fear when I will teach 160 students this
> fall.
> We should make sure that Pharo is not a system only for experts!
>
> any idea is welcome
>
>
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>
> Stef
>

Fast answer:

Some month (year?) ago I proposed to get pre-compilation rules that could
show warnings in interactive mode.

Maybe this can be a path to dig.

:)


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

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

[Pharo-dev] Lowering the pain of newbies

[Stephane Ducasse]

Hi guys

my son coded in Pharo 60

testGuessUrlPart

  |dg8|
  dg8 := GameItem new;
  name: 'Dragon Quest VIII : Journey Of The Cursed King';
  console: 'PS2'.
   self assert: dg8 guessUrlPart equals:
'dragonquestviiijourneyofthecursedking'

and guess what he broke the system.

We should not accept such kind of behavior.
name: should not change the name of the class.

I do not know the solution but I fear when I will teach 160 students this fall.
We should make sure that Pharo is not a system only for experts!

any idea is welcome

https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class

Stef

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

[Nicolas Cellier]

2017-08-17 20:43 GMT+02:00 Eliot Miranda :

> Hi Stef,
>
> On Thu, Aug 17, 2017 at 8:08 AM, Stephane Ducasse  > wrote:
>
>> I do not know but I imagine that I added basenameWithoutExtension because
>> I found the name much much clearer. I would have never guessed that
>> base is the basename without the extension.
>>
>
> While basenameWithoutExtension is an intension revealing selector it is
> soon ln :-)  For file manipulation code that's a problem.   I
> wonder if something like bodyName is better because it's shorter.
>
>
25 years ago I had `aFilename basename withoutExtension` in my vw app...
I don't think that such decomposition is a big efficiency problem for
scripting.

Nicolas


>> Stef
>>
>> On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant 
>> wrote:
>> > Hi All,
>> >
>> > I've just taken a look at issue 19609 FileReference>>base should be
>> > before last separator and wonder whether it is a correct interpretation
>> > of the original intentions.
>> >
>> > The original author of the issue, Michael, seems to feel that
>> > FileReferene>>base and FileReference>>basenameWithoutExtension are the
>> > same.
>> >
>> > My reading of the comments is that they perform a different function,
>> > i.e.:
>> >
>> >
>> > '/a/b/c.d.e' asFileReference base.  "c"
>> > '/a/b/c.d.e' asFileReference basenameWithoutExtension.  "c.d"
>> >
>> >
>> > are both the expected values, i.e.:
>> >
>> > - #base answers the name up to the first extensionDelimiter.
>> > - #basenameWithoutExtension answers the name without what is typically
>> >   considered the file extension (the bit after the last
>> >   extensionDelimiter).
>> >
>> > Not shown above, but:
>> >
>> > - #basename answers the entire filename, i.e. "c.d.e".
>> >
>> >
>> > Does anyone know the history of these methods?
>> >
>> >
>> > Cheers,
>> > Alistair
>> >
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

[Eliot Miranda]

Hi Stef,

On Thu, Aug 17, 2017 at 8:08 AM, Stephane Ducasse 
wrote:

> I do not know but I imagine that I added basenameWithoutExtension because
> I found the name much much clearer. I would have never guessed that
> base is the basename without the extension.
>

While basenameWithoutExtension is an intension revealing selector it is
soon ln :-)  For file manipulation code that's a problem.   I
wonder if something like bodyName is better because it's shorter.


> Stef
>
> On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant 
> wrote:
> > Hi All,
> >
> > I've just taken a look at issue 19609 FileReference>>base should be
> > before last separator and wonder whether it is a correct interpretation
> > of the original intentions.
> >
> > The original author of the issue, Michael, seems to feel that
> > FileReferene>>base and FileReference>>basenameWithoutExtension are the
> > same.
> >
> > My reading of the comments is that they perform a different function,
> > i.e.:
> >
> >
> > '/a/b/c.d.e' asFileReference base.  "c"
> > '/a/b/c.d.e' asFileReference basenameWithoutExtension.  "c.d"
> >
> >
> > are both the expected values, i.e.:
> >
> > - #base answers the name up to the first extensionDelimiter.
> > - #basenameWithoutExtension answers the name without what is typically
> >   considered the file extension (the bit after the last
> >   extensionDelimiter).
> >
> > Not shown above, but:
> >
> > - #basename answers the entire filename, i.e. "c.d.e".
> >
> >
> > Does anyone know the history of these methods?
> >
> >
> > Cheers,
> > Alistair
> >
>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Adding build info into pharo runtime

[Torsten Bergmann]

Hi Guille,

 

looks good - I approved the change on the PR.

Thanks a lot and have a happy holiday!


Regards
T.

 

Gesendet: Donnerstag, 17. August 2017 um 17:59 Uhr
Von: "Guillermo Polito" 
An: "Discusses Development of Pharo" 
Betreff: [Pharo-dev] Adding build info into pharo runtime


Hi all,
 

as asked by Torsten, I spent some time adding build info into the pharo runtime.

 

https://pharo.fogbugz.com/f/cases/20321/Add-build-number-to-SystemVersion

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

 

Tests are green

 

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-212/

 

The built image can be tested from here:

 

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-212/lastSuccessfulBuild/artifact/bootstrap-cache/

 

The build info is also shown in the About dialog. We show the same than what is found in built pharo artifacts in the file server.
 



 

Please review or go on and propose a change based on that. Remember that I'm leaving on vacations tomorrow.

 

Hope this is useful,

Guille

 
--




	
		
			
			   
			
			
			Guille Polito

			 

			Research Engineer

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

			 

			 

			Web: http://guillep.github.io

			Phone: +33 06 52 70 66 13
			
		
	

Re: [Pharo-dev] ZnEasy question

[Sven Van Caekenberghe]

Hi Milton,

> On 5 Aug 2017, at 03:15, milton mamani  wrote:
> 
> Hi to all
> 
> I want to use the next instruction in my code
> 
> response := ZnEasy get: 
> 'https://archive.softwareheritage.org/api/1/origin/git/url/https://github.com/hylang/hy'.
> response.
> 
> The previous code works from command line or in a webbrowser, but I does not 
> work with ZnEasy
> Because it takes the previous link as:
> a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy)
> 
> Could you please tell me what can I do for this situation?
> 
> Cheers,
> Milton

ZnUrl has indeed a problem parsing this URL. It skips empty path segments, 
we'll have to create an issue for that and we should try to fix it, maintaining 
current behaviour. The parser is hand written and has evolved a bit over the 
years, so it is a bit brittle. Seaside's WAUrl seems to have the same problem. 
It is funny that this only now comes up. Thanks for reporting it.

Here is a workaround, by manually creating a ZnUrl object from its elementary 
components.

ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; 
addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 
'hylang' 'hy'); yourself.

You can use this as follows.

ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; 
addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 
'hylang' 'hy'); retrieveContents.

ZnEasy get: (ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; 
addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 
'hylang' 'hy'); yourself).

Regards,

Sven

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

[Esteban Lorenzano]

> On 17 Aug 2017, at 17:37, Alistair Grant  wrote:
> 
> On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote:
>> 
>> 
>> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann :
>> 
>>Hi,
>> 
>>even when contributing to Pharo 7.0 is still very very cumbersome I was
>>able
>>to sort out most of the problems and contribute already a few smaller
>>things.
>> 
>>Unfortunately there is not much communication on what is currently in the
>>pipe
>>or planned on easing the process - which can easily lead to the impression
>>that we do not really move or slow us down.
>> 
>>I know step by step it goes and at least we have again the build process
>>rolling
>>https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-
>>starting-to-roll-for-real/
>> 
>>Nonetheless one of my PRs was already integrated and the integration of my
>>WebBrowser
>>package is still in the pipe (https://github.com/pharo-project/pharo/pull/
>>193)
>> 
>>The descriptions from Guille helped me - but there are still things I need
>>answers to:
>> 
>> 1. Will or is it still possible to automatically update" an image in 
>> Pharo
>>7
>>or in the future?
>>The World menu entry "System" -> "System update" has been removed?
>> 
>>Is this temporary of will it return once we know how it could be done
>>again?
>> 
>> 
>> You can update your image in Iceberg by switching to the updated #development
>> branch and then to reload all packages. In most cases it will probably work
>> fine but it does not know the right packages loading order, does not know
>> changes in the packages structure etc.
>> And some updates cannot be done at all (e.g. 
>> https://github.com/pharo-project/
>> pharo/pull/205). So you can expect troubles.
>> With Cargo we can get smoother updating process but trying to maintain it now
>> would be IMHO waste of resources.
>> 
>> -- Pavel
> 
> If the order is important...
> 
> Iceberg models the commits, so it should be possible to start at the
> head and trace back to the commit used to build the image.  The
> resulting list of commits could then be loaded in the correct order.
> (I don't know if this would help in the case of PR #205)

heh… no. Order of commits has nothing to do with order of loading packages. 
also: 
- class initialization has to happen
- migrate changed instances needs to be prepared pre and post change. 

while most of the time update packages “just works”, the case of slots for 
example will not work no matter the loading order, because we need to ensure 
some pre actions and post actions to happen.

I’m playing with the idea to extend iceberg with the capability of processing 
some information at package and class level (in package with manifests and in 
classes with class methods). Like adding #iceLoad, #iceUpdate methods (or 
#iceUpdateBefore and #iceUpdateAfter) so we can handle this… but this will not 
happen immediately (in case we decide it worths to have it) :)


> 
> Just to add a positive note to the conversation: I'm not very
> knowledgable about git, but it seems to be the best source control tool
> by far (based on my limited experience), and I've seen steady
> improvement in Iceberg since Esteban indicated that it would be the
> basis of source control for Pharo.  What I've seen so far makes me think
> that we are going down a good path, even if it is taking longer we would
> like and is causing some pain along the way.

nice!
and yes, this kind of changes take a lot of time… we are always too optimists 
and when we said “at least 3 months” we should have said double that time… but 
I’m happy with things as they are starting to fit. And in a couple of months we 
will be a full speed :)

cheers!
Esteban


> 
> 
> Cheers,
> Alistair
> 

[Pharo-dev] Adding build info into pharo runtime

[Guillermo Polito]

Hi all,

as asked by Torsten, I spent some time adding build info into the pharo
runtime.

https://pharo.fogbugz.com/f/cases/20321/Add-build-number-to-SystemVersion
https://github.com/pharo-project/pharo/pull/212

Tests are green

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-212/

The built image can be tested from here:

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-212/lastSuccessfulBuild/artifact/bootstrap-cache/

The build info is also shown in the About dialog. We show the same than
what is found in built pharo artifacts in the file server.

[image: Inline image 2]

Please review or go on and propose a change based on that. Remember that
I'm leaving on vacations tomorrow.

Hope this is useful,
Guille

-- 



Guille Polito


Research Engineer

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




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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

[Alistair Grant]

Hi Stef,

On Thu, Aug 17, 2017 at 05:08:40PM +0200, Stephane Ducasse wrote:
> I do not know but I imagine that I added basenameWithoutExtension because
> I found the name much much clearer. I would have never guessed that
> base is the basename without the extension.
> 
> Stef

Thanks for the clarification.  Although #base isn't the name without the
extension, it is the portion of the name up to the first extension
delimiter (for names with a single extension delimiter the two will of
course be the same, but for names with multiple extension delimiters
they will be different).

In that case, assuming no one else comes up with additional
information, I would argue that the issue should be closed (rejected),
and Michael should change his code to use #basenameWithoutExtension
instead of #base.

It would be nice to improve the comments in the code - I'll add it to my
list. :-)


Cheers,
Alistair


> On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant  wrote:
> > Hi All,
> >
> > I've just taken a look at issue 19609 FileReference>>base should be
> > before last separator and wonder whether it is a correct interpretation
> > of the original intentions.
> >
> > The original author of the issue, Michael, seems to feel that
> > FileReferene>>base and FileReference>>basenameWithoutExtension are the
> > same.
> >
> > My reading of the comments is that they perform a different function,
> > i.e.:
> >
> >
> > '/a/b/c.d.e' asFileReference base.  "c"
> > '/a/b/c.d.e' asFileReference basenameWithoutExtension.  "c.d"
> >
> >
> > are both the expected values, i.e.:
> >
> > - #base answers the name up to the first extensionDelimiter.
> > - #basenameWithoutExtension answers the name without what is typically
> >   considered the file extension (the bit after the last
> >   extensionDelimiter).
> >
> > Not shown above, but:
> >
> > - #basename answers the entire filename, i.e. "c.d.e".
> >
> >
> > Does anyone know the history of these methods?
> >
> >
> > Cheers,
> > Alistair
> >
> 

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

[Alistair Grant]

On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote:
> 
> 
> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann :
> 
> Hi,
> 
> even when contributing to Pharo 7.0 is still very very cumbersome I was
> able
> to sort out most of the problems and contribute already a few smaller
> things.
> 
> Unfortunately there is not much communication on what is currently in the
> pipe
> or planned on easing the process - which can easily lead to the impression
> that we do not really move or slow us down.
> 
> I know step by step it goes and at least we have again the build process
> rolling
> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-
> starting-to-roll-for-real/
> 
> Nonetheless one of my PRs was already integrated and the integration of my
> WebBrowser
> package is still in the pipe (https://github.com/pharo-project/pharo/pull/
> 193)
> 
> The descriptions from Guille helped me - but there are still things I need
> answers to:
> 
>  1. Will or is it still possible to automatically update" an image in 
> Pharo
> 7
> or in the future?
> The World menu entry "System" -> "System update" has been removed?
> 
> Is this temporary of will it return once we know how it could be done
> again?
> 
> 
> You can update your image in Iceberg by switching to the updated #development
> branch and then to reload all packages. In most cases it will probably work
> fine but it does not know the right packages loading order, does not know
> changes in the packages structure etc.
> And some updates cannot be done at all (e.g. https://github.com/pharo-project/
> pharo/pull/205). So you can expect troubles.
> With Cargo we can get smoother updating process but trying to maintain it now
> would be IMHO waste of resources.
> 
> -- Pavel

If the order is important...

Iceberg models the commits, so it should be possible to start at the
head and trace back to the commit used to build the image.  The
resulting list of commits could then be loaded in the correct order.
(I don't know if this would help in the case of PR #205)

Just to add a positive note to the conversation: I'm not very
knowledgable about git, but it seems to be the best source control tool
by far (based on my limited experience), and I've seen steady
improvement in Iceberg since Esteban indicated that it would be the
basis of source control for Pharo.  What I've seen so far makes me think
that we are going down a good path, even if it is taking longer we would
like and is causing some pain along the way.


Cheers,
Alistair

Re: [Pharo-dev] Issue that may break Epicea

[Guillermo Polito]

Ahh!! Yes, there is a test that fails from time to time, but nothing to do
with that PR I think.

Actually, Martin if you have some time to check, there is a cyclothymic
test that fails randomly on the CI. Maybe the test needs to be more robust.

On Thu, Aug 17, 2017 at 5:03 PM, Stephane Ducasse 
wrote:

> I do not know but tests broke when I integrated the changes.
>
> On Thu, Aug 17, 2017 at 10:59 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> Why would it break epicea?
>>
>> There is no major change in API. Only the method #createDirectory is
>> removed, but the only users are internal to the library. In my latest image
>> there are no Epicea users of it.
>>
>> On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> Hi martin
>>>
>>>
>>>  https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile
>>> https://github.com/pharo-project/pharo/pull/133
>>>
>>>
>>
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> 
>>
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


-- 



Guille Polito


Research Engineer

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




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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] 19609 FileReference>>base should be before last separator

[Stephane Ducasse]

I do not know but I imagine that I added basenameWithoutExtension because
I found the name much much clearer. I would have never guessed that
base is the basename without the extension.

Stef

On Wed, Aug 16, 2017 at 9:46 PM, Alistair Grant  wrote:
> Hi All,
>
> I've just taken a look at issue 19609 FileReference>>base should be
> before last separator and wonder whether it is a correct interpretation
> of the original intentions.
>
> The original author of the issue, Michael, seems to feel that
> FileReferene>>base and FileReference>>basenameWithoutExtension are the
> same.
>
> My reading of the comments is that they perform a different function,
> i.e.:
>
>
> '/a/b/c.d.e' asFileReference base.  "c"
> '/a/b/c.d.e' asFileReference basenameWithoutExtension.  "c.d"
>
>
> are both the expected values, i.e.:
>
> - #base answers the name up to the first extensionDelimiter.
> - #basenameWithoutExtension answers the name without what is typically
>   considered the file extension (the bit after the last
>   extensionDelimiter).
>
> Not shown above, but:
>
> - #basename answers the entire filename, i.e. "c.d.e".
>
>
> Does anyone know the history of these methods?
>
>
> Cheers,
> Alistair
>

Re: [Pharo-dev] Issue that may break Epicea

[Stephane Ducasse]

I do not know but tests broke when I integrated the changes.

On Thu, Aug 17, 2017 at 10:59 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Why would it break epicea?
>
> There is no major change in API. Only the method #createDirectory is
> removed, but the only users are internal to the library. In my latest image
> there are no Epicea users of it.
>
> On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse  > wrote:
>
>> Hi martin
>>
>>
>>  https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile
>> https://github.com/pharo-project/pharo/pull/133
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Dimitris Chloupis]

I remember my 10 year self struggling learning to code basic back in 1988
on an Amstrad CPC 6128 with Locomotive Basic that required entering line
numbers before the code statement. IDEs , code editors and what else were
unheard of for me at least and even if they did exist would be nowhere near
the budget of a 10 year old.

Nowdays we have a ton of options, easy access to it, its free , its open
source, insanely powerful and even documented. You can even find Youtube
tutorials if too lazy to read text and also a ton of examples and snippets
to get you started.

I agree 1000% with your argument that "batteries included" version is super
important, its one of the major reason why Python exploded in popularity.

But yeah I turn to Hulk every time I hear these dreaded 3 words "too many
options". I am willing to endure this hell of too many options and even
pray it gets much much worse. But then it may be just me :)

On Thu, Aug 17, 2017 at 5:50 PM Dimitris Chloupis 
wrote:

> On Thu, Aug 17, 2017 at 4:25 PM Esteban Lorenzano 
> wrote:
>
>> hi Dimitris (good to see you around ;) ),
>>
>>
> Not going anywhere , just taking a break from Pharo :)
>
>
>> thing is… we want to improve our tools.
>>
>> great
>
>
>> And improve tools sometime means to add stuff (I’m not very happy with it
>> either, I would like to remove more than what I add, but it is like that).
>> For example, if we want to have good class comments, we need some markup
>> format, then the best thing we have is pillar and then we need a parser and
>> then the easiest to use thing we have is petit parser.
>>
>
> Yeah.. about that. See the issue is exactly what you just mentioned ,
> improvement. Sometimes improving makes things worse. Markdown class
> comments is an excellent example of this. You do the logical thing and
> offer markdown for class comments , you make the image more complex by
> adding a feature the average user would need but you greatly improve your
> ability for class comments.
>
> But your average user does not even bother adding one line comment on the
> main class what are the chances that will use markdown ? I am willing to
> bet big money on "close to zero chance". Hence you end up making things
> actually worse by adding code that your user wont use and instead
> increasing the complexity and his motivation to explore and fall in love
> with your project.
>
>
>> Which means we will need an image that have a core PetitParser and a
>> basic Pillar… so we can have proper documentation. Of course, maybe the
>> full pillar is too much (as it is the full petit parser, probably) so we
>> need to think carefully what we put inside and what we left outside. Same
>> is with everything: why to put athens, or glamour, or X, Y, Z. (things that
>> few people use, but are very important for our echosystem in general).
>>
>
> Well if few people use them, how they are important to your ecosystem ? If
> you talking about dependencies then that means the ecosystem is deeply
> flawed and we go back to the modularity question. I fail to see how Athens
> is important to the Pharo ecosystem , apart from Roassal people I have not
> seen anyone else using it consistently.
>
> If you were talking about the UFFI I would agree 100% but I cannot agree
> by any means that Athens is so important for Pharo that must be included in
> the image. By the way I am a graphics guy so biased in favour of Athens.
>
>
>>
>>
> Now, along with this “bloating” movements, that adds more elements to the
>> system and because of that increases essential complexity, we are working
>> on the other direction: bootstrapping and modularising Pharo so in the near
>> future (it should be done for P7 or as late to P8) you will be able to
>> create an image with the elements you want.
>>
>> Another thing we need to work on (but that’s in part documentation and in
>> part modifications to be done) we need to work on overall
>> availability/comprehensibility of the system.
>>
>> So… we need to continue adding things, in order to continue improving. We
>> also need to remove a lot of things that are duplicated or obsolete.
>> Pharo will always be “the deliverable we make” (including all things we
>> officially support as “part of it”)… but we are making possible that
>> everybody can also do “the Pharo they want”.
>>
>
> I can understand having a Parser in image to parse Pharo syntax and other
> things, big thumbs up for that I think that would justify the inclusion for
> the average user. Parsing and dealing with text is a big deal afterall.
>
> I am ok with offering a minimal image and not being the default one. As
> long it exists I am happy.
>

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Dimitris Chloupis]

On Thu, Aug 17, 2017 at 4:25 PM Esteban Lorenzano 
wrote:

> hi Dimitris (good to see you around ;) ),
>
>
Not going anywhere , just taking a break from Pharo :)


> thing is… we want to improve our tools.
>
> great


> And improve tools sometime means to add stuff (I’m not very happy with it
> either, I would like to remove more than what I add, but it is like that).
> For example, if we want to have good class comments, we need some markup
> format, then the best thing we have is pillar and then we need a parser and
> then the easiest to use thing we have is petit parser.
>

Yeah.. about that. See the issue is exactly what you just mentioned ,
improvement. Sometimes improving makes things worse. Markdown class
comments is an excellent example of this. You do the logical thing and
offer markdown for class comments , you make the image more complex by
adding a feature the average user would need but you greatly improve your
ability for class comments.

But your average user does not even bother adding one line comment on the
main class what are the chances that will use markdown ? I am willing to
bet big money on "close to zero chance". Hence you end up making things
actually worse by adding code that your user wont use and instead
increasing the complexity and his motivation to explore and fall in love
with your project.


> Which means we will need an image that have a core PetitParser and a basic
> Pillar… so we can have proper documentation. Of course, maybe the full
> pillar is too much (as it is the full petit parser, probably) so we need to
> think carefully what we put inside and what we left outside. Same is with
> everything: why to put athens, or glamour, or X, Y, Z. (things that few
> people use, but are very important for our echosystem in general).
>

Well if few people use them, how they are important to your ecosystem ? If
you talking about dependencies then that means the ecosystem is deeply
flawed and we go back to the modularity question. I fail to see how Athens
is important to the Pharo ecosystem , apart from Roassal people I have not
seen anyone else using it consistently.

If you were talking about the UFFI I would agree 100% but I cannot agree by
any means that Athens is so important for Pharo that must be included in
the image. By the way I am a graphics guy so biased in favour of Athens.


>
>
Now, along with this “bloating” movements, that adds more elements to the
> system and because of that increases essential complexity, we are working
> on the other direction: bootstrapping and modularising Pharo so in the near
> future (it should be done for P7 or as late to P8) you will be able to
> create an image with the elements you want.
>
> Another thing we need to work on (but that’s in part documentation and in
> part modifications to be done) we need to work on overall
> availability/comprehensibility of the system.
>
> So… we need to continue adding things, in order to continue improving. We
> also need to remove a lot of things that are duplicated or obsolete.
> Pharo will always be “the deliverable we make” (including all things we
> officially support as “part of it”)… but we are making possible that
> everybody can also do “the Pharo they want”.
>

I can understand having a Parser in image to parse Pharo syntax and other
things, big thumbs up for that I think that would justify the inclusion for
the average user. Parsing and dealing with text is a big deal afterall.

I am ok with offering a minimal image and not being the default one. As
long it exists I am happy.

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[p...@highoctane.be]

Got an architecture discussion with a client this morning and a lot of pain
they face is that there are too many choices out there on some platforms.

A batteries included distro with one good framework doing its thing nicely
if really a good thing to have.

It reduces the amount of choice and thus allows to focus on the business
problem instead of diving into endless technical discussions.

Phil

On Thu, Aug 17, 2017 at 3:32 PM, Esteban Lorenzano 
wrote:

>
> On 17 Aug 2017, at 15:24, Esteban Lorenzano  wrote:
>
> hi Dimitris (good to see you around ;) ),
>
> thing is… we want to improve our tools.
>
> And improve tools sometime means to add stuff (I’m not very happy with it
> either, I would like to remove more than what I add, but it is like that).
> For example, if we want to have good class comments, we need some markup
> format, then the best thing we have is pillar and then we need a parser and
> then the easiest to use thing we have is petit parser.
>
> Which means we will need an image that have a core PetitParser and a basic
> Pillar… so we can have proper documentation. Of course, maybe the full
> pillar is too much (as it is the full petit parser, probably) so we need to
> think carefully what we put inside and what we left outside. Same is with
> everything: why to put athens, or glamour, or X, Y, Z. (things that few
> people use, but are very important for our echosystem in general).
>
>
> a corollary of this is that, if we think well and we include the correct
> addition, then it’s exponential (having a real parser inside can easy a lot
> of developments, and can also lead to better tools).
>
>
> Now, along with this “bloating” movements, that adds more elements to the
> system and because of that increases essential complexity, we are working
> on the other direction: bootstrapping and modularising Pharo so in the near
> future (it should be done for P7 or as late to P8) you will be able to
> create an image with the elements you want.
>
> Another thing we need to work on (but that’s in part documentation and in
> part modifications to be done) we need to work on overall
> availability/comprehensibility of the system.
>
> So… we need to continue adding things, in order to continue improving. We
> also need to remove a lot of things that are duplicated or obsolete.
> Pharo will always be “the deliverable we make” (including all things we
> officially support as “part of it”)… but we are making possible that
> everybody can also do “the Pharo they want”.
>
> cheers,
> Esteban
>
> On 17 Aug 2017, at 14:01, Dimitris Chloupis  wrote:
>
> Is it really necessary ?
>
> I am more a modular guy , I would love to get an image that 0.1% the size
> of the current one and offer me a convenient package manager to install the
> tools I like.
>
> I have used Pillar ALOT probably more than any other Pharo library because
> I was doing Pharo documentation stuff.
> I have even used Pillar to build my website , yeah I know that is not the
> pupose of Pillar but with some modification and the addition of a tool I
> created (Octopus) it help me generate some portion of the website via
> mustache.
>
> Do I want Pillar in ? Nope
>
> Already the System Browser looks like a monster ready to eat you alive, I
> think we need to make the image a lot less threatening especially for
> newcomers. There is such thing as too much info.
>
> Pillar is in the Package Browser you just click and install it if you dont
> mind the wait because its a rather big install.
>
> On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak  wrote:
>
>> Even though I've initiated this discussion I kind of stopped reading
>> because everyone started discussing completely unrelated things...
>>
>> The initial point was "we are using github/gitlab more and more, lets
>> leverage it more"
>>
>> New, lets separate the concepts at play here...
>>
>> "Pillar - document model" - the workhorse of pillar and (imho) the most
>> important part of it, and also the part I am interested in being included.
>> Because then I can generate the document directly without using any
>> syntax...
>>
>> "Pillar - syntax" - we can have endless arguments whether the syntax is
>> good or bad, and imho that should be a separate discussion unrelated to the
>> Pillar inclusion
>>
>> "Markdown for unrelated usecases" - whether you can or cannot write your
>> thesis in markdown is really irelevant here
>>
>> "Markdown - export" - there will always be different variants and
>> extensions for Markdown, simply because the sites using markdown offer
>> different capabilities.
>>
>> Therefore the first focus should be on the most impact/effort ratio,
>> which is CommonMark (basically the only meaningful Markdown specification),
>> and GFM (which is a CommonMark with added tables and strikethrough).
>>
>> Adding support for more extensive export support, whether code related
>> (e.g. GitLab), or code 

Re: [Pharo-dev] Can we have subclasses of Process?

[henry]

EventualProcess is in eventual_test [*], as example. Do not run 
RefsTest>>#testFailedArithmaticwithEventualArgument or will segfault vm.

- HH

[*] - http://www.squeaksource.com/TurquoiseTesting/eventual_test-hh.4.mcz

On Thu, Aug 17, 2017 at 08:33, Guillermo Polito  
wrote:

> I think there is no technical limitation for it, AFAIK, the VM never checks 
> the class of a process. I also proposed something like that in this paper:
>
> http://guillep.github.io/files/publications/Poli14b-IWST-GlobalStateClassification.pdf
>
> On Thu, Aug 17, 2017 at 2:24 PM, Max Leske  wrote:
>
>> I've used subclasses of process for the debugger stuff without problems.
>> Max
>>
>> On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisi...@gmail.com) wrote:
>>
>>> Hi.
>>>
>>> Is it allowed to subclass Process?  I remember that there were some 
>>> problems with it but I could not find any information.
>>>
>>> Generally I think about system processes which can be represented by 
>>> concrete subclasses. For example explicit UIProcess can be used to remove 
>>> many #isUIProcess conditions from system.
>>>
>>> Best regards,
>>> Denis
>
> --
>
> Guille Polito
>
> Research Engineer
>
> French National Center for Scientific Research - http://www.cnrs.fr
>
> Web: http://guillep.github.io
>
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] Issue that may break Epicea

[Martin Dias]

Hm, I'll take it into account anyway, thanks.
I miss coding in Pharo! I have to reserve some aftenoon to work in some
epicea open issues.
Cheers, Martin

On Thu, Aug 17, 2017 at 5:59 AM, Guillermo Polito  wrote:

> Why would it break epicea?
>
> There is no major change in API. Only the method #createDirectory is
> removed, but the only users are internal to the library. In my latest image
> there are no Epicea users of it.
>
> On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse  > wrote:
>
>> Hi martin
>>
>>
>>  https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile
>> https://github.com/pharo-project/pharo/pull/133
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Esteban Lorenzano]

> On 17 Aug 2017, at 15:24, Esteban Lorenzano  wrote:
> 
> hi Dimitris (good to see you around ;) ),
> 
> thing is… we want to improve our tools. 
> 
> And improve tools sometime means to add stuff (I’m not very happy with it 
> either, I would like to remove more than what I add, but it is like that). 
> For example, if we want to have good class comments, we need some markup 
> format, then the best thing we have is pillar and then we need a parser and 
> then the easiest to use thing we have is petit parser.
> 
> Which means we will need an image that have a core PetitParser and a basic 
> Pillar… so we can have proper documentation. Of course, maybe the full pillar 
> is too much (as it is the full petit parser, probably) so we need to think 
> carefully what we put inside and what we left outside. Same is with 
> everything: why to put athens, or glamour, or X, Y, Z. (things that few 
> people use, but are very important for our echosystem in general).

a corollary of this is that, if we think well and we include the correct 
addition, then it’s exponential (having a real parser inside can easy a lot of 
developments, and can also lead to better tools).

> 
> Now, along with this “bloating” movements, that adds more elements to the 
> system and because of that increases essential complexity, we are working on 
> the other direction: bootstrapping and modularising Pharo so in the near 
> future (it should be done for P7 or as late to P8) you will be able to create 
> an image with the elements you want.
> 
> Another thing we need to work on (but that’s in part documentation and in 
> part modifications to be done) we need to work on overall 
> availability/comprehensibility of the system.
> 
> So… we need to continue adding things, in order to continue improving. We 
> also need to remove a lot of things that are duplicated or obsolete. 
> Pharo will always be “the deliverable we make” (including all things we 
> officially support as “part of it”)… but we are making possible that 
> everybody can also do “the Pharo they want”. 
> 
> cheers, 
> Esteban
> 
>> On 17 Aug 2017, at 14:01, Dimitris Chloupis > > wrote:
>> 
>> Is it really necessary ?
>> 
>> I am more a modular guy , I would love to get an image that 0.1% the size of 
>> the current one and offer me a convenient package manager to install the 
>> tools I like. 
>> 
>> I have used Pillar ALOT probably more than any other Pharo library because I 
>> was doing Pharo documentation stuff. 
>> I have even used Pillar to build my website , yeah I know that is not the 
>> pupose of Pillar but with some modification and the addition of a tool I 
>> created (Octopus) it help me generate some portion of the website via 
>> mustache. 
>> 
>> Do I want Pillar in ? Nope
>> 
>> Already the System Browser looks like a monster ready to eat you alive, I 
>> think we need to make the image a lot less threatening especially for 
>> newcomers. There is such thing as too much info. 
>> 
>> Pillar is in the Package Browser you just click and install it if you dont 
>> mind the wait because its a rather big install. 
>> 
>> On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak > > wrote:
>> Even though I've initiated this discussion I kind of stopped reading because 
>> everyone started discussing completely unrelated things...
>> 
>> The initial point was "we are using github/gitlab more and more, lets 
>> leverage it more"
>> 
>> New, lets separate the concepts at play here...
>> 
>> "Pillar - document model" - the workhorse of pillar and (imho) the most 
>> important part of it, and also the part I am interested in being included. 
>> Because then I can generate the document directly without using any syntax...
>> 
>> "Pillar - syntax" - we can have endless arguments whether the syntax is good 
>> or bad, and imho that should be a separate discussion unrelated to the 
>> Pillar inclusion
>> 
>> "Markdown for unrelated usecases" - whether you can or cannot write your 
>> thesis in markdown is really irelevant here
>> 
>> "Markdown - export" - there will always be different variants and extensions 
>> for Markdown, simply because the sites using markdown offer different 
>> capabilities.
>> 
>> Therefore the first focus should be on the most impact/effort ratio, which 
>> is CommonMark (basically the only meaningful Markdown specification), and 
>> GFM (which is a CommonMark with added tables and strikethrough).
>> 
>> Adding support for more extensive export support, whether code related (e.g. 
>> GitLab), or code unrelated (writing a thesis) should be a future discussion, 
>> it is not relevant or too effortful right now.
>> 
>> "Markdown - import" - I would love to be able to write markdown and have it 
>> imported into the Pillar document model, however that is imho moot point 
>> right now, as it can always be added later
>> 
>> 
>> To 

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Esteban Lorenzano]

hi Dimitris (good to see you around ;) ),

thing is… we want to improve our tools. 

And improve tools sometime means to add stuff (I’m not very happy with it 
either, I would like to remove more than what I add, but it is like that). For 
example, if we want to have good class comments, we need some markup format, 
then the best thing we have is pillar and then we need a parser and then the 
easiest to use thing we have is petit parser.

Which means we will need an image that have a core PetitParser and a basic 
Pillar… so we can have proper documentation. Of course, maybe the full pillar 
is too much (as it is the full petit parser, probably) so we need to think 
carefully what we put inside and what we left outside. Same is with everything: 
why to put athens, or glamour, or X, Y, Z. (things that few people use, but are 
very important for our echosystem in general).

Now, along with this “bloating” movements, that adds more elements to the 
system and because of that increases essential complexity, we are working on 
the other direction: bootstrapping and modularising Pharo so in the near future 
(it should be done for P7 or as late to P8) you will be able to create an image 
with the elements you want.

Another thing we need to work on (but that’s in part documentation and in part 
modifications to be done) we need to work on overall 
availability/comprehensibility of the system.

So… we need to continue adding things, in order to continue improving. We also 
need to remove a lot of things that are duplicated or obsolete. 
Pharo will always be “the deliverable we make” (including all things we 
officially support as “part of it”)… but we are making possible that everybody 
can also do “the Pharo they want”. 

cheers, 
Esteban

> On 17 Aug 2017, at 14:01, Dimitris Chloupis  wrote:
> 
> Is it really necessary ?
> 
> I am more a modular guy , I would love to get an image that 0.1% the size of 
> the current one and offer me a convenient package manager to install the 
> tools I like. 
> 
> I have used Pillar ALOT probably more than any other Pharo library because I 
> was doing Pharo documentation stuff. 
> I have even used Pillar to build my website , yeah I know that is not the 
> pupose of Pillar but with some modification and the addition of a tool I 
> created (Octopus) it help me generate some portion of the website via 
> mustache. 
> 
> Do I want Pillar in ? Nope
> 
> Already the System Browser looks like a monster ready to eat you alive, I 
> think we need to make the image a lot less threatening especially for 
> newcomers. There is such thing as too much info. 
> 
> Pillar is in the Package Browser you just click and install it if you dont 
> mind the wait because its a rather big install. 
> 
> On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak  > wrote:
> Even though I've initiated this discussion I kind of stopped reading because 
> everyone started discussing completely unrelated things...
> 
> The initial point was "we are using github/gitlab more and more, lets 
> leverage it more"
> 
> New, lets separate the concepts at play here...
> 
> "Pillar - document model" - the workhorse of pillar and (imho) the most 
> important part of it, and also the part I am interested in being included. 
> Because then I can generate the document directly without using any syntax...
> 
> "Pillar - syntax" - we can have endless arguments whether the syntax is good 
> or bad, and imho that should be a separate discussion unrelated to the Pillar 
> inclusion
> 
> "Markdown for unrelated usecases" - whether you can or cannot write your 
> thesis in markdown is really irelevant here
> 
> "Markdown - export" - there will always be different variants and extensions 
> for Markdown, simply because the sites using markdown offer different 
> capabilities.
> 
> Therefore the first focus should be on the most impact/effort ratio, which is 
> CommonMark (basically the only meaningful Markdown specification), and GFM 
> (which is a CommonMark with added tables and strikethrough).
> 
> Adding support for more extensive export support, whether code related (e.g. 
> GitLab), or code unrelated (writing a thesis) should be a future discussion, 
> it is not relevant or too effortful right now.
> 
> "Markdown - import" - I would love to be able to write markdown and have it 
> imported into the Pillar document model, however that is imho moot point 
> right now, as it can always be added later
> 
> 
> To summarize:
> 
> * primary
> * include pillar document model
> * include pillar syntax (as an import format)
> * add CommonMark+GFM export
> * secondary
> * discuss Pillar syntax if needed (in a _new_ thread)
> * discuss Markdown parser / importing CommonMark into Pillar model
> * any other discussion not pertinent here should go elsewhere
> 
> Peter
> 
> 
> On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban 

Re: [Pharo-dev] Path * '' vs. Path workingDirectory

[Guillermo Polito]

On Mon, Aug 14, 2017 at 4:11 PM, Alistair Grant 
wrote:

> Hi Guille,
>
> Thanks for your reply.
>
>
> On Mon, Aug 14, 2017 at 01:44:41PM +0200, Guillermo Polito wrote:
> >
> >
> > On Sun, Aug 13, 2017 at 5:54 PM, Alistair Grant 
> wrote:
> >
> > Hi All,
> >
> > Is there any practical difference between (Path * '') and (Path
> > workingDirectory)?
> >
> >
> > Being strict, Path workingDirectory does not make any sense. A path is
> relative
> > or absolute.
>
> True, but Path is considered internal, so users shouldn't normally be
> calling Path>>workingDirectory.
>

Ah, I was thinking with Pablo the other day that it could be a nice small
and standalone library to manage paths. Then FileSystem can work on top.
What do you think?

That's why with Pablo we extracted the Path classes in a separate package
(FileSystem-Path). We also see it has few dependencies and this means that
it could go into the bootstrap :).


>
> I'm asking because the patch I'm preparing to improve canonicalisation
> affects the creation of the path in some instances ('.' asFileReference
> used to have a path with an empty segment, now it has Path
> workingDirectory).
>
> Just for the record :-)
>
> Path workingDirectory isRelative  " true"
>
>
> > And it is relative to some other path.
>
> Right, Pharo defines the image directory as the working directory (although
> https://github.com/pharo-project/pharo/pull/92 will change that to the
> more common shell interpretation of current working directory).
>
>
> > I'd expect that Path workingDirectory gives you an absolute path to the
> current
> > working directory,,,
>
> But the path doesn't have a file system to resolve against.
>
> Although even FileLocator workingDirectory gives a relative path.
>
>
>
> Thanks again,
> Alistair
>
>
>
> > Their internal representation is different:
> >
> > - (Path * '') has one empty segment
> > - Path workingDirectory has no segments
> >
> > But as far as I can tell they are otherwise the same:
> >
> >
> > | fs frEmpty frWD |
> >
> > fs := FileSystem disk.
> > frEmpty := FileReference fileSystem: fs path: (Path * '').
> > frWD := FileReference fileSystem: fs path: Path workingDirectory.
> > String streamContents: [ :stream |
> > stream
> > << 'frEmpty: ';
> > << frEmpty printString; cr;
> > << 'frWD: ';
> > << frWD printString; cr;
> > << '= : ';
> > << (frEmpty absolutePath = frWD absolutePath) printString;
> cr.
> > ]
> >
> > 'frEmpty: "File @ "
> > frWD: "File @ ."
> > = : true
> > '
> >
> >
> > Cheers,
> > Alistair
> >
> >
> >
> >
> >
> > --
> >  Guille Polito
> > [CNRS-filaire]
> >
> >  Research Engineer
> >
> >  French National Center for Scientific Research - http://
> >  www.cnrs.fr
> >
> >
> >
> >  Web: http://guillep.github.io
> >
> >  Phone: +33 06 52 70 66 13
> >
>
>


-- 



Guille Polito


Research Engineer

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




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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Can we have subclasses of Process?

[Guillermo Polito]

I think there is no technical limitation for it, AFAIK, the VM never checks
the class of a process. I also proposed something like that in this paper:

http://guillep.github.io/files/publications/Poli14b-IWST-GlobalStateClassification.pdf

On Thu, Aug 17, 2017 at 2:24 PM, Max Leske  wrote:

> I've used subclasses of process for the debugger stuff without problems.
>
> Max
>
>
>
> On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisi...@gmail.com)
> wrote:
>
> Hi.
>
> Is it allowed to subclass Process?  I remember that there were some
> problems with it but I could not find any information.
>
> Generally I think about system processes which can be represented by
> concrete subclasses. For example explicit UIProcess can be used to remove
> many #isUIProcess conditions from system.
>
> Best regards,
> Denis
>
>


-- 



Guille Polito


Research Engineer

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




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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Can we have subclasses of Process?

[Max Leske]

I've used subclasses of process for the debugger stuff without problems.

Max



On 17 August 2017 at 14:05:14, Denis Kudriashov (dionisi...@gmail.com)
wrote:

Hi.

Is it allowed to subclass Process?  I remember that there were some
problems with it but I could not find any information.

Generally I think about system processes which can be represented by
concrete subclasses. For example explicit UIProcess can be used to remove
many #isUIProcess conditions from system.

Best regards,
Denis

[Pharo-dev] Can we have subclasses of Process?

[Denis Kudriashov]

Hi.

Is it allowed to subclass Process?  I remember that there were some
problems with it but I could not find any information.

Generally I think about system processes which can be represented by
concrete subclasses. For example explicit UIProcess can be used to remove
many #isUIProcess conditions from system.

Best regards,
Denis

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Dimitris Chloupis]

Is it really necessary ?

I am more a modular guy , I would love to get an image that 0.1% the size
of the current one and offer me a convenient package manager to install the
tools I like.

I have used Pillar ALOT probably more than any other Pharo library because
I was doing Pharo documentation stuff.
I have even used Pillar to build my website , yeah I know that is not the
pupose of Pillar but with some modification and the addition of a tool I
created (Octopus) it help me generate some portion of the website via
mustache.

Do I want Pillar in ? Nope

Already the System Browser looks like a monster ready to eat you alive, I
think we need to make the image a lot less threatening especially for
newcomers. There is such thing as too much info.

Pillar is in the Package Browser you just click and install it if you dont
mind the wait because its a rather big install.

On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak  wrote:

> Even though I've initiated this discussion I kind of stopped reading
> because everyone started discussing completely unrelated things...
>
> The initial point was "we are using github/gitlab more and more, lets
> leverage it more"
>
> New, lets separate the concepts at play here...
>
> "Pillar - document model" - the workhorse of pillar and (imho) the most
> important part of it, and also the part I am interested in being included.
> Because then I can generate the document directly without using any
> syntax...
>
> "Pillar - syntax" - we can have endless arguments whether the syntax is
> good or bad, and imho that should be a separate discussion unrelated to the
> Pillar inclusion
>
> "Markdown for unrelated usecases" - whether you can or cannot write your
> thesis in markdown is really irelevant here
>
> "Markdown - export" - there will always be different variants and
> extensions for Markdown, simply because the sites using markdown offer
> different capabilities.
>
> Therefore the first focus should be on the most impact/effort ratio, which
> is CommonMark (basically the only meaningful Markdown specification), and
> GFM (which is a CommonMark with added tables and strikethrough).
>
> Adding support for more extensive export support, whether code related
> (e.g. GitLab), or code unrelated (writing a thesis) should be a future
> discussion, it is not relevant or too effortful right now.
>
> "Markdown - import" - I would love to be able to write markdown and have
> it imported into the Pillar document model, however that is imho moot point
> right now, as it can always be added later
>
>
> To summarize:
>
> * primary
> * include pillar document model
> * include pillar syntax (as an import format)
> * add CommonMark+GFM export
> * secondary
> * discuss Pillar syntax if needed (in a _new_ thread)
> * discuss Markdown parser / importing CommonMark into Pillar model
> * any other discussion not pertinent here should go elsewhere
>
> Peter
>
>
> On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote:
> > Hi,
> >
> > In general (you all know me), I have the policy of “do not go alien just
> because” which means we do not need to reinvent the wheel all the time and
> we need to stick with what is already there and known (I have pushed many
> changes in pharo following this direction, iceberg being just the latest),
> but we need to keep also the basis of what we are (which means: when we
> need to stay alien, we need to embrace it too).
> >
> > Said that: while I would LOVE to have a markdown compatible format, the
> amount of effort put on pillar to make it *what we need* and is a format
> used not just for doing README.md but to write books, etc., then replacing
> it would be complicated.
> >
> > but… I think we can do pillar syntax more “markdown alike” (and we can
> even have a stripped-pillar with would be even more like md), I would
> salute such change.
> >
> > cheers,
> > Esteban
> >
> >
> > > On 15 Aug 2017, at 19:23, Eliot Miranda 
> wrote:
> > >
> > >
> > >
> > > On Aug 15, 2017, at 7:25 AM, Ben Coman > wrote:
> > >
> > >>
> > >>
> > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <
> emaring...@gmail.com > wrote:
> > >> You hit several birds with one single mail.
> > >>
> > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon >:
> > >> > Jimmie et al. nicely reasoned arguments - and Doru's point about
> controlling
> > >> > the syntax is an interesting one that I hadn’t thought about.
> > >> >
> > >> > Personally, I find having too many similar syntax’s confusing -
> contributing
> > >> > to things is hard enough - having to remember that its !! Instead
> of ## and
> > >> > “” instead of ** is just frustrating for me.
> > >>
> > >> +1
> > >>
> > >> Not only for docs, most platforms like Slack/Discord share the syntax,
> > >> so now I'm getting "muscle memory" when 

Re: [Pharo-dev] @About posting here

[Dimitris Chloupis]

Could not agree more with entirety of your post.

Especially the part of the massive improvement of Pharo version 1 vs 6 are
like and day.

Documentation wise even Unreal with its massive community and one of the
most profitable game companies pouring massive resources has many doc
problems.

In perspective and taking the size of the community into account we do
great there too.

Personally I am running out of complains , my last ones is code completion
and bootstrapping.  I would like to thank all contributors for the amazing
work. Pharo is not perfect but it is improving blazing fast again taking
into account the size of the community.

So excited for the future :)

On Wed, 16 Aug 2017 at 17:27, p...@highoctane.be  wrote:

> I don't know why you think that anybody would silence you.
>
> Just the fact that you bother mentioning that is just a huge internal
> insecurity showcase to me.
>
> Come on, if we cared about popular opinions, this would be a javascript or
> nodejs list, not a Pharo list.
> I do not care a bit about popularity.
> I care about my  customers being happy and accounts receivable clearing up
> on time so that I can provide for people who depend on me.
>
> As far as I am concerned, you actively contributed to your channel volume
> being set to mute on my side.
> That's how you come across and get on my nerves. Not because of what you
> write. Because of how.
>
> I do not have a problem with critics against Pharo, I am cursing daily in
> front of it.
> So far, my level of cursing is lower when working with Pharo than with
> other tool chains.
>
> Pharo is there, I am happy for it to be around. Since the 1.x era, this
> thing has massively improved. Pharo 7 will be wonderful. Bootstrapping, how
> great. Massively great. Vector graphics, super. VM seeing major
> improvements and speedup. Roassal: awesome. GT: nothing can touch it.
> Community: packed to the gills with people who actually deliver working and
> innovative code. Want to be part of it? Your loss if you choose not to.
> Otherwise, welcome.
>
> Contribute whatever you can.
>
> Docs are in a bad state? Grab the docker image for book production at
> https://github.com/cdlm/docker-texlive
> Clone something like
> https://github.com/SquareBracketAssociates/Booklet-Glorp, make a book
> about some stuff and push.
>
> It is all tears in the rain anyway. As if I cared.
>
> Phil
>
> On Wed, Aug 16, 2017 at 12:52 PM, Frank-B 
> wrote:
>
>> Phil,
>>
>> nice attempt to drill and silence me! My advise: They all failed!
>>
>> If somebody can't cope with straight critics or unpopular opinions that
>> aint
>> my fault.
>>
>> Frank
>> who never worried about being labeled and
>> from a country where free speech is still welcome
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p4961628.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>

Re: [Pharo-dev] FileSystem fix integration

[Guillermo Polito]

FileSystem needs love, Thanks!

On Wed, Aug 16, 2017 at 9:22 PM, Alistair Grant 
wrote:

> Hi Stef,
>
> On Wed, Aug 16, 2017 at 08:43:24PM +0200, Stephane Ducasse wrote:
> > May be you already see it but
> > - https://pharo.fogbugz.com/f/cases/19609/FileReference-
> base-should-be-before-last-separator
> > https://github.com/pharo-project/pharo/pull/137
> > has a merge conflict
>
> I haven't looked at this at all.  I'll try and take a look it at soon
> (my daughter's birthday party this weekend, so time is limited :-)).
>
>
> > I will integrate now
> >
> > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile
> > https://github.com/pharo-project/pharo/pull/133
> >
> > and after when esteban is back we will integrate
> >
> > https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-
> linux-32-bit-VM
>
> I'm looking forward to this one :-)
>
> Cheers,
> Alistair
>
>
> > On Wed, Aug 16, 2017 at 3:42 PM, Alistair Grant 
> wrote:
> > > Hi Stef,
> > >
> > > On Wed, Aug 16, 2017 at 12:16:52PM +0200, Stephane Ducasse wrote:
> > >> I'm integrating 20307 and I would like to really thank you for
> > >> - the bug entry description
> > >> - all the comments
> > >> - and tests in the PR.
> > >>
> > >> Tx!!!
> > >
> > > Thanks for your kind words.
> > >
> > > And for integrating the PR :-)
> > >
> > >
> > > I've re-submitted 20165 Support segment path printing.
> > >
> > > So the open list is:
> > >
> > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment-
> path-printing
> > >   - https://github.com/pharo-project/pharo/pull/210
> > > Note that this is a different PR from before, see the comments in
> > > the issue.
> > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-
> EnsureCreateFile
> > > https://github.com/pharo-project/pharo/pull/133
> > > - https://pharo.fogbugz.com/f/cases/19609/FileReference-
> base-should-be-before-last-separator
> > > https://github.com/pharo-project/pharo/pull/137
> > > - https://pharo.fogbugz.com/f/cases/20294/Add-
> FileAttributesPlugin-to-the-linux-32-bit-VM
> > >   This is the first step in fixing FileReference>>isSymlink and
> > >   extending support for all file attributes returned by stat() and
> > >   lstat().
> > >   The parent issue is:
> > >   https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-
> to-be-broken-on-Linux
> > >
> > >
> > > Still to be closed (won't fix):
> > >
> > > - https://pharo.fogbugz.com/f/cases/18042
> > >   - https://github.com/pharo-project/pharo/pull/75
> > >
> > >
> > > And waiting on FFI / kernel resolution:
> > >
> > > - https://pharo.fogbugz.com/f/cases/5723/
> > >   - https://github.com/pharo-project/pharo/pull/92
> > >
> > >
> > > Cheers,
> > > Alistair
> > >
> > >
> >
>
>


-- 



Guille Polito


Research Engineer

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




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

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

[Esteban Lorenzano]

Hi,

> On 17 Aug 2017, at 11:28, Guillermo Polito  wrote:
> 
> 
> 
> On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann  > wrote:
> Hi,
> 
> even when contributing to Pharo 7.0 is still very very cumbersome I was able
> to sort out most of the problems and contribute already a few smaller things.
> 
> Unfortunately there is not much communication on what is currently in the pipe
> or planned on easing the process - which can easily lead to the impression
> that we do not really move or slow us down.
> 
> Vacations period…

most of us :)
I will be back next week :P

>  
> 
> I know step by step it goes and at least we have again the build process 
> rolling
> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-starting-to-roll-for-real/
>  
> 
> 
> Nonetheless one of my PRs was already integrated and the integration of my 
> WebBrowser
> package is still in the pipe (https://github.com/pharo-project/pharo/pull/193 
> )
> 
> Yes, I need to document better all the process with the baselines, I know :)
>  
> 
> The descriptions from Guille helped me - but there are still things I need
> answers to:
> 
>  1. Will or is it still possible to automatically update" an image in Pharo 7
> or in the future?
> The World menu entry "System" -> "System update" has been removed?
> 
> Is this temporary of will it return once we know how it could be done 
> again?
> 
>  
> AFAIU, this never worked "safely”.

yes, update is broken since *at least* Pharo 1.4.
I do not think is in our priorities to make it back since we are now 
bootstrapping (and is very different build process).

then… one of the plugins I would like to see is a “reload all packages 
following baseline” which will make it work on most cases. Still, it will not 
work 100% of the time (as Pavel points, there are issues that would simply not 
work updating… but this cases are not common).

Esteban

>  
> 
>  2. In latest Pharo 7.0 image there is a glitch that a method category
> has a typo in class "HEBinaryReaderWriter" and is "writting" instead of
> "writing".
> 
> Lets assume I want to fix such a simple problem. But Hermes was an 
> external package managed on GitHub.
> And it is now part of the image and therefore also in the "pharo" repo on 
> GitHub. So how is it
> maintainted/managed with the new process?
> 
> So do I fix this as a regular PR for Pharo 7 
> https://github.com/pharo-project/pharo 
> 
> or should it be fixed in the original repo 
> https://github.com/tesonep/hermes 
> and Hermes is synched from time to time into or from Pharo.
> 
> My answer to this is: until we support multiple code directories per 
> repository in iceberg (I think that's scheduled for next release), we kind of 
> have a fork (as we had before with the image and people committing to the 
> inbox).
> 
> The good way to do the fix on hermes should be, although a bit cumbersome, 
> the following:
>  - fix it in hermes repo
>  - then sync hermes with your pharo fork
>  - pull request for pharo
> 
> I know these are a lots of steps...
>  
> 
>  3. What still hit me most is that it is hard to identify the images and find 
> out
> how "new" they are.
> 
> Example: In Guilles example 
> https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo
>  
> 
>  it is written that one should use
> 
>   wget -O - get.pharo.org/70+vm  
> | bash
> 
>  This gives me an image file called "Pharo.image" and after a few days I 
> do not know how
>  old it is or what it was built from.
> 
>  When I start the image and look into the about box it gives me
> 
>  Pharo 7.0
>  Latest update: #0
> 
>  telling me nothing and when I run
> 
>  SystemVersion current
> 
>  it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also very 
> useless.
> 
> True, but if you inspect `SystemVersion` you'll see that it contains the 
> hash. Thus there are two issues:
>   - SystemVersion printing should include more info
>   - we should put build information into the image (so far it is only in the 
> zip archives in files.pharo.org )
> 
> The first issue should be easy to fix and maybe a good target for a guy 
> trying to make his first PR. 
> The second issue requires understanding a bit more the bootstrap process (I 
> need to write something more detailed about that, I know, but I'm on 
> vacations right now and from saturday I've no internet).
> 
> I can try to solve them today, I'll not be long I think.
>  
> 
>  Both do not tell me anything 

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

[Pavel Krivanek]

2017-08-17 10:44 GMT+02:00 Torsten Bergmann :

> Hi,
>
> even when contributing to Pharo 7.0 is still very very cumbersome I was
> able
> to sort out most of the problems and contribute already a few smaller
> things.
>
> Unfortunately there is not much communication on what is currently in the
> pipe
> or planned on easing the process - which can easily lead to the impression
> that we do not really move or slow us down.
>
> I know step by step it goes and at least we have again the build process
> rolling
> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-
> starting-to-roll-for-real/
>
> Nonetheless one of my PRs was already integrated and the integration of my
> WebBrowser
> package is still in the pipe (https://github.com/pharo-
> project/pharo/pull/193)
>
> The descriptions from Guille helped me - but there are still things I need
> answers to:
>
>  1. Will or is it still possible to automatically update" an image in
> Pharo 7
> or in the future?
> The World menu entry "System" -> "System update" has been removed?
>
> Is this temporary of will it return once we know how it could be done
> again?
>

You can update your image in Iceberg by switching to the updated
#development branch and then to reload all packages. In most cases it will
probably work fine but it does not know the right packages loading order,
does not know changes in the packages structure etc.
And some updates cannot be done at all (e.g.
https://github.com/pharo-project/pharo/pull/205). So you can expect
troubles.
With Cargo we can get smoother updating process but trying to maintain it
now would be IMHO waste of resources.

-- Pavel

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

[Guillermo Polito]

On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann  wrote:

> Hi,
>
> even when contributing to Pharo 7.0 is still very very cumbersome I was
> able
> to sort out most of the problems and contribute already a few smaller
> things.
>
> Unfortunately there is not much communication on what is currently in the
> pipe
> or planned on easing the process - which can easily lead to the impression
> that we do not really move or slow us down.
>

Vacations period...


>
> I know step by step it goes and at least we have again the build process
> rolling
> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-
> starting-to-roll-for-real/
>
> Nonetheless one of my PRs was already integrated and the integration of my
> WebBrowser
> package is still in the pipe (https://github.com/pharo-
> project/pharo/pull/193)
>

Yes, I need to document better all the process with the baselines, I know :)


>
> The descriptions from Guille helped me - but there are still things I need
> answers to:
>
>  1. Will or is it still possible to automatically update" an image in
> Pharo 7
> or in the future?
> The World menu entry "System" -> "System update" has been removed?
>
> Is this temporary of will it return once we know how it could be done
> again?
>
>
AFAIU, this never worked "safely".


>
>  2. In latest Pharo 7.0 image there is a glitch that a method category
> has a typo in class "HEBinaryReaderWriter" and is "writting" instead of
> "writing".
>
> Lets assume I want to fix such a simple problem. But Hermes was an
> external package managed on GitHub.
> And it is now part of the image and therefore also in the "pharo" repo
> on GitHub. So how is it
> maintainted/managed with the new process?
>
> So do I fix this as a regular PR for Pharo 7 https://github.com/pharo-
> project/pharo
> or should it be fixed in the original repo https://github.com/tesonep/
> hermes
> and Hermes is synched from time to time into or from Pharo.
>

My answer to this is: until we support multiple code directories per
repository in iceberg (I think that's scheduled for next release), we kind
of have a fork (as we had before with the image and people committing to
the inbox).

The good way to do the fix on hermes should be, although a bit cumbersome,
the following:
 - fix it in hermes repo
 - then sync hermes with your pharo fork
 - pull request for pharo

I know these are a lots of steps...


>
>  3. What still hit me most is that it is hard to identify the images and
> find out
> how "new" they are.
>
> Example: In Guilles example https://github.com/guillep/
> PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo
>  it is written that one should use
>
>   wget -O - get.pharo.org/70+vm | bash
>
>  This gives me an image file called "Pharo.image" and after a few days
> I do not know how
>  old it is or what it was built from.
>
>  When I start the image and look into the about box it gives me
>
>  Pharo 7.0
>  Latest update: #0
>
>  telling me nothing and when I run
>
>  SystemVersion current
>
>  it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also
> very useless.
>

True, but if you inspect `SystemVersion` you'll see that it contains the
hash. Thus there are two issues:
  - SystemVersion printing should include more info
  - we should put build information into the image (so far it is only in
the zip archives in files.pharo.org)

The first issue should be easy to fix and maybe a good target for a guy
trying to make his first PR.
The second issue requires understanding a bit more the bootstrap process (I
need to write something more detailed about that, I know, but I'm on
vacations right now and from saturday I've no internet).

I can try to solve them today, I'll not be long I think.


>
>  Both do not tell me anything about the build number!!! I can only
> guess the git commit from the name
>  of the sources file:
>
>Pharo7.0-32bit-c28bff9.sources
>
>  When I check https://github.com/pharo-project/pharo/commits/
> development with "c28bff9" then at least
>  I have an idea how old it is.
>
> Especially the last topic is a pain point and the most pressuring to be
> discussed - without a clear image build number
> in the version/about box nobody is able to reproduce in which image one
> run into trouble or he is basing his work on.
>
> I know during transition time we need more patience and things will get
> more stable and we make progress over
> time. But I whised we would have more communication on the overall topic
> (current work, plans, ...) on this list here.
>

Well, in part what I wanted as a first milestone is to reach the point
where the process is smooth enough to let people contribute. And well... at
that point people could contribute :)

This is my TODO list, if somebody wants to help:

On the CI and integration front:
 - automate integration mails
 - automate 

Re: [Pharo-dev] Issue that may break Epicea

[Guillermo Polito]

Why would it break epicea?

There is no major change in API. Only the method #createDirectory is
removed, but the only users are internal to the library. In my latest image
there are no Epicea users of it.

On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse 
wrote:

> Hi martin
>
>
>  https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile
> https://github.com/pharo-project/pharo/pull/133
>
>


-- 



Guille Polito


Research Engineer

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




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

*Phone: *+33 06 52 70 66 13

[Pharo-dev] Initial Feedback on Pharo 7 contribution process

[Torsten Bergmann]

Hi,

even when contributing to Pharo 7.0 is still very very cumbersome I was able 
to sort out most of the problems and contribute already a few smaller things.

Unfortunately there is not much communication on what is currently in the pipe
or planned on easing the process - which can easily lead to the impression
that we do not really move or slow us down.

I know step by step it goes and at least we have again the build process rolling
https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-starting-to-roll-for-real/

Nonetheless one of my PRs was already integrated and the integration of my 
WebBrowser 
package is still in the pipe (https://github.com/pharo-project/pharo/pull/193)

The descriptions from Guille helped me - but there are still things I need
answers to:

 1. Will or is it still possible to automatically update" an image in Pharo 7 
or in the future? 
The World menu entry "System" -> "System update" has been removed?

Is this temporary of will it return once we know how it could be done again?


 2. In latest Pharo 7.0 image there is a glitch that a method category
has a typo in class "HEBinaryReaderWriter" and is "writting" instead of 
"writing". 

Lets assume I want to fix such a simple problem. But Hermes was an external 
package managed on GitHub.
And it is now part of the image and therefore also in the "pharo" repo on 
GitHub. So how is it 
maintainted/managed with the new process? 

So do I fix this as a regular PR for Pharo 7 
https://github.com/pharo-project/pharo
or should it be fixed in the original repo https://github.com/tesonep/hermes
and Hermes is synched from time to time into or from Pharo.

 3. What still hit me most is that it is hard to identify the images and find 
out 
how "new" they are.

Example: In Guilles example 
https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo
 it is written that one should use

  wget -O - get.pharo.org/70+vm | bash

 This gives me an image file called "Pharo.image" and after a few days I do 
not know how
 old it is or what it was built from.

 When I start the image and look into the about box it gives me 

 Pharo 7.0
 Latest update: #0

 telling me nothing and when I run 

 SystemVersion current 

 it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also very 
useless.
 
 Both do not tell me anything about the build number!!! I can only guess 
the git commit from the name 
 of the sources file:

   Pharo7.0-32bit-c28bff9.sources

 When I check https://github.com/pharo-project/pharo/commits/development 
with "c28bff9" then at least 
 I have an idea how old it is.

Especially the last topic is a pain point and the most pressuring to be 
discussed - without a clear image build number
in the version/about box nobody is able to reproduce in which image one run 
into trouble or he is basing his work on.

I know during transition time we need more patience and things will get more 
stable and we make progress over
time. But I whised we would have more communication on the overall topic 
(current work, plans, ...) on this list here.
I have no idea who is working on what already regarding making the process more 
easier.

Thanks for any comments or own feedback you can share.

Regards
T.
   

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Peter Uhnak]

Even though I've initiated this discussion I kind of stopped reading because 
everyone started discussing completely unrelated things...

The initial point was "we are using github/gitlab more and more, lets 
leverage it more"

New, lets separate the concepts at play here...

"Pillar - document model" - the workhorse of pillar and (imho) the most 
important part of it, and also the part I am interested in being included. 
Because then I can generate the document directly without using any syntax...

"Pillar - syntax" - we can have endless arguments whether the syntax is good or 
bad, and imho that should be a separate discussion unrelated to the Pillar 
inclusion

"Markdown for unrelated usecases" - whether you can or cannot write your thesis 
in markdown is really irelevant here

"Markdown - export" - there will always be different variants and extensions 
for Markdown, simply because the sites using markdown offer different 
capabilities.

Therefore the first focus should be on the most impact/effort ratio, which is 
CommonMark (basically the only meaningful Markdown specification), and GFM 
(which is a CommonMark with added tables and strikethrough).

Adding support for more extensive export support, whether code related (e.g. 
GitLab), or code unrelated (writing a thesis) should be a future discussion, it 
is not relevant or too effortful right now.

"Markdown - import" - I would love to be able to write markdown and have it 
imported into the Pillar document model, however that is imho moot point right 
now, as it can always be added later


To summarize:

* primary
* include pillar document model 
* include pillar syntax (as an import format)
* add CommonMark+GFM export
* secondary
* discuss Pillar syntax if needed (in a _new_ thread)
* discuss Markdown parser / importing CommonMark into Pillar model
* any other discussion not pertinent here should go elsewhere

Peter


On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote:
> Hi, 
> 
> In general (you all know me), I have the policy of “do not go alien just 
> because” which means we do not need to reinvent the wheel all the time and we 
> need to stick with what is already there and known (I have pushed many 
> changes in pharo following this direction, iceberg being just the latest), 
> but we need to keep also the basis of what we are (which means: when we need 
> to stay alien, we need to embrace it too).
> 
> Said that: while I would LOVE to have a markdown compatible format, the 
> amount of effort put on pillar to make it *what we need* and is a format used 
> not just for doing README.md but to write books, etc., then replacing it 
> would be complicated. 
> 
> but… I think we can do pillar syntax more “markdown alike” (and we can even 
> have a stripped-pillar with would be even more like md), I would salute such 
> change.
> 
> cheers,
> Esteban
> 
> 
> > On 15 Aug 2017, at 19:23, Eliot Miranda  wrote:
> > 
> > 
> > 
> > On Aug 15, 2017, at 7:25 AM, Ben Coman  > > wrote:
> > 
> >> 
> >> 
> >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo 
> >> > wrote:
> >> You hit several birds with one single mail.
> >> 
> >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon  >> >:
> >> > Jimmie et al. nicely reasoned arguments - and Doru's point about 
> >> > controlling
> >> > the syntax is an interesting one that I hadn’t thought about.
> >> >
> >> > Personally, I find having too many similar syntax’s confusing - 
> >> > contributing
> >> > to things is hard enough - having to remember that its !! Instead of ## 
> >> > and
> >> > “” instead of ** is just frustrating for me.
> >> 
> >> +1
> >> 
> >> Not only for docs, most platforms like Slack/Discord share the syntax,
> >> so now I'm getting "muscle memory" when typing literals using the
> >> backtick (`) character, quoting with > or pasting snippets using ```
> >> 
> >> +1.  So I've posted this before...
> >>   
> >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/
> >>  
> >> 
> >> describing that "The only strategy in getting people to switch to your 
> >> product is to eliminate barriers"
> >> 
> >> But more... the best reason for Pillar to support a Markdown-ish syntax, 
> >> is that when we scratch-our-own-itch (nominally for Pillar) to build the 
> >> best damn markup-editor ever (because we can!) - if this happened to 
> >> support Markdown it can draw in Markdown-non-Pharo users (because its the 
> >> best editor ever!). Those users later want to make modifications, and now 
> >> have a *reason* to learn Pharo... ahHaA! now you see the cunning plan...
> >> 
> >> So don't just promote to people "hey come and play with this cool toy of 
> >> ours