Re: [Pharo-users] About balkanisation

[Esteban Lorenzano]

btw this is pharo-dev discussion, redirecting there.

Esteban

> On 7 Nov 2016, at 08:50, Esteban Lorenzano  wrote:
> 
> We are developing Iceberg… and I know is not enough :)
> Which “unifying tools” are you referring ?
> 
> I have followed very close your TOdE development… in a moment I was planning 
> a migration of it for pure-pharo, just… lack of time as always and then later 
> we started iceberg.
> now, we are in the process of defining a process ;) who works for pharo and 
> is the moment to build the bridges we need, but in general I think that 
> staying "with a foot in two boats” can just work during a very short lapse of 
> time, after that, the stream continues going and if you do not finish your 
> jump into one of the boats you will be very fast in the water. 
> 
> What I mean is that we can help any transition, but at the end there is no 
> way of having a “nice, coexisting” ecosystem: we will have one OR the other, 
> or something that does not works at all, but we will not have seamlessly one 
> AND the other (which does not means people using monticello will be forced to 
> use git tools or vice-versa, just that you will need to chose one… right now 
> many (many for real) of our problems come from the attempt of keeping our git 
> support behaving as regular monticello… and that way of doing has a limit. A 
> limit I think we already passed. 
> 
> Anyway, if you can list what you think we will need for the transition, I 
> will be very glad to see what we can do :)
> 
> Esteban
> 
>> On 7 Nov 2016, at 06:30, Dale Henrichs  
>> wrote:
>> 
>> 
>> 
>> On 11/6/16 1:12 PM, Tudor Girba wrote:
>>> Hi Stef,
>>> 
>>> I think that you are raising a valid point, and I actually agree with it.
>>> 
>>> But I think there is another side of the coin as well.
>>> 
>>> I think that right now we are in between worlds and this is not quite 
>>> beneficial. Switching to GitHub is a significant effort, and treating it as 
>>> business as usual will not work. That is why I think it is so important 
>>> that we committed to the move for Pharo 7 and that we invest in the 
>>> infrastructure. But, this will not be enough either if we do not get people 
>>> to exercise it as soon as possible.
>> Doru, there are also holes in the tool set that are not being addressed ... 
>> there are a number of critical tools that need to be created and I don't see 
>> anyone working on them 
>> 
>> I went through this transition 5 years ago with my tool set and with the 
>> proper set of tools approach the difficult transition will be a bit easier 
>> ...
>> 
>> As it stands Pharo is standing with one foot in two boats ... there are the 
>> old Monticello tools and the new Git/Filetree tools and what is needed is a 
>> tool or two that can unify to both tool sets so that the transition between 
>> the two can be seamless ... these two sets of tools are not complicated and 
>> there working implementations that can be adapted to Pharo or used as a 
>> fairly detailed guide ...
>> 
>> The confusion and frustration that I see now is not a surprise to me ... I 
>> wrote" the emails" at the beginning of this year because I saw that Pharo 
>> was finally reaching a critical point in its move to integrate git into the 
>> mainstream development environment and I knew that these types of issues 
>> were going to come up where Monticello and Git were going to create friction 
>> --- friction that can be reduced by creating some simple "unifying tools" ...
>> 
>> I want to help, I have tried to help and I am still willing to help, but I 
>> cannot write the tools for Pharo ...
>> 
>> Dale
>> 
> 

Re: [Pharo-users] About balkanisation

[Esteban Lorenzano]

We are developing Iceberg… and I know is not enough :)
Which “unifying tools” are you referring ?

I have followed very close your TOdE development… in a moment I was planning a 
migration of it for pure-pharo, just… lack of time as always and then later we 
started iceberg.
now, we are in the process of defining a process ;) who works for pharo and is 
the moment to build the bridges we need, but in general I think that staying 
"with a foot in two boats” can just work during a very short lapse of time, 
after that, the stream continues going and if you do not finish your jump into 
one of the boats you will be very fast in the water. 

What I mean is that we can help any transition, but at the end there is no way 
of having a “nice, coexisting” ecosystem: we will have one OR the other, or 
something that does not works at all, but we will not have seamlessly one AND 
the other (which does not means people using monticello will be forced to use 
git tools or vice-versa, just that you will need to chose one… right now many 
(many for real) of our problems come from the attempt of keeping our git 
support behaving as regular monticello… and that way of doing has a limit. A 
limit I think we already passed. 

Anyway, if you can list what you think we will need for the transition, I will 
be very glad to see what we can do :)

Esteban

> On 7 Nov 2016, at 06:30, Dale Henrichs  
> wrote:
> 
> 
> 
> On 11/6/16 1:12 PM, Tudor Girba wrote:
>> Hi Stef,
>> 
>> I think that you are raising a valid point, and I actually agree with it.
>> 
>> But I think there is another side of the coin as well.
>> 
>> I think that right now we are in between worlds and this is not quite 
>> beneficial. Switching to GitHub is a significant effort, and treating it as 
>> business as usual will not work. That is why I think it is so important that 
>> we committed to the move for Pharo 7 and that we invest in the 
>> infrastructure. But, this will not be enough either if we do not get people 
>> to exercise it as soon as possible.
> Doru, there are also holes in the tool set that are not being addressed ... 
> there are a number of critical tools that need to be created and I don't see 
> anyone working on them 
> 
> I went through this transition 5 years ago with my tool set and with the 
> proper set of tools approach the difficult transition will be a bit easier ...
> 
> As it stands Pharo is standing with one foot in two boats ... there are the 
> old Monticello tools and the new Git/Filetree tools and what is needed is a 
> tool or two that can unify to both tool sets so that the transition between 
> the two can be seamless ... these two sets of tools are not complicated and 
> there working implementations that can be adapted to Pharo or used as a 
> fairly detailed guide ...
> 
> The confusion and frustration that I see now is not a surprise to me ... I 
> wrote" the emails" at the beginning of this year because I saw that Pharo was 
> finally reaching a critical point in its move to integrate git into the 
> mainstream development environment and I knew that these types of issues were 
> going to come up where Monticello and Git were going to create friction --- 
> friction that can be reduced by creating some simple "unifying tools" ...
> 
> I want to help, I have tried to help and I am still willing to help, but I 
> cannot write the tools for Pharo ...
> 
> Dale
> 

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

[Nicolai Hess]

Am 06.11.2016 21:04 schrieb "Dimitris Chloupis" :
>
> yeah as I said the chapter needs a complete rewrite. I am not even it is
necessary to exist separately.
>
> On Sun, Nov 6, 2016 at 9:27 PM Nicolai Hess  wrote:
>>
>> 2016-11-03 15:11 GMT+01:00 Nicolai Hess :
>>>
>>>
>>>
>>> 2016-11-03 15:02 GMT+01:00 stepharo :

 Hi nicolai

 I started to work on the reflection chapter.
>>>
>>>
>>>
>>> The reflection chapter (and maybe some other too) could new some new
screenshots.
>>
>>
>> Actually, the reflection chapter needs some more rewrites (not only
updated screenshots). Some examples just aren't
>> applicable anymore because we don't have refactoring browser
preinstalled and although Nautilus can do alot, its missing
>> the full set of menus for creating scoped environments.
>> I'll try to rewrite those parts.
>>

 Now hacking PharoDoc :)

 Stef


 Le 3/11/16 à 14:29, Nicolai Hess a écrit :
