Re: [Pharo-dev] Spotter idea - exclusion filter and google search syntax

[Ben Coman]

On Sun, Feb 8, 2015 at 8:53 AM, Nicolai Hess  wrote:

>
>
> 2015-02-08 0:32 GMT+01:00 Ben Coman :
>
>>
>> Just a random idea for Spotter, being able to exclude items from the
>> search using a hyphen/minus sign.
>>
>> I don't have a use case right now, but it "feels" right, so maybe one
>> will turn up soon.  Its a broadly used paradigm per google search (
>> https://support.google.com/mail/answer/7190?hl=en)
>>
>>
>> Also, it would be useful to be able to search on multiple terms similar
>> to a regular web search.
>>
>> A slightly contrived use case is that I want to investigate drag handling
>> of morphs. So I guess entities will have the word "drag" and then maybe
>> "handler" or "handle" but in which order? Will it be #dragHandler or
>> #handleDrag or #handleEventDrag or #handlesMouseOverDragging: ?  A single
>> search term restricts me to having to guess and manually retry each
>> possible order.  Searching on "drag  hand" and getting all possible
>> ordering would be real nice.
>>
>> cheers -ben
>>
>
> +1 for exclusion filter
> (You can already combine search terms - sequentiel.
> 1. search drag and in the result list (implementors)
> 2. search again with the term handler)
>
>
Thanks for the tip, thats cool. Still, doing it from the first window would
be more immediate.
cheers -ben

Re: [Pharo-dev] Spotter idea - exclusion filter and google search syntax

[Nicolai Hess]

2015-02-08 0:32 GMT+01:00 Ben Coman :

>
> Just a random idea for Spotter, being able to exclude items from the
> search using a hyphen/minus sign.
>
> I don't have a use case right now, but it "feels" right, so maybe one will
> turn up soon.  Its a broadly used paradigm per google search (
> https://support.google.com/mail/answer/7190?hl=en)
>
>
> Also, it would be useful to be able to search on multiple terms similar to
> a regular web search.
>
> A slightly contrived use case is that I want to investigate drag handling
> of morphs. So I guess entities will have the word "drag" and then maybe
> "handler" or "handle" but in which order? Will it be #dragHandler or
> #handleDrag or #handleEventDrag or #handlesMouseOverDragging: ?  A single
> search term restricts me to having to guess and manually retry each
> possible order.  Searching on "drag  hand" and getting all possible
> ordering would be real nice.
>
> cheers -ben
>

+1 for exclusion filter
(You can already combine search terms - sequentiel.
1. search drag and in the result list (implementors)
2. search again with the term handler)

[Pharo-dev] Spotter idea - exclusion filter and google search syntax

[Ben Coman]

Just a random idea for Spotter, being able to exclude items from the search
using a hyphen/minus sign.

I don't have a use case right now, but it "feels" right, so maybe one will
turn up soon.  Its a broadly used paradigm per google search (
https://support.google.com/mail/answer/7190?hl=en)


Also, it would be useful to be able to search on multiple terms similar to
a regular web search.

A slightly contrived use case is that I want to investigate drag handling
of morphs. So I guess entities will have the word "drag" and then maybe
"handler" or "handle" but in which order? Will it be #dragHandler or
#handleDrag or #handleEventDrag or #handlesMouseOverDragging: ?  A single
search term restricts me to having to guess and manually retry each
possible order.  Searching on "drag  hand" and getting all possible
ordering would be real nice.

cheers -ben

Re: [Pharo-dev] ||

[Ben Coman]

On Sun, Feb 8, 2015 at 4:55 AM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

>
> How can I halt the execution of a specific pragma? Can I write  halt>?
>
>
In following this discussion, this thought also occurred to me.  It would
be nice to be able to break at the point where the pragma is being
collected.  As well as helping determine if the pragma is working, this
would help discoverability of how pragmas work.

cheers -ben

Re: [Pharo-dev] ||

[Thierry Goubier]

2015-02-07 20:48 GMT+01:00 Eliot Miranda :

>
>
> Array literals are not executable.  They are literals.  They need an
> interpreter to add semantics.  This is one of the reasons why Spec is
> poor.  Pragmas are Message instances.  They respond to sendTo:/sentTo:.
> STON is not executable, it needs an interpreter.
>

The STON thing was a joke on the tagging use of pragmas :)


>
> There are other ways to add metadata to methods. Without tagging.

>>>
>>> Haven't we discussed that?  Putting metadata off to the side introduces
>>> a bookkeeping problem.  It is a bad idea.
>>>
>>
>> And pragmas only partially address that.
>>
>
> Partially?  It completely solves the issue of keeping metadata associated
> with a method.
>

It solve the issue of associating a limited form of metadata (one or two
pragmas), with a few drawbacks (see below).


>
> Imagine that Sista works, that it has dozens of tuning points for a method
>> (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this
>> loop should be enrolled) do you imagine writing all that into the method to
>> guide Sista with pragmas? You'll end up in exactly the same situation as
>> OpenMP 4, where it is possible to write programs with more #pragma lines
>> than C/C++ code.
>>
>
> One doesn't need a line per option.  One can use... literal arrays
> someImportantMethod
> but for Sista we imagine very few tuning options, perhaps only one, which
> is to say to the optimizer optimize this method even if it doesn't show up
> as a hot spot.  Sista is /not/ going to look like gcc.
>

Hum, that's sad. I wanted to try a few ideas along the ones I see in the
HPC projects I'm on: specialisation, vectorisation, accelerator off-loading
:(


>
>
>
>> The method with the menu pragma is named "worldMenuCommand" ...
>>
>
> I don't see examples of this in the pharo 4 image I have to hand.  What's
> the full selector?
>

Search for menu pragmas with the finder; the first two in Pharo30 are:

RecentMessageList>>recentMessageListMenuOn:
ScriptLoader30>>menuCommandOn:

(I just made the worldMenuCommand up :))

The tag is, so it is strictly descriptive.


>
>
>> The method with the gtInspector pragma is named
>> "gtInspectorPresentation..."
>>
>
> This one is ok.  The pragma both says the method is a pane in a glamour
> inspector, and says what the order is relative to others.  One thing that's
> broken is that the finder doesn't find any senders.  Another thing is that
> the pragma doesn't do anything.  If the Glamour inspector added panes to
> itself by using sentTo: to evaluate the pragma then when you did
> "implementors" you'd find the builder.
>

Ok. We're starting to get somewhere, with a better idea of what the
semantic of pragmas should be.

And closer to what I said earlier: make pragmas executed at compile time.


>
> So those examples are not taking full advantage.  In VW they're more
> interesting, e.g.
> searchForStringInSource
> "Spawn a Browser on all methods which contain a specified string."
>
>  nameKey: nil
> menu: #(#listMenu #browse)
> position: 21.03 >
> ...
>

In a way, I like this usage: it's clear, it will be executed.

In another way, yuck :( You're doing an OpenMP 4 kind of pragma (writing
programs in the pragma syntax), forcing us to program in a pure literal
dialect of smalltalk :(


>
> which says which sub menu it is in (listMenu browse), where it is relative
> to other entries (21.03), what its hot key is (P). And
> MenuAutomaticGeneraotr implements the pragma (which shows up though the
> "implementors" menu on the menu pragma method):
> menuItem: label nameKey: key menu: menuIDs position: position "If the
> method is to be inserted into our menu, create a MenuItem, otherwise answer
> nil." | realLabel | menuIDs first = menuName ifFalse: [^nil]. realLabel :=
> self decodeLabel: label. ^Array with: ((MenuItem labeled: realLabel)
> nameKey: key) with: (menuIDs copyFrom: 2 to: menuIDs size) with: position
>
>
>> Additionally, as I told you before: the pragma semantic isn't in the
>> method... It's somewhere else in the system and senders of that pragma
>> doesn't get it.
>>
>
> I know that very well.  If things are done right, that the finder will
> find pragmas via "senders", and if the designer has chosen to implement the
> pragma in some processing object, then the link is made.  But I disagree
> that the semantic is entirely elsewhere in the system.  The
> /implementation/ is elsewhere in the system.  The semantic is in the
> pragma, in exactly the same way as a message specifies an operation to be
> performed and a method specifies an implementation, because... pragmas are
> messages.
>

But they can (and often are) used in a strictly descriptive way because
they do not carry any clear semantic in Smalltalk itself.


>
>
>> Just have a look at OmniBrowser and tell me that you don't understand
>> where the menu commands are :)
>>
>
> I don't want to criticise OmniBrowser, but if pragmas are used in the
> pattern above 

Re: [Pharo-dev] ||

[Hernán Morales Durand]

Hi Eliot,

2015-02-07 14:48 GMT-03:00 Eliot Miranda :

> Hi Hernan,
>
> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>>
>> 2015-02-07 5:59 GMT-03:00 kilon alios :
>>
>>> Personally I don't like Pragmas, they have not convinced me so far that
>>> they fit the style of Smalltalk syntax. I have to confess though I never
>>> liked descriptive elements and languages .
>>>
>>>
>> Me neither. Actually the pragma idea is not wrong per se, it is the tag
>> syntax to write them which bothers me. Because the world can be described
>> with tags if you start that path.
>>
>
> How exactly is the syntax wrong?
>

I am not saying syntax is wrong, I just don't like it because:

1) Adds another level of representation inside an already reflective system.
2) It could be done with plain common message sends.
3) Should be (to me) "hidden" from method pane, and displayed by a specific
tool inside the system browser.


