Re: [Pharo-dev] a Pharo talk from a ruby conference

[S Krish]

"So it's a question of who you're marketing to. Since we're marketing to
non-Smalltalkers (quite wise since 16% market penetration is the tipping
point [1], and we're not there yet)"

If you can get Pharo Smalltalk to be what makes people feel great about
using it and creating great applications with, it will succeed far more
than Ruby has in 5 years ahead. We need not push our efforts and energy in
labelling ( falsely ), that will give no impact / or add any value to the
perception of people.

Java succeeded because it enabled many to move on to the web enabled
world.. massively..

Rails succeeded because developers found it easier and simpler to bring up
a complete website and maintain it than its alternatives. JRuby helped in
as much Heroku did in its growth. Many developers made their fortune out of
Rails..

iPad, iPhone, iPod, now android phones / tablets succeed well and truly
because they enable the people to do what they want with it, make them feel
great about using them too and bigger bet was developing for the Appstore
and Android Market place that enabled many more to make money.

Can we move on to have a Pharo Appstore with a demand for the apps in the
store ... you will see more than 16% share you will need to make Pharo big.

http://skrishnamachari.wordpress.com/2014/04/29/pharo-is-a-smalltalk-dialect/





On Tue, Apr 29, 2014 at 5:54 AM, Sean P. DeNigris wrote:

> Tudor Girba-2 wrote
> > There is a point of view from which one could say that
> > Pharo is Smalltalk by seeing Smalltalk as a movement, rather than
> specific
> > implementation. Unfortunately, everyone else thinks of Smalltalk as a
> > specific language, or set of languages with specific environments that
> > typically look old enough to not be relevant anymore.
>
> Yes! This is a tower of babel argument.
> For almost every programmer alive, Smaltalk = Smalltalk 80 -> Pharo is
> Smalltalk-inspired
> For us, Smaltalk = "experimental Dynabook software that bootstraps itself
> (ideally every 4 years)" -> Pharo is Smalltalk 109.
>
> So it's a question of who you're marketing to. Since we're marketing to
> non-Smalltalkers (quite wise since 16% market penetration is the tipping
> point [1], and we're not there yet), clearly "Pharo is Smalltalk-inspired"
> is the thing to say. It's not any more or less true than the latter, just
> more useful in its context.
>
> [1] http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756891.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sean P. DeNigris]

Esteban A. Maringolo wrote
> Plays well with "choose your favorite text editor" (Sublime, Vim,
> etc.) and IDEs (RubyMine, etc.), with source control systems (any file
> based system), with unix in general (several cli commands), has
> binding for any major/mainstream library* (databases, network, etc.).

But again these boil down to community size/interest
- To use "your favorite text editor", Craig Latta serves Smalltalk via
WebDav [1], but who has jumped at this opportunity?
- source control - now that there is community interest, progress on git
support has been moving ahead rapidly with minimal resources
- unix in general - with FFI and OSProcess, what can't you do? Are we
talking about the lack of cool Ruby backtick syntax? While definitely cool,
that special-purpose syntax is the kind of cognitive load Smalltalk
overcomes. All those little syntactical twists and turns to remember lead
away from "syntax on a T-shirt" to manuals with hundreds of pages
- bindings - again, obviously just a question of community size and interest

So the "play well with others" is a self-fulfilling prophecy. There are no
bindings because there are no people to write them because there are no
bindings... At inception, Ruby (and every other language) didn't have those
bindings either.

[1]
http://thiscontext.com/2011/06/09/my-favorite-text-editor-editing-a-spoon-webdav-filesystem/



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756900.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Esteban A. Maringolo]

2014-04-28 21:42 GMT-03:00 Sean P. DeNigris :
> Yes, it was very fair and a nice bridge between the Ruby and Smalltalk
> communities i.e. not too elitist.

+1

> kilon alios wrote
>> I also completely agree with his criticism on smalltalk of... not playing
>> well with
>> others
> I think this has always been a red herring. How exactly does Ruby "play well
> with others"? Wth does that mean?


Plays well with "choose your favorite text editor" (Sublime, Vim,
etc.) and IDEs (RubyMine, etc.), with source control systems (any file
based system), with unix in general (several cli commands), has
binding for any major/mainstream library* (databases, network, etc.).
And even has a VM that runs on top of a Smalltalk one :)

Of course some of the "play well with others" decisions can restrict
what you can do (as it certainly did with ruby), but they certainly
play better. IMHO.

> If we're talking about e.g. native windows, Ruby has bindings to GUI
> libraries because it has a community big enough that is interested-in-that
> enough to write them. In fact IIRC, someone wrote GTK bindings for
> Squeak/Pharo, but there was little user interest and they took their code
> elsewhere. There's no difference in that regard.

When it comes to GUIs, any binding in langs is more a proof of concept
than anything else, there are no "killer apps" written in Ruby that
uses native GUIs (by means of Gtk, Qt, etc.). And I'd bet my balls
(the golf ones ;-) that no single person comes to Ruby world to
develop with Gtk bindings or similar. And a few years ago I'd say that
no one came to ruby for other thing than Rails. Same goes for PHP, and
other web based software.

Maybe I'm totally mistaken, but today demand is web UI or an API.
Considering the jobs request, no one is developing with native GUI any
longer, except for those doing mobile development (Android/iOS); and
that's because HTML5/JS is still slow/immature to replace the native
alternatives.

Regards,

Esteban A. Maringolo

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sean P. DeNigris]

kilon alios wrote
> Watched it once more and now it clear that he presented Smalltalk in a
> very fair
> manner

Yes, it was very fair and a nice bridge between the Ruby and Smalltalk
communities i.e. not too elitist.


kilon alios wrote
> I also completely agree with his criticism on smalltalk of... not playing
> well with
> others

I think this has always been a red herring. How exactly does Ruby "play well
with others"? Wth does that mean? 

If we're talking about e.g. native windows, Ruby has bindings to GUI
libraries because it has a community big enough that is interested-in-that
enough to write them. In fact IIRC, someone wrote GTK bindings for
Squeak/Pharo, but there was little user interest and they took their code
elsewhere. There's no difference in that regard. 

Another barrier of course, is that binding to external UI libraries in a way
violates the turtles-all-the-way-down principle of Smalltalk and would only
be a kludge until you could replace them with an implementation that was
part of the live, uniform system. Although if not being satisfied with a
system that is complicated beyond human comprehension is "not playing well
with others", perhaps you should reconsider your friendships ha ha ;)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756895.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sean P. DeNigris]

Tudor Girba-2 wrote
> There is a point of view from which one could say that
> Pharo is Smalltalk by seeing Smalltalk as a movement, rather than specific
> implementation. Unfortunately, everyone else thinks of Smalltalk as a
> specific language, or set of languages with specific environments that
> typically look old enough to not be relevant anymore.

Yes! This is a tower of babel argument.
For almost every programmer alive, Smaltalk = Smalltalk 80 -> Pharo is
Smalltalk-inspired
For us, Smaltalk = "experimental Dynabook software that bootstraps itself
(ideally every 4 years)" -> Pharo is Smalltalk 109.

So it's a question of who you're marketing to. Since we're marketing to
non-Smalltalkers (quite wise since 16% market penetration is the tipping
point [1], and we're not there yet), clearly "Pharo is Smalltalk-inspired"
is the thing to say. It's not any more or less true than the latter, just
more useful in its context.

[1] http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756891.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] a Pharo talk from a ruby conference

[p...@highoctane.be]

On Mon, Apr 28, 2014 at 10:24 PM, Esteban A. Maringolo  wrote:

> Hi Phil,
>
> 2014-04-28 17:07 GMT-03:00 p...@highoctane.be :
> > What no REPL? Check this:
> > http://stackoverflow.com/questions/3067563/using-squeak-from-a-shell
> >
> > "Works out of the box in Pharo 2.0. For prior versions (definitely works
> in
> > 1.3 and 1.4), first file in https://gist.github.com/2602113";
>
> I'm not saying it is not doable, if we have workspaces we can have
> something simple as a REPL (as your snippet shows).
>
> But it is not as prominent as a workspace. And of course it doesn't
> come bundled in the core image :)
>
> E.g. Think of the Javascript console in Chrome Developer Tools, where
> the console can work as a Workspace, a Transcript and an Inspector all
> in one.
>
> Or, think of python or ruby's irb.
>

Nothing precludes us from having just that. Topez in Gemstone does just
that no?

Phil

>
>
> Esteban A. Maringolo
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Tudor Girba]

Hi Eliot,

On Mon, Apr 28, 2014 at 9:08 PM, Eliot Miranda wrote:

>
>
>
> On Mon, Apr 28, 2014 at 11:38 AM, Tudor Girba wrote:
>
>> Hi Eliot,
>>
>> I know we went through it, and we still disagree :). I have provided
>> detailed arguments and I have seen no others that did refute mine.
>>
>
> OK, I'll bite :-).  Point me to the arguments and I'll have a go at
> refutation.
>

Besides the points laid out in the discussions on this mailing list, I
provided an initial argument here:
http://www.tudorgirba.com/blog/pharo-is-pharo


> But my statement that Pharo is a Smalltalk boils own to the facts that
> Smalltalk has always evolved
>

I agree on that. There is a point of view from which one could say that
Pharo is Smalltalk by seeing Smalltalk as a movement, rather than specific
implementation. Unfortunately, everyone else thinks of Smalltalk as a
specific language, or set of languages with specific environments that
typically look old enough to not be relevant anymore.

(Multiple inheritance was a discarded experiment that is in Smalltalk-80
> for example, Tweak contains a sort-of slot idea, as another) and that
> Pharo's evolutions are no different to other evolutions that have enriched
> Smalltalk but not redefined it, and that one way to tell is to see if the
> VM or instruction set needs to be radically different to implement the
> system efficiently. So there's nothing un-Smalltalk about traits, or slots
> or a modular compiler.
>

This is where our points diverge significantly. Just because Closure or
JRuby run on a Java VM does not make them Java. They are their own
languages.

Similarly, just because Newspeak runs pretty much the same VM as Squeak or
Pharo does not make it a Smalltalk either (according to the webpage it is a
new programming language in the tradition of Self and Smalltalk). Things
that want to have an identity should be allowed to get it as long as the
due credits are acknowledged.

Saying that there is nothing un-Smalltalk about slots, or compiler or
traits and all sorts of other things is not incorrect, but saying that the
same things are not defined by Smalltalk is not incorrect either. The point
of view matters. As for deciding how much of difference should there be
until we are not to be associated with the original, I would leave that to
lawyers that have to do it. I will focus on trying to market a fantastic
environment and community.

But, there is another point, too. "Pharo is Smalltalk-inspired" is not just
factual but also a statement of intention. We do not want to necessarily be
Smalltalk. If the future proves that some decisions made in Smalltalk are
good we will make them, too. Otherwise we will take other routes. That's a
promise :)


I am certainly open to talking about it. I have no intention of lying or
>> hiding. I am rather proud to be part of this community and to do my bit of
>> contributing.
>>
>
> Us both.
>
>
>> But, please understand that my main concern is getting Pharo adopted
>> which is what other Smalltalk rooted systems did not really manage until
>> now. There are many ways to say the same thing. Some people will resonate
>> with some messages, and some others will pick holes in them. I will focus
>> on increasing the first set of people while preserving the semantics I
>> believe in.
>>
>
> Quite.  Agreed.
>
>
Great :)

Doru


>
>> Doru
>>
>>
>> On Mon, Apr 28, 2014 at 7:38 PM, Eliot Miranda 
>> wrote:
>>
>>>
>>>
>>>
>>> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>>>
 That is why we talk about Pharo as a cool, modern environment and
 language that is Smalltalk-inspired.

>>>
>>> We went through this a few months ago.  Pharo  isn't inspired by
>>> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
>>> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
>>> as bad as apologizing for it being dead.
>>>
>>>
 We do not need to apologize because Pharo was never dead :).

>>>
>>> We don't need to avoid the S word either...
>>>
>>>

 Doru


 On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:

>
> Am 28.04.2014 um 18:58 schrieb kilon alios :
>
> very cool presentation. Definitely you need to add this to the new
> website.
>
> Question : Why in every presentation we have to apologise why
> smalltalk is dead / extinct ?
>
> As a newcomer to Smalltalk I find it quite annoying. Its not as if I
> came to Smalltalk without knowing that is not popular. The vast majority 
> of
> languages out there are so more unpopular than Smalltalk, yet they don't
> have this "sorry that I am dead" mentality to them.
>
> +1
>
> Well said.
>
> Norbert
>
>
> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker  > wrote:
>
>> … more a Smalltalk one using Pharo:
>>
>> MountainWest RubyConf 2014
>>
>> Noel Rappin: "But Really, You Should Learn Smalltalk”
>>
>> Smal

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Esteban A. Maringolo]