>
>
>
> 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis :
>>
>> In case someone missed it I will be doing a release for version 5
(pharo version = pbe version) this weekend , since we had Pharo 7 initiated
few days ago.
>>
>> Essentially that means that the repo will be tagged for version 5,
which means a git commit is associated as a last commit for that version
and there will be a frozen release - download for Pharo by Example version
5. After that we move to Pharo By Example version 6 or PBE6 for short
>>
>> The repo wont change otherwise and the process of submitting
commits, pull requests and issues remains the same.
>>
>> If you have found a flaw of any sort in the documentation , please
open an issue in the github issue tracker that can be found here
>>
>>
https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
>>
>> I will try to fix any problem reported but if I cannot , the fix
will have to move to version 6
>>
>> As always thanks to all people contributing into the impossible 
making Pharo more amazing
>>
>> If you want to contribute feel free to do so with a pull request.
>>
>> Does not matter if you are beginner because even minor corrections
like correcting mistakes in the grammar or content of the text, updated
pictures, or just a few lines of extra info are more than enough and more
than welcomed. Many Pharo beginners have already done so .
>>
>> -Salute to fellow Guardians of The Light
>
>
> I found some problems, but I don't have time to report/fix them now,
I 'll try to report them
> later (today or tomorrow).
>
>

>>>

I know fixed most text in the chapter. At least there are no notes on tools
that aren't there anymore and I cut those things that aren't true anyone.
But I would like to do some more pass over it.
Instead of just cutting, we could add some new things.
Explaing the RB-Pattern syntax is maybe to much. But I would like to add it.
Maybe I'll put some notes on criticbrower and QA.

Re: [Pharo-users] about balkanisation

[p...@highoctane.be]

Mcz repos are useful.

STH storage works nicely, that's more the frontend which si bitrotting.

I actually have a local FTP based thing on my Synology and it is neat and
needs no time to work.

Did you ever look into Zinc and see there is also a server there for that?

Now, GitHub is better for sharing as there is the *critical mass* there.
And the tooling is very good.

And we can stuff a lot of other things than mcz in it (and with Git LFS
https://git-lfs.github.com/ we could even stuff images and mcz in there
right away. This thing is next in line for inclusion in
https://github.com/Pharophile/ExternalTools

In pvt chats on Slack, there is this tension between moving forward and
stabilizing stuff. I hope that with boostrap, we'll be able to have a
stable core and LTS assemblies.

Reinventing the wheel is fun. But it better has to be a better wheel.

Let's alway thing about our "normal"
https://www.youtube.com/watch?v=FvmTSpJU-Xc

We are at risk of boiling ourselves, in whatever plane we are.

I like the progress and I hate to have to adapt. But once past the curve,
life is actually better. Lots.

Phil




On Mon, Nov 7, 2016 at 5:29 AM, Igor Stasenko  wrote:

>
>
> On 6 November 2016 at 17:21, Stephan Eggermont  wrote:
>
>> Kilon wrote:
>> > If you really want to embrace Github , kill Smalltalkhub
>>
>> We are not close to doing that. We'll need
>> Monticello support indefinitely, and at least a few years two-way. And
>> that assumes we automatically migrate all open projects.
>>
>> First we need good workflows that also work for complex projects. That
>> includes cross-platform projects like Seaside
>>
>>
> Oh, come on! Throw away everything you had.. and start using something new
> and trendy, rinse and repeat. Profit!
> :)
>
>
>> Stephan
>>
>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-users] About balkanisation

[Tudor Girba]

Hi Dale,

I think I missed your mails. I would be interested in hearing your opinion. 
Let’s aim for a chat sometime next week. Would this work for you?

Cheers,
Doru


> On Nov 7, 2016, at 6:30 AM, Dale Henrichs  
> wrote:
> 
> 
> 
> On 11/6/16 1:12 PM, Tudor Girba wrote:
>> Hi Stef,
>> 
>> I think that you are raising a valid point, and I actually agree with it.
>> 
>> But I think there is another side of the coin as well.
>> 
>> I think that right now we are in between worlds and this is not quite 
>> beneficial. Switching to GitHub is a significant effort, and treating it as 
>> business as usual will not work. That is why I think it is so important that 
>> we committed to the move for Pharo 7 and that we invest in the 
>> infrastructure. But, this will not be enough either if we do not get people 
>> to exercise it as soon as possible.
> Doru, there are also holes in the tool set that are not being addressed ... 
> there are a number of critical tools that need to be created and I don't see 
> anyone working on them 
> 
> I went through this transition 5 years ago with my tool set and with the 
> proper set of tools approach the difficult transition will be a bit easier ...
> 
> As it stands Pharo is standing with one foot in two boats ... there are the 
> old Monticello tools and the new Git/Filetree tools and what is needed is a 
> tool or two that can unify to both tool sets so that the transition between 
> the two can be seamless ... these two sets of tools are not complicated and 
> there working implementations that can be adapted to Pharo or used as a 
> fairly detailed guide ...
> 
> The confusion and frustration that I see now is not a surprise to me ... I 
> wrote" the emails" at the beginning of this year because I saw that Pharo was 
> finally reaching a critical point in its move to integrate git into the 
> mainstream development environment and I knew that these types of issues were 
> going to come up where Monticello and Git were going to create friction --- 
> friction that can be reduced by creating some simple "unifying tools" ...
> 
> I want to help, I have tried to help and I am still willing to help, but I 
> cannot write the tools for Pharo ...
> 
> Dale
> 

--
www.tudorgirba.com
www.feenk.com

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/6/16 1:12 PM, Tudor Girba wrote:

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.
Doru, there are also holes in the tool set that are not being addressed 
... there are a number of critical tools that need to be created and I 
don't see anyone working on them 


I went through this transition 5 years ago with my tool set and with the 
proper set of tools approach the difficult transition will be a bit 
easier ...


As it stands Pharo is standing with one foot in two boats ... there are 
the old Monticello tools and the new Git/Filetree tools and what is 
needed is a tool or two that can unify to both tool sets so that the 
transition between the two can be seamless ... these two sets of tools 
are not complicated and there working implementations that can be 
adapted to Pharo or used as a fairly detailed guide ...


The confusion and frustration that I see now is not a surprise to me ... 
I wrote" the emails" at the beginning of this year because I saw that 
Pharo was finally reaching a critical point in its move to integrate git 
into the mainstream development environment and I knew that these types 
of issues were going to come up where Monticello and Git were going to 
create friction --- friction that can be reduced by creating some simple 
"unifying tools" ...


I want to help, I have tried to help and I am still willing to help, but 
I cannot write the tools for Pharo ...


Dale

Re: [Pharo-users] About balkanisation

[Dale Henrichs]

On 11/6/16 9:05 AM, stepharo wrote:

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(
Stef, I have been working with git/monticello projects for about 5 years 
now and have been using a "mixed system" during that entire time ... My 
message has been consistent that in order to make a smooth transition 
that you need some specific tools, now the fact that you guys are _not_ 
building those tools has been concerning me for some time now ... I sent 
mails at the beginning of this year a) describing the tools to the best 
of my ability and b) offering to help ... it seems that you are somehow 
blaming git/github for this problem ... and as I come to this discussion 
late others are blaming smalltalkhub ...


I don't think it is necessary to move everything to github, as I said, I 
have been using a "mixed system" for 5 years ... and I think that the 
problem lies in the lack of the proper tools ... of course your problems 
with Bloc may be actually totally unrelated to packages, but it is clear 
to me that you are frustrated with the environment ... and that is a 
tools problem!


I can and want to help.

I have had good discussions with the Pharo team, but I am afraid that I 
am not able to get my ... to me ... simple points across ... and it is 
frustrating to me that I am not able to successfully communicate the 
simple solutions that I see ...


