Re: [Pharo-dev] Access to Pharo/TxText

[stepharo]

Was the issue solved?

Stef

Le 14/1/15 04:30, Bernardo Ezequiel Contreras a écrit :

Hi,
 Could someone take a look at this

https://pharo.fogbugz.com/f/cases/14632/Access-to-Pharo-TxText

?
Thanks.

--
Bernardo E.C.

Sent from a cheap desktop computer in South America.

Re: [Pharo-dev] Access to Pharo/TxText

[stepharo]

I do not think Igor will look at them.


Why not?

because he told me that is burned out.
Not able to do anything. So I hope he will get cured and get more energy.
I'm going to talk with him to see how I can help him.

And who else did work on this?

"me" but a little little me.
Alain started to use TxText for Bloc but he is not expert.

Documenting is where we are not good.

Stef



I can try but I'm a newbie there.
so tag me.

Stef

Le 14/1/15 12:43, Marcus Denker a écrit :



On 14 Jan 2015, at 00:30, Bernardo Ezequiel Contreras
mailto:vonbecm...@gmail.com>> wrote:

Hi,
 Could someone take a look at this

https://pharo.fogbugz.com/f/cases/14632/Access-to-Pharo-TxText



In general we need to organise: Who
-  will review fixes for TxText that are on the issue tracker?
- commits them to the repo and give commit right to people?
- push and coordinate to have the latest in Pharo4?

Right now, all TxText contributions are ignored.

Marcus

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

[stepharo]

Marcus I like your new year resolution...
Saying no :)


Le 16/1/15 15:51, Marcus Denker a écrit :


On 16 Jan 2015, at 11:44, Ben Coman > wrote:


do you mean...?
https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayouts.pdf



No, Tims refers to the mails I send… describing the reflective reading 
and writing if Slots.


My probkem is that I could now dig that out and postpone other things. 
But I will not.
i will write a tutorial later, but not now. (I am already behind at 
least 3 things that people

are waiting for that have higher priority…)

Marcus

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[stepharo]

Marcus
would not it make sense to emit a bytecode marker (kind of no-op) so 
that the tools can get more information

about the encoded computation and get some abtsraction?

Stef

Le 16/1/15 18:22, Andrei Chis a écrit :



On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker > wrote:



> On 16 Jan 2015, at 12:12, Andrei Chis
mailto:chisvasileand...@gmail.com>>
wrote:
>
> For me it's ok like it is now.
>
>
> I updated the GTDebuggers to use slots.
> For example you can use the bytecode one to see what actually
gets executed (and even step into the code of the slot).
>
>  
>

Wow! And just like that, the byte code debugger is actually very
useful to see what happens for real with Slots…. very useful
especially when
you emit you own byte code for a Slot.

> Now the other problem is that because reading a slot uses
#send:read: the debugger will now stop at that instruction so one
has to do an explicit step over to read the actual slot.
> The logic that performs this check is now isolated in
#stepToFirstInterestingBytecodeIn: so we could updated it to take
slots into account.
>

Yes, that would be nice.


I made an issue: 
https://pharo.fogbugz.com/f/cases/14743/The-debugger-should-skip-the-reading-of-slots


Now there is still the issue of stepping into a slot write, when 
stepping into instructions.
One solution could be to have a setting that makes the debugger slot 
sensitive (stepping into enters both slot reads and slot writes).

However, with the bytecode debugger one can easily step into slots.


Cheers,
Andrei



Marcus

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[stepharo]

Hi andrei

once it will be fully working I think that we will need a way to 
activate it or not.
Because for most people Slots will be transparent. But your work is 
great for slot designers.

Keep pushing.

Stef

Le 16/1/15 16:12, Andrei Chis a écrit :

For me it's ok like it is now.


I updated the GTDebuggers to use slots.
For example you can use the bytecode one to see what actually gets 
executed (and even step into the code of the slot).


Inline image 1

Now the other problem is that because reading a slot uses #send:read: 
the debugger will now stop at that instruction so one has to do an 
explicit step over to read the actual slot.
The logic that performs this check is now isolated in 
#stepToFirstInterestingBytecodeIn: so we could updated it to take 
slots into account.



Cheers,
Andrei



On Fri, Jan 16, 2015 at 3:41 PM, Marcus Denker > wrote:



> On 16 Jan 2015, at 11:28, Andrei Chis
mailto:chisvasileand...@gmail.com>>
wrote:
>
> Hi Marcus,
>
> So now ' self class allSlots ' should be used also in the
debugger to get the instance variables of an object?
>

Yes, at least for now… I am not yet that happy with the naming… it
is hard to get consistent *and* be resably compatible….

So the idea is that the old API for (instVarAt:, instVarNames…)
continues to work *but* this shows (and manipulates)
what is really there. VM level instance variables.

Slots are first class instance variables that
 a) might redefine what happens of read/write
—> all reflective read and write needs to
go through the slots.
 b) they often correspond 1:1 to a low level ivar, but
they don’t have to (e.g. the TestSlot in the example has no
underlying ivar)
—> we need to ask for all Slots, not just
all instVarNames.

For the naming… in some way Slots are just “First Class Instance
Variables” that map to VM level Fields.
Sometimes I feel it would be nice to use just these two for
naming: Fields (VM Level) and Instance Variables (Image level, aka
Slots).

But then, there is backward compatibility to be taken into
account… we can’t really change instVarAt:… but we could of course
keep
those for legacy and use the “long form” for the “reified”
instance variables: instanceVariableNamed:,
#instanceVariableNames, and so on…

To make it really consistent and just use “Field and Ivar", there
would be a lot to be changed: names of byte codes, for example.
So maybe having it like it is now is good? “Field and Ivar” are
one concept, while the high-level one is “Slot”.

I am not sure myself… I have to admit.

Marcus

Re: [Pharo-dev] [Pharo4] 450: Spotter version 1.0.7 and GTools version 2.0.9

[stepharo]

And some of us are on hold :)
So imagine soon
Stef

Le 17/1/15 00:24, Sven Van Caekenberghe a écrit :

Super, things are moving so fast ...


On 16 Jan 2015, at 22:18, Marcus Denker  wrote:

Hi,

#450 is online with Spotter version 1.0.7 and GTools version 2.0.9 containing:

14636: spotter: remap cmd+enter to shift+enter
14641: spot on global vars
14741: GTInspector: add simple slot support
14252: Make collections browsable again in the tools
14722: Disable FreeType gives MNU and RMOD in GTools
14711: The Playground print popper should allow for inserting the text in the 
editor
14587: deleting the whole text in the inspector pane throws SubscriptOutOfBounds
14515: Damaged configurations in the image

Marcus

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[stepharo]

Hi guys,

Why I found this kind of discussion distracting is
- 500 people * 10 seconds * 30 mails =  too much
- I do not want to lose time reading it
- I do not want to feel the need to say some points when I stupid 
gross estimation or statements.

- I want to get focus on getting impact right now on Pharo.

So I think that I will start to ban some discussions from this 
mailing-lists.

If auto regulation does not work, active policy will get a result.

Stef

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[stepharo]

Tx

Le 17/1/15 01:11, horrido a écrit :

I'm moving all discussions related to the Smalltalk Renaissance Program to
the *Pharo Smalltalk Users* forum where I think it more properly belongs.

My original reasoning for choosing the *Pharo Smalltalk Developers* forum
was because I wanted to reach out to /the developer community who are a
vital part of the campaign/. But I suppose this forum should be reserved
strictly for Pharo-specific development issues.

The Pharo Smalltalk Users forum sounds more general in nature. That's where
we should be talking about Smalltalk and the PR campaign.


Marcus Denker-4 wrote

I think we *really* need a smalltalk-talk mailing list…


On 16 Jan 2015, at 05:44, kilon alios <

kilon.alios@
> wrote:


"I would like to remind people that the aim of the Pharo project is more
ambitious than the Smalltalk one"

I would like to hear this grand plan of Pharo, where is it ? Where is the
official roadmap ? What are the goals that the core development team
agree on ? Why are such a secret and I have never seen them discussed
here or anywhere on the internet.

I would not call Pharo odd, Pharo is diffirent but not that diffirent. It
offers me a way to code that I prefer over python , but I would not call
my experience coding with pharo radically different compared to python
coding. Smalltalk used to be the Purple Cow no doubt when it first came
out , so many new concepts and ideas that were far apart from anything
remotely similar. But nowdays the smalltalk paradigm has been embraced in
several fronts , languages and IDEs are moving closer and closer.

It took python 24 years to get as popular as it is nowdays, the most
popular languages have a similar lifespan if not more in some cases. Its
a really long process and its full of compromises and ugly truths.

I also dont like the fact that Pharo calls itself "Smalltalk inspired"
its an insult to people who put an effort into Smalltalk by spending
hours making code. You cannot be "Smalltalk inspired" by forking code ,
your at best "Smalltalk based" and that makes you Smalltalk. Ruby can
call itself "Smalltalk inspired" , Pharo cannot. This shows to me a very
flawed mentality inside the heads of those Pharoers that believe this,
its shows me fear , its shows me embarrassment, it shows me weakness.

I would prefer it if Pharo was advertising itself as a modern Smalltalk
implementation as a project that lives true to the Smalltalk philosophy
and moves forward. Instead here we are calling Smalltalk "less ambitious"
, why ?   Innovativing more than any other language have done so , is not
ambitious enough for you ?

I do believe in Pharo If I did not I would not contribute but I would
prefer it without all the hype. Innovate all you want , code whatever
makes you happy, live your dream but also respect the dreams of others,
especially when you base your success on their success. And yes I will
dare say it , Smalltalk has been extremely succesful in many fronts , far
more than Pharo currently is.

PS: Just a clarification because people love to put words on other people
mouths, I never said that languages like Clojure and Scheme has been
miserable failures generally, but based on the hype of how popular they
will become. Both Clojure and Sceme are great language with continuously
expanding communities . I was merely wanted to point out how hype does
not help and there was tons of hype when Java allowed for the creation of
those languages. Jython for example is one of the oldest Java languages
(2001), and there was tons of hype when the project started that Jython
could become at worst an equal to Cpython on terms of popularity and even
more popular than Java at best.  Sun even funded the development of
Jython back in 2008.

I admire what the creator of Redline done as I admire the effort that has
been invested on both Pharo and Squeak. Its really hard to make a
competitive product in a world so complex and so demanding as the one we
live now. I do believe in Pharo and I hope the best for it but even Pharo
never makes it to the top 20 most popular languages even in 30 years I
wont lose my sleep over it. I love Pharo for what it is, and not what it
may become.







--
View this message in context: 
http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4800113.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[stepharo]

Yes call it Pharo-Talk :)

Le 16/1/15 10:58, Marcus Denker a écrit :

I think we *really* need a smalltalk-talk mailing list…

On 16 Jan 2015, at 05:44, kilon alios > wrote:



"I would like to remind people that the aim of the Pharo project is 
more ambitious than the Smalltalk one"


I would like to hear this grand plan of Pharo, where is it ? Where is 
the official roadmap ? What are the goals that the core development 
team agree on ? Why are such a secret and I have never seen them 
discussed here or anywhere on the internet.


I would not call Pharo odd, Pharo is diffirent but not that 
diffirent. It offers me a way to code that I prefer over python , but 
I would not call my experience coding with pharo 
radically different compared to python coding. Smalltalk used to be 
the Purple Cow no doubt when it first came out , so many new concepts 
and ideas that were far apart from anything remotely similar. But 
nowdays the smalltalk paradigm has been embraced in several fronts , 
languages and IDEs are moving closer and closer.


It took python 24 years to get as popular as it is nowdays, the most 
popular languages have a similar lifespan if not more in some cases. 
Its a really long process and its full of compromises and ugly truths.


I also dont like the fact that Pharo calls itself "Smalltalk 
inspired" its an insult to people who put an effort into Smalltalk by 
spending hours making code. You cannot be "Smalltalk inspired" by 
forking code , your at best "Smalltalk based" and that makes you 
Smalltalk. Ruby can call itself "Smalltalk inspired" , Pharo cannot. 
This shows to me a very flawed mentality inside the heads of those 
Pharoers that believe this, its shows me fear , its shows me 
embarrassment, it shows me weakness.


I would prefer it if Pharo was advertising itself as a modern 
Smalltalk implementation as a project that lives true to the 
Smalltalk philosophy and moves forward. Instead here we are calling 
Smalltalk "less ambitious" , why ? Innovativing more than any other 
language have done so , is not ambitious enough for you ?


I do believe in Pharo If I did not I would not contribute but I would 
prefer it without all the hype. Innovate all you want , code whatever 
makes you happy, live your dream but also respect the dreams of 
others, especially when you base your success on their success. And 
yes I will dare say it , Smalltalk has been extremely succesful in 
many fronts , far more than Pharo currently is.