> The  syntax predates pragmas.  It was used first
> for numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it
> with primitive:module:.  I and others extended it to include arbitrary
> literal message patterns.  The syntax of a literal message pattern is the
> syntax of a send with no receiver and only literal arguments.
>
The use of this syntax means
> a) no new syntax
> b) each pragma is potentially executable
> c) methods using specific pragmas can be found using "find senders"
> d) the execution side of a pragma can be found using "find implementors"
>
> So what's wrong with that?  How is it wrong to use a common Smalltalk
> object, a Message, that is well-supported in the system, for method
> metadata?
>
>
I get that pragmas are messages, but they assume an implicit receiver,
which actually depends on context. If I understood right with pragmas
always receiver = destination?  If you change things in the communication
model (receiver, sender, message, etc.), by removing or adding elements,
you have a loss in the message because it gets harder to reconstruct the
message send.

Consider


| eventRegistration |
{ eventRegistration }.
self eventRegistration.

which of them "it sounds like" you cannot infer their purpose?

To me the first because you need the context MyClass>>methodName
and you need to browse the pragma to get its purpose.



>
>> There are other ways to add metadata to methods. Without tagging.
>>
>
> Haven't we discussed that?  Putting metadata off to the side introduces a
> bookkeeping problem.  It is a bad idea.
>

Yes, but I still have a lot of doubts about feedback with pragmas (I hope
you view them as constructive criticism).

Is like pragmas assume there is always a perfect message transaction.
How can I halt the execution of a specific pragma? Can I write ?
How do I know if it will get executed? Is  a functional pragma?
How do I distinguis any pragma from being functional or "documentation"?


>
>
>> And they don't need to be in the method pane itself.
>>
>
> For some kinds of metadata, for metadata with semantics, not just a
> documentary function, it is important for the metadata to be obvious.
>

I think this depends on context. Because your work could be towards
low-level machinery details or software reenginering, doesn't mean that we
all need to view compiler directives, functional and structural
annotations, etc.

And if I can write some prediction... When someone invents automatic
annotation (like happens now with genomes) and decides it will be cool to
have them in the image (because you will gain performance, more reflective
capabilitites, etc) methods could explode with pragmas to the point gets to
be annoying to browse any method. Then the tool will have to be built by
need.


> No one has argued for hiding the primitive specification off-to-the-side.
>  "Need" is a poor criticism here because using turing equivalence lots of
> things don't "need" to be the way they are.  Instead why not ask what are
> the pros and cons?
>
>
Ok, many of us knows the pros. I have been using pragmas for a while.
But if we stop discussing then it will never adapt to new ideas.
So you may want to share your view of cons too :)


>
>> It is like having to specify protocol because there is no list pane to
>> create them.
>>
>
> I disagree.  When the pragma is specifying type information, specifying
> that the method is an action on a specific menu, is a pane in an inspector,
> and many other uses, it is essential that that information be represented,
> and putting it in a one-off bookkeeping system is a bad idea.  We're not
> talking about simple documentary metadata like author, category etc.
>

Well, I think documentary metadata is tremendously complex.


> We're using pragmas for semantics, semantics of the method that are
> outside of its execution semantics, semantics about how the method fits in
> the broader system.  And putting that in non-obvious places is a bad idea.
>
>
I agree. But obvious could be a place where can be loc

Re: [Pharo-dev] [Slots] Invisible Slots

[Eliot Miranda]

On Sat, Feb 7, 2015 at 9:35 AM, Marcus Denker 
wrote:

>
> On 07 Feb 2015, at 18:29, Marcus Denker  wrote:
>
>
>
> On Fri, Feb 6, 2015 at 10:13 PM, stepharo  wrote:
>
>> I want relationships for certain modeling purposes
>> What I like is that we should arrive to get a collection of useful slots
>> with optimal implementation instead all of us reinventing the wheel.
>>
>> I have started to collect the examples in Slots-Examples (in #481).
> At the start these are artificial (just testing/showing something), but
> slowly we will add useful ones, too.
>
> I started to implement PropertySlot, this uses hidden slots,
> initialisation (to set the empty dictionary of the base slot), virtual slots
> (the proper slots), reflectively changing the class both when adding and
> removing (to add the base slot and remove it as needed).
>
> and custom byte code generation to read and write with just #at: and
> #at:put on the base slot…
>

and remember that the closure bytecodes can access a field without a bounds
check

140   10001100   Push Temp At  In Temp Vector At:

141   10001101   Store Temp At  In Temp Vector At:

142   10001110   Pop and Store Temp At  In Temp
Vector At: 
-- 
best,
Eliot

Re: [Pharo-dev] ||

[Eliot Miranda]

On Sat, Feb 7, 2015 at 10:21 AM, Thierry Goubier 
wrote:

>
>
> 2015-02-07 18:48 GMT+01:00 Eliot Miranda :
>
>> Hi Hernan,
>>
>> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>>
>>> 2015-02-07 5:59 GMT-03:00 kilon alios :
>>>
 Personally I don't like Pragmas, they have not convinced me so far that
 they fit the style of Smalltalk syntax. I have to confess though I never
 liked descriptive elements and languages .


>>> Me neither. Actually the pragma idea is not wrong per se, it is the tag
>>> syntax to write them which bothers me. Because the world can be described
>>> with tags if you start that path.
>>>
>>
>> How exactly is the syntax wrong?
>> The  syntax predates pragmas.  It was used first
>> for numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it
>> with primitive:module:.  I and others extended it to include arbitrary
>> literal message patterns.  The syntax of a literal message pattern is the
>> syntax of a send with no receiver and only literal arguments.  The use of
>> this syntax means
>> a) no new syntax
>> b) each pragma is potentially executable
>> c) methods using specific pragmas can be found using "find senders"
>> d) the execution side of a pragma can be found using "find implementors"
>>
>> So what's wrong with that?  How is it wrong to use a common Smalltalk
>> object, a Message, that is well-supported in the system, for method
>> metadata?
>>
>
> The point was: descriptive and the world could be described  by tags :)
> Message syntax for pragmas is just a consequence of the original primitive
> syntax, nothing else (I.e. natural syntax extension). Given how it is used
> and that the "potentially executable" is just that, potential, array
> literals would work just as well (and I'm nearly sure that a todays design
> for pragmas would give us something like STON content :))
>

Array literals are not executable.  They are literals.  They need an
interpreter to add semantics.  This is one of the reasons why Spec is
poor.  Pragmas are Message instances.  They respond to sendTo:/sentTo:.
STON is not executable, it needs an interpreter.

There are other ways to add metadata to methods. Without tagging.
>>>
>>
>> Haven't we discussed that?  Putting metadata off to the side introduces a
>> bookkeeping problem.  It is a bad idea.
>>
>
> And pragmas only partially address that.
>

Partially?  It completely solves the issue of keeping metadata associated
with a method.

Imagine that Sista works, that it has dozens of tuning points for a method
> (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this
> loop should be enrolled) do you imagine writing all that into the method to
> guide Sista with pragmas? You'll end up in exactly the same situation as
> OpenMP 4, where it is possible to write programs with more #pragma lines
> than C/C++ code.
>

One doesn't need a line per option.  One can use... literal arrays

someImportantMethod


but for Sista we imagine very few tuning options, perhaps only one, which
is to say to the optimizer optimize this method even if it doesn't show up
as a hot spot.  Sista is /not/ going to look like gcc.



> (And C #pragmas are clearly more powerfull than Smalltalk's, since they
> are not required to be at the start of the function only)
>

Sure.  Pragmas associate with methods, not statements.