I will repeat that Pharo is missing some very critical tools that I 
consider to be absolutely required (in some form) to be able to be 
successful ... the required tools do not take a phd to implement, they 
are very straightforward and simple ... perhaps they are not sexy and 
complicated so noone is interested, but they are required ...


If you want to have a conversation about this I am willing ... now it 
happens that I am in Buenos Aires (soon to be Tucuman) so this week is 
not convenient for me to talk ...


If you don't want to talk to me then look at the series of messages that 
I wrote last winter/spring to this mailing list (or pharo dev) where I 
described what I think you guys are missing ... and then ask me 
questions ...


Dale

Re: [Pharo-users] about balkanisation

[Igor Stasenko]

On 6 November 2016 at 17:21, Stephan Eggermont  wrote:

> Kilon wrote:
> > If you really want to embrace Github , kill Smalltalkhub
>
> We are not close to doing that. We'll need
> Monticello support indefinitely, and at least a few years two-way. And
> that assumes we automatically migrate all open projects.
>
> First we need good workflows that also work for complex projects. That
> includes cross-platform projects like Seaside
>
>
Oh, come on! Throw away everything you had.. and start using something new
and trendy, rinse and repeat. Profit!
:)


> Stephan
>
>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] may I please be added to the Mercap/HighchartsSt repo

[Mariano Martinez Peck]

Paul,

Quick comment: I was about to make an ANN soon but I have been
refactoring it a LOT these last days and I did:

1) make it fully the auto-generation code (already done)
2) making it work for highcharts 5.0.2 (already done)
3) start supporting highstocks (was going to start this this week).

Please please please grab the very last version. What are your plans with
it?

I just added you.

Cbest



On Sat, Nov 5, 2016 at 3:24 PM, PAUL DEBRUICKER  wrote:

> I'd like to add code that allows the creation of boxplots:
>
> http://www.highcharts.com/docs/chart-and-series-types/box-plot-series
>
>
> my username is pdebruic
>
>
> Thanks
>
>


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

Re: [Pharo-users] Pharo desktop UI

[vikenti]

Maybe you can give some brief explanaition how to create Spec-compatible custom 
UI control? (Like TextModel or ButtonModel, etc.) How to create model class, 
corresponding adapter and how to process common and custom UI events 
(mouse\keyboard\focus ordering\changing).
I think such guide should also be included in Spec booklet.

On Sun, 6 Nov 2016 10:01:39 -0800 (PST)
"jfabry [via Smalltalk]"  wrote:

> 
> 
> Hello Vikenti,
> 
> I think that you are using the SpecAdapter for morphs in ways it has never 
> been tried or used. So the problems you are having reveal bugs in the 
> SpecAdapter. Please file a bug report, and feel free to contribute a fix as 
> well of course ;-) (more about bugreports here: http://pharo.org/contribute )
> 
> --
> Does this mail seem too brief? Sorry for that, I don’t mean to be rude! 
> Please see http://emailcharter.org  .
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
> Chile
> 
> > On 05 Nov 2016, at 21:37, vikenti  wrote:
> > 
> > 
> > New problem with Spec. 
> > 
> > Layout consists of menu and custom control (subclass of Morph created by 
> > asSpecAdapter): 
> > initializeWidgets 
> > menu := self instantiate: MenuModel.
> > self setupMenu. 
> > menu applyTo: self. 
> > locationField := LocationFieldMorph new asSpecAdapter. 
> > 
> > defaultSpec 
> >  
> > ^ SpecLayout composed 
> > newColumn: 
> > [ :col | 
> > col 
> > add: #menu height: self toolbarHeight;  
> > add: #locationField 
> > ] yourself 
> > 
> > My custom control doesn't automatically resize to fill the area reserved to 
> > it by layout spec. 
> > I've tried different existed controls instead of mine but didn't find any 
> > solution. Some controls resized (TextModal) some didn't (Morph, 
> > BorderedMorph, EllipseMorph). 
> > 
> > I did a dirty hack: in onDraw: of my custom control i set bounds: to 
> > aCanvas clipRect and it works fine. 
> > 
> > drawOn: aCanvas 
> > self bounds: aCanvas clipRect . 
> >  other code  
> > 
> > But i think it is a wrong solution and there is somewhere a simple property 
> > to setup ( or something like it ). 
> > 
> > Any ideas? 
> 
> 
> 
> 
> 
> ___
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Pharo-desktop-UI-tp4921212p4921932.html
> 
> To unsubscribe from Pharo desktop UI, visit 
> http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code=4921212=dmlrZW50aS5wb3RhcG92QGdtYWlsLmNvbXw0OTIxMjEyfDIxNDcxNTYzMTI=


-- 
С уважением,
Викентий Потапов

http://vikenti.ru
тел.: +7 (917) 880 25 07 (г. Казань)




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

Re: [Pharo-users] Pharo Shared Memory with C++ executable

[Esteban Lorenzano]

> On 6 Nov 2016, at 22:17, Dimitris Chloupis  wrote:
> 
> 
> "Now my challenges after reading the UFFI documentation are the following 

oh crap… I forget I have to finish that :(
UFFO doc: back to my TODO list...

Esteban

> 
> 1) How I can pass things like O_CREAT , MAP_SHARED
> 2) How I cast a void pointer (its what mmap returns) to a C++ string or  C++ 
> int"
> 
> After carefully re-reading the documentation its seems the answer to question 
> 1 is that I will have to take the constant values from the header and follow 
> the instructions of the section "passing variables"
> 
>  About question 2, I could fetch the void pointer as return type , I know 
> that what returns is ExternalAdress pointer but have no idea how to fetch the 
> contents that the pointer points to. Maybe ByteArray>>integerAt:size:signed: 
> is what I am looking for ?
> 
> Will give it a try tomorrow. In the meanwhile I am open to suggestions.

Re: [Pharo-users] Pharo Shared Memory with C++ executable

[Dimitris Chloupis]

"Now my challenges after reading the UFFI documentation are the following

1) How I can pass things like O_CREAT , MAP_SHARED
2) How I cast a void pointer (its what mmap returns) to a C++ string or
 C++ int"

After carefully re-reading the documentation its seems the answer to
question 1 is that I will have to take the constant values from the header
and follow the instructions of the section "passing variables"

 About question 2, I could fetch the void pointer as return type , I know
that what returns is ExternalAdress pointer but have no idea how to fetch
the contents that the pointer points to. Maybe
ByteArray>>integerAt:size:signed: is what I am looking for ?

Will give it a try tomorrow. In the meanwhile I am open to suggestions.

Re: [Pharo-users] How to consume the MOOC?

[Luke Gorrie]

Hi Stepharo,

On 5 November 2016 at 18:14, stepharo  wrote:

> you can use the webportal (it supports subtitles in french and english -
> but read carefully what we wrote because we got trapped into a bug with
> certain configurations).
>
> http://rmod-pharo-mooc.lille.inria.fr/MOOC/WebPortal/co/pharo.html


Thanks for this link! I had somehow missed the webportal and this looks
like the right thing for me.

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

[Dimitris Chloupis]

yeah as I said the chapter needs a complete rewrite. I am not even it is
necessary to exist separately.

On Sun, Nov 6, 2016 at 9:27 PM Nicolai Hess  wrote:

> 2016-11-03 15:11 GMT+01:00 Nicolai Hess :
>
>
>
> 2016-11-03 15:02 GMT+01:00 stepharo :
>
> Hi nicolai
>
> I started to work on the reflection chapter.
>
>
>
> The reflection chapter (and maybe some other too) could new some new
> screenshots.
>
>
> Actually, the reflection chapter needs some more rewrites (not only
> updated screenshots). Some examples just aren't
> applicable anymore because we don't have refactoring browser preinstalled
> and although Nautilus can do alot, its missing
> the full set of menus for creating scoped environments.
> I'll try to rewrite those parts.
>
>
> Now hacking PharoDoc :)
>
> Stef
>
> Le 3/11/16 à 14:29, Nicolai Hess a écrit :
>
>
>
> 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis :
>
> In case someone missed it I will be doing a release for version 5 (pharo
> version = pbe version) this weekend , since we had Pharo 7 initiated few
> days ago.
>
> Essentially that means that the repo will be tagged for version 5, which
> means a git commit is associated as a last commit for that version and
> there will be a frozen release - download for Pharo by Example version 5.
> After that we move to Pharo By Example version 6 or PBE6 for short
>
> The repo wont change otherwise and the process of submitting commits, pull
> requests and issues remains the same.
>
> If you have found a flaw of any sort in the documentation , please open an
> issue in the github issue tracker that can be found here
>
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
>
> I will try to fix any problem reported but if I cannot , the fix will have
> to move to version 6
>
> As always thanks to all people contributing into the impossible 
> making Pharo more amazing
>
> If you want to contribute feel free to do so with a pull request.
>
> Does not matter if you are beginner because even minor corrections like
> correcting mistakes in the grammar or content of the text, updated
> pictures, or just a few lines of extra info are more than enough and more
> than welcomed. Many Pharo beginners have already done so .
>
> -Salute to fellow Guardians of The Light
>
>
> I found some problems, but I don't have time to report/fix them now, I 'll
> try to report them
> later (today or tomorrow).
>
>
>
>
>

Re: [Pharo-users] [ALERT] Pharo by Example version 5 is about to be released

[Nicolai Hess]

2016-11-03 15:11 GMT+01:00 Nicolai Hess :

>
>
> 2016-11-03 15:02 GMT+01:00 stepharo :
>
>> Hi nicolai
>>
>> I started to work on the reflection chapter.
>>
>
>
> The reflection chapter (and maybe some other too) could new some new
> screenshots.
>

Actually, the reflection chapter needs some more rewrites (not only updated
screenshots). Some examples just aren't
applicable anymore because we don't have refactoring browser preinstalled
and although Nautilus can do alot, its missing
the full set of menus for creating scoped environments.
I'll try to rewrite those parts.


> Now hacking PharoDoc :)
>>
>> Stef
>>
>> Le 3/11/16 à 14:29, Nicolai Hess a écrit :
>>
>>
>>
>> 2016-10-27 13:32 GMT+02:00 Dimitris Chloupis :
>>
>>> In case someone missed it I will be doing a release for version 5 (pharo
>>> version = pbe version) this weekend , since we had Pharo 7 initiated few
>>> days ago.
>>>
>>> Essentially that means that the repo will be tagged for version 5, which
>>> means a git commit is associated as a last commit for that version and
>>> there will be a frozen release - download for Pharo by Example version 5.
>>> After that we move to Pharo By Example version 6 or PBE6 for short
>>>
>>> The repo wont change otherwise and the process of submitting commits,
>>> pull requests and issues remains the same.
>>>
>>> If you have found a flaw of any sort in the documentation , please open
>>> an issue in the github issue tracker that can be found here
>>>
>>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/issues
>>>
>>> I will try to fix any problem reported but if I cannot , the fix will
>>> have to move to version 6
>>>
>>> As always thanks to all people contributing into the impossible 
>>> making Pharo more amazing
>>>
>>> If you want to contribute feel free to do so with a pull request.
>>>
>>> Does not matter if you are beginner because even minor corrections like
>>> correcting mistakes in the grammar or content of the text, updated
>>> pictures, or just a few lines of extra info are more than enough and more
>>> than welcomed. Many Pharo beginners have already done so .
>>>
>>> -Salute to fellow Guardians of The Light
>>>
>>
>> I found some problems, but I don't have time to report/fix them now, I
>> 'll try to report them
>> later (today or tomorrow).
>>
>>
>>
>>
>

Re: [Pharo-users] About balkanisation

[Offray Vladimir Luna Cárdenas]

And for us, without Git :-).

Offray


On 06/11/16 13:27, Dimitris Chloupis wrote:

I agree Pharo works great for me with Git apart from the file tree issue.
On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna Cárdenas 
> wrote:


Hi,

This thread derived on using GitHub, the transitions to it, the
mismatch
between the Smalltalk code model and the files code model. I would
like
to offer another view.

Pharo is working pretty well here. We have just finished our seventh
edition of the Data Week workshop+hackathon. This time we explored the
fossil DCVS and make some templates with mustache to
export/publish some
data visualizations. The infrastructure we have now doesn't get in our
way, installing the software with Catalog, updating with Monticello,
syncing changes while the workshop is happening, working with teapot,
tealight and the mustache binding all that went pretty smooth. The
supporting documentation for these tools was of great help.

Nicolas is making a good job in making the transition to Git/GitHub
smooth, but at the same time he is having a critical perspective
on git
and its workflow (which is not the best for every community, case or
project) and I think that's healthy, so we don't need to make Pharo
conform to git.

So I just want to add that there are other places and people
(mostly not
developers), here in Colombia, South America, that really appreciate
what the Pharo ecosystem, in its current form, is offering: its fluid,
uniform, connected, self contained, and powerful. It is a breath of
fresh air in the current overcomplicated technology. I just hope that
the migration and evolution preserve and maximize that. Keeping the
equilibrium between fast feedback, change, diversity, balkanisation,
visibility and hyper trendy is difficult, but hopefully the core
experience that Pharo is providing, will guide such equilibrium, and
continue to serve its several communities around the world.

Cheers,

Offray


On 06/11/16 07:05, stepharo wrote:
> Hi
>
> I would like that you think a bit about our community and that there
> is a value in using common tools
>
> to share and develop common libraries. Because to me it feels
like we
> are getting balkanize.
>
>
> It may look super cool and be hyper trendy to use github
(because like
> that you can say that you use latest hyper cool
>
> features), but I would like to ask especially people building
> libraries to pay attention that it is important
>
> that other people can contribute back easily and that there is
an easy
> way to load/contribute.
>
> Today I experienced Bloc
>
> - I cannot load code and I cannot contribute.
>
> - I saw mdl with a mixture between smalltalkhub and github
(sounds
> super hyper cool) and I saw paul not being able to contribute :(
>
>
> Yes you can say that monticello sucks yes it is terrible yes we all
> fell like Cobol programmers but at the end of the day.
>
> Yes the herb is always greener elsewhere. Yes yes yes. Let us take
> some facts.
>
> We managed pharo and moose with it over the last 8 years
successfully
> and Pharo and moose are not 5 packages together from
>
> what I can see. So pay attention about the decision you take.
>
> Now we will provide git support (this is 8 months that nicolas is
> exclusively working/thinking/dreaming
>
> about that) and that we are doing experiments (Guille is
managing the
> bootstrap in github).
>
> Now when everybody will have its own little project lost on
github (I
> do not count the amount of time I do not find pillar on github
because
> I forget
>
> that it is called pillar-markup), what will we do.
>
> So we need an infrastructure to handle this and christophe is
working
> on this.
>
> I think that you should consider the accidental complexity as
> something that we can minimise by using patterns and common
practices.
>
> Now you can think that I'm an idiot and that I have no vision (be my
> guest) but we should pay attention because we are a small community.
>
> Stef
>
>
>
>
>

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

The commit messages, say nothing about the commits

On Sun, 6 Nov 2016 at 17:47, Sven Van Caekenberghe  wrote:

>
> > On 6 Nov 2016, at 16:27, Dimitris Chloupis 
> wrote:
> >
> > A biggy one is the pharo repo of the pharo image on github. Its a mess.
> >
> > https://github.com/pharo-project/pharo-core/commits/6.0
> >
> > seriously, Github makes us visible , this does not look good at all.
>
> why not ? how is this different from a multi file commit in any other
> language ?
>
>
>

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

I agree Pharo works great for me with Git apart from the file tree issue.
On Sun, 6 Nov 2016 at 20:22, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
> This thread derived on using GitHub, the transitions to it, the mismatch
> between the Smalltalk code model and the files code model. I would like
> to offer another view.
>
> Pharo is working pretty well here. We have just finished our seventh
> edition of the Data Week workshop+hackathon. This time we explored the
> fossil DCVS and make some templates with mustache to export/publish some
> data visualizations. The infrastructure we have now doesn't get in our
> way, installing the software with Catalog, updating with Monticello,
> syncing changes while the workshop is happening, working with teapot,
> tealight and the mustache binding all that went pretty smooth. The
> supporting documentation for these tools was of great help.
>
> Nicolas is making a good job in making the transition to Git/GitHub
> smooth, but at the same time he is having a critical perspective on git
> and its workflow (which is not the best for every community, case or
> project) and I think that's healthy, so we don't need to make Pharo
> conform to git.
>
> So I just want to add that there are other places and people (mostly not
> developers), here in Colombia, South America, that really appreciate
> what the Pharo ecosystem, in its current form, is offering: its fluid,
> uniform, connected, self contained, and powerful. It is a breath of
> fresh air in the current overcomplicated technology. I just hope that
> the migration and evolution preserve and maximize that. Keeping the
> equilibrium between fast feedback, change, diversity, balkanisation,
> visibility and hyper trendy is difficult, but hopefully the core
> experience that Pharo is providing, will guide such equilibrium, and
> continue to serve its several communities around the world.
>
> Cheers,
>
> Offray
>
>
> On 06/11/16 07:05, stepharo wrote:
> > Hi
> >
> > I would like that you think a bit about our community and that there
> > is a value in using common tools
> >
> > to share and develop common libraries. Because to me it feels like we
> > are getting balkanize.
> >
> >
> > It may look super cool and be hyper trendy to use github (because like
> > that you can say that you use latest hyper cool
> >
> > features), but I would like to ask especially people building
> > libraries to pay attention that it is important
> >
> > that other people can contribute back easily and that there is an easy
> > way to load/contribute.
> >
> > Today I experienced Bloc
> >
> > - I cannot load code and I cannot contribute.
> >
> > - I saw mdl with a mixture between smalltalkhub and github (sounds
> > super hyper cool) and I saw paul not being able to contribute :(
> >
> >
> > Yes you can say that monticello sucks yes it is terrible yes we all
> > fell like Cobol programmers but at the end of the day.
> >
> > Yes the herb is always greener elsewhere. Yes yes yes. Let us take
> > some facts.
> >
> > We managed pharo and moose with it over the last 8 years successfully
> > and Pharo and moose are not 5 packages together from
> >
> > what I can see. So pay attention about the decision you take.
> >
> > Now we will provide git support (this is 8 months that nicolas is
> > exclusively working/thinking/dreaming
> >
> > about that) and that we are doing experiments (Guille is managing the
> > bootstrap in github).
> >
> > Now when everybody will have its own little project lost on github (I
> > do not count the amount of time I do not find pillar on github because
> > I forget
> >
> > that it is called pillar-markup), what will we do.
> >
> > So we need an infrastructure to handle this and christophe is working
> > on this.
> >
> > I think that you should consider the accidental complexity as
> > something that we can minimise by using patterns and common practices.
> >
> > Now you can think that I'm an idiot and that I have no vision (be my
> > guest) but we should pay attention because we are a small community.
> >
> > Stef
> >
> >
> >
> >
> >
>
>
>

Re: [Pharo-users] About balkanisation

[Offray Vladimir Luna Cárdenas]

Hi,

This thread derived on using GitHub, the transitions to it, the mismatch 
between the Smalltalk code model and the files code model. I would like 
to offer another view.


Pharo is working pretty well here. We have just finished our seventh 
edition of the Data Week workshop+hackathon. This time we explored the 
fossil DCVS and make some templates with mustache to export/publish some 
data visualizations. The infrastructure we have now doesn't get in our 
way, installing the software with Catalog, updating with Monticello, 
syncing changes while the workshop is happening, working with teapot, 
tealight and the mustache binding all that went pretty smooth. The 
supporting documentation for these tools was of great help.


Nicolas is making a good job in making the transition to Git/GitHub 
smooth, but at the same time he is having a critical perspective on git 
and its workflow (which is not the best for every community, case or 
project) and I think that's healthy, so we don't need to make Pharo 
conform to git.


So I just want to add that there are other places and people (mostly not 
developers), here in Colombia, South America, that really appreciate 
what the Pharo ecosystem, in its current form, is offering: its fluid, 
uniform, connected, self contained, and powerful. It is a breath of 
fresh air in the current overcomplicated technology. I just hope that 
the migration and evolution preserve and maximize that. Keeping the 
equilibrium between fast feedback, change, diversity, balkanisation, 
visibility and hyper trendy is difficult, but hopefully the core 
experience that Pharo is providing, will guide such equilibrium, and 
continue to serve its several communities around the world.


Cheers,

Offray


On 06/11/16 07:05, stepharo wrote:

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all 
fell like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take 
some facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I 
do not count the amount of time I do not find pillar on github because 
I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working 
on this.


I think that you should consider the accidental complexity as 
something that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef

Re: [Pharo-users] Pharo desktop UI

[Johan Fabry]

Hello Vikenti,

I think that you are using the SpecAdapter for morphs in ways it has never been 
tried or used. So the problems you are having reveal bugs in the SpecAdapter. 
Please file a bug report, and feel free to contribute a fix as well of course 
;-) (more about bugreports here: http://pharo.org/contribute )

--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please 
see http://emailcharter.org  .

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

> On 05 Nov 2016, at 21:37, vikenti  wrote:
> 
> 
> New problem with Spec. 
> 
> Layout consists of menu and custom control (subclass of Morph created by 
> asSpecAdapter): 
> initializeWidgets 
> menu := self instantiate: MenuModel.  
> self setupMenu. 
> menu applyTo: self. 
> locationField := LocationFieldMorph new asSpecAdapter. 
> 
> defaultSpec 
>  
> ^ SpecLayout composed 
> newColumn: 
> [ :col | 
> col 
> add: #menu height: self toolbarHeight;
> add: #locationField 
> ] yourself 
> 
> My custom control doesn't automatically resize to fill the area reserved to 
> it by layout spec. 
> I've tried different existed controls instead of mine but didn't find any 
> solution. Some controls resized (TextModal) some didn't (Morph, 
> BorderedMorph, EllipseMorph). 
> 
> I did a dirty hack: in onDraw: of my custom control i set bounds: to aCanvas 
> clipRect and it works fine. 
> 
> drawOn: aCanvas 
> self bounds: aCanvas clipRect . 
>  other code  
> 
> But i think it is a wrong solution and there is somewhere a simple property 
> to setup ( or something like it ). 
> 
> Any ideas? 

[Pharo-users] Pharo Shared Memory with C++ executable

[Dimitris Chloupis]

Hey fellow Pharoers

I have great news, I was able to finally  understand how shared memory
file works and actually do it

Why is that great news you may ask.

A shared memory file is a file that maps a specific area of memory, which
means when you write to a specific part of the memory it writes directly to
the file without you having to actually do this. Memory mapped files have
the distinct characteristic of being able to share memory between
processes. This actually is the fastest way to make two process communicate
and exchange data.