PS: Just a clarification because people love to put words on other 
people mouths, I never said that languages like Clojure and Scheme 
has been miserable failures generally, but based on the hype of how 
popular they will become. Both Clojure and Sceme are great language 
with continuously expanding communities . I was merely wanted to 
point out how hype does not help and there was tons of hype when Java 
allowed for the creation of those languages. Jython for example is 
one of the oldest Java languages  (2001), and there was tons of hype 
when the project started that Jython could become at worst an equal 
to Cpython on terms of popularity and even more popular than Java at 
best.  Sun even funded the development of Jython back in 2008.


I admire what the creator of Redline done as I admire the effort that 
has been invested on both Pharo and Squeak. Its really hard to make a 
competitive product in a world so complex and so demanding as the one 
we live now. I do believe in Pharo and I hope the best for it but 
even Pharo never makes it to the top 20 most popular languages even 
in 30 years I wont lose my sleep over it. I love Pharo for what it 
is, and not what it may become.

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[stepharo]

There is an old vision paper and we will revisit it.

Stef

Le 16/1/15 09:44, kilon alios a écrit :


"I would like to remind people that the aim of the Pharo project is 
more ambitious than the Smalltalk one"


I would like to hear this grand plan of Pharo, where is it ? Where is 
the official roadmap ? What are the goals that the core development 
team agree on ? Why are such a secret and I have never seen them 
discussed here or anywhere on the internet.


I would not call Pharo odd, Pharo is diffirent but not that diffirent. 
It offers me a way to code that I prefer over python , but I would not 
call my experience coding with pharo radically different compared to 
python coding. Smalltalk used to be the Purple Cow no doubt when it 
first came out , so many new concepts and ideas that were far apart 
from anything remotely similar. But nowdays the smalltalk paradigm has 
been embraced in several fronts , languages and IDEs are moving closer 
and closer.


It took python 24 years to get as popular as it is nowdays, the most 
popular languages have a similar lifespan if not more in some cases. 
Its a really long process and its full of compromises and ugly truths.


I also dont like the fact that Pharo calls itself "Smalltalk inspired" 
its an insult to people who put an effort into Smalltalk by spending 
hours making code. You cannot be "Smalltalk inspired" by forking code 
, your at best "Smalltalk based" and that makes you Smalltalk. Ruby 
can call itself "Smalltalk inspired" , Pharo cannot. This shows to me 
a very flawed mentality inside the heads of those Pharoers that 
believe this, its shows me fear , its shows me embarrassment, it shows 
me weakness.


I would prefer it if Pharo was advertising itself as a modern 
Smalltalk implementation as a project that lives true to the Smalltalk 
philosophy and moves forward. Instead here we are calling Smalltalk 
"less ambitious" , why ?   Innovativing more than any other language 
have done so , is not ambitious enough for you ?


I do believe in Pharo If I did not I would not contribute but I would 
prefer it without all the hype. Innovate all you want , code whatever 
makes you happy, live your dream but also respect the dreams of 
others, especially when you base your success on their success. And 
yes I will dare say it , Smalltalk has been extremely succesful in 
many fronts , far more than Pharo currently is.


PS: Just a clarification because people love to put words on other 
people mouths, I never said that languages like Clojure and Scheme has 
been miserable failures generally, but based on the hype of how 
popular they will become. Both Clojure and Sceme are great language 
with continuously expanding communities . I was merely wanted to point 
out how hype does not help and there was tons of hype when Java 
allowed for the creation of those languages. Jython for example is one 
of the oldest Java languages  (2001), and there was tons of hype when 
the project started that Jython could become at worst an equal to 
Cpython on terms of popularity and even more popular than Java at 
best.  Sun even funded the development of Jython back in 2008.


I admire what the creator of Redline done as I admire the effort that 
has been invested on both Pharo and Squeak. Its really hard to make a 
competitive product in a world so complex and so demanding as the one 
we live now. I do believe in Pharo and I hope the best for it but even 
Pharo never makes it to the top 20 most popular languages even in 30 
years I wont lose my sleep over it. I love Pharo for what it is, and 
not what it may become.

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[stepharo]

+ 1

and you all can get an impact!


Le 16/1/15 07:26, Tudor Girba a écrit :
It is always tempting to go where others are. Yet, once we get there 
you might notice that many other people are there as well, and all of 
a sudden we are less remarkable and we get less attention than we 
hoped for.


In the meantime, I will continue working with people to make Pharo the 
thing that others will envy. I do want Pharo to be the odd one out, 
the Purple Cow. It is exactly by doing something radically different 
that we have a chance of reinventing software engineering.


Some might think that it is not possible. That we are too small. That 
we have no funding. That ... there are many reasons to be found for 
giving up and doing what others are doing. But, I think we are closer 
to reaching the Purple Cow than we think. We are on an ascending trend 
and the most important features are not yet out. We still have a hard 
road ahead of us, but I believe we are approaching a very interesting 
period in the Pharo history.


I would like to remind people that the aim of the Pharo project is 
more ambitious than the Smalltalk one. Please rally and focus on the 
larger goal. Together, we will get there.


Doru

On Fri, Jan 16, 2015 at 5:15 AM, horrido > wrote:


I believe in Redline. I think it's a very important project,
strategically.
On Twitter and elsewhere, I am urging contributors to join
Redline. It would
be something of a tragedy if Redline failed to reach version 1.0.
*We need
Smalltalk on the JVM.*


jamesl wrote
> Hi Smalltalkers,
>
> Redline Smalltalk is not dead although it looks like it.
> I recently made the grammar much cleaner and moved to using
Antlr4 as well
> as cleaning up the
> internals. Yes - what is in the core project in github is
dormant and I
> have spun off 'stc' to contain
> the the work Im doing until an appropriate time to merge back
into that
> main.
>
> I'd love some help but right now you would be limited to copying
across
> the runtime library and writing
> tests around it as I concentrate on the bytecode generation and
underlying
> code - which is hard to have too many people helping with.
>
> I'm *very* busy in my life right now with a startup
(http://mywave.me) and
> personal life but I really
> am trying to find the time to push this along.
>
> I've set myself some fitness, work and Smalltalk goals for this
year and
> all going well Redline will be
> out in September. BUT - Please don't hate me.
>
> This is the Year of Smalltalk and we can change the world - one
JVM at a
> time ;)
>
> - James.
> Redline Smalltalk





--
View this message in context:
http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4799830.html
Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.




--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[stepharo]

+1

Stef


I wonder if it would make sense to add a "Smalltalk-talk" mailing list...
I am sure ESUG could host that.

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[Ben Coman]

thanks Richard.

On Sat, Jan 17, 2015 at 8:11 AM, horrido  wrote:

> I'm moving all discussions related to the Smalltalk Renaissance Program to
> the *Pharo Smalltalk Users* forum where I think it more properly belongs.
>
> My original reasoning for choosing the *Pharo Smalltalk Developers* forum
> was because I wanted to reach out to /the developer community who are a
> vital part of the campaign/. But I suppose this forum should be reserved
> strictly for Pharo-specific development issues.
>
> The Pharo Smalltalk Users forum sounds more general in nature. That's where
> we should be talking about Smalltalk and the PR campaign.
>
>
> Marcus Denker-4 wrote
> > I think we *really* need a smalltalk-talk mailing list…
> >
> >> On 16 Jan 2015, at 05:44, kilon alios <
>
> > kilon.alios@
>
> > > wrote:
> >>
> >>
> >> "I would like to remind people that the aim of the Pharo project is more
> >> ambitious than the Smalltalk one"
> >>
> >> I would like to hear this grand plan of Pharo, where is it ? Where is
> the
> >> official roadmap ? What are the goals that the core development team
> >> agree on ? Why are such a secret and I have never seen them discussed
> >> here or anywhere on the internet.
> >>
> >> I would not call Pharo odd, Pharo is diffirent but not that diffirent.
> It
> >> offers me a way to code that I prefer over python , but I would not call
> >> my experience coding with pharo radically different compared to python
> >> coding. Smalltalk used to be the Purple Cow no doubt when it first came
> >> out , so many new concepts and ideas that were far apart from anything
> >> remotely similar. But nowdays the smalltalk paradigm has been embraced
> in
> >> several fronts , languages and IDEs are moving closer and closer.
> >>
> >> It took python 24 years to get as popular as it is nowdays, the most
> >> popular languages have a similar lifespan if not more in some cases. Its
> >> a really long process and its full of compromises and ugly truths.
> >>
> >> I also dont like the fact that Pharo calls itself "Smalltalk inspired"
> >> its an insult to people who put an effort into Smalltalk by spending
> >> hours making code. You cannot be "Smalltalk inspired" by forking code ,
> >> your at best "Smalltalk based" and that makes you Smalltalk. Ruby can
> >> call itself "Smalltalk inspired" , Pharo cannot. This shows to me a very
> >> flawed mentality inside the heads of those Pharoers that believe this,
> >> its shows me fear , its shows me embarrassment, it shows me weakness.
> >>
> >> I would prefer it if Pharo was advertising itself as a modern Smalltalk
> >> implementation as a project that lives true to the Smalltalk philosophy
> >> and moves forward. Instead here we are calling Smalltalk "less
> ambitious"
> >> , why ?   Innovativing more than any other language have done so , is
> not
> >> ambitious enough for you ?
> >>
> >> I do believe in Pharo If I did not I would not contribute but I would
> >> prefer it without all the hype. Innovate all you want , code whatever
> >> makes you happy, live your dream but also respect the dreams of others,
> >> especially when you base your success on their success. And yes I will
> >> dare say it , Smalltalk has been extremely succesful in many fronts ,
> far
> >> more than Pharo currently is.
> >>
> >> PS: Just a clarification because people love to put words on other
> people
> >> mouths, I never said that languages like Clojure and Scheme has been
> >> miserable failures generally, but based on the hype of how popular they
> >> will become. Both Clojure and Sceme are great language with continuously
> >> expanding communities . I was merely wanted to point out how hype does
> >> not help and there was tons of hype when Java allowed for the creation
> of
> >> those languages. Jython for example is one of the oldest Java languages
> >> (2001), and there was tons of hype when the project started that Jython
> >> could become at worst an equal to Cpython on terms of popularity and
> even
> >> more popular than Java at best.  Sun even funded the development of
> >> Jython back in 2008.
> >>
> >> I admire what the creator of Redline done as I admire the effort that
> has
> >> been invested on both Pharo and Squeak. Its really hard to make a
> >> competitive product in a world so complex and so demanding as the one we
> >> live now. I do believe in Pharo and I hope the best for it but even
> Pharo
> >> never makes it to the top 20 most popular languages even in 30 years I
> >> wont lose my sleep over it. I love Pharo for what it is, and not what it
> >> may become.
> >>
> >>
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4800113.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[horrido]

I'm moving all discussions related to the Smalltalk Renaissance Program to
the *Pharo Smalltalk Users* forum where I think it more properly belongs.

My original reasoning for choosing the *Pharo Smalltalk Developers* forum
was because I wanted to reach out to /the developer community who are a
vital part of the campaign/. But I suppose this forum should be reserved
strictly for Pharo-specific development issues.

The Pharo Smalltalk Users forum sounds more general in nature. That's where
we should be talking about Smalltalk and the PR campaign.


Marcus Denker-4 wrote
> I think we *really* need a smalltalk-talk mailing list…
> 
>> On 16 Jan 2015, at 05:44, kilon alios <

> kilon.alios@