> And they don't need to be in the method pane itself.
>>>
>>
>> For some kinds of metadata, for metadata with semantics, not just a
>> documentary function, it is important for the metadata to be obvious.  No
>> one has argued for hiding the primitive specification off-to-the-side.
>>  "Need" is a poor criticism here because using turing equivalence lots of
>> things don't "need" to be the way they are.  Instead why not ask what are
>> the pros and cons?
>>
>>
>>
>>> It is like having to specify protocol because there is no list pane to
>>> create them.
>>>
>>
>> I disagree.  When the pragma is specifying type information, specifying
>> that the method is an action on a specific menu, is a pane in an inspector,
>> and many other uses, it is essential that that information be represented,
>> and putting it in a one-off bookkeeping system is a bad idea.  We're not
>> talking about simple documentary metadata like author, category etc.  We're
>> using pragmas for semantics, semantics of the method that are outside of
>> its execution semantics, semantics about how the method fits in the broader
>> system.  And putting that in non-obvious places is a bad idea.
>>
>
> Good, you're giving my favorite examples for what pragmas are redundant :)
>
> The method with the menu pragma is named "worldMenuCommand" ...
>

I don't see examples of this in the pharo 4 image I have to hand.  What's
the full selector?


> The method with the gtInspector pragma is named
> "gtInspectorPresentation..."
>

This one is ok.  The pragma both says the method is a pane in a glamour

Re: [Pharo-dev] Metacello + Filetree

[Dale Henrichs]

The best way to resolve configuration errors is to run the validator:

  (MetacelloToolBox validateConfiguration: ) inspect.

The class comment of MetacelloMCVersionValidator has information about 
the various reason codes and between the two you should be able to 
figure out how to repair the configuration.


Let me know if you need additional help interpreting the validation report.

Dale

On 2/7/15 11:29 AM, Thierry Goubier wrote:

Hi Sebastian,

It seems that something is amiss in the configuration. You are using a 
baseline in the configuration? Are you using #common, #pharoX.x tags? 
I am also a bit lost with some of Metacello errors, and it is usually 
just a typo in one of the tags, or trying to use two baselines, etc...


Thierry

2015-02-06 14:40 GMT+01:00 Sebastian Tleye >:


Hi Thierry,

I still have the same problem, I managed to install and configure
GitFiletree, I can add a remote git repository, load packages from
it, etc.
Also, I created a new stable version with the versioner. If I open
the repository with Monticello I can see the history of the the
packages, not only the last one.
However, It's still throwing the same error, it cannot resolve the
name of the package that it needs.

(By the way,  the development version can be still loaded correctly)

Any Idea of what can it be?
I am not an expert in Metacello, so maybe is a problem with the
Configuration file (in the baseline I tried both, reference to the
remote git repository and to the local gitfiletree repository)


2015-02-05 13:38 GMT+01:00 Thierry Goubier
mailto:thierry.goub...@gmail.com>>:



2015-02-05 13:26 GMT+01:00 Sebastian Tleye
mailto:sebastian.tl...@gmail.com>>:

Ok, great, I'll try GitFileTree, we are using the standard
port.


Please ask if you need any help. Criticism on the lack of
documentation and missing features accepted :)

Thierry


Thanks!

2015-02-05 12:53 GMT+01:00 Serge Stinckwich
mailto:serge.stinckw...@gmail.com>>:

Why  not launching a kickstarter thing to have someone
(you !) paid to have a clean integration of git/pharo
with documentation ? I guess people, companies and
associations like ESUG can give money for that.


Sent from my iPhone

On 5 févr. 2015, at 12:38, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:




2015-02-05 11:27 GMT+01:00 Sebastian Tleye
mailto:sebastian.tl...@gmail.com>>:

Thanks Yuriy and Thierry,

I see what I can do, I was using Bitbucket until
some time ago but now we moved our project to a
private git server!


If you are on a private server, then GitFileTree will
work (except if the git server is on a non-standard
port: I will add support for that in the near future).

Look for baselines and branches support to make your
life (and your configurations) simpler.

As I said during PharoDays: we now have a good chunk
of the necessary infrastructure and we (the Pharo
community) can develop additional support if needed.
Asking (funding) the consortium for that could be a
real cool way of contributing :)

Thierry


2015-02-05 11:13 GMT+01:00 Thierry Goubier
mailto:thierry.goub...@gmail.com>>:

Hi Sebastian,

filetree only gives you access to the latest
version of your packages, and you can't
access the history without access to the
underlying version control system you are using.

This access for Metacello is available in two
ways: via Metacello github:// and
bitbucket:// urls and tags or branches (but
you need to be using either github or
bitbucket), or via GitFileTree if you are
using git.

Thierry

2015-02-05 11:03 GMT+01:00 Sebastian Tleye
mailto:sebastian.tl...@gmail.com>>:

Hi,

I am using a filetree repository for my
project, also I have created a first
stable version  using the versioner tool.
Everything was working fine until I
commited more changes, now when I want to
install the stable version is throwing an

Re: [Pharo-dev] Metacello + Filetree

[Thierry Goubier]

Hi Sebastian,

It seems that something is amiss in the configuration. You are using a
baseline in the configuration? Are you using #common, #pharoX.x tags? I am
also a bit lost with some of Metacello errors, and it is usually just a
typo in one of the tags, or trying to use two baselines, etc...

Thierry

2015-02-06 14:40 GMT+01:00 Sebastian Tleye :

> Hi Thierry,
>
> I still have the same problem, I managed to install and configure
> GitFiletree, I can add a remote git repository, load packages from it, etc.
> Also, I created a new stable version with the versioner. If I open the
> repository with Monticello I can see the history of the the packages, not
> only the last one.
> However, It's still throwing the same error, it cannot resolve the name of
> the package that it needs.
>
> (By the way,  the development version can be still loaded correctly)
>
> Any Idea of what can it be?
> I am not an expert in Metacello, so maybe is a problem with the
> Configuration file (in the baseline I tried both, reference to the remote
> git repository and to the local gitfiletree repository)
>
>
> 2015-02-05 13:38 GMT+01:00 Thierry Goubier :
>
>>
>>
>> 2015-02-05 13:26 GMT+01:00 Sebastian Tleye :
>>
>>> Ok, great, I'll try GitFileTree, we are using the standard port.
>>>
>>
>> Please ask if you need any help. Criticism on the lack of documentation
>> and missing features accepted :)
>>
>> Thierry
>>
>>
>>>
>>> Thanks!
>>>
>>> 2015-02-05 12:53 GMT+01:00 Serge Stinckwich 
>>> :
>>>
 Why  not launching a kickstarter thing to have someone (you !) paid to
 have a clean integration of git/pharo with documentation ? I guess people,
 companies and associations like ESUG can give money for that.


 Sent from my iPhone

 On 5 févr. 2015, at 12:38, Thierry Goubier 
 wrote:



 2015-02-05 11:27 GMT+01:00 Sebastian Tleye :

> Thanks Yuriy and Thierry,
>
> I see what I can do, I was using Bitbucket until some time ago but now
> we moved our project to a private git server!
>

 If you are on a private server, then GitFileTree will work (except if
 the git server is on a non-standard port: I will add support for that in
 the near future).

 Look for baselines and branches support to make your life (and your
 configurations) simpler.

 As I said during PharoDays: we now have a good chunk of the necessary
 infrastructure and we (the Pharo community) can develop additional support
 if needed. Asking (funding) the consortium for that could be a real cool
 way of contributing :)

 Thierry


>
> 2015-02-05 11:13 GMT+01:00 Thierry Goubier 
> :
>
>> Hi Sebastian,
>>
>> filetree only gives you access to the latest version of your
>> packages, and you can't access the history without access to the 
>> underlying
>> version control system you are using.
>>
>> This access for Metacello is available in two ways: via Metacello
>> github:// and bitbucket:// urls and tags or branches (but you need to be
>> using either github or bitbucket), or via GitFileTree if you are using 
>> git.
>>
>> Thierry
>>
>> 2015-02-05 11:03 GMT+01:00 Sebastian Tleye > >:
>>
>>> Hi,
>>>
>>> I am using a filetree repository for my project, also I have created
>>> a first stable version  using the versioner tool.
>>> Everything was working fine until I commited more changes, now when
>>> I want to install the stable version is throwing an error saying that
>>> cannot resolve the package that it needs, however if I load the 
>>> development
>>> version it works perfectly.
>>>
>>> To clarify a little,
>>>
>>> The development version tries to load
>>> Phadeo-ImporterExporters-SebastianTleye.12 and it works perfectly. The
>>> stable version tries to load Phadeo-ImporterExporters-SebastianTleye.10 
>>> and
>>> it throws an error saying that it cannot be resolve.
>>>
>>> Any Idea of what is happening?
>>> I read that filetree and Metacello are compatibles so I don't know
>>> what's the problem
>>>
>>
>> Hi sebastian
>>
>>
>>>
>>> Thanks in advance
>>>
>>> Sebastián Tleye
>>>
>>
>>
>
>
> --
> Sebastián Tleye
>