Hi Phil,

2014-04-28 17:07 GMT-03:00 p...@highoctane.be :
> What no REPL? Check this:
> http://stackoverflow.com/questions/3067563/using-squeak-from-a-shell
>
> "Works out of the box in Pharo 2.0. For prior versions (definitely works in
> 1.3 and 1.4), first file in https://gist.github.com/2602113";

I'm not saying it is not doable, if we have workspaces we can have
something simple as a REPL (as your snippet shows).

But it is not as prominent as a workspace. And of course it doesn't
come bundled in the core image :)

E.g. Think of the Javascript console in Chrome Developer Tools, where
the console can work as a Workspace, a Transcript and an Inspector all
in one.

Or, think of python or ruby's irb.


Esteban A. Maringolo

Re: [Pharo-dev] a Pharo talk from a ruby conference

[p...@highoctane.be]

What no REPL? Check this:
http://stackoverflow.com/questions/3067563/using-squeak-from-a-shell

"Works out of the box in Pharo 2.0. For prior versions (definitely
works in 1.3 and 1.4), first file in https://gist.github.com/2602113";

| command |
[
command := FileStream stdin nextLine.
command ~= 'exit' ] whileTrue: [ | result |
result := Compiler evaluate: command.
FileStream stdout nextPutAll: result asString; lf ].

Smalltalk snapshot: false andQuit: true.


Well, on Windows, this will suck big time, but on unix and osx, should
fare better.

IMHO, we shoould fix the stdin/stdout/stderr shit that we do have on
Pharo on Windows.


I had a shot on the VM side but that is nowhere to be complete... :-(

Phil




On Mon, Apr 28, 2014 at 9:49 PM, Esteban A. Maringolo
wrote:

> 2014-04-28 16:31 GMT-03:00 kilon alios :
> > I once laughed at the video when he pointed that pressing enter on
> workspace
> > does not run the code. That was a "WTF" moment for me when I first tried
> > workspace in Squeak. Many other strange things , instance variables by
> > default private , Transcript separate from Workspace, no source files etc
> > etc.
>
> Because it is too weird to be grasped properly. Most if not all people
> expect scripted or REPL/Console execution.
> Also it is weird the fact that you can "modify everything" while
> running. It causes a dissonance.
> I felt that when I was introduced to Smalltalk, and years after that I
> found the same reception in newcomers. So it wasn't just me.
>
> Smalltalk is so great, that it is hard to summarize many of it awesome
> features in a short demo.
>
> One point for "selling" Pharo to non-smalltalkers is thinking in what
> the benefit they would get by developing with it.
>
> Maybe we should brainstorm on this point:
> "If you were to recommend Pharo to a Java/Ruby/PHP programmer, what
> would be your two main selling points?"
> (https://twitter.com/emaringolo/status/460867076178341888)
>
> IMHO, it is not a simple question to answer, because an existing
> smalltalker will get much more out of it than a newcomer.
>
> Regards!
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sebastian Sastre]

On Apr 28, 2014, at 4:59 PM, Tudor Girba  wrote:

> For some reason, you are under the impression that I focus on the Smalltalk 
> community. I have no intention of going there. Our goal is precisely the 
> opposite - the developer community at large.

glad to hear that.

Keep showing your magic, the world will respond 

Re: [Pharo-dev] a Pharo talk from a ruby conference

[p...@highoctane.be]

On Mon, Apr 28, 2014 at 7:46 PM, S Krish
wrote:

>
> +1
>
> Smalltalk heritage and its future should be carried on by "Pharo
> Smalltalk".
>
>
> +1!


>  On Mon, Apr 28, 2014 at 11:08 PM, Eliot Miranda 
> wrote:
>
>>
>>
>>
>> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>>
>>> That is why we talk about Pharo as a cool, modern environment and
>>> language that is Smalltalk-inspired.
>>>
>>
>> We went through this a few months ago.  Pharo  isn't inspired by
>> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
>> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
>> as bad as apologizing for it being dead.
>>
>>
>>> We do not need to apologize because Pharo was never dead :).
>>>
>>
>> We don't need to avoid the S word either...
>>
>>
>>>
>>> Doru
>>>
>>>
>>> On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:
>>>

 Am 28.04.2014 um 18:58 schrieb kilon alios :

 very cool presentation. Definitely you need to add this to the new
 website.

 Question : Why in every presentation we have to apologise why smalltalk
 is dead / extinct ?

 As a newcomer to Smalltalk I find it quite annoying. Its not as if I
 came to Smalltalk without knowing that is not popular. The vast majority of
 languages out there are so more unpopular than Smalltalk, yet they don't
 have this "sorry that I am dead" mentality to them.

 +1

 Well said.

 Norbert


 On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker 
 wrote:

> … more a Smalltalk one using Pharo:
>
> MountainWest RubyConf 2014
>
> Noel Rappin: "But Really, You Should Learn Smalltalk”
>
> Smalltalk has mystique. We talk about it more than we use it. It seems
> like it should be so similar to Ruby. It has similar Object-Oriented
> structures, it even has blocks. But everything is so slightly different,
> from the programming environment, to the 1-based arrays, to the simple
> syntax. Using Smalltalk will make you look at familiar constructs with new
> eyes. We’ll show you how to get started on Smalltalk, and walk through 
> some
> sample code. Live coding may be involved. You’ll never look at objects the
> same way again.
>
>
> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
>



>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Tudor Girba]

For some reason, you are under the impression that I focus on the Smalltalk
community. I have no intention of going there. Our goal is precisely the
opposite - the developer community at large.

It is precisely for this reason that I will keep on saying that Pharo is a
modern language and environment that people should look at and that happens
to be inspired by Smalltalk.

You see, when something is dead (and this is what Smalltalk is in the mind
of everyone else that is not in our inner circle) you need a miracle.
Miracles are hard to produce, but magic isn't. We are actually pretty good
at magic, so I will pick a game in which magic will do just fine. Hence,
Pharo is Pharo and all the magic that comes with it.

Doru


On Mon, Apr 28, 2014 at 9:33 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Apr 28, 2014, at 3:24 PM, Tudor Girba  wrote:
>
> So, what is better as a communication strategy:
> - to say that Pharo is "a Smalltalk with traits, modular compiler, slots
> and moldable debugger, ... (more to come in this list)", or
> - to say that Pharo "is a modern Smalltalk-inspired system?"
> ?
>
>
> The first pitch totally sucks of course but for the sake of getting to
> your point, it depends on who the audience is, right?
>
> If you’re trying too hard to differentiate yourself from other Smalltalk
> dialects, then *“modern Smalltalk-inspired system” *might have a chance.
>
> But what that chance might lead you to? What’s the best thing that can
> happen with that strategy?
>
> That you steal some market space for your preferred dialect in a zero-sum
> game of an already very small community?
>
> Okay, let’s talk about the opposite direction. A non-zero-sum game. What
> about trying to connect with a wider audience? You’ll need something that
> serves as foundation to build on top of. Something inspiring.
>
> Now let’s do the numbers..
>
> A) What’s the size of the whole smalltalk community? what you can have
> from it? 2%? 10%? 20% conversion? let’s say you get 80% because you’re
> amazing beyond disbelief.
>
> B) What’s the size of the whole dynamic technology community? if you get
> 0.001% from it you multiplied the smalltalkers on the surface of this
> planet by x100 times
>
> So what strategy really deserves your effort?
>
> For me it’s pretty clear where the winner and looser communication
> strategy resides, I actually saw it in action and it wasn’t even hard. I
> also assume we’re for a winner strategy but I actually have no idea on how
> Pharo is managing its branding and Smalltalk has still to prove to itself
> it can actually market itself properly
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Esteban A. Maringolo]

2014-04-28 16:31 GMT-03:00 kilon alios :
> I once laughed at the video when he pointed that pressing enter on workspace
> does not run the code. That was a "WTF" moment for me when I first tried
> workspace in Squeak. Many other strange things , instance variables by
> default private , Transcript separate from Workspace, no source files etc
> etc.

Because it is too weird to be grasped properly. Most if not all people
expect scripted or REPL/Console execution.
Also it is weird the fact that you can "modify everything" while
running. It causes a dissonance.
I felt that when I was introduced to Smalltalk, and years after that I
found the same reception in newcomers. So it wasn't just me.

Smalltalk is so great, that it is hard to summarize many of it awesome
features in a short demo.

One point for "selling" Pharo to non-smalltalkers is thinking in what
the benefit they would get by developing with it.

Maybe we should brainstorm on this point:
"If you were to recommend Pharo to a Java/Ruby/PHP programmer, what
would be your two main selling points?"
(https://twitter.com/emaringolo/status/460867076178341888)

IMHO, it is not a simple question to answer, because an existing
smalltalker will get much more out of it than a newcomer.

Regards!

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sebastian Sastre]

On Apr 28, 2014, at 3:24 PM, Tudor Girba  wrote:

> So, what is better as a communication strategy:
> - to say that Pharo is "a Smalltalk with traits, modular compiler, slots and 
> moldable debugger, ... (more to come in this list)", or
> - to say that Pharo "is a modern Smalltalk-inspired system?"
> ?

The first pitch totally sucks of course but for the sake of getting to your 
point, it depends on who the audience is, right?

If you’re trying too hard to differentiate yourself from other Smalltalk 
dialects, then “modern Smalltalk-inspired system” might have a chance.

But what that chance might lead you to? What’s the best thing that can happen 
with that strategy?

That you steal some market space for your preferred dialect in a zero-sum game 
of an already very small community?

Okay, let’s talk about the opposite direction. A non-zero-sum game. What about 
trying to connect with a wider audience? You’ll need something that serves as 
foundation to build on top of. Something inspiring. 

Now let’s do the numbers..

A) What’s the size of the whole smalltalk community? what you can have from it? 
2%? 10%? 20% conversion? let’s say you get 80% because you’re amazing beyond 
disbelief.

B) What’s the size of the whole dynamic technology community? if you get 0.001% 
from it you multiplied the smalltalkers on the surface of this planet by x100 
times

So what strategy really deserves your effort?

For me it’s pretty clear where the winner and looser communication strategy 
resides, I actually saw it in action and it wasn’t even hard. I also assume 
we’re for a winner strategy but I actually have no idea on how Pharo is 
managing its branding and Smalltalk has still to prove to itself it can 
actually market itself properly

Re: [Pharo-dev] a Pharo talk from a ruby conference

[kilon alios]

I think for people coming outside , it wont matter whether Pharo is
Smalltalk or Smalltalk-inspired. Chances are that they wont care about the
semantics at all, just "what pharo can do for me now". And its great you
all focus on the practical side and not the philosophical side.

Also if you think about it even though you may disagree what you should
name Pharo as, as soon as you start describing Pharo in detail you will be
saying the exact same things.

I think the secret is not to try to make people understand what Pharo is in
a few words. Just describing what live coding means for Pharo is a rather
long talk. Unfortunately thats the downside when you creating a quite
different product from what already exists out there, your users will take
some time to realyl appreciate what the fuzz is all about.

When I started with python it was BOOM "a dynamic language that tries to
keep things simple and small" , thats what python is all about. Took me
literally a couple of days to realise what I had in front me.

With Squeak and Pharo it took several tries, it took me a couple of days to
realise the importance of blocks and why loops and ifs had to to use this
strange thing.

I once laughed at the video when he pointed that pressing enter on
workspace does not run the code. That was a "WTF" moment for me when I
first tried workspace in Squeak. Many other strange things , instance
variables by default private , Transcript separate from Workspace, no
source files etc etc.


On Mon, Apr 28, 2014 at 10:08 PM, Eliot Miranda wrote:

>
>
>
> On Mon, Apr 28, 2014 at 11:38 AM, Tudor Girba wrote:
>
>> Hi Eliot,
>>
>> I know we went through it, and we still disagree :). I have provided
>> detailed arguments and I have seen no others that did refute mine.
>>
>
> OK, I'll bite :-).  Point me to the arguments and I'll have a go at
> refutation.  But my statement that Pharo is a Smalltalk boils own to the
> facts that Smalltalk has always evolved (Multiple inheritance was a
> discarded experiment that is in Smalltalk-80 for example, Tweak contains a
> sort-of slot idea, as another) and that Pharo's evolutions are no different
> to other evolutions that have enriched Smalltalk but not redefined it, and
> that one way to tell is to see if the VM or instruction set needs to be
> radically different to implement the system efficiently.  So there's
> nothing un-Smalltalk about traits, or slots or a modular compiler.
>
>
>> I am certainly open to talking about it. I have no intention of lying or
>> hiding. I am rather proud to be part of this community and to do my bit of
>> contributing.
>>
>
> Us both.
>
>
>> But, please understand that my main concern is getting Pharo adopted
>> which is what other Smalltalk rooted systems did not really manage until
>> now. There are many ways to say the same thing. Some people will resonate
>> with some messages, and some others will pick holes in them. I will focus
>> on increasing the first set of people while preserving the semantics I
>> believe in.
>>
>
> Quite.  Agreed.
>
>
>>
>> Doru
>>
>>
>> On Mon, Apr 28, 2014 at 7:38 PM, Eliot Miranda 
>> wrote:
>>
>>>
>>>
>>>
>>> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>>>
 That is why we talk about Pharo as a cool, modern environment and
 language that is Smalltalk-inspired.

>>>
>>> We went through this a few months ago.  Pharo  isn't inspired by
>>> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
>>> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
>>> as bad as apologizing for it being dead.
>>>
>>>
 We do not need to apologize because Pharo was never dead :).

>>>
>>> We don't need to avoid the S word either...
>>>
>>>

 Doru


 On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:

>
> Am 28.04.2014 um 18:58 schrieb kilon alios :
>
> very cool presentation. Definitely you need to add this to the new
> website.
>
> Question : Why in every presentation we have to apologise why
> smalltalk is dead / extinct ?
>
> As a newcomer to Smalltalk I find it quite annoying. Its not as if I
> came to Smalltalk without knowing that is not popular. The vast majority 
> of
> languages out there are so more unpopular than Smalltalk, yet they don't
> have this "sorry that I am dead" mentality to them.
>
> +1
>
> Well said.
>
> Norbert
>
>
> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker  > wrote:
>
>> … more a Smalltalk one using Pharo:
>>
>> MountainWest RubyConf 2014
>>
>> Noel Rappin: "But Really, You Should Learn Smalltalk”
>>
>> Smalltalk has mystique. We talk about it more than we use it. It
>> seems like it should be so similar to Ruby. It has similar 
>> Object-Oriented
>> structures, it even has blocks. But everything is so slightly different,
>> from the programming environment, to the 1-based arrays, to

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Eliot Miranda]

On Mon, Apr 28, 2014 at 11:38 AM, Tudor Girba  wrote:

> Hi Eliot,
>
> I know we went through it, and we still disagree :). I have provided
> detailed arguments and I have seen no others that did refute mine.
>

OK, I'll bite :-).  Point me to the arguments and I'll have a go at
refutation.  But my statement that Pharo is a Smalltalk boils own to the
facts that Smalltalk has always evolved (Multiple inheritance was a
discarded experiment that is in Smalltalk-80 for example, Tweak contains a
sort-of slot idea, as another) and that Pharo's evolutions are no different
to other evolutions that have enriched Smalltalk but not redefined it, and
that one way to tell is to see if the VM or instruction set needs to be
radically different to implement the system efficiently.  So there's
nothing un-Smalltalk about traits, or slots or a modular compiler.


> I am certainly open to talking about it. I have no intention of lying or
> hiding. I am rather proud to be part of this community and to do my bit of
> contributing.
>

Us both.


> But, please understand that my main concern is getting Pharo adopted which
> is what other Smalltalk rooted systems did not really manage until now.
> There are many ways to say the same thing. Some people will resonate with
> some messages, and some others will pick holes in them. I will focus on
> increasing the first set of people while preserving the semantics I believe
> in.
>

Quite.  Agreed.


>
> Doru
>
>
> On Mon, Apr 28, 2014 at 7:38 PM, Eliot Miranda wrote:
>
>>
>>
>>
>> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>>
>>> That is why we talk about Pharo as a cool, modern environment and
>>> language that is Smalltalk-inspired.
>>>
>>
>> We went through this a few months ago.  Pharo  isn't inspired by
>> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
>> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
>> as bad as apologizing for it being dead.
>>
>>
>>> We do not need to apologize because Pharo was never dead :).
>>>
>>
>> We don't need to avoid the S word either...
>>
>>
>>>
>>> Doru
>>>
>>>
>>> On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:
>>>

 Am 28.04.2014 um 18:58 schrieb kilon alios :

 very cool presentation. Definitely you need to add this to the new
 website.

 Question : Why in every presentation we have to apologise why smalltalk
 is dead / extinct ?

 As a newcomer to Smalltalk I find it quite annoying. Its not as if I
 came to Smalltalk without knowing that is not popular. The vast majority of
 languages out there are so more unpopular than Smalltalk, yet they don't
 have this "sorry that I am dead" mentality to them.

 +1

 Well said.

 Norbert


 On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker 
 wrote:

> … more a Smalltalk one using Pharo:
>
> MountainWest RubyConf 2014
>
> Noel Rappin: "But Really, You Should Learn Smalltalk”
>
> Smalltalk has mystique. We talk about it more than we use it. It seems
> like it should be so similar to Ruby. It has similar Object-Oriented
> structures, it even has blocks. But everything is so slightly different,
> from the programming environment, to the 1-based arrays, to the simple
> syntax. Using Smalltalk will make you look at familiar constructs with new
> eyes. We’ll show you how to get started on Smalltalk, and walk through 
> some
> sample code. Live coding may be involved. You’ll never look at objects the
> same way again.
>
>
> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
>



>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>



-- 
best,
Eliot

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Tudor Girba]

Hi Eliot,

I know we went through it, and we still disagree :). I have provided
detailed arguments and I have seen no others that did refute mine.

I am certainly open to talking about it. I have no intention of lying or
hiding. I am rather proud to be part of this community and to do my bit of
contributing.

But, please understand that my main concern is getting Pharo adopted which
is what other Smalltalk rooted systems did not really manage until now.
There are many ways to say the same thing. Some people will resonate with
some messages, and some others will pick holes in them. I will focus on
increasing the first set of people while preserving the semantics I believe
in.

Doru


On Mon, Apr 28, 2014 at 7:38 PM, Eliot Miranda wrote:

>
>
>
> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>
>> That is why we talk about Pharo as a cool, modern environment and
>> language that is Smalltalk-inspired.
>>
>
> We went through this a few months ago.  Pharo  isn't inspired by
> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
> as bad as apologizing for it being dead.
>
>
>> We do not need to apologize because Pharo was never dead :).
>>
>
> We don't need to avoid the S word either...
>
>
>>
>> Doru
>>
>>
>> On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:
>>
>>>
>>> Am 28.04.2014 um 18:58 schrieb kilon alios :
>>>
>>> very cool presentation. Definitely you need to add this to the new
>>> website.
>>>
>>> Question : Why in every presentation we have to apologise why smalltalk
>>> is dead / extinct ?
>>>
>>> As a newcomer to Smalltalk I find it quite annoying. Its not as if I
>>> came to Smalltalk without knowing that is not popular. The vast majority of
>>> languages out there are so more unpopular than Smalltalk, yet they don't
>>> have this "sorry that I am dead" mentality to them.
>>>
>>> +1
>>>
>>> Well said.
>>>
>>> Norbert
>>>
>>>
>>> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker 
>>> wrote:
>>>
 … more a Smalltalk one using Pharo:

 MountainWest RubyConf 2014

 Noel Rappin: "But Really, You Should Learn Smalltalk”

 Smalltalk has mystique. We talk about it more than we use it. It seems
 like it should be so similar to Ruby. It has similar Object-Oriented
 structures, it even has blocks. But everything is so slightly different,
 from the programming environment, to the 1-based arrays, to the simple
 syntax. Using Smalltalk will make you look at familiar constructs with new
 eyes. We’ll show you how to get started on Smalltalk, and walk through some
 sample code. Live coding may be involved. You’ll never look at objects the
 same way again.


 http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk

>>>
>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>
>
> --
> best,
> Eliot
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Esteban A. Maringolo]

Fair enough.

But to me the distinction is like Scheme and Common Lisp. They're
dialects of Lisp.
Other example is Racket, that tries to sell itself as a superior
Lisp/Scheme, as TypeScript tries to sell itself as a superset of
JavaScript :)

To me, they're all Lisp. As Pharo IS Smalltalk. Smalltalk as a
moniker, not as a particular spec.

Regards!


Esteban A. Maringolo


2014-04-28 15:24 GMT-03:00 Tudor Girba :
> Hi,
>
> I do not claim that Pharo does not look like a Smalltalk now. It does as it
> shares quite a bit with the model. But, I do claim that it already has
> distinctive characteristics that make it go away from a "classic" Smalltalk.
> And there will be more and more in the future.
>
> So, what is better as a communication strategy:
> - to say that Pharo is "a Smalltalk with traits, modular compiler, slots and
> moldable debugger, ... (more to come in this list)", or
> - to say that Pharo "is a modern Smalltalk-inspired system?"
> ?
>
> We are not fooling anyone. We simply state that while we respect everything
> that Smalltalk stands for, Pharo will not be bound to it. This is not being
> disrespectful, it is simply creating the premise to look at how else we can
> invent the future. And there is so much to invent there.
>
> Doru
>
>
> On Mon, Apr 28, 2014 at 7:56 PM, Sebastian Sastre
>  wrote:
>>
>>
>> On Apr 28, 2014, at 2:20 PM, Tudor Girba  wrote:
>>
>> That is why we talk about Pharo as a cool, modern environment and language
>> that is Smalltalk-inspired.
>>
>> We do not need to apologize because Pharo was never dead :).
>>
>>
>> nice joke
>>
>> Talking of Smalltalk-inspired…. Ruby is that, and is very successful BTW
>>
>> So, yeah, we are aware that it would be incredibly lame to try to fool
>> ourselves and the world by trying to sell the idea that Pharo is not a
>> Smalltalk.
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

Re: [Pharo-dev] a Pharo talk from a ruby conference

[kilon alios]

my pleasure

I missed a couple of words he said in the video, hence my misunderstanding.
As always few words are enough to turn a meaning on its head. Watched it
once more and now it clear that he presented Smalltalk in a very fair
manner. I also completely agree with his criticism on smalltalk of being
unsafe (though the same can be said about python and ruby and C/C++  and
loads of other programming languages out there) and not playing well with
others. Great demo for Smalltalk, realistic and fair.


On Mon, Apr 28, 2014 at 9:21 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Apr 28, 2014, at 2:57 PM, kilon alios  wrote:
>
> Sebastian you are absolutely correct, I did not understand that he was
> referring to a stereotype that ruby community has about smalltalk. I
> apologize.
>
>
> Is important that we talk these things so we understand how to break
> stereotypes that aren’t doing any good.
>
> So thanks for expressing it
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Tudor Girba]

Hi,

I do not claim that Pharo does not look like a Smalltalk now. It does as it
shares quite a bit with the model. But, I do claim that it already has
distinctive characteristics that make it go away from a "classic"
Smalltalk. And there will be more and more in the future.

So, what is better as a communication strategy:
- to say that Pharo is "a Smalltalk with traits, modular compiler, slots
and moldable debugger, ... (more to come in this list)", or
- to say that Pharo "is a modern Smalltalk-inspired system?"
?

We are not fooling anyone. We simply state that while we respect everything
that Smalltalk stands for, Pharo will not be bound to it. This is not being
disrespectful, it is simply creating the premise to look at how else we can
invent the future. And there is so much to invent there.

Doru


On Mon, Apr 28, 2014 at 7:56 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Apr 28, 2014, at 2:20 PM, Tudor Girba  wrote:
>
> That is why we talk about Pharo as a cool, modern environment and language
> that is Smalltalk-inspired.
>
> We do not need to apologize because Pharo was never dead :).
>
>
> nice joke
>
> Talking of Smalltalk-inspired…. Ruby is that, and is very successful BTW
>
> So, yeah, we are aware that it would be incredibly lame to try to fool
> ourselves and the world by trying to sell the idea that Pharo is *not* *a
> Smalltalk*.
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sebastian Sastre]

On Apr 28, 2014, at 2:57 PM, kilon alios  wrote:

> Sebastian you are absolutely correct, I did not understand that he was 
> referring to a stereotype that ruby community has about smalltalk. I 
> apologize. 

Is important that we talk these things so we understand how to break 
stereotypes that aren’t doing any good.