> > wrote:
>> 
>> 
>> "I would like to remind people that the aim of the Pharo project is more
>> ambitious than the Smalltalk one"
>> 
>> I would like to hear this grand plan of Pharo, where is it ? Where is the
>> official roadmap ? What are the goals that the core development team
>> agree on ? Why are such a secret and I have never seen them discussed
>> here or anywhere on the internet.
>> 
>> I would not call Pharo odd, Pharo is diffirent but not that diffirent. It
>> offers me a way to code that I prefer over python , but I would not call
>> my experience coding with pharo radically different compared to python
>> coding. Smalltalk used to be the Purple Cow no doubt when it first came
>> out , so many new concepts and ideas that were far apart from anything
>> remotely similar. But nowdays the smalltalk paradigm has been embraced in
>> several fronts , languages and IDEs are moving closer and closer. 
>> 
>> It took python 24 years to get as popular as it is nowdays, the most
>> popular languages have a similar lifespan if not more in some cases. Its
>> a really long process and its full of compromises and ugly truths. 
>> 
>> I also dont like the fact that Pharo calls itself "Smalltalk inspired"
>> its an insult to people who put an effort into Smalltalk by spending
>> hours making code. You cannot be "Smalltalk inspired" by forking code ,
>> your at best "Smalltalk based" and that makes you Smalltalk. Ruby can
>> call itself "Smalltalk inspired" , Pharo cannot. This shows to me a very
>> flawed mentality inside the heads of those Pharoers that believe this,
>> its shows me fear , its shows me embarrassment, it shows me weakness. 
>> 
>> I would prefer it if Pharo was advertising itself as a modern Smalltalk
>> implementation as a project that lives true to the Smalltalk philosophy
>> and moves forward. Instead here we are calling Smalltalk "less ambitious"
>> , why ?   Innovativing more than any other language have done so , is not
>> ambitious enough for you ? 
>> 
>> I do believe in Pharo If I did not I would not contribute but I would
>> prefer it without all the hype. Innovate all you want , code whatever
>> makes you happy, live your dream but also respect the dreams of others,
>> especially when you base your success on their success. And yes I will
>> dare say it , Smalltalk has been extremely succesful in many fronts , far
>> more than Pharo currently is.  
>> 
>> PS: Just a clarification because people love to put words on other people
>> mouths, I never said that languages like Clojure and Scheme has been
>> miserable failures generally, but based on the hype of how popular they
>> will become. Both Clojure and Sceme are great language with continuously
>> expanding communities . I was merely wanted to point out how hype does
>> not help and there was tons of hype when Java allowed for the creation of
>> those languages. Jython for example is one of the oldest Java languages 
>> (2001), and there was tons of hype when the project started that Jython
>> could become at worst an equal to Cpython on terms of popularity and even
>> more popular than Java at best.  Sun even funded the development of
>> Jython back in 2008. 
>> 
>> I admire what the creator of Redline done as I admire the effort that has
>> been invested on both Pharo and Squeak. Its really hard to make a
>> competitive product in a world so complex and so demanding as the one we
>> live now. I do believe in Pharo and I hope the best for it but even Pharo
>> never makes it to the top 20 most popular languages even in 30 years I
>> wont lose my sleep over it. I love Pharo for what it is, and not what it
>> may become.  
>> 
>>





--
View this message in context: 
http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4800113.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Pharo4] 450: Spotter version 1.0.7 and GTools version 2.0.9

[Sven Van Caekenberghe]

Super, things are moving so fast ...

> On 16 Jan 2015, at 22:18, Marcus Denker  wrote:
> 
> Hi,
> 
> #450 is online with Spotter version 1.0.7 and GTools version 2.0.9 containing:
> 
> 14636: spotter: remap cmd+enter to shift+enter
> 14641: spot on global vars
> 14741: GTInspector: add simple slot support
> 14252: Make collections browsable again in the tools
> 14722: Disable FreeType gives MNU and RMOD in GTools
> 14711: The Playground print popper should allow for inserting the text in the 
> editor
> 14587: deleting the whole text in the inspector pane throws 
> SubscriptOutOfBounds
> 14515: Damaged configurations in the image
> 
>   Marcus

Re: [Pharo-dev] Fixing DNU binding in GT and Nautilus

[kilon alios]

Thank you Stef

On Fri, Jan 16, 2015 at 11:57 PM, stepharo  wrote:

>  DoesNotUnderstand
> Le 15/1/15 19:37, kilon alios a écrit :
>
> what DNU means ? is it the same as MNU ?
>
> On Thu, Jan 15, 2015 at 6:07 PM, Andrei Chis 
> wrote:
>
>> Should be Alain's repo:
>> http://smalltalkhub.com/mc/AlainPlantec/Rubric/main/
>> If you do not have access I can commit the change for you.
>>
>> On Thu, Jan 15, 2015 at 5:03 PM, Nicolai Hess  wrote:
>>
>>> The fix is in 4.0 446 but only for SmalltalkEditor. Where should we put
>>> the fix for RubSmalltalkEditor?
>>>
>>> 2015-01-14 22:49 GMT+01:00 stepharo :
>>>
  Thanks marcus

 I just open another one :( because I houtgh that my mail did go
 through. I will close it.

 Le 14/1/15 13:02, Marcus Denker a écrit :

 I have opened an issue for this:


 https://pharo.fogbugz.com/f/cases/14731/Fixing-DNU-binding-in-GT-and-Nautilus


  On 13 Jan 2015, at 20:11, stepharo  wrote:

 Hi

 in nautilus method pane and GT, when I select a global variable such as

 SystemOrganization and press command B + N

 I get DNU binding.
 Apparently this DNU only happen when the name does not match any class
 substring
 Transcript or Undeclared will not raise an error because we have
 classes having name matching the expression.

 Fixed included.

 PS: I'm dead after 1h30 train delay (after giving 6 hours lecture)
 today. So this mail will be sent whenever I get connected.

 Stef
 




>>>
>>
>
>

Re: [Pharo-dev] Fixing DNU binding in GT and Nautilus

[stepharo]

DoesNotUnderstand
Le 15/1/15 19:37, kilon alios a écrit :

what DNU means ? is it the same as MNU ?

On Thu, Jan 15, 2015 at 6:07 PM, Andrei Chis 
mailto:chisvasileand...@gmail.com>> wrote:


Should be Alain's repo:
http://smalltalkhub.com/mc/AlainPlantec/Rubric/main/
If you do not have access I can commit the change for you.

On Thu, Jan 15, 2015 at 5:03 PM, Nicolai Hess mailto:nicolaih...@web.de>> wrote:

The fix is in 4.0 446 but only for SmalltalkEditor. Where
should we put the fix for RubSmalltalkEditor?

2015-01-14 22:49 GMT+01:00 stepharo mailto:steph...@free.fr>>:

Thanks marcus

I just open another one :( because I houtgh that my mail
did go through. I will close it.

Le 14/1/15 13:02, Marcus Denker a écrit :

I have opened an issue for this:


https://pharo.fogbugz.com/f/cases/14731/Fixing-DNU-binding-in-GT-and-Nautilus



On 13 Jan 2015, at 20:11, stepharo mailto:steph...@free.fr>> wrote:

Hi

in nautilus method pane and GT, when I select a global
variable such as

SystemOrganization and press command B + N

I get DNU binding.
Apparently this DNU only happen when the name does not
match any class substring
Transcript or Undeclared will not raise an error because
we have classes having name matching the expression.

Fixed included.

PS: I'm dead after 1h30 train delay (after giving 6
hours lecture) today. So this mail will be sent whenever
I get connected.

Stef

Re: [Pharo-dev] GTInspector and TxWorkspace does not work well in Spur images

[stepharo]

Le 15/1/15 15:47, Clément Bera a écrit :

Ok thanks :-). You're quick for sure :-).

Now who maintains TxWorkspace ?

huhum...


me



2015-01-15 15:21 GMT+01:00 Tudor Girba >:


Thanks for noting this.

Could you open explicit issues for that?

#withSmalltalkSearch is definitely just a convenience that was
implemented before Opal so we can just change it without any
problems. Just to show how responsive we are, both me and Andrei
independently committed a fix for this 1 minute ago :).

Cheers,
Doru



On Thu, Jan 15, 2015 at 3:15 PM, Clément Bera
mailto:bera.clem...@gmail.com>> wrote:

Right now there is support for Opal but not for the old
Compiler in Spur images. GTInspector and TxWorkspace does
direct references to the old compiler in Pharo-40445, for
example, in GLMListingPresentation>>#withSmalltalkSearch.

This is a pain because I am using spur images for my
developments and I can't use some features of GTInspector.

In addition, the old Compiler will be removed by default from
the image in the next 6 months, so these features will not
work in non spur images soon.

Compiler references can be replaced, for example, by "self
class compiler" or "Smalltalk compiler" depending on which
compiler you want (one specific to the class with the specific
class settings or a generic one).






-- 
www.tudorgirba.com 


"Every thing has its own flow"

Re: [Pharo-dev] GTInspector and TxWorkspace does not work well in Spur images

[stepharo]

I will change it.

Le 15/1/15 15:15, Clément Bera a écrit :
Right now there is support for Opal but not for the old Compiler in 
Spur images. GTInspector and TxWorkspace does direct references to the 
old compiler in Pharo-40445, for example, 
in GLMListingPresentation>>#withSmalltalkSearch.


This is a pain because I am using spur images for my developments and 
I can't use some features of GTInspector.


In addition, the old Compiler will be removed by default from the 
image in the next 6 months, so these features will not work in non 
spur images soon.


Compiler references can be replaced, for example, by "self class 
compiler" or "Smalltalk compiler" depending on which compiler you want 
(one specific to the class with the specific class settings or a 
generic one).

[Pharo-dev] [Pharo4] 450: Spotter version 1.0.7 and GTools version 2.0.9

[Marcus Denker]

Hi,

#450 is online with Spotter version 1.0.7 and GTools version 2.0.9 containing:

14636: spotter: remap cmd+enter to shift+enter
14641: spot on global vars
14741: GTInspector: add simple slot support
14252: Make collections browsable again in the tools
14722: Disable FreeType gives MNU and RMOD in GTools
14711: The Playground print popper should allow for inserting the text in the 
editor
14587: deleting the whole text in the inspector pane throws SubscriptOutOfBounds
14515: Damaged configurations in the image

Marcus

[Pharo-dev] [pharo-project/pharo-core] 28434c: 40449

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 28434c8f56c2caae222befb157bbbab48d496dc1
  
https://github.com/pharo-project/pharo-core/commit/28434c8f56c2caae222befb157bbbab48d496dc1
  Author: Jenkins Build Server 
  Date:   2015-01-16 (Fri, 16 Jan 2015)

  Changed paths:
M 
Polymorph-Widgets.package/Pharo3Theme.class/class/settings/newDefaultSettings.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script449.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40449.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Slot.package/ClassVariable.class/instance/converting/asClassVariable.st
M Slot.package/SlotClassBuilder.class/instance/accessing/sharedVariables_.st
A Slot.package/extension/ByteString/instance/asClassVariable.st
A Slot.package/extension/Symbol/instance/asClassVariable.st

  Log Message:
  ---
  40449
14742 Fix: Allow defining simple ClassVariales using symbols
https://pharo.fogbugz.com/f/cases/14742

14712 The print-popper should have a different color than the selection in the 
default Pharo theme
https://pharo.fogbugz.com/f/cases/14712

14515 Damaged configurations in the image
https://pharo.fogbugz.com/f/cases/14515

http://files.pharo.org/image/40/40449.zip

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

[GitHub]

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

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

[Alexandre Bergel]

> def t(n):
>s = time.time()
>for x in range(0,1):
>l = []
>for i in range(1,10001):
>l.append(i)
>e = time.time()
>print(e-s, len(l))
>return l
> 
[…]
> So Pharo at 1.6 seconds (Array time) is respectable compared to Julia's 
> highly optimized preallocated arrays and thoroughly keeps Python in its place.

You have a super machine. Look at these figures:

Consider the Pharo version of your code:
[0 to: 1 do: [ :x |
l := OrderedCollection new.
1 to: 10001 do: [ :i | l add: i ].
]] timeToRun

My macbook air returns 0:00:00:04.234 seconds. We can improve it by 
preallocating the internal array with the following:

[0 to: 1 do: [ :x |
l := OrderedCollection new: 10001.
1 to: 10001 do: [ :i | l add: i ].
]] timeToRun
returns 0:00:00:03.959

We can avoid all the additional check to the ordered collection.
Getting rid of the ordered collection, and using an array gives me:

[0 to: 1 do: [ :x |
l := Array new: 10001.
1 to: 10001 do: [ :i | l at: i put: i ].
]] timeToRun

returns 0:00:00:02.45

Nearly a factor x 2, but that is the easy part. 
Let’s __really__ speed this thing up by writing the code "1 to: 10001 do: [ :i 
| l at: i put: i ].” in C.

Create the file /tmp/testarray.c  with the following code:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#include 
int fillArray(int *array, int size) {
  int s = 0;
  int i;
  for(i = 0; i < size; i ++ ) {
array[i] = i;
  }
  return 0;
}