>>>
>>>
>>> --
>>> Sebastián Tleye
>>>
>>
>>
>
>
> --
> Sebastián Tleye
>

Re: [Pharo-dev] Slides PharoDays...

[Marcus Denker]

> On 07 Feb 2015, at 19:27, Yuriy Tymchuk  wrote:
> 
> Missing graphics :) http://www.slideshare.net/YuriyTymchuk/pharo-days-2015 
> 
> 

can you send my a pdf version of the slides? So that we archive them with the 
rest.

>> On 07 Feb 2015, at 18:18, Marcus Denker > > wrote:
>> 
>> Hi,
>> 
>> Slides are online:
>> 
>> http://www.slideshare.net/pharoproject/presentations 
>> 
>> 
>> (thanks to Santiago for collecting and uploading!)
>> 
>> Videos soon… need to put titles and cross links to slides.
>> 
>>  Marcus
> 

Re: [Pharo-dev] Slides PharoDays...

[Yuriy Tymchuk]

Missing graphics :) http://www.slideshare.net/YuriyTymchuk/pharo-days-2015 


> On 07 Feb 2015, at 18:18, Marcus Denker  wrote:
> 
> Hi,
> 
> Slides are online:
> 
> http://www.slideshare.net/pharoproject/presentations 
> 
> 
> (thanks to Santiago for collecting and uploading!)
> 
> Videos soon… need to put titles and cross links to slides.
> 
>   Marcus

Re: [Pharo-dev] ||

[Thierry Goubier]

2015-02-07 18:48 GMT+01:00 Eliot Miranda :

> Hi Hernan,
>
> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>>
>> 2015-02-07 5:59 GMT-03:00 kilon alios :
>>
>>> Personally I don't like Pragmas, they have not convinced me so far that
>>> they fit the style of Smalltalk syntax. I have to confess though I never
>>> liked descriptive elements and languages .
>>>
>>>
>> Me neither. Actually the pragma idea is not wrong per se, it is the tag
>> syntax to write them which bothers me. Because the world can be described
>> with tags if you start that path.
>>
>
> How exactly is the syntax wrong?
> The  syntax predates pragmas.  It was used first
> for numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it
> with primitive:module:.  I and others extended it to include arbitrary
> literal message patterns.  The syntax of a literal message pattern is the
> syntax of a send with no receiver and only literal arguments.  The use of
> this syntax means
> a) no new syntax
> b) each pragma is potentially executable
> c) methods using specific pragmas can be found using "find senders"
> d) the execution side of a pragma can be found using "find implementors"
>
> So what's wrong with that?  How is it wrong to use a common Smalltalk
> object, a Message, that is well-supported in the system, for method
> metadata?
>

The point was: descriptive and the world could be described  by tags :)
Message syntax for pragmas is just a consequence of the original primitive
syntax, nothing else (I.e. natural syntax extension). Given how it is used
and that the "potentially executable" is just that, potential, array
literals would work just as well (and I'm nearly sure that a todays design
for pragmas would give us something like STON content :))


>
>
>
>> There are other ways to add metadata to methods. Without tagging.
>>
>
> Haven't we discussed that?  Putting metadata off to the side introduces a
> bookkeeping problem.  It is a bad idea.
>

And pragmas only partially address that.

Imagine that Sista works, that it has dozens of tuning points for a method
(int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this
loop should be enrolled) do you imagine writing all that into the method to
guide Sista with pragmas? You'll end up in exactly the same situation as
OpenMP 4, where it is possible to write programs with more #pragma lines
than C/C++ code.

(And C #pragmas are clearly more powerfull than Smalltalk's, since they are
not required to be at the start of the function only)


>
>
>> And they don't need to be in the method pane itself.
>>
>
> For some kinds of metadata, for metadata with semantics, not just a
> documentary function, it is important for the metadata to be obvious.  No
> one has argued for hiding the primitive specification off-to-the-side.
>  "Need" is a poor criticism here because using turing equivalence lots of
> things don't "need" to be the way they are.  Instead why not ask what are
> the pros and cons?
>
>
>
>> It is like having to specify protocol because there is no list pane to
>> create them.
>>
>
> I disagree.  When the pragma is specifying type information, specifying
> that the method is an action on a specific menu, is a pane in an inspector,
> and many other uses, it is essential that that information be represented,
> and putting it in a one-off bookkeeping system is a bad idea.  We're not
> talking about simple documentary metadata like author, category etc.  We're
> using pragmas for semantics, semantics of the method that are outside of
> its execution semantics, semantics about how the method fits in the broader
> system.  And putting that in non-obvious places is a bad idea.
>

Good, you're giving my favorite examples for what pragmas are redundant :)

The method with the menu pragma is named "worldMenuCommand" ...

The method with the gtInspector pragma is named "gtInspectorPresentation..."

Additionally, as I told you before: the pragma semantic isn't in the
method... It's somewhere else in the system and senders of that pragma
doesn't get it.

Just have a look at OmniBrowser and tell me that you don't understand where
the menu commands are :)

Thierry

Re: [Pharo-dev] ||

[kilon alios]

"Kilon, pragmas are not limited to being descriptive."

Ok , I went back and carefully read your posts. I did not noticed that
pragmas are executable too, I stand corrected. It appears I underestimated
Pragmas, after reading your posts I see where you going with this.
Especially the part of adding methods to objects like menu
entries definitely makes some sense.

The more I think how I would do this, the more I start to appreciate
pragmas. For example I would attach some variables to Object class to
create a dictionary that will manage meta data for each method. That would
move the definition of the method meta data outside the method definition
itself but I am not sure if that is such a good thing afterall.

I think I will let myself get a few years more experience in Pharo to make
up my mind and fully appreciate pragmas.

Re: [Pharo-dev] Pharo 4 & NeoCSV

[Sven Van Caekenberghe]

> On 07 Feb 2015, at 17:21, stepharo  wrote:
> 
> sven I'm adding a menu to the configuration browser to define the 
> corresponding repo in MC because I'm tired to add repo manually.

OK.

I always just load a random small thing to get the repo defined ;-)

> Stef
> 
> Le 7/2/15 14:19, Sven Van Caekenberghe a écrit :
>> Hi Andreas,
>> 
>> I added it.
>> 
>> Sven
>> 
>>> On 07 Feb 2015, at 13:59, Andreas Wacknitz  wrote:
>>> 
>>> I miss the configuration of NeoCSV in the configuration browser of Pharo 4. 
>>> Is there any reason for the lack of it?
>>> NeoJSON is available, though…
>>> 
>>> Regards
>>> Andreas
>> 
>> 
> 
> 

Re: [Pharo-dev] ||

[Eliot Miranda]

Hi Hernan,

On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

>
> 2015-02-07 5:59 GMT-03:00 kilon alios :
>
>> Personally I don't like Pragmas, they have not convinced me so far that
>> they fit the style of Smalltalk syntax. I have to confess though I never
>> liked descriptive elements and languages .
>>
>>
> Me neither. Actually the pragma idea is not wrong per se, it is the tag
> syntax to write them which bothers me. Because the world can be described
> with tags if you start that path.
>

How exactly is the syntax wrong?
The  syntax predates pragmas.  It was used first for
numeric primitives in Smalltalk-76 or Smalltalk-80.  Squeak extended it
with primitive:module:.  I and others extended it to include arbitrary
literal message patterns.  The syntax of a literal message pattern is the
syntax of a send with no receiver and only literal arguments.  The use of
this syntax means
a) no new syntax
b) each pragma is potentially executable
c) methods using specific pragmas can be found using "find senders"
d) the execution side of a pragma can be found using "find implementors"

So what's wrong with that?  How is it wrong to use a common Smalltalk
object, a Message, that is well-supported in the system, for method
metadata?



> There are other ways to add metadata to methods. Without tagging.
>

Haven't we discussed that?  Putting metadata off to the side introduces a
bookkeeping problem.  It is a bad idea.


> And they don't need to be in the method pane itself.
>

For some kinds of metadata, for metadata with semantics, not just a
documentary function, it is important for the metadata to be obvious.  No
one has argued for hiding the primitive specification off-to-the-side.
 "Need" is a poor criticism here because using turing equivalence lots of
things don't "need" to be the way they are.  Instead why not ask what are
the pros and cons?



> It is like having to specify protocol because there is no list pane to
> create them.
>