Its called Inter Process Communication or IPC for short , but is not
technically communication because both executables share the memory.

This means that its possible to make Pharo use C++ libraries from inside a
C++ executable. Because basically the shared memory will allow Pharo and
the C++ executables to share data, part of that data can be messages to
execute specific functions.

What is super cool about shared memory mapped files is not only that they
are super fast(its what the OS uses to load shared libraries ie. DLLs) ,
its not that it automagically stores the shared memory to disk like a Pharo
image (so we can store live data) but foremost that a great deal of
programming languages can use Memory Mapped Files which basically means
they have wrapped the mmap functions of the LibC library (C/C++ Standard
Library).

That means we can now use this to make Pharo able to use C++ libraries,
python libraries and any library from any programming language. Its also a
solution when you dont have access to a DLL or making one is very hard like
in my case that I use Unreal Engine. As you can imagine this will
replace/extend my socket bridge that I made for python.

Of course all the above are no magic, you have to have some basic
understanding of how C++ works and how memory mapped files work, funny
thing is that shared memory is actually simpler to understand than C++. You
also have to make the messaging system and manage the synchronisation. But
those are details which I will implement anyway.

So my challenge right now is to move this to Pharo. I have done it with
C++, I made two different executables which share a string with the value
"hello".

I need two functions to do this one is open, which is the classic way to
open files in C/C++ in my case is

#define FILEPATH "mmapped.bin"
 fd = open(FILEPATH, O_RDWR | O_CREAT | O_TRUNC, (mode_t)0600);

https://linux.die.net/man/3/open

second one is lseek which expand the size of the file to a desired size

result = lseek(fd, FILESIZE-1, SEEK_SET);

http://man7.org/linux/man-pages/man2/lseek.2.html

the third one is mmap which is doing the actually mapping of the shared
memory

 map =(std::string*) mmap(0, FILESIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, 0);

http://man7.org/linux/man-pages/man2/mmap.2.html

Now my challenges after reading the UFFI documentation are the following

1) How I can pass things like O_CREAT , MAP_SHARED
2) How I cast a void pointer (its what mmap returns) to a C++ string or
 C++ int

In case you want to take a look at the code is part of a project I named
Atlas which can be found here

https://github.com/kilon/Atlas

The file atlas-server.cpp creates the memory mapped file and writes to the
shared memory the string "hello"

The file atlas-client.cpp gains access to the shared memory and retrieves
the "hello" string

Atlas basically will be the library that will give Pharo full access to
Unreal internals.

Re: [Pharo-users] about balkanisation

[stepharo]

Le 6/11/16 à 17:21, Stephan Eggermont a écrit :

Kilon wrote:

If you really want to embrace Github , kill Smalltalkhub

We are not close to doing that. We'll need
Monticello support indefinitely, and at least a few years two-way. And that 
assumes we automatically migrate all open projects.


We decided that iceberg will support one way from MC -> github but not 
the inverse because we do not have the ressources.


First we need good workflows that also work for complex projects. That includes 
cross-platform projects like Seaside
We should be able to manage Pharo with the external projects composing 
it. Moose Seaside should be working too.


So yes this is why guille spent some time building cases and evaluate 
solutions (submodules vs subtrees vs under one umbrella)

with pull requests between subprojects and the rest



Stephan

Re: [Pharo-users] About balkanisation

[stepharo]

Le 6/11/16 à 17:12, Tudor Girba a écrit :

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.


Yes this what we decided.

To give an example. When the first version of Iceberg was announced, I started 
to use it for a couple of projects. I stumbled across problems that prevented 
me from working for several weeks. I could have easily switched to 
SmalltalkHub, but I did not. I connected with Nicolas and we worked through 
those problems. Btw, Nicolas is doing a wonderful job, and people should not 
take this for granted. He tends to be shy, so if you see him around, please 
give him a hug and let him know that we count on him. Or better yet, use 
Iceberg for your projects and send him your feedback :).


Yes people should try but should pay attention for libraries.

I am sure that there are more problems ahead, and the only way to go through 
them is committing to go through them. This will push us back for a while, but 
I really believe in the promise once we get on the other side. I actually think 
that GitHub is not really a good match for Pharo from a conceptual point of 
view (the mismatch between what it offers and what we need is quite large), but 
it is an engineering decision that makes perfect sense for the future. So, yes, 
we should take GitHub with a grain of salt, and make it a goal to not change 
much our concept of what makes sense for Pharo. For example, we should not give 
up on having to resort to the file system. That is why it is so important to 
make Iceberg (this is not for you Stef because I know you know it, but for 
others :)).

And I certainly agree that we should look for sane patterns, but as it goes 
with patterns, they emerge out of practice.

I think we should aim for limiting the time of being in between the two worlds. 
It will not be pleasant, and we can only do it if we stick together and go 
through it as soon as possible.


This why I mentioned that we should pay attention to create different 
versions




Cheers,
Doru





On Nov 6, 2016, at 1:05 PM, stepharo  wrote:

Hi

I would like that you think a bit about our community and that there is a value 
in using common tools

to share and develop common libraries. Because to me it feels like we are 
getting balkanize.


It may look super cool and be hyper trendy to use github (because like that you 
can say that you use latest hyper cool

features), but I would like to ask especially people building libraries to pay 
attention that it is important

that other people can contribute back easily and that there is an easy way to 
load/contribute.

Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds super 
hyper cool) and I saw paul not being able to contribute :(


Yes you can say that monticello sucks yes it is terrible yes we all fell like 
Cobol programmers but at the end of the day.

Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.

We managed pharo and moose with it over the last 8 years successfully and Pharo 
and moose are not 5 packages together from

what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is exclusively 
working/thinking/dreaming

about that) and that we are doing experiments (Guille is managing the bootstrap 
in github).

Now when everybody will have its own little project lost on github (I do not 
count the amount of time I do not find pillar on github because I forget

that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working on this.

I think that you should consider the accidental complexity as something that we 
can minimise by using patterns and common practices.

Now you can think that I'm an idiot and that I have no vision (be my guest) but 
we should pay attention because we are a small community.

Stef





--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-users] about balkanisation

[Stephan Eggermont]

Kilon wrote:
> If you really want to embrace Github , kill Smalltalkhub

We are not close to doing that. We'll need 
Monticello support indefinitely, and at least a few years two-way. And that 
assumes we automatically migrate all open projects. 

First we need good workflows that also work for complex projects. That includes 
cross-platform projects like Seaside

Stephan

Re: [Pharo-users] About balkanisation

[Tudor Girba]

Hi Stef,

I think that you are raising a valid point, and I actually agree with it.

But I think there is another side of the coin as well.

I think that right now we are in between worlds and this is not quite 
beneficial. Switching to GitHub is a significant effort, and treating it as 
business as usual will not work. That is why I think it is so important that we 
committed to the move for Pharo 7 and that we invest in the infrastructure. 
But, this will not be enough either if we do not get people to exercise it as 
soon as possible.

To give an example. When the first version of Iceberg was announced, I started 
to use it for a couple of projects. I stumbled across problems that prevented 
me from working for several weeks. I could have easily switched to 
SmalltalkHub, but I did not. I connected with Nicolas and we worked through 
those problems. Btw, Nicolas is doing a wonderful job, and people should not 
take this for granted. He tends to be shy, so if you see him around, please 
give him a hug and let him know that we count on him. Or better yet, use 
Iceberg for your projects and send him your feedback :).