int main() {
  int i, sum = 0;
  int table[5];
  
  fillArray(table, 5);
  
  for(i = 0; i < 5; i ++ )
sum += table[i];

  printf("The sum is %d\n", sum);

  return 0;
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The important thing is the function fillArray. The main is there just to try 
out.
Compile this file with:
 gcc -c -m32  testarray.c
and then create a dynamic library:
gcc -shared -m32 -o testarray.dylib testarray.o

So, you should have the file testarray.dylib  in your /tmp. Here is what I have 
on my machine:
/tmp> ls -l testarray.dylib 
-rwxr-xr-x  1 alexandrebergel  wheel  8588 Jan 16 17:02 testarray.dylib

This library is accessible from Pharo using NativeBoost. 

Create a class called A and add these two methods:
A>>fillArray: array
^ self fillArray: array asWordArray size: array size 

A>>fillArray: array size: size
  
^ self
nbCall: #( int fillArray( int* array, int size ) )
module: '/tmp/testarray.dylib'

You can make sure you have the same effect in Pharo than in C with the 
equivalent of the main function:
l := WordArray new: 5.
A new fillArray: l.
l sum
=> 10


Ok, so now we are ready to re-write our code:

[0 to: 1 do: [ :x |
l := WordArray new: 10001.
A new fillArray: l.
]] timeToRun

=> 0:00:00:00.463

We have gained a x 10 factor. 

Cheers,
Alexandre

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

Re: [Pharo-dev] Object>>logCr ?

[Richard Sargent]

abergel wrote
> ...
> why printString is used and not asString?
> ...

As stepharo pointed out, #asString is a conversion method. It is often
misused and misrepresented (see especially Java's toString() method).

It is important to clearly distinguish purpose, so we often see
#printString, #displayString, #storeString, as well as #asString.

With #asString, one could envision saying "1 asString asNumber" and
recreating the original object. That is what we expect from conversion
methods (oversimplified, but I think you get the point).

Most objects cannot do that.

 #printString is meant to portray the object in sufficient detail that one
can recognize it, but not necessarily recreate it. (typically of use to a
programmer, but not necessarily only to programmers)

 #displayString is meant to provide a suitable representation of an object
for a user of the system. (typically an application user more so than a
programmer, but really for anybody).

 And #storeString is meant to provide a representation that would allow
creation of an equivalent object when evaluated.


Back to your original question. One could override Object's implementation
of #logCr in String to do as you would like (it seems reasonable enough,
although you would probably want to ensure Symbol works differently from
String). Alternatively, one could (and perhaps should) define a #logString
with the default implementation using #printString and subclass that method
where appropriate. e.g. #printString often truncates long collections with a
"...". #logString probably would not do that.




--
View this message in context: 
http://forum.world.st/Object-logCr-tp4799595p4800051.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[horrido]

kilon.alios wrote
> It took python 24 years to get as popular as it is nowdays, the most
> popular languages have a similar lifespan if not more in some cases. Its a
> really long process and its full of compromises and ugly truths.

Longevity is not a strategy for success. There are many old languages that
have been around forever, and they have never become mainstream. Python,
along with a handful of other languages, are exceptions.

Smalltalk has had 40 years to get popular. It almost achieved it in the
1990s, but IBM dropped the ball and Sun kicked their ass. The last 20 years
have been dismal for Smalltalk; it's all but a forgotten language. (Not so
much in the past month. ;-)


> PS: Just a clarification because people love to put words on other people
> mouths, I never said that languages like Clojure and Scheme has been
> miserable failures generally, but based on the hype of how popular they
> will become. Both Clojure and Sceme are great language with continuously
> expanding communities . I was merely wanted to point out how hype does not
> help and there was tons of hype when Java allowed for the creation of
> those
> languages. Jython for example is one of the oldest Java languages  (2001),
> and there was tons of hype when the project started that Jython could
> become at worst an equal to Cpython on terms of popularity and even more
> popular than Java at best.  Sun even funded the development of Jython back
> in 2008.

Hype does not help if *all* it does is attract public attention. Hype helps
a great deal if it's backed up by tangible results; the product you're
hyping must deliver!

Hype is about growing mindshare from which springs many other benefits, /if
you play your cards right/.



--
View this message in context: 
http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4800040.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

[Jimmie Houchin]

On 1/16/2015 12:55 PM, Nicolas Cellier wrote:
2015-01-16 0:48 GMT+01:00 Jimmie Houchin >:


Hello,

Yes, I understand this is a micro-benchmark. And yes I know that
micro-benchmarks can be dangerous and sometimes worthless.
However, financial trading, which is the app I am working on, does
this a lot. This is precisely where most of the time is spent.
Adding data (numbers) or accessing data in arrays or matrices.
This is where my app lives. And performance is important.

Regarding my running of the test and the variety of loop sizes.
From what I see in the test there is only one loop size. 1
There are differing initial OrderedCollection sizes. Unless I am
misreading the code.

OrderedCollection new: 100.   (capacity 100).

I don't understand how this could be a capacity of 100 by what
seems to me to be a normal understanding when its initial size is
0 and it can grow infinitely beyond 100.

To me if it has a capacity of 100, immediately after creation its
size should be 100
and its initial 100 elements should be accessible.
oc at: 1 put: 1should work.
So I do not understand where this supposed capacity enters into
anything. It is neither immediately accessible, nor does it limit.


It's not specific to OrderedCollection.
Dictionary new: 100 and Set new: 100 also behave the same.

It's rather Array that behaves differently than the rest of Collection 
zoo, because an Array of capacity 100 is also an Array of size 100, 
same for other ArrayedCollection.


So if you re-think of it, you should always understand new: as 
reserving a certain capacity, which can casually also result in a 
collection of same size.


You should notice the #ofSize: message that was added once upon a time...


Yes, after writing the email when I went back into the image and browsed 
OrderedCollection, I saw the #ofSize: message which does exactly what I 
naively thought #new:   would do.


I ran the tests with   #ofSize:  and  #at:put:  and got a reasonably 
nice improvement over any of the #new:  implementations. It wasn't 
anywhere near the tests done using an Array, but better.


Dictionaries and Sets are very different creatures from Array and 
OrderedCollection. An OrderedCollection could just as easily be named 
GrowableArray or some such. At least from my understanding.


So, yes, I need to change my naive understanding to a now slightly 
better informed understanding.

There is much to learn.

Thanks for your input.

Jimmie

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

[Stephan Eggermont]

Eliot wrote:
>About 90% of the entire time is in the string copying primitive.  
>Not much to be done there.  Sista could speed this up by eliminating 
>the validation overhead of the primitive.  But with our current VM technology 
>there's not a lot one can do given that OrderedCollection is organized as a 
>flat stack. 
> This is probably a case where an ordered tree would be faster, albeit have a 
> lot more space overhead.

Switching collections backing store to a chunked representation once they grow 
beyond a certain threshold is probably the best thing to support larger 
collections.

Stephan

 

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

[Nicolas Cellier]

2015-01-16 0:48 GMT+01:00 Jimmie Houchin :

> Hello,
>
> Yes, I understand this is a micro-benchmark. And yes I know that
> micro-benchmarks can be dangerous and sometimes worthless. However,
> financial trading, which is the app I am working on, does this a lot. This
> is precisely where most of the time is spent. Adding data (numbers) or
> accessing data in arrays or matrices. This is where my app lives. And
> performance is important.
>
> Regarding my running of the test and the variety of loop sizes. From what
> I see in the test there is only one loop size. 1
> There are differing initial OrderedCollection sizes. Unless I am
> misreading the code.
>
> OrderedCollection new: 100.   (capacity 100).
>
> I don't understand how this could be a capacity of 100 by what seems to me
> to be a normal understanding when its initial size is 0 and it can grow
> infinitely beyond 100.
>
> To me if it has a capacity of 100, immediately after creation its size
> should be 100
> and its initial 100 elements should be accessible.
> oc at: 1 put: 1should work.
> So I do not understand where this supposed capacity enters into anything.
> It is neither immediately accessible, nor does it limit.
>
>
It's not specific to OrderedCollection.
Dictionary new: 100 and Set new: 100 also behave the same.

It's rather Array that behaves differently than the rest of Collection zoo,
because an Array of capacity 100 is also an Array of size 100, same for
other ArrayedCollection.

So if you re-think of it, you should always understand new: as reserving a
certain capacity, which can casually also result in a collection of same
size.

You should notice the #ofSize: message that was added once upon a time...

When I create an Array, it has a capacity with an understanding that I have.
> a := Array new: 100.
> size a.  "100"
> a at: 1.  "nil"  "works"
> a at: 1 put: 1.  "works"
>
> I naively expect the same from another Collection which looks like
> oc := OrderedCollection new: 100.
> Since it is a collection with an initial size (capacity). But because it
> is an OrderedCollection and not an Array, it is not limited by its initial
> capacity.
> Apparently my understanding faulty. I just wanted to express how this
> would potentially/probably be understood by someone who does not know this
> peculiarity of OrderedCollection.
>
> Regarding the comparison to Python and Julia.
> Mea Culpa, mea culpa, maxima mea culpa.
>
> While I thought I duplicated the Pharo code. I did not.
> I duplicated the inner loop which created and populated the array.
> I completely left off the outer loop which ran the inner loop 1 times.
>
> The Python code is simple.
>
> def t(n):
> s = time.time()
> for x in range(0,1):
> l = []
> for i in range(1,10001):
> l.append(i)
> e = time.time()
> print(e-s, len(l))
> return l
>
> list_test(1)#  ==  15.5 seconds
>
> Julia
> function test_array(asize)
>   for i = 1:1
> a = Array(Int64, asize)
> for i = 1:asize
>   a[i]=i
> end
>   end
> end
>
> @time(test_array(1))  # 0.9 seconds
>
> So Pharo at 1.6 seconds (Array time) is respectable compared to Julia's
> highly optimized preallocated arrays and thoroughly keeps Python in its
> place.
>
> And if I start Julia off with an Array(Int64,0) and do append!(a,[i,]).
> Julia's time plummets to 19seconds.
>
> I feel much better. Thanks for challenging my numbers and insuring my
> comparisons were correct.
>
> Jimmie
>
>
>
>
> On 1/15/2015 1:13 PM, Sven Van Caekenberghe wrote:
>
>> Jimmy,
>>
>>  On 15 Jan 2015, at 19:46, Jimmie Houchin  wrote:
>>>
>>> I do not understand what is happening here.
>>>
>>> oc := OrderedCollection new: 1.
>>> oc size. "0"
>>>
>>> a := Array new: 1.
>>> a size. "1"
>>>
>>> So it seems that the #new: isn't creating an OrderedCollection of the
>>> size we pass in.
>>>
>>> I discovered this when I attempted to do the identical test but with an
>>> Array instead of an OrderedCollection. Since the Array doesn't #add:   I
>>> had to change the code to #at:put:.
>>>
>> This is all normal and by design.
>>
>> OrderedCollection is a growable collection, designed so you can add
>> elements at either end. The thread's discussion is about growing strategies.
>>
>> Consider,
>>
>>(OrderedCollection new: 100) capacity = 100
>>
>> it means it has preallocated room for a 100 elements, but the way it is
>> managed is tricky, as people discovered.
>>
>>> When I noticed all of the OC code did #add: even if supposedly setting
>>> its size to 1(0). I tried to use #at:put: in the OrderedCollection but
>>> it failed because their was no index 1, because the size was still 0.
>>>
>>> I naively would have thought that OrderedCollection new: 1 would
>>> return an OrderedCollection of 1 empty/nil elements and that I could
>>> #at:put: into any of those 1 slots and #add if I needed to go beyond
>>> those 1.
>>>
>>> Tests done on a laptop with Wind

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Andrei Chis]

On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker 
wrote:

>
> > On 16 Jan 2015, at 12:12, Andrei Chis 
> wrote:
> >
> > For me it's ok like it is now.
> >
> >
> > I updated the GTDebuggers to use slots.
> > For example you can use the bytecode one to see what actually gets
> executed (and even step into the code of the slot).
> >
> >  
> >
>
> Wow! And just like that, the byte code debugger is actually very useful to
> see what happens for real with Slots…. very useful especially when
> you emit you own byte code for a Slot.
>
> > Now the other problem is that because reading a slot uses #send:read:
> the debugger will now stop at that instruction so one has to do an explicit
> step over to read the actual slot.
> > The logic that performs this check is now isolated in
> #stepToFirstInterestingBytecodeIn: so we could updated it to take slots
> into account.
> >
>
> Yes, that would be nice.
>

I made an issue:
https://pharo.fogbugz.com/f/cases/14743/The-debugger-should-skip-the-reading-of-slots

Now there is still the issue of stepping into a slot write, when stepping
into instructions.
One solution could be to have a setting that makes the debugger slot
sensitive (stepping into enters both slot reads and slot writes).
However, with the bytecode debugger one can easily step into slots.


Cheers,
Andrei




>
> Marcus
>

Re: [Pharo-dev] Understanding Object Structures

[Eliot Miranda]

Hi Thierry,

On Jan 16, 2015, at 8:10 AM, Thierry Goubier  wrote:

> 
> 
> 2015-01-16 16:55 GMT+01:00 Eliot Miranda :
>> Hi All,
>> 
>> On Jan 16, 2015, at 7:36 AM, Eliot Miranda  wrote:
>> 
>> > Hi Marcel,
>> >
>> > On Jan 16, 2015, at 5:54 AM, Marcel Taeumel 
>> >  wrote:
>> >
>> >> Ah, okay. I was curious about the performance of iterating over an array 
>> >> vs.
>> >> the linked list:
>> >>
>> >> a := Array new: 1000.
>> >> l := LinkedList new.
>> >>
>> >> 1000 timesRepeat: [l add: (StackLink with: nil)].
>> >>
>> >> [a do: [:ea | 1 + 2]] bench. "'94,600 per second.'"
>> >>
>> >> [l do: [:ea | 1 + 2]] bench. "'159,000 per second.'"
>> >>
>> >> I expected the opposite! :-O Why is that so?
>> >
>> > Look at the implementations of do:.
>> >
>> > In the Array case we iterate over the indices using SmallIntegers (fast 
>> > arithmetic with no allocation) and dereference each element using the 
>> > Object>>at: primitive, which (apart from type and bounds checking) is 
>> > simple indexed memory access. So one read per element.
>> >
>> > In the LinkedList case each list element is fetched from the previous 
>> > element and each value fetched from the element, so two reads per element.
>> 
>> This is interesting.  (Marcel, Chris, forgive me; I'm presuming; please 
>> don't take this personally).  Marcel above appears to lack an intuition 
>> about the structure of Array vs LinkedList.  And in developing a hash 
>> algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to 
>> lack an I tuition about Floats being boxed, assuming they were value types, 
>> not containers.
>> 
>> As a VM implementer I carry around a clear picture (literally, I am a visual 
>> thinker) of objects in my head.  Those pictures are key to my approach to 
>> design and optimization.
>> 
>> I presume that for someone approaching the system given only a textual 
>> description of object structures, through class comments and method source 
>> it is difficult to develop a good picture or mental model.  For me, I read 
>> the blue book first, which is replete with pictures.
>> 
>> I know that historically visual inspector frameworks such as Jun have been 
>> able to auto-generate pictorial representations of specific object graphs.  
>> I wonder how useful it would be to provide support for designers to include 
>> pictorial representations in class comments.
>> 
>> Again I presume that the text model would have to support inclusion of 
>> simple bitmaps (to avoid having to include a full drawing framework in the 
>> system) and that the designer would construct a sample graph, generate a 
>> diagram using a visual inspector framework using eg Jun, render it to a 
>> bitmap and include it in the class comment.
> 
> 
>  
>> 
>> A more elaborate system could of course include the sample graph and render 
>> it dynamically, that would allow exploration.
>> 
>> Either approach would make an interesting project, yes?
> 
> I would prefer something conceptually simpler and worthwhile: the ability to 
> embed a morph as a character in the text (would do the two approaches 
> easily). And a bit of marshalling/text representation to make a completely 
> textual representation possible.

Yes that's a *much* better idea and one we could realize v quickly.

> 
> I used to have that for hypermedia (i.e. a drawing editor with text frame 
> objects, and text frames able to display GUI components... in ParcPlace 
> Smalltalk)
> 
> Now I dream a bit of having something like TiddlyWiki in Pharo ;)
> 
> Thierry
> 

Re: [Pharo-dev] Understanding Object Structures

[Thierry Goubier]

2015-01-16 16:55 GMT+01:00 Eliot Miranda :

> Hi All,
>
> On Jan 16, 2015, at 7:36 AM, Eliot Miranda 
> wrote:
>
> > Hi Marcel,
> >
> > On Jan 16, 2015, at 5:54 AM, Marcel Taeumel <
> marcel.taeu...@student.hpi.uni-potsdam.de> wrote:
> >
> >> Ah, okay. I was curious about the performance of iterating over an
> array vs.
> >> the linked list:
> >>
> >> a := Array new: 1000.
> >> l := LinkedList new.
> >>
> >> 1000 timesRepeat: [l add: (StackLink with: nil)].
> >>
> >> [a do: [:ea | 1 + 2]] bench. "'94,600 per second.'"
> >>
> >> [l do: [:ea | 1 + 2]] bench. "'159,000 per second.'"
> >>
> >> I expected the opposite! :-O Why is that so?
> >
> > Look at the implementations of do:.
> >
> > In the Array case we iterate over the indices using SmallIntegers (fast
> arithmetic with no allocation) and dereference each element using the
> Object>>at: primitive, which (apart from type and bounds checking) is
> simple indexed memory access. So one read per element.
> >
> > In the LinkedList case each list element is fetched from the previous
> element and each value fetched from the element, so two reads per element.
>
> This is interesting.  (Marcel, Chris, forgive me; I'm presuming; please
> don't take this personally).  Marcel above appears to lack an intuition
> about the structure of Array vs LinkedList.  And in developing a hash
> algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to
> lack an I tuition about Floats being boxed, assuming they were value types,
> not containers.
>
> As a VM implementer I carry around a clear picture (literally, I am a
> visual thinker) of objects in my head.  Those pictures are key to my
> approach to design and optimization.
>
> I presume that for someone approaching the system given only a textual
> description of object structures, through class comments and method source
> it is difficult to develop a good picture or mental model.  For me, I read
> the blue book first, which is replete with pictures.
>
> I know that historically visual inspector frameworks such as Jun have been
> able to auto-generate pictorial representations of specific object graphs.
> I wonder how useful it would be to provide support for designers to include
> pictorial representations in class comments.
>
> Again I presume that the text model would have to support inclusion of
> simple bitmaps (to avoid having to include a full drawing framework in the
> system) and that the designer would construct a sample graph, generate a
> diagram using a visual inspector framework using eg Jun, render it to a
> bitmap and include it in the class comment.
>




>
> A more elaborate system could of course include the sample graph and
> render it dynamically, that would allow exploration.
>
> Either approach would make an interesting project, yes?
>

I would prefer something conceptually simpler and worthwhile: the ability
to embed a morph as a character in the text (would do the two approaches
easily). And a bit of marshalling/text representation to make a completely
textual representation possible.

I used to have that for hypermedia (i.e. a drawing editor with text frame
objects, and text frames able to display GUI components... in ParcPlace
Smalltalk)

Now I dream a bit of having something like TiddlyWiki in Pharo ;)

Thierry

Re: [Pharo-dev] review request

[Ben Coman]

I know everyone is busy and working in their own domains not having the
time to review a lot of other people's issues.  However I am on my own, not
part of a team where I can walk over and tap someone on the shoulder to ask
for review of an issue I've resolved.  It is a bit discouraging not to be
able to proceed for lack of review.  I'd be glad for any feedback including
"its crap, do it a different way".  So consider this a virtual should tap.

I have...
* refactored the two calls to #forMilliseconds: out to a single call
* replaced call to #wait  with #waitOr:
* added #waitOr:

Here is the diff...

WorldState >> interCyclePause: milliSecs
| currentTime wait |
self serverMode
ifFalse: [
(lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [
currentTime := Time millisecondClockValue.
wait := lastCycleTime + milliSecs - currentTime.

+ "wait is the time remaining until milliSecs has passed
+ since lastCycle. If wait is zero or less, no need to Delay"

+ "If wait is greater than milliSeconds then bypass Delay,
+ by setting wait to zero."
- (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [
- (Delay forMilliseconds: wait) wait ] ] ]
+ wait > milliSecs ifTrue: [ wait := 0 ] ] ]  "btw, wait>milliSecs can only
occur when clock rolls over. Eliminate after integrating issue 14353 ?"

- ifTrue: [ (Delay forMilliseconds: 50) wait ].
+ ifTrue: [ wait := 50 ].

+ wait > 0 ifTrue: [
+ (Delay forMilliseconds: wait) waitOr: [
+  self inform: 'WorldState>>interCyclePause failed.' ]
].

lastCycleTime := Time millisecondClockValue.
CanSurrenderToOS := true.

"--"

+Delay >> waitOr: anErrorBlock
+ self schedule.
+ [ beingWaitedOn
+ ifTrue: [ delaySemaphore wait ]
+ ifFalse:[ anErrorBlock value ]
+ ] ifCurtailed:[self unschedule].

+"Only the high priority timer event loop (TEL) signals /delaySempahore/.
If the
+ TEL is not running, a delay will block forever (for example the UI will
lock up).
+ /beingWaitedOn/ is only set to true from the TEL (via
+ DelayScheduler>>scheduleDelay: and Delay>>timingPriorityWaitedOn:) so
test
+ this to determine if TEL is running.  Avoid waiting when the TEL is not
running."

"--"

This is for issue 14669 "Delay refactoring (part 2a) - avoid UI locking up
when timer event loop is stopped" that is required to facilitate
integration of issue 14353 "Delay refactoring (part 2) - change from
milliseconds to microseconds.

cheers -ben

https://pharo.fogbugz.com/default.asp?14669
https://pharo.fogbugz.com/default.asp?14353

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Damien Pollet]

On 16 January 2015 at 16:22, Marcus Denker  wrote:
>> How do you do that?
>
> double click on the value… (it is a secret feature for now ;-)

hhhaaa :)

it worked via writing an accessor method too


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Marcus Denker]

> On 16 Jan 2015, at 12:20, Damien Pollet  wrote:
> 
> On 16 January 2015 at 14:59, Marcus Denker  wrote:
>> change “iv” to value (e.g. 5).
> 
> How do you do that?

double click on the value… (it is a secret feature for now ;-)

> When I try iv := 5 in the inspector, it looks like it's changing a
> local variable instead of the slot (as if the bottom field of the
> inspector was a workspace)
> 
> -- 
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
> 

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Marcus Denker]

> On 16 Jan 2015, at 12:12, Andrei Chis  wrote:
> 
> For me it's ok like it is now.
> 
> 
> I updated the GTDebuggers to use slots.
> For example you can use the bytecode one to see what actually gets executed 
> (and even step into the code of the slot).
> 
>  
> 

Wow! And just like that, the byte code debugger is actually very useful to see 
what happens for real with Slots…. very useful especially when
you emit you own byte code for a Slot.

> Now the other problem is that because reading a slot uses #send:read: the 
> debugger will now stop at that instruction so one has to do an explicit step 
> over to read the actual slot.
> The logic that performs this check is now isolated in 
> #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into 
> account.
> 

Yes, that would be nice.

Marcus

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Damien Pollet]

On 16 January 2015 at 14:59, Marcus Denker  wrote:
> change “iv” to value (e.g. 5).

How do you do that?
When I try iv := 5 in the inspector, it looks like it's changing a
local variable instead of the slot (as if the bottom field of the
inspector was a workspace)

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Andrei Chis]

For me it's ok like it is now.


I updated the GTDebuggers to use slots.
For example you can use the bytecode one to see what actually gets executed
(and even step into the code of the slot).

 [image: Inline image 1]

Now the other problem is that because reading a slot uses #send:read: the
debugger will now stop at that instruction so one has to do an explicit
step over to read the actual slot.
The logic that performs this check is now isolated in
#stepToFirstInterestingBytecodeIn: so we could updated it to take slots
into account.


Cheers,
Andrei



On Fri, Jan 16, 2015 at 3:41 PM, Marcus Denker 
wrote:

>
> > On 16 Jan 2015, at 11:28, Andrei Chis 
> wrote:
> >
> > Hi Marcus,
> >
> > So now ' self class allSlots ' should be used also in the debugger to
> get the instance variables of an object?
> >
>
> Yes, at least for now… I am not yet that happy with the naming… it is hard
> to get consistent *and* be resably compatible….
>
> So the idea is that the old API for (instVarAt:, instVarNames…) continues
> to work *but* this shows (and manipulates)
> what is really there. VM level instance variables.
>
> Slots are first class instance variables that
>  a) might redefine what happens of read/write
> —> all reflective read and write needs to go
> through the slots.
>  b) they often correspond 1:1 to a low level ivar, but they don’t
> have to (e.g. the TestSlot in the example has no underlying ivar)
> —> we need to ask for all Slots, not just all
> instVarNames.
>
> For the naming… in some way Slots are just “First Class Instance
> Variables” that map to VM level Fields.
> Sometimes I feel it would be nice to use just these two for naming: Fields
> (VM Level) and Instance Variables (Image level, aka Slots).
>
> But then, there is backward compatibility to be taken into account… we
> can’t really change instVarAt:… but we could of course keep
> those for legacy and use the “long form” for the “reified” instance
> variables: instanceVariableNamed:, #instanceVariableNames, and so on…
>
> To make it really consistent and just use “Field and Ivar", there would be
> a lot to be changed: names of byte codes, for example.
> So maybe having it like it is now is good? “Field and Ivar” are one
> concept, while the high-level one is “Slot”.
>
> I am not sure myself… I have to admit.
>
> Marcus
>
>
>

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

[Marcus Denker]

> On 16 Jan 2015, at 11:44, Ben Coman  wrote:
> 
> do you mean...?
> https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayouts.pdf
>  
> 
> 

No, Tims refers to the mails I send… describing the reflective reading and 
writing if Slots.