I disagree.  When the pragma is specifying type information, specifying
that the method is an action on a specific menu, is a pane in an inspector,
and many other uses, it is essential that that information be represented,
and putting it in a one-off bookkeeping system is a bad idea.  We're not
talking about simple documentary metadata like author, category etc.  We're
using pragmas for semantics, semantics of the method that are outside of
its execution semantics, semantics about how the method fits in the broader
system.  And putting that in non-obvious places is a bad idea.


>
> Hernán
>
>>
>> About python decorators I disagree that are similar to pragmas. Pragmas
>> are focused on being descriptive , python decorators are descriptive as by
>> product. The main focus of python decorators is to shorten code by
>> introducing syntactic sugar.
>>
>
Kilon, pragmas are not limited to being descriptive.


>
>> I agree though this is a very interesting discussion and I dont
>> understand most of the things stated here so I leave an open door and mind
>> for pragmas. Maybe one day I will "get it".
>>
>
That would be nice :)

>
>
>
>
>
>>
>> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>>
>>>
>>> 2015-02-06 22:00 GMT+01:00 stepharo :
>>>
 Really interesting discussion. I like pragmas but this is interesting
 to see them challenged.

>>>
>>> Thanks. It's a pleasure to discuss that way :)
>>>
>>>
  Yes, but there end up being lots of naming conventions and they are
> non-obvious.  Whereas pragmas, because they are in-your-face in the 
> methods
> in question, don't need conventions. They just need documenting ;-).
>
 Thierry I'm skeptical that multiple protocol will save the problem
 because you will rely on coding conventions.

>>>
>>> Pragma as well: just explain the conventions behind the gtInspector
>>> pragmas, for example.
>>>
>>> But give me multiple protocols and I'll show you the same conventions
>>> rewritten in less lines (and a slightly more efficient code).
>>>
>>>
 And pragma is a clever tagging.

>>>
>>> Then maybe we should remove protocols and replace them with pragmas :)
>>>
>>> Thierry
>>>
>>>

 Stef



>>>
>>
>


-- 
best,
Eliot

Re: [Pharo-dev] [Slots] Invisible Slots

[Marcus Denker]

> On 07 Feb 2015, at 18:29, Marcus Denker  wrote:
> 
> 
> 
> On Fri, Feb 6, 2015 at 10:13 PM, stepharo  > wrote:
> I want relationships for certain modeling purposes
> What I like is that we should arrive to get a collection of useful slots with 
> optimal implementation instead all of us reinventing the wheel.
> 
> I have started to collect the examples in Slots-Examples (in #481).
> At the start these are artificial (just testing/showing something), but 
> slowly we will add useful ones, too.
> 
> I started to implement PropertySlot, this uses hidden slots, initialisation 
> (to set the empty dictionary of the base slot), virtual slots
> (the proper slots), reflectively changing the class both when adding and 
> removing (to add the base slot and remove it as needed).
> 
and custom byte code generation to read and write with just #at: and #at:put on 
the base slot…

Marcus

Re: [Pharo-dev] [Slots] Invisible Slots

[Marcus Denker]

On Fri, Feb 6, 2015 at 10:13 PM, stepharo  wrote:

> I want relationships for certain modeling purposes
> What I like is that we should arrive to get a collection of useful slots
> with optimal implementation instead all of us reinventing the wheel.
>
> I have started to collect the examples in Slots-Examples (in #481).
At the start these are artificial (just testing/showing something), but
slowly we will add useful ones, too.

I started to implement PropertySlot, this uses hidden slots, initialisation
(to set the empty dictionary of the base slot), virtual slots
(the proper slots), reflectively changing the class both when adding and
removing (to add the base slot and remove it as needed).

   Marcus

[Pharo-dev] [ANN] Pharo Consortium New Academic Partner: REVEAL University of Lugano

[Marcus Denker]

The Pharo Consortium is very happy to announce that the REVEAL 
research group of the University of Lugano has joined the Consortium 
as an Academic Partner.

The REVEAL (Reverse Engineering, Visualization, Evolution Analysis 
Lab) group carries out research in diverse aspects of how to ease the
 comprehension and evolution of large and complex software systems. 
Current research is focused on software visualization, mining software 
repositories, collaborative development, and novel integrated 
development environments.

About

   - REVEAL: http://www.inf.usi.ch/faculty/lanza/reveal.html
   - University of Lugano: http://www.usi.ch/en/index.htm
   - 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] Slides PharoDays...

[Marcus Denker]

Hi,

Slides are online:

http://www.slideshare.net/pharoproject/presentations 


(thanks to Santiago for collecting and uploading!)

Videos soon… need to put titles and cross links to slides.

Marcus

Re: [Pharo-dev] [squeak-dev] Re: ||

[kilon alios]

And none of the XML and web technologies sell as much as Angry Birds and
Candy Crash Saga :D

I think you underestimate people. True Web is very popular, but lets not
forget all the promises a decade ago that we will completely move to the
cloud in a few years and we are still desktop all the way. Only desktop has
moved to mobile devices which none could predict it at the time.

On the other hand Smalltalk was not rejected because it was beautiful , it
was rejected because it failed to adjust to current demands. It remained a
good proof of concept and not much more than that. It opened the door , but
never truly entered the room.

On Sat, Feb 7, 2015 at 6:01 PM, Andreas Wacknitz  wrote:

>
> > Am 07.02.2015 um 16:18 schrieb David T. Lewis :
> >
> > On Thu, Feb 05, 2015 at 01:54:51PM +0100, Marcus Denker wrote:
> >>
> >>> On 05 Feb 2015, at 10:12, Marcus Denker 
> wrote:
> 
>  On 05 Feb 2015, at 10:04, Marcus Denker 
> wrote:
> >>>
> >>> Another way to see it: How would the original Smalltalk be designed if
> they would have had 4GB RAM in 1978?
> >>>
> >>> What fascinates me still is that Smalltalk used the existing resources
> (even building their own machines) to an
> >>> extreme, while today we are obsessed to find reasons why we can not do
> anything that makes the system
> >>> slower or use more memory than yesterday. And that even with resources
> growing every year???
> >>>
> >>> This is why we e.g. now have a meta object describing every instance
> variable in Pharo. I am sure there are people
> >>> who will see these ~7000 objects as pure waste??? while I would say
> that we have already *now* the resources to be
> >>> even more radical.
> >>>
> >>
> >> Seemingly I still can not explain what I mean in away that people get
> it, so please just ignore this mail.
> >>
> >>  Marcus
> >>
> >
> > Your point makes good sense to me. In 1978, a system in which a low-level
> > integer was represented as an object with behavior would have been
> perceived
> > as a rediculously wasteful idea. And can you imagine someone seriously
> > suggesting something so wasteful as automatic memory management?
> >
> > So if the "same" system was being designed today, it might very well
> include
> > new concepts that today are perceived as wasteful. Some of those concepts
> > might turn out to be very good thing once we get used to them.
> The times have changed. Today waste seems to be a requirement.
> Whatever application you have - reimplement it using „web technologies“.
> Whatever data you have - store it in „the cloud“ and tunnel its
> transportation over port 80,
> gain extra points for using XML here.
>
> Today, beautiful small things like Smalltalk are ignored by the masses and
> being laughed at.
>
> Andreas
>

Re: [Pharo-dev] ||

[kilon alios]

I agree, my objection too is how it looks syntax wise. As I said I don't
understand pragmas deeply enough to make a decision if I want them removed
or not.

Tag wise, well I think a tag should be an IDE and not a language feature.
But thats my personal preference. Protocols for me at least is another way
to tag things.

As I said in the past I would prefer a more elaborate system of tagging for
methods and classes similar how Stackoverflow questions work of default and
custom tags.

On the other hand, people like different things so I never made a big deal
out of it.  So for now I just tolerate pragmas and they do tolerate me :D

On Sat, Feb 7, 2015 at 5:41 PM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

>
> 2015-02-07 5:59 GMT-03:00 kilon alios :
>
>> Personally I don't like Pragmas, they have not convinced me so far that
>> they fit the style of Smalltalk syntax. I have to confess though I never
>> liked descriptive elements and languages .
>>
>>
> Me neither. Actually the pragma idea is not wrong per se, it is the tag
> syntax to write them which bothers me. Because the world can be described
> with tags if you start that path.
> There are other ways to add metadata to methods. Without tagging.
> And they don't need to be in the method pane itself.
> It is like having to specify protocol because there is no list pane to
> create them.
>
> Hernán
>
>>
>> About python decorators I disagree that are similar to pragmas. Pragmas
>> are focused on being descriptive , python decorators are descriptive as by
>> product. The main focus of python decorators is to shorten code by
>> introducing syntactic sugar.
>>
>> I agree though this is a very interesting discussion and I dont
>> understand most of the things stated here so I leave an open door and mind
>> for pragmas. Maybe one day I will "get it".
>>
>
>
>
>
>
>>
>> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>>
>>>
>>> 2015-02-06 22:00 GMT+01:00 stepharo :
>>>
 Really interesting discussion. I like pragmas but this is interesting
 to see them challenged.

>>>
>>> Thanks. It's a pleasure to discuss that way :)
>>>
>>>
  Yes, but there end up being lots of naming conventions and they are
> non-obvious.  Whereas pragmas, because they are in-your-face in the 
> methods
> in question, don't need conventions. They just need documenting ;-).
>
 Thierry I'm skeptical that multiple protocol will save the problem
 because you will rely on coding conventions.

>>>
>>> Pragma as well: just explain the conventions behind the gtInspector
>>> pragmas, for example.
>>>
>>> But give me multiple protocols and I'll show you the same conventions
>>> rewritten in less lines (and a slightly more efficient code).
>>>
>>>
 And pragma is a clever tagging.

>>>
>>> Then maybe we should remove protocols and replace them with pragmas :)
>>>
>>> Thierry
>>>
>>>

 Stef