I am sure that there are more problems ahead, and the only way to go through 
them is committing to go through them. This will push us back for a while, but 
I really believe in the promise once we get on the other side. I actually think 
that GitHub is not really a good match for Pharo from a conceptual point of 
view (the mismatch between what it offers and what we need is quite large), but 
it is an engineering decision that makes perfect sense for the future. So, yes, 
we should take GitHub with a grain of salt, and make it a goal to not change 
much our concept of what makes sense for Pharo. For example, we should not give 
up on having to resort to the file system. That is why it is so important to 
make Iceberg (this is not for you Stef because I know you know it, but for 
others :)).

And I certainly agree that we should look for sane patterns, but as it goes 
with patterns, they emerge out of practice.

I think we should aim for limiting the time of being in between the two worlds. 
It will not be pleasant, and we can only do it if we stick together and go 
through it as soon as possible.

Cheers,
Doru




> On Nov 6, 2016, at 1:05 PM, stepharo  wrote:
> 
> Hi
> 
> I would like that you think a bit about our community and that there is a 
> value in using common tools
> 
> to share and develop common libraries. Because to me it feels like we are 
> getting balkanize.
> 
> 
> It may look super cool and be hyper trendy to use github (because like that 
> you can say that you use latest hyper cool
> 
> features), but I would like to ask especially people building libraries to 
> pay attention that it is important
> 
> that other people can contribute back easily and that there is an easy way to 
> load/contribute.
> 
> Today I experienced Bloc
> 
>- I cannot load code and I cannot contribute.
> 
>- I saw mdl with a mixture between smalltalkhub and github (sounds super 
> hyper cool) and I saw paul not being able to contribute :(
> 
> 
> Yes you can say that monticello sucks yes it is terrible yes we all fell like 
> Cobol programmers but at the end of the day.
> 
> Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts.
> 
> We managed pharo and moose with it over the last 8 years successfully and 
> Pharo and moose are not 5 packages together from
> 
> what I can see. So pay attention about the decision you take.
> 
> Now we will provide git support (this is 8 months that nicolas is exclusively 
> working/thinking/dreaming
> 
> about that) and that we are doing experiments (Guille is managing the 
> bootstrap in github).
> 
> Now when everybody will have its own little project lost on github (I do not 
> count the amount of time I do not find pillar on github because I forget
> 
> that it is called pillar-markup), what will we do.
> 
> So we need an infrastructure to handle this and christophe is working on this.
> 
> I think that you should consider the accidental complexity as something that 
> we can minimise by using patterns and common practices.
> 
> Now you can think that I'm an idiot and that I have no vision (be my guest) 
> but we should pay attention because we are a small community.
> 
> Stef
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-users] About balkanisation

[Sven Van Caekenberghe]

> On 6 Nov 2016, at 16:27, Dimitris Chloupis  wrote:
> 
> A biggy one is the pharo repo of the pharo image on github. Its a mess.
> 
> https://github.com/pharo-project/pharo-core/commits/6.0
> 
> seriously, Github makes us visible , this does not look good at all.

why not ? how is this different from a multi file commit in any other language ?

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

If you really want to embrace Github , kill Smalltalkhub.

Smalltalkhub should have been dead years ago. Its unmaintained anyway apart
from when it crashes and Esteban fixes. Smalltalkhub has been a constant
state from crashes since 2011 when I joined Pharo community.

Give people a month to move their projects in github and then kill it. At
worst give only read access the same way squeakers made the old
squeaksource read only.

Another thing that must be fixed is the file format chosen for git, the
idea to fragment source code to a billion diffirent source code files each
one containing a method or class definition is problematic both for viewing
those files offline and online. There is very little chance that if I give
a link to my github repo to an outsider to take a look at my code that he
will have the patience to navigate 10 files to read the code for 10
methods. Even the class comment is a separate file. I don't even have the
patience to do that.

Make an organisation for people to join, those are made inside github we
have one for the books we have none for the community , this way we can
gain easier visibility of source code and it will also make easier for
people to contribute to third party code.

Move the meta repos of Pharo to Github and remove "meta" from the name.
Instead name them Pharo Packages Catalog as we do inside the image. One
repo for all versions of Pharo. Branches can be used to separate versions.

Add to Playground the ability to paste code directly to Gist. This is a low
priority one but its a nice touch.

A biggy one is the pharo repo of the pharo image on github. Its a mess.

https://github.com/pharo-project/pharo-core/commits/6.0

seriously, Github makes us visible , this does not look good at all.

If you do all the above you will have reduced the pain of working with Git
by 80%.

On Sun, Nov 6, 2016 at 4:37 PM stepharo  wrote:

> Dimitris
>
> better reread what I wrote because you missed it.
>
> My point is let us minimize the mess and act in a concerted way. Do you
> think that we would pay 9 months of dev + esteban that will started to
> push there too
>
> and base all our dev on it if we would not believe that moving to git is
> stupid!
>
> Can you read what I write?
>
> Stef
>
>
> Le 6/11/16 à 13:05, stepharo a écrit :
> > Hi
> >
> > I would like that you think a bit about our community and that there
> > is a value in using common tools
> >
> > to share and develop common libraries. Because to me it feels like we
> > are getting balkanize.
> >
> >
> > It may look super cool and be hyper trendy to use github (because like
> > that you can say that you use latest hyper cool
> >
> > features), but I would like to ask especially people building
> > libraries to pay attention that it is important
> >
> > that other people can contribute back easily and that there is an easy
> > way to load/contribute.
> >
> > Today I experienced Bloc
> >
> > - I cannot load code and I cannot contribute.
> >
> > - I saw mdl with a mixture between smalltalkhub and github (sounds
> > super hyper cool) and I saw paul not being able to contribute :(
> >
> >
> > Yes you can say that monticello sucks yes it is terrible yes we all
> > fell like Cobol programmers but at the end of the day.
> >
> > Yes the herb is always greener elsewhere. Yes yes yes. Let us take
> > some facts.
> >
> > We managed pharo and moose with it over the last 8 years successfully
> > and Pharo and moose are not 5 packages together from
> >
> > what I can see. So pay attention about the decision you take.
> >
> > Now we will provide git support (this is 8 months that nicolas is
> > exclusively working/thinking/dreaming
> >
> > about that) and that we are doing experiments (Guille is managing the
> > bootstrap in github).
> >
> > Now when everybody will have its own little project lost on github (I
> > do not count the amount of time I do not find pillar on github because
> > I forget
> >
> > that it is called pillar-markup), what will we do.
> >
> > So we need an infrastructure to handle this and christophe is working
> > on this.
> >
> > I think that you should consider the accidental complexity as
> > something that we can minimise by using patterns and common practices.
> >
> > Now you can think that I'm an idiot and that I have no vision (be my
> > guest) but we should pay attention because we are a small community.
> >
> > Stef
> >
> >
> >
> >
> >
>
>
>

Re: [Pharo-users] About balkanisation

[stepharo]

Dimitris

better reread what I wrote because you missed it.

My point is let us minimize the mess and act in a concerted way. Do you 
think that we would pay 9 months of dev + esteban that will started to 
push there too


and base all our dev on it if we would not believe that moving to git is 
stupid!


Can you read what I write?

Stef


Le 6/11/16 à 13:05, stepharo a écrit :

Hi

I would like that you think a bit about our community and that there 
is a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building 
libraries to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all 
fell like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take 
some facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I 
do not count the amount of time I do not find pillar on github because 
I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working 
on this.


I think that you should consider the accidental complexity as 
something that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef

Re: [Pharo-users] About balkanisation

[Dimitris Chloupis]

> It may look super cool and be hyper trendy to use github (because like
> that you can say that you use latest hyper cool
>
> features), but I would like to ask especially people building libraries
> to pay attention that it is important
>
> that other people can contribute back easily and that there is an easy
> way to load/contribute.
>
>
>
 Indeed Git and Github are hypercool and trendy but the important question