My probkem is that I could now dig that out and postpone other things. But I 
will not.
i will write a tutorial later, but not now. (I am already behind at least 3 
things that people
are waiting for that have higher priority…)

Marcus

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

[stepharo]

We would love.
With Epicea we have Changes representing not only class and instance 
addition/removal...
Now the question is also how do we initialize such new added instance variable.

That's easy if the slot definition has an initialiser.


Now we have probably to recompile the full class hierarchy.

I don't see a way if avoiding this unless we move to a self/newspeak model of 
inst var accessor.  But it can be made much faster than recompiling from 
source.  The idea is simply to disassemble every method from bytecode to an 
assembler level representation (such as Marcus' byte surgeon or my method 
massage), adjust offsets and regenerate.

This is what VisualWorks does and it is /much/ faster than recompiling from 
source.


Yes we should do that.

We are brainstorming on a modular way to initialize objects
What are the paths to achieve that in a clever way.

Yes the monolithic initialize method is an issue if one wants to be able to add 
inst vars individually.  Lazy initialize toon in accessors is one way.  That 
works well for eg inst vars used to implement caches (although now flushing 
becomes an issue).  There's no such thing as a free lunch :-)

I know :)
Damien was working on a incremental initialization model with marco

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

[Ben Coman]

do you mean...?
https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayouts.pdf

On Fri, Jan 16, 2015 at 8:02 PM, Tim Mackinnon  wrote:

> Maybe it wasn’t a blog post - but I definitely recall reading something
> last year that introduced the idea and showed some sample code (it wasn’t a
> pdf). I thought it was really handy, and wanted to go back a read it in the
> context of this thread.
>
> Tim
>
> On 15 Jan 2015, at 18:04, Marcus Denker  wrote:
>
> >
> >> On 15 Jan 2015, at 13:04, Tim Mackinnon  wrote:
> >>
> >> Marcus, can you remind us where that Blog post you wrote about using
> slots is? A google search of “Pharo Smalltalk slots” doesn’t seem to find
> it, and I remember it being a great intro to what is possible.
> >>
> >> (It’s worth considering tagging that post better - it should come up
> much higher in google search results).
> >>
> >
> > There is no blog post yet… I want to actually have it finished, else I
> would write a post about something not working… which would be
> > hard.
> >
> >   Marcus
> >
> >> Tim
> >>
> >> On 12 Jan 2015, at 14:59, Marcus Denker  wrote:
> >>
> >>>
>  On 11 Jan 2015, at 18:50, Chris Muller  wrote:
> 
>  It has been a while since I read the paper, but my memory is that
>  Slots lets you define features and/or constraints on inst-var's.  For
>  example, assigning default values or restricting the set of valid
>  values.
> 
>  This would probably be appealing for folks coming from languages like
>  Java or C++, because they're used to all of their "slots" being
>  statically typed.  It does seem ironic that where those static
>  languages have been trying to move toward being more dynamic, Pharo
>  newbies would find themselves arrived at a language which is trying to
>  make something that was purely dynamic into something more static.
> 
> >>>
> >>> It is *possible* to implement a kind of TypedSlot, but I do not think
> that
> >>> this is what people will use Slots for. And for sure there will be no
> TypeSlot
> >>> by default in Pharo.
> >>>
> >>> For Slots there are two levels
> >>>
> >>> 1) having objects that describe variables instead of strings. This is
> very powerful
> >>> already and will allow us to e.g. do watchpoints/breakpoitns in
> variables very easily
> >>>
> >>> This is already in Pharo3, but Pharo4 enhances the API and provides
> with the LinkWrapper
> >>> slot a way to transparently hook into variable access. This will be
> very powerful.
> >>>
> >>> 2) provide a way to declare that a slot is described by a special
> subclass of Slot. This is what this
> >>> change is about
> >>>
> >>> This is what we use Slots for are three directions:
> >>>
> >>> 1) active slots that announce when the are set. Replacing the whole
> ValueHolder stuf to some extend.
> >>> (This is where Slots + their Meta Object Protocol allow one to
> implement the special variables in Tweak
> >>> very easily. It is interesting that there, one had to copy the whole
> compiler and do many, many hacks.
> >>>
> >>> 2) Allow optimizing memory representation. E.g. look at Morph. Many
> flags are needed, but each takes a
> >>> whole pinter to true of false. So we have MorphExtension. And then on
> top of that a property dictionary.
> >>> With Slots, flags (sots that can only store true or false) can be
> realised very efficiently (31 boolean slots
> >>> of the hierarchy map to one ivar). With a PropertySlot, one can have
> values that are used seldomely
> >>> encoded in a way that they take no space.
> >>>
> >>> 3) Slots + Magritte. Magritte now relies of conventions and methods
> added to the class side. But what it
> >>> is: meta descriptions for ivars. I think there will be something very
> powerful in combining Magritte and Slots.
> >>>
> >>> 4) Experiments. One way to see Pharo is that it is suppose to be
> flexible enough to allow experiments
> >>> to be done fast and easy so we can explore many ideas easily.
> >>> These experiments will often be just that: experiments. But some of
> them will be so good that they will
> >>> turn out to be useful.
> >>>
>  My understanding is that specifying a certain Slot-type can save the
>  need to write, i.e., initializing or validating methods.  In exchange,
>  the number of concepts inherent in the language that must be learned
>  and remembered is increased.  Standard Smalltalk is only about 2 or 3
>  concepts -- sending messages and assigning pointers.  Period.  There's
>  something exciting about that because even Grandma can grok 2 or 3
>  concepts.  No other language is so simple.
> 
> >>> Slots do not really increase the concepts: they just are meta objects
> that have the
> >>> definition of the behaviour of assignment, turning assignment into
> message sends.
> >>>
>  By introducing the implicit behaviors of slots, the number of
>  different conceptual interactions between code and the slots it
>  references i

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Marcus Denker]

> On 16 Jan 2015, at 11:28, Andrei Chis  wrote:
> 
> Hi Marcus,
> 
> So now ' self class allSlots ' should be used also in the debugger to get the 
> instance variables of an object?
> 

Yes, at least for now… I am not yet that happy with the naming… it is hard to 
get consistent *and* be resably compatible….

So the idea is that the old API for (instVarAt:, instVarNames…) continues to 
work *but* this shows (and manipulates)
what is really there. VM level instance variables.

Slots are first class instance variables that
 a) might redefine what happens of read/write
—> all reflective read and write needs to go through 
the slots.
 b) they often correspond 1:1 to a low level ivar, but they don’t have 
to (e.g. the TestSlot in the example has no underlying ivar) 
—> we need to ask for all Slots, not just all 
instVarNames.

For the naming… in some way Slots are just “First Class Instance Variables” 
that map to VM level Fields.
Sometimes I feel it would be nice to use just these two for naming: Fields (VM 
Level) and Instance Variables (Image level, aka Slots).

But then, there is backward compatibility to be taken into account… we can’t 
really change instVarAt:… but we could of course keep 
those for legacy and use the “long form” for the “reified” instance variables: 
instanceVariableNamed:, #instanceVariableNames, and so on…

To make it really consistent and just use “Field and Ivar", there would be a 
lot to be changed: names of byte codes, for example.
So maybe having it like it is now is good? “Field and Ivar” are one concept, 
while the high-level one is “Slot”.

I am not sure myself… I have to admit.

Marcus

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Tudor Girba]

I guess so.

Doru

On Fri, Jan 16, 2015 at 3:28 PM, Andrei Chis 
wrote:

> Hi Marcus,
>
> So now ' self class allSlots ' should be used also in the debugger to get
> the instance variables of an object?
>
>
> Cheers,
> Andrei
>
> On Fri, Jan 16, 2015 at 2:59 PM, Marcus Denker 
> wrote:
>
>> Hi,
>>
>> Now GTInspector can inspect objects that use custom Slot definitions.
>>
>>
>> https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support
>>
>> create a class with he TestSlot (where the ivar lives in the Slot
>> instance and is thus shared
>> over all instances of A):
>>
>> Object subclass: #A
>> slots: { #iv => TestSlot }
>> classVariables: {  }
>> category: ‘Playground'
>>
>>
>> Inspect
>>
>> A new
>>
>> change “iv” to value (e.g. 5).
>>
>> inspect another  "A new”
>>
>> ==> it should show the value as 5.
>>
>> Thus both reading and writing now is done via the Slot. (as such this
>> require just a very simple change in GT, of course).
>>
>> The GT support of course needs to be improved later:
>>
>> -> we need a view that shows the object “as it really is” (keep in mind,
>> this object has no VM level instance variable!).
>> -> In the view with the slots they should annotated so we see that it is
>> a slot and can easily navigate to the slot definition
>> -> … I am sure more will be obvious as soon as we use it.
>>
>> Marcus
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Andrei Chis]

Hi Marcus,

So now ' self class allSlots ' should be used also in the debugger to get
the instance variables of an object?


Cheers,
Andrei

On Fri, Jan 16, 2015 at 2:59 PM, Marcus Denker 
wrote:

> Hi,
>
> Now GTInspector can inspect objects that use custom Slot definitions.
>
> https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support
>
> create a class with he TestSlot (where the ivar lives in the Slot instance
> and is thus shared
> over all instances of A):
>
> Object subclass: #A
> slots: { #iv => TestSlot }
> classVariables: {  }
> category: ‘Playground'
>
>
> Inspect
>
> A new
>
> change “iv” to value (e.g. 5).
>
> inspect another  "A new”
>
> ==> it should show the value as 5.
>
> Thus both reading and writing now is done via the Slot. (as such this
> require just a very simple change in GT, of course).
>
> The GT support of course needs to be improved later:
>
> -> we need a view that shows the object “as it really is” (keep in mind,
> this object has no VM level instance variable!).
> -> In the view with the slots they should annotated so we see that it is a
> slot and can easily navigate to the slot definition
> -> … I am sure more will be obvious as soon as we use it.
>
> Marcus
>

Re: [Pharo-dev] [Pharo4] Slots: GTInspector support

[Alexandre Bergel]

Excellent!

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



> On Jan 16, 2015, at 10:59 AM, Marcus Denker  wrote:
> 
> Hi,
> 
> Now GTInspector can inspect objects that use custom Slot definitions.
> 
>   
> https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support 
> 
> 
> create a class with he TestSlot (where the ivar lives in the Slot instance 
> and is thus shared
> over all instances of A):
> 
> Object subclass: #A
>   slots: { #iv => TestSlot }
>   classVariables: {  }
>   category: ‘Playground'
> 
> 
> Inspect
> 
> A new
> 
> change “iv” to value (e.g. 5).
> 
> inspect another  "A new”
> 
> ==> it should show the value as 5.
> 
> Thus both reading and writing now is done via the Slot. (as such this require 
> just a very simple change in GT, of course).
> 
> The GT support of course needs to be improved later: 
> 
> -> we need a view that shows the object “as it really is” (keep in mind, this 
> object has no VM level instance variable!).
> -> In the view with the slots they should annotated so we see that it is a 
> slot and can easily navigate to the slot definition
> -> … I am sure more will be obvious as soon as we use it.
> 
>   Marcus

Re: [Pharo-dev] [ANN] Pharo Consortium New Academic Partner: Ecole des Mines de Douai

[Ben Coman]

great to hear.
cheers -ben

On Fri, Jan 16, 2015 at 6:23 PM, Marcus Denker 
wrote:

> The Pharo Consortium is very happy to announce that the Ecole des Mines de
> Douai has joined the Consortium as an Academic Partner.
>
> About
>
> - Ecole des Mines de Douai: http://www.mines-douai.fr
> - Ecole des Mines de Douai, IA: http://ia.mines-douai.fr
> - Pharo Consortium: http://consortium.pharo.org
>
> The goal of the Pharo Consortium is to allow companies and institutions to
> support the ongoing development and future of Pharo.
> Individuals can support Pharo via the Pharo Association:
> http://association.pharo.org
>

[Pharo-dev] [Pharo4] Slots: GTInspector support

[Marcus Denker]

Hi,

Now GTInspector can inspect objects that use custom Slot definitions.


https://pharo.fogbugz.com/f/cases/14741/GTInspector-add-simple-slot-support 


create a class with he TestSlot (where the ivar lives in the Slot instance and 
is thus shared
over all instances of A):

Object subclass: #A
slots: { #iv => TestSlot }
classVariables: {  }
category: ‘Playground'


Inspect

A new

change “iv” to value (e.g. 5).

inspect another  "A new”

==> it should show the value as 5.

Thus both reading and writing now is done via the Slot. (as such this require 
just a very simple change in GT, of course).

The GT support of course needs to be improved later: 

-> we need a view that shows the object “as it really is” (keep in mind, this 
object has no VM level instance variable!).
-> In the view with the slots they should annotated so we see that it is a slot 
and can easily navigate to the slot definition
-> … I am sure more will be obvious as soon as we use it.

Marcus

Re: [Pharo-dev] Any Deep Learning Algorithm related lib in Pharo ?

[Serge Stinckwich]

Hi Cédrick,

I dunno what is deep learning but looks like neural networks.
I remember there was some library for NN in Squeak/Smalltalk that you
might find with Google.
You can help us develop machine learning algorithms for SciSmalltalk also.

Regards,

On Fri, Jan 16, 2015 at 12:05 PM, Cédrick Béler  wrote:
> Hi all,
>
> The question is in the title. I’m just journeying in this field and was
> wandering if it exists something on deep learning algorithms.
>
> Some refs
> an introduction:
> http://www.toptal.com/machine-learning/an-introduction-to-deep-learning-from-perceptrons-to-deep-networks
> Python lib:
> http://www.pyimagesearch.com/2014/09/22/getting-started-deep-learning-python/
> http://deeplearning.net/tutorial/
> Java lib (link in the tutorial)
> ...
>
> Cheers and best wishes all for 2015,
>
> Cédrick



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

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

[Tim Mackinnon]

Maybe it wasn’t a blog post - but I definitely recall reading something last 
year that introduced the idea and showed some sample code (it wasn’t a pdf). I 
thought it was really handy, and wanted to go back a read it in the context of 
this thread.

Tim

On 15 Jan 2015, at 18:04, Marcus Denker  wrote:

> 
>> On 15 Jan 2015, at 13:04, Tim Mackinnon  wrote:
>> 
>> Marcus, can you remind us where that Blog post you wrote about using slots 
>> is? A google search of “Pharo Smalltalk slots” doesn’t seem to find it, and 
>> I remember it being a great intro to what is possible.
>> 
>> (It’s worth considering tagging that post better - it should come up much 
>> higher in google search results).
>> 
> 
> There is no blog post yet… I want to actually have it finished, else I would 
> write a post about something not working… which would be
> hard.
> 
>   Marcus
> 
>> Tim
>> 
>> On 12 Jan 2015, at 14:59, Marcus Denker  wrote:
>> 
>>> 
 On 11 Jan 2015, at 18:50, Chris Muller  wrote:
 
 It has been a while since I read the paper, but my memory is that
 Slots lets you define features and/or constraints on inst-var's.  For
 example, assigning default values or restricting the set of valid
 values.
 
 This would probably be appealing for folks coming from languages like
 Java or C++, because they're used to all of their "slots" being
 statically typed.  It does seem ironic that where those static
 languages have been trying to move toward being more dynamic, Pharo
 newbies would find themselves arrived at a language which is trying to
 make something that was purely dynamic into something more static.
 
>>> 
>>> It is *possible* to implement a kind of TypedSlot, but I do not think that
>>> this is what people will use Slots for. And for sure there will be no 
>>> TypeSlot
>>> by default in Pharo.
>>> 
>>> For Slots there are two levels
>>> 
>>> 1) having objects that describe variables instead of strings. This is very 
>>> powerful
>>> already and will allow us to e.g. do watchpoints/breakpoitns in variables 
>>> very easily
>>> 
>>> This is already in Pharo3, but Pharo4 enhances the API and provides with 
>>> the LinkWrapper
>>> slot a way to transparently hook into variable access. This will be very 
>>> powerful.
>>> 
>>> 2) provide a way to declare that a slot is described by a special subclass 
>>> of Slot. This is what this
>>> change is about
>>> 
>>> This is what we use Slots for are three directions:
>>> 
>>> 1) active slots that announce when the are set. Replacing the whole 
>>> ValueHolder stuf to some extend.
>>> (This is where Slots + their Meta Object Protocol allow one to implement 
>>> the special variables in Tweak
>>> very easily. It is interesting that there, one had to copy the whole 
>>> compiler and do many, many hacks.
>>> 
>>> 2) Allow optimizing memory representation. E.g. look at Morph. Many flags 
>>> are needed, but each takes a
>>> whole pinter to true of false. So we have MorphExtension. And then on top 
>>> of that a property dictionary.
>>> With Slots, flags (sots that can only store true or false) can be realised 
>>> very efficiently (31 boolean slots
>>> of the hierarchy map to one ivar). With a PropertySlot, one can have values 
>>> that are used seldomely 
>>> encoded in a way that they take no space.
>>> 
>>> 3) Slots + Magritte. Magritte now relies of conventions and methods added 
>>> to the class side. But what it
>>> is: meta descriptions for ivars. I think there will be something very 
>>> powerful in combining Magritte and Slots.
>>> 
>>> 4) Experiments. One way to see Pharo is that it is suppose to be flexible 
>>> enough to allow experiments
>>> to be done fast and easy so we can explore many ideas easily.
>>> These experiments will often be just that: experiments. But some of them 
>>> will be so good that they will
>>> turn out to be useful.
>>> 
 My understanding is that specifying a certain Slot-type can save the
 need to write, i.e., initializing or validating methods.  In exchange,
 the number of concepts inherent in the language that must be learned
 and remembered is increased.  Standard Smalltalk is only about 2 or 3
 concepts -- sending messages and assigning pointers.  Period.  There's
 something exciting about that because even Grandma can grok 2 or 3
 concepts.  No other language is so simple.
 
>>> Slots do not really increase the concepts: they just are meta objects that 
>>> have the
>>> definition of the behaviour of assignment, turning assignment into message 
>>> sends.
>>> 
 By introducing the implicit behaviors of slots, the number of
 different conceptual interactions between code and the slots it
 references increases exponentially with the number of slot-types.  I
 fear trying to explain them to Grandma will have her eyes starting to
 glaze…
 
>>> I do not see now an active slot is harder to understand than e.g. a 
>>> ValueHolder.
>>

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[Sebastian Sastre]

> On Jan 16, 2015, at 7:52 AM, Tudor Girba  wrote:
> 
> We have no intention to insult anyone. At the same time, we also take the 
> freedom to choose the goals we want. We started from Smalltalk but our goal 
> is not to be a Smalltalk. We might end up being one for a while, but we might 
> as well not. Our goal is to reinvent software engineering. This implies that 
> we want to get to novel things that were not invented yet, hence difficult to 
> plan or predict. For example, we already have indications of novel language 
> models (like the new compiler, slots, new debugger model), novel IDE (GT), 
> novel VM (Spur and the up-and-coming Sista) and more will come.
> 
> So, when you read "Smalltalk inspired" please interpret it as saying that 
> while we honor the giants on the shoulders of which we build now, we want to 
> invent the future.
> 
> Cheers,
> Doru

This is probably the best thing I’ve read so far about the Pharo not being 
Smalltalk subject.

I suggest you create a blog post or try to get it published somewhere, 
potentially as Pharo FAQ answer

Success!

[Pharo-dev] Any Deep Learning Algorithm related lib in Pharo ?

[Cédrick Béler]

Hi all,

The question is in the title. I’m just journeying in this field and was 
wandering if it exists something on deep learning algorithms. 

Some refs
an introduction: 
http://www.toptal.com/machine-learning/an-introduction-to-deep-learning-from-perceptrons-to-deep-networks
Python lib: 
http://www.pyimagesearch.com/2014/09/22/getting-started-deep-learning-python/   
 http://deeplearning.net/tutorial/   
Java lib (link in the tutorial) 
...

Cheers and best wishes all for 2015,

Cédrick

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[kilon alios]

"I think we *really* need a smalltalk-talk mailing list…"

I definetly not need it, I am far more interested into coding with pharo
and understanding pharo libraries and tools than generally debating
smalltalk. But if you want such list to discuss smalltalk be my guest.

"Hi,

This topic was discussed before and I do not want to elaborate more, but
given that you seem to not have been involved in that thread, I will write
one single comment.

We have no intention to insult anyone. At the same time, we also take the
freedom to choose the goals we want. We started from Smalltalk but our goal
is not to be a Smalltalk. We might end up being one for a while, but we
might as well not. Our goal is to reinvent software engineering. This
implies that we want to get to novel things that were not invented yet,
hence difficult to plan or predict. For example, we already have
indications of novel language models (like the new compiler, slots, new
debugger model), novel IDE (GT), novel VM (Spur and the up-and-coming
Sista) and more will come.

So, when you read "Smalltalk inspired" please interpret it as saying that
while we honor the giants on the shoulders of which we build now, we want
to invent the future.

Cheers,"

I understand your (plural) position on this because I have read that thread
, and like you I dont want to elaborate more on this since I don't want to
create a very long thread of people agreeing that they disagree which what
that thread ended up being. I merely stated my opinion you are more than
welcome to disagree.

[Pharo-dev] [ANN] Pharo Consortium New Academic Partner: Ecole des Mines de Douai

[Marcus Denker]

The Pharo Consortium is very happy to announce that the Ecole des Mines de 
Douai has joined the Consortium as an Academic Partner.

About

- Ecole des Mines de Douai: http://www.mines-douai.fr
- Ecole des Mines de Douai, IA: http://ia.mines-douai.fr
- Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions to 
support the ongoing development and future of Pharo.
Individuals can support Pharo via the Pharo Association: 
http://association.pharo.org

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[Sven Van Caekenberghe]

> On 16 Jan 2015, at 10:58, Marcus Denker  wrote:
> 
> I think we *really* need a smalltalk-talk mailing list…

+1024

These discussions have nothing to do with developing or using Pharo.

>> On 16 Jan 2015, at 05:44, kilon alios  wrote:
>> 
>> 
>> "I would like to remind people that the aim of the Pharo project is more 
>> ambitious than the Smalltalk one"
>> 
>> I would like to hear this grand plan of Pharo, where is it ? Where is the 
>> official roadmap ? What are the goals that the core development team agree 
>> on ? Why are such a secret and I have never seen them discussed here or 
>> anywhere on the internet.
>> 
>> I would not call Pharo odd, Pharo is diffirent but not that diffirent. It 
>> offers me a way to code that I prefer over python , but I would not call my 
>> experience coding with pharo radically different compared to python coding. 
>> Smalltalk used to be the Purple Cow no doubt when it first came out , so 
>> many new concepts and ideas that were far apart from anything remotely 
>> similar. But nowdays the smalltalk paradigm has been embraced in several 
>> fronts , languages and IDEs are moving closer and closer. 
>> 
>> It took python 24 years to get as popular as it is nowdays, the most popular 
>> languages have a similar lifespan if not more in some cases. Its a really 
>> long process and its full of compromises and ugly truths. 
>> 
>> I also dont like the fact that Pharo calls itself "Smalltalk inspired" its 
>> an insult to people who put an effort into Smalltalk by spending hours 
>> making code. You cannot be "Smalltalk inspired" by forking code , your at 
>> best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself 
>> "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed 
>> mentality inside the heads of those Pharoers that believe this, its shows me 
>> fear , its shows me embarrassment, it shows me weakness. 
>> 
>> I would prefer it if Pharo was advertising itself as a modern Smalltalk 
>> implementation as a project that lives true to the Smalltalk philosophy and 
>> moves forward. Instead here we are calling Smalltalk "less ambitious" , why 
>> ?   Innovativing more than any other language have done so , is not 
>> ambitious enough for you ? 
>> 
>> I do believe in Pharo If I did not I would not contribute but I would prefer 
>> it without all the hype. Innovate all you want , code whatever makes you 
>> happy, live your dream but also respect the dreams of others, especially 
>> when you base your success on their success. And yes I will dare say it , 
>> Smalltalk has been extremely succesful in many fronts , far more than Pharo 
>> currently is.  
>> 
>> PS: Just a clarification because people love to put words on other people 
>> mouths, I never said that languages like Clojure and Scheme has been 
>> miserable failures generally, but based on the hype of how popular they will 
>> become. Both Clojure and Sceme are great language with continuously 
>> expanding communities . I was merely wanted to point out how hype does not 
>> help and there was tons of hype when Java allowed for the creation of those 
>> languages. Jython for example is one of the oldest Java languages  (2001), 
>> and there was tons of hype when the project started that Jython could become 
>> at worst an equal to Cpython on terms of popularity and even more popular 
>> than Java at best.  Sun even funded the development of Jython back in 2008. 
>> 
>> I admire what the creator of Redline done as I admire the effort that has 
>> been invested on both Pharo and Squeak. Its really hard to make a 
>> competitive product in a world so complex and so demanding as the one we 
>> live now. I do believe in Pharo and I hope the best for it but even Pharo 
>> never makes it to the top 20 most popular languages even in 30 years I wont 
>> lose my sleep over it. I love Pharo for what it is, and not what it may 
>> become.  
>> 
>> 
> 

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[Marcus Denker]

I think we *really* need a smalltalk-talk mailing list…