>>>
>>
>

Re: [Pharo-dev] Pharo 4 & NeoCSV

[stepharo]

sven I'm adding a menu to the configuration browser to define the 
corresponding repo in MC because I'm tired to add repo manually.


Stef

Le 7/2/15 14:19, Sven Van Caekenberghe a écrit :

Hi Andreas,

I added it.

Sven


On 07 Feb 2015, at 13:59, Andreas Wacknitz  wrote:

I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is 
there any reason for the lack of it?
NeoJSON is available, though…

Regards
Andreas

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 9ab119: 40481

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 9ab11917016d78cb7c3a9af695bd4c15faaceb1b
  
https://github.com/pharo-project/pharo-core/commit/9ab11917016d78cb7c3a9af695bd4c15faaceb1b
  Author: Jenkins Build Server 
  Date:   2015-02-07 (Sat, 07 Feb 2015)

  Changed paths:
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script481.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40481.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Slot.package/AccessorInstanceVariableSlot.class/README.md
A Slot.package/AccessorInstanceVariableSlot.class/definition.st
A Slot.package/AccessorInstanceVariableSlot.class/instance/class 
building/installingIn_.st
A Slot.package/AccessorInstanceVariableSlot.class/instance/class 
building/removingFrom_.st
A Slot.package/ExampleSlotWithDefaultValue.class/README.md
A Slot.package/ExampleSlotWithDefaultValue.class/definition.st
A 
Slot.package/ExampleSlotWithDefaultValue.class/instance/initialization/initialize_.st
A 
Slot.package/ExampleSlotWithDefaultValue.class/instance/meta-object-protocol/wantsInitalization.st
A System-Caching.package/AbtractCache.class/instance/accessing/addAll_.st
A System-Caching.package/AbtractCache.class/instance/accessing/at_put_.st
A System-Caching.package/LRUCache.class/instance/accessing/at_put_.st
A System-Caching.package/TTLCache.class/instance/accessing/at_put_.st
A 
System-CachingTests.package/LRUCacheTests.class/instance/testing/testPopulate.st

  Log Message:
  ---
  40481
14851 Extend AbstractCache API to allow cache population using #at:put:
https://pharo.fogbugz.com/f/cases/14851

14883 Add two examples for Slots
https://pharo.fogbugz.com/f/cases/14883

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

Re: [Pharo-dev] ||

[Hernán Morales Durand]

2015-02-07 5:59 GMT-03:00 kilon alios :

> Personally I don't like Pragmas, they have not convinced me so far that
> they fit the style of Smalltalk syntax. I have to confess though I never
> liked descriptive elements and languages .
>
>
Me neither. Actually the pragma idea is not wrong per se, it is the tag
syntax to write them which bothers me. Because the world can be described
with tags if you start that path.
There are other ways to add metadata to methods. Without tagging.
And they don't need to be in the method pane itself.
It is like having to specify protocol because there is no list pane to
create them.

Hernán

>
> About python decorators I disagree that are similar to pragmas. Pragmas
> are focused on being descriptive , python decorators are descriptive as by
> product. The main focus of python decorators is to shorten code by
> introducing syntactic sugar.
>
> I agree though this is a very interesting discussion and I dont understand
> most of the things stated here so I leave an open door and mind for
> pragmas. Maybe one day I will "get it".
>





>
> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>>
>>
>> 2015-02-06 22:00 GMT+01:00 stepharo :
>>
>>> Really interesting discussion. I like pragmas but this is interesting to
>>> see them challenged.
>>>
>>
>> Thanks. It's a pleasure to discuss that way :)
>>
>>
>>>  Yes, but there end up being lots of naming conventions and they are
 non-obvious.  Whereas pragmas, because they are in-your-face in the methods
 in question, don't need conventions. They just need documenting ;-).

>>> Thierry I'm skeptical that multiple protocol will save the problem
>>> because you will rely on coding conventions.
>>>
>>
>> Pragma as well: just explain the conventions behind the gtInspector
>> pragmas, for example.
>>
>> But give me multiple protocols and I'll show you the same conventions
>> rewritten in less lines (and a slightly more efficient code).
>>
>>
>>> And pragma is a clever tagging.
>>>
>>
>> Then maybe we should remove protocols and replace them with pragmas :)
>>
>> Thierry
>>
>>
>>>
>>> Stef
>>>
>>>
>>>
>>
>

Re: [Pharo-dev] How to connect to SmalltalkHub using only an MCHttpRepository

[Ben Coman]

The Smalltalkhub repository page...
http://smalltalkhub.com/#!/~StephaneDucasse/Tetris

shows...
MCHttpRepository
location: 'http://smalltalkhub.com/mc/StephaneDucasse/Tetris/main'
user: ''
password: ''

So you are missing the '/main' and also note the change of '/#!/' to '/mc/'
, which caught me out a few times.

cheers -ben

On Sat, Feb 7, 2015 at 11:02 PM, stepharo  wrote:

> Hi guys
>
> I should be doing something obvious totally wrong but I cannot connect to
>
> MCSmalltalkhubRepository
> owner: 'StephaneDucasse'
> project: 'Tetris'
> user: 'StephaneDucasse'
> password: ''
>
> using
>
> MCHttpRepository
> location: 'http://www.smalltalkhub.com/StephaneDucasse/Tetris'
> user: 'StephaneDucasse'
> password: ''
>
> I tried all kind of combinations.
>
> MCHttpRepository
> location: 'http://smalltalkhub.com/#!/~StephaneDucasse/Tetris'
> user: 'StephaneDucasse'
> password: ''
>
> open so this is a progress but I cannot see the files inside.
>
>
> Stef
>
>

[Pharo-dev] How to connect to SmalltalkHub using only an MCHttpRepository

[stepharo]

Hi guys

I should be doing something obvious totally wrong but I cannot connect to

MCSmalltalkhubRepository
owner: 'StephaneDucasse'
project: 'Tetris'
user: 'StephaneDucasse'
password: ''

using

MCHttpRepository
location: 'http://www.smalltalkhub.com/StephaneDucasse/Tetris'
user: 'StephaneDucasse'
password: ''

I tried all kind of combinations.

MCHttpRepository
location: 'http://smalltalkhub.com/#!/~StephaneDucasse/Tetris'
user: 'StephaneDucasse'
password: ''

open so this is a progress but I cannot see the files inside.


Stef

Re: [Pharo-dev] Pharo 4 & NeoCSV

[Andreas Wacknitz]

Am 07.02.15 um 14:19 schrieb Sven Van Caekenberghe:

Hi Andreas,

I added it.

Thanks a lot.

Andreas


Sven


On 07 Feb 2015, at 13:59, Andreas Wacknitz  wrote:

I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is 
there any reason for the lack of it?
NeoJSON is available, though…

Regards
Andreas

Re: [Pharo-dev] Pharo 4 & NeoCSV

[Sven Van Caekenberghe]

Hi Andreas,

I added it.

Sven

> On 07 Feb 2015, at 13:59, Andreas Wacknitz  wrote:
> 
> I miss the configuration of NeoCSV in the configuration browser of Pharo 4. 
> Is there any reason for the lack of it?
> NeoJSON is available, though…
> 
> Regards
> Andreas

[Pharo-dev] Pharo 4 & NeoCSV

[Andreas Wacknitz]

I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is 
there any reason for the lack of it?
NeoJSON is available, though…

Regards
Andreas

Re: [Pharo-dev] Howto create a new configuration?

[Nicolai Hess]

2015-02-06 22:02 GMT+01:00 Juraj Kubelka :