here is why.

Why C++ is so popular, why Java is so popular, why Javascript is so
popular, Why python is so popular. When you ask why you understand that
being hyper cool, its not a thing, its not something you can glance over

its a practical need

we needed a language that is super fast with ability to handle complex
code, C++
we needed a language that is focused on enterprise development , Java
we needed a language to make web developent, Javascript
we needed a language to simplify C/C++/Java and C# without losing
libraries, Python
we needed a superfast decentralized versions control systems for both code
and other assets , Git
we needed a place to host online open source projects with git , Github
we needed the perfect language , the perfect libraries a tool to end all
tools , Nothing

each one of those hypercools excel in what you are doing, in many cases
they are more than one, not because they are easy but because they are
powerful. To go back to old alternatives would be like going back to caves
because you have hard time opening the front door of your house.

You may choose to go back to the cave but do not expect people to follow
you.

You preach people not to leave the comforts of the nest because its safe
and it easy, but in the end I find that as wasted potential.

The question I am asking myself everyday how far can Pharo go with taking
advantage of modern technology, how far Pharo can go if it gains access to
the same exact resources as all other programming languages ? What would it
mean for the average Pharo developer to be able to use not just web dev
libraries but any library, any tool , any programming language , any time ?

If you can answer these questions then you know why embracing git and
github is the right choice even if it pains you, even if makes you lose
sleep sometimes or even if you find it hard.

Just because Smalltalk is an island, Pharo does not need to be one.

Afterall  Pharo is not Smalltalk, or so we claim

Its time to put our money where our mouths are.

[Pharo-users] About balkanisation

[stepharo]

Hi

I would like that you think a bit about our community and that there is 
a value in using common tools


to share and develop common libraries. Because to me it feels like we 
are getting balkanize.



It may look super cool and be hyper trendy to use github (because like 
that you can say that you use latest hyper cool


features), but I would like to ask especially people building libraries 
to pay attention that it is important


that other people can contribute back easily and that there is an easy 
way to load/contribute.


Today I experienced Bloc

- I cannot load code and I cannot contribute.

- I saw mdl with a mixture between smalltalkhub and github (sounds 
super hyper cool) and I saw paul not being able to contribute :(



Yes you can say that monticello sucks yes it is terrible yes we all fell 
like Cobol programmers but at the end of the day.


Yes the herb is always greener elsewhere. Yes yes yes. Let us take some 
facts.


We managed pharo and moose with it over the last 8 years successfully 
and Pharo and moose are not 5 packages together from


what I can see. So pay attention about the decision you take.

Now we will provide git support (this is 8 months that nicolas is 
exclusively working/thinking/dreaming


about that) and that we are doing experiments (Guille is managing the 
bootstrap in github).


Now when everybody will have its own little project lost on github (I do 
not count the amount of time I do not find pillar on github because I forget


that it is called pillar-markup), what will we do.

So we need an infrastructure to handle this and christophe is working on 
this.


I think that you should consider the accidental complexity as something 
that we can minimise by using patterns and common practices.


Now you can think that I'm an idiot and that I have no vision (be my 
guest) but we should pay attention because we are a small community.


Stef

Re: [Pharo-users] May I please be added as a contributor to the KevinLanvin/MaterialDesignLite repo on Sthub?

[Esteban Lorenzano]

Hi, 


> On 5 Nov 2016, at 22:28, stepharo  wrote:
> 
> I do not think that Kevin is following this list. I strongly suggest that the 
> repo is moved to one that we can control and let people contribute.
> 

AFAIK this is the case: 

https://github.com/DuneSt/MaterialDesignLite 
 

is the one we use (at least, this is the one I forked to add stuff… which I 
will submit back as PR next week :P)

Esteban

Re: [Pharo-users] Forgive me

[p...@highoctane.be]

As any person with an ounce of self awareness.

Remember that you are one interesting way the universe is introspecting
itself.

Phil



On Sun, Nov 6, 2016 at 10:08 AM, Robert Withers 
wrote:

> Thank you. It breaks my heart I'm who I am, so at odds with who I wish to
> be. Cave shadowz and distorted viewpoints.
>
>
>
> On 11/6/2016 2:56 AM, p...@highoctane.be wrote:
>
> You are forgiven.
>
> Now get back to delivering us awesome features.
>
> Namaste.
> Phil
>
> On Sun, Nov 6, 2016 at 8:24 AM, Robert Withers  > wrote:
>
>> Forgive me for being such a huge unbearable fucking asshole.
>>
>>
>>
>>
>
>

Re: [Pharo-users] Speed up JPG images loading

[Ben Coman]

What does the Time Profiler show?
Can you link to a sample picture?

cheers -ben

On Sat, Nov 5, 2016 at 11:11 PM, Matteo via Pharo-users
 wrote:
>
>
> -- Forwarded message --
> From: Matteo 
> To: "Pharo is welcome (ML)" 
> Cc:
> Date: Sat, 5 Nov 2016 16:10:45 +0100
> Subject: Speed up JPG images loading
> Dears,
> I'm loading a lot of pictures (70) through the method
> "ImageReadWriter>>formFromFileNamed:".
> The method is very slow, with images bigger than 5MB.
>
> Is there a way to improve the pictures speed loading?
>
>
> Thanks
> Matteo
>
>

Re: [Pharo-users] Forgive me

[p...@highoctane.be]

You are forgiven.

Now get back to delivering us awesome features.

Namaste.
Phil

On Sun, Nov 6, 2016 at 8:24 AM, Robert Withers 
wrote:

> Forgive me for being such a huge unbearable fucking asshole.
>
>
>
>

Re: [Pharo-users] Can pharo association web page point to association.pharo.org, like the consortium one?

[John Pfersich]

Great! Thanks for all your work. 

Sent from my iPhone

> On Nov 5, 2016, at 04:31, Marcus Denker  wrote:
> 
> Hi,
> 
> Current Status:
> 
> - SPF record DONE, mails are now send from @association.pharo.org
> - DNS setup now uses association.pharo.org for normal viewing, just forms 
> forward to https://pharo.wildapricot.org
> This will change as soon as the SSL certificate setup is completed, which 
> will be next week.
> 
> Else the website is fully working, all members have been added.
> 
>   Marcus
> 
>> On 3 Nov 2016, at 08:21, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> yes, mistake to send out the emails to early. On the TODO:
>>  -> Get SSL cert so always our domain is shown
>>  -> Sort out some strange problem with SPF record in DNS.
>> 
>> After that it will be fully operational. The system itself will not change, 
>> so if e.g. someone wants
>> to join, you can do that already now.
>> 
>>  Marcus
>> 
>>> On 2 Nov 2016, at 17:58, Esteban Lorenzano  wrote:
>>> 
>>> it is correct, 
>>> just we still didn’t change the domain (to association.pharo.org) and we 
>>> send the mail too early. 
>>> 
>>> but you can trust that mail, is ours :)
>>> 
>>> Esteban
>>> 
 On 2 Nov 2016, at 17:40, Offray Vladimir Luna Cárdenas 
  wrote:
 
 Hi,
 
 I just received a mail telling me some password and login information and 
 telling me to go to https://pharo.wildapricot.org/, but that domain seem 
 suspicious to me, so I went to the consortium and association which are 
 subdomains of Pharo. First one works well, but second is a redirection to 
 the previous link. In this time of page defacement, could we have the 
 subdomain of the association not redirected to another domain?
 
 Cheers,
 
 Offray
 
 
>>> 
>> 
>