> On 16 Jan 2015, at 05:44, kilon alios  wrote:
> 
> 
> "I would like to remind people that the aim of the Pharo project is more 
> ambitious than the Smalltalk one"
> 
> I would like to hear this grand plan of Pharo, where is it ? Where is the 
> official roadmap ? What are the goals that the core development team agree on 
> ? Why are such a secret and I have never seen them discussed here or anywhere 
> on the internet.
> 
> I would not call Pharo odd, Pharo is diffirent but not that diffirent. It 
> offers me a way to code that I prefer over python , but I would not call my 
> experience coding with pharo radically different compared to python coding. 
> Smalltalk used to be the Purple Cow no doubt when it first came out , so many 
> new concepts and ideas that were far apart from anything remotely similar. 
> But nowdays the smalltalk paradigm has been embraced in several fronts , 
> languages and IDEs are moving closer and closer. 
> 
> It took python 24 years to get as popular as it is nowdays, the most popular 
> languages have a similar lifespan if not more in some cases. Its a really 
> long process and its full of compromises and ugly truths. 
> 
> I also dont like the fact that Pharo calls itself "Smalltalk inspired" its an 
> insult to people who put an effort into Smalltalk by spending hours making 
> code. You cannot be "Smalltalk inspired" by forking code , your at best 
> "Smalltalk based" and that makes you Smalltalk. Ruby can call itself 
> "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed mentality 
> inside the heads of those Pharoers that believe this, its shows me fear , its 
> shows me embarrassment, it shows me weakness. 
> 
> I would prefer it if Pharo was advertising itself as a modern Smalltalk 
> implementation as a project that lives true to the Smalltalk philosophy and 
> moves forward. Instead here we are calling Smalltalk "less ambitious" , why ? 
>   Innovativing more than any other language have done so , is not ambitious 
> enough for you ? 
> 
> I do believe in Pharo If I did not I would not contribute but I would prefer 
> it without all the hype. Innovate all you want , code whatever makes you 
> happy, live your dream but also respect the dreams of others, especially when 
> you base your success on their success. And yes I will dare say it , 
> Smalltalk has been extremely succesful in many fronts , far more than Pharo 
> currently is.  
> 
> PS: Just a clarification because people love to put words on other people 
> mouths, I never said that languages like Clojure and Scheme has been 
> miserable failures generally, but based on the hype of how popular they will 
> become. Both Clojure and Sceme are great language with continuously expanding 
> communities . I was merely wanted to point out how hype does not help and 
> there was tons of hype when Java allowed for the creation of those languages. 
> Jython for example is one of the oldest Java languages  (2001), and there was 
> tons of hype when the project started that Jython could become at worst an 
> equal to Cpython on terms of popularity and even more popular than Java at 
> best.  Sun even funded the development of Jython back in 2008. 
> 
> I admire what the creator of Redline done as I admire the effort that has 
> been invested on both Pharo and Squeak. Its really hard to make a competitive 
> product in a world so complex and so demanding as the one we live now. I do 
> believe in Pharo and I hope the best for it but even Pharo never makes it to 
> the top 20 most popular languages even in 30 years I wont lose my sleep over 
> it. I love Pharo for what it is, and not what it may become.  
> 
> 

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[Tudor Girba]

Hi,

This topic was discussed before and I do not want to elaborate more, but
given that you seem to not have been involved in that thread, I will write
one single comment.

We have no intention to insult anyone. At the same time, we also take the
freedom to choose the goals we want. We started from Smalltalk but our goal
is not to be a Smalltalk. We might end up being one for a while, but we
might as well not. Our goal is to reinvent software engineering. This
implies that we want to get to novel things that were not invented yet,
hence difficult to plan or predict. For example, we already have
indications of novel language models (like the new compiler, slots, new
debugger model), novel IDE (GT), novel VM (Spur and the up-and-coming
Sista) and more will come.

So, when you read "Smalltalk inspired" please interpret it as saying that
while we honor the giants on the shoulders of which we build now, we want
to invent the future.

Cheers,
Doru



On Fri, Jan 16, 2015 at 9:44 AM, kilon alios  wrote:

>
> "I would like to remind people that the aim of the Pharo project is more
> ambitious than the Smalltalk one"
>
> I would like to hear this grand plan of Pharo, where is it ? Where is the
> official roadmap ? What are the goals that the core development team agree
> on ? Why are such a secret and I have never seen them discussed here or
> anywhere on the internet.
>
> I would not call Pharo odd, Pharo is diffirent but not that diffirent. It
> offers me a way to code that I prefer over python , but I would not call my
> experience coding with pharo radically different compared to python coding.
> Smalltalk used to be the Purple Cow no doubt when it first came out , so
> many new concepts and ideas that were far apart from anything remotely
> similar. But nowdays the smalltalk paradigm has been embraced in several
> fronts , languages and IDEs are moving closer and closer.
>
> It took python 24 years to get as popular as it is nowdays, the most
> popular languages have a similar lifespan if not more in some cases. Its a
> really long process and its full of compromises and ugly truths.
>
> I also dont like the fact that Pharo calls itself "Smalltalk inspired" its
> an insult to people who put an effort into Smalltalk by spending hours
> making code. You cannot be "Smalltalk inspired" by forking code , your at
> best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself
> "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed
> mentality inside the heads of those Pharoers that believe this, its shows
> me fear , its shows me embarrassment, it shows me weakness.
>
> I would prefer it if Pharo was advertising itself as a modern Smalltalk
> implementation as a project that lives true to the Smalltalk philosophy and
> moves forward. Instead here we are calling Smalltalk "less ambitious" , why
> ?   Innovativing more than any other language have done so , is not
> ambitious enough for you ?
>
> I do believe in Pharo If I did not I would not contribute but I would
> prefer it without all the hype. Innovate all you want , code whatever makes
> you happy, live your dream but also respect the dreams of others,
> especially when you base your success on their success. And yes I will dare
> say it , Smalltalk has been extremely succesful in many fronts , far more
> than Pharo currently is.
>
> PS: Just a clarification because people love to put words on other people
> mouths, I never said that languages like Clojure and Scheme has been
> miserable failures generally, but based on the hype of how popular they
> will become. Both Clojure and Sceme are great language with continuously
> expanding communities . I was merely wanted to point out how hype does not
> help and there was tons of hype when Java allowed for the creation of those
> languages. Jython for example is one of the oldest Java languages  (2001),
> and there was tons of hype when the project started that Jython could
> become at worst an equal to Cpython on terms of popularity and even more
> popular than Java at best.  Sun even funded the development of Jython back
> in 2008.
>
> I admire what the creator of Redline done as I admire the effort that has
> been invested on both Pharo and Squeak. Its really hard to make a
> competitive product in a world so complex and so demanding as the one we
> live now. I do believe in Pharo and I hope the best for it but even Pharo
> never makes it to the top 20 most popular languages even in 30 years I wont
> lose my sleep over it. I love Pharo for what it is, and not what it may
> become.
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

[kilon alios]

"I would like to remind people that the aim of the Pharo project is more
ambitious than the Smalltalk one"

I would like to hear this grand plan of Pharo, where is it ? Where is the
official roadmap ? What are the goals that the core development team agree
on ? Why are such a secret and I have never seen them discussed here or
anywhere on the internet.

I would not call Pharo odd, Pharo is diffirent but not that diffirent. It
offers me a way to code that I prefer over python , but I would not call my
experience coding with pharo radically different compared to python coding.
Smalltalk used to be the Purple Cow no doubt when it first came out , so
many new concepts and ideas that were far apart from anything remotely
similar. But nowdays the smalltalk paradigm has been embraced in several
fronts , languages and IDEs are moving closer and closer.

It took python 24 years to get as popular as it is nowdays, the most
popular languages have a similar lifespan if not more in some cases. Its a
really long process and its full of compromises and ugly truths.

I also dont like the fact that Pharo calls itself "Smalltalk inspired" its
an insult to people who put an effort into Smalltalk by spending hours
making code. You cannot be "Smalltalk inspired" by forking code , your at
best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself
"Smalltalk inspired" , Pharo cannot. This shows to me a very flawed
mentality inside the heads of those Pharoers that believe this, its shows
me fear , its shows me embarrassment, it shows me weakness.

I would prefer it if Pharo was advertising itself as a modern Smalltalk
implementation as a project that lives true to the Smalltalk philosophy and
moves forward. Instead here we are calling Smalltalk "less ambitious" , why
?   Innovativing more than any other language have done so , is not
ambitious enough for you ?

I do believe in Pharo If I did not I would not contribute but I would
prefer it without all the hype. Innovate all you want , code whatever makes
you happy, live your dream but also respect the dreams of others,
especially when you base your success on their success. And yes I will dare
say it , Smalltalk has been extremely succesful in many fronts , far more
than Pharo currently is.

PS: Just a clarification because people love to put words on other people
mouths, I never said that languages like Clojure and Scheme has been
miserable failures generally, but based on the hype of how popular they
will become. Both Clojure and Sceme are great language with continuously
expanding communities . I was merely wanted to point out how hype does not
help and there was tons of hype when Java allowed for the creation of those
languages. Jython for example is one of the oldest Java languages  (2001),
and there was tons of hype when the project started that Jython could
become at worst an equal to Cpython on terms of popularity and even more
popular than Java at best.  Sun even funded the development of Jython back
in 2008.

I admire what the creator of Redline done as I admire the effort that has
been invested on both Pharo and Squeak. Its really hard to make a
competitive product in a world so complex and so demanding as the one we
live now. I do believe in Pharo and I hope the best for it but even Pharo
never makes it to the top 20 most popular languages even in 30 years I wont
lose my sleep over it. I love Pharo for what it is, and not what it may
become.

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

[Norbert Hartl]

> Am 16.01.2015 um 00:50 schrieb Ben Coman :
> 
> Actually, the requirements to modify/link the vm make it more a [vm-dev] 
> topic, but still interesting for [pharo-dev]s. 
> It wouldn't be [pharo-users] until there was something to "use" :)
> 
But you could use it if it would be there. Having it on pharo-users could lead 
to a lot of people showing their interest in using it. And it definetely is a 
use case :)

Norbert
>> On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul  wrote:
>> Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
>> 
>>> 
>>> 
> 
>> -Original Message-
>> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf
>> Of Alain Rastoul
>> Sent: Wednesday, January 14, 2015 10:39 PM
>> To: pharo-dev@lists.pharo.org
>> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS
>> 
>> Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a écrit :
>>> 
>>> I was not planning specializing the VM for the image. But rather
>>> link in a VM with everything needed to run a range of images. The
>>> dependencies are handled by creating an OCAML module that expresses
>> these and the VM code then lives in the module. The OCAML dependence
>> analyser (a sat solver) then ensures those are satisfied.
>>> 
>> But if you don't have a specialized smalltalk vm and image, you will
>> have to embed full system dependencies, in order to build a full
>> working smalltalk system (having most part not working could be a
>> very bad thing), and then you loose the unikernel approach benefits
>> (very lean dedicated system, small attack surface etc.).
> My implicit assumption was that these VM would be designed for running
 headless web-services on smaller EC2 instances. And perhaps naively was
 thinking that the number of system dependencies would be quite low:
> 
> - memory
> - CPU
> - networking stack
> - http/https
> 
> - no file system but access to block storage (or perhaps even link
> image in so no storage at all)
> - mirage is single threaded with green threads so no
> multithreading/processing
 
 Honestly, the VM is not that large. There are not many variation points on 
 that
 level.
 Where you want specialization is the *image*.
>>> 
>>> Thanks Marcus - good to know
>>> 
 
 Marcus
>>> 
>>> 
>>> 
>> Yes, the vm is not so big, and specialization has to be done in the image.
>> But there is a key point to mention about openmirage : if it started as unix 
>> (or linux, don't know), it is not linux at all as I understand it See 
>> chapter 3
>> http://queue.acm.org/detail.cfm?id=2566628
>> " ... The last compilation strategy drops the dependency on Unix entirely 
>> and recompiles the MirNet module to link directly to a Xen network driver, 
>> which in turn pulls in all the dependencies it needs to boot on Xen. This 
>> progressive recompilation is key to the usability of MirageOS, ... etc"
>> 
>> The compilation process produce a single compiled unit that includes your 
>> application linked with the needed libraries, ie: the kernel+application, 
>> there is no linux kernel and no processes at all.
>> Even driver's code is linked to you application.
>> It can be booted in a Xen guest vm like PharoNOS, Linux tiny core
>> or others linux but ...
>> I see a completely different animal is here :)
>> if I'm wrong, please correct me
>> 
>> NB: Is this thread about pharo devel ?
>> or should it be moved to pharo-users ?
>> 
>> -- 
>> Regards,
>> 
>> Alain
>> 
>> 
>