So thanks for expressing it

Re: [Pharo-dev] a Pharo talk from a ruby conference

[kilon alios]

Sebastian you are absolutely correct, I did not understand that he was
referring to a stereotype that ruby community has about smalltalk. I
apologize.


On Mon, Apr 28, 2014 at 8:27 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Apr 28, 2014, at 1:58 PM, kilon alios  wrote:
>
> very cool presentation. Definitely you need to add this to the new
> website.
>
> Question : Why in every presentation we have to apologise why smalltalk is
> dead / extinct ?
>
> Is not on video but for what’s worth, I don’t know from were you take that
> impression but I’m pretty sure that what you described in the previous
> paragraph was *not* the impression the audience got from my talk.
>
> “Dead / extinct” for the industry is a matter of nailing it when you
> expose talent and the tools that can expand it. Can you do cool projects
> with it? if you do then that’s your place, good for you, go for more, and
> give something in return.
>
> The hard work of this community is continuing the legacy of an inspiring
> legend.
>
> A legend that inspires them when you take the time and effort to break
> with self-serving tasks and start to expose it instead
>
>
>
> As a newcomer to Smalltalk I find it quite annoying. Its not as if I came
> to Smalltalk without knowing that is not popular. The vast majority of
> languages out there are so more unpopular than Smalltalk, yet they don't
> have this "sorry that I am dead" mentality to them.
>
>
>
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Esteban A. Maringolo]

It is good when an "outsider" talks about your stuff, they have views
we simply can't have because reflection is not always possible.

I think he nails the point about the shift from what's become
important and what not (24:45), and the monolithic or mandatory
approach of Smalltalk in general, vs the small utilities working
together
(Mainly Rule of Composition and Rule of Diversity).
http://www.catb.org/esr/writings/taoup/html/ch01s06.html

I think this has to do with the fact that Smalltalk was born with a
GUI, and then built down from there, instead of being born as a
command line program with an added GUI layer on top.

However, thank you for sharing, it is a good presentation. And I like
to see the enthusiasm of other when they meet Smalltalk. The MagLev
presentation is good too
(http://www.confreaks.com/videos/3285-mwrc-maglev-from-download-to-deploy).

Regards!





Esteban A. Maringolo


2014-04-28 13:12 GMT-03:00 Marcus Denker :
> … more a Smalltalk one using Pharo:
>
> MountainWest RubyConf 2014
>
> Noel Rappin: "But Really, You Should Learn Smalltalk”
>
> Smalltalk has mystique. We talk about it more than we use it. It seems like 
> it should be so similar to Ruby. It has similar Object-Oriented structures, 
> it even has blocks. But everything is so slightly different, from the 
> programming environment, to the 1-based arrays, to the simple syntax. Using 
> Smalltalk will make you look at familiar constructs with new eyes. We’ll show 
> you how to get started on Smalltalk, and walk through some sample code. Live 
> coding may be involved. You’ll never look at objects the same way again.
>
> 
> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sebastian Sastre]

On Apr 28, 2014, at 2:20 PM, Tudor Girba  wrote:

> That is why we talk about Pharo as a cool, modern environment and language 
> that is Smalltalk-inspired.
> 
> We do not need to apologize because Pharo was never dead :).


nice joke

Talking of Smalltalk-inspired…. Ruby is that, and is very successful BTW

So, yeah, we are aware that it would be incredibly lame to try to fool 
ourselves and the world by trying to sell the idea that Pharo is not a 
Smalltalk.

Re: [Pharo-dev] a Pharo talk from a ruby conference

[S Krish]

+1

Smalltalk heritage and its future should be carried on by "Pharo Smalltalk".


On Mon, Apr 28, 2014 at 11:08 PM, Eliot Miranda wrote:

>
>
>
> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>
>> That is why we talk about Pharo as a cool, modern environment and
>> language that is Smalltalk-inspired.
>>
>
> We went through this a few months ago.  Pharo  isn't inspired by
> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
> as bad as apologizing for it being dead.
>
>
>> We do not need to apologize because Pharo was never dead :).
>>
>
> We don't need to avoid the S word either...
>
>
>>
>> Doru
>>
>>
>> On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:
>>
>>>
>>> Am 28.04.2014 um 18:58 schrieb kilon alios :
>>>
>>> very cool presentation. Definitely you need to add this to the new
>>> website.
>>>
>>> Question : Why in every presentation we have to apologise why smalltalk
>>> is dead / extinct ?
>>>
>>> As a newcomer to Smalltalk I find it quite annoying. Its not as if I
>>> came to Smalltalk without knowing that is not popular. The vast majority of
>>> languages out there are so more unpopular than Smalltalk, yet they don't
>>> have this "sorry that I am dead" mentality to them.
>>>
>>> +1
>>>
>>> Well said.
>>>
>>> Norbert
>>>
>>>
>>> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker 
>>> wrote:
>>>
 … more a Smalltalk one using Pharo:

 MountainWest RubyConf 2014

 Noel Rappin: "But Really, You Should Learn Smalltalk”

 Smalltalk has mystique. We talk about it more than we use it. It seems
 like it should be so similar to Ruby. It has similar Object-Oriented
 structures, it even has blocks. But everything is so slightly different,
 from the programming environment, to the 1-based arrays, to the simple
 syntax. Using Smalltalk will make you look at familiar constructs with new
 eyes. We’ll show you how to get started on Smalltalk, and walk through some
 sample code. Live coding may be involved. You’ll never look at objects the
 same way again.


 http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk

>>>
>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>
>
> --
> best,
> Eliot
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Esteban A. Maringolo]

2014-04-28 14:38 GMT-03:00 Eliot Miranda :
> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba  wrote:
>> That is why we talk about Pharo as a cool, modern environment and language
>> that is Smalltalk-inspired.
> We went through this a few months ago.  Pharo  isn't inspired by Smalltalk;
> it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and claiming
> inspiration, rather than proudly declaring its a Smalltalk is IMO as bad as
> apologizing for it being dead.

I totally agree here.

Esteban.

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Eliot Miranda]

On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba  wrote:

> That is why we talk about Pharo as a cool, modern environment and language
> that is Smalltalk-inspired.
>

We went through this a few months ago.  Pharo  isn't inspired by Smalltalk;
it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and claiming
inspiration, rather than proudly declaring its a Smalltalk is IMO as bad as
apologizing for it being dead.


> We do not need to apologize because Pharo was never dead :).
>

We don't need to avoid the S word either...


>
> Doru
>
>
> On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl  wrote:
>
>>
>> Am 28.04.2014 um 18:58 schrieb kilon alios :
>>
>> very cool presentation. Definitely you need to add this to the new
>> website.
>>
>> Question : Why in every presentation we have to apologise why smalltalk
>> is dead / extinct ?
>>
>> As a newcomer to Smalltalk I find it quite annoying. Its not as if I came
>> to Smalltalk without knowing that is not popular. The vast majority of
>> languages out there are so more unpopular than Smalltalk, yet they don't
>> have this "sorry that I am dead" mentality to them.
>>
>> +1
>>
>> Well said.
>>
>> Norbert
>>
>>
>> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker wrote:
>>
>>> … more a Smalltalk one using Pharo:
>>>
>>> MountainWest RubyConf 2014
>>>
>>> Noel Rappin: "But Really, You Should Learn Smalltalk”
>>>
>>> Smalltalk has mystique. We talk about it more than we use it. It seems
>>> like it should be so similar to Ruby. It has similar Object-Oriented
>>> structures, it even has blocks. But everything is so slightly different,
>>> from the programming environment, to the 1-based arrays, to the simple
>>> syntax. Using Smalltalk will make you look at familiar constructs with new
>>> eyes. We’ll show you how to get started on Smalltalk, and walk through some
>>> sample code. Live coding may be involved. You’ll never look at objects the
>>> same way again.
>>>
>>>
>>> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
>>>
>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>



-- 
best,
Eliot

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Sebastian Sastre]

On Apr 28, 2014, at 1:58 PM, kilon alios  wrote:

> very cool presentation. Definitely you need to add this to the new website. 
> 
> Question : Why in every presentation we have to apologise why smalltalk is 
> dead / extinct ?   
> 
Is not on video but for what’s worth, I don’t know from were you take that 
impression but I’m pretty sure that what you described in the previous 
paragraph was not the impression the audience got from my talk.

“Dead / extinct” for the industry is a matter of nailing it when you expose 
talent and the tools that can expand it. Can you do cool projects with it? if 
you do then that’s your place, good for you, go for more, and give something in 
return.

The hard work of this community is continuing the legacy of an inspiring legend.

A legend that inspires them when you take the time and effort to break with 
self-serving tasks and start to expose it instead



> As a newcomer to Smalltalk I find it quite annoying. Its not as if I came to 
> Smalltalk without knowing that is not popular. The vast majority of languages 
> out there are so more unpopular than Smalltalk, yet they don't have this 
> "sorry that I am dead" mentality to them. 

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Tudor Girba]

That is why we talk about Pharo as a cool, modern environment and language
that is Smalltalk-inspired.

We do not need to apologize because Pharo was never dead :).

Doru


On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl  wrote:

>
> Am 28.04.2014 um 18:58 schrieb kilon alios :
>
> very cool presentation. Definitely you need to add this to the new
> website.
>
> Question : Why in every presentation we have to apologise why smalltalk is
> dead / extinct ?
>
> As a newcomer to Smalltalk I find it quite annoying. Its not as if I came
> to Smalltalk without knowing that is not popular. The vast majority of
> languages out there are so more unpopular than Smalltalk, yet they don't
> have this "sorry that I am dead" mentality to them.
>
> +1
>
> Well said.
>
> Norbert
>
>
> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker wrote:
>
>> … more a Smalltalk one using Pharo:
>>
>> MountainWest RubyConf 2014
>>
>> Noel Rappin: "But Really, You Should Learn Smalltalk”
>>
>> Smalltalk has mystique. We talk about it more than we use it. It seems
>> like it should be so similar to Ruby. It has similar Object-Oriented
>> structures, it even has blocks. But everything is so slightly different,
>> from the programming environment, to the 1-based arrays, to the simple
>> syntax. Using Smalltalk will make you look at familiar constructs with new
>> eyes. We’ll show you how to get started on Smalltalk, and walk through some
>> sample code. Live coding may be involved. You’ll never look at objects the
>> same way again.
>>
>>
>> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
>>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] a Pharo talk from a ruby conference

[Norbert Hartl]

Am 28.04.2014 um 18:58 schrieb kilon alios :

> very cool presentation. Definitely you need to add this to the new website. 
> 
> Question : Why in every presentation we have to apologise why smalltalk is 
> dead / extinct ?   
> 
> As a newcomer to Smalltalk I find it quite annoying. Its not as if I came to 
> Smalltalk without knowing that is not popular. The vast majority of languages 
> out there are so more unpopular than Smalltalk, yet they don't have this 
> "sorry that I am dead" mentality to them. 
> 
+1 

Well said.

Norbert
> 
> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker  wrote:
> … more a Smalltalk one using Pharo:
> 
> MountainWest RubyConf 2014
> 
> Noel Rappin: "But Really, You Should Learn Smalltalk”
> 
> Smalltalk has mystique. We talk about it more than we use it. It seems like 
> it should be so similar to Ruby. It has similar Object-Oriented structures, 
> it even has blocks. But everything is so slightly different, from the 
> programming environment, to the 1-based arrays, to the simple syntax. Using 
> Smalltalk will make you look at familiar constructs with new eyes. We’ll show 
> you how to get started on Smalltalk, and walk through some sample code. Live 
> coding may be involved. You’ll never look at objects the same way again.
> 
> 
> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
> 

Re: [Pharo-dev] a Pharo talk from a ruby conference

[kilon alios]

very cool presentation. Definitely you need to add this to the new website.

Question : Why in every presentation we have to apologise why smalltalk is
dead / extinct ?

As a newcomer to Smalltalk I find it quite annoying. Its not as if I came
to Smalltalk without knowing that is not popular. The vast majority of
languages out there are so more unpopular than Smalltalk, yet they don't
have this "sorry that I am dead" mentality to them.


On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker wrote:

> … more a Smalltalk one using Pharo:
>
> MountainWest RubyConf 2014
>
> Noel Rappin: "But Really, You Should Learn Smalltalk”
>
> Smalltalk has mystique. We talk about it more than we use it. It seems
> like it should be so similar to Ruby. It has similar Object-Oriented
> structures, it even has blocks. But everything is so slightly different,
> from the programming environment, to the 1-based arrays, to the simple
> syntax. Using Smalltalk will make you look at familiar constructs with new
> eyes. We’ll show you how to get started on Smalltalk, and walk through some
> sample code. Live coding may be involved. You’ll never look at objects the
> same way again.
>
>
> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[p...@highoctane.be]