> I have changed two methods of the configuration:
>
> -=-=-
> stable: spec
> 
>
> spec for: #'pharo2.x' version: '2.1'.
> "after some modification in NB made it incompatible with 3.0"
> spec for: #'pharo3.x' version: '2.3'.
> *spec for: #'pharo4.x' version: '2.7’.  “<<== added, maybe instead of
> pharo4.x could be common"*
> -=-=-
> development: spec
> 
>
> spec for: #'common' version: '*2.3-baseline*’. “<<== it is likely not
> necessary"
> -=-=-
>
> I have changed it, because I think there should be two lines in Versioner:
> one with development label, second with stable label.
> Then everything works.
> Let me know if it helps.
> Juraj
>

Thank you Juraj,
that works  better, but now, commiting the new configuration
shows a bunch of "Critical Issues"
Critical Warning missing recommend field...
Critcal Warning The name of package x does not match file name x.7
Critical Warning No Version specified.


Not that easy. Maybe, the ConfigurationOfAthens was only written and
updated by hand, does not work with Versionner?







>
>
> 6. 2. 2015 v 17:28, Nicolai Hess :
>
> 2015-02-06 1:40 GMT+01:00 Juraj Kubelka :
>
>> Well, then I cannot see packages that are not included in the version
>> 2.7. Can you mention some? I will try to make a new version.
>>
>
> I want to include the latest versions of
> Athens-Cairo: Athens-Cairo-NicolaiHess.82
> and
> Athens-Text: Athens-Text-NicolaiHess.16
>
> The other packages hasn't change since version 2.7
>
>
> nicolai
>
>
>
>>
>> Juraj
>>
>> 5. 2. 2015 v 20:07, Nicolai Hess :
>>
>>
>> 2015-02-05 23:06 GMT+01:00 Juraj Kubelka :
>>
>>> I have downloaded the latest Pharo 4 and it looks like Esteban Lorenzano
>>> did the job. There is a new 2.7 version.
>>>
>>
>> No, the version 2.7 is not new, I have some changes that came after that
>> version.
>>
>>
>>>
>>> Cheers,
>>> Juraj
>>>
>>> 5. 2. 2015 v 18:28, Nicolai Hess :
>>>
>>> 2015-02-05 21:56 GMT+01:00 Juraj Kubelka :
>>>
 I am just guessing: try to click on “development” item on the left side.

>>>
>>>
>>> -> "Information: Nothing to save"
>>>
>>> Already tried :)
>>>
>>>

 Cheers,
 Juraj

 > 5. 2. 2015 v 17:13, Nicolai Hess :
 >
 > Hello,
 >
 > I fixed some issues for Athens and upload the changes to the
 > repository. Now, I want to use Versionner to create a new
 configuration.
 > What I tried:
 >
 > Open a fresh image
 > Open the Athens repository and load the new changesets
 >  -> There are some merge conflicts. Why? There shouldn't be
 > any conflicts. How do you do this?
 >
 > After merging the changes I open Versionner.
 > I thought I have to make a new Release but the button "Release
 Version" is
 > disabled.
 > What did I miss?
 >
 >
 >
 > nicolai


>>>
>>>
>>
>>
>
>

[Pharo-dev] [pharo-project/pharo-core] c8ce6d: 40480

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c8ce6dadac22e0dc8c0280e697c63c70c8161749
  
https://github.com/pharo-project/pharo-core/commit/c8ce6dadac22e0dc8c0280e697c63c70c8161749
  Author: Jenkins Build Server 
  Date:   2015-02-07 (Sat, 07 Feb 2015)

  Changed paths:
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script480.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40480.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Slot.package/Slot.class/instance/class building/installingIn_.st
A Slot.package/Slot.class/instance/class building/removingFrom_.st
R Slot.package/Slot.class/instance/meta-object-protocol/installingIn_.st
R Slot.package/Slot.class/instance/meta-object-protocol/removingFrom_.st
A 
Slot.package/Slot.class/instance/meta-object-protocol/wantsInitalization.st
A Slot.package/Slot.class/instance/private/addSlotInitToInitialize_.st
A Slot.package/Slot.class/instance/private/ensureInitalizeMethodExists_.st
A Slot.package/Slot.class/instance/private/ensureSlotIniatializationFor_.st
A Traits.package/TBehavior.class/instance/initialization/initializeSlots_.st

  Log Message:
  ---
  40480
14882 Slots: add mechanism for initializing slots
https://pharo.fogbugz.com/f/cases/14882

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

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

[GitHub]

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

Re: [Pharo-dev] [Slots] Slots that initialize

[Marcus Denker]

> On 07 Feb 2015, at 10:13, Marcus Denker  wrote:
> 
>> 
>> On 06 Feb 2015, at 18:15, Marcus Denker > > wrote:
>> 
>> 
>>> On 06 Feb 2015, at 11:50, Marcus Denker >> > wrote:
>>> 
 
 Next: When building classes with Slots, the class builder need to call 
 back on the slot and hand the class to each. Then the slot
 can reflectively change the class, e.g. the PropertySlot will check if 
 there is already a hidden property base slot and if not, add it
 reflectively).
>>> 
>>> This is now done:
>>> 
>>> 
>>> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-call-slots-when-building-a-class
>>>  
>>> 
>>> 
>> 
> 
> So, with this mechanism in place we can actually solve a nice problem: Slot 
> initialisation.
> 
> on #initialize, we want to hand the new object to each slot to give it a 
> change to initialize it.
> Now adding 
>   self allSlots do: [ :slot | slot initialize: anObject ]
> 
> to #initialize and doing that for all object is not good as this would slot 
> down all #initialize calls.
> We might want to pay that later when if we happen to use it a lot, but now 
> now.
> 
> https://pharo.fogbugz.com/f/cases/14882/Slots-add-mechanism-for-initializing-slots
>  
> 
> 

This is now in update #470

Marcus

Re: [Pharo-dev] [Slots] Slots that initialize

[Marcus Denker]

> On 06 Feb 2015, at 18:15, Marcus Denker  wrote:
> 
> 
>> On 06 Feb 2015, at 11:50, Marcus Denker  wrote:
>> 
>>> 
>>> Next: When building classes with Slots, the class builder need to call back 
>>> on the slot and hand the class to each. Then the slot
>>> can reflectively change the class, e.g. the PropertySlot will check if 
>>> there is already a hidden property base slot and if not, add it
>>> reflectively).
>> 
>> This is now done:
>> 
>>  
>> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-call-slots-when-building-a-class
>> 
> 

So, with this mechanism in place we can actually solve a nice problem: Slot 
initialisation.

on #initialize, we want to hand the new object to each slot to give it a change 
to initialize it.
Now adding 
self allSlots do: [ :slot | slot initialize: anObject ]

to #initialize and doing that for all object is not good as this would slot 
down all #initialize calls.
We might want to pay that later when if we happen to use it a lot, but now now.

https://pharo.fogbugz.com/f/cases/14882/Slots-add-mechanism-for-initializing-slots
 


now implements it this way:

1) Slots that want #initialize: the be called on allocation need to implement 
#wantsInitalization
2) Then magically we add #initialize if needed and, if needed, add 
self class initializeSlots: self.
to it.
(this for now just uses text manipulation… later this will be a nice 
example for a concept that
we need to reify as part of the MOP: “I want to hook into object 
initialization”).


Playing with it
——— 
 (I need to add a tests…)

InstanceVariableSlot subclass: #InitSlot
slots: {  }
classVariables: {  }
category: ‘PlayGround'

initialize: anObject
self write: 5 to: anObject. 

wantsInitalization
^ true

Now create a class:

Object subclass: #MyCClass
slots: { #ttt => InitSlot }
classVariables: {  }
category: ‘PlayGround'


MyCClass new ==> ttt is initialised with 5.


For what is this useful?
———

1) e.g. the virtual slot that hold the dictionary for all PropertySlots needs 
to be initialised with an empty Dict
2) We can start to experiment with Slots that specify a value in the definition
3) ….

Marcus

Re: [Pharo-dev] [Slots] Invisible Slots

[Ben Coman]

On Sat, Feb 7, 2015 at 5:13 AM, stepharo  wrote:

> I want relationships for certain modeling purposes
> What I like is that we should arrive to get a collection of useful slots
> with optimal implementation instead all of us reinventing the wheel.
>
> Stef
>

In the Flexible Object Layouts paper, it was first class relationships that
really caught my eye.  Thats what I am hoping for to start having a dive
into Slots.  And since the paper says "no mainstream OOPL provides
first-class relationships as a programming construct" it might be a nice
feature to advertise with Pharo 4 release.  "First-class relationships" is
quite a catchy term ?