On Mon, Apr 28, 2014 at 6:58 PM, kilon alios  wrote:

> very cool presentation. Definitely you need to add this to the new
> website.
>
> Question : Why in every presentation we have to apologise why smalltalk is
> dead / extinct ?
>
> As a newcomer to Smalltalk I find it quite annoying. Its not as if I came
> to Smalltalk without knowing that is not popular. The vast majority of
> languages out there are so more unpopular than Smalltalk, yet they don't
> have this "sorry that I am dead" mentality to them.
>
>
Pharo is a strategic platform to me. Productivity on that thing cannot be
beaten. Still had proof today when looking for a nasty bug.

Phil


>
> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker wrote:
>
>> … more a Smalltalk one using Pharo:
>>
>> MountainWest RubyConf 2014
>>
>> Noel Rappin: "But Really, You Should Learn Smalltalk”
>>
>> Smalltalk has mystique. We talk about it more than we use it. It seems
>> like it should be so similar to Ruby. It has similar Object-Oriented
>> structures, it even has blocks. But everything is so slightly different,
>> from the programming environment, to the 1-based arrays, to the simple
>> syntax. Using Smalltalk will make you look at familiar constructs with new
>> eyes. We’ll show you how to get started on Smalltalk, and walk through some
>> sample code. Live coding may be involved. You’ll never look at objects the
>> same way again.
>>
>>
>> http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk
>>
>
>

[Pharo-dev] a Pharo talk from a ruby conference

[Marcus Denker]

… more a Smalltalk one using Pharo:

MountainWest RubyConf 2014

Noel Rappin: "But Really, You Should Learn Smalltalk”

Smalltalk has mystique. We talk about it more than we use it. It seems like it 
should be so similar to Ruby. It has similar Object-Oriented structures, it 
even has blocks. But everything is so slightly different, from the programming 
environment, to the 1-based arrays, to the simple syntax. Using Smalltalk will 
make you look at familiar constructs with new eyes. We’ll show you how to get 
started on Smalltalk, and walk through some sample code. Live coding may be 
involved. You’ll never look at objects the same way again.


http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk

Re: [Pharo-dev] [Pharo-users] 30838 and 837 *REVERTED*

[Sean P. DeNigris]

Tudor Girba-2 wrote
> Thank you, Marcus.

+ 100



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

Re: [Pharo-dev] Amber-Pharo based coding dojo in a coworking space

[Mariano Martinez Peck]

>
>
>  Great to hear of small successes in reception of Pharo in the broader
> community.  Some ideas...
>
> 1. The most kick ass thing I can think of would go something like this...
>   a. Set up two computers nominally "customer" (or "webserver") and
> "support team".  Start the same image on each.
>   b. On the "customer" computer run some code that cause an error. In the
> debugger Fuel-out to a USB stick. Show them the small size of the file.
>   c. On the "support team" computer, insert the USB stick and drag the
> Fuel file into the image and start debugging.
>

Or the CI example were test failures are fueled out. This is a nice
extension to the typical CI behavior.


>   Even better if the code that was running was a morph stepping across the
> screen with some text inside counting up, and that counter and morph
> position were maintained in the transition to the second computer - but I'm
> not sure if Fuel would handle that.
>
>
There is no way to know it but trying. The only problem could be that
during the serialization, the traversed graph to serialize may be to big if
it reaches to the display and all its world and related objects. Also, you
may arrive to places that change so frequently like mouse position etc...
This normally happens when you end up serializing the whole UI. In this
case, it is likely the graph will change while you are serializing it...so
you will be screw. Of course, if can hook a bit and cut the graph...but you
should know in which place of your morph to cut.



> 2. Parts of the Zinc quick start might be worthwhile...
> http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/
>
> 3. Pull up halos on a menu and drag a duplicate a menu item onto the
> background, then show that it still works when it is clicked.  Bring up the
> halos again and inspect the morph where you can change the name of that
> menu item.  Exit Pharo and restart to show that the renamed menu item is
> still there.
>
> 4. Some of Doru's "build a custom browser" demos of Glamorous Toolkit are
> inspiring for how few lines of code are needed, but I don't have references.
>
> good luck,
> cheers -ben
>
>


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

Re: [Pharo-dev] [ANN]: Little NeoJSON Helper

[Sean P. DeNigris]

Sean P. DeNigris wrote
> I improved the API a bit. Now, the mapping is done via class-side
> #addNeoJsonMapTo: aNeoJSONReader.

Of course, if I had RTFM (more thoroughly), I would've noticed that Sven
already implemented that ;) So the hook is simply a default
Class>>#neoJsonMapping: which brings up the helper if no class-side mapping
is defined.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ANN-Little-NeoJSON-Helper-tp4756763p4756798.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Pharo-users] 30838 and 837 *REVERTED*

[Tudor Girba]

Thank you, Marcus.

Doru


On Mon, Apr 28, 2014 at 4:39 PM, Marcus Denker wrote:

>
> On 28 Apr 2014, at 16:31, Marcus Denker  wrote:
>
> > Hi,
> >
> > if you downloaded 30 838 (from today) or 30 837 please re-download 837.
> >
> > Both images where broken due to things that have to be done “just before
> the release”,
> > which are, of course, broken as they are only done just before the
> release once a year.
> >
>
> The 837 available now is ok:
>
> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/
>
> http://files.pharo.org/image/30/latest.zip
>
> Marcus
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Amber-Pharo based coding dojo in a coworking space

[Ben Coman]

Sebastian Sastre wrote:

  
Hi guys,
  
  
  I thought you might like to hear that after presenting a case on
Smalltalk using these slides:
  
  
  http://dinos.flowingconcept.com
  
  
  to an for
an heterogeneous audience ~(10% devel 10% creatives a couple of angel
investors and most people with administration profile) in a coworking space.
  
  
  Many
things happened after that session, one of those was that developers
there started to ask for more but only after I’ve shown
them availability for a demoing / coding session together.
  
  
  So, that coworking has scheduled a friday night coding dojo
in a couple of weeks where they expect that I show them how to use
Smalltalk to kick some ass
  
  
  
  
  
  
  sebastian
  
  
  o/
  
  
  
  
  
  
  

Great to hear of small successes in reception of Pharo in the broader
community.  Some ideas...

1. The most kick ass thing I can think of would go something like
this...
  a. Set up two computers nominally "customer" (or "webserver") and
"support team".  Start the same image on each.
  b. On the "customer" computer run some code that cause an error. In
the debugger Fuel-out to a USB stick. Show them the small size of the
file.
  c. On the "support team" computer, insert the USB stick and drag the
Fuel file into the image and start debugging.
  Even better if the code that was running was a morph stepping across
the screen with some text inside counting up, and that counter and
morph position were maintained in the transition to the second computer
- but I'm not sure if Fuel would handle that.

2. Parts of the Zinc quick start might be worthwhile...
    http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/

3. Pull up halos on a menu and drag a duplicate a menu item onto the
background, then show that it still works when it is clicked.  Bring up
the halos again and inspect the morph where you can change the name of
that menu item.  Exit Pharo and restart to show that the renamed menu
item is still there.

4. Some of Doru's "build a custom browser" demos of Glamorous Toolkit
are inspiring for how few lines of code are needed, but I don't have
references.

good luck, 
cheers -ben

Re: [Pharo-dev] [ANN]: Little NeoJSON Helper

[Sean P. DeNigris]

Sean P. DeNigris wrote
> "Assuming Neo-JSON-Core is loaded"
> To aid in writing mappings, send "reader mapHelperFor: MyDomainClass"

I improved the API a bit. Now, the mapping is done via class-side
#addNeoJsonMapTo: aNeoJSONReader.
The default (defined in class) brings up the helper. So now you can write:
MyClass addNeoJsonMapTo: aNeoJSONReader.

The first time you do this, you will get an inspector on the helper object,
which you still send #generateInstVars.

But for the second step, you now send #generateMapping, which compiles
MyClass class>>#addNeoJsonMapTo: with the necessary mapping.

If you're mapping a collection, you probably have to close the halt debugger
now and restart, because the default behavior of inspecting the helper is
cached in the reader. Otherwise, you can proceed and map the next class.

I like the class side methods because they decompose monolithic mapping
declarations and can be reused.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ANN-Little-NeoJSON-Helper-tp4756763p4756791.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Amber-Pharo based coding dojo in a coworking space

[Nicolas Petton]

Awesome! It's really cool to see you pushing like this! Keep going!

Cheers,
Nico

Sebastian Sastre writes:

> Hi guys,
>
> I thought you might like to hear that after presenting a case on Smalltalk 
> using these slides:
>
> http://dinos.flowingconcept.com
>
> to an for an heterogeneous audience ~(10% devel 10% creatives a couple of 
> angel investors and most people with administration profile) in a coworking 
> space.
>
> Many things happened after that session, one of those was that developers 
> there started to ask for more but only after I’ve shown them availability for 
> a demoing / coding session together.
>
> So, that coworking has scheduled a friday night coding dojo in a couple of 
> weeks where they expect that I show them how to use Smalltalk to kick some ass
>
> sebastian
>
> o/


-- 
Nicolas Petton
http://nicolas-petton.fr

Re: [Pharo-dev] 30838 and 837 *REVERTED*

[Marcus Denker]

On 28 Apr 2014, at 16:31, Marcus Denker  wrote:

> Hi,
> 
> if you downloaded 30 838 (from today) or 30 837 please re-download 837.
> 
> Both images where broken due to things that have to be done “just before the 
> release”,
> which are, of course, broken as they are only done just before the release 
> once a year.
> 

The 837 available now is ok:

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/

http://files.pharo.org/image/30/latest.zip

Marcus

[Pharo-dev] 30838 and 837 *REVERTED*

[Marcus Denker]

Hi,

if you downloaded 30 838 (from today) or 30 837 please re-download 837.

Both images where broken due to things that have to be done “just before the 
release”,
which are, of course, broken as they are only done just before the release once 
a year.

Marcus

Re: [Pharo-dev] [Pharo3] 30837 has new sources file

[Marcus Denker]

On 28 Apr 2014, at 16:21, Sven Van Caekenberghe  wrote:

> 
> On 28 Apr 2014, at 16:12, Marcus Denker  wrote:
> 
>> A close examination shows that *all* class side Traits methods have broken 
>> source pointers…
> 
> Maybe that is just an oversight and easily fixed ?

I reverted… the condenser needs to be fixed and after we should waste another 
hours on doing all this
again.

Marcus

Re: [Pharo-dev] [Pharo3] 30837 has new sources file

[Sven Van Caekenberghe]

On 28 Apr 2014, at 16:12, Marcus Denker  wrote:

> A close examination shows that *all* class side Traits methods have broken 
> source pointers…

Maybe that is just an oversight and easily fixed ?

Re: [Pharo-dev] [Pharo3] 30837 has new sources file

[Sven Van Caekenberghe]

On 28 Apr 2014, at 15:58, Marcus Denker  wrote:

> 
> On 28 Apr 2014, at 15:34, Marcus Denker  wrote:
> 
>> Hi,
>> 
>> So we did
>> 
>> -> an update 30837 to remove a bit of Scriploader methods so the do not end 
>> up in the .sources file (60.000 LOC…)
>> -> then we condensed the sources and changes and re-uploaded that file.
>> -> Zeroconf has been updated. Now it download V1, V2 and V3 sources… (which 
>> is far from nice… but works).
>> -> the sources files is here: http://files.pharo.org/sources/
>> 
>> Overall, the whole sources and changes mechanism again showed that it was 
>> not designed with the idea in mind
>> to be able to “release at any point”. Our goal has to be that the build 
>> server artefact is the release artefact. 
>> Concerning .sources and .changes this is not the case… we really need 
>> another design.
>> 
> 
> e.g. now we have three tests failing:
> 
>> SlotTests.SlotTraitsTest.testClassWithTrait2

>> Tests.Files.SourceFileArrayTest.testProtocol

It seems that there is a minor difference in the method timestamp:

testProtocol
"Test that we can access protocol correctly"
"self debug: #testProtocol"

| okCm notOkCm |
okCm := Point>>#dist: .
self assert: (SourceFiles sourcedDataAt: okCm sourcePointer) = 'Point 
methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42'''.

while 

SourceFiles sourcedDataAt: okCm sourcePointer 

equals

'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42'' prior: 0'

it is just the prior: 0

>> Tests.Files.SourceFileArrayTest.testTimeStamp

same here, the rest is OK

> I think the first goal of Pharo4 should be to make the artefact from the 
> build server a true release
> artefact…
> 
>   Marcus

Re: [Pharo-dev] [Pharo3] 30837 has new sources file

[Marcus Denker]

On 28 Apr 2014, at 15:58, Marcus Denker  wrote:

> 
> On 28 Apr 2014, at 15:34, Marcus Denker  wrote:
> 
>> Hi,
>> 
>> So we did
>> 
>> -> an update 30837 to remove a bit of Scriploader methods so the do not end 
>> up in the .sources file (60.000 LOC…)
>> -> then we condensed the sources and changes and re-uploaded that file.
>> -> Zeroconf has been updated. Now it download V1, V2 and V3 sources… (which 
>> is far from nice… but works).
>> -> the sources files is here: http://files.pharo.org/sources/
>> 
>> Overall, the whole sources and changes mechanism again showed that it was 
>> not designed with the idea in mind
>> to be able to “release at any point”. Our goal has to be that the build 
>> server artefact is the release artefact. 
>> Concerning .sources and .changes this is not the case… we really need 
>> another design.
>> 
> 
> e.g. now we have three tests failing:
> 
>> SlotTests.SlotTraitsTest.testClassWithTrait2
>> Tests.Files.SourceFileArrayTest.testProtocol
>> Tests.Files.SourceFileArrayTest.testTimeStamp
> 
> 
> I think the first goal of Pharo4 should be to make the artefact from the 
> build server a true release
> artefact…
> 

 A close examination shows that *all* class side Traits methods have broken 
source pointers…

So let’s revert everything…

(and I guess we do not need any other proof that *THE BUILD SERVER ARTEFACT 
NEEDS TO BE THE
ARTEFACT OF RELEASE*.

Marcus.

[Pharo-dev] [ANN]: Little NeoJSON Helper

[Sean P. DeNigris]

"Assuming Neo-JSON-Core is loaded"
Gofer it
smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground';
package: 'Neo-JSON-Utilities';
load.

To aid in writing mappings, send "reader mapHelperFor: MyDomainClass", where
MyDomainClass need not even exist. This will halt inside the mapping, and
bring up an inspector on a NeoJSONMapHelper object. 

>From here, you can #generateInstVars to map the json keys to inst vars,
translating underscores to camel case.

Then you can inspect #mappingSnippet, which will give you the code to
replace "reader mapHelperFor: MyDomainClass" with the new mappings to inst
vars. For example:
mapper for: DoDropletSize do: [ :m |
m
mapInstVars: #(name cpu slug memory id disk);
mapInstVar: #costPerHour to: #cost_per_hour;
mapInstVar: #costPerMonth to: #cost_per_month ].

It could be enhanced, especially with a UI to further customize the mappings
(e.g. maybe you want to map the boolean "required" key to a more
Smalltalkish "isRequired" inst var, but it makes the common cases a bit
easier.

HTH :)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ANN-Little-NeoJSON-Helper-tp4756763.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] ef6865: 30838

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: ef6865d4ee8946855c64c4131e505ea13852bd8e
  
https://github.com/pharo-project/pharo-core/commit/ef6865d4ee8946855c64c4131e505ea13852bd8e
  Author: Jenkins Build Server 
  Date:   2014-04-28 (Mon, 28 Apr 2014)

  Changed paths:
M Athens-Cairo.package/TCairoLibrary.class/class/library 
path/nbLibraryNameOrHandle.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script100.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
updates/update30838.st
M 
ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M SlotTests.package/TOne.class/class/testing/classOne.st
M 
Traits.package/TClass.class/class/fileIn%2FOut/allSuperclassesFor_cache_.st
M 
Traits.package/TClass.class/class/fileIn%2FOut/doesNotIncludeInstanceOrSuperclassesFor_in_cache_.st
M Traits.package/TClass.class/class/fileIn%2FOut/fileOutPool_.st
M 
Traits.package/TClass.class/class/fileIn%2FOut/hasNoDependenciesForMetaclass_in_cache_.st
M 
Traits.package/TClass.class/class/fileIn%2FOut/hasNoSuperclassesOf_in_cache_.st
M Traits.package/TClass.class/class/fileIn%2FOut/superclassOrder_.st
M Traits.package/TClass.class/class/inquiries/rootsOfTheWorld.st
M Traits.package/TClass.class/class/instance 
creation/templateForSubclassOf_category_.st
M Traits.package/TClass.class/class/instance creation/template_.st
M 
Traits.package/TClass.class/class/private/hasNoDependenciesFor_in_cache_.st
M 
Zinc-System-Support.package/extension/SmalltalkImage/instance/downloadSources.st
M Zinc-Tests.package/ZnClientTests.class/instance/testing/testProgress.st

  Log Message:
  ---
  30838
- fix the refs to PharoV3 sources in the downloader

http://files.pharo.org/image/30/30838.zip

Re: [Pharo-dev] Hijri calendar

[Maximiliano Taborda]

Hi Stef.
Yes, of course.
Please, tell me what kind of documentation you need.

Regards.
Maxi


2014-04-27 18:07 GMT-03:00 stepharo :

>  Hi maximillo
>
> would you be interested to have a chapter on our next book on Chalten?
> I hope so. We could take your documentation at input.
>
> Stef
>
>
>
>
> On 23/4/14 22:44, Maximiliano Taborda wrote:
>
>  Hi,
> You could try Chalten, it also has support for the Islamic Calendar.
> Take a look here: https://github.com/mtaborda/chalten.
>
>  Regards.
> Maxi
>
>
> 2014-04-23 17:26 GMT-03:00 Paul DeBruicker :
>
>> Torsten Bergmann wrote
>>  > Paul DeBruicker wrote
>> >> Chronos has:
>> >> ...
>> >> Is that what you want?
>> >
>> > The www.chronos-st.org seems to be gone. But there is
>> > http://smalltalkhub.com/#!/~Chronos/Chronos/
>> >
>> > Thanks - I will have a look. Is it known to work in Pharo 3.0?
>> >
>> > Thx
>> > T.
>>
>>  Eh it will probably die because the base config loads code that uses
>> FileDirectory.  I did port it to Pharo 2.  I think if you edit the
>> ConfigurationOfChronos to load into Pharo 3 what it loads into Pharo 2 it
>> should work OK.  But I haven't tried it.
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Hijri-calendar-tp4756080p4756106.html
>>  Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>
>

Re: [Pharo-dev] [Pharo3] 30837 has new sources file

[Marcus Denker]

On 28 Apr 2014, at 15:34, Marcus Denker  wrote:

> Hi,
> 
> So we did
> 
> -> an update 30837 to remove a bit of Scriploader methods so the do not end 
> up in the .sources file (60.000 LOC…)
> -> then we condensed the sources and changes and re-uploaded that file.
> -> Zeroconf has been updated. Now it download V1, V2 and V3 sources… (which 
> is far from nice… but works).
> -> the sources files is here: http://files.pharo.org/sources/
> 
> Overall, the whole sources and changes mechanism again showed that it was not 
> designed with the idea in mind
> to be able to “release at any point”. Our goal has to be that the build 
> server artefact is the release artefact. 
> Concerning .sources and .changes this is not the case… we really need another 
> design.
> 

e.g. now we have three tests failing:

>  SlotTests.SlotTraitsTest.testClassWithTrait2
>  Tests.Files.SourceFileArrayTest.testProtocol
>  Tests.Files.SourceFileArrayTest.testTimeStamp


I think the first goal of Pharo4 should be to make the artefact from the build 
server a true release
artefact…

Marcus

[Pharo-dev] Amber-Pharo based coding dojo in a coworking space

[Sebastian Sastre]

Hi guys,

I thought you might like to hear that after presenting a case on Smalltalk 
using these slides:

http://dinos.flowingconcept.com

to an for an heterogeneous audience ~(10% devel 10% creatives a couple of angel 
investors and most people with administration profile) in a coworking space.

Many things happened after that session, one of those was that developers there 
started to ask for more but only after I’ve shown them availability for a 
demoing / coding session together.

So, that coworking has scheduled a friday night coding dojo in a couple of 
weeks where they expect that I show them how to use Smalltalk to kick some ass

sebastian

o/

[Pharo-dev] [Pharo3] 30837 has new sources file

[Marcus Denker]

Hi,

So we did

-> an update 30837 to remove a bit of Scriploader methods so the do not end up 
in the .sources file (60.000 LOC…)
-> then we condensed the sources and changes and re-uploaded that file.
-> Zeroconf has been updated. Now it download V1, V2 and V3 sources… (which is 
far from nice… but works).
-> the sources files is here: http://files.pharo.org/sources/

Overall, the whole sources and changes mechanism again showed that it was not 
designed with the idea in mind
to be able to “release at any point”. Our goal has to be that the build server 
artefact is the release artefact. 
Concerning .sources and .changes this is not the case… we really need another 
design.

 Next

-> update to fix the direct pointer to the PharoV2 sources in the source 
downloader
-> MC history pruning


Marcus

[Pharo-dev] [pharo-project/pharo-core] 659670: 30837

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 659670e7cb6f37d4d76c485f11bb7c6870f71862
  
https://github.com/pharo-project/pharo-core/commit/659670e7cb6f37d4d76c485f11bb7c6870f71862
  Author: Jenkins Build Server 
  Date:   2014-04-28 (Mon, 28 Apr 2014)

  Changed paths:
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script282.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script283.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script284.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script285.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script286.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script287.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script288.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script289.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script290.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script291.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script292.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script293.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script294.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script295.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script296.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script297.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script298.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script299.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script300.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script301.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script302.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script303.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script304.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script305.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script306.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script307.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script308.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script309.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script310.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script311.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script312.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script313.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script314.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script315.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script316.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script317.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script318.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script319.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script320.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script321.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script322.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script323.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script324.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script325.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script326.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script327.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script328.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script329.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script330.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script331.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script332.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script333.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script334.st
R ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scr

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

[GitHub]

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

Re: [Pharo-dev] [Pharo3] New Sources File

[Marcus Denker]

On 28 Apr 2014, at 14:43, Norbert Hartl  wrote:

> 
> Am 28.04.2014 um 14:21 schrieb Marcus Denker :
> 
>> 
>> On 28 Apr 2014, at 14:11, Esteban Lorenzano  wrote:
>> 
>>> yes we are :)
>>> 
>>> On 28 Apr 2014, at 14:10, Sven Van Caekenberghe  wrote:
>>> 
 Are we also going to do a condenseChanges ?
 I think that would be good too.
 And then finally also cleaning the MC caches I guess.
>> 
>> And ScriptLoader… that is always growing like a weed, too.
>> (and the code still is accessible in the repo).
>> 
>> a test-run shows:
>> 
>> Size of Image: 21MB
>> Size of .sources: 31.6MB
>> 
>> (sources zipped is 6.4MB… we really should embed the sources file in the 
>> image…
>> but that is for Pharo4 ;-) 
>> 
> I didn’t understand until now how I can have a pharo4 with external sources. 
> Will this be possible by any supporting code. You know I still dream about an 
> embedded device that has less memory where I can remotely attach an pharo 
> image to do live debugging/coding :)
> 

The design has not been done yet… so this is unknown.

Marcus

Re: [Pharo-dev] [Pharo3] New Sources File

[Norbert Hartl]

Am 28.04.2014 um 14:21 schrieb Marcus Denker :

> 
> On 28 Apr 2014, at 14:11, Esteban Lorenzano  wrote:
> 
>> yes we are :)
>> 
>> On 28 Apr 2014, at 14:10, Sven Van Caekenberghe  wrote:
>> 
>>> Are we also going to do a condenseChanges ?
>>> I think that would be good too.
>>> And then finally also cleaning the MC caches I guess.
> 
> And ScriptLoader… that is always growing like a weed, too.
> (and the code still is accessible in the repo).
> 
> a test-run shows:
> 
> Size of Image: 21MB
> Size of .sources: 31.6MB
> 
> (sources zipped is 6.4MB… we really should embed the sources file in the 
> image…
> but that is for Pharo4 ;-) 
> 
I didn’t understand until now how I can have a pharo4 with external sources. 
Will this be possible by any supporting code. You know I still dream about an 
embedded device that has less memory where I can remotely attach an pharo image 
to do live debugging/coding :)

Norbert

Re: [Pharo-dev] [Pharo3] New Sources File

[Marcus Denker]

On 28 Apr 2014, at 14:11, Esteban Lorenzano  wrote:

> yes we are :)
> 
> On 28 Apr 2014, at 14:10, Sven Van Caekenberghe  wrote:
> 
>> Are we also going to do a condenseChanges ?
>> I think that would be good too.
>> And then finally also cleaning the MC caches I guess.

And ScriptLoader… that is always growing like a weed, too.
(and the code still is accessible in the repo).

a test-run shows:

Size of Image: 21MB
Size of .sources: 31.6MB

(sources zipped is 6.4MB… we really should embed the sources file in the image…
but that is for Pharo4 ;-) 

Marcus

Re: [Pharo-dev] [Pharo3] New Sources File

[Esteban Lorenzano]

yes we are :)

On 28 Apr 2014, at 14:10, Sven Van Caekenberghe  wrote:

> Are we also going to do a condenseChanges ?
> I think that would be good too.
> And then finally also cleaning the MC caches I guess.
> 
> On 28 Apr 2014, at 14:01, Marcus Denker  wrote:
> 
>> Hi,
>> 
>> We will do a PharoV3.sources for Pharo3. This will take a couple of 
>> interations to do
>> (e.g. uploading it to files.pharo.org, updating zeroconf… fining references 
>> in the image for the
>> downloader).
>> 
>> As soon as we have it will will send the link.
>> 
>>  Marcus
> 
> 

Re: [Pharo-dev] [Pharo3] New Sources File

[Sven Van Caekenberghe]

Are we also going to do a condenseChanges ?
I think that would be good too.
And then finally also cleaning the MC caches I guess.

On 28 Apr 2014, at 14:01, Marcus Denker  wrote:

> Hi,
> 
> We will do a PharoV3.sources for Pharo3. This will take a couple of 
> interations to do
> (e.g. uploading it to files.pharo.org, updating zeroconf… fining references 
> in the image for the
> downloader).
> 
> As soon as we have it will will send the link.
> 
>   Marcus

[Pharo-dev] [Pharo3] New Sources File

[Marcus Denker]

Hi,

We will do a PharoV3.sources for Pharo3. This will take a couple of interations 
to do
(e.g. uploading it to files.pharo.org, updating zeroconf… fining references in 
the image for the
downloader).

As soon as we have it will will send the link.

Marcus

Re: [Pharo-dev] Stable Mac VM for latest 3.0?

[Henrik Johansen]

On 28 Apr 2014, at 1:08 , stepharo  wrote:

> Hi henrik
> 
> I downloaded vm 338 and the latest image 30836 and I could not reproduce your 
> problem.
> 
> 
> Smalltalk vm buildDate  'Mac Cocoa Cog 5.8b12 21-Sep-10 
> >1B0534FA-246C-47C5-AB29-7A76C81CCDCB<'
> so the build date looks bogus to me 
> 
> Smalltalk vm platformSourceVersion
> did not work either.
> 
It was fixed by reverting 30830.

Cheers,
Henry


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] Stable Mac VM for latest 3.0?

[stepharo]

Hi henrik

I downloaded vm 338 and the latest image 30836 and I could not reproduce 
your problem.



Smalltalk vm buildDate  'Mac Cocoa Cog 5.8b12 21-Sep-10 
>1B0534FA-246C-47C5-AB29-7A76C81CCDCB<'

so the build date looks bogus to me

Smalltalk vm platformSourceVersion
did not work either.



On 24/4/14 12:52, Henrik Johansen wrote:

I tried loading Roassal3d into 30830 using
Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: 
'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) 
loadDevelopment

using both the VM linked at
http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-stable.zip (from December?)
and the latest successful from CI
https://ci.inria.fr/pharo/view/3.0-VM/job/PharoVM/Architecture=32,Slave=vm-builder-mac/lastSuccessfulBuild/artifact/337.zip

And both crash for me during load (attached  report)...

Anyone know where a VM which works is located?

Cheers,
Henry

Re: [Pharo-dev] Fast way to load package form github

[Goubier Thierry]

Le 28/04/2014 11:37, François Stephany a écrit :

Thank you both for the details!

Haha, I understand if you prefere to be on your own for the bindings (at
least while it's still in construction).
Thierry, If you need some feedback for the merge conflict resolution,
I'll be glad to help. Just ask :)


Thanks, I'll need it. I let you know, and anybody else interested, when 
I have something to test; soon.


Thierry


Max, I don't know how is your master thesis schedule organized but if
you're interested, we can maybe try to allocate a summer of code with
the libgit2 integration?

Cheers,
Francois



On Mon, Apr 28, 2014 at 11:08 AM, Max Leske mailto:maxle...@gmail.com>> wrote:


On 28.04.2014, at 10:42, François Stephany
mailto:tulipe.mouta...@gmail.com>> wrote:


Sounds *really* good!

Do you have a time goal for this integration (even rough estimate)?
Sorry if this sound stupid but are we far from an integration
with, say, the "Changes" tool?

If you need some help somewhere (money or manpower), I'm sure
there are quite a few people interesting in donating for this (Ta
Mère is).


It’s on the way but we still have some way to go. I’ll be off the
grid for the next 4 weeks and after that I’ll have to prepare for my
exams. Still, I hope that I can show a prototype for using github
around mid June (I’m pessimistic on purpose here). BTW: push and
fetch via SSH / HTTPS already work (but you don’t want to see the
code…).

I’m glad you’re so enthusiastic but it’s a complex project and I
don’t want to rush it (it’s also part of my master’s thesis btw).

I’m posting updates from time to time with “FileSystem-Git update X”
or similar in the subject if you want to follow. There’s also a
dedicated mailing list: smalltalk-...@googlegroups.com


To answer your questions:
- no, there is no concrete plan other than “ships with Pharo4” (I hope…)
- tool integration should be pretty straight forward once the
bindings work. But I really can’t give you a date.

As soon as there’s stuff that can be easily partitioned into
workable chunks I’ll take to the mailing list. But I want to do the
bindinds first, preferably on my own (requires a lot of special
knowledge about git / libgit2 / NativeBoost). But thanks for the
offer anyway. Much appreciated!

Cheers,
Max




On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry
mailto:thierry.goub...@cea.fr>> wrote:

Hi François,

with gitfiletree://, there isn't any real place describing a
multi-developper workflow because it is designed to work along
existing workflows... as much as possible.

In short, you work like you used to do in git, and gitfiletree
ensures that the commit are properly made, that you have
access to your development history (your true development
history: the git one), and that pushes and pulls are made as
painless as possible.

After, you just manage your git the way you like it. Branches,
merging, one branch per developper, whatever: gitfiletree://
will ensure that what you see inside Pharo is what you have
done in git, and that what you do in Pharo is properly
committed to git.

Now, the bad thing: git merge conflicts :( When merging
packages under git, some files will regularly(allways :()
conflict: the version history of the package and the method
properties. Whatever way you resolve those conflicts,
gitfiletree:// will cope because it never reads them, but,
still, having conflicts in git isn't cool.

We have a better integration coming, through Max Leske work on
integrating libgit to Pharo, and we will be able to solve some
of the issues above ;)

Thierry



*De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org
] de la part de
François Stephany [tulipe.mouta...@gmail.com
]

*Envoyé :* samedi 26 avril 2014 19:06
*À :* Pharo Development List
*Objet :* Re: [Pharo-dev] Fast way to load package form github

I'm a bit lost of what is currently possible to do with git in
Pharo. Is there a place where you describe your workflow in a
multi-developer environment?

We currently use git flow[1] for our iOS, Android and Rails
apps. We would love to use the same for Pharo. What we are
doing now is using a filetree repository under a src/
directory sitting next to the image. We use versionner to save
all our packages in the filetree tree and then we `git
commit/push`.

It was working fine while I was alone but we are now two
   

Re: [Pharo-dev] Fast way to load package form github

[François Stephany]

Thank you both for the details!

Haha, I understand if you prefere to be on your own for the bindings (at
least while it's still in construction).
Thierry, If you need some feedback for the merge conflict resolution, I'll
be glad to help. Just ask :)

Max, I don't know how is your master thesis schedule organized but if
you're interested, we can maybe try to allocate a summer of code with the
libgit2 integration?

Cheers,
Francois



On Mon, Apr 28, 2014 at 11:08 AM, Max Leske  wrote:

>
> On 28.04.2014, at 10:42, François Stephany 
> wrote:
>
> Sounds *really* good!
>
> Do you have a time goal for this integration (even rough estimate)?
> Sorry if this sound stupid but are we far from an integration with, say,
> the "Changes" tool?
>
> If you need some help somewhere (money or manpower), I'm sure there are
> quite a few people interesting in donating for this (Ta Mère is).
>
>
> It’s on the way but we still have some way to go. I’ll be off the grid for
> the next 4 weeks and after that I’ll have to prepare for my exams. Still, I
> hope that I can show a prototype for using github around mid June (I’m
> pessimistic on purpose here). BTW: push and fetch via SSH / HTTPS already
> work (but you don’t want to see the code…).
>
> I’m glad you’re so enthusiastic but it’s a complex project and I don’t
> want to rush it (it’s also part of my master’s thesis btw).
>
> I’m posting updates from time to time with “FileSystem-Git update X” or
> similar in the subject if you want to follow. There’s also a dedicated
> mailing list: smalltalk-...@googlegroups.com
>
> To answer your questions:
> - no, there is no concrete plan other than “ships with Pharo4” (I hope…)
> - tool integration should be pretty straight forward once the bindings
> work. But I really can’t give you a date.
>
> As soon as there’s stuff that can be easily partitioned into workable
> chunks I’ll take to the mailing list. But I want to do the bindinds first,
> preferably on my own (requires a lot of special knowledge about git /
> libgit2 / NativeBoost). But thanks for the offer anyway. Much appreciated!
>
> Cheers,
> Max
>
>
>
> On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry 
> wrote:
>
>>  Hi François,
>>
>> with gitfiletree://, there isn't any real place describing a
>> multi-developper workflow because it is designed to work along existing
>> workflows... as much as possible.
>>
>> In short, you work like you used to do in git, and gitfiletree ensures
>> that the commit are properly made, that you have access to your development
>> history (your true development history: the git one), and that pushes and
>> pulls are made as painless as possible.
>>
>> After, you just manage your git the way you like it. Branches, merging,
>> one branch per developper, whatever: gitfiletree:// will ensure that what
>> you see inside Pharo is what you have done in git, and that what you do in
>> Pharo is properly committed to git.
>>
>> Now, the bad thing: git merge conflicts :( When merging packages under
>> git, some files will regularly(allways :() conflict: the version history of
>> the package and the method properties. Whatever way you resolve those
>> conflicts, gitfiletree:// will cope because it never reads them, but,
>> still, having conflicts in git isn't cool.
>>
>> We have a better integration coming, through Max Leske work on
>> integrating libgit to Pharo, and we will be able to solve some of the
>> issues above ;)
>>
>> Thierry
>>
>>
>>  --
>> *De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de
>> François Stephany [tulipe.mouta...@gmail.com]
>>
>> *Envoyé :* samedi 26 avril 2014 19:06
>> *À :* Pharo Development List
>> *Objet :* Re: [Pharo-dev] Fast way to load package form github
>>
>> I'm a bit lost of what is currently possible to do with git in
>> Pharo. Is there a place where you describe your workflow in a
>> multi-developer environment?
>>
>>  We currently use git flow[1] for our iOS, Android and Rails apps. We
>> would love to use the same for Pharo. What we are doing now is using a
>> filetree repository under a src/ directory sitting next to the image. We
>> use versionner to save all our packages in the filetree tree and then we
>> `git commit/push`.
>>
>>  It was working fine while I was alone but we are now two developers
>> working on this and I do not feel confident about this flow; merging
>> filetree tree in CLI doesn't sound like a good idea. probably not be
>> practical.
>>
>>  The second developer is working on this since yesterday so we haven't
>> yet decided how we gonna handle this.
>>
>>  I would love to hear from people working with git and Pharo.
>>
>>
>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>
>>
>> On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry 
>> wrote:
>>
>>> Yuri,
>>>
>>> pure filetree will only allow you access to the latest version (HEAD) of
>>> the repository (and will only match if you load that precise version number
>>> as stored in the p

Re: [Pharo-dev] Fast way to load package form github

[Max Leske]

On 28.04.2014, at 10:42, François Stephany  wrote:

> Sounds *really* good!
> 
> Do you have a time goal for this integration (even rough estimate)? 
> Sorry if this sound stupid but are we far from an integration with, say, the 
> "Changes" tool?
> 
> If you need some help somewhere (money or manpower), I'm sure there are quite 
> a few people interesting in donating for this (Ta Mère is).

It’s on the way but we still have some way to go. I’ll be off the grid for the 
next 4 weeks and after that I’ll have to prepare for my exams. Still, I hope 
that I can show a prototype for using github around mid June (I’m pessimistic 
on purpose here). BTW: push and fetch via SSH / HTTPS already work (but you 
don’t want to see the code…).

I’m glad you’re so enthusiastic but it’s a complex project and I don’t want to 
rush it (it’s also part of my master’s thesis btw).

I’m posting updates from time to time with “FileSystem-Git update X” or similar 
in the subject if you want to follow. There’s also a dedicated mailing list: 
smalltalk-...@googlegroups.com

To answer your questions: 
- no, there is no concrete plan other than “ships with Pharo4” (I hope…)
- tool integration should be pretty straight forward once the bindings work. 
But I really can’t give you a date.

As soon as there’s stuff that can be easily partitioned into workable chunks 
I’ll take to the mailing list. But I want to do the bindinds first, preferably 
on my own (requires a lot of special knowledge about git / libgit2 / 
NativeBoost). But thanks for the offer anyway. Much appreciated!

Cheers,
Max


> 
> On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry  
> wrote:
> Hi François,
> 
> with gitfiletree://, there isn't any real place describing a multi-developper 
> workflow because it is designed to work along existing workflows... as much 
> as possible.
> 
> In short, you work like you used to do in git, and gitfiletree ensures that 
> the commit are properly made, that you have access to your development 
> history (your true development history: the git one), and that pushes and 
> pulls are made as painless as possible.
> 
> After, you just manage your git the way you like it. Branches, merging, one 
> branch per developper, whatever: gitfiletree:// will ensure that what you see 
> inside Pharo is what you have done in git, and that what you do in Pharo is 
> properly committed to git.
> 
> Now, the bad thing: git merge conflicts :( When merging packages under git, 
> some files will regularly(allways :() conflict: the version history of the 
> package and the method properties. Whatever way you resolve those conflicts, 
> gitfiletree:// will cope because it never reads them, but, still, having 
> conflicts in git isn't cool.
> 
> We have a better integration coming, through Max Leske work on integrating 
> libgit to Pharo, and we will be able to solve some of the issues above ;)
> 
> Thierry
> 
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de François 
> Stephany [tulipe.mouta...@gmail.com]
> 
> Envoyé : samedi 26 avril 2014 19:06
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Fast way to load package form github
> 
> I'm a bit lost of what is currently possible to do with git in Pharo. Is 
> there a place where you describe your workflow in a multi-developer 
> environment?
> 
> We currently use git flow[1] for our iOS, Android and Rails apps. We would 
> love to use the same for Pharo. What we are doing now is using a filetree 
> repository under a src/ directory sitting next to the image. We use 
> versionner to save all our packages in the filetree tree and then we `git 
> commit/push`. 
> 
> It was working fine while I was alone but we are now two developers working 
> on this and I do not feel confident about this flow; merging filetree tree in 
> CLI doesn't sound like a good idea. probably not be practical. 
> 
> The second developer is working on this since yesterday so we haven't yet 
> decided how we gonna handle this.
> 
> I would love to hear from people working with git and Pharo.
> 
> 
> [1] http://nvie.com/posts/a-successful-git-branching-model/
> 
> 
> On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry  
> wrote:
> Yuri,
> 
> pure filetree will only allow you access to the latest version (HEAD) of the 
> repository (and will only match if you load that precise version number as 
> stored in the package metadata or if you don't specify a version number). You 
> have to change the commit ID (and branch) via git clone, git checkout and git 
> checkout -b before.
> 
> github:// urls may be able to select a specific commit ID, but I don't know 
> how. You can select the branch, however. Again, if you specify a version 
> number for your package with a github:// url, the metadata of your package 
> has to agree with you or it will refuse to load (you are able to see only the 
> latest version of the package).
> 
> gitfiletree:// urls allows you to select the branch and any version visible 
> in the git h

Re: [Pharo-dev] Fast way to load package form github

[Goubier Thierry]

Le 28/04/2014 10:42, François Stephany a écrit :

Sounds *really* good!

Do you have a time goal for this integration (even rough estimate)?
Sorry if this sound stupid but are we far from an integration with, say,
the "Changes" tool?


I think Max should answer that question, he is on it. Then either he 
will propose another solution to integrate git or I will port 
gitfiletree on his work, whichever comes first or is considered better 
from a technical point of view.


I think I will have a solution for the merge conflicts sometime by the 
end of the week, if I don't have too many disruptions...



If you need some help somewhere (money or manpower), I'm sure there are
quite a few people interesting in donating for this (Ta Mère is).


All the development is done in the open, so if you're ready to spend 
some manpower on it, then please do it :) I'm not into funding, unless 
you make it a collaborative research project :) but the Pharo 
association may be interested.


At the moment, I'd say the needs are:

- gitfiletree//: at most one man-week to add Microsoft Windows support.

- libgit integration: Max, this is yours to answer ;)

- git merge conflicts resolution: give me until the end of the week and 
I'll be able to say what is needed.


And a bit of dicussion on a git workflow for a small team.

Thierry


On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry mailto:thierry.goub...@cea.fr>> wrote:

Hi François,

with gitfiletree://, there isn't any real place describing a
multi-developper workflow because it is designed to work along
existing workflows... as much as possible.

In short, you work like you used to do in git, and gitfiletree
ensures that the commit are properly made, that you have access to
your development history (your true development history: the git
one), and that pushes and pulls are made as painless as possible.

After, you just manage your git the way you like it. Branches,
merging, one branch per developper, whatever: gitfiletree:// will
ensure that what you see inside Pharo is what you have done in git,
and that what you do in Pharo is properly committed to git.

Now, the bad thing: git merge conflicts :( When merging packages
under git, some files will regularly(allways :() conflict: the
version history of the package and the method properties. Whatever
way you resolve those conflicts, gitfiletree:// will cope because it
never reads them, but, still, having conflicts in git isn't cool.

We have a better integration coming, through Max Leske work on
integrating libgit to Pharo, and we will be able to solve some of
the issues above ;)

Thierry



*De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org
] de la part de François
Stephany [tulipe.mouta...@gmail.com ]

*Envoyé :* samedi 26 avril 2014 19:06
*À :* Pharo Development List
*Objet :* Re: [Pharo-dev] Fast way to load package form github

I'm a bit lost of what is currently possible to do with git in
Pharo. Is there a place where you describe your workflow in a
multi-developer environment?

We currently use git flow[1] for our iOS, Android and Rails apps. We
would love to use the same for Pharo. What we are doing now is using
a filetree repository under a src/ directory sitting next to the
image. We use versionner to save all our packages in the filetree
tree and then we `git commit/push`.

It was working fine while I was alone but we are now two developers
working on this and I do not feel confident about this flow; merging
filetree tree in CLI doesn't sound like a good idea. probably not be
practical.

The second developer is working on this since yesterday so we
haven't yet decided how we gonna handle this.

I would love to hear from people working with git and Pharo.


[1] http://nvie.com/posts/a-successful-git-branching-model/


On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry
mailto:thierry.goub...@cea.fr>> wrote:

Yuri,

pure filetree will only allow you access to the latest version
(HEAD) of the repository (and will only match if you load that
precise version number as stored in the package metadata or if
you don't specify a version number). You have to change the
commit ID (and branch) via git clone, git checkout and git
checkout -b before.

github:// urls may be able to select a specific commit ID, but I
don't know how. You can select the branch, however. Again, if
you specify a version number for your package with a github://
url, the metadata of your package has to agree with you or it
will refuse to load (you are able to see only the latest version
of the package).

gitfiletree:// u

Re: [Pharo-dev] Fast way to load package form github

[François Stephany]

Sounds *really* good!

Do you have a time goal for this integration (even rough estimate)?
Sorry if this sound stupid but are we far from an integration with, say,
the "Changes" tool?

If you need some help somewhere (money or manpower), I'm sure there are
quite a few people interesting in donating for this (Ta Mère is).

On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry wrote:

>  Hi François,
>
> with gitfiletree://, there isn't any real place describing a
> multi-developper workflow because it is designed to work along existing
> workflows... as much as possible.
>
> In short, you work like you used to do in git, and gitfiletree ensures
> that the commit are properly made, that you have access to your development
> history (your true development history: the git one), and that pushes and
> pulls are made as painless as possible.
>
> After, you just manage your git the way you like it. Branches, merging,
> one branch per developper, whatever: gitfiletree:// will ensure that what
> you see inside Pharo is what you have done in git, and that what you do in
> Pharo is properly committed to git.
>
> Now, the bad thing: git merge conflicts :( When merging packages under
> git, some files will regularly(allways :() conflict: the version history of
> the package and the method properties. Whatever way you resolve those
> conflicts, gitfiletree:// will cope because it never reads them, but,
> still, having conflicts in git isn't cool.
>
> We have a better integration coming, through Max Leske work on integrating
> libgit to Pharo, and we will be able to solve some of the issues above ;)
>
> Thierry
>
>
>  --
> *De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de
> François Stephany [tulipe.mouta...@gmail.com]
>
> *Envoyé :* samedi 26 avril 2014 19:06
> *À :* Pharo Development List
> *Objet :* Re: [Pharo-dev] Fast way to load package form github
>
> I'm a bit lost of what is currently possible to do with git in Pharo.
> Is there a place where you describe your workflow in a multi-developer
> environment?
>
>  We currently use git flow[1] for our iOS, Android and Rails apps. We
> would love to use the same for Pharo. What we are doing now is using a
> filetree repository under a src/ directory sitting next to the image. We
> use versionner to save all our packages in the filetree tree and then we
> `git commit/push`.
>
>  It was working fine while I was alone but we are now two developers
> working on this and I do not feel confident about this flow; merging
> filetree tree in CLI doesn't sound like a good idea. probably not be
> practical.
>
>  The second developer is working on this since yesterday so we haven't yet
> decided how we gonna handle this.
>
>  I would love to hear from people working with git and Pharo.
>
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
>
> On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry 
> wrote:
>
>> Yuri,
>>
>> pure filetree will only allow you access to the latest version (HEAD) of
>> the repository (and will only match if you load that precise version number
>> as stored in the package metadata or if you don't specify a version
>> number). You have to change the commit ID (and branch) via git clone, git
>> checkout and git checkout -b before.
>>
>> github:// urls may be able to select a specific commit ID, but I don't
>> know how. You can select the branch, however. Again, if you specify a
>> version number for your package with a github:// url, the metadata of your
>> package has to agree with you or it will refuse to load (you are able to
>> see only the latest version of the package).
>>
>> gitfiletree:// urls allows you to select the branch and any version
>> visible in the git history. Read-only gitfiletree:// urls reduce the git
>> history to one commit, so all versions are listed as .1. (Note that
>> gitfiletree:// urls with https are read-only).
>>
>> That said, if you found a way to refer a specific commit via github://,
>> I'd really like to know how :)
>>
>> Thierry
>> 
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy
>> Tymchuk [yuriy.tymc...@me.com]
>>  Envoyé : samedi 26 avril 2014 12:11
>>  À : Pharo Development List
>> Objet : Re: [Pharo-dev] Fast way to load package form github
>>
>> Do you know how to specify versions with pure filetree? I know that I can
>> specify commit SHA or branch in URL, but can I somehow redefine version for
>> a version definition?
>>
>> Uko
>>
>> On 26 Apr 2014, at 11:06, GOUBIER Thierry  wrote:
>>
>> > Yuri,
>> >
>> > I think the best would be a github:// url in a configuration.
>> >
>> > Shortest is something like:
>> >
>> > Gofer new
>> >  url: 'http://smalltalkhub.com/mc/Yuri/ProjectOfYuri/main/';
>> >  configurationOf: 'ProjectOfYuri';
>> >  loadStable
>> >
>> > (with the github:// url inside ConfigurationOfProjectOfYuri)
>> >
>> > Note that I have added back https access to github in gitfiletree, but,

Re: [Pharo-dev] Pharo Inbox now Public Writable

[stepharo]

Yes this is normal.



IIRC you still need to be logged in...





-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Pharo-Inbox-now-Public-Writable-tp4756131.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.