cheers -ben


>
> Le 6/2/15 18:15, Marcus Denker a écrit :
>
>  On 06 Feb 2015, at 11:50, Marcus Denker  wrote:
>>>
>>>  Next: When building classes with Slots, the class builder need to call
 back on the slot and hand the class to each. Then the slot
 can reflectively change the class, e.g. the PropertySlot will check if
 there is already a hidden property base slot and if not, add it
 reflectively).

>>> This is now done:
>>>
>>> https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-
>>> ClassBuilder-to-call-slots-when-building-a-class
>>>
>>>  For playing with this, in 479:
>>
>> InstanceVariableSlot subclass: #AccessorSlot
>> slots: {  }
>> classVariables: {  }
>> category: ‘Package'
>>
>> two methods, #installingIn and #removingFrom:, which are called by the
>> class builder:
>>
>>
>> installingIn: aClass
>> | reader writer |
>>
>> reader := String streamContents: [ :str |
>> str
>> nextPutAll: self name;
>> cr;tab;
>> nextPutAll: ' ^';
>> nextPutAll: self name.
>>  ].
>> writer := String streamContents: [ :str |
>> str
>> nextPutAll: self name;
>> nextPutAll: ': anObject';
>> cr;tab;
>> nextPutAll: self name;
>> nextPutAll: ':= anObject.'.
>> ].
>> aClass compile: reader classified: 'accessing'.
>> aClass compile: writer classified: 'accessing’.
>>
>>
>> removingFrom: aClass
>>
>> aClass removeSelector: self name.
>> aClass removeSelector: self name asMutator.
>>
>>
>> Now we can make a class and see how the accessors are automatically added
>> (and removed when the slot is removed):
>>
>> Object subclass: #TT
>> slots: { # => AccessorSlot }
>> classVariables: {  }
>> category: ‘Package'
>>
>>
>> NOTE: this is an example of what can be done with Slots. It is *not* an
>> example of what *should* be done with Slots.
>> (this we only will know after using them for a while).
>>
>> Marcus
>>
>>
>>
>>
>>
>
>

Re: [Pharo-dev] ||

[kilon alios]

Personally I don't like Pragmas, they have not convinced me so far that
they fit the style of Smalltalk syntax. I have to confess though I never
liked descriptive elements and languages .

About python decorators I disagree that are similar to pragmas. Pragmas are
focused on being descriptive , python decorators are descriptive as by
product. The main focus of python decorators is to shorten code by
introducing syntactic sugar.

I agree though this is a very interesting discussion and I dont understand
most of the things stated here so I leave an open door and mind for
pragmas. Maybe one day I will "get it".

On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier 
wrote:

>
>
> 2015-02-06 22:00 GMT+01:00 stepharo :
>
>> Really interesting discussion. I like pragmas but this is interesting to
>> see them challenged.
>>
>
> Thanks. It's a pleasure to discuss that way :)
>
>
>>  Yes, but there end up being lots of naming conventions and they are
>>> non-obvious.  Whereas pragmas, because they are in-your-face in the methods
>>> in question, don't need conventions. They just need documenting ;-).
>>>
>> Thierry I'm skeptical that multiple protocol will save the problem
>> because you will rely on coding conventions.
>>
>
> Pragma as well: just explain the conventions behind the gtInspector
> pragmas, for example.
>
> But give me multiple protocols and I'll show you the same conventions
> rewritten in less lines (and a slightly more efficient code).
>
>
>> And pragma is a clever tagging.
>>
>
> Then maybe we should remove protocols and replace them with pragmas :)
>
> Thierry
>
>
>>
>> Stef
>>
>>
>>
>

Re: [Pharo-dev] ||

[Thierry Goubier]

2015-02-06 22:00 GMT+01:00 stepharo :

> Really interesting discussion. I like pragmas but this is interesting to
> see them challenged.
>

Thanks. It's a pleasure to discuss that way :)


>  Yes, but there end up being lots of naming conventions and they are
>> non-obvious.  Whereas pragmas, because they are in-your-face in the methods
>> in question, don't need conventions. They just need documenting ;-).
>>
> Thierry I'm skeptical that multiple protocol will save the problem because
> you will rely on coding conventions.
>

Pragma as well: just explain the conventions behind the gtInspector
pragmas, for example.

But give me multiple protocols and I'll show you the same conventions
rewritten in less lines (and a slightly more efficient code).


> And pragma is a clever tagging.
>

Then maybe we should remove protocols and replace them with pragmas :)

Thierry


>
> Stef
>
>
>

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

[Ben Coman]

On Sat, Feb 7, 2015 at 4:24 AM, stepharo  wrote:

>
>  Would it be possible/desirable to have a system such that:
> * bug fixes for external packages can be still be directly applied and
> tested in the Pharo-integrated branch
> * the CI workflow generates an updated ConfigurationOf{external package}
> that it pushes back to the external package repository?
>
> Yes this is the process I had in mind but this is not that simple because
> the configuration of the external package may also have changed
> and a merge should be done in the external package.
>

I considered that, but unless our workflow is constrained to having only a
single branch we need explore this space.   Consider Package A has a core
group of people working towards its next feature on its development branch,
and a third-party submits a bug fix for Package A.  Do we need to wait for
the next feature to be ready for integration to get the bug fix, and in one
hit get feature+fix (a), or do we want the fix integrated asap after
suitable review, and integrate the feature separately in its own time (b).
  In either case there will be a PackageA-thirdparty.#.mcz that needs to
merged.  Its just a question of when its merged.

Now if I am the third-party, the latter option (b) seems a faster and more
transparent turnaround which is more motivational.

So I haven't experienced much with distributed multi-party workflows.  I
only know the ones I read related to git.  Here it seems the common
workflow is for the feature branch to merge the master into itself before
pushing itself to the master. This seems to align with option (b).

I feel a bit that how we have a single versioned file for Configuration is
the bottleneck for the workflow of managing develop paths outside the
master image.  Sure multiple branches can be defined within that file, but
it seems awkward for multiple parties to manage those branches without
stepping on toes.

My musings lead me to the following analogy with git:
* The way that multiple branches are defined within the Configuration file
seems like the metadata defining a cloned git repository.  It defines the
versions for the heads of the various branches.
* Multiple parties updating the single ConfigurationOfA-name.#.mcz file is
like multiple parties working in the same cloned git repository.
* Copying the ConfigurationOfA-name.#.mcz to
ConfigurationOfA-Pharo-name.#.mcz would be like cloning a repository.  Its
a copy of the repository branch metadata.
* These files ConfigurationOfA-name.#.mcz and
ConfigurationOfA-Pharo-name.#.mcz could still be stored in the same server
location, similar to how github holds multiple repository clones, but the
heads of the branches could progress independently in each clone.
 * What we would need is a way to merge a Configuration's dependencies
similar to how we merge and display a Slice's dependencies (making the
workflow like merging a pull request between cloned repositories).  What do
we currently have like that?

cheers -ben



>  Its a great idea to separate out Configurations to devolve
> responsibility for sub-packages, but it adds some friction to bug fixing.
>
> Yes I always thought about it.
>
>
>   It "seems" we will have a single branch combining both feature
> development and bug-fixing, but it would be nicer to have two branches.
>
>
>
>
>  ---
> On another track, I wonder if it would be useful if a package which is
> part of a Configuration is made dirty, the Configuration itself could also
> be marked dirty?
>
>  cheers -ben
>
>
>
> On Fri, Feb 6, 2015 at 4:36 AM, Nicolai Hess  wrote:
>
>>  14850  Integrate GTools
>> #development
>> "From this version onwards the development version should be integrated."
>>
>>  Is this a good idea? Does the #development version always include *all*
>> the latest
>> changes, because after Andrei opened
>>  14866  Integrate GTools
>> (which got integrated in 40475)
>>  I uploaded some changes for issue
>>  14608 
>>  ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to
>> Spotter methods
>>  I set the status to "Fix Review needed",
>>
>>  but my changes are integrated in 40475 too!
>>
>>  I am not satisfied with the way external packages are handled.
>>  1. if there is not one slice/changeset per issue, it is even less
>> likely someone will
>>  review the changes.
>>  2. you don't know who works when on a issue. They are solved in a bulk.
>>  3. a new configuration might not only includes bugfixes but new
>> features as well.
>>  4. often we have unbound globals / undeclared references or other test
>> failures.
>>
>>  Can we use the build server for those external projects (like
>> GToolkitCore, Athens, TxText),
>> and that if a project makes a new configuration, it uses the same
>>  issue validator for loading and testing that configuration?
>>
>>
>>  nicolai
>>
>>
>>
>
>